> Up to a certain point of course. As I pass about 1000 lines of code I start feeling a bit uncomfortable about the lack of static type checking to catch my changes.
This is indeed where statically typed languages come in to shine - refactoring and maintenance. With a powerful type system you can be much more assured that your refactors or small/big changes here and there don't break the whole system or unexercised parts of it.
> It requires far more investment than other languages to learn and I've learned plenty. Nothing has required as much effort as Haskell. Despite the effort I never felt like I could write any real and practical programs with it.
That's often attributed to the fact that Haskell isn't just another syntax slapped on an Algol-like language. It's not just different syntax (ML-style), but an entirely different approach to programming. This often leaves experienced programmers frustrated with the experience that they are starting from scratch (without realising that, that is what they are doing).
> I honestly think the Haskell fan club is slightly deluded. If Haskell was truly as amazing as they think, we ought to have seen a lot more amazing software being made in Haskell
We have a lot of amazing software in Haskell already, e.g. Facebooks Haxl, Pandoc, QuickCheck, Yesod, Servant and many more.
The argument that Haskell isn't doing stuff right because we don't see it everywhere is quite silly. By that metric PHP would be the best designed language ever...
> True but run of the mill languages like this always tend to culminate in codebases that are hard to maintain and necessitates an eventual rewrite due to accumulation of complexity.
I'm reluctant to believe that Haskell magically protects you from that, but let's suppose it was true. What if my run-of-the-mill gang can rewrite the project three times over before your wizards have congregated to sing their first incantation?
> Haskell is hard to learn and hard to find developers for, but the trade off is incredible safety and a type system that promotes good design and easy refactoring of inevitable design flaws.
Again, I'm reluctant to buy into that. Even if that was true, unless you're writing Haskell in a vacuum, you're going to have to interface with various other horrible pieces of technology that will throw a wrench into your beautiful pure design.
Dealing with the ugly bits while maintaining composure is what makes the difference between a really good engineer and somebody who just wants to program. That quality is invaluable, but you're likely not going to develop it by programming in a language that you enjoy.
> The problem, however, is that its such a departure from imperative languages that you can't bring much of anything you already know over to it.
I don't find that really true; if you've used any structured language with static typing, there's a lot of carryover, especially if you've ever done any formal study of CS, since even when imperative languages are used functional patterns are pretty common.
The biggest problem I see is that there isn't a lot of pragmatic guidance on the bits that are unique to Haskell -- a lot of the documentation is very abstract, without a lot of guidance on solving specific real world problems. The power of Haskell is that you can make very general solutions in it quite easily; the weakness of the documentation of Haskell is that virtually all of it focusses on that highly general facilities and not enough on the kind of specifics that would help people get familiar with it while solving real problems.
> My problem with Haskell is that it is not pragmatic and the reason I stopped using it.
I find it extremely pragmatic, but perhaps not in the way most people use the word. It's pragmatic about the abilities of programmers to get everysingle detail right all of the time, i.e. it discards that notion entirely. We will not get things right enough of the time and so the language must support and help you. This goes all the way from simple static typing to enforcing Purity of Essence, I mean, Functions.
If you don't care about managing side effects you can always just write everything in IO and slap a "pure" here or there. Haskell's actually also a pretty good imperative programming language, IME.
> I have tried to learn Haskell a few times, always unsuccessfully
I suspect that people wanting to learn Haskell actually want to learn a statically typed functional programming language. And if you also want that language suitable to everyday problems, the kind of things you are dealing with at work, then Haskell is probably not the best one to start with.
I love how Scott Wlaschin presents statically typed functional programming languages as straightforward and pragmatic solutions to everyday problems:
Once you're comfortable with that (and the way it is presented here really isn't very complex) then Haskell becomes a lot easier to understand.
But Haskell is very distracting because it is much more expressive and complex than than ML dialects for example, so it will be a big learning curve before someone is comfortable reading someone else's Haskell code. For other statically typed functional programming languages (f.i. OCaml/ReasonML, F#, Elm) that is not the case.
> On the other hand, sometimes people get the idea that Haskell can encode everything in types. It can't. They get stuck and get into messes. Nonetheless the ability to encode some things into types makes Haskell by far the most practical language I've used.
It's not even that, I'll assume that the majority of Haskell novices are aware that there are humble limits to the expressiveness of most (including Haskell's) type systems.
The real problem IMHO is the dichotomy that this approach entails. You have to decide which language to use to model a concept (type language or run time language), and if the idea of what you want to do changes a little, chances are you can't continue on your current path.
In other words, I think the type system approach prevents a lot of the fluidity that I want from a programming language as a tool to get things done.
I picked up Haskell while still getting my degree on my own. My only training was in C. Payoff was huge within a couple months of starting (didn't even finish LYAH), especially when writing concurrent programs.
> I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell.
Haskell is so effortless once you get over the learning curve though. I've used less effort & focus programming professionally in Haskell than I ever did in other languages. The types & way programs are structured make so many tasks 100% mechanical, with your only thought being where to direct the mechanics.
> If I stood up in a corporate business boardroom meeting for tech analysis on a new project and said "I want to write it in Haskell", I'd get laughed + kicked out.
Don't care about those people's opinions in the first place. Never will :) Should be viable for me to write professional software for years to come in Haskell.
> The problem with Haskell is its syntax. Too many arbitrary and traditionless things to memorize. It's curious that the Haskell developers try to one-up the rest of the language space in nearly every other space, but choose such a weird and unhelpful syntax.
I've seen this criticism before, and I don't understand it. The syntax of Haskell is not that big. There are some things a bit funky about it, especially the indent rules, but I don't see what there is to be mystified about.
On the other hand, it does introduce a lot of mind-bending concepts if your background includes imperative programming and no category theory, and that's typically what people find hard to grok. You don't find a pile of "Haskell syntax cheatsheets", you find a bunch of monad tutorials instead.
> I get answers about idempotence and list comprehension and strong typing which are great tactics but I never get the sense that they fit into an overarching strategy for how my life will be made easier by using Haskell.
First, I suppose those three things fit together in the sense that they make list comprehensions safe and fast.
But as you say, Haskell isn't the only language that gives you that.
I think the killer feature of haskell is that the community went through ridiculous contortions and pain to get rid of side effects.
Which means that Haskell programs exclude certain kinds of bugs - so it's not just that you can program in a functional style, but that you can be fairly certain there's no "shifting sands" under your functions.
On the other hand, I see many haskell programmers say that the powerful type checker forces them to think a bit differently, and perhaps harder, when writing - with the result that once the type signature fits, the function tends to "just work".
Anyway, I never did really enjoy Haskell - not as much as StandardML anyway. Sadly there doesn't seem to be any sml with good real-world libraries, so I've not really been using that either, outside of university :/
Perhaps looking at one of the few popular haskell utilities, and see if you feel Haskell is a good fit? I'm honestly not certain myself.
> Why then do you think at a certain point they start hurting
Oh, it's just a guess, but partly because of Haskell and its success at being continuously rejected by the industry for two decades now (it was touted as the next big thing when I was at university over 15 years ago). There have been few if any languages of Haskell fame that have clearly tried to break out of academia and have had so little use in the industry.
And the problem is less with types themselves but with the referential-transparency-everywhere and non-strict-evaluation approach. The result is that Haskell allows -- nay, demands -- a lot of reasoning about the program upfront at the expense of reasoning about it as it runs, with a debugger and a profiler (because of the complicated execution model). I also think Haskell places an unreasonable burden of thinking about the types vs. the algorithm an domain.
As to Scala, because it's such a "multi-paradigm" language, it's pretty hard to know exactly how it's used in the industry. There are certainly those that use it anywhere between Haskell-like with scalaz to Java-like only without having to write constructors and getters (in fact, Spark is written, I believe, closer in the latter style). But even if Scala is to be counted as an advocate for rich typing, its success record is pretty spotty (and, again, I wouldn't blame that necessarily on the type system).
I could, of course, be very wrong. One thing is certain: what a type system can do is a comp-sci question; how useful it is is a psychological question, and trying to argue about the usefulness of type systems (or any programming approach) as if it were a mathematical problem is just silly.
> We've certainly never reached that "certain point" where they start hurting.
I think Haskell is beyond that point, although I still believe a language with a type system as sophisticated as Haskell's might not be (because getting more for the same price might be worth it). By that I mean that Haskell types -- just like the article said -- waste a lot of mental power in the wrong places (i.e. on proving trivial stuff). I don't know what that imagined language would look like, but it would probably have some effect types (and like the author of the article has noted, there's a huge difference between being able to simulate effect systems and effect systems controlling actual effects).
> you can just start writing in a declarative style and not worry about debugging, because everything is checked by the type system
That is dangerously close to the infamous "if it compiles, then it works" boast, which Haskellers make all the time (while denying that they make it), demonstrating in the process that they don't write real software, where the defects one encounters are very often of a nature such that the program behaves exactly as intended by its authors, but the intended behavior is itself wrong. How does the type system help here?
My comment wasn't glib. I actually think those phenomena quite well explain much Haskell advocacy. Considering how massive an undertaking it is to learn the language and its Byzantinely-complex, PhD-theses-in-disguise libraries (each of which sports a zoo of custom operators) and how small the payoff is, it's unsurprising that those who take the plunge begin zealously encouraging others to do the same, lest their own investment have been for nothing. In a way it's like a conspiracy.
>My impression of the Haskell community is its full of snobbery and complaining.
Probably because the Haskell community is used to having a programming language that is, in and of itself, very good. They complain because they know what they're missing when they have to use inferior tools.
>Develop an imagination. Javascript can be wielded very effectively. It's just different.
The same can be said of x86 assembly. That doesn't mean we don't complain about programming in it, and we don't try to find better alternatives. The entire field of programming language development is about finding tools that are better than the old ones, even if the old ones work OK.
>The disadvantages are alleviated by comprehensive functional or black box testing.
If you think "more testing" alleviates all the problems of weakly typed languages, you have no idea what you're missing.
>I feel liberated by not having a strong type system restricting my options.
If you feel restricted by a type system, you're using it wrong. A type system is a useful tool, not an impediment. It only prevents you from doing wrong things.
"I like assembly because it lets me do any operation on anything."
> What this means is that you spent most of your time thinking about how to express your code elegantly in the type system, but once you do it usually just works.
Yes. And I'd suggest that Haskell is one of the more flexible and expressive languages, just in general. If you want to write C-style or Rust unsafe {} code, you can, and it's not even much uglier than C, and it compiles down to C-like speed.
If you want some absurdly abstract approach, you can do that, too. The type system, particularly type classes, encourage the reuse of algorithms and data structures. So if you provide the necessary functions to treat your data structure as a list, then everything that can work on lists (or more abstract list-like things) automatically works on your data structure. Same for trees and graphs and etc. It is very satisfying when that happens and you don't even have to write any algorithms because it's all in the libraries already and derived automatically for you.
But you'll be doing very little typing until you see how, if you ever do. I often despair at expressing something at all, let alone elegantly, in Haskell. It's also very normal for Haskell users to implement mini-languages and domain-specific languages, and the language is very well-suited to that. And IMO a DSL is in fact an appropriate tool for many problems. The downside is that it's also very easy to shoot yourself in the foot that way, and produce some weird cant only you can speak.
>>So many people spend so much time learning the ins and outs of JS, which often find use only in JS, yet balk at learning the simplest things about Haskell.
If the lenses for records thing in Haskell is amongst the simplest things for you, I beg to differ. I spent considerable time trying to get this working but could not succeed beyond toyish examples. Combine lenses/records with exceptions, applicatives, monads and monad-transformers as they become necessary once you try to expand your toy-example code and the Haskell thing becomes anything but simplest.
Yet, other languages support records flawlessly and almost out of the box.
The heavy and unnecessary usage of symbols, like, >>, <<, >>=, >=>, <=<, and so on just adds cognitive overload and gives no inherent benefit but most of the Haskell library code is littered with it and due to almost arbitrary overloading of these symbols to mean different things in different contexts (libraries) just adds more cognitive overhead without any benefit. The almost cult-like insistence on the excessive usage of meaningless-to-humans symbols reminds me of the great practical programming language known as brainfuck [1]. Sorry but no sarcasm intended. Some Haskellers harp on succinctness, when talked about this religious fetish for symbolism in Haskell. So I ask, such succinctness at what cost?
The excessive and obsessive usage of symbols may give mental kicks to the hardcore Haskellers out there, but sorry, I don't see any incentive to waste my time trying to wade through the gobble-de-gook of brainfuck type code.
So sadly, Haskell and me are not a match. Maybe some most common things in other languages when tried in Haskell seem to be (are) rocket-science (e.g. lenses for records) and/or maybe I am a daft blockhead, but that's so.
> Clearly static typing isn't some magic pixie dust that all of a sudden makes all your code work correctly.
Static typing itself - no. What is important about Haskell is the equational reasoning (algebraic thinking, if you will) you can do, not static typing. Static typing is just a vehicle to be able to pull it off.
There is a payoff already - see my comment to Lisp guy above. We could also talk about how monads made LINQ great, or how streams in Java have to be more complicated than necessary because the language wasn't very well formally defined.
And there will be bigger payoff in the future, when we will learn for example how to type a whole big software component correctly (like a web service). So far, it's an art driven by engineering intuition; but formalization will help to make more robust systems.
The payoff is also assumed based on experience with other branches of mathematics (as I was alluding in my first comment), where historically, the formalization always paid off. It doesn't mean you cannot get things right informally, but it's usually fiendishly difficult.
> As someone who really likes Haskell, I've found the response to the talk from Haskellers, like in that thread, really disappointing. The common refrains indicating that Rich doesn't understand Haskell, types, etc. are patronizing and likely incorrect. (I realize he's trying to hit a few targets, from C++ to Java to Haskell in one go, so it's not always clear which he's complaining about.)
I can see why you would feel that, if you hadn't seen Hickey's talk, being having seen it he was honestly quite patronising himself towards static typing, so no wonder he would risk getting some of the same tone back. That said, I don't think it is far off to say he doesn't understand Haskell, either that or he deliberately ignores the solutions that Haskell offer to the problems he's complaining about. Also, one commenter from the thread mentioned,
I do know from interviews that he's done (MS Channel9, i think it was) that he has at least a passing familiarity with Haskell as of 5-10 years ago, but that's a completely different beast to what exists now
Including he himself mainly focusing on having been a C++ programmer.
> underestimate how little reach the type system has in an open system where data's flying around arbitrary services
There are certainly times when dynamic programming is nice and all, but I feel your statement is quite disproven with e.g. something like Haxl and Facebooks spam filter, which is an incredibly large scale open system, unless we have some different definition of that.
Finally, I agree Haskell and the like are not panaceas, but when a person goes out with incorrect/invalid points talking down about the effectiveness of a system, when in fact the users of it would agree it is highly effective, I feel like it does no benefit to the community to simply let it stand just because the person speaking is someone kinda famous.
> The line that if it compiles, it’s probably correct is often true.
That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide.
And while that's still not a great fleshed out explanation, it's a great oversimplification of the symptoms of a programming language with a great type system. And that type system is more or less the only reason to use Haskell.
As other people in this thread have commented, Haskell has fantastic abstract libraries, which let you do abstract things, the most useful of which that I'm aware of/understand is parsing. Parser combinators are a very natural fit for Haskell, and making DSLs with them becomes practically trivial to do.
Edit: I think the author takes for granted the general praise that Haskell gets, and was attempting to temper it with his practical experiences using the language.
> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development.
the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java / C++ is in school where they have an assignment due for tonight and the compiler won't stop banging pages of errors about std::__1::basic_string<char, std::__1::allocator<char>> and what the fuck is that shit I just want to make games !!11!1!
In contrast Haskell is often self-taught which gives a very different set of incentives and motivations.
As a mostly C++ programmer making sure that I get compiler errors as often as possible by encoding most preconditions in the type system is one of the most important part of my job and make the language very easy to use when you use an IDE which allows to click on an error and going to the right place in the code.
> Still, I wish I could see more info on this. At what point does the additional cognitive burden of advanced type system features become a worthwhile tradeoff for program correctness?
As a professional Haskell programmer, I find the cognitive burden to be lower in Haskell than in, say, Java, where I have to do a lot more bookkeeping about design patterns and how they're glued together than in standardish Haskell where compositional forms fall into a compact set of powerful concepts amenable to reasoning.
I say standardish Haskell because the sweet spot in my experience is a few lightweight GHC extensions but mostly shunning some of the seriously experimental stuff in the language. For example, i agree with your doubt when it comes to dependent types and in particular singletons, a halfway house implementation that can be used in Haskell today.
Some of my coworkers had unsuccessfully attempted to write mobile games in Haskell. That was 10 or so years ago and many of the technical hurdles that impeded them then are no longer there.
The only major one I know of at the moment that prevents Haskell from being used in a AAA game engine is a guaranteed low latency garbage collector. I expect someone to implement such a thing for Haskell in the next 10 years.
The space is moving fast, our understanding of how to write big Haskell apps has advanced drastically since when I first started using the language! I expect big things to come in the next couple of years.
This is not to say that the space is getting rewritten all the time, it's just that more useful concepts are being discovered and matured. For example, Applicative only 11 years ago and scalable FRP like 4 years ago or so.
I should say what type concepts compose my compact tool set:
* higher order functions with syntax optimized for using them.
* algebraic data types (sparingly generalized algebraic data types)
* type classes + higher kinds (The synergy is far greater than the individual features)
* monad transformers (the promise of aspect oriented programming actually realized)
> If you don’t like Haskell, that’s fine. You don’t have to.
That's the problem: I do like most parts of Haskell! It's a language I really want to use more often, as many parts of it are miles beyond most other languages. Just the fact that it has proper first-class support for tagged unions makes programming an absolute joy.
All the "introduction to Haskell"-level stuff made me fall in love with the language, and I basically wanted to rewrite all my code into Haskell. But then I started trying to actually write production-level code and engage with the larger ecosystem, and I basically drowned into a marsh of incomprehensible language extensions which were somehow required for pretty much every single library - and more than once I ran into severe project-breaking design limitations only after investing dozens of hours into the library.
There are plenty of languages I really can't give a rat's arse about, but I like Haskell too much to just ignore it. To me Haskell is the one that got away, and I am eagerly waiting for someone - like this project - to essentially create a "Haskell for programmers".
This is indeed where statically typed languages come in to shine - refactoring and maintenance. With a powerful type system you can be much more assured that your refactors or small/big changes here and there don't break the whole system or unexercised parts of it.
> It requires far more investment than other languages to learn and I've learned plenty. Nothing has required as much effort as Haskell. Despite the effort I never felt like I could write any real and practical programs with it.
That's often attributed to the fact that Haskell isn't just another syntax slapped on an Algol-like language. It's not just different syntax (ML-style), but an entirely different approach to programming. This often leaves experienced programmers frustrated with the experience that they are starting from scratch (without realising that, that is what they are doing).
Some nice advice is giving by Gabriel Gonzales here http://www.haskellforall.com/2017/10/advice-for-haskell-begi....
> I honestly think the Haskell fan club is slightly deluded. If Haskell was truly as amazing as they think, we ought to have seen a lot more amazing software being made in Haskell
We have a lot of amazing software in Haskell already, e.g. Facebooks Haxl, Pandoc, QuickCheck, Yesod, Servant and many more.
The argument that Haskell isn't doing stuff right because we don't see it everywhere is quite silly. By that metric PHP would be the best designed language ever...
reply