Haskell is a Bad Programming Language (2020)

https://blog.shitiomatic.tech/post/haskell-is-a-bad-programming-language/#👾

by fpoling • 6 years ago

340 307 6 years ago

blog.shitiomatic.tech

smlckz2• 6 years ago

Maybe Haskell is bad from practical perspective, but not from theoritical. So it has a strong appeal towards academics and purists.

smcl3• 6 years ago

Yeah this article was bizarre for me to read. My understanding is that Haskell doesn't aim to be big and popular (as Rust and Go have as a nice counterexample) its intended use is in academia by CS researchers, and its users seem to be quite satisfied with it. The fact that it gets any sort of traction at all outside this suggests that it's actually exceeded expectations of its success.

It is as if Haskell doesn’t want “normal” people to understand it

Well, yeah kind of. I don't think it's as hostile as that though, the language isn't actively against "normal" people (I guess, that means your common or garden OOP programmer) it just doesn't actively court them.

The comments about how the community treat newcomers are quite interesting though and if they are true then that's pretty shitty behaviour. It's one thing if the language isn't aimed at a given demographic of programmers, but it's another thing for people to use it as an excuse to beat down and berate others.

Typhon• 6 years ago

The one valid definition of success for a programming language is that it looks pretty and thus the most successful programming language is Piet ( http://www.dangermouse.net/esoteric/piet.html )

I mean, joking aside, it's always fascinating when people can't wrap their minds around the idea that their criteria for success or quality or goodness are subjective and not universal.

Blikkentrekker8• 6 years ago

I know many academics that exclusively use Haskell or even Idris and Agda which are even more obscure but more correct.

Agda is so “correct” that the language is total and not Turing complete with the exception of a “partiality monad” that allows for partial and Turing complete computations — similarly to how Haskell isolates effects on the world from the main language and encapsulates them into a special type, Agda isolates partial computations.

And this language is very much used within specific academic fields.

madog• 6 years ago

I definitely agree with the documentation side of things, particularly lack of concrete examples.

I found that overall however, learning Haskell made me a better programmer, even if it's more useful as more of an academic than practical language.

Dealing with pure functions, no access to loops so recursion is paramount and it is rather beautiful and useful some of the tail recursion and pattern matching stuff.

The Haskell quicksort is the classic example of this:

  quicksort [] = []
  quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
    where
        lesser = filter (< p) xs
        greater = filter (>= p) xs

leereeves• 6 years ago

That is quite elegant for that variant, which is a great fit for Haskell's features. How easy is it to write a different variant, like using a different pivot, or sorting in place?

seppel2• 6 years ago

The Haskell quicksort is the classic example of this:

The Haskell quicksort is also classic example of something that is small, beautiful and still misses the point. Yes, it contains the core idea of quicksort (partion the list and divide and conquer) but it completely fails on the quick part, because the Haskell lists are are leaky abstraction of real computer memory.

A real quicksort in Haskell is much more convoluted.

hashingroll• 6 years ago

What's a real quicksort anyway? You could argue that a reasonably fast implementation of quicksort is much more convoluted, which it most certainly is, but that doesn't make this implementation any less real.

n4r92• 6 years ago

Sounds like a hardware issue.

gspr• 6 years ago

I found that overall however, learning Haskell made me a better programmer,

I definitely had that experience, too!

mcintyre1994• 6 years ago

It's worth noting though that in-place quicksort really doesn't play to Haskell's strengths - there are some examples of the code for it here: https://stackoverflow.com/questions/7717691/why-is-the-minim...

Blikkentrekker8• 6 years ago

One cann do this in Python, or any other language for that matter:

  def quicksort ( xs ):
   if len(list) == 0:
    return []
   else:
    less = [x for x in xs[1:] if x <= xs[0]]
    more = [x for x in xs[1:] if x >  xs[0]]
    return less + [xs[0]] + more

Not the most efficient implementation in either.

wheybags• 6 years ago

And IMO, that python version is one million % more readable. In particular, because you defined more and less before using them, vs after in the Haskell example. I don't know if there's a way that could be achieved in Haskell too though.

Edit: you forgot the recursive calls though.

n4r92• 6 years ago

True, although you forgot the recursion. The Haskell filter expression is much nicer as well. You could perhaps be terser by using ternary conditionals:

  def quicksort ( xs ):
   return [] if len(list) == 0 else quicksort([x for x in xs[1:] if x <= xs[0]]) + xs[0] + quicksort([x for x in xs[1:] if x > xs[0]])

lawn• 6 years ago

I found that overall however, learning Haskell made me a better programmer

I had the same experience, but with ML. It almost feels like Haskell with the annoying parts removed.

useerup• 6 years ago

Quicksort in one line:

    Quicksort = { []->[], [p,,m]->this(m??<p) + (m??==p) + this(m??>p) }

malthejorgensen• 6 years ago

Given the opinion expressed in this blog post I wonder how the author intends to process data that they don’t know the type of :P

Yes, Haskell is born out of academia. That’s where its strengths come from but also its weaknesses. Many new languages and language features are directly inspired by Haskell’s strong typing and type safety and the world of programming languages is better for it.

I do question whether Haskell will ever be ready for mainstream - probably not. But hopefully some other more practical ML derivative will gain enough momentum to truly become mainstream. Arguably Scala is that language, but Scala feels the C++ of ML-derivatives - the language is too big and the syntax irks me.

prohobo• 6 years ago

One heuristic for the quality of a language is to literally ask "what is it good for?"

Just off the top of my head (I'm skipping a lot of categories and languages):

C/C++/Rust are great for systems programming, games, and performance critical applications.

Go/JS/Python are great for creating web servers, data processing (Python mostly), and small apps/scripts.

Haskell? I have no idea.

als0• 6 years ago

Haskell: 5 line quicksort and parsers/compilers. I do like the language, though.

sn412• 6 years ago

Actually: in-place quicksort in Haskell is as verbose as in other languages. The 5 line quicksort uses linear order additional space.

AzzieElbab• 6 years ago

Well, that 5 line quicksort is fake. Haskell is good for writing other languages like Elm for example

usrnm• 6 years ago

You can write quicksort in C++ in about the same number of lines using std::partition from the standard library.

tlarkworthy• 6 years ago

Compilers and logic programming

Blikkentrekker8• 6 years ago

The advantage of Haskell is obviously that it's very easy to write code that is very bug free compared to most languages.

Java and Go are used and Haskell has comparable performance but certainly less bugs.

Guthur3• 6 years ago

These are just wild unsubstantiated claims.

In my experience the worst errors are those of broken referential integrity in distributed systems, misinterpreted product specifications and plain old "this doesn't do what i thought it did" code

UncleMeat3• 6 years ago

The software engineering research community has almost no idea how to measure "ease of writing correct programs". So it becomes very difficult to make meaningful claims that Haskell programs will contain fewer bugs.

shipp022• 6 years ago

Haskell is born out of academia and PL research so it has a great ability to add extensions to the language.

If you have a concept PL feature it is probably easiest to create a prototype in Haskell.

A handy guide to its [extensions](https://limperg.de/ghc-extensions/)

Not much practical purpose for most people but nonetheless a useful feature.

pea• 6 years ago

Building DSLs in finance

IshKebab2• 6 years ago

Haskell is good for transformation type programs, e.g. compilers or document conversion (e.g. Pandoc).

It sucks for pretty much everything else.

anta40• 6 years ago

As a mobile dev, I don't see much effort in Haskell community working on Haskell toolchain for mobile apps.

They seem to more interested in web frameworks. Hmm...

stingraycharles3• 6 years ago

As far as I understand, Haskell’s original intent was to be like a testing ground for research into functional language design, which I think it really succeeded at.

Additionally, I do know of more than a few production deployments of Haskell in finance, but that doesn’t necessarily mean that that is what Haskell excels at.

Blikkentrekker8• 6 years ago

It's probably quite a good language for “transformation of data” without side effects where correctness is more important than performance.

_query6• 6 years ago

Haskell is pretty nice for building web applications.

Thanks to it's type system you can build much more stable web apps in less time. Usually later in the application life cycle you have a hard time refactoring stuff when working with e.g. JS or rails. Without tests you will definitly break stuff. With haskell you can confidently refactor your code without worrying about breaking stuff, the compiler will tell you.

The way data structure are declared in haskell is also very nice for domain modeling. You don't have as much boilerplate as e.g. when using PHP with doctrine.

The performance is also pretty good compared to python or rails.

Guthur3• 6 years ago

Empirically the evidence suggests all those languages without Haskells type system are doing fine considering that the vast majority of the software is not written in Haskell in its actually running.

Frankly hiring is just a way harder problem than building a Web app, and fixing JS, Java python or whatever engineers is significantly easier than finding reasonable Haskell engineers.

jwr• 6 years ago

Can you use it to write code that will be used (compiled) both server-side and client-side?

Because these days this is my bar for a language that is "nice for building web applications". I've gotten so much mileage out of Clojure+ClojureScript just because of this, it's not even funny.

unnouinceput• 6 years ago

You cannot create web applications without JavaScript these days. It does not matter what is your server side programming language, you need to send to the client JavaScript code to be executed in browser. And that in itself is a shitshow. End of story.

dom962• 6 years ago

For most web apps correctness is not the most important thing, this is why Python and PHP are/were so popular.

What is important is flexibility, Haskell's strict typing definitely impedes flexibility so I disagree with you that it's nice for building web apps.

kreetx2• 6 years ago

Making other languages feel like they are missing out :).

zhte415• 6 years ago

Haskell is great for screwing with undergraduates' minds. Box proofs anyone? I did it more than two decades ago and for some reason haven't decided to pick it up again.

ojnabieoot4• 6 years ago

I am personally not a huge fan, but like many statically-typed functional languages, Haskell is great for

- creating new programming languages and DSLs

- problems in finance, energy, medicine, etc., that are more correctness-sensitive than performance-sensitive (it is widely used in Bitcoin brokerages / exchanges / etc, and in general blockchain technologies)

- highly-concurrent scenarios that would otherwise involve a lot of painful management of threads/locks/etc

Facebook’s Haxl is a good example of software that uses Haskell effectively: https://engineering.fb.com/2014/06/10/web/open-sourcing-haxl...

bborud3• 6 years ago

I'm not a big fan of DSLs. Yes, they allow for convenient notation to express things within specific domains, but they also create more barriers. It is both more impressive and more useful if one is able to create abstractions in mechanical sympathy with idiomatic uses of existing languages. Of course, this is harder to do.

I think DSLs are a bit of a lazy cop-out.

This is not a new idea. The myth of the tower of Babel and the observation that by creating lots and lots of communication barriers and interfaces, you lose the ability to coordinate major efforts is indeed very old.

st1x7• 6 years ago

problems in finance, energy, medicine, etc., that are more correctness-sensitive than performance-sensitive

What does correctness-sensitivity mean in this context and how is it missing from a language like Python for example?

chowells3• 6 years ago

Haskell is really good when:

1. You can afford the costs of a garbage-collected system.

2. Your collaborators know it or are eager to learn it.

3. You intend to maintain your system over an extended period of time while adding features.

4. You don't need close integration with the platform GUI.

That last one isn't impossible to do in Haskell, but it's painful enough that it overrides the benefits in a lot of cases.

What products niches does this leave? Servers and command-line tools, primarily, though there is room for GUI applications that use various cross-platform UI toolkits and games that build their entire UIs from scratch. (Yes, both of those exist. Even games. Unity uses C#, it's not like garbage collection is incompatible with games - it just has overhead you'll have to live with and work around.)

Honestly, condition 2 above is the biggest limit. A lot of people who like to talk about judging things on their merits refuse to learn Haskell because it's not yet another shallow skin over the same programming concepts.

My personal experience is that any time you think Ruby would be a good choice for a long-term project, Haskell is a far better option. It supports the same joy of green-field development but is less of a tarpit when the green field is 5 years behind you.

nicoburns5• 6 years ago

Seems like you'd be better off using Rust for most of these. A lot of the same correctness benefits of Haskell, but a much more practical langauge with a more complete ecosystem of libraries.

Jenz• 6 years ago

Haskell is fantastic for programming systems where types are not just a tool, but central to the goals of the program. E.g. a program for converting one type of markup files to another (from one type to another type), like pandoc [1], which indeed is written in Haskell.

[1] https://github.com/jgm/pandoc

ghc4• 6 years ago

Haskell is good for correctness.

Where correctness really matters, you might find Haskell. That makes it a very niche language, as most developers don't really care about correctness.

But you do find Haskell in places where complexity is high and correctness matters. Mostly banking, infrastructure, defense, and research applications.

newswasboring8• 6 years ago

Everyone makes this point about correctness, but I have never seen an easy to understand illustration of this. Now I am by no means a leet programmer but I have been reading about programming for more than a decade and every article about this point feels confusing. I even tried writing small stuff in haskell, still don't get this point.

JabavuAdams3• 6 years ago

The thing is correctness should not be viewed as the role of the language alone. You have to look at the whole ecosystem and organizational engineering practices.

Obviously people were writing life-critical code in C or ASM. You wouldn't expect a car manufacturer to write an ECU in the same way a game dev studio writes a game, but C and ASM can accommodate both.

From my experience Haskell seems to make easy things hard. It's the same mistake as a small startup thinking they need to do whatever Google / Facebook / Amazon are doing, when they're operating at one millionth the scale.

EDIT> By not focusing on correctness as the role of the language alone, you have a smooth path from quickly iterating in a non-safety-critical environment to whatever level of safety you need. In engineering safety is empirical, anyway. You don't just build a system and then assume it will work absent tests, so the idea of getting the code perfect is a bit of a red herring. You're going to have to test it rigorously anyway before anyone will get on your airplane.

whalesalad• 6 years ago

I’ve always felt like Haskell was purely an academic language used to argue about what monads are.

dcolkitt• 6 years ago

Honestly, I feel like the success of Go has eaten some Haskell’s lunch.

I used to use it when I was reaching for a native binary with near-C performance, but wanted an easier to maintain, terser, GC language.

Nowadays that’s pretty much Go. But if the problem would benefit from a lot of higher-level, Haskells still a good choice, given Gos lack of generics.

likeclockwork• 6 years ago

D is my goto when I have similar requirements.

alexmingoia2• 6 years ago

I program in Haskell and quite enjoy it.

mac01021• 6 years ago

Do you use many 3rd party libraries? How do you learn to use them?

The one thing stopping me from using Haskell for real work is that nothing in the library ecosystem seems to have a users manual.

seanparsons• 6 years ago

What? I've worked in a whole bunch of languages and I tend to find that Haskell is the easiest on this front. Hackage has all the definitions for packages cross linking to each other.

kreetx2• 6 years ago

In what area would you like to program in?

At least on the types-are-documentation front, I find that really helpful - just see what you have, what you want, and then find a way from one to the other. In JavaScript on the other hand it's hard to tell what the structure of some object needs to be.

alexmingoia2• 6 years ago

Many libraries lack tutorials because the type definitions are self explanatory.

For example, I’ve been doing a lot of web stuff lately and here’s a package I used for working with URIs: https://hackage.haskell.org/package/modern-uri-0.3.3.0/docs/...

Everything I need to work with is there in the type definitions.

jchw• 6 years ago

I don't have the experience or knowledge necessary to judge this post, but I’m glad it exists and got posted to Hacker News because I believe the discussion will end up being insightful.

I am not generally a functional programming person. I grew up on C and C++ and went on to learn Python, JS, etc. Eventually I finally wrote actual code in Scala and thought it was fine. Didn’t love the syntax, not great at “thinking” functionally, but loved sum types and pattern matching.

I feel like Rust is the perfect mix for me because it gives me the aspects I like about functional programming languages (sum types, pattern matching, strong type inference) combined with composition based polymorphism and an almost C++ like attitude towards meta programming (though obviously with a clean slate.) I do think that learning to “think functionally” better would be good; maybe I should listen to the 4chan meme and read SICP after all. :)

roflc0ptic• 6 years ago

I’ll be interested to see if this generates thoughtful discussion. It feels like a flame-y, ignorant piece of writing and my gut response is to say flame-y, marginally less ignorant things in response. Which I won’t, because that would be unhelpful and make everyone’s life who read it slightly less pleasant for no reason.

Ericson23144• 6 years ago

I kinda want every would-be Haskeller to just go use Rust for a few years. That gives us Haskellers more time to pursue "success at minimal costs".

smichel17• 6 years ago

In my experience so far, SML hit a really sweet spot between ease of learning and features. I never had a "what would I use this for?" moment. Kotlin comes close, but is less elegant and especially lacks full pattern matching.

Unfortunately, sml is used approximately nowhere. Not sure why, but I also haven't used ocaml yet. Maybe one day. My hosting provider (hcoop.net)'s domtool is written in SML, and I hope to hack on it at some point.

vnorilo2• 6 years ago

+1 for SML. I've found F# scratches some of that itch. It is a CLR language with all the up- and downsides that come with .net

bor0• 6 years ago

The whole article builds on the premise that the main point of every programming language is adoption and growth, while for Haskell we have

avoid success at all costs

According to that statement, to me it seems that the current "success" (however one defines it) of Haskell is just a side-effect.

Yes, it is used in industry, but I believe the bigger impact here is how other languages "steal" features from it.

Blikkentrekker8• 6 years ago

Rust would certainly not have existed in it's current form without Haskell.

There are many such “progenitor languages” that focus primarily on theoretical elegance such as Smalltalk, Scheme, and Haskell that might not see huge adoption but do inspire a rather lasting influence on many languages that grew far larger than they.

vnorilo2• 6 years ago

Too bad the tone is so vitriolic, because there is an argument hidden in there somewhere.

Type systems allow us to add theorems to our programs about how they operate and have the compiler check their consistency.

We fight with bugs: programs behaving unlike we planned and specified. We encode plans and specifications as types, and now have formal proof that a certain class of bugs is eliminated. Excited, we want to use this strategy to eliminate more bugs.

A larger part of the programming task is moved over to this higher order type layer. As it becomes less trivial, bugs and antipatterns start to manifest.

We do not have any answers about the objectively best division of labor between static and dynamic aspects. This is a research project that's bigger than any single person, community or language, and I'd argue we need more of Haskell, Rust, Idris and their ilk rather than less. To merely argue that they did not result in a dramatically better OS or a word processor is beside the point.

asplake• 6 years ago

I for one upvoted not because I agreed with the article but for what I hope is a constructive discussion.

Personally, and without wishing to sound entitled, I would love for it to be a lot easier to dip one’s toe in the water. A great start would be a web dev tutorial that starts from scratch with a sane Prelude that hides away anything I don’t need to know now (or perhaps ever). With of course a database, json, and html.

Coming from Flask where I was well served in that regard (no pun intended).

Aside: Thought ocaml might get there first but I’m not seeing that either

dgb23• 6 years ago

I agree, the benefit of this, is that it creates a frontier where math can be applied more rigorously to programs. There is a related xkcd comic about this.

We’re in a “not there yet” kind of situation.

The author likely comes from a very mainstream product centric domain, as most do. In this context one has to agree with the criticism and maybe also admit that this is not what the language is for?

feanaro5• 6 years ago

This is a good point. But I also want to add that as a freelance developer, I've done quite a number of medium sized projects for business use cases in Haskell singlehandedly. Empirically, the results were very low in bugs and remain at use at the companies in question without requiring much maintenance.

So this kind of thing is something that is well served by Haskell, in my opinion. I wouldn't seriously recommend someone else that the best path to doing this kind of work is to go and learn Haskell but I also feel this is something I wouldn't have been able to do as well using many other more popular languages.

robertlagrant• 6 years ago

Vitriolic is an exaggeration. It's a little cynical, for sure, but not necessarily without reason.

jonny383• 6 years ago

Haskell is honestly like a cult. Not so great, but once people are hooked, try convincing them otherwise.

valenterry3• 6 years ago

That's not about Haskell but about the paradigms though. So rather, pure functional programming is hooking people. I understand why: once it feels natural, it is very painful to go back.

Santosh83• 6 years ago

There are languages more suited to program in, and there are languages more suited to move the field of programming itself forward. I guess Haskell belongs to the latter category and when people try to ram it into the former set, they get frustrated.

_query6• 6 years ago

programming languages are meant to ease the task of creating computer programs as opposed to writing assembly by hand

This! The haskell ecosystem is missing a certain kind of pragmatism. There's a lot of beautiful type abstractions, talking about monads, etc., but not enough builders doing actual application development. In my opinion it's not the language that is bad, but the ecosystem. Missing documentation, missing tooling and infrastructure, no focus on actually building applications.

We're trying to fix that with IHP, a new haskell framework with a focus on actual building applications. Imagine the productiveness of rails combined with the typesafety of haskell.

6 months after it's release it's already the second biggest haskell framework, and we just had a new record of weekly active users last week. To me this shows that by fixing the ecosystem haskell can reach a lot more than it's currently doing.

Check it out: https://ihp.digitallyinduced.com/ GitHub: https://github.com/digitallyinduced/ihp

shipp022• 6 years ago

Thank you will check out. I was going to work on a web app in Haskell and am scouting libraries.

kdkeyser2• 6 years ago

This indeed seems to be the main/only point of criticism in this post that is valid: however, it is not that Haskell has no "pragmatic" libraries to get stuff done (e.g. WAI/Warp, Yesod, Servant, ... are top notch, practical libraries if you are writing network/HTTP services). They do seem to drown in the sea of libraries/blog posts that are focused on the academic/abstract stuff. The end result does not feel consistent, and reminds me of the horrors we had with the early C++ metaprogramming efforts: it looks cool, but you end up fighting the language and produce unreadable code.

For Haskell to become a successful "industrial" language, I think most of the dependent-typing stuff should probably go (to Idris/Agda etc.), so that a clear and consistent Haskell subset can be defined.

The other arguments in the article are just weak. The rant about data not having a type, is missing the point. Sure, often you receive data that you need to inspect to know what it is. You can easily do this in Haskell (just label it with the UnknownData type), and have a function that inspects it and returns, depending on the contents, the right type). The big advantage is that you don't have to keep on doing this same check.

Types being the cause of difficulty in refactoring when business requirements change, is the opposite of my experience. In large dynamically typed codebases, being sure that a large refactor caught everything, is very hard / costly in test coverage. I have seen this go wrong many times. Having the compiler point out what you have missed, based on the types, is very helpful.

While I think the arguments are a bit weak, I do agree that it is at least unclear if Haskell is a sound choice as a production language at this time. Fighting against an ecosystem is not something you want to be doing while building your product. But in contrast to the author, I do think this is fixable, and see steps happening in the right direction (e.g. with IHP, but also with the efforts around the Haskell Foundation and the Haskell Language Server)

WJW3• 6 years ago

I don't think that quote is complete enough though. If you really believe that programming languages are just tools for building programs (in particular "useful" programs that make money) then yes, Haskell has not much to offer you over PHP or Ruby and other languages in that vein.

On the other hand if you are interested in research, exploring the extent of the design space for programming languages and what you can (or can't) express in them, then Haskell is an excellent language for you. Both for the community of like-minded researchers and for the flexibility of the language/compiler itself.

On a wider scale, I've always liked https://josephg.com/blog/3-tribes/ as an explanation for why this topic comes up again and again and again. The writer of the article is more of a "type 3" programmer. He wants to build a house but does not care much which tools he uses as long as they don't get in the way. It is the end result they are interested in, not the process. Haskell is, by design as a research language, more process oriented than result oriented. And yes, you can still get results with it as IHP and SC and Jane Street have shown. But they seem to be the exceptions that show the norm.

_query6• 6 years ago

I think for making stuff the speed of iteration is the most important metric.

Haskell is great for this because:

- In dev mode it's super fast, see https://www.youtube.com/watch?v=nTjjDo57B8g&feature=youtu.be

- You can change features of your product easier thanks to the type system. Doing a big refactoring with rails always adds many bugs. With haskell you spend less time on doing these kind of changes because the compiler tells you what needs to be changed.

UncleMeat3• 6 years ago

If you really believe that programming languages are just tools for building programs (in particular "useful" programs that make money) then yes, Haskell has not much to offer you over PHP or Ruby and other languages in that vein.

I'd agree with this generally. During grad school I loved hacking my research on haskell.

But this doesn't seem to be a consistent claim from the community. It'd be helpful if the core maintainers published this somewhere. Because I consistently get haskellers telling me that I'd be more productive as an engineer and my programs would have fewer errors if only I worked in Haskell.

Some other languages do have this sort of vision statement (or, at least a fairly well implied one) that makes it clear what they are offering and what they aren't. C++ wants to give you speed and flexibility without overhead for things you aren't using. That's been consistent for decades.

madsbuch2• 6 years ago

The quote

programming languages are meant to ease the task of creating computer programs as opposed to writing assembly by hand.

is wrong: Assembly is certainly a programming language, which the author acknowledges when writing `writing assembly`.

As mentioned elsewhere, the whole blog post appears to be a troll post and should definitely not be taken as a part of a sober discussion on programming languages.

erik_seaberg• 6 years ago

He should have written “as opposed to writing object code by hand,” because assembly does save some effort there. Some architectures were even designed around making assembly code more readable, rather than making it the compiler’s problem.

jawline• 6 years ago

Not sure if you are the right person to talk to but there's a small mistake on the front page. Missing "language" in functional programming language (at least on my phone)

pyrale2• 6 years ago

but not enough builders doing actual application development.

It's simply because the community is small.

People compare Haskell to other languages like Java or JS like there's an equal amount of manpower, and therefore, if not everything has a library, it must be because haskellers are slacking on useless stuff. It is not.

Other small languages communities have exactly the same issues, it's not specific to haskell. The only thing that is specific is outsiders feeling entitled to an ecosystem and blaming "these damn fp ivory tower types" for not providing it.

JabavuAdams3• 6 years ago

No, it's really not. Haskell is a pain in the ass to program in. It's a language developed for mathematicians, not the real world. It makes the same mistakes as OpenCyc and expert systems.

I know assembly, C, C++, Scheme, Common Lisp, Python, MATLAB, C#, some D, some Javascript, some Mathematica. Programming in Haskell looks promising initially, but just drains all the joy and productivity out of my programming.

sn412• 6 years ago

I finally understood what monads and monad transformers are about. And there comes arrows and linear types. Ouch, my head hurts.

WJW3• 6 years ago

The line which sprung out most to me was the one claiming that "Clojure took the world by storm". This is simply not the case. JavaScript has taken the world by storm, as has Python. Ruby, PHP and others have taken the world by storm before and are slowly fading. Clojure has never taken the world by storm and (IMO) never will. Neither will Haskell btw.

To me, Clojure is very much on the same level as Haskell: an extremely niche programming language with a small (sub-1% in TIOBE) but dedicated following that is unlikely to grow much beyond what it already is.

Rest of the article: meh. It presupposes a lot of what it thinks Haskell should aspire to without investigating whether those things are actually what it is aspiring to be.

ImprobableTruth3• 6 years ago

The entire article just reads like a badly regurgitated Hickey talk.

thom2• 6 years ago

Yeah, I think Clojure people have a lot of insecurity around Haskell and it’s rarely a good look. Clojure is a language of sensible compromises without any real philosophical slam dunks, which doesn’t seem to satiate engineers’ natural desire to win internet points.

iLemming5• 6 years ago

Clojure people have a lot of insecurity around Haskell

I beg to differ. I think it's the other way around. I rarely see Clojure folk bashing on Haskell - they usually admit Haskell's strong points or any other language. They very often borrow ideas from other languages, libraries, and tools. I've heard they are figuring out interop with Python and R. They've built Clojure-like Lisp dialects that work on Golang, Erlang, compile to Lua, etc.

Haskellites, however, get sad and defensive anytime someone mentions that it's not so widely used in the real world.

iLemming5• 6 years ago

I think you are ignoring the facts: Clojure at the moment is the most widely used programming language with a strong FP emphasis.

Clojure gathers more conferences and meetups, has more active podcasts, books, jobs, etc. Many companies are using Clojure in production: Apple, Walmart Labs, Cisco, Pandora, CircleCI, Roamresearch, Grammarly, Pitch - are just a few that come to mind. And they're not using it for the small stuff; for example, Cisco has built its entire security platform with it.

Clojure is the third most popular JVM lang. To be fair though, this is mainly due to Kotlin taking over Scala. Also, Clojure probably is the second most popular lisp dialect on GitHub (after Emacs-lisp).

So I think the claim is correct. At least within the FP world - Clojure currently dominates over Haskell, OCaml, F#, Scala, Elixir, Erlang, etc.

WJW3• 6 years ago

Are you not just moving the goalposts? The original article was "took the world by storm", not "took the FP world by storm". As part of the wider programming world FP languages are a tiny minority, regardless of how many impressive companies we rattle off. JS and Python absolutely rule the roost at the moment.

travv03• 6 years ago

You claim that they’re ignoring facts, but provide no facts of your own beyond “some companies use it in production,” which is undoubtably also true of Haskell.

jpcooper• 6 years ago

I have been giving Python a go for writing a programme which concurrently scrapes and collates data from multiple sources.

I chose to figure out how to do this in Python instead of my usual Haskell because I wanted to see how productive I would be compared to how I did similar things in Haskell. I wanted to get away from what I call type-wankery, which the author seems to be complaining about as well.

I’ve been using the Python asyncio library and have been thinking that Python could certainly do with monads in this context. Then I remembered what a ball-ache stacking monads is. In any case, I can’t help seeing programmes in an algebraic context after using Haskell.

The author, and many people who complain about types, seem to forget that types and interfaces exist whether or not they are explicitly defined.

Is the problem with such an attractive type system that they lead to people defining interfaces before they are fully explored? In that case, maybe it could be argued that a less attractive type system would keep people away from so much type-wankery.

It’s hard to know where the best balance is. I am considering F# now. It also seems to have working IDEs, which is nice.

smlckz2• 6 years ago

Here is a very good argument on why types are needed, by Bartosz Milewski: https://bartoszmilewski.com/2014/11/24/types-and-functions/

jokethrowaway5• 6 years ago

Haskell is a language for experimenting, success is not their goal and it would remove resources to actual research.

They had promises and async/await in 1995. They're trailblazers that other languages can follow (like rust did).

I would add that, after stack, tooling is not a problem anymore. It's not as good and polished as rust's cargo but it's ahead several other languages.

Still, as a language, Haskell is not ideal for teaching and productivity.

There too many different ways of doing things (eg. strings, records); compiler errors need improvement, prelude has too many exceptions-throwing functions (eg. head); exceptions handling is not something I want in a pure language; ghc extensions change the language so much that using some extensions almost feel like having to learn another language.

On documentation, I can't say I feel the need for it, but I understand some developers may be used to program against documentation and feel lost without it.

I think that Haskell is a great language to prototype pure business logic because of the type system and focus on purity, but it has several warts, because haskellers focus more on language research than DX.

The reason I stopped using Haskell is because I was bit by exception handling (which is a feature shared by many other languages, incidentally!) and by GC spikes.

I still like Haskell, it's closest to my "ideal" language than any other, but for production Rust is more useable (albeit being a bit uglier)

dom962• 6 years ago

They had promises and async/await in 1995.

Really? Do you have a source on this? I was under the impression that C# was the pioneer here.

jcelerier• 6 years ago

promises, futures, etc... are much older - it takes 15 years for stuff pioneered in research to make it into general purpose langs :p

- https://d1wqtxts1xzle7.cloudfront.net/50657913/p260-liskov.p...

- http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97....

jokethrowaway5• 6 years ago

More precisely, I was referring to monads and do-notation with that phrase.

Here are some references on when it was invented / implemented: https://www.reddit.com/r/haskell/comments/8rkrgq/when_was_do...

Also a JS gist on async/await and do-notation: https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb...

arianvanp• 6 years ago

Async/await is specialised syntax for a more generic concept of monads which haskell was the language in which this was heavily researched.

Specifically continuation monad describes asynchronous computation (promises) and was one of the motivating examples In the early 90s going back all the way to Moggis original "notions of computations" paper from 1991 http://homepages.inf.ed.ac.uk/wadler/topics/monads.html

Async/await and LINQ were the brainchild of Erik Meijer. A haskell researcher.

Also see https://news.ycombinator.com/item?id=25565229 from a recent discussion here.

Specifically http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.... where Eric tells his story about bringing haskell concepts to .NET

paavohtl• 6 years ago

Even though the concepts weren't invented for C#, you are technically correct in that C# pioneered the keywords async and await.

knuthsat• 6 years ago

Exactly. It's a research vehicle. Not everything in Haskell is useful for business or productivity.

The reason I stopped using it is because of performance. Despite having state of the art optimizations there it's still too slow for my needs and writing fast code is way to hard compared to C++ or C.

I was also quite disappointed to learn that a lot of useful concepts (Monad transformers/stacks) have a runtime performance impact when it looked to me like I was just playing with types.

Quekid58• 6 years ago

It's a research vehicle.

Well, it's also one that happens to make people lots and lots of money. Standard Chartered, for example, uses it extensively to earn lots of money. Facebook uses it for spam filtering logic. Niche, perhaps, but painting it as purely for research is just incorrect.

Yes, it's not going to be great if all you're writing is integrations with various vendors using SOAP or just legacy or odd protocols. Those have libraries or code generators on the JVM/.Net/etc. platforms... not so much in Haskell. However, this has nothing to do with the language, it's just a matter of people actually doing the work to support those things.

Everything else, though... you're golden. It has a learning curve, but there's a reason that Scala is moving ever closer to monads, adopting proper syntax for type classes, etc.

Blikkentrekker8• 6 years ago

prelude has unsafe functions (eg. head),

`head` is not unsafe, it is a partial function. An unsafe function can lead to u.b.; the behavior of `head` on an empty list is very much defined. Haskell is not a total language.

jokethrowaway5• 6 years ago

Thanks for the correction, changed to exception-throwing - that's the behaviour I don't like

EE84M3i3• 6 years ago

As an aside -- Rust's definition of "unsafe" (e.g. "can lead to u.b.") is not the only definition of unsafe one can use for a programming language, which can have different safety guarantees.

As a motivating example, in many languages converting a reference to an integer containing a memory address is unsafe (e.g. Java[1]/golang[2]/C#[3]/Haskell[4]), but this is considered safe in Rust.[5] All these languages literally use the word "unsafe" for it.

[1]: See sun.misc.Unsafe, which indirectly provides this https://stackoverflow.com/a/7060500/315936

[2] https://golang.org/pkg/unsafe/#Pointer

[3]: pointer types are only allowed with the unsafe keyword, see: https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

[4]: I believe this requires unsafeCoerce https://stackoverflow.com/a/18563789/315936

[5] https://doc.rust-lang.org/reference/unsafety.html

dan00• 6 years ago

I would add that, after stack, tooling is not a problem anymore. It's not as good and polished as rust's cargo but it's ahead several other languages.

In a way Cabal 3 is even ahead of cargo, by being able of sharing build libraries between different projects and still having a sandbox like build for each project.

There too many different ways of doing things (eg. strings, records), compiler errors need improvement, prelude has unsafe functions (eg. head), exceptions handling is not something I want in a pure language, ghc extensions change the language so much that using some extensions almost feel like having to learn another language.

For such a self called safe language, some things are almost comedy like, like getting exceptions for uninitialised record fields or unhandled alternatives in case expressions.

But Haskell still has a place in my heart and I‘m still following its development. But for my side projects Rust has replaced it, by being at some things even safer, but foremost safe at the places it‘s most important for me and also quite a bit more pragmatic. For me Rust combines the best parts of Haskell and C++.

Ericson23144• 6 years ago

some things are almost comedy

We're trying to fix that! https://github.com/ghc-proposals/ghc-proposals/pull/351

blippage• 6 years ago

Haskell is a language for experimenting, success is not their goal and it would remove resources to actual research.

It's somewhat facetious motto is "Avoid success at all cost".

yrimaxi• 6 years ago

   Avoid $ success at all costs

_query6• 6 years ago

I think that Haskell is a great language to prototype pure business logic because of the type system and focus on purity, but it has several warts, because haskellers focus more on language research than DX.

This is very true. We recently started https://github.com/digitallyinduced/haskell-ux to keep track of haskell DX improvements. Some of our suggestions are already issues on the GHC (haskell compiler) bug tracker.

Here's an example of a great UX improvement in GHC: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4711

ludamad• 6 years ago

Good to see that the article is at least underselling that people are actively working on this

ookdatnog• 6 years ago

Haskell is a language for experimenting, success is not their goal and it would remove resources to actual research.

You rightfully point to Rust, which took a lot of inspiration from Haskell, but I think it's worth emphasizing just how much of the progress in programming languages in the last two decades was inspired by functional programming (many features were not invented in Haskell, but some like type inference were popularized by it).

For example: proper type inference, algebraic data types (enums in Rust) and consequently option types, pattern matching, property-based testing, immutability by default, parametric polymorphism (generics), ad-hoc polymorphism (type classes/traits/...), first class functions (very old idea but only recently common in mainstream languages), ...

pjmlp7• 6 years ago

I learned type inference in Caml Light, Haskell was still Miranda back then, and I bet any language designer of all major languages has similar backgrounds in regards to ML type inference.

Even type classe ideas can be found in CLU, ML, Objective-C, before the paper that gave origin to their adoption in Haskell.

brabel• 6 years ago

The Rust docs claim most things actually came from ML and OCaml: https://doc.rust-lang.org/reference/influences.html

They only mention Haskell's type classes and type families as inspiring a Rust feature directly (traits).

hyperpallium22• 6 years ago

from lisp and ML, but yes, haskell is a white-coat language.

pjmlp7• 6 years ago

It's not as good and polished as rust's cargo but it's ahead several other languages.

Until cargo supports sharing of binary crates it isn't as polished as I care about.

All the languages I use, except for scripting languages, support distribution of binary artifacts, including Haskell.

agentultra• 6 years ago

Hi.

I am a professional software developer and my full time job is currently writing software in Haskell for a bank.

I also stream projects and open source work I do in Haskell once a week.

I am not a researcher. I don’t have a horse in that race. Although I am thankful for the research that is done as things like STM and type system extensions benefit my work greatly.

I really wish Haskell could shed this meme that it’s a “research,” language and that, “nobody uses it.”

I’m Nobody. I use Haskell every day. It’s a practical language for industrial strength programming in a pure functional language.

jokethrowaway5• 6 years ago

The fact that Haskell is a good industrial strength language is a byproduct of its quest for language design excellence.

Avoid success at all cost, implies an unwillingness to sacrifice on design to please corporate needs.

I don't think it's a "meme", there really is a focus on research over being production ready. Monads, Arrows, Dependent Types - Haskell is where a lot language research happens (and the language chosen by a lot of researchers).

Sure, you can ship Haskell in production if you're happy to fill in the gaps. I did some of that for a non-Haskell company and it wasn't as easy to deploy apps written in other languages and community-provided solutions for logging / monitoring were lacking.

That said, I'm always happy to hear about people using Haskell in production and wish you the best

whereistimbo• 6 years ago

But since industries used Haskell, now they are concerned with backward compatibility, which AFAIK makes some parts of Haskell ugly. I wish there would be something like RHEL/Fedora model rather than letting Simon Peyton Jones being dictated by industry by ceding towards backward compatibility.

kazinator2• 6 years ago

async/await in 1995

Unix had fork and wait before 1979.

Unix shell:

  # run some commands asynchronously

  $ command1 &
  $ command2 &
  $ command3 &

  # wait for all of them

  $ wait

OskarS• 6 years ago

Multiprocessing and parallel programming is a different thing from async/await, which primarily has to do with with green threads and coroutines. You're right that the ideas go way back (hell, Knuth was writing about coroutines in TAoCP in the 70s!), but this does not qualify.

foolmeonce2• 6 years ago

I think an aspect of many paradigms and then the multiparadigm languages is that people don't see the original two camps of CS pioneers.

Haskell is from math, brevity, correctness.

Perl is a linguist's take on applied math.

I would prefer to write a proof in haskell and a manifesto that expresses what I think, however irrational, in perl.

("If I had more time I would have written a shorter letter." and general sentiment towards first language vs math education imply that perl will be the easier and more comfortable language for most if that is really the primary goal. But the slight irrational thinking as we add more layers means eventual collapse.)

cannabis_sam3• 6 years ago

When people talk about the beauty of Haskell due to it’s definition they are making a qualitative claim.

When people say Haskell sucks because of low adoption rate they are making a quantitative claim.

As a research language there is real value in Haskell not getting broad adoption, since that would increase the demands for maintaining backwards compatibility.

As an industry language that philosophy is a huge detriment because it introduces risk and extra costs in keeping up with an ever changing language.

These things are not a one dimensional structure, otherwise Java and C are pure perfection due to adoption and Rust and Haskell should be forcefully shutdown or whatever.

harry8• 6 years ago

You either think the astronomical number of bugs in delivered software is a problem or you don't (and good luck with that). The use of Haskell is a huge win on this metric and demonstrably so. You don't have bugs in any of the Haskell programmed OSes you actually use, nor your editor written in Haskell, your Haskell mp3 player nor your Haskell time machine and Haskell en-truthenator.

Pandoc is good. Some like xmonad window manager, git-annexe has some fans. There's probably 4 or 5 more too! Mostly centred around parsing.

And for all that you absolutely should learn Haskell. You'll enjoy it and it will enable you to think about programming in New and powerful ways. Just don't fall so deep you expect to actually ship anything you write.

thom2• 6 years ago

The only Haskell software I regularly interact with is Hasura, and it has plenty of bugs (even ones around nulls and other things Haskell is supposed to magic away).

jbjbjbjb• 6 years ago

I wish functional advocates would stop saying this, it just isn’t true. There any many types of bugs and Haskell may help prevent some of those.

tchaffee• 6 years ago

You either think the astronomical number of bugs in delivered software is a problem or you don't (and good luck with that).

We don't need luck. Competition has already given us the answer that most bugs are ok. The vast majority of the software that creates literally trillions of dollars of economic activity, and pays most of our bills, is not mission critical. Software fails all the time with the only significant consequence being a developer has to spend some time fixing it. Sure sometimes money is lost. So is money lost when factory equipment needs repair.

Some software does deserve to be bug free when it might put lives at risk, like flight software or medical software. Perhaps even operating systems. But the vast majority of the software I use on a day to day basis does not fit that category. What significant harm does a bug in VS Code or Slack or even my OS cause me? None.

If bug free software gave a significant economic competitive advantage, smart folks would start writing it and win big in the marketplace. Considering this has had decades to happen, and has not, it's very unlikely that bug free is the winning competitive advantage when it comes to software. I'd guess the winning advantage is that the software is useful. Much like a car with many small problems is still useful.

The truth is that much of the software that exists today simply would not be worth building bug free and would never be profitable.

You can extend this outside of software development to see that it's true in a more general sense. Most of the manufactured products we buy are not perfect and do not last forever. Some even have flaws from the day you buy them, but flaws that can be worked around. Once on vacation I bought screwdriver at a dollar store. Poorly manufactured and it does have "bugs" compared to something I would have paid 10x the price for. But years later I still have it and it's good enough for some jobs.

You could potentially build a car that doesn't fail for any reason for a few hundred years. Only Bezos and friends could afford it. With that said, I'd like to see the negative externalities of pollution and waste included in the true cost of things we buy, so that we don't produce so many disposable things that society pays for in the long run. But that's a different discussion.

Please don't take this to mean that I don't take great pride in writing quality software that is as bug free as possible. I do. I also take great pride in meeting budget goals and deadlines. All successful businesses understand that competing goals must be balanced against each other.

tome5• 6 years ago

A well thought out reply, thank you. Haskellers would typically agree with you. Unfortunately harry8 who you were replying to isn't one. He was being sarcastic.

lukashrb• 6 years ago

I wonder is there any good research/data for this claim correlation between bugs and used language. I know there is some for development practices but it's independent from the language used.

tarleb• 6 years ago

You might like these:

An Empirical study on the impact of static typing on software maintainability, Stefan Hanenberg, Sebastian Kleinschmager, Romain Robbes, Éric Tanter, Andreas Stefik/. Empir Software Eng, (2013-12-11). DOI: 10.1007/s10664-013-9289-1.

An Empirical Investigation of the Effects of Type Systems and Code Completion on API Usability using TypeScript and JavaScript in MS Visual Studio. Lars Fischer, Stefan Hanenberg, Proceedings of the 11th Symposium on Dynamic Languages (154--167), 2015.

A large-scale study of programming languages and code quality in GitHub. Ray et al., 2014

The TL;DR is: typing matter, but so does tooling. However, programmers in dynamic languages are slightly slower, appear to produce more defects. There is a measurable benefit of static typing, but it's small.

p0nce3• 6 years ago

Economics of Software Quality has a function point to language conversion data, and function point to quality charts, so you could possibly say infer from that.

tome5• 6 years ago

Your respondents don't seem to have realised that you are being sarcastic.

p0nce3• 6 years ago

The use of Haskell is a huge win on this metric and demonstrably so.

So.... where are all the haskell competitors that benefit from this lower bug count? (edit: ah! satire!)

isubasinghe• 6 years ago

I really like Haskell, I do enjoy Rust as well. I really am not a fan of OOP languages, largely because the data flow can be anything you want it to be. When the data flow is linear I find code far more easier to understand.

One thing I dont like about Haskell: GHC doesn't seem to be aware of some of its escape hatches (allowing for imperative code) and performs incorrect optimizations. I had some trouble working with IORef recently and had to write some hacky code to get it to work properly.

agumonkey4• 6 years ago

Look at Clojure. Weird parentheses, and yet it took the world by storm

Am I on another planet ? I'd rate clojure slightly above haskell in terms of market share. Is my radar broken ?

waffle_ss• 6 years ago

That raised my eyebrow as well.

Semi-recently I was interested in learning Datalog so I wanted to kick the tires on Datomic (written in Clojure). I ended up getting stuck on some things; posted questions to StackOverflow and didn't get a response. I then realized the Clojure tag is very low volume + engagement.

Then someone on Twitter told me that I'd be better off asking questions in the Clojurians Slack channel. So I go to sign up and... the signup link is broken. Had to flag down someone on Twitter or IRC to fix it.

As an outsider I felt a whiff of decay from the Clojure community (no offense)

agumonkey4• 6 years ago

The whole article felt it's coming from a traditional / industrial OO (everybody happy about UML usually doesn't see the world as I do).

broken slack links or not, the community is not as large as the author seems to convey.

travv03• 6 years ago

Yeah, it’s kind of mind-blowing to me that this post is so highly rated when to me it just seems like a bunch of unsubstantiated claims like this, as well as blatant misunderstandings of fundamental functional programming concepts.

agumonkey4• 6 years ago

I guess haskell is just rarely enough on HN FP to get a boost just for that. Content is not worth spending much time IMO. To each his own, if the guy really suffers with Haskell then so be it, may he have a lot of fun with perl or js.

iLemming5• 6 years ago

If you try to set a google alert for "Clojure jobs" and "Haskell jobs", or just go through "HN: who's hiring" of the recent years and compare search results for Clojure and Haskell, you'd see that it's not "just slightly above". Clojure currently is the most widely used FP lang.

haskellandchill• 6 years ago

Doesn't Scala beat Clojure in industry? That would be my experience and it has higher number of jobs on Who's Hiring. My ranking for adoption goes: Scala > F# > Elixir > Clojure > Haskell > OCaml. F# doesn't make much of a showing on Who's Hiring but I think it has stronger adoption in industry than Clojure.

greatgirl• 6 years ago

I find the circle jerk around programming languages to be kind of tired. I realise this is a deeply ironic statement. But, personally, once i realised the vast amount of the rest of the world that is out there and can be explored, intellectually and physically, going back to arguing about programming languages made me feel a bit sick.

I think this can't be applied to other niche interests. There's something uniquely tireless, insignificant, and wanky about programming language discourse that makes it especially sickening to me.

malf• 6 years ago

Functors are basically an Object with a internal state changing method in typical OOP terms.

This lets me safely ignore the rest of the article.

newswasboring8• 6 years ago

Care to say why? Or just going to hit and run?

davorak5• 6 years ago

I will take a stab at it.

Functors are basically an Object with a internal state changing method in typical OOP terms.

If I was writing a functional language, in an oop language, I could implement functors at least partially with an Object with an internal state changing method. I could not model/implement an Object with an internal state changing method in a fp language via a functor.

The main issue with the author's statement is that it makes a claim of approximate equivalence and does not back it up with additional evidence or examples.

kryptiskt• 6 years ago

Functor is a typeclass, which is the equivalent of an interface in Java, it's very basic, providing the ability to lift a function and execute it in the context of the functor (whatever that is, this is the interface, remember), a generalization of map.

So a lot of types have an implementation of Functor. In theory one of those implementations could be guilty of using hidden state and all that, but in practice all of them are just straightforward functions transforming values into a new value, not mutating them.

In short, not a single word of the description is correct.

fooker• 6 years ago

That’s a pretty reasonable colloquial description for anyone who does not grok functional programming.

davorak5• 6 years ago

If the author was using the description to explain Functors to someone who only knew oop it's a reasonable start. I got the impression the author was implying that is basically all you need to understand Functors and is not the case.

evincarofautumn• 6 years ago

Wow, I honestly wonder if this was caused by mixing up “functor” in the C++ and Haskell senses…

To expand on that, for those in the audience:

In Haskell, a functor is a type constructor (like “list”, “optional”, “future”, “I/O request”, &c.) with a way to map a function over it, covariantly, in a way that preserves its structure—i.e. without changing the shape of the container or structure of the action represented by the constructor, just the contained elements or produced result.

This is based on the more general notion of a functor in mathematics, which is a mapping between categories. The Haskell version is much more constrained, though: it only maps between Haskell types, and it’s parametric (iow completely generic), not just any old mapping.

While in C++, a functor is a completely different thing: an object that can be called like a function. It’s thus equivalent to a closure, where the object fields are the captured values. And that sounds like the description being used here.

danidiaz• 6 years ago

I disagree with this:

One, types are a concretion. If you’re looking for higher level of abstractions to get flexible behaviour, you’re ultimately going to have a world of pain

I don't see why types should be in the way of flexible behaviour. Frameworks like Spring in Java use types to direct dependency injection and it works well.

Also this:

Types wrap data and treat it like a black box whereas schema describes the shape and content of data.

Types can be made abstract and blackboxy, and sometimes that's what you want. But doesn't a record type give info about its fields? Doesn't a sum type give info about possible alternatives in the values?

As such haskell ultimately suffers a lot when they have to interact with the real world. Suddenly they are left reeling as they find out that the real world is, in fact, dynamic.

The trick is to know what we are really modelling. If we are deserializing domain objects from JSON, it makes sense to have types for the domain objects. If we are writing a tool like, say, jq, perhaps we should merely have a datatype for the JSON tree itself: http://hackage.haskell.org/package/aeson-1.5.5.1/docs/Data-A...

Bottom up design is something we’ve learnt collectively as a good way to be much more flexible in responding to change.

Even if you want to design bottom-up, the moment you want to add anything to your program, you need a little top-down thinking, if only at the micro-level. You want to create something new that isn't there, and then think how to accomplish that with the tools you have.

johtela• 6 years ago

You can agree or disagree about the design decisions made by people contributing to Haskell language, but you have to admit that it's a pretty clever bunch of people. Haskell has contributed more to PL research in past few decades than any other language. That alone makes it a language every programmer should learn. Not because they should use it daily, but to learn what functional programming is in its purest form.

ilikebits• 6 years ago

Haskell has a lot of problems, but this article is not good, and does not describe them well. It reads like it was written by someone who has tried Haskell, and has sort of written some code in it, but has mostly been put off by bad and confusing tutorials, and has never really grokked the language. Indeed, look at the author's GitHub - of their 50 projects, only 1 is Haskell, and that is a handful of commits before giving up.

My main complaint with Haskell is that it's actually a great language, wrapped up in (1) hilariously beginner-unfriendly syntax and tooling, and (2) a library ecosystem that does not quite understand the value of friendly documentation (although this is actually improving a lot). There are also some weird warts around the language itself, but those are mostly tolerable and not so much worse than the weird warts in all other languages.

My specific complaints about beginner-unfriendliness in syntax and tooling:

- The compiler will infer the types of names as generally as possible, and will run this inference both forwards ("this variable was assigned a string, so must be a string later") and backwards ("this variable is used as a string, and therefore must have been a string earlier") depending on what information is available for inference. This means that type errors are hit-or-miss; about 60% of the time, the type error will point you to your actual mistake, and the rest of the time it will point you to where the type inference algorithm got stuck in unification (this may not be the location you made your actual mistake, because the algorithm will try its best to infer concrete types working under the assumption that you didn't make a mistake, so it sometimes gets stuck trying to unify types at an earlier/later point than your actual mistake).

- The syntax is VERY minimal, and prefers minimalism over readability. In particular, Haskell has no explicit parentheses for function calls, and has implicit currying! This means that it is very easy to accidentally get the arity wrong in a function call (for example, `foo (bar baz) quux` and `foo bar baz quux` mean very different things!), and create an extraordinarily confusing type error (in the best case, an error about applying things to the wrong number of arguments; in the worst case, errors about constructing infinite types).

- This minimal syntax also means that you can sometimes type something that is _almost_ correct, but is actually valid syntax that means something totally different! Fortunately, your almost-correct expression will not type-check (so you won't ever mean something else without getting an error), but it's still a head-scratcher in the beginning to figure out exactly what the compiler is taking your code to mean. In some of these cases, you may even type something that is not syntactically valid vanilla Haskell, but _is_ valid Haskell-with-some-extension, and the compiler will unhelpfully suggest that you turn the extension on even though it may not be what you want (and also provides no explanation of the extension).

- The compiler tells you what expression has a type error, but never actually tells you the exact term that has a type error. You have to sort of guess at this by understanding the rough high-level of how the type inference works. It's something you have to really pick up, and is hilariously unfriendly compared to e.g. `rustc --explain`.

- Print-debugging works differently than what you'd expect. Nobody ever teaches you that `trace` is a thing (seriously, this should be thing #2 that is taught), and nobody ever teaches you "you're getting trace messages in a different order than you expect because Haskell is evaluating expressions with graph reduction, not in the order of the lines of code you wrote").

Really this boils down to: even though Haskell will do a very good job at preventing you from holding it wrong, you really do have to have a decent grasp on what you're doing to write a program. As a complete beginner, you can't just put something you think will mostly work and then rely on simple compiler errors to tell you where to spot fix (unlike e.g. Go, Java, etc.). Fortunately, this gets much better over time - you learn how to interpret compiler errors better as you get a grasp on the language, and you learn tricks for building incrementally correct programs up using `undefined` and friends.

My specific complaints about documentation:

- Contrary to this article, types actually ARE decent documentation in Haskell. The constraints you can do with types in a pure language are much, much stronger than in other languages you've used before. Trust me - this is a Blub paradox thing. It's just a qualitatively different kind of type safety.

- Unfortunately, although types do a great job at preventing me from plugging the pipes together wrong, they still don't tell me anything about the _semantics_ of a function. Lots of older libraries do a very bad job at documenting semantics, but this is getting a lot better.

- Arguments in Haskell functions are not named (or at least, their names are not exposed in documentation). This makes for some confusion sometimes - what am I supposed to pass as arguments to this `foo :: String -> String -> String` function?

- Lastly, a lot of libraries document very academically. Here's an example: https://hackage.haskell.org/package/logict-0.7.0.3/docs/Cont.... The documentation here is written assuming you understand how Logic computation works, provides no examples, and you're supposed to read the module documentation and actually go and _read the paper_ (in fairness, it's pretty short) that they've linked. This is a far cry from the NPM world (which, for all its faults, has really embraced accessibility in documentation), where everybody has a quick start.

Overall though, it's a really good language. Once you get monads (and a HUGE part of this is not the idea of monads, but the really unfriendly syntax and error messages of Haskell; IMO the _real_ lightbulb moment is grokking the difference between data, types, data constructors, type constructors, and typeclasses), a lot of things make a lot more sense. The testing story is amazing, the refactoring experience is amazing, the incremental development and REPL stories are great, and there are some truly astounding abstractions you can use that are just impossible to express in other languages. It's my regular side project driver, and my team maintains a Haskell codebase in production.

Lastly, a word of advice to anyone looking to actually make a good-faith evaluation of Haskell: try it, make something substantive with it, and stick with it until you actually grok it. Ask for help from the FP Slack! Seriously, don't just pick it up, get stumped by error messages, and give up. The tooling is very beginner-unfriendly, but fortunately the humans over at the Functional Programming Slack (https://fpchat-invite.herokuapp.com/) are VERY friendly. As a first project, I'd recommend doing the Advent of Code, or building a small web application (IMO with Scotty, which feels like Express, rather than Yesod, which feels like Rails. Yesod is almost certainly better in production, but has a different and IMO less instructive learning curve). If anyone needs help, follow along with my AoC 2020 (https://github.com/liftM/advent2020), although be aware that some things I do there are a bit fancier than necessary.

I find that articles like this that complain about things like type abstractness or the mathy concept names really are not representative of the actual pain points with Haskell, and are FUD more than useful. Yes, the tooling is beginner-unfriendly. Yes, you will probably need to ask some questions on the FP Slack on your path to learning, things that a friendlier language would have documented. But this mystical aura of "ooh, there are types and they are very abstract!" is not reflective of reality, is not a criticism grounded in the reality of writing Haskell, and IMO is misleading for people genuinely trying to assess the language.

ColinWright• 6 years ago

I have coded in Haskell, although only to get a sense of it, and quite a long time ago. I'm not going to pontificate about it here, but I would love to be able to filter these comments based on the length and depth of experience of the commenter, both in Haskell and other language of choice.

There's a lot being said here that's true, and a lot that's personal opinion. I'd love to know the personal experiences that drive those opinions.

Alas, I suspect we will get the opinions, but no way to assess how accurate they might be.

dathinab3• 6 years ago

In my opinion the problem with Haskell is that terminology from computer language research (e.g. type theory) bleed into language which combined with sometimes appearing "elitarism" makes it just not very appealing for anyone not being deep into the relevant parts of computer since research.

I mean I don't need to know how engineers speak about the internals of my car to drive it (but it can be helpful), but Haskell kinda expects that.

Also it's not uncommon in Haskel to see functionality named not after what it does but after the theoretical computer since properties it has. Which might describe how you can combine it on a type system level but isn't that useful for easily writing programs and makes any "types as documentation" much worse.

FridgeSeal3• 6 years ago

I suspect this is because Haskell is proudly a "research"/bleeding-edge language. It's distinctly _not_ a Java or a .Net and that's ok, as it's not trying to fulfill the same role.

Things in Haskell have names from theoretical computer science, because people are using it to express and experiment with those ideas - they don't need or want to spend undue time describing a monad or a functor for the 15-millionth time, they want to use them in some new cutting-edge way.

I once saw (on this website) Haskell described as "the primordial soup of programming language features". Wild and weird ideas get tried-out in Haskell, and then 5-10 years later someone takes the lessons learned from the evolution of some feature in Haskell and brings it to mainstream programming in some elegant, distilled form. And I think that's super cool.

sfvisser• 6 years ago

Haskell has many problems, but this really isn’t one of them.

sordina• 6 years ago

Please keep in mind, when Haskell introduced some of these features they decided to take existing terminology from theory rather than make something up. The big benefit from this is that people already with the theoretical terminology have an intuition to start from, plus, users of the language also build some intuition for the theory. Win win. Given that they often broke ground on the features and couldn't borrow from other languages can you say this was a bad decision?

colonwqbang• 6 years ago

Abstractions with types is a bad type of abstraction because it ignores the basic fact that programs deal with data, and data has no types.

Or in the conventional Haskell notation:

data HasNoTypes = BasicFact

Yet, everyone is busy adding typing to their favourite dynamic languages. Even languages like Javascript which whose designs show open contempt for the idea of type safety, are now getting support for static typing (typescript/flow).

dotdi2• 6 years ago

A very clear indication of this is how Haskell treats programming terms. Instead of explaining Monads like all other design patterns out there, they insist on using some obscure definition from category theory to explain it.

The author is bashing people for explaining a concept from Category Theory with... dum dum dum... Category Theory?! Just because OP was looking for articles explaining monads as design patterns doesn't mean there aren't other people who, God forbid, are looking for theoretical articles about CT/Monads explained with Haskell.

Yes, there is value in pragmatism. Rant posts, on the other hand, have little value IMHO. Haskell has shortcomings like any other programming language. That absolutely does not make it a bad programming language.

dathinab3• 6 years ago

Rant posts, on the other hand, have little value IMHO.

Sure ;=)

But Haskell's explanations of Monads is in my experience really no adequate. Category Theory is the underlying since theory, but do you need to know about mechanics and gears to drive a car?

There are explanations of Monads which are much much easier to understand for most people (people not having much to do with Category Theory).

E.g. by now the concept of map, flat_map is fairly wide spread in most programming languages and you can teach about Monads in terms of that fairly easy. And then add the additional abstraction layer used in context of Monads like abstracting over the "external world state" (IO) and "combining computation descriptions".

dotdi2• 6 years ago

but do you need to know about mechanics and gears to drive a car?

Depends on what you are trying to do. You don't need that knowledge in order to drive a car, but there are drivers that absolutely should know about mechanics and gears.

davorak5• 6 years ago

But Haskell's explanations of Monads is in my experience really no adequate. Category Theory is the underlying since theory, but do you need to know about mechanics and gears to drive a car?

Monads are part of the underlying category theory. So asking for a full explanation of Monads you are asking to explain part of the "mechanics and gears" in your car analogy.

E.g. by now the concept of map, flat_map is fairly wide spread in most programming languages and you can teach about Monads in terms of that fairly easy. And then add the additional abstraction layer used in context of Monads like abstracting over the "external world state" (IO) and "combining computation descriptions".

I think I agree with your main point here that teaching the internal details first is often not the optimal method. You do not need to know how Monads work to use them to great effect in Haskell and other languages.

sweeneyrod• 6 years ago

I think that 99% of programmers can get approximately all the value of monads by reading an article explaining how promises, options and lists all have this pattern in common, without any mention of monoids or endofunctors. I enjoyed the courses I did in category theory very much, but the benefit to my code has been zero.

Ericson23144• 6 years ago

Well to be fair, Functor and Monad in base are pretty far removed from the Category Theory originals.

https://hackage.haskell.org/package/categories has something much closer to the math.

Maybe we should just save the math explanation for the latter, and just call the former something else? :O

Snarwin• 6 years ago

Explaning monads in terms of category theory is like explaining regular expressions in terms of finite automata. It's a good idea if you're writing a textbook, but maybe not so much if you're writing documentation for users of a programming language.

dnlkrgr• 6 years ago

It's always amusing to read critiques on Haskell written by people that don't know Haskell.

This entire post is borderline trolling and it's sad so many people are falling for it.

cuddlecake• 6 years ago

I feel like being Anti-Haskell is becoming a ridiculous meme.

The author makes a lot of statements, but no arguments, no proofs, and no explanations.

Also, the post is riddled with "The Community does X" memes, such as:

Funnily enough everyone in the Haskell community blamed everyone else instead of [...]
[Senior Developers tell you to just] write types and interfaces for the types and fill in the blanks
Look, even most haskellers would agree that purescript is a better choice compared to GHCJS
[Haskellers are] using some obscure definition from category theory to explain [Monads]
Haskell proponents try to claim that type signatures are somehow documentation
Every few months some newbie comes along to the Haskell reddit and asks why is Haskell documentation so confusing, and the post get destroyed by people telling them to get good or just pointing at academic papers. Really?
suddenly their precious castle [of type declarations] is reduced to dust

and the author does not give a single link or concrete example, not a single proof or evidence of this actually being the case. In the author's defense, I would also think that the Haskell Community behaves exactly like that, if I had taken every comment on HN about Haskell as being correct and truthful.

One very absurd claim by the author that I'd like to point out is:

programs deal with data, and data has no types

All data has a type (structure, schema, intent), otherwise it wouldn't be data. Instead, it would be electrical noise.

Types wrap data and treat it like a black box whereas schema describes the shape and content of data.

I don't understand why the author makes a distinction between "types" and "schema". I get the feeling that the author makes the distinction only to bash on Haskell because Haskellers will talk of "data types" and not of "data schemas".

Suddenly they are left reeling as they find out that the real world is, in fact, dynamic.

That's why Haskell has `Maybe`, duh. I don't buy into the statement that the "real world is dynamic". It's just as slogan-y as "The Real World is Object-Oriented", because it seems to be trivially observed, BUT, programming is not the Real World. One programmer has a data type that he/she sends over the wire. It would be weird if another program didn't anticipate the data but could still handle it correctly without expecting the data to have a certain type. Programming is not dynamic, programming is guessing "what the fuck did the other programmer try to send me" and defining a type for that. This is done either implictly by just accessing the fields or explicitly by defining the type and parsing the data.

---

All in all, I feel like this post adds nothing in value, and I am very annoyed that it has been ranked #1 on HN, but this stays consistent with how I personally perceive the broader HN Community.

Sidenote: I am not a Haskell Developer.

dathinab3• 6 years ago

I'm not sure why the article hates on types that much I mean:

- schemas are types

- types do not require encapsulation ("even" in java "plain old data" type which do not give any encapsulation are a thing)

- many popular languages without static type ascription have by now added optional type ascription or there exists a derivative which do so which are recommended for larger projects (e.g. TypeScript and python3 type hints)

- I can understand why people might not like nominal type systems, or to many explicit type ascription.

- In my experience when maintaining & changing software having a proper type system is making the task easier and faster (if the type system is not abused, idk how common type system abuse is in Haskell). And in my experience non nominal type system as seen in TypeScript are already helpful making changes easier then in JavaScript. But it's still harder to change (larger projects) in TypeScript then e.g. in Rust (assuming the type system was not abused!!).

- To be fair abusing type systems is in my experience often worse then not having a nice type system.

cannabis_sam3• 6 years ago

I used to hate on types, largely because I had mostly learned to program in Java, where you hade to write the name of the type twice just to initialize an object, and just the general tendency in Java to rely on explicitly specified types everywhere.

I felt that the value gained from all this extra work was minimal, so when I got into Python it felt like being unshackled from utterly pointless chains.

After around 10 years of developing in Java and Python/php, I learned Haskell, and realized that types are only shackles in languages that refuse to utilize them in an efficient and useful manner (i.e. type inference instead of endless type specification or type casting at every point of mutation. And don’t even get me started on the destructive horrors of automatic/implicit type coercion..)

In Haskell, types feel like the nubs on jigsaw puzzle pieces, guiding you to what (potentially) fits together, which drastically reduces the amount of programming details you need to keep in your head, so you can focus on the actual, fuzzy, real-life semantics of the system your developing.

dgellow• 6 years ago

One niche I'm curious about is the use of Haskell for blockchains and smart contracts. Cardano is one of such project: https://docs.cardano.org. It's still very experimental and won't have smart contracts before March/April of this year (likely to be later). The blockchain and their smart contract DSLs are implemented in Haskell, that will be interesting to see how that compare to what Ethereum is doing with Solidity.

kodefant• 6 years ago

About Haskell missing pragmatism, ever tried IHP? I don't think the development environment sucks, but you are free to disagree. In my opinion, the developer experience is ultraslick, it's easy for beginners to get started with and there is very little type theory to getting started.

Yes, Haskell has been bad at teaching to beginners, by forcing people to learn theory before build something, but it has been really catching on for the better recently.

I think a "bad" and "good" programming language can be subjective, but I have never tried more enjoyable languages than Elm and Haskell. I feel confident using these languages because of the static types.

Some will probably say that the usefulness of types is an illusion and I can live with that, but I don't think it is.

js8• 6 years ago

IMHO, Haskell is a bridge between practical programming and mathematics. That's why they use "monad" instead of "flatMappable", for example. It is connecting two different languages that cover the same concepts.

Regarding types, there is a talk from Gilad Bracha titled "Types are antimodular", and it makes a similar argument as the article.

nvarsj• 6 years ago

Haskell has plenty of legitimate criticisms for use as a production language.

However this article isn't it. Please don't read this and repeat the opinions posted here. A lot of what the author says is just plain wrong and shows a misunderstanding of basic functional idioms.

For example: "Functors are basically an Object with a internal state changing method in typical OOP terms." Uh, no. Functors are stateless, with a well defined semantic. This is nothing like an object with internal mutable state, with instance methods that mutate it in god-knows-what-way.

There are a lot of mischaracterizations like this in the article.

nix233• 6 years ago

>Haskell is not too hard to learn.

Obviously he did no even that then.

IshKebab2• 6 years ago

Hard to disagree with the premise, but the rambling that follows doesn't exactly argue the case very well.

fbn79• 6 years ago

I think we can find many analogies between the history of "Haskell/FP vs Mainstream Languages/OOP" with that of "RISC vs x86/MIPS". The article says Haskell is hard to learn/use and not appetible for business. A similar article could be written about RISC architecture in 2007 when x86 ruled. Then Steve Jobs built the iPhone and with it an empire based on RISC architecture. And now Apple Silicon it's threatening desktop and servers, last standing of X86.

cute_boi2• 6 years ago

"When you’re reading this article, or talking to someone, do you claim that you’re saying a string, a number, a Text, or something else. No! Data is simply data, and data is inherently dynamic"

I think I disagree with this one. Yes data are inherently dynamic but every data usually have types associated with it. For me type is like rule. Eg u8 is a 8 bit unsigned int which is 0-255 is just a rule.

In English we have grammar which is rule or another type so to speak. a-zA-z etc doesn't make meaning on its own but a combination of rules make it meaningful and beautiful.

Thank You.

madsbuch2• 6 years ago

The article is generally imprecise, and I completely agree with you. Stating that `... data is inherently dynamic` in this context is plain and deductively wrong. If we can not add type to data, we can't even interpret it as a bit-string because, hey, it's a type! (the type of a string of 1's and 0's)

Types are mostly used to reason about a program internally. But sometimes we need to consider the real world. When doing do we need to interpret data. In the Haskell-sense this means assigning types to it.

A language like Elm has exemplified how the internal / external data barrier can be implemented for strictly typed languages. Haskell just considers everything a string and lets it be up to the developer to parse it.

414owen2• 6 years ago

I'm very sorry OP didn't stay the course, and opted to write an angry post instead.

Every few months some newbie comes along to the Haskell reddit and asks why is Haskell documentation so confusing, and the post get destroyed by people telling them to get good or just pointing at academic papers.

The Haskell subreddit has a monthly 'Hask Anything', and is generally a friendly forum.

I searched: https://www.reddit.com/r/haskell/search/?q=documentation%20&... and was unable to find any such behavior. In fact, people asking for documentation were generally helped: https://www.reddit.com/r/haskell/comments/eo7orr/where_to_fi...

“Haskell doesn’t suck, the development environment does”

There are certainly people who would agree with this, however our language server is pretty complete nowadays, we have amazing static analysis tools, a variety of formatters, I can't think of any tooling I desperately miss. Then again, I'm an editor person, not an IDE person...

Write types and interfaces for the types and fill in the blanks. Sounds familiar? Because that’s we’ve been doing with Java and the like using UML

Ouch. It's very rare to hear anyone complain about having a type system with strong guarantees. UML... Well I guess I'm not a fan of specifying your design outside of your source code...

Professional developers find themselves describing the system in such concrete ways using types that when the requirements change suddenly their precious castle is reduced to dust

Hmm, so generally the better at Haskell you are, the more you express constraints in terms of Haskell constraints, rather than concrete types. It's a style called `Tagless Final`. I recommend taking a look. It gives you strong guarantees, without breaking any castles.

Somehow Haskellers think that they are more productive with Haskell when the reality in the real world is that only a few languages can proudly make that claim, such as Python and Lisp. These are languages battle tested in actual software products

As other people have pointed out, there are companies that use all three of these. I think it's safe to assume OP didn't measure the productivity of any developers before writing this.

Abstractions with types is a bad type of abstraction because it ignores the basic fact that programs deal with data, and data has no types

Have you heard of datatypes?

In most cases people are looking for schemas, not types

Schemas describe the structure of data. Types describe the structure of data.

Types wrap data and treat it like a black box whereas schema describes the shape and content of data

The former here is actually more of a slight on encapsulation, which is something you can do in Haskell, but is probably more a goto recommendation of OOP languages. It can be pretty useful to only expose the inferfaces you want, and hide the implementation.

most haskellers would agree that purescript is a better choice compared to GHCJS. No man is an island, and yet Haskellers generally convinced themselves that other languages need to learn from Haskell

Are you saying Purescript didn't learn from Haskell? Have you seen PureScript?

Instead of explaining Monads like all other design patterns out there, they insist on using some obscure definition from category theory to explain it

Pick a monad explanation that suits you. There are plenty of posts / tutorials online. Some people like burritos, some people like mathematics. I recommend looking at the type of (>>=), as in the end, that's the only operation a Monad adds (above Applicative)...

Look, when monads are used without the infix notation, the result is horrendous and it looks like yet another callback chain

I think you mean when they're used without `do notation`. This point seems moot, seeing as we have do notation. Explicit binds can be readable, if you're going pointfree.

I tried it myself. Of course, there are very smart people who do understand Monads, but most people would just tell you to “get an intuition for it”, which to be honest is total BS

You'll get there, I recommend leaving the do-notation behind, and writing some functions over Maybe, [], and Writer.

Don't give up on the learning process, there's still time to write a `How I learned Haskell` blog post, or maybe you can write the umpteenth Monad tutorial :)

pi-victor• 6 years ago

i would say, that because it is a hard language to learn, it holds itself back. otherwise it would thrive, people would be interested in it, libraries would flourish.

I feel Rust is somehow in the place as well, it has a rather steep learning curve and there are not enough mature libraries out there because of this.

mark_l_watson• 6 years ago

I have been playing around with Haskell for many years, and wrote a short Haskell book. That said, I still consider myself a newbie at the language and have only used it for customer work one time.

Many years ago, I set aside learning Scala for a while, dug into Haskell (again), and for reasons that I don’t even understand myself, I then had an easier time using Scala. Same comment for Clojure (not my favorite language by far, but I have used it often professionally).

One thing resonated in the article “Very senior Haskellers calls for “type oriented programming” which goes like this: Write types and interfaces for the types and fill in the blanks.” I prefer just using simple types, and one thing I like about Clojure is just using the built in simple data structures.

In any case, I think it is very worthwhile using a wide variety of languages but I understand it when other people prefer to not spend the resources experimenting.

zacwood• 6 years ago

I discovered Haskell in a comparative programming languages course I took at university last semester, and it completely changed how I think about programming. I can't speak for an industrial use case, but for a hobbyist writing open source software and personal projects, programming in Haskell has been an absolute joy and has reinvigorated my love for programming.

Tools like IHP (https://ihp.digitallyinduced.com/) are a great example of not only the beauty of the language, but when combined with Nix and the IHP IDE, a better development experience than I ever had with Rails or any other language.

If you are pragmatically minded, you can get stuff done in Haskell. In my experience there's a lack of online resources for this kind of work in Haskell, but that's what I and others especially in the IHP world are working on. If you just want to experiment, Haskell is great for that too.

voidhorse• 6 years ago

Haskell has it’s fair share of problems, the major one being pointed out in this article, that in spite of all of SPJ’s noble efforts it’s still primarily stuck in the “ivory tower”, bogged down by tons of libs and docs that are full of academic or theoretical jargon, and unfortunately plagued in some sub communities, by people that have intellectual superiority complexes, which makes it alienating to a large number of potential users and leads to bitter posts like this.

But in terms of the language itself, I really don’t see the issues raised here and the author of the article comes off as having not understood the language very well. Libraries like Euterpea show that the language is insanely expressive and that they’ve, IMO, created a language that is very solid from a language design perspective. Sure there are wrinkles like records, but otherwise it’s generally pretty great from an expressive power standpoint.

Communication only works when people are speaking the same language. Of course you are going to struggle when that language is different than what you are used to (lazy, functional, pure) but if you spend time in language classes and eventually learn it, you’ll find that you can probably communicate your ideas just as well in this language too. If you decide you don’t like the sound of the language then don’t communicate in it, but that’s your choice, it’s not a knock on the language itself. This article feels like it was written by someone that struggled to learn Haskell and gave up and ranted about it rather than persevering or simply deciding it wasn’t for them and moving on. If you are comparing functors to objects in OOP I don’t think you actually groked it.

jtdev• 6 years ago

Functional zealotry seems to be at the core of most problems with Haskell. It’s unfortunate that these concepts keep being shoehorned into numerous other languages.

Ericson23144• 6 years ago

abstractions ultimately leak

This is where they really loose me. No, they don't. Only bad abstractions leak.

How did real limitations with statistics ("all models are wrong, some are useful") mutate into pessimism about designed, not discovered, systems? When did we all become such mindless empiricists?

nix233• 6 years ago

Spoiler alert. It did not.

Really?

https://wiki.haskell.org/Haskell_in_industry

carapace• 6 years ago

In re: Haskell's goodness or badness, compare and contrast with, say, PHP (crap language with wild success.) Or Prolog (a stately Elven language with deep but obscure success.) Haskell is what it is.

In re: types and data, FP is good for that. See e.g. "Domain Modeling Made Functional" by Scott Wlaschin ( https://www.youtube.com/watch?v=Up7LcbGZFuo ) it's about F# but the concepts apply cross-language.

In re: FP PLs "done right" I submit Elm lang. I've been using Elm recently and it gets the job done. It's weird though: on the one hand, as a experienced professional it feels like a toy. The error messages feel almost insulting, like I'm being patronized. On the other hand, once I got over that (silly) reaction, they're awesome. Changing code is a breeze, because Elm leverages the crap out of the type system, and the structure of the code and runtime prevent whole vast categories of errors.

Combine that with the sort of Domain-Driven development that Wlaschin is talking about and "baby, you got a stew going!"

KurtMueller2• 6 years ago

I was introduced to OCaml through Elm - a deeply-opinionated language with strict guard rails. In Elm, there is either a happy path or there is no path. As a newcomer, you're not overwhelmed or paralyzed with a plethora of choices on how to get things done simply because Elm limits your choices. Each tool in your toolbox is documented with simple examples how to use that tool.

After finally jumping the fence and exploring/devving with other OCaml languages (specifically F#), I still come back to Elm to see how it and the community does things: namely their best practices and explanation of fp concepts.

butterisgood2• 6 years ago

I can't believe how much I like this font choice on that blog post!

ur-whale• 6 years ago

Haskell : because there must be a place where ivory tower mentality folks can convene in peace.

butterisgood2• 6 years ago

I find the "I'm more productive with Python" claim in the post to be specious.

Maybe I've been abused (and abusive) by bad programming practices with python in the past, but it seems you really need to lint and exercise python code to have any kind of confidence that something you think is correct won't blow up at runtime.

False confidence that something is "ready to go", is the worst, and it can cost a lot of money, and sometimes human life.

Erlang has this problem too. It's so late binding you can make spelling mistakes and it won't be caught until runtime. It's actually the basis of some very powerful features, but you really have to know that coding in Erlang is not like coding in Rust, Haskell, or something else strongly typed.

So while I think the author has a point that concretions can get you into an inflexible, hard to refactor mess over time, I think sometimes those concretions don't have to be as bad as they seem.

Consider Go. Interfaces are a form of concretion too, but the advice is to keep them small. An interface of exactly one function can be a beautiful thing. I think it's better to have a type implement many interfaces than to have a type implement one huge interface.

adsharma3• 6 years ago

python3 has type checkers. I like pyright. You can use protocols which are similar to Go interfaces.

The benefit of go is really in performance and packaging.

psychometry• 6 years ago

I've gotta say...the font (Magnetic Pro) used on this site might be one of the worst-designed typefaces I've ever seen. It honestly looks like a random mixture of two bad typefaces.

daxfohl4• 6 years ago

So if we were to create something new and Haskell like (pure, closer to Haskell than OCaml or Rust), then what should be different?

bluepoint• 6 years ago

Does it explain why I got truly fascinated by Haskell and at the same time I did not feel like writing any useful program in it? (not that I ever write useful programs, just saying).

adsharma3• 6 years ago

Counter point:

This has nothing to do with the programming language in question. The anti-abstraction, everything must be concrete argument leads to madness. You can do type oriented design with python3 or typescript.

Since writing this, I've discovered other systems with the same general philosophy:

* Avro IDL * Fuschia/Zircon and the associated IDL (FIDL)

https://adsharma.github.io/flattools-programs/

whateveracct2• 6 years ago

I know Go. I know Rust. I know Haskell.

Any project I have built with Haskell, I could have with any other language. Maybe even faster (for some definitions of fast) But not with as little personal labor. I've found that no matter the scale, Haskell allows me to solve it without effort. Because I'm not jerry-rigging commands to do what I want. I just eventually Solve the problem.

I say this as a computer engineer, so "how the computer works" is my training. But god it's nice to build things without the inherent manual labor of imperative programming.

Haskell is a Bad Programming Language (2020)

Related Stories