3 ms·

Add spaces around APL operators and name them. You examples become: 2 partial mod 1 minus 2 partial mod > partial 4 I guess your examples still need so

by thesz 4y ago

Add spaces around APL operators and name them. You examples become: 2 partial mod 1 minus 2 partial mod > partial 4 I guess your examples still need some framing to make them somehow passable around, for example, a definition or some kind of closure. Let's say they require no more than square brackets around them. Now your examples will look like this: [ 2 partial mod ] [ 1 minus 2 partial mod ] [ > partial 4 ] And, magically, they are not more terse than what was expressed in Joy. Not at all. Quite the opposite. One character operator is still an operator. If it does not require spaces around it most of the time, for sake of comparison between languages it should have them.

HelloNurse 4y ago
What would be useful is the definition of abstractions, breaking long chains of combinators and functions into manageable pieces, instead of playing one-liner code golf. Meaningful function names rather than superfluous parameter names. For example (adapted from Wikipedia and untested): arrayaverage =: +/ % # arrayaverage 1 2 3 i.e. defining the average as the ratio (%) between the sum (+/) and the cardinality (#) of an array, with the advantage of being able to replace this function with a better version that doesn't fail miserably for an empty array.
marcosdumay 4y ago
> One character operator is still an operator. Yet if you look at the original code and you version, the difference is perfectly clear. Programmers are not computers, so syntax is important.
- thesz 4y ago
  What I did was not even at syntax level. These are lexems that were changed, a level below syntax. When you use C, you can write "~ x" and you can also write "??- x" [1], a slightly more verbose version of the same thing. [1] https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C I did exactly the same - I changed lexical structure of language, mainitaining the syntax, most of it. Programmers, just like most other people, read words as a whole entities, quite like hierogliphics [2]. If we talk about "people are not computers" we should recognize that and allow for longer (yet atomic) lexical structure of the same language. [2] https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/ https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/
- dkersten 4y ago
  All they did was do C preprocessor style text replacement to illustrate that, semantically and syntactically, they are very similar, the only difference being that APL chose to use super terse operator symbols instead of names. Assuming that the language allows Unicode identifiers, you could just as easily define even? or whatever to have a symbolic name and the factor/joy/forth code would look almost the same as APL. Now I’m not saying that APL isn’t interesting and that it’s choices aren’t useful, just that the comparison here shows the difference in many ways is a surface level, visual one. Of course syntax does matter but we could argue all day about whether replacing everything with symbols as APL does is more or less readable, for non-trivial code, than what factor/joy/forth do (once familiar with either style).
rak1507 4y ago
Wow, if you completely change the language to make it more verbose, it becomes more verbose! Incredible.
- thesz 4y ago
  I glad you liked it. The transformation employed is used in application of Halstead metric [1] to various programming languages. [1] https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.106.8419 https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.106... APL/K and concatenative languages are not there, but Haskell is. What is fascinating is that Haskell wins by large margin because it uses implicit "apply" operation in place of space between expressions' parts. Something similar can be the case of APL and Joy/Forth as well. It appears to me that APL/K construct operations using implicit operations' stack. In case of Haskell, there would be an (infix) operation to perform something like that, much like what is discussed with the "implicit apply" in the paper above. In case of Joy, there is a stack of stacks (or list of lists).
  - rak1507 4y ago
    The link you provided doesn't seem to work for me. I don't think it's a particularly useful metric anyway, as the actual code matters a lot, not just the semantics. Also, those examples were very simple ones, and APL has a lot of handy composition features[1] that make function composition the best in any language I've tried, including Haskell. For example (+/÷≢) in APL is (liftM2 (/) (foldl1 (+)) (fromIntegral . length)) in Haskell. [1] https://aplwiki.com/wiki/Tacit_programming#Trains https://aplwiki.com/wiki/Tacit_programming#Trains
    - thesz 4y ago
      I have several questions about your APL example. Why did you use (foldl1 (+)) instead of sum? Also, (fromIntegral . length) is (genericLength) - and that means you used implicit type conversion which may add terseness and also lead to errors. After all that, your example becomes (liftM2 (/) sum genericLength). Not much longer than APL's in terms of actual symbols used. APL fails differently, I think. It may very well fail you if you try to express parsing combinators, especially when context sensitivity and/or non-determinism are important.

