Does anyone else think of "configuring" as distinct from "programming"? Some activities I consider "configuring" and not "programming": much devops work such as Terraform, YML files for build pipelines, even commonly labeled "programming" of a VCR/DVR.

I think many times the distinction for me ends up being a matter of interface. I feel much more like I’m programming when doing the CDK vs doing Cloudformation. Yet, I’m accomplishing the same task. I don’t think it is because one is TS and one yaml, but the kinds of concepts I have to think about and the ability to build abstractions. Configuration, to me, ends up being a fill in the blank rather than a crafting. It’s like painting by numbers. Even though in the cdk, I am given a bunch of material to work with, and constraints on it, I still get to put that material together. I still can look at how it was implemented, I can still tear it apart and do something different. I can’t with configuration. I’m stuck listing details I don’t want to list. I definitely find all configuration tasks deeply unsatisfying and it’s one of the things I don’t like about “low code” tools as they are generally made. They are just configuration. No way to dive in, no way to remix, to take parts apart and make them do something new.

Yes! This relates to the very end of the episode, where (if I interpret correctly) Ivan imagines a world where general purpose programming languages are replaced (or supplanted) by domain-specific tooling. To reach that point, it seems we need to constrain the problem space to the point where the activity of programming becomes less interesting. Maybe I focus my attention elsewhere, though, to the output of the activity rather than the activity itself. Another small distinction in my mind is the addition of boolean logic and branching. I know, there are plenty of programming languages that don't involve branching. I know I shouldn't be constraining myself to the Von Neumann architecture. Still, branching offers freedom that makes the activity of programming more intellectually interesting.

My naive distinction between programming and configuration is that the former is specifying dynamic behavior of a system while the latter is providing initial values to it.

For what it’s worth Ivan’s definition of domain specific includes things like Elm. So I’d assume he’d imagine not a less powerful setup, but a tailor made approach. I definitely think there is a danger in going the direction of configuration though.

Sounds like Racket Lang could be a solid bet if they can withstand the elites knocking performance and distribution issues out. I do know someone was playing with emitting web assembly from Racket for distribution and runtimes.

I see it the same way as @Stefan. The configuration is declarative programming that defines constant values (like HTML / CSS..). I think a PL should be able to do both (and distinguish between the two). You can have branching in a declarative PL, but it will be resolved at compile time. One could argue that an executable is also a "constant", so all programming is configuration, but I think the difference is that the interactions are defined in the executable, if you have a constant, they are defined in the player. My last blog post touches on this.

I agree with @Jimmy Miller in that it’s all about the interface. Configuration done badly, feels like bureaucracy eg, filling in a tax form - you don’t know what to put in a lot of the times and it’s very tedious. Yaml/Json interfaces encourage this type of interface. When designed well, it’s part of the system eg, games that make you “configure” the game by playing the game

Ivan imagines a world where general purpose programming languages are replaced (or supplanted) by domain-specific tooling.

In some ways I think we are already there: javascript on the client, backend in C/C++/java/Python/C# etc. Shell scripting for OS, YML for build pipelines. In other ways, we are a long way off. An example: • say you are a nurse manager running a new service you have staff you know the laws relating to healthcare provision, safety, there are agree services, metrics and tariffs. How do you do this? what you do is run it on a bunch of spreadsheets. Why - even low code tools require you to bring in a consultant to get it working acceptably - if you are running a large service that is widespread you may eventually put together a business case to procure a system. (assuming there is a vendor for what your need). When the service winds down that patient information is lost.

Another potential distinction here, from the discussion above: some freedom to define relationships between different parts of the program. If we lock the user into a pre-defined schema with pre-defined relationships, then we fall squarely on the side of "configuration".

Sounds like Racket Lang could be a solid bet if they can withstand the elites knocking performance and distribution issues out.

Racket is interesting because the metaprogramming facilities open the doors to building a wider variety of programming languages. The performance question is interesting, because Racket has excellent performance, but it isn't a system programming language like Rust or C++ - and doesn't pretend to be. So you wouldn't run Racket on a large scale - but DSL's for professionals - the machines they use are mostly idle - the size and speed of the Racket is just not noticeable. What is missing is DSL's(future of coding!) that support the needs of the users. Racket has tools to help make those DSL's (as do many other languages) - but the DSL's for non-programmers don't exist yet.

I used to TA a compiler/PL design course and we would tell students that using their language should feel more like verbs than nouns.

@Jacob Zimmerman could you give me an example of a "bad" PL design, that this advice is trying to help people stay away from?

@Axel Svensson Not bad in a general sense, it was more because of the course logistics. We wanted to make sure that students implemented basic features like branching and iteration, etc. I just liked my teacher’s notion of coding in nouns vs verbs. At the extreme end, SVG would be a noun based language, even though it might explicitly describe an imperative routine.

The advice reminds me of this classic http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html?m=1

I wasn’t programming in 06, but reading the old the Java battles in the comments are hilarious. I’m sure it must’ve been exhausting.