Enterprise Integration Zone is brought to you in partnership with:

I'm a writer, programmer, web developer, and entrepreneur. Preona is my current startup that began its life as the team developing Twitulater. Our goal is to create a set of applications for the emerging Synaptic Web, which would rank real-time information streams in near real time, all along reading its user behaviour and understanding how to intelligently react to it. Swizec is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

Dynamic Languages have Jumped the Shark

  • submit to reddit

  Jumping the shark

I still remember the heated arguments I’d have with my high school professors about dynamic languages. What do you mean python isn’t a real language? What’s wrong with you!? Dynamic languages are the coolest thing ever!

Some kids fight about curfews and school rules, I fought about scripting languages being just as “real” as the likes of C and Pascal. That was ten years ago – dynamic languages were all the rage and I just started exploring the world of programming beyond what my mentors laid out in front of me.

Nimble scripting languages sounded like a promised land compared to the musky static languages of yore. No longer would you be forced to think about data types all the time, no longer would your code be littered with the int and char and double of the world, no more stifling constraints on using a variable once it’s been defined.

Just a pure expression of thought. Programmer and problem at peace with one another, no angry compiler will get in your way.

The promised land tumbles

Yesterday I realised dynamic languages have jumped the shark. The evidence has been mounting for a while, but yesterday’s mishap with Ruby on Rails sealed the deal.

Did you know that Rails environment settings, the ENV hash, only accepts string settings? I wanted to make a boolean flag. The only solution was to make a string 'false', then do a string comparison when needed. There isn’t even a native way to cast a string to a boolean.

Programmer left completely to his own devices. Out in the rain. With no chance of escape.

The closest Ruby will let you to casting a string to a boolean is using something like !!'blah', but all strings evaluate to true. Even empty strings.


The situation is just as bad in other dynamic languages. JavaScript is particularly famous for its weird handling of data types.

Try it. It works.

Part of the code returns undefined, which is magically transformed into a string, then other parts of the code select particular characters from that string … the mind reels in disbelief.

I don’t want to remember the atrocities I’ve committed in PHP just to convince it that yes, I do know what I’m doing, yes I do want that variable to behave like it’s a particular type.

Python’s strong typing at least ensures we can’t add a string to an integer, but there’s still the odd 5/float(2) type of hack. Some people suggest going as far as littering your code with assert statements to ensure your team mates can’t do stupid things with your functions.

This is the exact opposite of what I was promised as an aspiring 15 year old coder.

Why we wanted dynamic languages in the first place

Dynamic languages promised an ease of development, a sense of thinking about solving the problem instead of worrying about talking to the computer. And the world fell in love.

Instead, dynamic languages delivered a hodgepodge so wibbly-wobbly it always forces you to think about data types, even about the particular quirks of how this particular language handles certain conversions. Always at the worst possible moment. Nothing is true anymore, you can’t rely on a single thing; without automated tests you’re flying blind, relying on nothing but your raw coding prowess to stave off the always imminent failure.

God forbid one of your team mates does something stupid.

But we did get away from the whole int a nonsense. And we did get fancy REPL‘s. And we did get away from the write-compile-run cycle.

But what have the Romans ever done for us!

Static is better now

Here’s the thing, though, there is now a whole new class of even awesomer languages – the modern statically strong typed languages.

Scala and Haskell have everything we’ve always wanted from a dynamic language. You never have to spell out a variable’s name, the compiler often knows better than you do anyway, and there is a REPL you can use to prototype things.

But unlike dynamic languages you can rely on everything. All the benefits of static type analysis, most of the benefits of dynamic languages. Hell, you can get rid of the write-compile-run cycle with a simple bash script that compiles your code before running it.

Just remember, static languages are not just C and Java anymore. The world has moved on while we were stuck in the dynamic hell hole for the past ten years.

You should read my book, Why programmers work at night

Published at DZone with permission of Swizec Teller, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mark Bernard replied on Mon, 2013/06/03 - 9:19am

Eclipse has performed dynamic compiling for years now. Writing Java code in Eclipse for me has always been write-run not write-compile-run. (Unless it is a web/enterprise app then it's write-deploy-run)

Paddy 3118 replied on Tue, 2013/06/04 - 8:11am

When talking about all strings being true you state "The situation is just as bad in other dynamic languages." In Python all empty container types such as strings are False.

When mentioning Python you state "but there’s still the odd5/float(2) type of hack". Python 3 does not need this. '/' performs floating point division '//' performs integer division. (The Python two behaviour was consistent too).

If you are moving to a non-manifestly typed static language then good for you. 

Andre Roodt replied on Wed, 2013/06/05 - 7:36am

Like with anything, once the evangelists and fanboys run out of steam, its the people on the ground doing the actual work that get the real picture. Java, and C# for that matter wont get replaced any time soon. The fanboys wont really care, because they have probably moved onto something else(I suspect they're all Scrum evangelists now. The whole scrum movement smells an awfull lot like the dynamic language movement).

With JRebel and modern IDE's there is no longer any excuse for not being productive with Java, and as an added bonus the Java compiler saves a considerable amount of time in the testing department. I mean seriously, do I really want to spend my time writing tests when my compiler can do that job for me.

Furthermore, any enterprise dev will tell you that the time spent coding is just one small part of the job spec, so thinking that improving the time writing syntax is going to ultimately speed up the whole dev process is really naive.

dani pardo replied on Thu, 2013/06/06 - 8:33am

I can buy the fact that the javascript snipped you wrote is awful, sure. But please, Haskell?? Here's a lovely Haskell snippet:

view sourceprint?1.fix$(<$>)<$>(:)<*>((<$>((:[{- Jörð -}])<$>))(=<<)<$>(*)<$>(>>=)(+)($))$1

Lund Wolfe replied on Sat, 2013/06/08 - 6:09am

I like my strongly or statically typed languages.  Type matters and I like knowing my data types.  Dynamic types are a leaky abstraction, since you assume a type and you have to know what it will do under any given circumstance, anyway.  At the very least it is more trouble and more risk than it is worth.

Like any tool that automates or does something for you, there is a risk that it also takes away some of your control.  Sometimes this is a bad trade.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.