6 ms·

> Myth: Perl 6 is hard to read. [[&g]] (1..100)».&f ...OK. > Myth: Perl 6 is too complicated and too hard to learn. C Chaining infix != ≠ == < <=

> Myth: Perl 6 is hard to read. [[&g]] (1..100)».&f ...OK. > Myth: Perl 6 is too complicated and too hard to learn. C Chaining infix != ≠ == < <= ≤ > >= ≥ eq ne lt le gt ge ~~ === eqv !eqv =~= ≅ (elem) (cont) (<) (>) (<=) (>=) (<+) (>+) ∈ ∉ ∋ ∌ ⊂ ⊄ ⊃ ⊅ ⊆ ⊈ ⊇ ⊉ ≼ ≽ ...OK.

benj111 7y ago
"[[&g]] (1..100)».&f" In all fairness you can construct an obtuse example for any programming language.
- tyingq 7y ago
  It's verbatim from the blog post. To be fair, the author is trying to make the point you're making.
  - raiph 7y ago
    The OP is making the point that A) it's extremely easy to read if you know the language and B) it's extremely easy to learn the language and C) it's extremely easy to think something is hard to read just because you don't know the language. Some hints: sub add ($left, $right) { $left + $right } add 1,2 # call function add as listop; yields 3 1 [&add] 2 # use function add as infix; yields 3 [+] 1,2,3 # sticks + between numbers; yields 6 [[&add]] 1,2,3 # sticks add between numbers; yields 6 1..100 # numeric range between 1 and 100 (1..100) # so postfix applies to range, not 100 » # parallelizable map passing values 1..100 . # call a method as the mapped function &f # function f gets called 100 times with # its first arg values 1..100
- cygx 7y ago
  For the record, this could also be written as (1..100).hyper.map(&f).reduce(&g) Syntactic sugar can make a mess when overused, but also improve readabiliy tremendously when used judiciously.
KirinDave 7y ago
Yeah, as the author implied: languages you don't know are hard to read. Let's just pause for a moment and reflect on how Haskell is also beat up over this, but as one twitter user recently pointed out[0], we pretend that stuff like this: concatMap :: [a] -> (a -> [b]) -> [b] is somehow less readable and "harder to learn" than common expressions in more mainstream languages where we see absolutely inscrutable equivalent constructions: SelectMany<TSource,TCollection,TResult> IEnumerable<TSource>, Func<TSource,IEnumerable<TCollection>>, Func<TSource,TCollection,TResult>) The sin of these languages is not that they're hard to read, it's that you're irritated with unicode syntax. But languages that support dense constructs will always need to appeal to symbolic artifice to not end up being totally unreadable strings of useless syllables, as above. You might argue in the Pythonic tradition that such code shouldn't be allowed to exist. But that's a bit of a lie from Python. They just want to push it up and up the library chain to where someone anointed as "sufficiently smart" eventually just has to write a dozen lines to do the same thing we could have taught everyone to do with the conveniences of notation that lean on natural language. [0]: https://twitter.com/MxLambda/status/1147150220876308480 https://twitter.com/MxLambda/status/1147150220876308480
- overgard 7y ago
  The latter looks gross, but has something the former doesnt: words and names. Even if it's verbose and ugly, I can at least puzzle it out just based on the information at hand (I can figure out that <> is similar to (), and Enumerable/Select/Func/Collection/Result are all words I can figure out). I wouldn't be able to write that expression without knowing the language, but, I can read it, even if it's gross. It's also much easier to lookup. I can google IEnumerable a lot more easily than "what is -> after ::". The haskell version on the other hand is undeniably more elegant, but if I don't know those symbols I'm ENTIRELY lost. There's nothing about :: that means anything to me if I don't look it up. Likewise -> only implies... a transform of some sort? And [a] might mean a list, or, it might mean optional, or it might mean... lots of things. To be clear, I like the haskell version better, but it is more opaque to a beginner.
  - KirinDave 7y ago
    > Even if it's verbose and ugly, I can at least puzzle it out just based on the information at hand (I can figure out that <> is similar to () But you can't make similar inferences about [] and ->? I mean... it's an arrow. People generally get what arrows imply about processes, right? Most kids are exposed to a flow chart somewhere in their lives. > Enumerable/Select/Func/Collection/Result are all words I can figure out Only because of extensive exposure to a world where that works. And I submit SOME of those words are quite sketchy. For example, what exactly is a "Select" and what on earth does "Result" mean on this? Why do we need such a special type? And what's the semantics significance of "T" vs "I"? I think you're ignoring what you know. In terms of the number of symbols at play that you'd need to know, the Haskell is more familiar because you need far fewer symbols AND fewer words AND it actually constrains the implementation much less! > There's nothing about :: that means anything to me if I don't look it up. But you can just work out what <> means? Especially given that this code could easily be in one of 3 languages that all have significantly different semantics for <>? > Likewise -> only implies... a transform of some sort? nd [a] might mean a list, or, it might mean optional, or it might mean... lots of things. That's probably a less opaque concept than "IEnumerable". > To be clear, I like the haskell version better, but it is more opaque to a beginner. This fictive beginner who doesn't know what a function is but naturally can work out what "Select", "Func" and "Enumerable" are is a very strange story to me. If you're expecting me to just accept this person exists, I'm afraid I'm going to disappoint you by saying it sounds unlikely.

