Hacker News Reader

Comment by mschaef | Hacker News Reader

Whatever trouble Lisp had from its parenthesis heavy prefix syntax will be dwarfed by the comprehensibility issues presented by this:

    { ⊃ ⍵ ⊇⍨ ↑⍒≢¨ ⍵ /⍨ 2≥ (⊂"aeiou") (+/∊⍨)¨ ⍵ } io:read "dict.txt"

I get that there's a very coherent intellectual framework to this, and it's possible to get used to it... but most people don't do that.

This is particularly true when the alternative is Excel, which was widely accessible before it was taught in schools, and is now taught in schools too.

(This language comes from a history where it used to be necessary to by special typewriter balls to print the text. https://www.computerhistory.org/collections/catalog/10269647... )

View on HN

APL notation makes more sense once you get that it was developed as an better notation for expressing math. [1]

Classical Math notation is full of weird Greek symbols and absolutely incomprehensible without any training. APL is way more regular and easier to grok as well as to type on computers.

With it's small set of special symbols, regular syntax and human-friendly infix notation APL is designed be very easy to learn.

It looks utterly alien to programmers that are used to the C-style syntax based languages, yes. but your JS or C# code looks as alien if not more alien to an non-programmer as does APL to you.

I am not convinced that APL is harder to learn that JS for non-programmers. I think existing programmer struggle way more with learning APL because it requires them to unlearn certain ideas.

[1] https://dl.acm.org/doi/pdf/10.1145/358896.358899

Non-programmers can understand IF A = 42 THEN PRINT "WTF" just fine.

Only if they already speak English. When I first learned C, I didn’t know English well enough to understand what “if” or “else” meant. I learned these words in the context of programming first, and natural language second. This experience is probably the same for most of the world’s programmers.

When I was learning programming back then, those keywords could just as well have been single letters. It wouldn’t have made a difference.

Also, I went up to my printer and there is no “WTF” there. Surely, this program doesn’t work! More seriously, this just illustrates that convention and idioms are much more powerful carriers of meaning than dictionary words. Array languages rely heavily on conventions/idioms.

If you don't speak the language, then of course it won't make sense to you, but what relevance does it have to the conversation?

As for expecting "print" to go to printer, I doubt that's the default expectation of anyone under the age of ~35 at this point.

Array languages rely heavily on idiosyncratic conventions/idioms that are utterly alien to all outsiders. Hence why they don't see uptake, and that is not going to change until their proponents are going to take this seriously. This all reminds me how Lisp adherents keep saying that syntax doesn't matter, except, looking at the actual adoption of Lisp, it evidently does. You are not going to convince everyone else to learn to "hold it the right way".

> If you don't speak the language, then of course it won't make sense to you, but what relevance does it have to the conversation?

It demonstrates that your criticism of the syntax of array languages boils down to “it’s different than the things I already know” and that not using words in a programming language isn’t a meaningful barrier to most people, given that most programmers in the world overcame this obstacle with no sweat. There is a meaningful criticism to be had in the area of syntax, but this is not it IMO. One valid criticism I know of is that most array languages have a context-sensitive syntax: you need to maintain a symbol table in your head to know how to parenthesise a line of code. Fortunately, BQN fixes this issue by using a context-free grammar.

Lisp is defined by much more than syntax. I certainly see many flaws in it (starting with the cons cell), which are total deal-breakers for me and have nothing to do with syntax. I think your view that syntax is the biggest obstacle to Lisp’s popularity isn’t as evident as you claim. There are too many other, IMO bigger obstacles.

> It demonstrates that your criticism of the syntax of array languages boils down to “it’s different than the things I already know”

There's a lot of value in leveraging existing knowledge and experience. If something is different, it needs to justify the expense of overcoming that difference in terms of time and utility.

This is not just a 'tech' issue, it predates that. To pick the example of syntax, infix languages date back to at least John Backus' FORTRAN compiler in the 1950's. That team selected an infix syntax (at the cost of taking on implementation complexity) for the express purpose of aligning with what its expected user base was familiar with. In this case, it was an approximation of the infix notation universal to mathematics for centuries. Even now, infix is taught to kids as young as five or six, if not younger.

Any alternative syntax has to overcome heavily ingrained training in legacy syntax. It also has to overcome the fact that the existing legacy syntax is a more universal means of communication. The fact that something else is new, does not necessarily make it better or worth the investment. This is particularly the case when when there are many competing ways to spend time/energy the point is communicating ideas. (It strikes me as a little odd the tendency of our industry to so often pursue inventing novel languages to help improve communication.)

> Lisp is defined by much more than syntax. I certainly see many flaws in it (starting with the cons cell), which are total deal-breakers for me

This is a weird complaint, given that 1) linked data structures are almost universal in languages with pointers/references 2) all serious Lisps dating back to before Common Lisp offer alternative data structures 3) some Lisp's (Clojure comes to mind) essentially deprecate the cons cell in favor of these alternatives.

