Comment by boje | Hacker News Reader

Comment by boje | Hacker News Reader

APL suffers from the same apparent problems as Perl: They have friction coming from an unconventional syntax that's hard to understand without knowing the language beforehand, and when faced with competition, people went with the path of least resistance.

* Out of all people, and especially in the newer generations, it is increasingly uncommon to find someone with a desktop or even a laptop.

* Out of them, very few decide to do anything with it besides checking mail, social media, the web or play games.

* Out of them, very few decide to learn a programming language.

* Out of them, very few decide to learn anything besides Javascript or maybe Python.

* Out of them, very few decide to learn anything besides Java/C#/C++, learn algorithms, or learn tools like Vim or Emacs.

* Out of them, very few decide to learn anything besides Rust/Go/Haskell/Lisp/Scheme or even Fortran.

* Out of them, very few decide to learn a language with an alien, symbolic notation that resembles a code golfing language, and which, too, requires them to possibly learn a completely new keyboard layout to type with proificiency.

Not trying to discredit APL's contributions to functional programming and the like, but from the letter, it is pretty obvious Djkstra had little respect for friction. Not saying that he's right to dismiss it outright, though.

Now that I think about it, and I don't know if this exists yet, but APL would probably very much benefit from having a Scratch-like or Factorio-like visual editor paired with a touch interface. You would drag and drop symbols, and long-pressing a symbol would popup its definition.

You could also probably do nice things with the symbol "icon blocks" themselves, and provide them with colors or different visualizations to convey different contextual meanings.

That wouldn't help much. People who don't use these languages doesn't understand that what makes the language different isn't the syntax. There are plenty of dialects that use English words instead of symbols (check out Ivy by Ron Pike for example).

The difference is much deeper, but the best way to understand it is probably to check out an introduction (there is a lot on youtube).

I'd personally be happy to give an introduction to anyone willing to listen, but this comment field is not the place to do it.

Excel, visual "programming" lo/no code environments, and Factorio itself are all examples of this fallacy: making it easier to build complex symbolic systems doesn't help people learn how to manage that complexity; it in fact enables them to produce overtly complex systems that become hard to extend, to maintain and to debug.

That is precisely the source of my skepticism regarding the use of LLMs to code. What benefits most programmers, teams and organizations in building and manage complex systems is discipline. Disciplined work produces systems that are relatively easy to represent and reason about, and the shallow lesson people take is that easy representation is a silver bullet.

People keep falling for that trap over and over again. Understanding it deeply can provide lots of great opportunity for interesting work though.

Not APL, but an array language https://www.uiua.org/

Yes, this! Weird notation solved with essentially written word autocomplete!

It naturally trains your memory as you use it. Definitely a language of choice for getting into array languages in my opinion.

IMO, Perl's downfall was mostly Perl 6, not the language.

Plenty people wrote plenty of Perl long ago. Yeah, the whole $ business is maybe a bit unintuitive, but it's the least of the problem really. It's easy to get past it.

IMO, the first part of Perl's downfall is that it didn't evolve fast enough. It was good enough that people tried to do big things in it and then it turned out it wasn't a good idea. Perl's OO for instance is kind of a neat hack that turns into a horrible mess with large projects. Large projects also increasingly need verification and safety because the debug costs rise higher and higher, and Perl is paradoxically safer at small scales. "use strict" works great in toy scripts and is nigh useless in OO-laden large projects where "strict" does nothing to check your $this->{foo}->{bar} hash trees. Yes, solutions sort of exist but they're all adhoc and you have to plan for them, and module writers don't use them, and...

That could have been survivable with the right improvements, but:

The second part is that Perl 6 was terribly planned and took bloody ages to get anywhere. People stopped writing Perl 5 expecting Perl 6 was around the corner, so why invest too much effort when it was clear 6 was going to be incompatible even early on? And it kept not coming out, so Python quickly ate its lunch.

Reply on news.ycombinator.com