
Language choices for long-term projects - richorama
http://richorama.github.io/blog/2014/12/31/languages/
======
informatimago
This is an ill-informed opinion.

He correctly reject quite a number of language, but probably not for the right
reason, given the criteria of using it for long-term projects.

What languages will be still usable in 50 years? A language like perl, that
was popular a few years ago, but that nobody use anymore? A language like java
or C++ that's changing every few years (because it's so limited or ill-
designed)? What guarantee do we have to be able to compile our current C++
programs with C++2060? What would you bet? Even C's evolving.

On the other hand, there are a small number of candidate language that
withstand the test of time:

\- Fortran and Cobol (somewhat specialized languages),

\- Lisp, notably Common Lisp which is still able to run programs 55 years old
(that's my personnal bet, CL programs written today will be still runnable in
the Lisp of 2060), and whose ANSI standard has not changed for 20 years now.

\- probably Smalltalk. Perhaps Ada and Eiffel.

All the other languages are too recent or evolving too fast to ensure any
perenity for long term projects, AFAICS.

For example, while Haskell is the current fad in purely functional programming
languages, I could count at least half a dozen of rather popular functional
languages invented since I was in University, for an average of lifespan of a
few years each, not much more. If I wanted to write a long term project in a
functional style, I'd still choose Common Lisp to do that...

