7 ms·

> I find the cognitive burden to be lower in Haskell than in, say, Java I don't think Java is a meaningful competitor. It's a language completely based on 90's

> I find the cognitive burden to be lower in Haskell than in, say, Java I don't think Java is a meaningful competitor. It's a language completely based on 90's hopes that OOP was a good idea. Turns out it is mostly good to program simple things as complex "ravioli code". Better compare against languages that games, kernels, and compilers are typically implemented in. > monad transformers (the promise of aspect oriented programming actually realized) How do monad transformers realize aspect oriented programming? In my experience they lead to pretty verbose code and lots of boilerplate. I think the way to achieve "aspect-orientedness" (I think this name is based on the same insight that lead to names like "separation of concerns", "cohesion", or "cross-cutting concerns") is simply to draw modules boundaries by shape of data, not in an OOP style where most objects do a million different things (etc. cat must eat, walk, sleep, meow...)

hota_mazi 9y ago
> It's a language completely based on 90's hopes that OOP was a good idea. I find the dismissive tone rather amusing. A large majority of the code running on our planet today is OOP. You could argue that there might be better ideas out there, but OOP is certainly an idea that has not only proven itself to be tremendously useful, but that has also been able to adjust and adapt through decades of changing requirements. It's pretty much the only software paradigm that's survived for that long.
- jstimpfle 9y ago
  Every objects-first codebase I've seen was terrible. OOP survived mostly because people push hard for it, because they think there must be value in overly taxonomic code, but in the end they never seem to get value out of it, only more and more incompatible objects (when I hear "mock object" it's time to run). In OOP >50% of the LOC is just stupid bureaucrazy, setting up object graphs in the name of "isolation" (the irony), half-initializing fields, conforming to the right interfaces etc. This is completely meaningless, do-nothing code. Worse, it gives the illusion to remove some contextual dependencies this way, but the code never seems to work outside of the context it was created in. It's only much harder to read because the context is files away. OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. It tries to repair this wrong idea with inheritance (which is at least as bad an idea). And it makes it really hard to cope for "cross-cutting concerns", which are actually 90% of all we care for, not just a side concern. The complexity is in the edges (i.e. how is information moved/transformed), not in the objects! OOP mostly survived where performance / architectural scalability is not super important (e.g. Python or similar scripting languages, where it enables dynamic typing). And it survived where the big money is, but not necessarily technical competence (where it enables Object-verb type code completion). That relates to OOP as in languages like Java - not Alan Kay's idea of OOP, which he emphasizes was very different, but I still don't get what's the idea :p > A large majority of the code running on our planet today is OOP. Good example code base? > It's pretty much the only software paradigm that's survived for that long. Maybe check on your history? Many people are totally happy with procedural programming.
  - mgummelt 9y ago
    > when I hear "mock object" it's time to run Do Haskell programmers not create mocks to test external components? > OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. The number of programs isn't the relevant metric. Complexity is. Any complex system is going to trend toward modularity. Modularity requires standard interfaces, which inevitably lead to bureaucracy. A 1MM line Haskell program is going to be similarly bureaucratic. There are going to be standards you have to adhere to in order to play nice with the rest of the system. That's what typeclasses are, after all. OOP is traditionally defined by three things: polymorphism, encapsulation, and inheritance. Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Encapsulation: You definitely want encapsulation if your data is mutable. Inheritance: This is the only truly problematic feature, and it's certainly abused, but it has its place. I don't always want to compose and delegate 20 methods when I just want to change the behavior of one.
    - tathougies 9y ago
      > Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Haskell had ad-hoc polymorphism way before Java was a twinkle in its creator's eye. Before Haskell, Miranda (the language Haskell was based off of) could have kicked Java's polymorphism to the curb. Neither Java nor OOP invented polymorphism. If anything, they butchered it by introducing subtyping. > Do Haskell programmers not create mocks to test external components? The equivalent in Haskell would be having some kind of 'effects' system. An effect system differs from a mock object in that it limits in its totality what kind of interactions can take place. Typically, each layered effect also has a set of laws. Pure interpreters can be written for these effects, but the impure (i.e., real-world) interpreters are not privileged in their consumption of this effect. The pure interpreter also provides a proper implementation, such that you should be able to replace your real program with all pure interpreters, supply all your input at once, and still have a correct program. In other words, a Haskell program is typically polymorphic over which effects it uses in a way that other languages simply aren't. > Encapsulation: You definitely want encapsulation if your data is mutable. Again, Haskell, Miranda, and Lisp had encapsulation long before OOP came about, and Lisp has mutable data.
