4 ms·

> 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 ma

> 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.
  - overgard 7y ago
    My point, which you seem to be avoiding, is that words are a lot less ambiguous than symbols. EDIT for additional point: also, since your examples are haskell and C#, let me point out that reality seems to agree with me here, since C# is vastly more popular than haskell. If you're learning something, learning something with less ambiguity is usually easier. Considering that F# is similar(ish) to haskell and has the full power of the .NET platform and is still vastly less popular than C#, I think it's clear which option people think is easier. Easy may not be better, but that's a separate discussion.
    - cygx 7y ago
      It's a trade-off, though: Compactness and visual variety can help readability. There's a reason why symbolic math notation won out, and why the most regular and/or verbal languages (eg Lisp, Cobol) haven't won over everyone's hearts and minds.
    - KirinDave 7y ago
      > My point, which you seem to be avoiding, is that words are a lot less ambiguous than symbols. Sorry, I don't accept this and you haven't demonstrated it except to say "well we can use an appeal to other things for words, but not for symbols." That really dosn't fly at all, for me. > let me point out that reality seems to agree with me here, since C# is vastly more popular than haskell. If you're learning something, learning something with less ambiguity is usually easier. This isn't actually an argument. It's a hope. Besides, many of the folks in industry learned to program in other languages than the ones they use today in industry, but not languages that didn't exist at all. > Considering that F# is similar(ish) to haskell and has the full power of the .NET platform and is still vastly less popular than C#, Imagine, if you please, a world where people in industry and on Hacker News repea an untrue mantra that one language is "simpler" from first principles, confusing familiarity with simplicity? In such a world, educators would look to what the industry demands and feel that in good faith, they should give those languages some treatment in courses over time. We might also see these universities (under pressure from an increasingly competitive market for the bulk of undergrad education), start to set aside time-tested teaching languages and regretfully move to courseware that prepares people for these industry jobs. I feel like maybe my story matches reality at least as well as yours. It also explains why a simpleton like me might be able to learn these supposedly unapproachable languages like Forth, Lisp, F# and Haskell without appealing to me being a genius.

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.
- overgard 7y ago
  My point, which you seem to be avoiding, is that words are a lot less ambiguous than symbols. EDIT for additional point: also, since your examples are haskell and C#, let me point out that reality seems to agree with me here, since C# is vastly more popular than haskell. If you're learning something, learning something with less ambiguity is usually easier. Considering that F# is similar(ish) to haskell and has the full power of the .NET platform and is still vastly less popular than C#, I think it's clear which option people think is easier. Easy may not be better, but that's a separate discussion.
  - cygx 7y ago
    It's a trade-off, though: Compactness and visual variety can help readability. There's a reason why symbolic math notation won out, and why the most regular and/or verbal languages (eg Lisp, Cobol) haven't won over everyone's hearts and minds.
  - KirinDave 7y ago
    > My point, which you seem to be avoiding, is that words are a lot less ambiguous than symbols. Sorry, I don't accept this and you haven't demonstrated it except to say "well we can use an appeal to other things for words, but not for symbols." That really dosn't fly at all, for me. > let me point out that reality seems to agree with me here, since C# is vastly more popular than haskell. If you're learning something, learning something with less ambiguity is usually easier. This isn't actually an argument. It's a hope. Besides, many of the folks in industry learned to program in other languages than the ones they use today in industry, but not languages that didn't exist at all. > Considering that F# is similar(ish) to haskell and has the full power of the .NET platform and is still vastly less popular than C#, Imagine, if you please, a world where people in industry and on Hacker News repea an untrue mantra that one language is "simpler" from first principles, confusing familiarity with simplicity? In such a world, educators would look to what the industry demands and feel that in good faith, they should give those languages some treatment in courses over time. We might also see these universities (under pressure from an increasingly competitive market for the bulk of undergrad education), start to set aside time-tested teaching languages and regretfully move to courseware that prepares people for these industry jobs. I feel like maybe my story matches reality at least as well as yours. It also explains why a simpleton like me might be able to learn these supposedly unapproachable languages like Forth, Lisp, F# and Haskell without appealing to me being a genius.