Hacker News new | past | comments | ask | show | jobs | submit login

> Haskell is great for business and great in production.

Hot take: no it isn't. It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely. I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell.

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.




Sounds like you've barely programmed in Haskell and don't know what you're talking about.

> It is extremely hard to learn

Haskell was the first language I learned. I didn't think this at all and I still don't. It doesn't strike me as any more difficult than learning Java or something.

You may think this because Haskell is a different paradigm than what you're used to, so while you may be able to get quickly started with Rust coming from a C++ background, Haskell will take more work because what you already know doesn't intersect with what you need to know quite as well. You may misconstrue this mismatch as Haskell being more difficult to learn.

> extremely confusing + needlessly complicated syntax

I think Haskell syntax is less confusing/complicated than many other language. Unlike a lot of other languages, Haskell doesn't have a lot of things baked-in. As an example, lot of oft-used functions are "user-space" functions that anyone could define themselves. Like `($)` or `otherwise`.

> 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.

This is such a stupid argument: what relevance is the opinion of boardroom meeting attendees on the suitability of Haskell for a project?

It sounds like you're hating on Haskell out of ignorance and some personal encounter with the language that went poorly. Instead of actually being informed.


I have taught both Haskell and Java and there is no comparision in difficulty. Teaching basically all of the Java language can be done in a couple of days (excepting generics, which take another day or two), and the language bugs are always "shallow".

Haskell on the other hand creates crazy errors which confuse students, and often require extensive teaching to understand what is going on.

I'm happy to accept the possibility expert Haskell programs will be more productive in the longer term, but the learning is MUCH harder.

For example, here's one "simple" haskell error:

Prelude> print 2 + 3

<interactive>:9:1: error: • No instance for (Num (IO ())) arising from a use of ‘+’

Now, it's not too hard to figure out what's gone wrong, but when doing beginning learning, explaining what (Num (IO ()))) is isn't something I want to be doing. No Java error gets that complicated.


That error message is easy to understand.

Explaining why a language can't handle print 2 + 3 is priceless.

It seems like an interesting language to learn for the sake of learning but introducing this to a beginner is not fair.


> I have taught both Haskell and Java and there is no comparision in difficulty.

Interesting. How much real world experience did you have with both languages before teaching it?


What kind of error would you like to see here instead ?


Maybe just one extra line like this?

    Prelude> print 2 + 3

    <interactive>:3:1: error:
        • No instance for (Num (IO ())) arising from a use of ‘+’
        • The expression `print 2` :: IO ()
        • In the expression: print 2 + 3
          In an equation for ‘it’: it = print 2 + 3
Just adding the one line telling telling you what was `IO ()` is helpful. ghci obviously knows what it was here.


This suggestion is a straightforward, easy to implement improvement. Many compilers have serious UX problems because their authors don't take UX seriously. Elm and Rust are two languages getting this right.


The Rust compiler does a great job of making suggestions for how you can fix your code, which is tremendously helpful for the majority of cases where your mistake was simple. There is no reason (in theory) that GHC can't offer the same level of guidance.


Counterpoint: learning your first language and learning languages later in your career are very different processes and learning Haskell with a background in OOP languages may be harder then learning it as your first.

> Arguments over programming languages often become emotional and skip past many of the practical business concerns that make programming languages valuable in the first place


> Sounds like you've barely programmed in Haskell and don't know what you're talking about.

You're right. I do not subject myself to Haskell because I can't fathom a world where JavaScript is less efficient than Haskell.


> I can't fathom a world where JavaScript is less efficient than Haskell.

You can't fathom a world where a compiler can more easily produce efficient machine code from a statically typed language with very few semantic corners than from a dynamically typed language with lots of sharp corners plus reflection? I think you may need to meditate on the task of compilation a for a bit.

Unless you mean efficient for the programmer, in which case you are mistaking the up front effort of getting things to type check for additional effort. Usually it spares you the same number of iterations in debugging and testing, and the type checker is a lot faster than running unit tests. Plus the first time you make a major refactor to a program by making the change and then fixing everywhere the type checker complains, and that turns out to be it, it all works, it feels like you just mutated into a superhero.


Efficient use of time I think the parent poster was referring to.