- macintux 9y ago
  > It's pretty much the only software paradigm that's survived for that long. Perhaps the only one that’s been the most popular for that long.
- thesz 9y ago
  >It's pretty much the only software paradigm that's survived for that long. Functional programming predates non-functional programming - Turing's papers and thesis were published (at least) a year after Church's papers on lambda calculus. Type systems in FP run decades ahead of type systems in regular programming languages. For example, simple type system for FP was published in 1948 and it was (more or less) equivalent to Fortran's type system (1958). The type inference was published in 1968 by Hindley and Milner adapted his algorithm to more "efficient" mutable state in 1978. Type inference come to mainstream languages only in what? 2004? The algebraic types and pattern matching were born in 1971, the year I born too. These facilities start to appear in mainstream languages no earlier than 2008 if you consider Rust at that time as a mainstream language. And C# acquired them, I think, in 2016 and not earlier. I boldly and offensively assume that OOP is the only paradigm you decide to care about and thus you consider it "the only software paradigm". I think that it is a very useful position in life, not to care about things you decided not to care about. I do that too.
lomnakkus 9y ago
> I don't think Java is a meaningful competitor. Just curious... what would you consider a meaningful competitor to Haskell? Just to lay my own cards on the table: I'd prefer Haskell to almost all other languages if we were only talking about the language (well, the GHC dialect). I do use Haskell quite a bit, but unfortunately I also have to do quite a lot of work in the "enterprise" space where ridiculous things like being able to read e.g. Excel spreadsheets is a big deal. (That is, one cannot rely on people sending those spreadsheets over email to convert to CSV in any meaningful way, so...)
- jwdunne 9y ago
  Actually, I think there is at least one area where Haskell and java compete where other languages don't: design by committee. It's often joked that it IS possible to design by committee. The result is Haskell. Otherwise, you get Java.
iainmerrick 9y ago
Better compare against languages that games, kernels, and compilers are typically implemented in. Games... So, C# then? :)
- justinhj 9y ago
  If you’re talking about Unity it’s fair to point out that the game engine itself is built in C++ with C# being a user land VM. But a lot of mobile and a few PC games are written in Java
  - iainmerrick 9y ago
    I was more thinking that C# and Java are close to identical. I know they have some different features and can feel a little different, but they’re much closer to each other than ML and Haskell, say.

hota_mazi 9y ago

> It's a language completely based on 90's hopes that OOP was a good idea. I find the dismissive tone rather amusing. A large majority of the code running on our planet today is OOP. You could argue that there might be better ideas out there, but OOP is certainly an idea that has not only proven itself to be tremendously useful, but that has also been able to adjust and adapt through decades of changing requirements. It's pretty much the only software paradigm that's survived for that long.

