18 ms·

Probably because, A), it was an uncalled-for digression into language wars, and B), now that we're here anyways, a lot of us think the majority of features in

by jbooth 12y ago

Probably because, A), it was an uncalled-for digression into language wars, and B), now that we're here anyways, a lot of us think the majority of features in scala and Haskell for that matter are fundamentally misguided. My goal is not to write elegant code, but to write the least complex code with the lowest cognitive overhead. TCO, 10x the man-hours in maintenance and all that. If the choice is between having to write null-checks or having to understand category theory to read my code, I'll take the null-checks.

psibi 12y ago
> majority of features in scala and Haskell for that matter are fundamentally misguided I'm interested in the Haskell part. What features do you think are fundamentally misguided ?
- jbooth 12y ago
  I'm much less experienced with Haskell than with Scala, so I might be unfairly painting it with the same brush here. But, for example, https://www.haskell.org/tutorial/io.html https://www.haskell.org/tutorial/io.html. At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. I shouldn't have to care what a monad is, and side effects? The whole point of I/O is side effects. It could be a no-op, idle process or CPU-burning busy loop if I didn't care about side effects. From that doc: " So, in the end, has Haskell simply re-invented the imperative wheel? In some sense, yes. The I/O monad constitutes a small imperative sub-language inside Haskell, and thus the I/O component of a program may appear similar to ordinary imperative code. But there is one important difference: There is no special semantics that the user needs to deal with. In particular, equational reasoning in Haskell is not compromised. The imperative feel of the monadic code in a program does not detract from the functional aspect of Haskell. An experienced functional programmer should be able to minimize the imperative component of the program, only using the I/O monad for a minimal amount of top-level sequencing. The monad cleanly separates the functional and imperative program components. In contrast, imperative languages with functional subsets do not generally have any well-defined barrier between the purely functional and imperative worlds." So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere). And that's fine, they can knock themselves out and I hope it's fulfilling for them. It's not for me.
  - tree_of_item 12y ago
    I don't think they are acknowledging any impedance mismatch there. The point of that paragraph is to emphasize that Haskell retains the usual feel of imperative programming, with the important difference that the imperative bits of your code are cleanly separated from the pure bits due to the IO type. There's no theoretical stuff here, it's just making sure that the caller knows about callees having side effects.
  - imanaccount247 12y ago
    >At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. No, you have a tiny, very simple type that allows for type safe IO. It also happens to make haskell a more powerful imperative language than most imperative languages, as IO actions are first class and can be passed around and manipulated like anything else. >So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere) No, they acknowledge that doing IO is so important that it should be done correctly. You are going to some pretty extreme mental gymnastics to misrepresent a language you want to hate.
    - yarou 12y ago
      To be fair, understanding I/O in Haskell takes quite a bit of mental gymnastics. :) The I/O monad modifies the Universe that contains the set of all functions that comprise your program (if I even understand the concept correctly).
      - tome 12y ago
        > The I/O monad modifies the Universe that contains the set of all functions that comprise your program That sounds rather complicated. My way of thinking of it is simpler than that. a -> IO b is just a function from a to b that can do some I/O. Nothing more complicated than that.
        wbillingsley 12y ago
eranation 12y ago
Understood, By the way, I do null checks in Scala, may the lord have mercy on my soul. I don't like all the "I'm functional and smarter than you with my higher kind types, Monads and type classes" attitude that a minority of Scala lead figures have given it. Scala is very pragmatic down to earth language that you don't HAVE to abuse, the issue is that some people abused it on some libraries (e.g. with weird operators etc...) and some people are "either all the way functional or I rather die" but I think that if any C# developer would have jumped into Scala, they would have had much better things to say about it, even without using a single "purely functional" aspect of the language.
- hibikir 12y ago
  I'd not say that avoiding null checks requires any serious functional magic. It's a matter of convention: If you are ever using anything that could be null, surround it with an Option. It just makes the fields that might need to be checked explicit. One doesn't have to learn category theory to realize that Options are great, especially when accompanied by a little bit of help from pattern matching, map, flatten and getOrElse. The fact that many Scala lead figures that come from a Haskell background are bringing with them a holier than thou attitude doesn't mean that there aren't some functional concepts that are very useful even if your code is mostly imperative, and Option is arguably the least controversial of the lot. It's so uncontroversial it's in Java 8, although suffering from the fact that it is lacking some of the great Scala goodies.
