Thursday, December 3, 2015

The End of Dynamic Languages

Elben Shira (via Michael Feathers):

There is a frantic rush to bolt-on a type system to every dynamic language out there. Typed Racket, Typed Clojure, TypeScript, Typed Lua. Even Python has “type hints”. […] The fundamental problem, you see, is that a programming language is not just about code. Implied in the community is a school of thought, a philosophy. And that is difficult to change.


This is my bet: the age of dynamic languages is over. There will be no new successful ones. Indeed we have learned a lot from them. We’ve learned that library code should be extendable by the programmer (mixins and meta-programming), that we want to control the structure (macros), that we disdain verbosity. And above all, we’ve learned that we want our languages to be enjoyable.

Marcel Weiher:

Looks like someone else confused hash-languages with dynamic languages. If you pass hashes around the type checker won’t save you

Dan Luu:

There are some pretty strong statements about types floating around out there; for the most part, those claims haven’t matched my personal experience. The claims range from the oft-repeated phrase that when you get the types to line up, everything just works, to “not relying on type safety is unethical (if you have an SLA)”, “I think programmers who doubt that type systems help are basically the tech equivalent of an anti-vaxxer”, and “It boils down to cost vs benefit, actual studies, and mathematical axioms, not aesthetics or feelings”. There are probably plenty of strong claims about dynamic languages that I’d disagree with if I heard them, but I’m not in the right communities to hear the more outlandish claims about dynamically typed languages. Either way, it’s rare to see people cite actual evidence.

This is a review of the empirical evidence.

Via Lambda the Ultimate:

Part of the benefits of types allegedly surround documentation to help refactoring without violating invariants. So another future study I’d like to see is one where participants develop a program meeting certain requirements in their language of choice. They will have as much time as needed to satisfy a correctness test suite. They should then be asked many months later to add a new feature to the program they developed. I expect that the maintenance effort required of a language is more important than the effort required of initial development, because programs change more often than they are written from scratch.

This could be a good thread on how to test the various beliefs surrounding statically typed and dynamically languages. If you have any studies that aren’t mentioned above, or some ideas on what would make a good study, let’s hear it!

Maxime Chevalier-Boisvert:

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.


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.


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.

Update (2015-12-04): Michael R. Bernstein:

IMO you’re wrong if you think the “next big language” will be “either” “static” or “dynamic.” It’ll be both, if we’re making progress.

8 Comments RSS · Twitter

Interesting given the open sourcing of Swift today. One of the main complaints (more from the smalltalk style side) is that Swift grafts static types onto Obj-C in a way that makes it worse or at least difficult to do many things.

The point about IDEs is good too. Most dynamic languages don't have great IDEs IMO.

@Clark It can be confusing to discuss because there are several separate issues that get lumped into what sounds like a binary choice between static and dynamic: types, generics, data structure style, dispatch, etc.

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

*picks up jaw from floor*

This has to be the most ridiculous things I have ever read.

Brendan Eich (JavaScript), Yukihiro Matsumoto (Ruby), John Osterhout (Tcl), Guido van Rossum (Python), and Larry Wall (Perl) are not amateurs. What arrogance and snobbery to assert such a thing.

"Cowboys to the left of me,
Martinets to the right..."

Actually, the sensible thing is to have a soft, latent type system which can be progressively hardened to provide improved correctness checks and performance optimization. That would allow code to scale from quick-n-dirty hack or exploratory prototype (when it's more important to work fast, test fast, and throw away often, without having to dot every single 'i' before it even runs), to a stable polished application (when it's important to prove correctness before you inflict it on users) according to changing needs. But, you know, programmers.

@Clark: A lot of what you describe are bad ideas like Cocoa Bindings, which is an abomination unto itself, or Core Data, which just does at run-time what ought to be done at build-time. For gluing View to Model you really want a declarative DSL, something that moves time and sequential control decisions out of the programmer's hands and into the machine's. (I'd say 'FRP', but that term's already been rendered useless by imperative muppets, just like everything else they misunderstand.) For assembling custom object graphs, a homoiconic language where code is data that can be manipulated just like any other makes it simple to construct the logic for a given schema. Unfortunately, Swift's not the right solution either, because it's so big and complicated and unconstrained it can neither scale down to function as a restricted task-specific language nor do metaprogramming through recursive evaluation.

As for Swift's type system, it really is a painfully shallow and ill thought-through bag of shite, a cheap and hasty C++ knockoff that could have been vastly better were its authors better versed in languages outside the imperative C* family. But that's what happens when you send compiler hackers to do a mathematician's job. Dynamic languages may be the work of rank amateurs, but frankly so too are mainstream static languages*. So color me unimpressed with the lot of them and their stupid childish culture wars.


* Protip: a static type system is a Declarative Set Algebraic DSL, not dirty compiler annotations for allocating memory on stack cos you're too damn lazy to calculate it yourself. (Even my weakly dynamically typed language understands this, which is why its coercion and constraint checking system is intended to support Set operations... just as soon as SourceKit and swiftc stop puking and crapping themselves long enough for me to actually implement them**.)

(**I've been at this same problem for weeks, and what ought to be straightforward if inelegant double-dispatch logic has been repeatedly bent out of shape just trying to find a magic incantation that will make it build without crashing, never mind run correctly. Today's awesome behavior: dispatching directly to a base class method even though it's been overridden in the subclass whose instance I'm actually passing. So much for correctness proofs and developer efficiency.)

@Kevin Walzer: Sure they are, but that's less important than the question of whether they managed to build the solution they were after in a cost-justifiable length of time.

In modern mainstream programming's massively anally-retentive OCD culture, where languages like C* and Java are incredibly good at generating the appearance of vast amounts of developer productivity without actually producing anything useful or even fit for purpose, that's no small achievement and definitely not to be sniffed at. It's just unfortunate that such languages over time tend to outgrow their area of competence and effectiveness; the computational equivalence of the Peter Principle at work.

But again that's programmer culture at work, in this case the pathological packrat-ism that means they can never just throw away an acquired tool in favor of learning a new one, but must instead pound it to destruction making it do things for which it was never intended or designed. (Then congratulating themselves upon their proverbial dog for being able to walk on its hind legs at all.)

Not that the kitchen sink fetishists of C++ or factory-factory-factory-workers of Java can talk, mind. And frankly if that lot had their way, us 'amateur' tool creators would be locked out completely, and we'd never get the tools we need to do our jobs, because that lot are incapable of making them for us.

"It seems to me that what people really like about static languages is IDE support for things like simple refactorings and autocompletion."


"...where languages like C* and Java are incredibly good at generating the appearance of vast amounts of developer productivity without actually producing anything useful or even fit for purpose..."

Not sure if satire or serious.

"Not sure if satire or serious."

Obviously you've never encountered "enterprise development". :p

Enterprise development is my day job. In Java.

Leave a Comment