11 ms·

I definitely find there's a strong relationship between language complexity and bikeshedding. When you have a big language like Haskell or Scala, it's easy to g

I definitely find there's a strong relationship between language complexity and bikeshedding. When you have a big language like Haskell or Scala, it's easy to get distracted from solving the actual problem by trying to do it the most "proper" way possible. This is also how you end up with design astronautics in enterprise Java as well where people obsess over using every design pattern in the book instead of writing direct and concise code that's going to be maintainable. Nowadays I have a strong preference for simple and focused languages that use a small number of patterns that can be applied to a wide range of problems. That goes a long way in avoiding the analysis paralysis problem.

mac01021 8y ago
I don't disagree in general but is Haskell a big language?
- klodolph 8y ago
  Large in the sense that it admits many approaches to solving problems. https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html
  - dwohnitmok 8y ago
    It's meant as a joke but as the author of that page points out, I think there's real pedagogical value in understanding all of the examples. You'll learn quite a bit of CS fundamentals independent of Haskell itself. Then please do as the professor does when it comes to production code.
- wtracy 8y ago
  Haskell has a ridiculous number of obscure operators. Here's a list of "common surprising" operators in Haskell: https://haskell-lang.org/tutorial/operators https://haskell-lang.org/tutorial/operators
  - jhayward 8y ago
    Those are mostly library functions, not part of the language. It doesn't seem any more reasonable to use them to declare Haskell a complex language than it would to have the existence of, say, a linear algebra library providing mathematical operators for Forth mean that Forth is a complex language.
    - AnimalMuppet 8y ago
      Depends on what library they're from. Is the STL part of C++? Sure, it's a library, but it's a standard library - it should be there in every conforming implementation. Personally, I think of that as part of the language. Is some vendor's RS232-port-handling library part of C++? I would say no. In the same way, I think that Java's standard library is part of the language, and is in fact the strongest selling point of Java.
  - dwohnitmok 8y ago
    Those are part of the standard library rather than the language itself though. You can (and a lot of people do) define and use your own standard library instead (hmmm... maybe a rabbit hole of its own? Although it seems companies with legitimate business needs do this as well so who knows).
  - dpratt71 8y ago
    I don't think it makes sense to characterize Haskell as "big" on this basis, because 1) it is trivial to define an operator in Haskell, so there's bound to be a lot of them and 2) even the "standard" operators typically have a simple definition (e.g. https://www.stackage.org/haddock/lts-12.9/base-4.11.1.0/src/GHC-Base.html#%24 https://www.stackage.org/haddock/lts-12.9/base-4.11.1.0/src/...).
    - wtracy 8y ago
      Even if the operators themselves don't count as "part of the language", the complex precedence rules around them certainly should.
- dwohnitmok 8y ago
  Haskell 2010 is pretty small. Comparable to say Clojure, but more complex than Scheme. GHC Haskell with the kitchen sink of extensions turned on is big. Very big. Sticking to Haskell 2010 with a few extensions that make known behavior more consistent (GADTs, NoMonomorphismRestriction, and a few others in that vein) is the best bang for buck in my experience.
  - hota_mazi 8y ago
    The complexity of a language has nothing to do with its size. Brainfuck or Whitespace are two minuscule languages that produce the most impenetrable sources.
    - dwohnitmok 8y ago
      That's true. I meant size in the hand-wavy sense of "this feels complicated" (although the syntax part is also true in this case). For example there's a GHC extension to overload the meaning of a type declaration (DataKinds). This technically doesn't introduce new syntax but it's definitely a "big" extension in my book.
    - Tarean 8y ago
      > I'm from Microsoft and when you see Microsoft documentation it often says, you know, x y or z is a rich something, right. In this case Haskell - or ghc's version of haskell is a rich language. What does this mean? Sounds good, doesn't it? But it always means this, right. That it's a large, complex, poorly understood, ill documented thing that nobody understands completely. From a great talk by Simon Peyton Jones https://youtu.be/re96UgMk6GQ https://youtu.be/re96UgMk6GQ
      - Tarean 8y ago
        Linked the wrong talk, oups https://www.youtube.com/watch?v=uR_VzYxvbxg https://www.youtube.com/watch?v=uR_VzYxvbxg
- yogthos 8y ago
  I think the complexity in Haskell largely comes from its advanced type system and laziness. For example, pervasive use of monads in Haskell is a direct result of encoding side effects using the type system. You can't just put a log statement in a function, you have to do a whole design exercise of how to push it to the edge of the application.
  - pka 8y ago
    http://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-Trace.html#v:trace http://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-... For future reference, this isn’t a good argument for trolling Haskellers.
    - fnord123 8y ago
      >These can be useful for investigating bugs or performance problems. They should not be used in production code.
      - pka 8y ago
        Well yeah, because a logging statement in production can fail (i.e. network connection drops). The type system forces you to deal with that fact instead of letting you write code that e.g. brings down your server unexpectedly because of some random log call. Many would consider that a feature, but if you want to #yolo it anyway, like in most other languages, just use trace in prod and call it a day.
        yogthos 8y ago
        The type system forces you to solve this problem in a very specific way by structuring your entire app around pushing IO to the edges. There are plenty of other ways to address the problem that work perfectly fine in practice. For example, you can specify what should happen is IO fails in your logging configuration. This handles the exceptional case consistently and in a single place without forcing you to structure your whole app around it. What's more is that there really isn't a sane way to recover from such a catastrophic failure. If your database goes down, or you lose a disk, the only thing you can do is shut down the app. It's not like it's gonna keep humming along with the logging failing silently. This kind of hyperbole that your either solve all problems via the type system or #yolo is precisely what makes Haskell community so toxic in my opinion.
- rs86 8y ago
  I don't think it is small or minimal but I believe it to be smaller than Scala
- gizmo686 8y ago
  Haskell 98 is a simple language. Modern Haskell is not. Or, at least, the superset of modern Haskell that GHC implements is not simple.
Barrin92 8y ago
Reminds me of one of Rich Hickey's talks where he states that people just love to solve puzzles, and that complex languages with, for example, demanding type systems trick people into thinking they are adding safety or value when in fact they're just outsmarting themselves. Often when I write something in Haskell I have this feeling. It feels satisfying to build up nice types and constructs but I don't know if it at all pays off in any objective or empiric sense. I can't really tell if I've invented the problem that I just solved.
- wool_gather 8y ago
  > I can't really tell if I've invented the problem that I just solved. Priceless observation, nicely done! I was quite inspired by Rich Hickey's Simple Made Easy talk when I listened to it a last year. I think that's the one you're referring to. Excellent food for thought in that talk.
vmchale 8y ago
> Nowadays I have a strong preference for simple and focused languages that use a small number of patterns that can be applied to a wide range of problems. Haskell is a simple and focused language, provided you use GHC with minimal extensions.
lmm 8y ago
I think the very fact that this happens in Java - a deliberately simplistic language - is proof that it's not a problem with the language itself. If the language doesn't support particular constructs, all that means is that people will bikeshed over which pattern to use instead of which language construct.

mac01021 8y ago

I don't disagree in general but is Haskell a big language?

klodolph 8y ago
Large in the sense that it admits many approaches to solving problems. https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html
- dwohnitmok 8y ago
  It's meant as a joke but as the author of that page points out, I think there's real pedagogical value in understanding all of the examples. You'll learn quite a bit of CS fundamentals independent of Haskell itself. Then please do as the professor does when it comes to production code.
wtracy 8y ago
Haskell has a ridiculous number of obscure operators. Here's a list of "common surprising" operators in Haskell: https://haskell-lang.org/tutorial/operators https://haskell-lang.org/tutorial/operators
- jhayward 8y ago
  Those are mostly library functions, not part of the language. It doesn't seem any more reasonable to use them to declare Haskell a complex language than it would to have the existence of, say, a linear algebra library providing mathematical operators for Forth mean that Forth is a complex language.
  - AnimalMuppet 8y ago
    Depends on what library they're from. Is the STL part of C++? Sure, it's a library, but it's a standard library - it should be there in every conforming implementation. Personally, I think of that as part of the language. Is some vendor's RS232-port-handling library part of C++? I would say no. In the same way, I think that Java's standard library is part of the language, and is in fact the strongest selling point of Java.
- dwohnitmok 8y ago
  Those are part of the standard library rather than the language itself though. You can (and a lot of people do) define and use your own standard library instead (hmmm... maybe a rabbit hole of its own? Although it seems companies with legitimate business needs do this as well so who knows).
- dpratt71 8y ago
  I don't think it makes sense to characterize Haskell as "big" on this basis, because 1) it is trivial to define an operator in Haskell, so there's bound to be a lot of them and 2) even the "standard" operators typically have a simple definition (e.g. https://www.stackage.org/haddock/lts-12.9/base-4.11.1.0/src/GHC-Base.html#%24 https://www.stackage.org/haddock/lts-12.9/base-4.11.1.0/src/...).
  - wtracy 8y ago
    Even if the operators themselves don't count as "part of the language", the complex precedence rules around them certainly should.
dwohnitmok 8y ago
Haskell 2010 is pretty small. Comparable to say Clojure, but more complex than Scheme. GHC Haskell with the kitchen sink of extensions turned on is big. Very big. Sticking to Haskell 2010 with a few extensions that make known behavior more consistent (GADTs, NoMonomorphismRestriction, and a few others in that vein) is the best bang for buck in my experience.
- hota_mazi 8y ago
  The complexity of a language has nothing to do with its size. Brainfuck or Whitespace are two minuscule languages that produce the most impenetrable sources.
  - dwohnitmok 8y ago
    That's true. I meant size in the hand-wavy sense of "this feels complicated" (although the syntax part is also true in this case). For example there's a GHC extension to overload the meaning of a type declaration (DataKinds). This technically doesn't introduce new syntax but it's definitely a "big" extension in my book.
  - Tarean 8y ago
    > I'm from Microsoft and when you see Microsoft documentation it often says, you know, x y or z is a rich something, right. In this case Haskell - or ghc's version of haskell is a rich language. What does this mean? Sounds good, doesn't it? But it always means this, right. That it's a large, complex, poorly understood, ill documented thing that nobody understands completely. From a great talk by Simon Peyton Jones https://youtu.be/re96UgMk6GQ https://youtu.be/re96UgMk6GQ
    - Tarean 8y ago
      Linked the wrong talk, oups https://www.youtube.com/watch?v=uR_VzYxvbxg https://www.youtube.com/watch?v=uR_VzYxvbxg
yogthos 8y ago
I think the complexity in Haskell largely comes from its advanced type system and laziness. For example, pervasive use of monads in Haskell is a direct result of encoding side effects using the type system. You can't just put a log statement in a function, you have to do a whole design exercise of how to push it to the edge of the application.
- pka 8y ago
  http://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-Trace.html#v:trace http://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-... For future reference, this isn’t a good argument for trolling Haskellers.
  - fnord123 8y ago
    >These can be useful for investigating bugs or performance problems. They should not be used in production code.
    - pka 8y ago
      Well yeah, because a logging statement in production can fail (i.e. network connection drops). The type system forces you to deal with that fact instead of letting you write code that e.g. brings down your server unexpectedly because of some random log call. Many would consider that a feature, but if you want to #yolo it anyway, like in most other languages, just use trace in prod and call it a day.
      - yogthos 8y ago
        The type system forces you to solve this problem in a very specific way by structuring your entire app around pushing IO to the edges. There are plenty of other ways to address the problem that work perfectly fine in practice. For example, you can specify what should happen is IO fails in your logging configuration. This handles the exceptional case consistently and in a single place without forcing you to structure your whole app around it. What's more is that there really isn't a sane way to recover from such a catastrophic failure. If your database goes down, or you lose a disk, the only thing you can do is shut down the app. It's not like it's gonna keep humming along with the logging failing silently. This kind of hyperbole that your either solve all problems via the type system or #yolo is precisely what makes Haskell community so toxic in my opinion.
rs86 8y ago
I don't think it is small or minimal but I believe it to be smaller than Scala
gizmo686 8y ago
Haskell 98 is a simple language. Modern Haskell is not. Or, at least, the superset of modern Haskell that GHC implements is not simple.

Barrin92 8y ago

Reminds me of one of Rich Hickey's talks where he states that people just love to solve puzzles, and that complex languages with, for example, demanding type systems trick people into thinking they are adding safety or value when in fact they're just outsmarting themselves. Often when I write something in Haskell I have this feeling. It feels satisfying to build up nice types and constructs but I don't know if it at all pays off in any objective or empiric sense. I can't really tell if I've invented the problem that I just solved.

wool_gather 8y ago
> I can't really tell if I've invented the problem that I just solved. Priceless observation, nicely done! I was quite inspired by Rich Hickey's Simple Made Easy talk when I listened to it a last year. I think that's the one you're referring to. Excellent food for thought in that talk.

vmchale 8y ago

> Nowadays I have a strong preference for simple and focused languages that use a small number of patterns that can be applied to a wide range of problems. Haskell is a simple and focused language, provided you use GHC with minimal extensions.

lmm 8y ago

I think the very fact that this happens in Java - a deliberately simplistic language - is proof that it's not a problem with the language itself. If the language doesn't support particular constructs, all that means is that people will bikeshed over which pattern to use instead of which language construct.