You could have the project finished quickier in Javascript. Would you disagree? Does choosing haskell increase development time (ignoring major rewrites)?


I'd say it depends heavily on what you're writing. If it involves graphics, Javascript is going to be substantially less annoying, at least initially. However, the version you write in Haskell will be much more reliable, and much easier to progressively refactor and scale up, whereas in JS, the weird edge cases and lack of static guarantees will gradually pile up and make the project a chore to maintain.

For something non graphics related that you're building by yourself, if you already know Haskell, it's a no brainer, due to the high expressivity ceiling. Once a team is involved, the right choice (as always) basically just depends on what people already know.


> You could have the project finished quickier in Javascript. Would you disagree?

That very much depends on the project (I have a lot of experience with Javascript, Typescript and Haskell).


maybe you shouldn't be spouting answers when you should be asking questions then


Then keep quiet.

I agree completely with @foopdoopfoop.


You can't do this here. We've had to ask you several times to follow the site guidelines. Would you please review https://news.ycombinator.com/newsguidelines.html and take the spirit of this site more to heart? Note the most important one: "Be kind." That doesn't vary depending on how annoying or wrong other comments are.


> Hot take: no it isn't.

Odd. I did some Haskell in prodution (hardware control and Unix daemons) and it was delightful.

> It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and I question the payoff immensely.

It is unfamiliar if you have only worked in the C family of languages. The syntax is quite similar to the rest of the ML family, which dates back to 1973. It's basically as old as C. I had the good fortunate of learning Standard ML around the same time as C, SQL, and Perl. Standard ML and SQL were by far the most straightforward to learn.

> 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.

Yes, you would, because why are you talking about programming languages in a boardroom? If you mean a more technical review committee, I wouldn't be so sure of that.


> The syntax is quite similar to the rest of the ML family, which dates back to 1973.

How close is it to say something Like F# then? I've toyed with F# a bit and was able to pick it up pretty decently, but a lot of Haskell still looks foreign to me


If you know F# you are going to feel a lot more comfortable than coming from say C/C++/C#.

The largest difference imo between F#/Ocaml and Haskell is the evaluation model where Haskell is lazy by default.


IMHO the largest difference is purity.

Not being able to mix IO and non-IO functions like this

    print “Enter name:”
    print (“Hello “ ++ readStdinLine ++ “!”)
in Haskell means you have to learn a new way of writing IO code.


Not really. You can mix them in Haskell too. Think of F# as Haskell except you are always working in the IO monad. Haskell doesn't require a "new way of writing IO code" at all. It just allows you to separate out the IO from the pure in a way that can be enforced by the compiler. But there is nothing preventing you from writing all Haskell code in the IO monad if you were so inclined - which is essentially OCaml/F#.


> Not really. You can mix them in Haskell too.

True, but it's not particularly syntactically convenient.


The entire point of monadic (do) syntax in Haskell is to make this convenient. I'm not following you exactly.


runeks mentioned

    print “Enter name:”
    print (“Hello “ ++ readStdinLine ++ “!”)
which can't be written like that with do notation. It's also pretty confusing code to write in any language, so maybe that's not a problem.


True, do notation does require you to add a line -

  main = do
      print "Enter name:"
      name <- getLine
      print ("Hello " ++ name ++ "!")
But I only said that it makes this convenient not that it allowed you to write any statement you want. It still makes it easy to intersperse pure and non-pure code.


The surface similarities between haskell and F# are fairly clear - emphasis on pure functions, no parens and commas for function calls, etc.

Alexis King wrote an interesting comment on one reason haskell can be difficult to pick up, which might be one cause of the foreignness you've noticed: https://www.reddit.com/r/haskell/comments/ddsvbk/you_are_alr...


Really close. :: between variable name and type instead of : and similarly superficial things. As the sibling comment pointed out, the semantics can take some time to wrap your brain around.


One of my colleagues was tasked (by me) to extend microcontroller model for new controllers, including new commands, different bus widths, etc. Models was written in Haskell and parametrized by different widths - program counter width, address space width, etc. As you can imagine, it was heavy on type-level code, has monads and hierarchy of type classes and had to produce C and Java code for different modeling tools.

