Hacker News Reader

Also not many languages allow people to explore true powers of deeper stack modifications by delimited continuations. Using them the users would be able to create their own looping and threading constructs as well as custom exceptions and iterator mechanisms and effect handlers.

The concept of a "programmable" programming language is intuitively appealing, but in practice turns out to not be so helpful for actually shipping software. Everybody builds their own, incompatible versions of common utilities. This is why languages like Lisp or Forth are great for exploratory hacking with small teams but are very rarely used these days for larger scale development and lag far behind more mainstream languages in tooling.

What you really want is a tasteful "omakase" language design that gives you a carefully selected menu of building blocks that average developers can use to be productive. Languages like Kotlin and Swift are a good example of this. They cherry pick a lot of the good ideas from academic functional programming without going down the Scala/Haskell rabbit hole. Golang takes this to an extreme by providing native typed containers without exposing generics to the programmer.

The success of a language these days depends at least as much on the library ecosystem and tooling as it does on the language itself.

> programmable programming language ... appealing ... not so helpful

This has also been my observation, and that of many actual Lisp hackers I talked to. It also mirrors the experience the developers of Smalltalk documented: at first they had ultimate flexibility, every object could in effect re-define the language completely. Not so good.

On the other hand, we also seem to be stuck a bit in a local maximum of expressiveness that, to many including myself, seems obviously not expressive enough.

What if ... the idea of a programmable programming language is actually good, but the implementations have not been as useful as we thought?

I think what is missing is a good meta-model and a good "language library", for want of a better term.

With most programmable programming languages, you are basically given the "it can do everything, now have fun" treatment. So everyone has some fun, implements "their own, incompatible versions of common utilities" then realises this isn't quite as useful as it was thought to be and gives up.

Going back to OO, I would claim that most OO "languages" by themselves are somewhat useless. What makes them incredibly useful is their class libraries. It is of course the languages that make these class libraries possible, but that's a second-order effect.

In fact, Smalltalkers have the saying "Talk small, but carry a big class library" (repurposing "speak softly and carry a big stick, you will go far.").

For me, the most useful meta-model is the analysis of software into components, connectors and styles that the software architecture people came up with. It appears to capture most of the variations in how we build software and has a useful, empirically built taxonomy.

In this meta-model, the connectors pretty much define styles, so the "language library" I mentioned above becomes a "connector library" in actual usable artefacts. Interestingly, existing languages seem to be describable as a set of connectors, and the connectors are very much related, so this does seem to solve the problem of lack of guidance.

This makes sense, the latest C++ standard for example makes C++ a great language, but without a great standard library built on top (the current STL is quite clunky) C++ is much more inconvenient to use than Python for example.

As cageface notes - it's not that we can't "just use Lisp" - it's that the metaprogramming leverage added by those systems isn't the form of leverage that helps with shipping. You can achieve "good-enough" metaprogramming with an external code generator and customized checks in the build process. The lasting power of the C preprocessor and its crude lexical macros is a testament to how far you get with this "worse is better" level expressiveness.

What production teams focus on instead tends to be the meat and potatoes aspects of libraries, documentation, build time, and debug time. A new user of Rust who writes C-like code can still benefit; they'll have to learn some things while fighting the borrow checker, and they may not have exactly the libraries they need(which can often be the showstopper) but their debug time will go down and their builds are likely to get simpler, if not faster.

It is true that we could use more syntax that explicitly deals with concurrency, but that's also the thing that we have little agreement on.

What good meta programming gives you is that a lot of language features can become library features. A good example of be Julia’s differential equation support or its XLA support. A language like Swift needs to modify its compiler to do similar things.

This is often not a good thing. You now have to version the library separately from the language itself and deal with dependency issues. Also you get competing and incompatible implementations of things everyone needs. This is exactly why people bag on JS for needing 600 node modules to build anything.

Having to handle library versions and long library dependencies isn't a result of a programmable language, it's the result of having better tools for sharing and integrating code without having to reinvent and maintain independently everything for every tool, and that's generally a good thing (even if it has extra steps to solve over having everything imaginable already in the base language).

And incompatible implementations are not really exclusive to metaprogramming either. Pytorch, Tensorflow, Numpy and the Python standard libraries are not compatible by default, each has to deliberately create (or not) tools to convert from one type to the other (or build entirely on top of the other).

You can argue about the Lisp Curse, in which having a lower entry barrier to make your own tool makes it easier for each create it's own "perfect" one (which is flawed/lacking to everyone else), while languages in which the sunk cost is higher would make people gravitate towards something already created and improve it with their own use case. That's definitely true, but since that's something cultural then it can probably be handled in some way (for example deciding global common interfaces for interoperability, blessed packages for each domain and the most popular extensions of the language being promoted as official language feature after enough deliberation).

There is some active research in academia and there is also the factor that veteran programmers almost all develop an itch they would love to scratch. Text editors, programming language, debuggers, terminals...

I know that if I had a few more hours a day I would try to write yet another of these things.

(Where is my cross-platform, OSX-Linux-Windows one-file text editor that just has smart indent and syntax highlighting for python?)

> (Where is my cross-platform, OSX-Linux-Windows one-file text editor that just has smart indent and syntax highlighting for python?)

I know people are gonna protest this suggestion vociferously, but Emacs ticks all these boxes (except that it works for multiple files), with almost no configuration. Admittedly, getting auto-completion to work cross-platform for various languages is still quite tricky.

By one-file, I mean one executable file. Also, emacs does not have the defaults most people expect since the 90s.

>> (Where is my cross-platform, OSX-Linux-Windows one-file text editor that just has smart indent and syntax highlighting for python?)

Just use vim? I mean, if the complexity of the projects you work with require access to a single file you might as well use _any_ editor that supports automated syntax highlights.

This got me started on my own editor. https://news.ycombinator.com/item?id=14046446

Sublime Text 3? I don’t think it’s quite “one-file” but it gets pretty close.

PyCharm.

This is what I am using for dev. Does not qualify as a light one-file app.

> I'd wager the true next generation programming languages will be ultra minimalistic languages, retaining only the essentials while not losing on legibility.

This is a fashionable idea, but I don't like it. Minimalistic languages rely on encodings, which are always far more expensive than using native features. Minimalism is fine in theoretical/academic settings -- fewer proofs to worry about -- but it's not great when performance matters.

Each time I come back to C# I find more and more 'decorations' etc. that qualify behaviour of code in one way or another, and it's getting to the point that I feel I need a reference book on the desk as I try to parse some source. These features might make the language more powerful for experts, but they make it much more difficult for devs that have to drop in and out.

If you have a minimalistic language you have a similar problem. Instead of learning language features you will need to learn libraries. You cannot run away from complexity. The advantage of the language features of libraries will always be cost.

> will need to learn libraries

which is easier for me personally, because the calls to the libraries are generally very much in keeping with the core language syntax, whereas the decorations can be very much a framework specific deviation. I can generally easily identify calls to libraries, whereas I cannot guess easily at the consequence of a particular decoration I have never encountered before.

Check out John Shutt's Kernel lisp, it uses some clever constructs to reduce the number of special forms needed, and also supports delimited continuations