> Take a page full of intense mathematical notation or an orchestral score and translate it into either full words (i.e.: "integral" in place of the integral symbol) or one, two or three character ASCII mnemonics. You should realize that the original is far more powerful a tool for communicating thoughts, ideas and the subject at hand than a seemingly random dump of ASCII on paper.
I've heard this idea before: have a language that separates the chrome of the top-level syntax from the underlying code.^1 That is, you can have the same language use different syntaxes ^2. This would allow robomartin to have his "notation as a tool for thought", while still having another syntax that's easier to understand, for those that want it.
But, of course, this would be difficult, especially if you want to allow mixing of multiple syntaxes in the same line of code.
For this specific example, you could have aliases for APL tokens to (possibly) multiple J tokens. The reader of the code could decide how to view it.^3 The writer could write whatever he or she prefers. But this doesn't even seem to be enough here; I don't think J and APL have all the same operators; unless you can make APL operators easily by combining J ones, this won't work. Of course, that doesn't mean a newly-designed language won't work.
Also, it's hard enough to get one language adopted by people; trying to get a language with variable syntax must be significantly harder. The toolchain will be an extremely important part of language evangelism; if there's no good way for people who don't use, say, either Emacs or Vim to use this language, no one will.
Perhaps start with an even simpler J version; instead of
avg=: +/ % #
you would write ^4:
avg=: fold(+) divide list-len
Why do I think people would tolerate having multiple syntaxes for the same thing? Let's take a musical interlude here. Now, music is traditionally written on as sheet music: on a staff, with different notes to indicate length, and the vertical position on the staff to indicate pitch. However, for guitars, there's a more common way of writing it: guitar tab. This throws away information like timing, and simply says "fret X on string Y".^5 Like our J-analogue for APL, tab is much simpler; if you can play the guitar, you can understand tab in a few minutes. Staff takes much longer; weeks or months. People don't go back and forth between one or the other; generally, if you're comfortable working with sheet music, you use that if you have the choice, only choosing tab if you don't have sheet music. I don't know if someone's designed a tool to translate between sheet music and tab.
[1] Heck, even Lisp started that way, with M-expressions: https://en.wikipedia.org/wiki/M-expression . That no one used them is possibly an indication this is a bad idea.
[2] It's a fool's argument, but not technically wrong, to say we have that with different languages that compile to assembly, or to C, or scheme, or whatever. That's missing the point.
[3] This sounds like a nice Emacs mode.
[4] Yes; I'm suggesting a "simple" version include the terminology "fold". It's an implementation detail; perhaps this is better:
avg=: +-list divide list-len
[5] Note that guitar tab specifically says which string to use: since a single note can be played multiple ways on a guitar (e.g., the open A string is enharmonically the same to the fifth fret on the low E), guitar tab has information which sheet music does not. Whether this is a benefit or not is hotly debated.
"This would allow robomartin to have his "notation as a tool for thought", while still having another syntax that's easier to understand, for those that want it."
For the past 6 months I've been going to a hackerspace in Oakland every monday evening, and trying to learn how to teach programming to non-programmers. So I've been thinking about this a lot.
BTW, a friend mentioned that APL does indeed have an 'english' mode as a debugging aid. Perhaps it's indicative that people are using the more concise notation in spite of the availability of alternatives.
