Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Joy and Agony of Haskell in Production

stephendiehl.com

Post reply on HN
Print view View original

71–80 of 94 posts

Re: The Joy and Agony of Haskell in Production

#71

Post by Drup »

rwmj wrote: post #19

Good article. I'm involved with a large-ish OCaml project[1] and some of these things apply there too. In particular we avoid "academic" features of the language like functors[2] and first class modules, because they obscure the flow of the code and are a headache for ordinary programmers to understand. I often get requests from people from the OCaml academic community asking if we have any available positions, and t…

I understand why one would avoid first class modules (I don't use them a lot either). However I fail to see why functors are too complicated, since they are basically just functions. Could you explain ?

Also, according to this[1], There are basically three main contributors, including you, so I fail to see how training would be an issue ...

[1]: https://github.com/libguestfs/libguestfs/graphs/contributors

Re: The Joy and Agony of Haskell in Production

#72

Post by iopq »

javiercr wrote: post #26

> Haskell code tends to be of high quality by construction, but for several reasons that are only correlated; not causally linked to the technical merits of Haskell. Just by virtue of language being esoteric and having a relatively higher barrier to entry we’ll end up working with developers who would write above average code in any language. I think this happened to Ruby for some time, not anymore probably. Maybe th…

I think it's already happening with Rust. People are doing really cool things with it.

Re: The Joy and Agony of Haskell in Production

#73

Post by illumen »

iopq wrote: post #72
javiercr wrote: post #26

> Haskell code tends to be of high quality by construction, but for several reasons that are only correlated; not causally linked to the technical merits of Haskell. Just by virtue of language being esoteric and having a relatively higher barrier to entry we’ll end up working with developers who would write above average code in any language. I think this happened to Ruby for some time, not anymore probably. Maybe th…

I think it's already happening with Rust. People are doing really cool things with it.

Any top apps?

I don't think you can beat other languages yet, except in some very niche areas. There's not even incremental compilation!

Hell, even python can infer function types these days!

Rust has been around much longer than Swift for example, and yet there are many very more production Swift apps. Whereas rust seems limited to play stuff.

Of course, given another 2-5 years it should catch up in many ways. Comparing it to mature languages, or languages like Swift (from the worlds largest company paying some of the worlds best language developers) is not really fair.

Definitely a play ground for enthusiasts at this point. Which I guess is what you meant.

Re: The Joy and Agony of Haskell in Production

#74

Post by klibertp »

ScottBurson wrote: post #67
klibertp wrote: post #22

Earlier quoted context omitted.

"Living" being the a key word here. I was astonished when I started learning Common Lisp last year: the language, despite its warts, feels modern and convenient, and the ecosystem - SLIME, asdf & quicklisp - is impressively well designed and surprisingly nice to use.

Yes, CL does have its share of historical baggage and warts. Despite those, I think it's still the best dynamically typed language. The rich number types, with arbitrary-precision integers by default, single- and double-floats, ratios, and complex numbers all built in; macros; and multimethods -- CL still has major features that the other dynamic languages, rather inexplicably to my mind, have yet to embrace. It's al…

> it's still the best dynamically typed language

One of the best, for sure. There are Racket and Clojure in the Lisp family, both comparable to Common Lisp in terms of features. Outside of that, there is Elixir, which in my mind gave Erlang enough additional features to also finally be at that level. Pharo is another language - a modern Smalltalk-inspired, image based GUI environment - which comes close in terms of expressivity, but is nowhere near CL implementations in terms of stability. There's also REBOL and recently also Red. They all differ, of course, but what they have in common is the amount of features such languages offer and the unique kind of synergy you get from each of them. It is still unmatched by currently mainstream dynamically typed languages.

> you might appreciate my functional collections library for CL

Thanks, looks interesting. I'll take a look later. I think one of the most irritating things when I started learning Common Lisp was weird naming of common functions. In Emacs Lisp-land we got dash.el and s.el which made the situation (mostly) better; similar thing was done by Underscore.js. I think something like this could be helpful in CL - maybe your library could fill that role for me.

Re: The Joy and Agony of Haskell in Production

#75

Post by nightski »

wiz21 wrote: post #68
incepted wrote: post #13

Earlier quoted context omitted.

If the language you want to work in is so important, you should have picked the company first and the location second. Besides, data outlives code. By orders of magnitude. You seem to be in love with Haskell today, chances are you'll be using a different language in ten years but the data you'll be working with will probably have been around for much longer than that. Don't fall in love with programming languages, it…

That's a very insightful comment. I 100% agree. And I'd add that I'm still completely baffled to see that some very obvious data support issues are still not resolved in the industrial world (e.g Java) : * Computing with units (which is tough to put in a language, but so is compilation) * Computing with dates in a sensible way Of course one can make computation on those types, but it is so un-natural that it scares m…

I fell in love with Haskell for quite some time. In fact, I still really enjoy the language. But after a while I noticed that I was not in love with Haskell itself but some of the things it brings to the table which are very important. Sure there may be new languages in 50 years in the mainstream, but let's hope we learn from our past successes and failures. In that sense, it pays to care about languages today as they will directly impact the future.

If we all give up and just use mainstream languages, then the future will be filled with copies of mainstream languages.

Re: The Joy and Agony of Haskell in Production

#76

Post by EdwardDiego »

wiz21 wrote: post #68
incepted wrote: post #13

Earlier quoted context omitted.

If the language you want to work in is so important, you should have picked the company first and the location second. Besides, data outlives code. By orders of magnitude. You seem to be in love with Haskell today, chances are you'll be using a different language in ten years but the data you'll be working with will probably have been around for much longer than that. Don't fall in love with programming languages, it…

That's a very insightful comment. I 100% agree. And I'd add that I'm still completely baffled to see that some very obvious data support issues are still not resolved in the industrial world (e.g Java) : * Computing with units (which is tough to put in a language, but so is compilation) * Computing with dates in a sensible way Of course one can make computation on those types, but it is so un-natural that it scares m…

> Computing with units (which is tough to put in a language, but so is compilation

F#'s units are nice.

> Computing with dates in a sensible way

The new Java time API is pretty good. But honestly my favourite datetime API would have to be Postgres'.

> BigDecimal for currency, let me laugh

Out of curiosity, why?

Re: The Joy and Agony of Haskell in Production

#77

Post by steveklabnik »

illumen wrote: post #73
iopq wrote: post #72

Earlier quoted context omitted.

I think it's already happening with Rust. People are doing really cool things with it.

Any top apps? I don't think you can beat other languages yet, except in some very niche areas. There's not even incremental compilation! Hell, even python can infer function types these days! Rust has been around much longer than Swift for example, and yet there are many very more production Swift apps. Whereas rust seems limited to play stuff. Of course, given another 2-5 years it should catch up in many ways. Compa…

Dropbox has Rust at the core of their product now. We have a fair amount of production use.

Re: The Joy and Agony of Haskell in Production

#78

Post by ch0wn »

moomin wrote: post #66
tamana wrote: post #45

Earlier quoted context omitted.

Not in OCaml. It's a different concept.

There seem to be a hundred language definitions of Functor. Even Haskell's doesn't exactly correspond to the mathematical understanding of the term (if it did, Set would be a functor) C++ is the worst offender, though.

How is Set a functor in a mathmatical sense?

Re: The Joy and Agony of Haskell in Production

#79

Post by kibwen »

illumen wrote: post #73
iopq wrote: post #72

Earlier quoted context omitted.

I think it's already happening with Rust. People are doing really cool things with it.

Any top apps? I don't think you can beat other languages yet, except in some very niche areas. There's not even incremental compilation! Hell, even python can infer function types these days! Rust has been around much longer than Swift for example, and yet there are many very more production Swift apps. Whereas rust seems limited to play stuff. Of course, given another 2-5 years it should catch up in many ways. Compa…

Swift reached 1.0 a full year before Rust did. Just because Rust was developed in the open and Swift wasn't doesn't mean that Rust has been usable longer than Swift. :P

Re: The Joy and Agony of Haskell in Production

#80

Post by insulanian »

steveklabnik wrote: post #77
illumen wrote: post #73

Earlier quoted context omitted.

Any top apps? I don't think you can beat other languages yet, except in some very niche areas. There's not even incremental compilation! Hell, even python can infer function types these days! Rust has been around much longer than Swift for example, and yet there are many very more production Swift apps. Whereas rust seems limited to play stuff. Of course, given another 2-5 years it should catch up in many ways. Compa…

Dropbox has Rust at the core of their product now. We have a fair amount of production use.

Aren't they sold to Go?

https://twitter.com/jamwt/status/629727590782099456 https://blogs.dropbox.com/tech/2014/07/open-sourcing-our-go-...

Post reply on HN