Cooleague was not familiar with Haskell before, barely touched it. He also was recovering from hard divorce and, as he has said later, was not willing to work at all.

After a month he delivered changes needed, with tests and ready to use.

So my experiences (there are several others anecdotes) directly contradict what you say.

Now about RTS and language itself.

Haskell has threads greener than Erlang and/or Go. Go's thread stack size is 4K-8K, in Haskell it is about 1K-1.5K. It is possible in Haskell to have scheduler as a library http://hackage.haskell.org/package/meta-par for finer scheduling which is not possible with Erlang and Go.

So I question the well-being of anybody who subjects themselves to the pain and torture that is not Haskell.


Are you speaking from experience? The article is about the author’s experience from a year of using Haskell.

I don’t think it’s fair or constructive to disagree with his findings unless you also have experience using the language, and it doesn’t sound like that is the case.


So if somebody asserted that INTERCAL-72 is the proper language to use for production code, you would consider it unfair to contradict them until you've used INTERCAL in production code yourself?

Personally, I would not necessarily disbelieve somewhat propagating Haskell as a production ready language. However, I'm fairly confident that it would be thoroughly unsuited to any areas of work I regularly operate in.

I have tried a number of times to learn Haskell (from a variety of tutorials and text books). I find myself nodding along sympathetically at the fundamentals (functional purity, non-strict evaluation). I can follow the initial chapters. And somewhere between "Functor" and "Applicative", I tend to lose the plot.

Then I look at supposedly real world code like the URL shortener in Allen/Moronuki's "Haskell Programming from First Principles", and I just can't make heads or tails of it: https://github.com/bitemyapp/shawty-prime/blob/master/app/Ma...

   app :: R.Connection
       -> ScottyM ()
   app rConn = do
     get "/" $ do
       uri <- param "uri"
       let parsedUri :: Maybe URI
           parsedUri = parseURI (TL.unpack uri)
       case parsedUri of
         Just _  -> do
           shawty <- liftIO shortyGen
           let shorty = BC.pack shawty
               uri' = encodeUtf8 (TL.toStrict uri)
           resp <- liftIO (saveURI rConn shorty uri')
           html (shortyCreated resp shawty)
         Nothing -> text (shortyAintUri uri)
If that's supposed to be the way to write production code in the future, count me out!


What exactly is wrong with it? I've never even used the Scotty library or monad being used and I can understand it.


1. I have a vague idea what the second "do" is for. I don't have the slightest idea what the first "do" does.

2. I have some idea what "$" is, but I have no idea what it does in this context.

3. param "uri" is presumably extracting a parameter, presumably from the result of an incoming HTTP request. How is that request passed into "app"? How is it passed into the "get"? How is it passed to "param"?

4. Why does "parsedURI" need a type signature?

5. "Just/Nothing" more or less makes sense, but "Left/Right" (used outside the excerpt I quoted) is a notation that makes about as much sense to communicate meaning as "car/cdr" does in Lisp.

6. A response is generated. How does that response get back to the client?

7. What does liftIO do?

8. The overall syntax is just a pile of wrongness. There are left pointing arrows and right pointing arrows, which have completely different (and entirely non-symmetric) functions. There is an equals sign, which has a somewhat similar role to a left pointing arrow, but for some reason needs a completely different operator. There is a right pointing arrow in the function signature which is completely unrelated to the arrow in the case statement. There is an empty pair of parentheses doing Curry knows what. There are return values, which you can identify by following the peaks and valleys of the indentation.

So, TL;DR, this is an incomprehensible control and data flow, wrapped in an ugly syntax.


At the risk of proving your point (this part of the code is indeed a bit of a hash), but in the hope that this will help a little with learning, here are some answers:

1. The first do in your snippet does nothing - it's redundant. In the actual code you linked, though, it sequences the `get "/" ...` and the `get "/:short" ...` expressions into a single application initializer. When the app starts up (i.e. when `app` is called), this outer "do" runs through your endpoint-defining expressions and registers each endpoint in turn with the HTTP server.

2. That `get` function takes two arguments: the URI pattern and the action to run if the pattern matches. The whole rest of your snippet _is_ the second argument! Because of the low precedence of the "$" operator, using "$" means you don't have to enclose all that code in parentheses. It is a tiny bit of syntactic sugar that is wildly popular in Haskell-land because Heaven forfend any of your code ends up looking like LISP. ;-)

3. The answer is in the monad being used in this case to sequence these steps together (`ActionT Text IO <some return type>`). Think of `param "uri"` not as an expression returning a string, but a partially-constructed function that takes an HTTP request as an additional argument. The monad takes care of threading the request into this function when the request is actually handled, and `uri` will be bound to the resulting value.

4. I'm guessing it doesn't. Many type signatures in Haskell are optional, and are added if either 1) there's a genuine ambiguity in the code that needs to be clarified, 2) the author thinks it will make things clearer, or 3) the author hit a bug where the compiler inferred some crazy generic type that the author didn't intend or understand, and they put in some type signatures as sanity checks and constraints on what type is actually expected.


