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.

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

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

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.

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

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.

come work for me. you'll have to work remotely cause a mountain view office is still in the planning. i will gladly compensate you for your efforts at a rate of 5 cheetos an hour.

"when people are ready to engineer code that lasts 1000 years"

Actually, as silly as it sounds, I write most my hobby code in C++ because of this. Well, not for a thousand year span but for longevity anyway.

C++ if far too volatile. Stick to Common Lisp instead, it is a living fossil.

"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 also much faster than Python or (especially) Ruby, and would be much faster than JavaScript but for the massive amount of effort that's gone into JIT compilation of this now-ubiquitous language.

If you're coming from a Haskell, F#, or even Scala or Ruby background, you might appreciate my functional collections library for CL [0]. It expands the range of code that can easily be written functionally.

Even if you don't have that experience, you might find FSet interesting, but it will take a little longer to wrap your head around.

[0] https://github.com/slburson/fset

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

There is a reason the Catholic Church uses Latin for important documents. The fact that Latin is a dead language means that the meaning of those documents won't change over time.

Thanks, but I'm not very productive in Lisp. Lisp development environments need emacs and emacs and my brains are not compatible. I've tried the 15 years to pick it up time and again but to no avail. Last time I even made a cheat sheet for myself (a link here as a proof of effort):

https://www.dropbox.com/s/ceiijwn8s31j8hv/emac_memo.svg?dl=0

Given the platform availability I'm pretty sure C++ will eventually reach the living fossil status Lisp and Fortran have.

With all the activity with C++ development it'll hardly ever stabilise. Ever since C++11 it keeps changing at a frightening pace.

And you don't really need Emacs for Lisp, there are multiple other options (but yes, I'm using Emacs for C++ too).

Btw., quite a nice cheat sheet. What did you use to make it?

What's the best alternative to emacs for common lisp development?

"Btw., quite a nice cheat sheet. What did you use to make it?"

Thanks. Inkscape.

LispWorks is really nice. I've seen some people using Dandelion with Eclipse (although never tried it myself). It's also possible to interact with SWANK in vim, if you're into such things.

> Inkscape

Wow. Never even thought of it in such a context. I'll definitely give it a try.

Lucky for you, Mountain View has Haskell startups!

Question 1: Do you actually know Haskell?

Question 2: How the F#*$ are you a software developer in Mountain View without a job?

On question 2: "I arrived in Mountain View tonight."