tome 12y ago
> If the choice is between having to write null-checks or having to understand category theory to read my code Me too. Luckily this is a false dichotomy.
- jbooth 12y ago
  Here's a random line from the Scala standard collections library: def :+[B >: A, That](elem: B)(implicit bf: CanBuildFrom[Repr, B, That]): That This is from the standard collections library. In Java, I've got a List.add function. In case it's not clear from the name, 'add', I can click through to the implementation and it's pretty obvious what's happening. In Scala, I've got +, ++, +:, :+, and a bunch of other nonsensical bullshit, and when I click through to the implementation? Even less sense. Whenever I use a standard scala collection, I have no idea what it's actually doing. Additionally, everything favors allocation-happy overly-clever immutable wrappers rather than a simple ArrayList which will smoke those immutable implementations in real-world performance. The cure is far worse than the disease, here.
  - imanaccount247 12y ago
    How on earth does "I don't like operators" support your claim?
    - jbooth 12y ago
      The claim was that scala code is very difficult to read and idiomatic scala code, as evidenced by their collections library, brings along a ton of conceptual overhead that creates much more complexity than it eliminates. That line alone drives home the point for me, you can read the rest of scala.collection.immutable if you need more convincing.
      - yarou 12y ago
        First and foremost, I think you need to read about Blub. [0] Also, idiomatic Scala code is perfectly readable. You have no right to complain about readability until you've dealt with spaghetti code written for Megacorp Inc, that completely ignores the fundamentals of structured programming. :) [0] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
eloisant 12y ago
A) I think C# is a great language actually, and Scala's success is probably due to Java's severe limitations. I just don't think someone working on Unix should be jealous of C# because there are great languages available here. B) Precisely, unlike Haskell, Scala doesn't force you to write "elegant code", you can even use variables. Purists will flame you for that, but sometimes it's the best way to write a small piece of code and as soon as no state leaks outside of the function, it's not that bad. That said, I believe most of the features of Scala make maintenance easier, including the absence of null-checks as it moves errors from runtime to compile time and make major modifications without regressions easier.
- deleted 12y ago
  [deleted]
- Filligree 12y ago
  You can use variables in Haskell as well, no problem. It just forces you to stack your monad on IO, STM or some other mutable-value-supporting monad, of which there are several. The only difference worth mentioning is that they type system won't allow "leaks".
imanaccount247 12y ago
How can you think they are "fundamentally misguided" if you don't even know what they are? The category theory strawman is the absolute laziest, most absurd piece of FUD you could possibly resort to. It is even worse than the old "perl is bad because I don't want to read line noise" nonsense, at least that had some loose tie to reality.
- jacquesm 12y ago
  Missed opportunity to explain why those are 'fundamentally misguided'.
  - SamReidHughes 12y ago
    GP didn't mention specifically which features were misguided, making a response require a disproportionate amount of effort compared to what he's put in. And he's talking complete nonsense about "category theory," which is just ridiculous so it's not like he's close to worthy of some effort-post.
    - _dps 12y ago
      In my experience the "category theory" claim is imprecise but not unfounded. Without fairly serious abstract understanding of monads, functors, and applicatives (at a bare minimum), it is not possible to write Haskell code profitably. By that I mean that without such knowledge you should have just written something else. To make Haskell a serious advantage and not just a minor benefit (compared to, say, SML), you probably also need to understand kinds. Let's bear in mind that the vast majority of practicing programmers can't reasonably define an algebraic data type, and that it's not their fault, because the ROI for learning such things is often negative. I do think there is a reactionary "don't-wanna-learn anything" vibe against Haskell among certain groups. But I think we should be clear that, to get the power that Haskell promises, you do need to learn many new things. Those things, while not exactly category theory in a narrow sense, are closer to category theory than they are to conventional programming knowledge.
      - 12y ago