Thanks for your explanations! 2&4 make a lot of sense. 1, and even more so 3, lead to more questions than they answer, in my opinion. Monads appear to be an absolutely indispensible aspect of most substantial Haskell programs, but to me, they just look incomprehensible. I understand the advantages of a pure programming model for formal reasoning about programs, but in terms of communicating an intent with a program, I can't help thinking that the cure offered by Monads is far worse than the disease of mutable state.


The advantage of monads is that they whisk away a bunch of boring, repetitive boilerplate code that nobody wants to write and that people will even go so far in other languages as to create a bunch of global/thread-local/hidden-context variables to avoid writing!

The downside is that the abstraction and its applications, maybe a bit like pointers, do take a while to really master. Particularly when you start composing monad types to make other monads, as Scotty does with IO.


Look, I sympathize with you because Haskell is not easy to learn by any means so I understand someone not liking it. If I get time later I'll go item-by-item and explain. There's a lot of questions there but it's actually just a few fundamental concepts.

But I've seen engineers with only C/C++ experience get onboarded and write code with the same concepts & more complicated ones as the link shortener above. The key was onboarding by someone who knew Haskell well. Haskell companies need a culture of learning _and_ teaching to truly thrive and counteract downsides of the language like hiring pool and learning curve.


> I don't have the slightest idea what the first "do" does.

We know from the type signature that it returns a `ScottyM ()`, whatever that means. We don't know what that entails without having looked at the documentation. I don't think it's fair to criticize it on this basis, though, it seems basically the same as when you see an unfamiliar function in some python code and have to look up what it does.

However when we look at the docs: http://hackage.haskell.org/package/scotty-0.11.5/docs/Web-Sc...

There's literally no documentation for this type. Imo this is emblematic of a pretty dysfunctional culture in haskell of not bothering to document things properly.

By ctrl-f-ing "ScottyM" and looking around the page we can see that it's returned by the `get` and `post` functions, and get a vague idea that it's the type used to progressively build up a scotty web application. Then we see that the `scotty` function takes a `ScottyM ()` and returns an IO () that we can run as the main function of our program.

It can definitely be figured out, but the docs sure don't help much.

> this is an incomprehensible control and data flow, wrapped in an ugly syntax.

Parts of it are pretty bad, but I don't think the control flow being quite implicit here is actually much of a problem. Scotty is based heavily on Sinatra, a minimal ruby framework, and it kind of reminds me of Flask as well. In all of these, it falls to the programmer to decide what to return on a given route, and the sending back of the data is all handled implicitly and invisibly by the framework. So, I don't see this as an issue, and, if it is one, it isn't Haskell specific.


We can quickly find out that ScottyM is a Functor/Applicative/Monad though. And in this code (and using this library in general), that's all we need to know! FAM is a universal interface.


Knowing you can <$> <*> >>= doesn't mean you know what something does/what it's for though.


But it typically tells you how to compose such a thing, especially if it's 100% abstract to begin with (like Scotty.) It just becomes type Tetris.


As to the rest:

5. Completely agreed, especially since, semantically, it's almost always used as "Error/Success". Silly naming aside, though, it's extremely similar to Maybe, except that the failure case can contain a value (an error message, for example).

6. Think of your entire "action" (the second argument to get) as a function that takes a request and returns a response. Scotty takes care of invoking your action as necessary when a request comes in, and it also handles writing the response out for you.

