Hello Alex!
A small disclaimer: none of the members of our team has an academic background. We all have different backgrounds: C#, Java, Ruby, Python, C, even Perl if I am not mistaken. Yet we ended up with FP first, and then with Haskell. We have switched to Haskell from Scala, which _is_ a multi-paradigm language borrowing bits and pieces from other languages/paradigms and mixing them together. It is an enormously hard work to do it and for that, I very much respect
Oh, my 1st question will be: did you try Eta, Frege? May be I’m wrong but Eta should support Haskell libraries as well as Java ones? They allow you to use libraries from the both world...
As a result, the language becomes overly complicated and less useful.
Yes, this is another side. You know, anything has several sides: good and bad...
Your joke about how Haskell has been made misses one point: it was initially designed as a lazy language (at least as far as I know). Many features that Haskell has now are there because of laziness: if you want to be lazy, then you have to be pure, you have to sequence your effects, etc.
True. Laziness makes Haskell unique. I think Haskell makes laziness so popular in modern languages although it was known long ago (as data in “infinite streams”, etc). I think, Miranda was lazy, so Haskell is lazy too 😊 And IMHO there was some lazy dialect of ML (may be, I’m not right).
"Let's defer lambda, name it IO and let's call it Monad" - this bit isn't even funny. Monad isn't IO. IO happens to be a monad (as many things do, List as an example), but monad isn't IO and has nothing to do with IO. A horse is classified as Mammal, but Mammal doesn't mean horse _at all_.
Sure. I mean, the need of side-effects (and firstly I/O) led to the monads.
In a context of a lazy language, you need to sequence your effects (including side effects), that's the first point. The second is that instead of disappearing from Haskell, monads (and other concepts) are making their way to other languages. Scala has them, F# has them, even C# has them (however indirectly). Try to take away List Monad from C# developers and they'll kill you ;)
Better IMHO to have less infrastructure code. Better is to hide all “machinery” in compiler. My point was that monads are workaround of Haskell problem, this was historically reason of their appearance. And if I have not such limitation in my language I don’t need any monads. What are the monad benefits in ML, for example? They are using in F#, but 1) comp. expressions are not monads but step forward, “monads++” and 2) they play different role in F#: simplifying of the code. And you can avoid them in all languages except Haskell. For example, Prolog can be “pure” and to do I/O without monads, also Clean can as well as F#. Monads have pros, sure, but they are not composable and workaround leads to another workaround – transformers. I’m not unique in my opinion: https://www.youtube.com/watch?v=rvRD_LRaiRs All of this looks like overengineering due to mentioned limitation. No such one in ML, F#. D has keyword “pure”, and didn’t introduce monads. Performance is very important feature of the language, that limitation is the reason #1 why Haskell has bad and unpredictable performance. “do”-block is not the same as “flat” block of C# statements and its performance is not the same. I can achieve Maybe effect with nullable+exceptions or ?-family operators, List with permutations/LINQ, guard with if+break/continue and to do it without sacrificing performance.. ListT/conduits – are just generators/enumerators. Benefit of monads IMHO is small, they are workaround of Haskell problem and are not needed in other languages. Sure, there are monads in Ocaml, Javascript, Python (as experimental libraries), but the reason is hype. Nobody will remember them after 5-10 years... Actually this is very-very subjective IMHHHHO 😊
Lenses and generic lenses help, so be it. But I don't think that anything prevents Haskell from having it, and I don't think that Haskell as a language needs a dramatic change as you depict to make it happen. Just a feature.
When I have legacy code, there are a lot of types which fields are not starting with “_” prefix, so I need to create lenses explicitly... “Infrastructure” code. What is the business value of such code: nothing. For non-Haskell programmer it looks like you try to solve non-existing problem 😊 (very-very provocative point: all Haskell solutions looks very overengineering. The reason is: lambda-abstraction-only. When you try to build something big from little pieces then the process will be very overengineering. Imagine that the pyramids are built of small bricks).
I don't agree that operators are noise. You certainly can write Haskell almost without operators if you wish.
Here I’m agree with D. Knuth ideas of literature programming: if code can not be easy read and understand on the hard-copy then used language is not fine. Haskell code needs help from IDE, types hints, etc. And I often meet a case when somebody does not understand what monads are in “do” blocks. Also there are a lot of operators in different libraries and no way to know what some operator means (different libraries, even different versions have own set of operators).
As for extensions, I think that many more should be just switched on by default.
+1
You mean that conversion should happen implicitly? Thank you, but no, thank you. This is a source of problems in many languages, and it is such a great thing that Haskell doesn't coerce types implicitly.
No... Actually, I have not idea what is better. Currently there are a lot of conversions. Some libraries functions expect String, another - Text, also ByteString, lazy/strict, the same with the numbers (word/int/integer). So, conversions happen often.
I don't understand this "no business value" statement. Value for which business? What does it mean "check types, no business value"?
There are libraries which nothing do in run-time. Only types playing. Only abstractions over types. And somebody says: oh man, see how many libraries has Haskell. But you can compare libraries of Haskell, Java, C#, Javascript, Perl, Python 😊 All libraries of Java, Python... have business value. Real-world functionality. Not abstract play with types. But more important point is a case with installed Agda 😊 or alternative libraries which does the same/similar things. The reason is important: Haskell moves a lot of functionality to libraries which is not good design IMHO. This is the root of the problem. Better is to have one good solid library bundled with GHC itself (“batteries included”) and only specific things will live in libraries and frameworks. Monads and monads transformers are central thing in Haskell. They a located in libraries. There is standard parser combinators in GHC itself, but you will have in the same project another one (or more than 1!). Etc, etc... Also installed GHC... Why is it so big!? IMHO it’s time to clear ecosystem, to reduce it to “batteries” 😊
And then it falls into a famous joke: "The problem with Open Source Software is YOU because YOU are not contributing" :) Meaning that if we want more good libs then we should write more good libs :)
1. Haskell limits itself to lambda-only. Example, instead to add other abstractions and to become modern MULTI-paradigm languages, "modern"? That's not an interesting property. "maintainable", "expressive" - THESE are interesting. Multi-paradigm can help, but if overdone can hinder it - the earliest multi-paradigm language I'm aware of was PL/I, and that was a royal mess I hear. So, point #1 is limitation in abstraction: monads, transformers, anything - is function. It's not good. Actually limiting yourself to a single abstraciton tool can be good. This simplifies semantics and makes it easier to build stuff on top of it. Not that I'm saying that this is necessarily the best thing. There were such languages already: Forth, Joy/Cat, APL/J/K... Most of them look dead. Which proves nothing, because many multi-paradigm languages look dead, too. When you try to be elegant, your product (language) died. Proven by Lisp... er, disproven. This is not my opinion, this is only my observation. People like diversity and variety: in food, in programming languages, in relations, anywhere :) Not in programming languages. Actually multi-paradigm is usually a bad idea. It needs to be done in an excellent fashion to create something even remotely usable, while a single-paradigm language is much easier to do well. And in practice, bad language design has much nastier consequences than leaving out some desirable feature. 2. When language has killer app and killer framework, IMHO it has more chances. But if it has _killer ideas_ only... So, those ideas will be re-implemented in other languages and frameworks but with more simple and typical syntax :) "Typical" is in the eye of the beholder, so that's another non-argument. It's difficult to compete with product, framework, big library, but it's easy to compete with ideas. It's an observation too :-) Sure, but Haskell has product, framework, big library. What's missing is commitment by a big company, that's all. Imagine Google adopting Haskell, committing to building libraries and looking for Haskell programmers in the streets - all of a sudden, Haskell is going to be the talk of the day. (Replace "Google" with whatever big-name company with deep pockets: Facebook, MS, IBM, you name it.) language itself is not argument for me. You are arguing an awful lot about missing language features ("multi-paradigm") to credibly make that statement. Argument for me (I am usual developer) are killer apps/frameworks/libraries/ecosystem/etc. Currently Haskell has stack only - it's very good, but most languages has similar tools (not all have LTS analogue, but big frameworks are the same). Yeah, a good library ecosystem is very important, and from the reports I see on this list it's not really good enough. The other issue is that Haskell's extensions make it more difficult to have library code interoperate. Though that's a trade-off: The freedom to add language features vs. full interoperability. Java opted for the other opposite: 100% code interoperability at the cost of a really annoying language evolution process, and that gave it a huge library ecosystem. But... I'm not going to make the Haskell developers' decisions. If they don't feel comfortable with reversing the whole culture and make interoperability trump everything else, then I'm not going to blame
Absolutely true 😊
On Sat, Jul 14, 2018 at 5:05 PM Paul