Pxtl 12y ago
I'd rather duck the question by supporting non-nullable columns without resorting to higher-kinded types.
pistle 12y ago
If I'm not mistaken C# 6 will be improving on the null check thing as well. Though, the syntax seems jarring to me right now (so did the inverted SQL-like linq style - yeah for the fluent style).

by jbooth 12y ago

psibi 12y ago

> majority of features in scala and Haskell for that matter are fundamentally misguided I'm interested in the Haskell part. What features do you think are fundamentally misguided ?

jbooth 12y ago
I'm much less experienced with Haskell than with Scala, so I might be unfairly painting it with the same brush here. But, for example, https://www.haskell.org/tutorial/io.html https://www.haskell.org/tutorial/io.html. At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. I shouldn't have to care what a monad is, and side effects? The whole point of I/O is side effects. It could be a no-op, idle process or CPU-burning busy loop if I didn't care about side effects. From that doc: " So, in the end, has Haskell simply re-invented the imperative wheel? In some sense, yes. The I/O monad constitutes a small imperative sub-language inside Haskell, and thus the I/O component of a program may appear similar to ordinary imperative code. But there is one important difference: There is no special semantics that the user needs to deal with. In particular, equational reasoning in Haskell is not compromised. The imperative feel of the monadic code in a program does not detract from the functional aspect of Haskell. An experienced functional programmer should be able to minimize the imperative component of the program, only using the I/O monad for a minimal amount of top-level sequencing. The monad cleanly separates the functional and imperative program components. In contrast, imperative languages with functional subsets do not generally have any well-defined barrier between the purely functional and imperative worlds." So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere). And that's fine, they can knock themselves out and I hope it's fulfilling for them. It's not for me.
- tree_of_item 12y ago
  I don't think they are acknowledging any impedance mismatch there. The point of that paragraph is to emphasize that Haskell retains the usual feel of imperative programming, with the important difference that the imperative bits of your code are cleanly separated from the pure bits due to the IO type. There's no theoretical stuff here, it's just making sure that the caller knows about callees having side effects.
- imanaccount247 12y ago
  >At the end of the day, this is a huge inner-framework anti-pattern over the same procedural syscalls that every other language handles procedurally. No, you have a tiny, very simple type that allows for type safe IO. It also happens to make haskell a more powerful imperative language than most imperative languages, as IO actions are first class and can be passed around and manipulated like anything else. >So, basically, they acknowledge that their theoretical model has a huge impedance mismatch with what we write programs to do (I/O, eventually, somewhere) No, they acknowledge that doing IO is so important that it should be done correctly. You are going to some pretty extreme mental gymnastics to misrepresent a language you want to hate.
  - yarou 12y ago
    To be fair, understanding I/O in Haskell takes quite a bit of mental gymnastics. :) The I/O monad modifies the Universe that contains the set of all functions that comprise your program (if I even understand the concept correctly).
    - tome 12y ago
      > The I/O monad modifies the Universe that contains the set of all functions that comprise your program That sounds rather complicated. My way of thinking of it is simpler than that. a -> IO b is just a function from a to b that can do some I/O. Nothing more complicated than that.
      - wbillingsley 12y ago

eranation 12y ago

Understood, By the way, I do null checks in Scala, may the lord have mercy on my soul. I don't like all the "I'm functional and smarter than you with my higher kind types, Monads and type classes" attitude that a minority of Scala lead figures have given it. Scala is very pragmatic down to earth language that you don't HAVE to abuse, the issue is that some people abused it on some libraries (e.g. with weird operators etc...) and some people are "either all the way functional or I rather die" but I think that if any C# developer would have jumped into Scala, they would have had much better things to say about it, even without using a single "purely functional" aspect of the language.

hibikir 12y ago
I'd not say that avoiding null checks requires any serious functional magic. It's a matter of convention: If you are ever using anything that could be null, surround it with an Option. It just makes the fields that might need to be checked explicit. One doesn't have to learn category theory to realize that Options are great, especially when accompanied by a little bit of help from pattern matching, map, flatten and getOrElse. The fact that many Scala lead figures that come from a Haskell background are bringing with them a holier than thou attitude doesn't mean that there aren't some functional concepts that are very useful even if your code is mostly imperative, and Option is arguably the least controversial of the lot. It's so uncontroversial it's in Java 8, although suffering from the fact that it is lacking some of the great Scala goodies.

