I’m interested in other people’s thoughts on this.
In the Lisp world we often talk about “exploratory programming.” There are contexts, or at least there have been in my career, when I sit down to work on a particular problem and I don’t know ahead of time how it’s gonna work out or how I’m going to solve it. In these contexts I find Common Lisp to be a useful tool.
In other contexts I have a clear understanding of what I need to do, and so writing software in C++ or some other language is fine.
I’m not really interested in trying to shoehorn one solution into another context. I’d say use the tool that works best for you in the context in which you find yourself.
I could be wrong. Interested in your thoughts if you want to share them.
Exploratory programming, for me, involves tons of quick refactoring jobs. Moving methods around, copying code from one place to another. If I sit down with a decent Go, C#, or Java IDE, I can sling code left and right, mash it up, refactor it, move code around, change interfaces, etc.
The good tooling for these languages makes it so I can do a lot of this work with a couple button presses. I inevitably end up with code made from different phases of the exploration... the static type checker is good at reminding me which pieces of the code base need to be updated, because they were from an earlier phase of exploration. There are a lot of idiosyncratic tricks buried in here, like changing the name of a method when I change its semantics (like frobnicateWidgets() to frobnicateWidgets2()), so all the call sites become errors, and I can review them one by one.
I agree that tooling for JVM languages, Go, and C# are better at that, but clang and Jetbrains' CLion has helped close that gap. They've done a lot to make refactoring a lot easier, find errors better, and not have to compile just to find obvious mistakes. Newer languages are much better designed for IDE/tooling support in general, with stronger type systems in a lot of cases.
Jetbrains has put a similar amount of work into tools like Rider, it's just that they're starting from a language where these problems are much simpler to deal with.
I do exploratory programming all the time in C++ and Haskell. I know Lisp (scheme, Clojure) however I prefer typed languages. Types enable me to sketch out a whole application without writing any code. The types will tell me if the architecture is fully specked. And when done, the implementation step is simply to add the code needed to implement the type contracts. I often implement code with zero or very few bugs that way.
While I agree and do the same, I guess when something you integrate with is untyped (hardware, bags of (crappy) json or xml etc), exploring really helps.
In the Lisp world we often talk about “exploratory programming.” There are contexts, or at least there have been in my career, when I sit down to work on a particular problem and I don’t know ahead of time how it’s gonna work out or how I’m going to solve it. In these contexts I find Common Lisp to be a useful tool.
In other contexts I have a clear understanding of what I need to do, and so writing software in C++ or some other language is fine.
I’m not really interested in trying to shoehorn one solution into another context. I’d say use the tool that works best for you in the context in which you find yourself.
I could be wrong. Interested in your thoughts if you want to share them.