Some languages express the same thing with more or less concepts, and more or less explicit complexity, and that is a true difference in verbosity, but symbol-vs-word is just a superficial difference that can and should be ignored for a useful comparison.
[1] 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).
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.
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.
'Not much longer than APL's in terms of actual symbols used.' - well, there's liftM2, and for longer examples, chaining it is even worse - (f g h i j) in APL becomes liftM2 g f $ liftM2 i h j -> quickly becoming unwieldy and unclear.
A lot of people also seem to say 'oh well if each character was a word it would be the same', and while it seems like that might be true, in practice it isn't, and the use of symbols allows for pattern recognition that you just don't get with words.
[1] https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/
You used monadic interface, instead you may use applicative interface.
liftM2 then become liftA2 and what you exemplify above (if I understand that correctly) will render as (g <$> f <*> (i <$> h <*> j)). It is unusual, because "g" goes before "f", but not much unusual. Note the explicit pure function application in the use of <$> and explicit apply <*>. I would like you and other readers compare that to the implicit apply in the "Are ours smaller than theirs?" paper I provided link above.
That translation shows what APL hides in its implicits.
Let me repeat. APL will certainly help you with computations over arrays but will most probably fail you big time with parsing of something like Ada. Haskell won't fail you in both cases at the expense of slightly more verbose program text.
Tacit programming exposes the need to "normalize" programs, to express them with as less function argument rearragement as possible. In stack based languages this is guided by the dependence on the stack(s) (data, return, control, whatever you invented). In point-free programming in Haskell, this is guided by argument capture and propagation. In K (I mostly studied it), as I understand it, tacit programming is guided by the implicit operations upon the stack of actual operations.
These variants of tacit programming are mostly the same, just some cases are more easily expressible or some operations conveniently assumed to be implicit.
Yet if you look at the original code and you version, the difference is perfectly clear.
Programmers are not computers, so syntax is important.
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
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/
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).
For example (adapted from Wikipedia and untested):
arrayaverage =: +/ % #
arrayaverage 1 2 3
You examples become:
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:
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.