HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
48% Positive
Analyzed from 1648 words in the discussion.
Trending Topics
#language#apl#dijkstra#interface#code#programming#more#learn#few#https
Discussion (32 Comments)Read Original on HackerNews
Is this a horrible sideswipe or do people think it was intended frankly?
Due to my affinity for the language, and my wish to have worked in its heyday (would love to have an APL gig someday), I have been exposed to various writings and recordings of Ken Iverson. I've also been exposed to a few of Dijkstra's thoughts on APL.
I have to say that Iverson generally comes across as a very generous and curious individual while Dijkstra seems to have been a miserable ass. Maybe, given the lens, I've not given Dijkstra a proper chance to demonstrate a more positive attitude, so I'm open to any suggestions of writings where he doesn't seem like such a grump.
Kinda hard to find where Dijkstra praised something (except Algol 60).
One funny example: he called FORTRAN "an infantile disorder", though he said this about the team behind it: "At that time this was a project of great temerity and the people responsible for it deserve our great admiration.".
On LISP: "LISP has jokingly been described as 'the most intelligent way to misuse a computer'. I think that description is a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts."
Alan Kay on Dijkstra: "Arrogance in computer science is measured in nano-dijkstras."
Hamilton Richards, who was one of Dijkstra's colleagues at the University of Texas, told me in an email that Dijkstra was impressed by the work of Richard Bird on functional programming.
* 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.
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.
I really enjoyed it because it was fun. You could do an incredible amount of work in a single line of code.
The only problem was, that line would then be almost impossible to read and understand! It could easily be used as a "write-only" language even without a separate obfuscation step.
When I become a professional programmer right after college, I never used it again, and learned to write code that was readable above all else.
Are you aware of any APL programs written using Literate Programming?
Apparently there was at least one attempt:
Lee J. Dickey. Literate programming in APL and APLWEB. APL Quote Quad, 23(4):11–??, June 1, 1993. CODEN APLQD9. ISSN 0163-6006.
Perhaps that additional layer of documentation would help? (APL is a language I've always been fascinated by, but never had occasion to more than superficially examine)
Did he feel the language design was bad, or would having TTF fonts being able to show "rho", "iota", "grade up" have removed one or more of his objections?
What I would like to know is how he would bend Algol 60 if he had tablet with pencil that could evaluate it in real-time.
That's a pretty silly claim. Is Haskell not high-level?
https://www.cs.utexas.edu/~EWD/transcriptions/OtherDocs/Hask...
Someone happy to see Haskell used in freshman CS education is not someone who opposes high-level languages.
Before computers, we could write things only on paper, either with our hands or a typewriter. So, naturally, when computers came about, the way of thinking about programming was very text-driven, with an emphasis on what a typewriter could represent.
But then, code could be written directly with computers, opening up more typesetting possibilities thanks to keyboards not being bound anymore by the mechanical limitations of typewriters. You could add keys and combinations to your heart's desire, and they would be natively digital and unlimited.
Now, with graphics, both 2D and 3D, and a myriad or other HIDs, shouldn't we try to make another cognitive jump?
> The practical objective of linearizing the typography also led to increased uniformity and generality. It led to the present bracketed form of indexing, which removes the rank limitation on arrays imposed by use of superscripts and subscripts.
(https://www.jsoftware.com/papers/APLDesign.htm)
I think this is more true than they realized at that time. The paper describes the outer product, which in Iverson notation was written as a function with a superscript ∘ and in APL became ∘. followed by the function. In both cases only primitive functions were allowed, that is, single glyphs. However, APL's notation easily extends to any function used in an outer product, no matter how long. But Iverson notation would have you write it in the lower half of the line, which would quickly start to look bad.
The problem of course is: ``What does an algorithm look like?''
Depicting one usually directs one into flowchart territory, and interestingly efforts at that style of programming often strive for simplicity, e.g., the straight-down preference from Raptor or Drakon --- systems which do not implement that often become a visual metaphor for ``spaghetti code'':
https://blueprintsfromhell.tumblr.com/
https://scriptsofanotherdimension.tumblr.com/
As a person who uses: https://www.blockscad3d.com/editor/ and https://github.com/derkork/openscad-graph-editor a fair bit, and needs to get Ryven up-and-running again (or to fix the OpenSCAD layer in his current project or try https://www.nodebox.net/ again), this is something I'd really like to see someone be successful with, but the most successful exemplar would be Scratch, which I've never seen described as innovatively expressive --- I'd love to see such a tool which could make a traditional graphical application.
https://en.wikipedia.org/wiki/Fortress_(programming_language...
I think any such leap would have to be a really big one to catch on though, due to inertia. Colorforth is not exactly popular, and I can't think of any other examples.
I'm struggling to see how Roger's manipulation of the expressions without executing each line validates Dijkstra's point...
5 lines of completely inscrutable symbols follow.
If you are expecting someone to learn a completely new notational language before you can communicate a basic algorithm, you have gone wrong somewhere.
You could also similarly write down merge sort in pure lambda calculus, which is interesting as an exercise, but not especially useful as working code, or as a way to explain how merge sort works.
FORTRAN — "an infantile disorder"
COBOL — "the use of COBOL cripples the mind"
BASIC — students exposed to it are "mentally mutilated beyond hope of regeneration"
PL/I — "the fatal disease"
APL — "a mistake, carried through to perfection"
He liked his languages and programs to be easily traceable with pen & paper. He always wrote programs on the paper (and proved correctness) and only then into computer. REPL-driven development (what APL pioneered) was a foreign concept to him. He would be so appalled by LLM code generation.
I also don't love your mapping of this observation onto modern LLMs. The interface of an LLM is natural language text, along with some files written in plain text or markdown. Can it be improved? Undoubtedly! But as a baseline, it doesn't seem half bad to me. If it is so terrible, it should not be hard to propose an interface that will be significantly more productive. Can you?
That's just a taste judgement, and you can decide the interface sucks on a one of a kind item quite easily, and people often do.