Live data from Hacker News

A Personal History of APL (1982)

ed-thelen.org

21–30 of 50 posts

Re: A Personal History of APL (1982)

#21
post #20
post #14

Earlier quoted context omitted.

genuinely curious -- do you not feel the burden of being locked in with cpython, gcc/clang, rustc, ...? or do you maintain forks of those?

what do you mean by "locked in"? They all support external libraries for extra functionality and this extension mechanisms are very well thought over. The syntax can't be easily extended which I believe could be a good thing, because it encourages using common idioms instead of ad-hoc, understandable only by its author inventions. Not to mention that some form of syntax extension is present in all of your examples.

> They all support external libraries for extra functionality

this is, of course, also true for dyalog apl, just the same as any practical programming system, be it open-source or not.

Re: A Personal History of APL (1982)

#22
post #14

I find it sad that APL nowadays means Dyalog. They appear to do amazing work. Unfortunately, the license isn't open. Why would I invest time learning it only to be locked in? I wonder how much licensing plays in APL not being more popular and used in the present day. There are open variants, like GNU APL2 and J. However, GNU APL2 has none of the advancements made in the past 40 years and J is J, not APL. The notation…

genuinely curious -- do you not feel the burden of being locked in with cpython, gcc/clang, rustc, ...? or do you maintain forks of those?

I don't feel locked in by the license of those projects. They have permissive licenses. Anyone can maintain them.

I don't need to personally maintain a fork in order for the possibility to maintain one to exist.

Re: A Personal History of APL (1982)

#23

It's at least reassuring to learn from the 1952-1954 section that the phenomenon of doing things without having any clue about them easily predates the microprocessor. (btw I second the recommendation of the 1962 A Programming Language ) Edit: > The third page had an illustration that, in a few short lines, described George Dantzig's simplex algorithm simply and precisely. > That was the overwhelming, crucial experie…

> most people vastly prefer easy and DWIM over simple and precise

Most people also vastly prefer not having to work on difficult problems. Iverson was clearly trying to provide a notation that would help the (admittedly smaller) group of people who find solving difficult problems interesting and valuable.

Re: A Personal History of APL (1982)

#24
I tried J (Iverson's successor to APL) in earnest but struggled to understand what I was supposed to do when I needed data structures other than arrays. E.g. tries, trees, hash tables and so on. The majority of the out-of-the-box vocabulary is centered on arrays, so it seemed that either you convert your problem to some kind of an array representation, or go somewhere else.

Re: A Personal History of APL (1982)

#25

We had APL on our Prime minicomputer at Swarthmore when I started there in 1978.

My missive a few years ago about APL at Swarthmore in the mid-1970s:

https://news.ycombinator.com/item?id=27460887

> In the mid-seventies at Swarthmore College, we were mired in punched card Fortran programming on a single IBM 1130. ... Late one Saturday night, I made a misguided visit to the computer center while high, smelled sweat and fear, and spun to leave. Too late, a woman's voice: "Dave! I told Professor Pryor he needed you!" ... So busted! Then I heard this voice “See these square brackets? See where you initialize this index?” He was spectacularly grateful.

> One cannot overstate the rend in the universe that an APL terminal presented, catapulting me decades into the future.

Re: A Personal History of APL (1982)

#26
post #24

I tried J (Iverson's successor to APL) in earnest but struggled to understand what I was supposed to do when I needed data structures other than arrays. E.g. tries, trees, hash tables and so on. The majority of the out-of-the-box vocabulary is centered on arrays, so it seemed that either you convert your problem to some kind of an array representation, or go somewhere else.

J has primitives (like I. and i. and e. and the primitives which set up for their use) which serve some of those roles.

But, yes, approaches which use some kind of array representation are highly favored by the language (and by other languages, to varying degrees, once you understand the patterns and issues).

Re: A Personal History of APL (1982)

#27

The language is interesting, but the management ideas in this are very strange. Example: tin flippers. Items are being checked manually and miscounted. The numbers are inherently inaccurate. And he makes the point that this applies in many other situations - some where the inputs are mechanical, so "Use a machine" isn't a solution. ("Use a better machine" might be. But how would you know without being able to monitor…

Real time processes are indeed critical in some contexts. And, arguably, we should be putting more effort into some of those contexts.

For the APL family, that's often a call for code which works with external interfaces. In many potential APL environments a handful of well designed custom primitives would get you where you need to go.

But no programming language is adequate for all roles, and that includes APL. (It can still be useful for modeling / prototyping for real time work, but that's not always necessary.)

Re: A Personal History of APL (1982)

#28
J influenced the creation of Pandas by Wes McKinney.

Ah, I sometimes have the wild thought that if he had just stuck with J or APL, Python may not be where it is today in ML. Python has become the Borg.

Re: A Personal History of APL (1982)

#30

It's at least reassuring to learn from the 1952-1954 section that the phenomenon of doing things without having any clue about them easily predates the microprocessor. (btw I second the recommendation of the 1962 A Programming Language ) Edit: > The third page had an illustration that, in a few short lines, described George Dantzig's simplex algorithm simply and precisely. > That was the overwhelming, crucial experie…

> most people vastly prefer easy and DWIM over simple and precise Most people also vastly prefer not having to work on difficult problems. Iverson was clearly trying to provide a notation that would help the (admittedly smaller) group of people who find solving difficult problems interesting and valuable.

In the beginning of the computer age all problems were difficult. If not because of the problem itself then because of the limitations of the machines. It's amazing they did as much as they did with so little, your average Arduino makes the best hardware from those days look puny.
Post reply on HN