7. liftIO takes an `IO String` computation as input, and transforms it into an `ActionT Text IO String` computation. This is done about the stupidest way possible: it returns an action that ignores the input request, generates a string, and "returns" it. liftIO is a heavily overloaded function that is defined for lots of monads that can easily incorporate IO computations, usually because they themselves are nothing more than dressed-up IO computations.

8. Yes, -> and <- are very different, and -> is overloaded. = and <- are very different because the latter relies on a monad to define how a value is extracted from the right-hand side and fed to the next part of the computation. The empty pair of parentheses is like void in C - a function with a return type of () doesn't return any value. In the case of our HTML actions, an action of type ActionT Text IO () may have a side effect of writing a lovely HTML response, but it doesn't produce a value like `param "uri"` does - it just does the side effect and it's done. Yes, indentation is important in Haskell, it's less regular (or you might say "more expressive") than in other languages, and in the code you linked it looks like it got jumbled somewhere along the way.


Could be a fun game. I'll guess. No haskell knowledge. PHP background.

1. Connect to remote connection. DO - wait..

2. $ Loop-over

3. It comes from a config file with a hardcoded value and is globally included

4. Because it could be reused to handle a different types.

6. Text is printing to standard output.

7. Creating and Repointing the response to the resp var


The only thing I see bad about that code is some bad variable naming, especially shorty/shawty, and possibly a couple bits of needless and unhelpful verbosity. Neither are inherent to Haskell.


> If that's supposed to be the way to write production code in the future, count me out!

Eh? Sorry but the code is really clear to me? Which parts do you find difficult to read?


This is roughly the same structure as the code you’d write in Python flask. There’s nothing unusual about it beyond Haskell’s syntax.


> It is extremely hard to learn

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.


> It is extremely hard to learn, has an extremely confusing + needlessly complicated syntax and

I agree with your other points but what's wrong with the syntax? I actually really like the syntax for the most part


I've been using Haskell on and off for almost ten years, and the "front end" of the language, including its syntax, is pretty much the only thing that I absolutely hate about it.