benj111 7y ago

"[[&g]] (1..100)».&f" In all fairness you can construct an obtuse example for any programming language.

tyingq 7y ago
It's verbatim from the blog post. To be fair, the author is trying to make the point you're making.
- raiph 7y ago
  The OP is making the point that A) it's extremely easy to read if you know the language and B) it's extremely easy to learn the language and C) it's extremely easy to think something is hard to read just because you don't know the language. Some hints: sub add ($left, $right) { $left + $right } add 1,2 # call function add as listop; yields 3 1 [&add] 2 # use function add as infix; yields 3 [+] 1,2,3 # sticks + between numbers; yields 6 [[&add]] 1,2,3 # sticks add between numbers; yields 6 1..100 # numeric range between 1 and 100 (1..100) # so postfix applies to range, not 100 » # parallelizable map passing values 1..100 . # call a method as the mapped function &f # function f gets called 100 times with # its first arg values 1..100
cygx 7y ago
For the record, this could also be written as (1..100).hyper.map(&f).reduce(&g) Syntactic sugar can make a mess when overused, but also improve readabiliy tremendously when used judiciously.

KirinDave 7y ago

Yeah, as the author implied: languages you don't know are hard to read. Let's just pause for a moment and reflect on how Haskell is also beat up over this, but as one twitter user recently pointed out[0], we pretend that stuff like this: concatMap :: [a] -> (a -> [b]) -> [b] is somehow less readable and "harder to learn" than common expressions in more mainstream languages where we see absolutely inscrutable equivalent constructions: SelectMany<TSource,TCollection,TResult> IEnumerable<TSource>, Func<TSource,IEnumerable<TCollection>>, Func<TSource,TCollection,TResult>) The sin of these languages is not that they're hard to read, it's that you're irritated with unicode syntax. But languages that support dense constructs will always need to appeal to symbolic artifice to not end up being totally unreadable strings of useless syllables, as above. You might argue in the Pythonic tradition that such code shouldn't be allowed to exist. But that's a bit of a lie from Python. They just want to push it up and up the library chain to where someone anointed as "sufficiently smart" eventually just has to write a dozen lines to do the same thing we could have taught everyone to do with the conveniences of notation that lean on natural language. [0]: https://twitter.com/MxLambda/status/1147150220876308480 https://twitter.com/MxLambda/status/1147150220876308480

overgard 7y ago
The latter looks gross, but has something the former doesnt: words and names. Even if it's verbose and ugly, I can at least puzzle it out just based on the information at hand (I can figure out that <> is similar to (), and Enumerable/Select/Func/Collection/Result are all words I can figure out). I wouldn't be able to write that expression without knowing the language, but, I can read it, even if it's gross. It's also much easier to lookup. I can google IEnumerable a lot more easily than "what is -> after ::". The haskell version on the other hand is undeniably more elegant, but if I don't know those symbols I'm ENTIRELY lost. There's nothing about :: that means anything to me if I don't look it up. Likewise -> only implies... a transform of some sort? And [a] might mean a list, or, it might mean optional, or it might mean... lots of things. To be clear, I like the haskell version better, but it is more opaque to a beginner.
- KirinDave 7y ago
  > Even if it's verbose and ugly, I can at least puzzle it out just based on the information at hand (I can figure out that <> is similar to () But you can't make similar inferences about [] and ->? I mean... it's an arrow. People generally get what arrows imply about processes, right? Most kids are exposed to a flow chart somewhere in their lives. > Enumerable/Select/Func/Collection/Result are all words I can figure out Only because of extensive exposure to a world where that works. And I submit SOME of those words are quite sketchy. For example, what exactly is a "Select" and what on earth does "Result" mean on this? Why do we need such a special type? And what's the semantics significance of "T" vs "I"? I think you're ignoring what you know. In terms of the number of symbols at play that you'd need to know, the Haskell is more familiar because you need far fewer symbols AND fewer words AND it actually constrains the implementation much less! > There's nothing about :: that means anything to me if I don't look it up. But you can just work out what <> means? Especially given that this code could easily be in one of 3 languages that all have significantly different semantics for <>? > Likewise -> only implies... a transform of some sort? nd [a] might mean a list, or, it might mean optional, or it might mean... lots of things. That's probably a less opaque concept than "IEnumerable". > To be clear, I like the haskell version better, but it is more opaque to a beginner. This fictive beginner who doesn't know what a function is but naturally can work out what "Select", "Func" and "Enumerable" are is a very strange story to me. If you're expecting me to just accept this person exists, I'm afraid I'm going to disappoint you by saying it sounds unlikely.