[http://longnow.org/](http://longnow.org/)

~~~
ekidd
_\- Fortran and Cobol_

This is definitely the right general strategy: You want to ensure that
compilers, libraries and a community are all available in 50 years. This
depends, in turn, on having a huge community of users with high-value legacy
systems that can't be feasibly rewritten.

So basically, you want to choose a boring, widely-adopted "enterprise"
language, one used to implement a large number of critical back-office
applications in Fortune 500 companies. You also want to choose a language
which has a long history of backwards compatibility. In the 80s, Cobol would
have been an excellent choice.

Today, I'd probably go with Java for this role. Sure, there's a lot of
boilerplate (or whatever your personal complaint might be). But in 2064, there
will absolutely be a huge quantity of ugly legacy code written in Java, and it
will still be running critical systems somewhere. At a minimum, there will be
a small market of specialists who can maintain it, and Oracle (or one of their
successors) will be happy to sell you a JVM and enterprise consulting services
at a hideous markup.

~~~
riffraff
not to be underestimated: the jdk is open source.

------
georgemcbay
(FTA) On C#:

"For some reason bit rot in .NET seems to set in very quickly."

(FTA) On Java:

"It’s been slow to catch C# up on language features"

These two observations (which are independently correct) are inter-related in
a way that materially impacts what decision I'd make if I were really forced
to make one similar to this article's thought experiment.

(FTA) On Java:

"I haven’t done much Java, and I’d like to keep it that way."

As someone who programs in Java almost every day (Android development), I
respect this opinion because there's a lot about Java that I hate, _but_ if
your goal is honestly to create a system to be maintained on the scale of
decades Java would probably be the best, most practical bet of any of the
languages mentioned, by far.

It isn't sexy, it often isn't fun, but in my experience (which involves
programming in Java off and on in various contexts since the mid-1990s) it
hits the biggest cross-section of development system/runtime that bit-rots the
least and is most likely to still be around for 10+ more years (even if this
is much to my chagrin). This doesn't mean I'm a fan of Java, I'd much rather
code everything in Go, but Java is the safe bet given the premise.

Before anyone brings up picking Java over C/C++ (which are older languages and
still have robust ecosystems), try compiling K&R era C code with a modern
compiler. Java is ironically like the (pre-Windows Vista) Windows of
programming languages in that the tools and runtime basically bend over
backward to not break your old code that used to work, this is both good and
bad in different contexts but is very useful for the specific niche of
development this article is talking about.

------
ikusalic
Seriously one of the worst posts I've seen on top page in a long while.

Disclaimer: from here on I'll also be a bit opinionated, hardly can be worse
than the post. And yes he did write the disclaimer, and no, still doesn't help
at all.

Just LOL.

What's the difference between Python and Ruby and the conclusion?

Scala doesn't get him excited? Well, can be if he's "not clever enough to
program in Haskell". (Not a bad thought-terminating cliché btw)

The best: "limited compile-time safety (you can lint and unit test)" of node?
And is offset by "not creating a large codebase!" ?!

Half the languages he mentioned are less verbose than JS.

Oh, and he didn't mention the coolest feature of JS: weak typing, which works
perfectly for long-term projects.

On the other hand Lisp? Ah, I'll stop here.

He could have just written "here are the languages I'm currently interested
in" and be done with that.

~~~
commentzorro
> _He could have just written "here are the languages I'm currently interested
> in" and be done with that._

To me he did. I saw this as a casual listing of what languages he wanted
explore next by ruling out the ones he didn't want to learn because of one or
two things in each that he didn't want to contend with.

------
hugh4life
This blog post is absolutely maddening.

He wants a language choice for a 10+ year project and dismissing Java because
it doesn't evolve fast enough. That is one of the top attributes you want for
a long running project.

Being OK with Elixer and Clojure but dismissing Erlang and Java is insane when
the former are much more likely to break compatibility.

------
humanrebar
On Rust:

    
    
       An interesting language, but rather than taking
       an opinion about how software should be built,
       Rust just seems to throw everything at you. You
       can be functional, object-orientated or procedural.
    

You can write functional and procedural Rust code. It's really, really hard to
write object oriented code except in the "object oriented C" sense. For
instance, there are no classes or inheritance as such.

And Rust seems to have a pretty strong opinion about how software should be
built, mostly centered around correctness and safety, which seems to be an
underserved niche.

Perhaps the author should read through the Rust Guide, which has been recently
written and is a great intro to the language: [http://doc.rust-
lang.org/guide.html](http://doc.rust-lang.org/guide.html)

------
lawn
This isn't even about long-term projects, it's more about the author's
personal preferences.

Erlang is dismissed with "the Erlang syntax itself is a bit odd" and other
languages (rust, Python, Scala) are dismissed as they don't _feel_ good.

The article is a bit shallow.

~~~
richorama
yeah it is, I'll try harder next time...

------
nkishore
Nice comparison. I believe every language has a purpose.

Ruby is a good choice for front end. We use them to build front-ends
([https://github.com/megamsys/nilavu](https://github.com/megamsys/nilavu)).

Go is a good choice for system programming, its native binary interests
everybody.

Nodejs is good choice for realtime programming.

Scala is concise and good when you need heavy duty API and such and allows to
build a robust code
([https://github.com/megamsys/megam_gateway](https://github.com/megamsys/megam_gateway))

~~~
humanrebar
> Nodejs is good choice for realtime programming.

...for some definition of realtime. Javascript and node.js are terrible
choices for serious signal processing systems, for example.

We really need to find another word for the kinds of browser applications
people call realtime these days.

~~~
hobs
I propose: Humantime. Humantime means that you react as fast as person would
give a crap about.

------
cubano
With the way I see young developers shy away from anything-legacy, and the way
new languages and fads pop up on a monthly basis, I can hardly believe ANY
software is going to last 5 years, much less 10 to (yeah-right) 25.

I basically assume whatever I'm working on today will be gone in 5...now
obviously, it's very dependent on how deep in the soup you are (COBAL is still
being run on banking systems etc etc), but still...I don't see a lot of
legacy-code maintenance and extending skills being developed as they once
were.

------
StefanKarpinski
I think this is best taken as a half-serious, somewhat comedic take on these
languages in the vein of PG's
[http://www.paulgraham.com/fix.html](http://www.paulgraham.com/fix.html). Some
of them are quite funny. I also think that a large consideration is whether
the author is personally interested in trying each language, which rules out
many languages that are reasonable choices from a purely practical perspective
(Fortran, Ada, etc. mentioned elsewhere).

------
NhanH
A few months ago, after reading on HN about long-term (forever) side projects,
I decide to write a kind of personal tracker/ todo list/ personal knowledge
base mix up (basically, a "this is my life"/ "this is my brain extension"
app). I went through the exercise to pick a language, with the following
criteria:

\- The language will need to be usable for the next, let's say 20 years.

\- The project will forever has only one developer, and one user (both me).
That means I can pick whatever exotic language I want without any concern.

\- Following from the previous criteria, it means the most important - if not
only - necessary characteristic of the language would be programmer
productivity.

\- This is more of a point on framework rather than language. From the first
criteria (long term), it means that it's probably safe to ignore any, and
everything that is currently popular. Chance are those would be too bloated,
and one they stop being popular, whatever productive was gained will be lost
with dealing with the cruft anyway. Also, what's the rush in gaining
productivity early on in the project anyway.

\- If I can actually keep hacking at it, I might imagine myself using it on
multiple devices. Also, I will probably be using a combination
linux/freebsd/mac/windows a few times in the next 20 years that marrying to
.NET or similar is a no-no.

\- It has to be a reasonably "fun" language.

There are a few more criteria, but they're just natural extensions of those
mentioned. Anyway, it was a pretty simple decision that it will probably have
a backend API of some sort. But what about the frontend? A JS single page app
seems to be fitting at first (multiple devices/ platform), but miserably fail
the longevity criteria. Even without any framework, the current rate of change
in JS/HTML means that I will have to keep redoing the entire frontend every
few years.

Actually, on second thought it seems impossible for UI to be long lasting, for
the simple reason that UI have to be specific to the platform. So I just
decide to ignore mobile for the moment (that was a far-fetched plan anyway).

Without elaborating through each language. The first short list was actually a
pretty easy choice of Common Lisp, Racket and Smalltalk (Pharo). With the
choice of UI, I decided to go with Smalltalk!

------
qznc
If it is a distributed system of various components, then use a solid
connection/communication layer which has a C interface and bindings for
basically everything (maybe ZeroMQ or ProtocolBuffers or?). Make sure to
document the protocol well and you can exchange and mix languages at will.

------
kolodny
In case anyone is curious about any of those languages:

[http://learnxinyminutes.com/](http://learnxinyminutes.com/)

------
itsadok
Obligatory:
[http://www.paulgraham.com/hundred.html](http://www.paulgraham.com/hundred.html)

~~~
qznc
I don't think Paul Graham's Arc will be around in a hundred years.

------
michaelochurch
I agree with some of the observations, and not others.

On Java...

 _I haven’t done much Java, and I’d like to keep it that way. My impression of
the language is that too much time is spent doing the boiler plate. It’s been
slow to catch C# up on language features, and Object orientation doesn’t seem
to be the right approach anyway._

Yep. Correct. Nailed it. I wrote about "Java Shop Politics" in 2012 (
[http://michaelochurch.wordpress.com/2012/04/13/java-shop-
pol...](http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/) )
but the truth is that any big-program methodology is going to become a
political quagmire. The problem is the business bastardization of OOP, which
isn't limited to Java. I'm sure that companies that identify as ".NET shops"
are just as bad.

Clojure...

 _I have played around with Clojure a bit and I like it. However, it seems
like a language of compromises, the biggest of which is sitting on the JVM. Is
this a stepping-stone language, or a long term viable option? It’s hard for me
to say._

Everyone should be exposed to Clojure. The JVM is incidental. The Clojure
community (and this is damn surprising, given that the language lives on the
JVM, and Java's community is so awful in this regard) has excellent aesthetic
sense. I haven't used core.async or Om for any large projects, but I'm a huge
fan of what the Clojure community's doing with the front-end. In terms of
aesthetics, I think they're still 5 years ahead of Haskell.

Speaking of which...

 _I’m not clever enough to program in Haskell._

Yeah... I'm going to call that a cop-out. For a 1-month project, don't use
Haskell if you're not familiar with the language and not intent on learning
it. Use Python or Clojure. For a _long-term_ project, you can use Haskell.
It's not about "clever enough". Sure, Haskell has some wonky terminology
(monoid, monad, functor) and learning everything that's possible takes years,
but anyone who's smart enough to program can develop a basic capability in it.

Personally, my choice would be Python for a short-term project, Clojure for
the mid-range, and Haskell for a long-term project that's destined to go
multi-developer.

