Near Future of Programming Languages [pdf]

Moreover, having direct introspection of a model stored in a local notebook is still quite limited with respect to having it in the whole environment like Smalltalk or HyperCard did. There are a few systems trying to explore that "structure of the project" approach, like Leo Editor or the Smallest Federated Wiki which could be a better basis for a "Inventing on principle" tool.

That said, I didn't mean text substitution, but AST transformations (or rather, AST comparisons, since my example is defined in terms of AST equality with the MOCK magic thingie making the particular part of AST be ignored for the sake of comparison).

To me it seems we are catching up with the past, and as someone already programming on those environments, it looks we have spent 10-20 years loosing our tools, educating the masses, only to get a taste of things used to be.

I don't think that's a fair reflection of what these languages feel like. When your constraints mean that only the right thing can be done, you can make the thing implicit. The things that are tacit when humans talk about the problem can be tacit in our programming as well. You have ways to factor out concerns that are separate, even when they are entangled. "Better decomposition of the problem" doesn't sound exciting, but ultimately that's the very essence of programming. I don't think we need new grand ideas, at least if we're just talking about the next 50 years of industrial programming; I think we need to follow through on the ideas we already have, and I actually think that gradient ascent from Java will happen, and will move the industry forward, even if it ends up being a lot slower than I'd like.

> How do you even know that we can do much better? NASA engineers may not like it, but they don't complain that we're "stuck" at sub-light speeds. Maybe Brooks was right and we are close to the theoretical limit (that we know must exist).

I think we can go at least one or two substantial steps better than Idris: I want Noether's levels of stratification (beyond just total/not-provably-total), and I want Rust-style linearity, not as a specialised capability but as something integrated into the regular type system. But even if Idris is the limit, it's still a big step ahead of Java, and it's going to take the industry a while to make that step. (Maybe it will have to be two or three steps to get there - it feels like most of the industry is only just adopting the things that OCaml offered, and not yet familiar enough with them to appreciate what Haskell offers above that. And I can't blame them - I only have an appreciation of those things because I've been able to work for a long time in Scala and very gradually work my way up towards using the less familiar facilities). "The future is already here — it's just not very evenly distributed."

> Can you find another useful way, available to us today, of talking about languages?

Yeah, that's the problem :(.

The whole industry is a huge iceberg in terms of what's visible about the practice of programming versus what's actually happening. I'd like to see more programming happening in public - which I think probably means more publicly-funded programming (I was thinking about this a few days ago in the context of research and scientific code - we have a relatively good system in place for providing grants for research, but we're a lot less good at funding the infrastructure that's used for research - we end up with a lot of researchers repeating the same work because they're only ever funded for a specific project, rather than being funded to produce something that's useful for many research projects). What makes sense in an open-source webdev project is all that most of us ever see about most languages, and while it's a lot better than nothing it's still a seriously distorted picture of what most programmers are actually doing.