tome 12y ago

> If the choice is between having to write null-checks or having to understand category theory to read my code Me too. Luckily this is a false dichotomy.

jbooth 12y ago
Here's a random line from the Scala standard collections library: def :+[B >: A, That](elem: B)(implicit bf: CanBuildFrom[Repr, B, That]): That This is from the standard collections library. In Java, I've got a List.add function. In case it's not clear from the name, 'add', I can click through to the implementation and it's pretty obvious what's happening. In Scala, I've got +, ++, +:, :+, and a bunch of other nonsensical bullshit, and when I click through to the implementation? Even less sense. Whenever I use a standard scala collection, I have no idea what it's actually doing. Additionally, everything favors allocation-happy overly-clever immutable wrappers rather than a simple ArrayList which will smoke those immutable implementations in real-world performance. The cure is far worse than the disease, here.
- imanaccount247 12y ago
  How on earth does "I don't like operators" support your claim?
  - jbooth 12y ago
    The claim was that scala code is very difficult to read and idiomatic scala code, as evidenced by their collections library, brings along a ton of conceptual overhead that creates much more complexity than it eliminates. That line alone drives home the point for me, you can read the rest of scala.collection.immutable if you need more convincing.
    - yarou 12y ago
      First and foremost, I think you need to read about Blub. [0] Also, idiomatic Scala code is perfectly readable. You have no right to complain about readability until you've dealt with spaghetti code written for Megacorp Inc, that completely ignores the fundamentals of structured programming. :) [0] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

eloisant 12y ago

A) I think C# is a great language actually, and Scala's success is probably due to Java's severe limitations. I just don't think someone working on Unix should be jealous of C# because there are great languages available here. B) Precisely, unlike Haskell, Scala doesn't force you to write "elegant code", you can even use variables. Purists will flame you for that, but sometimes it's the best way to write a small piece of code and as soon as no state leaks outside of the function, it's not that bad. That said, I believe most of the features of Scala make maintenance easier, including the absence of null-checks as it moves errors from runtime to compile time and make major modifications without regressions easier.

deleted 12y ago
[deleted]
Filligree 12y ago
You can use variables in Haskell as well, no problem. It just forces you to stack your monad on IO, STM or some other mutable-value-supporting monad, of which there are several. The only difference worth mentioning is that they type system won't allow "leaks".

imanaccount247 12y ago

How can you think they are "fundamentally misguided" if you don't even know what they are? The category theory strawman is the absolute laziest, most absurd piece of FUD you could possibly resort to. It is even worse than the old "perl is bad because I don't want to read line noise" nonsense, at least that had some loose tie to reality.

jacquesm 12y ago
Missed opportunity to explain why those are 'fundamentally misguided'.
- SamReidHughes 12y ago
  GP didn't mention specifically which features were misguided, making a response require a disproportionate amount of effort compared to what he's put in. And he's talking complete nonsense about "category theory," which is just ridiculous so it's not like he's close to worthy of some effort-post.
  - _dps 12y ago
    In my experience the "category theory" claim is imprecise but not unfounded. Without fairly serious abstract understanding of monads, functors, and applicatives (at a bare minimum), it is not possible to write Haskell code profitably. By that I mean that without such knowledge you should have just written something else. To make Haskell a serious advantage and not just a minor benefit (compared to, say, SML), you probably also need to understand kinds. Let's bear in mind that the vast majority of practicing programmers can't reasonably define an algebraic data type, and that it's not their fault, because the ROI for learning such things is often negative. I do think there is a reactionary "don't-wanna-learn anything" vibe against Haskell among certain groups. But I think we should be clear that, to get the power that Haskell promises, you do need to learn many new things. Those things, while not exactly category theory in a narrow sense, are closer to category theory than they are to conventional programming knowledge.
    - 12y ago

Pxtl 12y ago

I'd rather duck the question by supporting non-nullable columns without resorting to higher-kinded types.

pistle 12y ago

If I'm not mistaken C# 6 will be improving on the null check thing as well. Though, the syntax seems jarring to me right now (so did the inverted SQL-like linq style - yeah for the fluent style).