Language choices for long-term projects
richorama.github.io
richorama.github.io
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...
Like it's opinionated, poorly researched, and really just the thoughts from his head?
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.
Misguided as the article is, I think it still reached the correct conclusion.
Nobody uses anymore, or that no longer gets a lot of buzz?
Also, Lisp has as you say been around for a long time, but Common Lisp goes back only so far. Will it really run the Lisp programs of 1960?
"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.
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.
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.
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.
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.
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
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.
Ruby is a good choice for front end. We use them to build front-ends (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)
...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.
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.
- 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!
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... ) 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.