Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

APL deserves its renaissance too

wordsandbuttons.online

Post reply on HN
Print view View original

51–60 of 123 posts

Re: APL deserves its renaissance too

#51

Post by eigenspace »

qop wrote: post #33
untangle wrote: post #27

Earlier quoted context omitted.

Remember the Palm Pilot? Drawing the ASCII-ish symbols in the little box? While I did memorize the strokes, I never found the process efficient. I don't think that drawing APL runes would be any better -- certainly not better than the key-combos of Dyalog's bespoke APL editor (free for personal use, BTW).

Wow, actually I do remember that, and it sucked! So, I've never written apl, and I'm glad I read this comment because that's an excellent point you raise. To expand a bit, I was thinking about being able to notate computation graphically. That's really what I want. Visual programming has existed and has sucked forever, but those thoughts don't go away that there might be a way to do it, if I just had the missing piec…

To be fair, ownning an iPad Pro, I can say first hand that the handwriting recognition possible with the stylus is actually quite remarkable and a great improvement from the old palm-pilot days.

Re: APL deserves its renaissance too

#52

Post by riskneutral »

keithnz wrote: post #50

J seems to have its fans ( http://www.jsoftware.com/ and https://en.wikipedia.org/wiki/J_%28programming_language%29 ) and uses ascii instead of all the different symbols. Some of the code CAN be quite terse (and cryptic) like quicksort=: (($:@( #[)) ({~ ?@#)) ^: (1 I spent a small amount of time learning the basics a while ago, but never really used it for anything. But it was interesting and I'd have to spend a lot…

> quicksort=: (($:@(#[)) ({~ ?@#)) ^: (1Please, no. Glyphs / characters are not a scarce or constrained resource in software development. The major resource constraint is developer time spent writing, reading and debugging code. APL (and its descendants) are specifically designed to make these challenges far more difficult than they need to be.

Re: APL deserves its renaissance too

#53

Post by repsilat »

enord wrote: post #42
untangle wrote: post #22

Neat little tribute article. APL will not be reborn. If that was going to happen, this century's embrace of analytics and linear-algebra-rich machine learning would have propelled the upswell. It didn't and it won't. Why? It's not the symbols. Not the keyboard. Nor the learning curve. Nor the lack of standardization, libraries, or GPU support. These are collateral damage, not primary drivers. APL will not flourish be…

I like your take, and Haskell is an apt comparison in this sense. Another sense in which i think APL is... un-competitive is that its strengths (terse, mathematical, matrix-centered) are the easy parts of programming, i.e. the parts that are the most objectively quantifiable and verifiable (you just use math). Accounting for numbers is trivial, accounting for human factors is a proverb.

I agree that Haskell is a good comparison. I think matrices and math are too closely focused on in array languages (and dismissals of array languages), though.

For fun I'm writing a "spreadsheet programming language" that borrows a little from array languages, and I think there's useful stuff to take away from them.

They make you focus on the data, and the transformations you want to effect on the data.

They make you think, "where there's one, there's probably many."

The implicit mapping over arrays for most functions and operators is a massive ergonomic win over "a formula for each row" in the spreadsheet model. (Excel "array formulas" but not shit.)

Some of the simple little abstractions are beautiful. Seriously, as someone who didn't know anything about array languages three weeks ago, I say go spend a day reading the first two parts of the J book (http://www.jsoftware.com/help/learning/contents.htm) up to "Rank". It's this humble little operator that makes the whole language sing and fit together masterfully, and I'm heartbroken my language's data model (and programming style) isn't a good fit for it.

Really, though, for me being able to have my (still hypothetical) non-programmer users type

  organisations[users.orgId]
instead of

  users.map(({ orgId }) => organisations[orgId])
is a no-brainer. Ditto just about any place I might want to use an anonymous function in JS, really:

  sort(people, by: people.age)
vs

  sort(people, ({ age }) => age)
So simple. Pass an array of things to use as the sort key, not "a function to call on each item-to-sort".

Forget the cryptic syntax, "operator ambivalence" and math/matrix-focus, there's a lot of useful stuff in there that should be better known in language circles.

As for the grandparent's complaint of being "nearly-pure functional", that's the zeitgeist now -- functional transformation of data, with big ugly explicit data-replacement as the mutation story. That's not an impediment to use, it's an encouragement to use responsibly while not being too much of an encumbrance if you want to walk off the beaten track.

Re: APL deserves its renaissance too

#54

Post by keithnz »

riskneutral wrote: post #52
keithnz wrote: post #50

J seems to have its fans ( http://www.jsoftware.com/ and https://en.wikipedia.org/wiki/J_%28programming_language%29 ) and uses ascii instead of all the different symbols. Some of the code CAN be quite terse (and cryptic) like quicksort=: (($:@( #[)) ({~ ?@#)) ^: (1 I spent a small amount of time learning the basics a while ago, but never really used it for anything. But it was interesting and I'd have to spend a lot…

> quicksort=: (($:@( #[)) ({~ ?@#)) ^: (1 Please, no. Glyphs / characters are not a scarce or constrained resource in software development. The major resource constraint is developer time spent writing, reading and debugging code. APL (and its descendants) are specifically designed to make these challenges far more difficult than they need to be.

I think it's worth suspending judgement and opinions about what you think a programming language should be and evaluate it on its own terms. The preceding is a terse form of the code, you can write it more verbosely. But just like regex, terse forms can be very useful once you understand them.

Re: APL deserves its renaissance too

#55

Post by wwweston »

keithnz wrote: post #54
riskneutral wrote: post #52

Earlier quoted context omitted.

> quicksort=: (($:@( #[)) ({~ ?@#)) ^: (1 Please, no. Glyphs / characters are not a scarce or constrained resource in software development. The major resource constraint is developer time spent writing, reading and debugging code. APL (and its descendants) are specifically designed to make these challenges far more difficult than they need to be.

I think it's worth suspending judgement and opinions about what you think a programming language should be and evaluate it on its own terms. The preceding is a terse form of the code, you can write it more verbosely. But just like regex, terse forms can be very useful once you understand them.

I could also see either the existing chain of ascii glyphs becoming more legible with some wisely-chosen syntax highlighting, or an editing environment where the ascii glyphs are used to produce something distinctive, and that might change how developers relate to the symbols.

Re: APL deserves its renaissance too

#56

Post by cowile2 »

rebootthesystem wrote: post #14

No, it does not. I used APL professioally for about ten years back in the 80's. I love the language. It is incredibly powerful. Once you internalize it's like playing the piano, you don't think about the mechanics you play music. However, the language did not stand the test of time for far more important issues than the inconvenience of the character set and the keyboard. And, no, J is not a successor to APL, even th…

> Finding qualified programmers and having access to libraries so you don't reinvent the wheel.

Lots of niche languages have the same problem, notably lisp, but it doesn't do to say they aren't popular for those reasons. It's circular reasoning. Languages get those things by being popular. They get popular by having those things.

Every current "popular" language with good libraries and a large userbase started with no popularity, no libraries, and no users. They built these things over time.

The problem is these languages can't create a robust community. They are powerful, so people don't need large teams to do what they want. They are different, so it is a bigger investment to understand them. The combination means they attract the kind of elitists who are not willing to help newcomers or write basic libraries, the kind of people who are perfectly capable of reinventing every wheel and doing it better than last time.

No one teaches these languages. How popular could they get if companies and universities spent millions of hours collectively drilling even the most marginal programmer on how to use them like they do for C++ and Java?

They would never do it though. Large companies don't want more powerful languages. They will take the productivity loss for fungible employees. It's part ego. Middle managers look much more important if they have 20 programmers write 1,000,000 lines of code over 5 years than two programmers write 10,000 over six months even if functionality is equivalent. It's part bargaining and risk. If you only have a few programmers, the individual programmer is worth a lot more. It is also riskier to employ one because she could leave or get hit by a bus at any time.

Re: APL deserves its renaissance too

#57

Post by uryga »

qwerty456127 wrote: post #38

APL looks like the best programming language I've ever seen. I wish it could be extended with SQL and web-service mappings to input-output data conveniently and to use functions written in other languages (like C and Python) for acceleration and rapid logic prototyping.

Well, there's K, along with its flagship database KDB which lets you write SQL-like queries and, from what I've heard, integrates very nicely with the language. idk how good their FFI story is. Unfortunately, you need to pay for commercial use.

Re: APL deserves its renaissance too

#58

Post by sharpercoder »

untangle wrote: post #22

Neat little tribute article. APL will not be reborn. If that was going to happen, this century's embrace of analytics and linear-algebra-rich machine learning would have propelled the upswell. It didn't and it won't. Why? It's not the symbols. Not the keyboard. Nor the learning curve. Nor the lack of standardization, libraries, or GPU support. These are collateral damage, not primary drivers. APL will not flourish be…

If you think about it, a decent stack is composed of languages. That's currently already often true, e.g. the use of IDL languages like protobuf/flatbuffers. Some languages offer integrated idl like Kotlin (data classes). Another example is html, where the UI is described using a dsl to specify elements and CSS for layout & appearance.

This fact caused me to think: should stack also not be made of other languages? Is there a place for a completely pure functional language? I mean, Haskell is nice, but get a bit awkward with I/O. Same for APL. C# has nicely integrated data querying, but from a distance is actually at least somewhat awkward. C# seems to be optimized for mutable domain objects; everything else can be nicely done but falls somewhat outside it's "identity".

I would love to be able to express functions, functors and math using a terse math-y language. Whether that be APL or some sort of blend of Haskell and APL (Haspell? spelling pun intended), I don't care, but it would be great if we can have nice integrations of these languages in a full stack. Sort-of like how TypeScript and JavaScript have dialects to enable React syntax to express HTML within it.

The same thought experiment can be applied to SQL. Can we have a data-querying language integrated right into, say, C# or Java?

Re: APL deserves its renaissance too

#60

Post by b2gills »

FractalLP wrote: post #31
bstamour wrote: post #18

Earlier quoted context omitted.

Have you looked at Perl 6? It's optionally typed, and can be nearly as terse as apl with some of it's higher order operators.

You'd have to essentially embed a slow unoptimized APL in it which you can do. Add that to the fact that P6 is already slow at the moment would be an issue. Also, unlike APL, your P6 APL operators would probably be only known to you. It would definitely work though.

Unicode has APL characters, so create the operators using them.

If there is a conflict with an existing feature you could always create a Slang. A Slang is a module that changes the parser. (It could be argued that with this feature all programming languages are a subset of Perl 6)

Post reply on HN