by thesz 4y ago

HelloNurse 4y ago

What would be useful is the definition of abstractions, breaking long chains of combinators and functions into manageable pieces, instead of playing one-liner code golf. Meaningful function names rather than superfluous parameter names. For example (adapted from Wikipedia and untested): arrayaverage =: +/ % # arrayaverage 1 2 3 i.e. defining the average as the ratio (%) between the sum (+/) and the cardinality (#) of an array, with the advantage of being able to replace this function with a better version that doesn't fail miserably for an empty array.

marcosdumay 4y ago

> One character operator is still an operator. Yet if you look at the original code and you version, the difference is perfectly clear. Programmers are not computers, so syntax is important.

thesz 4y ago
What I did was not even at syntax level. These are lexems that were changed, a level below syntax. When you use C, you can write "~ x" and you can also write "??- x" [1], a slightly more verbose version of the same thing. [1] https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C I did exactly the same - I changed lexical structure of language, mainitaining the syntax, most of it. Programmers, just like most other people, read words as a whole entities, quite like hierogliphics [2]. If we talk about "people are not computers" we should recognize that and allow for longer (yet atomic) lexical structure of the same language. [2] https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/ https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/
dkersten 4y ago
All they did was do C preprocessor style text replacement to illustrate that, semantically and syntactically, they are very similar, the only difference being that APL chose to use super terse operator symbols instead of names. Assuming that the language allows Unicode identifiers, you could just as easily define even? or whatever to have a symbolic name and the factor/joy/forth code would look almost the same as APL. Now I’m not saying that APL isn’t interesting and that it’s choices aren’t useful, just that the comparison here shows the difference in many ways is a surface level, visual one. Of course syntax does matter but we could argue all day about whether replacing everything with symbols as APL does is more or less readable, for non-trivial code, than what factor/joy/forth do (once familiar with either style).

rak1507 4y ago

Wow, if you completely change the language to make it more verbose, it becomes more verbose! Incredible.

thesz 4y ago
I glad you liked it. The transformation employed is used in application of Halstead metric [1] to various programming languages. [1] https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.106.8419 https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.106... APL/K and concatenative languages are not there, but Haskell is. What is fascinating is that Haskell wins by large margin because it uses implicit "apply" operation in place of space between expressions' parts. Something similar can be the case of APL and Joy/Forth as well. It appears to me that APL/K construct operations using implicit operations' stack. In case of Haskell, there would be an (infix) operation to perform something like that, much like what is discussed with the "implicit apply" in the paper above. In case of Joy, there is a stack of stacks (or list of lists).
- rak1507 4y ago
  The link you provided doesn't seem to work for me. I don't think it's a particularly useful metric anyway, as the actual code matters a lot, not just the semantics. Also, those examples were very simple ones, and APL has a lot of handy composition features[1] that make function composition the best in any language I've tried, including Haskell. For example (+/÷≢) in APL is (liftM2 (/) (foldl1 (+)) (fromIntegral . length)) in Haskell. [1] https://aplwiki.com/wiki/Tacit_programming#Trains https://aplwiki.com/wiki/Tacit_programming#Trains
  - thesz 4y ago
    I have several questions about your APL example. Why did you use (foldl1 (+)) instead of sum? Also, (fromIntegral . length) is (genericLength) - and that means you used implicit type conversion which may add terseness and also lead to errors. After all that, your example becomes (liftM2 (/) sum genericLength). Not much longer than APL's in terms of actual symbols used. APL fails differently, I think. It may very well fail you if you try to express parsing combinators, especially when context sensitivity and/or non-determinism are important.