jstimpfle 9y ago
Every objects-first codebase I've seen was terrible. OOP survived mostly because people push hard for it, because they think there must be value in overly taxonomic code, but in the end they never seem to get value out of it, only more and more incompatible objects (when I hear "mock object" it's time to run). In OOP >50% of the LOC is just stupid bureaucrazy, setting up object graphs in the name of "isolation" (the irony), half-initializing fields, conforming to the right interfaces etc. This is completely meaningless, do-nothing code. Worse, it gives the illusion to remove some contextual dependencies this way, but the code never seems to work outside of the context it was created in. It's only much harder to read because the context is files away. OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. It tries to repair this wrong idea with inheritance (which is at least as bad an idea). And it makes it really hard to cope for "cross-cutting concerns", which are actually 90% of all we care for, not just a side concern. The complexity is in the edges (i.e. how is information moved/transformed), not in the objects! OOP mostly survived where performance / architectural scalability is not super important (e.g. Python or similar scripting languages, where it enables dynamic typing). And it survived where the big money is, but not necessarily technical competence (where it enables Object-verb type code completion). That relates to OOP as in languages like Java - not Alan Kay's idea of OOP, which he emphasizes was very different, but I still don't get what's the idea :p > A large majority of the code running on our planet today is OOP. Good example code base? > It's pretty much the only software paradigm that's survived for that long. Maybe check on your history? Many people are totally happy with procedural programming.
- mgummelt 9y ago
  > when I hear "mock object" it's time to run Do Haskell programmers not create mocks to test external components? > OOP is the wrong-minded idea that a program should be a bundle of many "self-contained" objects. But that's wrong, we're writing ONE program here, not thousands. The number of programs isn't the relevant metric. Complexity is. Any complex system is going to trend toward modularity. Modularity requires standard interfaces, which inevitably lead to bureaucracy. A 1MM line Haskell program is going to be similarly bureaucratic. There are going to be standards you have to adhere to in order to play nice with the rest of the system. That's what typeclasses are, after all. OOP is traditionally defined by three things: polymorphism, encapsulation, and inheritance. Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Encapsulation: You definitely want encapsulation if your data is mutable. Inheritance: This is the only truly problematic feature, and it's certainly abused, but it has its place. I don't always want to compose and delegate 20 methods when I just want to change the behavior of one.
  - tathougies 9y ago
    > Polymorphism: Modern Non-OOP languages can also be polymorphic, so that's no longer a differentiator. Haskell had ad-hoc polymorphism way before Java was a twinkle in its creator's eye. Before Haskell, Miranda (the language Haskell was based off of) could have kicked Java's polymorphism to the curb. Neither Java nor OOP invented polymorphism. If anything, they butchered it by introducing subtyping. > Do Haskell programmers not create mocks to test external components? The equivalent in Haskell would be having some kind of 'effects' system. An effect system differs from a mock object in that it limits in its totality what kind of interactions can take place. Typically, each layered effect also has a set of laws. Pure interpreters can be written for these effects, but the impure (i.e., real-world) interpreters are not privileged in their consumption of this effect. The pure interpreter also provides a proper implementation, such that you should be able to replace your real program with all pure interpreters, supply all your input at once, and still have a correct program. In other words, a Haskell program is typically polymorphic over which effects it uses in a way that other languages simply aren't. > Encapsulation: You definitely want encapsulation if your data is mutable. Again, Haskell, Miranda, and Lisp had encapsulation long before OOP came about, and Lisp has mutable data.
macintux 9y ago
> It's pretty much the only software paradigm that's survived for that long. Perhaps the only one that’s been the most popular for that long.
thesz 9y ago
>It's pretty much the only software paradigm that's survived for that long. Functional programming predates non-functional programming - Turing's papers and thesis were published (at least) a year after Church's papers on lambda calculus. Type systems in FP run decades ahead of type systems in regular programming languages. For example, simple type system for FP was published in 1948 and it was (more or less) equivalent to Fortran's type system (1958). The type inference was published in 1968 by Hindley and Milner adapted his algorithm to more "efficient" mutable state in 1978. Type inference come to mainstream languages only in what? 2004? The algebraic types and pattern matching were born in 1971, the year I born too. These facilities start to appear in mainstream languages no earlier than 2008 if you consider Rust at that time as a mainstream language. And C# acquired them, I think, in 2016 and not earlier. I boldly and offensively assume that OOP is the only paradigm you decide to care about and thus you consider it "the only software paradigm". I think that it is a very useful position in life, not to care about things you decided not to care about. I do that too.

lomnakkus 9y ago

> I don't think Java is a meaningful competitor. Just curious... what would you consider a meaningful competitor to Haskell? Just to lay my own cards on the table: I'd prefer Haskell to almost all other languages if we were only talking about the language (well, the GHC dialect). I do use Haskell quite a bit, but unfortunately I also have to do quite a lot of work in the "enterprise" space where ridiculous things like being able to read e.g. Excel spreadsheets is a big deal. (That is, one cannot rely on people sending those spreadsheets over email to convert to CSV in any meaningful way, so...)

jwdunne 9y ago
Actually, I think there is at least one area where Haskell and java compete where other languages don't: design by committee. It's often joked that it IS possible to design by committee. The result is Haskell. Otherwise, you get Java.

iainmerrick 9y ago

Better compare against languages that games, kernels, and compilers are typically implemented in. Games... So, C# then? :)

justinhj 9y ago
If you’re talking about Unity it’s fair to point out that the game engine itself is built in C++ with C# being a user land VM. But a lot of mobile and a few PC games are written in Java
- iainmerrick 9y ago
  I was more thinking that C# and Java are close to identical. I know they have some different features and can feel a little different, but they’re much closer to each other than ML and Haskell, say.