The endless operators, all the language extensions required in 2019, the madness called Template Haskell, the absurdity of point free style, the multiple ways of achieving things by cleverly using . and $, the uncanny valley of do-notation (why does it look different? F# gets it right). It's too easy to be clever. It's too easy to take shortcuts that the next person won't understand.

I'm completely fine with the underlying semantics! Lazy evaluation, the majestic typechecker, concepts like monads, functors, lenses. Even when it comes to syntax, I love how functions are declared, the way parenthesis work, currying, all the "simple stuff". I adore all those concepts and apply them to other languages. I long for a Haskell-like language without the stuff I mentioned above.

I think the problem is that in Haskell everything feels like an afterthought, everything feels "bolt on" rather than "built in". 99% of the hot stuff is implemented using libraries. That's similar to Lisp and C++, other languages I hate (I also love Lisp parens, but I hate macros). Now that I think about it, I prefer less extensible languages that require adding code to the compiler to extend it: C#, F#, Go, JavaScript.


If you can have better solution to the problem at hand with the library, you will solve it faster. Turnaround time for library is much less than for a compiler.

So if language provides a way to solve something with a library instead of compiler, it provides a way for faster path to solution.


>but what's wrong with the syntax?

I'll just link to this blog about readable Haskell. If everyone followed his advise, it would be much better.

http://www.haskellforall.com/2015/09/how-to-make-your-haskel...


Thanks. That's a good blog. The $ operator is definitely confusing in Haskell. F# uses <| to indicate a backward pipe, which I find much more intuitive. For example:

    print <| even <| 4 * 2
This means: Take the result of 4 * 2 and send it to `even`, then take that result and send it to `print`. Or you can write it with forward pipes to make it even clearer:

    4 * 2 |> even |> print
The thing about backward pipes is that they're often used to avoid parentheses, which is IMHO a good idea. It's just that thinking of them as "function application" is confusing. F#'s operators makes the data flow clear.

[Side note: The mathematical symbol for function composition is the circle operator, ∘, which is also confusing for the same reason. Does (g ∘ f)(x) mean g(f(x)) or f(g(x))? Personally, I can never remember. If math used F#'s >> and << composition operators instead, there'd be no doubt that f >> g sends the output of f to g, so (f >> g)(x) means g(f(x)).]


> The $ operator is definitely confusing in Haskell

I generally think of it as a sort of open-ended parentheses that encloses the rest of the line. Instead of a backward pipe. It means "evaluate everything after this character first then apply the preceding function to it" just like parentheses would.

    print $ even $ 4 * 2
is equivalent to

    print ( even ( 4 * 2 ))


You're right, and that's why it's usually called "function application" instead of "backward pipe". However, using $ as an operator is confusing because the associativity is ambiguous if you're not already comfortable with it.


> Does (g ∘ f)(x) mean g(f(x)) or f(g(x))?

The function composition operator can be vocalized as, in this case, "g after f". That is, apply the f and then g. Translating '∘' into 'after' is the easiest way to understand it.


Alternatively, I learnt it as "of" (from a mathematical standpoint). "(g ∘ f)(x) " is "g of f of x", so g(f(x))


Haskell provides the (g . f) notation as the standard, and also has (f >>> g) notation buried in one of its more advanced libraries if anyone finds the right-to-left reading too disorienting.


I don't see the above better than

    print(even(4*2))


Yeah, that's a small example, so it's fine either way. But larger examples with lots of parentheses can be overwhelming (see: Lisp).


Note that this is to make Haskell more readable to non-Haskell programmers (which is a bit of a weird goal IMO). It is not for readable Haskell in general. Advice like "not using $" just makes code less readable if you're familiar with Haskell and is quite frankly just bizarre. I do not think you'll find many programmers, Haskell or otherwise, who find lots of nested parenthesis to be the paragon of readability.¹

If the goal is to show snippets of cool Haskell code to other people this article is… fine I guess? But I don't think it's good for much more. Not even for teaching Haskell, since people should probably learn the language as it is used instead of some arbitrary "more readable to non-Haskell programmers" version. Using do-notation is probably even counterproductive for teaching since it obscures what's actually going on.

Honestly this sentiment from the Haskell community that Haskell is somehow bizarre and impenetrable to outsiders and needs to be somehow watered down so that normal people can understand it just feels extremely elitist and if anything only scares people away from Haskell.

¹ Lisp programmers aside, but even then in Lisp you're basically just drawing a tree and so the parenthesis kind of fade away, but in languages with infix syntax and operator precedence you can't ignore them.


>Note that this is to make Haskell more readable to non-Haskell programmers (which is a bit of a weird goal IMO). It is not for readable Haskell in general. Advice like "not using $" just makes code less readable if you're familiar with Haskell and is quite frankly just bizarre

This is why no one likes Haskell programmers and why the community just sucks.

You're telling me that it's _more difficult_ for a Haskell programmer to understand parentheses than for a non-haskell programmer to understand functors?

I can't think of a single haskell programmer that doesn't also know at least 2 C-style languages.

Meanwhile, there are many C-style programmers that don't know Haskell at all.

If the goal is to remain an impenetrable fortress / secluded monastery, the Haskell community is a safe bet for the Benedict Option[1]. But if the goal is to become popular and get others to understand the benefits of Haskell, it seems to be a culture problem within Haskell, more than anything else.

[1]: https://www.amazon.com/Benedict-Option-Strategy-Christians-P...


> This is why no one likes Haskell programmers and why the community just sucks.

I like most Haskell programmers and I don't think the community sucks more than any other language community. So I guess that proves that assertion wrong.

> If the goal is to remain an impenetrable fortress / secluded monastery

I am pretty sure there is no such goal :D

> if the goal is to become popular and get others to understand the benefits of Haskell

I am pretty sure that is a goal for some Haskell people and not for others. For me personally I had a lot of fun learning Haskell. It taught me to become a better developer in any programming language.


> Honestly this sentiment from the Haskell community that Haskell is somehow bizarre and impenetrable to outsiders

They’re not inventing that from thin air. I can understand Haskell with a great deal of effort, but it certainly requires a great deal of effort.

My wife is a non-programmer. She knows nothing about code. I could explain what the go code I write does in a few minutes and she could follow it with a minimum of hand waving. I don’t think I could explain any non trivial Haskell code in hours to even professional programmers


I have explained Haskell code in a few minuts to professional programmers and they got it. It took a bit longer to explain monads but it wasn't hours.


I have tried to teach C# to a smart non-programmers friend. That was really really hard. The idea of OO/classes just blew his mind.


I'd quibble with this, but that's probably largely because I used Hudak's "Haskell School of Expression" book as my road into Haskell, which seems to generally aim for readability at the expense of making everything into a monad. I gather it would be considered a bit of an outdated style now, but in retrospect I think it eased me into the pool.


> Honestly this sentiment from the Haskell community that Haskell is somehow bizarre and impenetrable to outsiders and needs to be somehow watered down so that normal people can understand it just feels extremely elitist and if anything only scares people away from Haskell.

What? The thread we're in is descended from a post about how terrible the syntax is!


Awesome advice! Thank you for the link.

Sadly, the author of “Haskell in production” breaks many of the rules in part 2 and code reads like ascii-art :(


Most people that have worked as developers/programmers/etc. that don't have a lot of exposure to or training in fp find it painfully hard to learn. This could be one of those cases.


To them, I would suggest that they remember back to when they learned their first imperative language like Java or C. For me, that was really difficult to wrap my mind around at the time, but now those languages are second nature to me. I kind of suspect that if everyone were exposed to a functional language first, there would be a lot fewer people who think they are extremely hard to learn.


I fondly remember being confused by “return” for weeks (granted, I was 9). What are you returning? And to where? And why was it only one thing? And where did it go when it got there?

It’s easy to forget how hard something was to learn once you already know it.


I remember when I started with Java at University.

Like, "hello, what is a method? What the hell is a class? Come on, stop kidding me, objects have methods???? How do I call them? Wait, how do I _write_ a method?"


What I kept bouncing off of was all the stupid as shit "sally sends a BUY message to Tommy's bagel shop" crap. I just needed about two to four pages worth of text & diagrams demonstrating how objects and structs are pretty much the same thing, and what the OO sugar inheritance and keywords and dynamic dispatch and such do under the hood, which ain't that complicated. Every single book I picked up (back in the '90s, when if you didn't know someone to personally recommend a book it was much harder to figure out which ones were decent and which sucked) wanted to use those awful, cutesy analogies to introduce OO and they just confused the hell out of me, and convinced me something dead-simple was hard.


There are many reasons Haskell is difficult to learn, and the functional programming aspects are only part of it. I'd venture a guess that it's vastly easier to go from say, python to clojure, than from python to haskell. Even neglecting clojure's impure escape hatches.


If you are learning something new and it isn't hard to learn then you are not learning anything truly new. Just variations/flavours of what you already know. If it is really hard then you are truly learning something new. No pain no gain.


Haskell syntax is great except for the indentation/layout rules. There is no simple definition of the grammar with regards to the layout. It's only specified as a headache-inducting operation of a state machine [1], and the implementation is quite hard to read. This is fine for writing Haskell, but quite painful if you want to parse it.

[1]https://www.haskell.org/onlinereport/haskell2010/haskellch10...


I'm not the OP but I would agree and my problem with the syntax is the number of symbols that don't make the semantics clear at all. The Lens library for example, but also a lot of standard stuff like the bind operator, it's extremely complex. Many people also seem to go overboard on the dot notation which can be very hard to read.


++ >> >>> >>= `concat` .


Hard disagree on the syntax. ML languages to me have the best syntax and their ease of currying is extremely attractive.


Syntax is the absolute best thing about Haskell and it's ML relatives, especially coming from C++ and Java as I did. It's succinct and very easy to read, without braces, parens and type annotations scattered everywhere. For example, defining a function is as simple as "let f x = ..x.."

The succinctness of Haskell really matters when dealing with non-trial code or types. Just compare the type signtaure of "SelectMany" in C# to an equivalent in Haskell.


"Complicated" and "weird syntax" are pretty subjective measures to define how good a programming language is. C++ is weird and complicated to me.


> I question the well-being of anybody who subjects themselves to the pain and torture that is Haskell.

I question the well-being of anybody who refuse to learn anything that is hard to learn. Learning is like body building. No pain no gain.


That's a really strong opinion to present with absolutely no evidence.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: