"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: