After learning lisp, I just feel like every other language is a weird set of macros. Looking at this AST confirms that.
Wish I could live the rest of my life in Sexp-land.
Wish I could live the rest of my life in Sexp-land.
I've come to the opinion that when sending data in or out of software, it should always preserve as much structure as possible in an easily parseable form accessible to off-the-shelf parsers; e.g. s-expressions, JSON or, if it can't be avoided, XML. Even thrown-together debugging messages. Basically I should be able to reconstruct all of the structure in basically any programming language with something like one module import and a function call (or equivalent); I shouldn't have to define my own parsing rules, no matter how simple their author thinks they are.
Not only this, but any format which, for some reason, cannot be represented in this way, e.g. programs in languages which consciously avoid s-expressoins, should pass through a layer which does convert to a structured form, and this form should be obtainable, e.g. by setting an environment variable or a commandline flag. That's why I commend this "dump AST" flag.
It's basically the opposite of the many "Lisp-on-top-of-X" approaches. Instead of being able to write s-exprs which translate to some underlying language, like Swift, I should be able to translate any Swift into s-exprs to be manipulated. Why? Because there will always be strictly less code written in a Lispy language than there will be for the underlying platform as a whole. For example, there will always be less code written in Clojure than code written for the JVM.
The benefits of s-expressions (and accessible AST structures in general) is that they can be inspected, transformed, manipulated, pulled apart, recombined, etc. This is of some use when programming, e.g. having macros manipulate our Clojure ASTs, but not a huge amount; after all, we could write our code in a different way which didn't need the macros (we could even, in principle, write it in Java!).
In contrast, being able to manipulate code which isn't ours is much more useful; since we don't have the option of writing it a different way (since we didn't write it at all!).
Whilst I agree that the visual and on-disk representations of programs are too tightly-coupled, there are many structure-based IDE experiments out there, but few see much adoption due to the immense momentum of existing infrastructure, and the subtlety of integrating nicely with things like version control.
It's a less drastic change to make existing language compilers/interpreters more modular, so that we can use them for things like parsing, type-checking, optimisation, etc. in a "standalone" way, without having to reinvent everything from scratch each time we want to do something the implementors didn't consider.
The way I see it, the fact that our programming tools operate on huge character sequences is historical accident. Rather than coming up with a particular editor, I'm trying to think of what a more 'correct' structure for representing programs in general would be, as a replacement for character sequences.
Of course this is essentially suggesting a paradigm shift, and as you say (approximately), the current paradigm has lots of momentum.
It feels like this might be closer to describing planetary orbits with the more natural ellipses rather than circles—but maybe I'm just suggesting triangles or something :)
Some of it's just habit, of course, but the lightness and simplicity also seem objective to me. It becomes hard to understand why everyone else keeps jumping through all those pointless hoops, you get ever more impatient and irritable with it all, and one day you fall prey to full smugweeniness.
IMO people prefer to communicate with some nuance and some degree of redundant expression. Terseness is itself even a kind of nuance when you're allowed to not use it.
Drives for widespread purity in language never seem to pan out, in either human<->human communication or human<->computer communication. I suspect there are reasons for this that might be somewhat under-researched.
I do agree that people often desire to make things more complicated than they need to.
That is, you seemed to be arguing that there was redundancy in my comment, similar to what I called busywork and noise in code. An interesting point, but my comment was conversation—not code—so it struck me as a non sequitur.
Your comment hints at an insight into why we make code overcomplicated. But the superfluous complexity I'm talking about rarely strikes me as nuance, i.e. valuable enhancement for humans. It's mostly boilerplate to satisfy machines. It's no accident that "Programs must be written for people to read, and only incidentally for machines to execute" is a line that came out of the Lisp mentality.
Mandarin is an outlier in that comparison - but also not popular as a second language.
English, in particular, is known for being difficult to learn--it uses phones that very rare ("th" and the English "r"), it has a bizarrely large vocabulary, and, somewhat separately, its spelling is nonsensical.
I could add a stack-based language like Factor too.