Live data from Hacker News

Why APL Is Still Cool

infoq.com

31–37 of 37 posts

Re: Why APL Is Still Cool

#31
post #28

Earlier quoted context omitted.

I have a fork because I sent several pull requests back, before I got commit rights to the main repo (kevinlawler's).

I meant fork(2). Maybe edit the source to optionally use execve?

Oh, right. execve replaces the existing process with the invoked one, so I'm not sure that use case makes sense. Usually execve is used with fork, too.

If you're concerned with Windows portability, mmap(2) is a bigger problem. Otherwise, not sure why you're asking...?

Re: Why APL Is Still Cool

#32
post #29

Earlier quoted context omitted.

With all due respect to Mr. Iverson, whom I had the pleasure of meeting at an international APL conference many moons ago, I think J went in the wrong direction. Part of the power of APL is in the symbolic representation of concepts. The symbols are important. They form a language in more than one sense. Replacing them with ASCII/unicode equivalents rips the guts out of the language. Here's a thought experiment: Take…

Replacing them with ASCII/unicode equivalents rips the guts out of the language. … What have you accomplished? Well, at the very least you've ruined the superbly expressive nature of mathematics through agreed upon special symbols. I really don't think the small number of keystrokes is what makes this sort of language expressive. Cryptic notation is a cost, not a bonus. Moving from, say, J to C, having to write log(……

Indeed, the brevity that comes from a glyph-oriented syntax is orthogonal to that which comes from having array-oriented semantics (e.g., making loops implicit). You could have a word-based syntax, and still have very concise code.

q uses words for its single-argument operators, using "til 10" rather than "!10". It certainly makes a better first impression, but I'm not convinced it matters after a few days. My experience as an enthusiastic k novice is that I recognize idioms from symbols (e.g. "{x@<x}" more directly than I do in words ("fun x at grade-up x end"). Perhaps it's like reading poetry in Kanji, rather than letters?

Re: Why APL Is Still Cool

#33

Everyone should read "Notation as a Tool of Thought" by Iverson: http://www.jdl.ac.cn/turing/pdf/p444-iverson.pdf APL was originally designed as a uniform mathematical notation. It was only implemented as a programming language some time later. I don't think classic APL has a future, but there are ideas there worth learning.

Strongly reminiscent of Lisp. Wishful ideas brought to reality.

I think we need more of this. Crazy niche languages that are unafraid and unashamed of to be ambitious and novel in paradigm.

We have plenty of choices for minor syntax tweaks or extensions of OO and ML. We need to get brave again.

Re: Why APL Is Still Cool

#34
post #28

Earlier quoted context omitted.

I meant fork(2). Maybe edit the source to optionally use execve?

Oh, right. execve replaces the existing process with the invoked one, so I'm not sure that use case makes sense. Usually execve is used with fork, too. If you're concerned with Windows portability, mmap(2) is a bigger problem. Otherwise, not sure why you're asking...?

Sometimes I don't want to fork, e.g., if there's nothing waiting for input, e.g., the last program in a pipe.

prog |prog |exec prog

The usual way to do this is to put it in a shell script, then run the shell script. Though it would be nice in some instances, you can't run exec from a shell prompt or you'll exit the shell. I was thinking that if I'm in the kona console, executed from a parent shell, then I could type exec from the console and run programs without forking, because it's not going to cause kona to exit. Wishful thinking.

To stop forking, you would have to add an option to call execve() instead of system() in the kona source.

Re: Why APL Is Still Cool

#35

I may be being a bit stupid here, but how do you advance the slides on that link? I've never been able to figure out how to use InfoQ presentations. I must be doing something wrong...

I don't know if there's a way to advance them manually, but they are in sync with the video. You should able to read them seeking through the timeline.

Re: Why APL Is Still Cool

#36
post #34

Earlier quoted context omitted.

Oh, right. execve replaces the existing process with the invoked one, so I'm not sure that use case makes sense. Usually execve is used with fork, too. If you're concerned with Windows portability, mmap(2) is a bigger problem. Otherwise, not sure why you're asking...?

Sometimes I don't want to fork, e.g., if there's nothing waiting for input, e.g., the last program in a pipe. prog |prog |exec prog The usual way to do this is to put it in a shell script, then run the shell script. Though it would be nice in some instances, you can't run exec from a shell prompt or you'll exit the shell. I was thinking that if I'm in the kona console, executed from a parent shell, then I could type…

Oh. That wouldn't need much changed to work. I probably won't get to it for a while, but a patch/pull request would be welcome.

Re: Why APL Is Still Cool

#37
post #21
post #7

Earlier quoted context omitted.

Morgan Stanley used a variant of APL called A+. It was used quite extensively in parts of the firm. They open-sourced it a while back. http://www.aplusdev.org/

I don't remember details, but my colleagues at Merrill Lynch used to say you could look at somebody's APL code and tell if they came from Sharp (Toronto), IBM (Yorktown Heights or San Jose CA), STSC or Morgan Stanley. In APL2, the equivalent to a lisp map was "each", it was a colon rotated to be horizontal and superscript. We used to have "each" contests, I always got destroyed. And one of my (distant) friends got a…

What was the difference between code from Sharp, IBM, STSC and MS?
Post reply on HN