3 ms·

You can assign a name to each of those symbols if you want and have something equivalent to what you just wrote. tranpose=:⍉ take:=↑ index=:⍳ each=:¨ done,

You can assign a name to each of those symbols if you want and have something equivalent to what you just wrote. tranpose=:⍉ take:=↑ index=:⍳ each=:¨ done, now I can write (⍉↑x⍳¨x) as (transpose take x index each x) But the entire idea of APL is notation as a tool of thought. Would you write read your maths as five plus twenty is equals to twenty five or 5 + 20 = 25? Would you rather read music with it's musical notiation or quarter note at middle C, quarter note at middle E, etc? The entire idea of APL is that we read and write algorithms the way we read mathematical and musical notes.

FPGAhacker 9y ago
That’s a pretty good analogy, the 5 + 20 example. By using abstract symbols, it encourages one to skip the internal verbalization and go straight to the concept. Pretty neat. But in the article, they use symbols that I don’t have on my keyboard. I guess one would learn the combination for such symbols and become fluent to the point that it didn’t matter. For example, I don’t think of the individual letters when I’m typing. Although my highschool typing class strongly encouraged doing so. I believe that was more for maintaining a rhythm, however.
- Jtsummers 9y ago
  Earlier this year I took a deep dive into APL (something I'd been meaning to do for a while). With Dyalog APL and the APL mode in emacs, typing these things in is pretty easy and becomes natural if you're already a touch typist. For instance, iota is just `.i`, rho is `.r`, etc. Some are more natural (like that) others are arbitrary but logically consistent, like take and drop are next to each other on the keyboard. After a few days I felt like I could type most programs without having to think about where keys were. Admittedly, I've lost it all now since I haven't touched it for a couple months. If I actually stuck with it for more than the 4-6 weeks I did I imagine I wouldn't have lost it so quickly.
  - untangle 9y ago
    > APL mode in emacs, typing these things in is pretty easy...iota is just `.i`, rho is `.r`, etc. ...and iota is just `i and rho is `r in the Dyalog editor. So non-emacs folks can play too.
    - Jtsummers 9y ago
      Ah. You’re right. I had changed the prefix in Dyalog to match emacs since that’s what I’d started with.
- segmondy 9y ago
  J uses all ASCII characters so you can use a regular keyboard
dnautics 9y ago
Honestly I would much rather read it as: 5 |> Plus (20) |> Equals? (25) Why? Because when you aggressively use infix notation, there is operation order precedence ambiguity which is not there in polish (functional) notation. The pipeline idiom creates a "main line of computation" which really covers about 80% of use cases. I'd rather not have to remember so many things (I am getting old) and some notations are far clearer than others.
- isidor3 9y ago
  In APL and J at least, all operators have the same precedence, and always associate to the right, so there's never any ambiguity.
deleted 9y ago
[deleted]
evincarofautumn 9y ago
I understand that the compactness is a feature, and I don’t have any gripes with the symbolic notation personally, I just think a more verbose notation might avoid turning people off too early. By starting from familiar territory, you can get people accustomed to a new style of thinking before switching to a more compact syntax. Lots of new programming languages borrow syntax from familiar mainstream languages in order to reduce friction for beginners and experts alike. Heck, as long as we’re on the subject, I’d take a symbolic notation that used small icons or emoji as a sort of middle ground—at least then they might be more mnemonic. For instance, there’s nothing about ↑ that suggests “take” to me, or ⍉ “transpose”, but I’d have a good guess at what these icons mean, and they could remain legible at fairly small sizes: ├───┤ ┌─┬─┬─┬─┬─┬─┐ │A│A│B│B│B│B│ └─┴─┴─┴─┴─┴─┘ ┌─┬─┬─┐ ┌─┬─┐ │A│A│A│ │A│B│ ├─┼─┼─┤ ├─┼─┤ │B│B│B│ │A│B│ └─┴─┴─┘ ├─┼─┤ │A│B│ └─┴─┘ (Where A and B are different colours/shades—shade characters don’t appear to work on HN.)
kazinator 9y ago
Music notation is a form of assembly language in which the original compositional ideas are expanded and flattened out into reams of tiny instructions for a "virtual machine": an abstraction of a musical instrument. Nothing in music indicates semantic concepts like "this is motif M3 from the first movement, but transposes into a minor key, and played backward at half tempo". It's all just expanded into notes, which are like micro-instructions for the violin or oboe. The music composer, when engraving notation, rarely invents any new symbols. If so, in a modest quantity. In even small scale software engineering, the symbols unique to a given software system outnumber those in the programming language. We develop software by creating large dictionaries of new identifiers, such as functions and types. These symbols, which can number in the thousands and beyond, cannot have one character names, or there will be chaos. The main challenge is understanding a program's own identifiers, not those in the programming language. Terseness in the programming language helps at the microscopic level. The leaf terms of the program's syntax tree become more compact. The advantage of this in the overall context of making a big program is modest and has diminishing returns. Giving the core functions of a language short names, say from around two to six characters, goes a long way toward bringing about a useful level of terseness. What also helps understanding is giving meaningful names to intermediate values. A pipeline of 13 operations is hard to understand, whether their names are one-character glyphs or 4-8 character words. If it's broken into, say, three smaller pipes, the first two of which are evaluated into variables with meaningful names, it will be helpful. So that is to say, we shouldn't be cramming so many open-coded steps into a computation that they need one character names in order to fit into a reasonable space on the screen. This is the problem with APL programs and programmers: failure to decompose complex operations into small functions with clear names. I don't care that you can make some cool operation by stringing together seven letters. I am not impressed. What I don't want to see is you copy and pasting those seven letters all over the place whenever you wish to invoke this cool operation. If I will have to maintain that, I would really appreciate it if that string of seven letters appeared in one place as a definition, and had a nice ten-letter name, which is then used in all the other places where that operation is required even though (horror of horrors) it is 42% longer! And, no, do not be giving it a one-character name using some Greek or Japanese symbol not yet claimed by APL. Do you really want your maintainers to have to make flashcards of the program's identifiers and do spaced repetition night after night?

FPGAhacker 9y ago

That’s a pretty good analogy, the 5 + 20 example. By using abstract symbols, it encourages one to skip the internal verbalization and go straight to the concept. Pretty neat. But in the article, they use symbols that I don’t have on my keyboard. I guess one would learn the combination for such symbols and become fluent to the point that it didn’t matter. For example, I don’t think of the individual letters when I’m typing. Although my highschool typing class strongly encouraged doing so. I believe that was more for maintaining a rhythm, however.

Jtsummers 9y ago
Earlier this year I took a deep dive into APL (something I'd been meaning to do for a while). With Dyalog APL and the APL mode in emacs, typing these things in is pretty easy and becomes natural if you're already a touch typist. For instance, iota is just `.i`, rho is `.r`, etc. Some are more natural (like that) others are arbitrary but logically consistent, like take and drop are next to each other on the keyboard. After a few days I felt like I could type most programs without having to think about where keys were. Admittedly, I've lost it all now since I haven't touched it for a couple months. If I actually stuck with it for more than the 4-6 weeks I did I imagine I wouldn't have lost it so quickly.
- untangle 9y ago
  > APL mode in emacs, typing these things in is pretty easy...iota is just `.i`, rho is `.r`, etc. ...and iota is just `i and rho is `r in the Dyalog editor. So non-emacs folks can play too.
  - Jtsummers 9y ago
    Ah. You’re right. I had changed the prefix in Dyalog to match emacs since that’s what I’d started with.
segmondy 9y ago
J uses all ASCII characters so you can use a regular keyboard

dnautics 9y ago

Honestly I would much rather read it as: 5 |> Plus (20) |> Equals? (25) Why? Because when you aggressively use infix notation, there is operation order precedence ambiguity which is not there in polish (functional) notation. The pipeline idiom creates a "main line of computation" which really covers about 80% of use cases. I'd rather not have to remember so many things (I am getting old) and some notations are far clearer than others.

isidor3 9y ago
In APL and J at least, all operators have the same precedence, and always associate to the right, so there's never any ambiguity.

deleted 9y ago

[deleted]

evincarofautumn 9y ago

I understand that the compactness is a feature, and I don’t have any gripes with the symbolic notation personally, I just think a more verbose notation might avoid turning people off too early. By starting from familiar territory, you can get people accustomed to a new style of thinking before switching to a more compact syntax. Lots of new programming languages borrow syntax from familiar mainstream languages in order to reduce friction for beginners and experts alike. Heck, as long as we’re on the subject, I’d take a symbolic notation that used small icons or emoji as a sort of middle ground—at least then they might be more mnemonic. For instance, there’s nothing about ↑ that suggests “take” to me, or ⍉ “transpose”, but I’d have a good guess at what these icons mean, and they could remain legible at fairly small sizes: ├───┤ ┌─┬─┬─┬─┬─┬─┐ │A│A│B│B│B│B│ └─┴─┴─┴─┴─┴─┘ ┌─┬─┬─┐ ┌─┬─┐ │A│A│A│ │A│B│ ├─┼─┼─┤ ├─┼─┤ │B│B│B│ │A│B│ └─┴─┴─┘ ├─┼─┤ │A│B│ └─┴─┘ (Where A and B are different colours/shades—shade characters don’t appear to work on HN.)

kazinator 9y ago

Music notation is a form of assembly language in which the original compositional ideas are expanded and flattened out into reams of tiny instructions for a "virtual machine": an abstraction of a musical instrument. Nothing in music indicates semantic concepts like "this is motif M3 from the first movement, but transposes into a minor key, and played backward at half tempo". It's all just expanded into notes, which are like micro-instructions for the violin or oboe. The music composer, when engraving notation, rarely invents any new symbols. If so, in a modest quantity. In even small scale software engineering, the symbols unique to a given software system outnumber those in the programming language. We develop software by creating large dictionaries of new identifiers, such as functions and types. These symbols, which can number in the thousands and beyond, cannot have one character names, or there will be chaos. The main challenge is understanding a program's own identifiers, not those in the programming language. Terseness in the programming language helps at the microscopic level. The leaf terms of the program's syntax tree become more compact. The advantage of this in the overall context of making a big program is modest and has diminishing returns. Giving the core functions of a language short names, say from around two to six characters, goes a long way toward bringing about a useful level of terseness. What also helps understanding is giving meaningful names to intermediate values. A pipeline of 13 operations is hard to understand, whether their names are one-character glyphs or 4-8 character words. If it's broken into, say, three smaller pipes, the first two of which are evaluated into variables with meaningful names, it will be helpful. So that is to say, we shouldn't be cramming so many open-coded steps into a computation that they need one character names in order to fit into a reasonable space on the screen. This is the problem with APL programs and programmers: failure to decompose complex operations into small functions with clear names. I don't care that you can make some cool operation by stringing together seven letters. I am not impressed. What I don't want to see is you copy and pasting those seven letters all over the place whenever you wish to invoke this cool operation. If I will have to maintain that, I would really appreciate it if that string of seven letters appeared in one place as a definition, and had a nice ten-letter name, which is then used in all the other places where that operation is required even though (horror of horrors) it is 42% longer! And, no, do not be giving it a one-character name using some Greek or Japanese symbol not yet claimed by APL. Do you really want your maintainers to have to make flashcards of the program's identifiers and do spaced repetition night after night?