4 ms·

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

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.
  - overgard 7y ago
    > But you can't make similar inferences about [] and ->? Words are WAY less ambiguous. -> means pointer dereference, or function call, or an associative mapping in other languages I know. [] is often an indexer, or an indication of a fixed allocation, or an indicator in documentation that a value is optional... Both of those symbols have very overloaded meanings. > For example, what exactly is a "Select" and what on earth does "Result" mean on this? I mean, Result is pretty straightforward. Especially in the context of "Func" which is already there. Select is a common phrase used in, well, english, but also sql, smalltalk, C#, ruby ... and a bunch of others. If I know any of those it's a pretty big hint. It's also a common word for anyone that uses computers. If I say "select a group of files" you know that I mean, grab some files based on some criteria. If I tell you to concat map a group of files, you would probably have no idea what the hell I'm talking about. > But you can just work out what <> means? It's roughly the same shape as () and [] and I already know it from html. > That's probably a less opaque concept than "IEnumerable". Subjective really. Enumerable means a thing that can be numbered. That's pretty unambiguous. [a] in unix docs often means "optional". Or it's an indexer. Or it's.. it's used in a lot of different ways. > 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 creature to me. To most programmers, a function looks like: f(a,b,c) The alternative: a -> b -> c Is REALLY unfamiliar to most programmers that have never been exposed to a functional language like haskell or F# (which is to say, most programmers). Select and enumerable are commonly used vocabulary (well, maybe the former more than the latter, but enumerable is an easy word to lookup). Func is a very common abbrev. I've read some intro to haskell docs, and even I don't remember what :: means. There's nothing implicitly about :: that means anything at all. In C++ it's a namespace separator. In other languages it apparently just gets used because a single ":" just doesn't quite get the point across well enough.

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.
- overgard 7y ago
  > But you can't make similar inferences about [] and ->? Words are WAY less ambiguous. -> means pointer dereference, or function call, or an associative mapping in other languages I know. [] is often an indexer, or an indication of a fixed allocation, or an indicator in documentation that a value is optional... Both of those symbols have very overloaded meanings. > For example, what exactly is a "Select" and what on earth does "Result" mean on this? I mean, Result is pretty straightforward. Especially in the context of "Func" which is already there. Select is a common phrase used in, well, english, but also sql, smalltalk, C#, ruby ... and a bunch of others. If I know any of those it's a pretty big hint. It's also a common word for anyone that uses computers. If I say "select a group of files" you know that I mean, grab some files based on some criteria. If I tell you to concat map a group of files, you would probably have no idea what the hell I'm talking about. > But you can just work out what <> means? It's roughly the same shape as () and [] and I already know it from html. > That's probably a less opaque concept than "IEnumerable". Subjective really. Enumerable means a thing that can be numbered. That's pretty unambiguous. [a] in unix docs often means "optional". Or it's an indexer. Or it's.. it's used in a lot of different ways. > 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 creature to me. To most programmers, a function looks like: f(a,b,c) The alternative: a -> b -> c Is REALLY unfamiliar to most programmers that have never been exposed to a functional language like haskell or F# (which is to say, most programmers). Select and enumerable are commonly used vocabulary (well, maybe the former more than the latter, but enumerable is an easy word to lookup). Func is a very common abbrev. I've read some intro to haskell docs, and even I don't remember what :: means. There's nothing implicitly about :: that means anything at all. In C++ it's a namespace separator. In other languages it apparently just gets used because a single ":" just doesn't quite get the point across well enough.