Really? Fine. Then please show me a list of Haskell equivalents of Eclipse, NetBeans, Open Office, e-commerce software, and other big software which was written in Java. Thank you.
Let me answer you and it will hopefully address other replies as well.
First, your response is a straw man; there is an enormous amount of effort put into systems that are more complex than needs to be be. Mostly this is for historical and compatibility reasons (including social inertia). In case of Java, it succeeded because it was based on C++.
Also, simpler programming doesn't always translate to more runtime efficiency. Haskell programs on their own are not very efficient; potentially, yes, but IMHO at this moment efficiency shouldn't be a reason why to choose Haskell over C++ or Java.
Paradoxically, to understand how to do things in a simple way requires a lot of effort, and history seems to progress from more complicated to simpler (although there is also increase in abstraction, because that's what improves productivity).
I work in mainframes, and it's a sort of archeology that gives you a good perspective on that. A good canonical example is datasets; on z/OS, datasets have different organization (different record sizes and whatnot), unlike in Unix, where file is simply a sequence of bytes. There are many other examples from mainframes (like CKD DASD). Some of them were given by historical limitations of hardware (or also done for efficiency reasons), but mostly they are evolutionary dead ends of too much complexity.
So I really think Haskell has simpler building blocks. More abstract, more orthogonal, and so on, than Java (or most imperative languages). The point is, it's not simpler to build something with more complicated building blocks, on the contrary. There are intrinsic complications of the problem (which other reply to me alludes to), but there are also unnecessary complications arising from complicated building blocks (such as, having to deal with different ways to access files on z/OS, compared to Unix).
To conclude, I feel that the concept of Java-like "class" is a too complicated building block that tries to do too many things in one abstraction. And I see design patterns as a sort of evidence, because most of these explain how to build things from classes that are perfectly obvious when you have data types and functions.
> Really? Fine. Then please show me a list of Haskell equivalents of Eclipse, NetBeans, Open Office, e-commerce software, and other big software which was written in Java. Thank you.
> I actually prefer Haskell, because it is pretty simple, you have datatypes and functions and that's it.. In Java, things are more complicated, with all the different design patterns and classes and other contraptions. I think you have to be smarter to program in Java than to program in Haskell.
did you take to be a claim that Haskell offers equivalents of the vast Java ecosystem, or even any claim about the relative merits of the products of the languages (rather than the ease of using them to program)?
If people claim that Haskell is "pretty simple" and Java is "more complicated" then why in the world is there almost no evidence for that? Why are things like Eclipse and Netbeans availabe for many years why Haskell is still blaming itself by fighting the very basic cabal hell? I know sandboxes and Nix and all those tools which circumvent the cabal hell. But consider how the Java world would respond if Java 9 would require sandboxes or Nix to manage every software project :-)
I like Haskell, and I consider Haskell far superior (and more complicated) than Java. I also know Java pretty well. Java is far from being "more complicated" than Haskell. There is a reason why there are way more Java developers than Haskell developers. In my experience Haskell is powerful and elegant but not very practical. Practical are other languages (Rust, C++, Java, Nim, OCaml, ...). That' why Eclipse, Open Office, MS Office, operating systems, mars land projects and other big software is written in everything but Haskell.
I think there is a problem in your thinking with conflating "simple" and "practical". You can have a more complicated thing being more practical simply because there is a better tooling or ecosystem, as you correctly point out.
> What is the worth of "simple" if it is not "practical"?
I cannot speak for js8, but I think you took his or her statement of personal preferences as a statement of value. (That is, I think that the statement that he or she preferred a simple language was not the statement that it was 'worth' more in any abstract sense.) I imagine that everyone in this discussion would agree that 'simple' and 'practical' are different. I personally think that the lambda calculus is even simpler than the theory of Turing machines, and yet probably still less practical. I enjoy the theoretical beauty and austerity, and I imagine that js8 is in somewhat the same boat.
(For an extreme example of going the other direction, consider Perl, which is an eminently, even sometimes excessively, practical language, but which none among even its most ardent fans—and I am one!—would call simple.)
First, your response is a straw man; there is an enormous amount of effort put into systems that are more complex than needs to be be. Mostly this is for historical and compatibility reasons (including social inertia). In case of Java, it succeeded because it was based on C++.
Also, simpler programming doesn't always translate to more runtime efficiency. Haskell programs on their own are not very efficient; potentially, yes, but IMHO at this moment efficiency shouldn't be a reason why to choose Haskell over C++ or Java.
Paradoxically, to understand how to do things in a simple way requires a lot of effort, and history seems to progress from more complicated to simpler (although there is also increase in abstraction, because that's what improves productivity).
I work in mainframes, and it's a sort of archeology that gives you a good perspective on that. A good canonical example is datasets; on z/OS, datasets have different organization (different record sizes and whatnot), unlike in Unix, where file is simply a sequence of bytes. There are many other examples from mainframes (like CKD DASD). Some of them were given by historical limitations of hardware (or also done for efficiency reasons), but mostly they are evolutionary dead ends of too much complexity.
So I really think Haskell has simpler building blocks. More abstract, more orthogonal, and so on, than Java (or most imperative languages). The point is, it's not simpler to build something with more complicated building blocks, on the contrary. There are intrinsic complications of the problem (which other reply to me alludes to), but there are also unnecessary complications arising from complicated building blocks (such as, having to deal with different ways to access files on z/OS, compared to Unix).
To conclude, I feel that the concept of Java-like "class" is a too complicated building block that tries to do too many things in one abstraction. And I see design patterns as a sort of evidence, because most of these explain how to build things from classes that are perfectly obvious when you have data types and functions.