I had a play around with Logo the other day. In the end I decided to dive too deeply into it, but I came away thinking that there is basically nothing wrong with the language. It was invented in 1967. 1965! Yet it has everything "there". I think there's even a university professor who teaches Logo to undergraduates, too, claiming it is much better than Pascal.<p>Pascal. That could be used as a systems programming language. Maybe it's not perfect - C++ wins when it comes to resource management - but that doesn't mean it's unfixable. Just fix the bits you don't like. Sorted.<p>I could go on: Dylan, Ada, even Basic. They all "work". We've been inventing language after language after language, and yet all the key ideas were already there.<p>Now, it's true, many are lacking the kinds of libraries we want. And most of these languages don't receive the love they need to smooth over the rough edges that have programmers reaching for the more popular languages.<p>Let us now consider programming languages that can be programmed graphically. These kinds of tools get announced with great hype, only to be ignored when everyone realises that it's more fuss that it's worth.<p>And yet, it's maybe not a complete wash. NodeRed looked practical, and Scratch seemed to have a place. In principle, the whole idea that a program can be viewed as a schematic has appeal.<p>Then there's the "MX" tool for STM32 MCUs (microcontrollers). It can used to configure the pins and peripherals of your MCU. I hated it at first, but now I'm seeing its advantage at simplifying configuration, even if it does spew out a ton of stuff.<p>One thing about MX is that it "understands" the chip, so it knows about conflicts of pins and the limitations of the chip. The key thing here is that it's a metatool, a kind of Domain Specific "Language" (although it's actually graphical). It can achieve something that general-purpose languages can't. There's no magic here, of course, the MX only understands the chips because it has been programmed to.<p>MX is completely useless for making things like database applications, for example.<p>So DSLs /can/ work - maybe - but they tend to suffer from the same problems as graphical programming tools. They are also niche products, so they don't tend to get much interest. They also tend to suffer from the problem of "walled gardens" - whereby anticipated things are trivial, but unanticipated things are impossible.<p>One of my own ideas is a kind of "compilation language". It would be a language, possibly a subset of a larger language, in which you could give developers something that "understands" their problem domain. I'm thinking something along the lines of C++'s notion of "constexpr all the things". Perhaps we could push this idea so far that we could build a set of libraries that the compiler itself executes and can validate other developer code.