Knowledge of English is nowhere near as widespread as knowledge of infix notation. If we were to create a programming language based on words from a natural language which is most likely known by people trying to learn (i.e. most of them are in the age bracket 10-20), it would need to be Mandarin Chinese, since it’s the most popular first language. Even then it covers only 1/8 of the world population. Comparing it to infix notation is unjustified. To the rest of the population keywords in this language would at first be even less comprehensible than APL. Later they would be just as comprehensible as C is today. English is not known by most people learning programming, and yet it’s not a real problem. Even English-speaking people don’t seem to have an issue with the for loop, even though its name has nothing to do with any meaning of “for”.

But let’s now take something that is actually widespread: angular degrees. Before high school, I used only degrees at school and everywhere else. In high school I was taught about radians. Radians are a lot less used by random people than degrees. But since I learned them, as I later went through uni, then job etc, I’ve completely stopped thinking in degrees and use only radians, both professionally and in everyday life. That’s because their benefits justify the switch. So even when something is actually widespread, we can still find good reasons to switch to something that provides material benefits. I claim that the notation of array languages is beneficial enough (at least in the case of BQN).

As for Lisp:

1) Most languages offer a hash table as the default associative data structure. In Lisp culture alists are the default. Books about lisp also focus pn data structures built out of cons cells disproportionally more than any other data structures.

2) They do. But then you read actual programs available on the web and they still default to using alists. There is an impedance mismatch, if you’re more array/stack/hashtable-minded, which isn’t there in most mainstream languages. FTR I’m a big fan of SML too, but even in SML using the best data structures is very much going against the grain, when the language tries to steer you so much towards linked lists and away from arrays. I swear my SML programs look nothing like the things I find on GitHub.

> 2) They do. But then you read actual programs available on the web and they still default to using alists.

I was wondering how true this was, so I checked Planet Lisp. The first article is an admonition to use structures and classes _instead_ of alists, and it's followed by a bunch of other articles that use instances, structures, and hash tables. No a-lists to be found.

I've used Lisp (mainly Clojure, but others also) and I don't even remember the last time I used an a-list, outside of maybe Emacs Lisp. As you point out, they're a mostly dumb idea in an age where there are better data structures and memory hierarchies are multi-leveled and often packet switched.

I'll agree with you that it has been part of the Lisp culture, but that's the Lisp culture of the 70's and 80's. The language has moved on.

> When I first learned C, I didn’t know English well enough to understand what “if” or “else” meant. I learned these words in the context of programming first, and natural language second. This experience is probably the same for most of the world’s programmers.

This is the experience of learning to read music without speaking Italian. "Allegro ma non troppo" doesn't mean much in English.

> APL notation makes more sense once you get...... APL is way more regular... With it's small set of special symbols, regular syntax and human-friendly infix notation APL is designed be very easy to learn....It looks utterly alien to programmers that are used to the C-style syntax based languages, yes.

As you might guess from my original post, I'm a Lisp apologist. I like the syntax and I can make an argument for Lisp [1] that sounds a lot like the argument you make here for APL. From what you say and from what I've read, I suspect APL is another language like Lisp (and Smalltalk, Forth, and Tcl). These are all languages derive a great deal of elegance and coherence from a pure approach to syntax and design, and all are seductive in their way to people that have taken on the effort to learn how they work.

The problem is that this doesn't matter enough to overcome the incumbency bias in favor of more traditional languages.

> but your JS or C# code looks as alien if not more alien to an non-programmer as does APL to you.

It would be convenient for APL if this were true, but the reality is that it's not.

I learned Logo and Basic when I was eight. My kids learned JS/Python around the same age. This is a common experience. It's just not that hard to learn basic imperative programming in an infix language.

1] https://mschaef.com/lisp-syntax

Reply on news.ycombinator.com