Paul Graham's Keynote at Pycon 2003: The Hundred-Year Language

Those are 1/100th or less of the type of code people write everyday, in startups, enterprise, cloud apps, even regular desktop and mobile apps...

>When I think Java, what comes to my mind is something like LibreOffice.

That's written in C++

> When I think Java, what comes to my mind is something like LibreOffice.

You should probably revise that thinking, since it is not written (at least in substantial ways) in Java. Moreover, desktop applications are probably not really the main use case for it (or any language other than web technologies) these days.

Java running on server processes or any long-lived computation sits in the top tier of performance. Not as fast as C/C++ but in the same ball-park.

Real time requires predictability, something that was solved in GCs by mid-1990s and had workarounds (which are required in C/C++ as well, and widely used by games etc.) by 1980s - when real-time GC'ed programs started to be used. Including hard-realtime in telephone switches.

With the advent of Learn You a Haskell, Real World Haskell, Haskell Book...etc, I really feel it is a lot more popular now, but I don't have your experience to draw upon so maybe it is just cognitive dissonance on my part.

I doubt Paul Graham was into the theoretical programming scene in that era. He might have been aware of it, but I doubt it was as production worthy as Common Lisp and thus probably not worthy of his time.

Also, Microsoft is quite open in its support for more heterogenous programming than typical Unix environment, with significant use of "niche" programming languages in various places (including things as atypical as putting custom Prolog implementation into Windows network configuration tools, just to run a prolog program that handled said configuration)

For example LINQ in C# lets you build an AST and evaluate it at runtime for database-like languages. I think that's a good direction to go.

Also DSLs still can be written without macros, a lot of frameworks use functions and builders to define a symbolic representation to be consumed later.

Today's languages don't scale up or down very well. For example, you can't write cache-optimized algorithms in Ruby and you can't write a sleek ORM in C.

Languages like Rust and C++ try to bridge the worlds by starting out being "near the metal" and then building high-level primitives on top, and that's a good start, but even with Rust's macro system — which does allow you to write some DSL-like stuff — you're always targeting Rust syntax.

Neither is every going to let you operate in a region without type annotations, for example, even though it's more productive for the programmer when experimenting/sketching, prototyping or in some contexts like shells or game scripting.

As an example, think about how much boilerplate there is around writing tests. Even though Go has a test framework built in, and tests can be nice and small, you still end up writing a lot of this:

  func TestUppercase(t testing.T) {
    v := Uppercase("hello")
    if v != "HELLO" {
      t.Errorf("expected HELLO, got %q", v)
    }
  }

  test "Uppercase" {
    Uppercase("hello") => "HELLO"
  }

In fact, monads have better afordance on domain specific semantics, while macros usually afford specific syntaxes. That makes macro based DSLs shallow and hard to understand when compared to the monad ones.