[incepted]

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's a waste of emotional energy.

[wiz21]

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

* BigDecimal for currency, let me laugh * Date/timestamp without proper casting rules * Types towers with inheritance, generics, etc. Pfff... * Still no fine library to represent an address * Representing mutable ordered lists in SQL databases is still quite painful (possible, sure, but there's so boiler plate code to write)

So the data representation/manipulation problem, which goes with the data longevity you observe, that's something to learn about...

There's no reason to love current programming languages :-( (but I do love Python :-) 3 of course :-))

[EdwardDiego]

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

[wiz21]

For F#, I didn't know. It looks verrrrrry sweet.

For BigDecimal, my grief is that it makes code horrible (at least in my experience, I'm still locked in JDK 1.7).

BigDecimal has the problem I see with the rest of my griefs : it is possible to compute things correctly with code (obviously), but the way the code is written is ugly (and painful).

   BigDecimal yearly_amount = new BigDecimal("1000.00"); 
   BigDecimal daily_amount = yearly_amount.divide(new BigDecimal("12")); // Beware the rounding issue

Wouldn't it be nicer if :

   money<4> yearly_amount = 1000.00 EUR; // 4 decimals 
   money<2> daily_amount = yearly_amount / 12; // Beware the rounding issue !

Of course, this notation doesn't help much with rounding, but at least it makes the code easier to read. And trust me, using BigDecimal, doesn't prevent many people of making mistakes with rounding.

[EdwardDiego]

True, but it can do, if you set precision etc.

[nightski]

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.