Have Static Languages Won?
A few days ago, Elben Shira caught the attention of the programming blogosphere with his post entitled The End of Dynamic Languages. The key point from this post is in the following statement:
This is my bet: the age of dynamic languages is over. There will be no new successful ones.
Like him, I’ve noticed that despite the fact that there have been an enormous number of new programming languages coming out recently, the overwhelming majority of them are statically typed. Elben and others make the argument that this is because static languages are better equipped to deal with larger projects, they have better tooling, and programmers prefer them.
I’m fairly invested in dynamic languages. I happen to be completing a PhD thesis on techniques for optimizing dynamic languages for performance (JavaScript in particular). I’ve also been slowly working, in my spare time, on a dynamic language of my own. I like dynamic languages, but I think it’s important, as a scientist and as a human being, not to stupidly fall into the trap of confirmation bias. I’m not going to vehemently defend dynamic languages, or claim that those who don’t appreciate them are unknowing fools. Instead, I’ll be honest and say that Elben’s post, and the significant amount of agreement he found in online communities made me pause and question myself. Are static languages inherently superior? Are they really winning?
That there are less dynamic programming languages coming out is an undeniable fact. I’ve written code in statically typed languages such as C, C++, D and OCaml, and I agree that their type systems help catch certain classes of bugs more easily and rapidly. When writing code in JavaScript, you can run into nasty surprises. Latent, trivial bugs that remain hidden in your code, sometimes for months, until some specific input causes them to manifest themselves.
The problem here though, is that JavaScript is a badly designed programming language. The JS origin story is that Brendan Eich originally designed the language in just two weeks. As such, it has many glaring flaws. If you compare Haskell, a language that came out of type theoretic circles and was carefully crafted by a large research community and extensively studied, to JS, a language designed in two weeks, you find that one looks like a NASA spacecraft and the other looks like a pile of fireworks on the 4th of July in Alabama.
Dynamic languages are at a disadvantage. Most of the mainstream ones out there today were designed by amateurs, people with no formal CS background, or no adequate background in compiler construction. They were designed with no regard for performance, and an impractical mash of features that often poorly work together. Most of the dynamic languages you know are simply poorly crafted. This has resulted in some backlash. I think it’s pretty clear that there’s some amount of prejudice when it comes to dynamic languages.
In universities, computer science professors generally want little to do with dynamic languages. Compiler design courses are focused on statically typed and compiled languages. Type theoretic courses will teach you about Hindley-Milner type inference, but will leave you ill-equipped to understand dynamic typing. Students coming out of your average university compiler and PLT classes have no idea about the challenges involved in creating a JIT compiler, and know little about dynamic typing. It’s no big surprise that these students would go on to create statically typed programming languages.
There might be another factor at play here. Dynamic languages such as PHP, JS, Python and Ruby, in addition to being relatively poorly designed, are the languages that powered the explosion of the web. Nowadays, much (most?) of the programming happening in the world is web development. Much of this work is done by people with no formal CS background. The result is that you have millions of people with less formal education writing code in less well designed languages. JS, Python, PHP and Ruby, and by extension all dynamic languages, are seen by many academics as the programming languages of the riffraff, the unwashed masses, or maybe simply programming languages for relatively ignorant beginners.
Have static languages won? It seems to me that what people really like about static languages is IDE support for things like simple refactorings and autocompletion. Program analysis that can provide some guarantees, find certain classes of bugs without having to run programs with every possible combination of inputs. It’s perfectly legitimate for programmers to want these things. They help alleviate the cognitive burden of working with large (and small) codebases. But, these advantages aren’t inherently advantages of statically typed programming languages. I would argue that Smalltalk had (has) some amazingly powerful tools that go way beyond what the Eclipse IDE could ever give you.
I believe dynamic languages are here to stay. They can be very nimble, in ways that statically typed languages might never be able to match. We’re at a point in time where static typing dominates mainstream thought in the programming world, but that doesn’t mean dynamic languages are dead. So long as dynamic languages do offer advantages, either in terms of expressiveness or ease of learning, they will still be around. You should remember that, in the end, there is no war between static and dynamic languages. There are only tools and tradeoffs.
I will conclude by saying that in my view, programming languages are constantly evolving and influencing each other in what seems like an organic process. Features that are viewed as good ideas tend to spread from one language to many others. Think about closures, for instance. The functional crowd has been in love with closures since the days of LISP, and now, almost all mainstream programming language have closures. Going back to Elben Shira’s post, he states:
We will see a flourishing of languages that feel like you’re writing in a Clojure, but typed. Included will be a suite of powerful tools that we’ve never seen before, tools so convincing that only ascetics will ignore.
I’ve written, back in 2012, about my belief that static and dynamic typing can essentially be combined. You can have statically compiled languages that use type inference to realize what is effectively dynamic typing. That is, the compiler inserts union types where appropriate, and does so automatically. The Crystal programming language is a realization of this idea. This isn’t static languages winning a war over dynamic languages though. It’s the influence of dynamic languages bleeding into static languages. The Crystal language developers are entirely honest about the fact that this language is based on Ruby. Their aim is to build a language which captures much of the flexibility of Ruby’s dynamic typing and also provides you with static guarantees.
At the moment the use of statically type language is certainly better. Although to be honest I don’t acknowledge any difference other than how easy and reliable a language is. JavaScript is one of those language that just keeps getting worse with every ‘patch’ made to it, but its here to stay, static or dynamic is just horrible!
Perhaps there are just too many languages out there and there is very little that can be done in one that can’t be done in another – so why bother?
Perhaps languages are like art – its a matter of opinion, but we do know when something really sucks!
fyi, many a space craft do come from Alabama, which btw some in Montreal may be aware was also once part of New France.
Good post. Just wanted to say that .net had type inference for few years now and it’s making great addition to C# – you can write some really neat looking code with all the latest features. Also I think the work they’ve been doing on TypeScrpit is quite interesting…
what is “relatively poorly designed” in python?
do you understand that python originally came as the better scripting language replacement,
but now is used in other contexts (building large programs)?
.. and slightly emotional comment:)
“if Haskell/Smalltalk/etc. are so wonderfully designed by CS grads and phds — why are they not wonderfully popular?”
Haskell/Smalltalk/etc are not more popular, in my opinion, because they aren’t as practical as languages like Python. For a language to succeed, it needs a healthy dose of pragmatism.
It’s not about the IDE tools, it’s that static languages have compile time errors with type mistakes, while dynamic languages have runtime errors.
Or perhaps said differently – Static language errors upset the software engineer, dynamic languages wait to annoy the end users!
I work in Java. I know the type system in Java isn’t as flexible or full featured as the one in Scala, Kotlin, Haskell, etc… but it does use static types.
Nevertheless, we have thousands of unit tests and thousands of system tests that have to run, and they routinely do catch errors that the compiler missed. We still occasionally get production crashes on some product features.
In Java, at least, static types are a help but not a silver bullet.
I had some weird issues with comment placement, hopefully this response is placed in the correct location.
I agree with you. That’s why I was responding to Brian and louisch – the idea that a static type system offers great insulation from runtime errors is an exaggeration. It mitigates some risks, not all.
That’s to be expected. At the end of the day, unless your static type system is Turing-complete, it’s limited in what it can express about your program. It’s a large net that filters out the more obvious bugs, but there’s no substitute for real testing.
This is something that I’ve been pondering about for ages. Type annotations/gradually typing seems to be a comfortable medium (see: Typed Racket and the heavily influenced core.typed in clojure). Especially when you’re exploring the problem domain and are still basically figuring “writing the type signature”[1], you want that ability to take a vector of BigInts and then to swap in some data imported in a .csv. Once you solidify your solution, annotating it with types gives you the type safety you need. Strongly/statically typed languages always ‘feel’ safer to me, and I’d rather have my plane running on Ada verified by SparkPRO than some Node.js stuff ;).
RE: Smalltalk. Interesting you mention that. How do you feel about Strongtalk? I argue that the dynamic components of Smalltalk (the language) aren’t want make it such a pleasure, but rather the pleasure is derived from the inherent construction of Smalltalk (the environment – e.g. the debugging experience – which isn’t too much of a factor of its dynamic nature, but rather it’s ability to prevent a stack-unwind (or so it seems, I don’t know the internal functionality that enables the recover functionality (quite ironic as Smalltalk affords the ability to look into such things))).
[1](in the Haskell sense of “once you’ve written the signature, the code writes itself”)
Language types carry an ideology with them most of the time.
A static language is most of the time minimal, compiled, doesn’t load any kind of add-ons per default, so no surprise it’s faster most of the time.
In theory dynamic is simply more work for the CPU so it will never won over static, so what’s matter is to optimize it to the point that the slow overcome the advantages dynamic offer (which IMO already happened).
About the web, the web just don’t care, most of its slowness is libraries/frameworks…
Please, spare us of the academic elitist moaning. You said it correctly – most of the Web is written in dynamic languages by non-CS grads. Maybe because you don’t need to be a CS grad to build a good consumer product. We need CS to build tools – interpreters, VMs, frameworks that enable the higher level abstraction so people can focus on the rapid development and business value (Facebook, Uber, Twitter, LinkedIn, YouTube, Groupon, Airbnb, Gmail, github… Any of those built in static languages by CS purists?). Keep the academic moaning in the lab where it belongs, let people build the Web with Node, Ruby, Python and php.
Did you not read the post? For my PhD, I built an optimizing JIT compiler for JavaScript. I specialize in compiler design for dynamic languages.
Haskell & well designed? It’s an ocean of language pragmas… An this trying to impose strictness for performance where the design is lazy? I don’t like such a design.
I would argue that interest in dynamic languages was sparked also by the fact that the type systems of most of the static languages available in the nineties had, and still have, gaping holes and were quite reasonably seen as not delivering on their promises.
I’m a dynamic languages fan. But I find it interesting that Common Lisp, Scheme, and Racket are old, respected dynamic languages that came out of academia but haven’t been mainstream since the 1980s. Now Clojure is on the scene, and maybe it can succeed where they failed.
Professionally I use Java with a little bit of Javascript and Python here and there. On the side I’ve been playing with the Lisp family languages. But I’m puzzled why Perl, Python, PHP, and Ruby took off in the dot-com boom and since then but those older, equally useful languages did not.
I mean no disrespect to users or fans of those other dynamic languages. I’m just a little puzzled by the trend.
Dynamic languages aren’t dead or dying. If anything, they are changing.
A side note – I know too many non-CS grads who are much greater devs than your average CS grad. But don’t listen to me, I’m biased for not being a CS grad myself.
The issue with type inference is that understanding it becomes a burden on the developer, you now have to mentally parse the code in order to infer the type.
Some observations:
1) When I look at the Wikipedia page:
https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites
I see the following.
Front end: Java Script.
Back End: Java(Used by 7), C++(Used by 5), Python(Used by 4), rest lower.
The dynamic languages have won the front end battle. But on the back end??
2) I know a NYC startup with code written in Clojure. The dynamic typing was killing them. The chief developer gave up and rewrote the core libraries in Java.
3) The most CPU/Memory intensive app I use is Firefox. Way worse then Visual Studio. It has gotten worse and less stable over time. I attribute it to JS.
4) Multi-threading seems to be the biggest unsolved problem. I believe the next major future language will need to help solve multi-threading.
5) I see a lot of interest in Haskell.
-Kurt
You left out PHP, also used by 4.
It depends upon how you cherry-pick your statistics, though. If you look at CMS systems used on the web, e.g. http://w3techs.com/technologies/overview/content_management/all – of systems that have 1% marketshare or more, about 4% total come from static programming languages and the others constituting 80% marketshare use dynamic languages.
And as a developer, if you don’t already work at Facebook, Twitter, Google, Microsoft, or Amazon what are the odds that you will be working at a company that builds the next technology giant? Those odds are astronomically small – so picking Python, PHP, Perl, Ruby, Clojure, or anything else that gets the job done would be fine because you won’t ever have to deal with a billion unique visitors per month.
Firefox’s major problem is that the codebase is old. The interesting question is whether their Servo project will be a CPU and memory hog when it matures – because it’s a clean sheet restart at building a browser. Right now it’s highly efficient, but it’s not feature complete so that’s not fair for comparison.