4 ms·

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 info

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.
  - KirinDave 7y ago
    > 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 roughly the same shape as () and [] and I already know it from html. The entire point of this is that folks who are educated in a language forget how much they had to learn to render a piece of code obvious, instead appealing to "simplicity" and imaginary beginners. I think these quotes demonstrate that's how you're thinking here too.
antidesitter 7y ago
> I can google IEnumerable a lot more easily than "what is -> after ::" That's not really a fair comparison. You're comparing an identifier in one language with the basic syntax of the other. The correct comparison would be whether : {} <> [] , ++ ; & * and other syntax structures of the C-like counterpart are more easily searchable or understandable than those of Haskell, which I don't think is the case.

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.
- KirinDave 7y ago
  > 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 roughly the same shape as () and [] and I already know it from html. The entire point of this is that folks who are educated in a language forget how much they had to learn to render a piece of code obvious, instead appealing to "simplicity" and imaginary beginners. I think these quotes demonstrate that's how you're thinking here too.

antidesitter 7y ago

> I can google IEnumerable a lot more easily than "what is -> after ::" That's not really a fair comparison. You're comparing an identifier in one language with the basic syntax of the other. The correct comparison would be whether : {} <> [] , ++ ; & * and other syntax structures of the C-like counterpart are more easily searchable or understandable than those of Haskell, which I don't think is the case.