"Worse is better" is a belief, not a fact - Haskell

Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.

Sridhar Ratnakumar

So, Haskell, I conclude: it was definitely worth my time, even if it had only been so I can understand PL research papers. I can wholeheartedly endorse you learning it as well. But I'm sad to say I don't imagine myself basing a new major project (or company) around it.

Strangely lately I've been writing a lot of code in Go, which seems to have attracted a lot of other people I know. I think of the Go language as sort of the anti-Haskell: visually ugly, semantically warty, written with apparently little regard for the state of the art in research — but on the other hand, incredibly pragmatic throughout. A shining example of worse is better.

http://neugierig.org/software/blog/2011/10/why-not-haskell.html

James King

That is an odd opinion. "Warty" semantics make Go more pragmatic than Haskell?

James King

That's a valid trade-off but to categorically exclude Haskell even when what you need is a language with Haskell's features seems premature.

James King

Haskell is incredibly pragmatic throughout. Maybe we need more blog posts and articles about the practical aspects of Haskell.

James King

I find that even terribly written, no good, down and dirty Haskell is easier to work with and refactor into a clean, maintainable program than the same in C++...

Asad Saeeduddin

I wonder what the golang circle on that diagram would look like

Hazem

It's worth mentioning that this post is from 2011. I don't know about the state of Haskell back then (specifically in terms of tooling/libraries/docs), but Go was still new and shiny when the author made this post (Go first appeared in 2009) and that may have had an influence on the conclusion of the post.

Joel McCracken

a lot will have changed

Joel McCracken

"... compile it due to the "DLL hell" that is package versioning of Hackage" solved with stack and maybe cabal sanboxes, depending upon things

Joel McCracken

so one thing in my philosophy to add to this is that getting started with a new tech on a project is largely a function of how familiar that tech is

Joel McCracken

and getting familiar is a one time const

Joel McCracken

whereas maintenance pain is an ongoing problem

Joel McCracken

But, i can easily imagine being familar-enough with enough of haskell to make it faster to prototype in than say ruby

James King

I like using Haskell for prototyping now more than say, Javascript or Python, because I spend less time worrying about defined-ness or duck typing and more time on the actual problem.

James King

Asad Saeeduddin said:

I wonder what the golang circle on that diagram would look like

I'd imagine the circles would be inverted.

( code written in go (code that works) )

James King

But to be less snarky... it took a while to get comfortable enough with Haskell to use it for rapid prototyping. As it does with pretty much any language you haven't been using and practicing with for years.

TheMatten

It does require more principled approach to prototyping though - you can't really mash random blobs of POC code together, instead you may need to take more top-down approach... unless you use -fdefer-type-errors :big_smile:

Julian KG

As one of the few people who really likes Go let me add to this thread really late. I think Go is a great language for correctness relatively speaking. In my opinion the reason why Haskell is so great for correctness is not just that it gives you certain compile time guarantees, but that it frees up that space in your brain to focus on solving logic problems. When I'm writing Go I only think about how to solve the problem, not any of the complexities of the language. And for difficult problems (resource managment, concurrency) they give you easy to use custom built tools (defer, channels). This is why I was a big person pushing against Java style generics when everyone was clamoring for them. Writing generic code is hard, and when things don't need to be generic they shouldn't be. Go sometimes feels awkward and verbose sometimes especially from a Haskell background, I'm not going to sugar coat it. But I have yet to find a difficult to read Go project, and I can't say the same about Haskell. Under abstraction is better than over abstraction in my opinion.

Julian KG

I'd also like to add that IMO Go is not really competing with Haskell in my opinion. Go's biggest problem IMO, is there are some things it just isn't powerful enough to do (this may be changing with generics, but I'm not convinced). Something like LLVM will never be written in Go. The languages Haskell competes with are typed languages with are other swiss army knife languages like C++, and dynamically typed languages which achieve Haskell-esque expressiveness by throwing out guarantees.

Georgi Lyubenov // googleson78

Go is competing with Haskell, at least in my company - we have services written in both

Rizary

whose win? This happen to me, when it more easy to find Go programmer than Haskell one, or when we are afraid if only few people can maintain Haskell code, Go win.

Georgi Lyubenov // googleson78

well I can't say "win" or "loss" - they're coexisting, it's just different teams

Georgi Lyubenov // googleson78

personally I really would rather not give up servant and all the things that come with it

Joel McCracken

I have not written much go at all, but I have seen go and what I have seen is extremely verbose

Joel McCracken

it can be quite hard to grok because of that, and also the lack of controlled effects means you have lots of things happening

Daniel Díaz Carrete

I'm not fluent in Go, but there seem to be things that are better. Not "worse is better" better, but "honest-to-God better" better. Things like struct tags to decouple serialized field names from the internal field names of structs, and also this: YouTube - Phil Wadler: Featherweight Go

Joel McCracken

Haskell is pretty old. It would be quite surprising if you couln't find anything in a language made 20 years later that was better in some way.