Aren't s-expressions all one really needs?
I’ve realized it’s because we are still stuck in a text-file-oriented way of writing programs. We are hand-editing the serialization format of our programs. All of these languages with complex syntax is an attempt to optimize around that use-case.
If we had better tools which allowed us to leave behind text-file-oriented programming, there would be no need for all of this complex syntax.
There would be a few other benefits as well. No one cares whether photoshop .psd files use tabs or spaces, or whether the curly brace should go at end-of-line or next-line, etc.
Why should "easy for the machine" ever be a consideration for software used by humans? Surely "easy for the human" is the metric that matters. The entire point of having computers is so that can do hard things to make our lives easier.
If rich syntax is easier for us to read and feasible for computers to parse, that's the right trade-off.
If we had better tools, we wouldn’t necessarily be limited to just one user-facing syntax for a language. The syntax could simply be a preference in the tools. My point is that as long as we are stuck in text-file-oriented thinking, no one is even thinking about these possibilities.
And yet many more people are writing C++ code. Toolability definitely matters, but the empirical observation is that a relatively small number of tools for complex languages used by a large number of people seems to provide a lot of benefit.
> My point is that as long as we are stuck in text-file-oriented thinking, no one is even thinking about these possibilities.
Thousands of people are thinking about this. I've been reading blog posts and manifestos about the death of text-based syntax literally since the 90s.
What I think most of those people overlook is that if you think programmers struggle to write text, you're really underestimating how much they would struggle to layout boxes and lines or do whatever other spatial/visual user experience you have in mind instead.
- Intentional Programming: https://en.m.wikipedia.org/wiki/Intentional_programming
- Light Table: http://lighttable.com/ (inspired by some ideas from Bret Victor: http://worrydream.com/)
- Visual Programming (lots of examples)
- Literate Programming
You can view sophisticated IDEs and refactoring tools as an attempt to improve the interface to plain text representations of code. These have actually had quite a bit of success.
Some approaches that move away from editing code as plain text have had success in particular domains. Visual Programming has shader graphs, Houdini, Unreal Blueprints, Substance Designer and other niches where it is relatively successful. Literate Programming has Jupiter notebooks and Mathematica that are popular in certain domains. Most of the success seems to come in particular niches, it's hard to think of widely adopted examples for "general" programming.
And Excel of course is a very successful non text based programming model within many domains.
Assuming natural language is the serialization format of thought (quesionable), we could have non-serial program representation when we can interface directly with thought.
\aside Chomsky reckons natural language is not primarily used for communication, but as an internal linkage between concepts and perception/action. If so, why is it serial? Is it serial? Is a grammar needed if it is not serial? Perhaps structure is all that is needed, and that does not require grammar (though fits with it, via AST).
https://github.com/ruby/ruby/blob/trunk/parse.y
https://github.com/clojure/tools.reader/blob/master/src/main...
An S-Expression parser will accept (loop for in do), and the rest of the language implementation has to deal with detecting that there is no variable, no collection and no action.
S-expressions know nothing and represent nothing about concepts like functions, variables, argument lists, operators, bindings, type declarations, function defintions, variable defintions, class definitions, ...
Even syntactic (3 4 +) is READ successfully, but it is not a valid Clojure form.
Basically a READER is on the level of a TOKENIZER, but not a parser.
(2 + 3)
(- 3 4)
All are valid s-expressions. Only one is a valid Lisp expression.
When we parse an expression, we usually parse a textual representation into an object. If the object is meant / subject to evaluation -> then we call this a form.
Every character in a S-expression must be "dealt with at the reader level" (and produced at the printer level).
The term "S-expression" was originally in contrast with "M-expression", but that's a historic usage.
One then maps a programming language to s-expressions.
You could easily map a complex infix/mixfix language to s-expressions.
This is a valid s-expression:
(foo = x ^ 3 * 4 / sin x)
You can imagine variants with more parenthesis, too.