
The Long-Term Problem with Dynamically Typed Languages - messorian
http://chadaustin.me/2015/04/the-long-term-problem-with-dynamically-typed-languages
======
SoftwareMaven
Bollocks. Maintainable code is maintainable. Unmaintainable code is
unmaintainable. In 20 years of writing software, I've dealt with Java code
that was impossible to understand which made it painful make even simple
changes, and I've dealt with Python code that was trivial to reason about so
changes were easy and fast.

Invariably, the ugliest code I've seen has always come from "we must move fast
at the expense of everything else" startups. I worked at a startup that
combined the worst of architectural temple building with the worst of
"maintaining code is a Maserati problem" (e.g. by the time somebody has to
maintain it, I'll be driving a Maserati and not caring). The company almost
folded due to the weight of the code base preventing features from being
released. Did I mention this was all Java?

Many fast-moving startups choose dynamic languages to do their ultra-fast,
sloppy iterations on. Fast-moving startups tend to write code that is
unmaintainable. Later in the lifecycle, as the maintenance nightmare hits,
these same companies move to static languages to "fix their problem", but
they've also introduced a lot more discipline in their engineering process.
Afterwards, the dynamically typed language gets the blame for the lack of
maintainability and the static language gets props for being maintainable.

Correlation is not causation. The engineering practice has far more to do with
maintainability than the language itself. It just happens that, in the last 10
years, dynamic languages have been chosen more often during periods when
companies write poor code. My Java example above was from 1998 to 2001 , when
Java was the hot language for building the dotcom boom.

~~~
zak_mc_kracken
> Unmaintainable code is unmaintainable.

Sure, but not all unmaintainable codes are equal.

Code without types is orders harder to maintain and modify, even with
extensive code coverage (because you can never really now how extensive that
coverage is).

Also, the absence of type annotations make the simple human understanding of
such code extremely harder.

~~~
jonnybgood
Are you just giving your anecdotal experience or do you have something to
support your claims?

~~~
learc83
Every claim that's been made in this thread is based on anecdotal experience.
Maybe in 50 years software will be mature enough that we'll have actual
empirical data to back up our design/tooling decisions. But for now, almost no
one is seriously interested in testing this stuff with well designed (and well
funded) studies.

~~~
jonnybgood
I realize this. I'm just hoping someone has come across some knowledge that
I'm not aware of.

------
uiri
I think the author's lack of distinction between static vs dynamic and strong
vs weak typing detracts from his point. Static vs dynamic typing boils down to
whether typechecking is done at compile time or at run time (for various
definitions of "compile time" and "run time"). Strong vs weak typing is
whether the language will raise a type error or it will try to silently
convert types. Python is dynamic but also strongly typed. I feel like PHP's
weak typing contributes to the maintainability issues mentioned - passing in
the wrong types to the APIs cause silent failures rather than generating some
kind of error message. I feel like this makes it more difficult to design a
good API because you have to take care of more cases rather than simply throw
an exception when you get something badly typed. Since programming in a
statically typed language is going to require a test suite anyways, I'm not
sure that it buys you much over a strong dynamic typed language like python.
That said, an argument could easily be made the other way - it doesn't cost
much to use a strong statically typed language like Java. You are going to
have to spend time on type safety in each case the question is just whether it
is while trying to get a prototype to compile or ensure that a mature project
exhaustively tests arguments of illegal types (to pick the worst case for each
side).

~~~
chadaustin
What I've found in discussing these topics with some colleagues are that the
terms "strong typing" and "weak typing" are so vague that almost everyone has
a different definition.

The academic literature uses types to mean checked at compile-time, and tags
to mean checked at runtime. Python, calls them types but checks at runtime. I
think the fuzzy terminology can work as long as we all declare in advance what
we mean. :)

In general, I agree with your points. Where strong type systems start to help
a lot is when you have super-complicated data flows and invariants, where many
different types might actually have the same representation (say, a 32-bit
integer or small string), but only some operations are valid on some types.
That stuff gets tricky in Python, even if you implement a unique class per
type.

------
taeric
The long term problem with bashing less statically typed languages and
constructs is that, long term, they have worked. The more statically typed
languages are infants in the world of abstracting and solving problems.

Now, this is in large part because static type checking is a rather expensive
operation. The "price" of which has been dropping significantly with
computers. But, I can't help but see a large amount of hubris in the field of
people proclaiming that dynamically typed languages don't lead to solid
solutions.

Especially when some of the larger train wrecks I have ever had the pleasure
of working on were abuses in higher kinded types.

------
zak_mc_kracken
As much as I try to remain objective, it's really hard to see any future for
dynamically typed languages (and by that, I mean languages verified at compile
time in order to avoid the silly pedantic distracting argument between
statically and weakly typed languages).

The bottom line is that statically typed languages (STL) have been much better
at getting good at what dynamically typed languages (DTL) shine than the other
way around to the point that there is hardly any good reason left to use a
DTL.

These days, STL are terse, fast, expressive, are supported by tremendous tool
chains including amazing IDE's and DTL pretty much suck in all these areas.

~~~
taeric
Your bottom line reads more to indicate the resources that have gone into the
statically typed languages than it does anything else. Also ignores the ocean
that is javascript.

Seriously, think about that example for a minute. During a time when
statically typed languages were getting more and more tooling than you can
shake a stick at, browsers take off and prove that the ultimate tool for any
language is a widely distributed runtime.

So, where is the difficulty in seeing that dynamic runtimes that can adapt to
changes in the system have a very valid place in the future? I realize I'm an
emacs person, so biased as can be. But there is something inspiring about
finding a problem in my editor/runtime, popping over to the function, fixing
it, reevaluating it, and then continuing without a restart. Is ridiculously
nice.

~~~
zak_mc_kracken
Couldn't agree more with your last point, it's just that we've been able to do
this with statically typed languages for years now.

Javascript still reigns supreme, no argument there, but the contenders that
are trying to replace it all have something in common: they add types to
Javascript. All of them.

I think the trend is pretty clear.

~~~
taeric
Sadly, if there is a trend, it is that none of them have succeeded. So, if
that is the path to success, it will only be after it was forced through more
effort than really makes sense.

And, correct me if I'm wrong, but Haskel and vanilla Java, along with many
other common statically typed languages, can not hotswap. Well, to be fair,
vanilla Java can, under limited conditions.

~~~
zak_mc_kracken
The fact that none of them have succeeded is more due to inertia than anything
else. Again, this doesn't take anything away from the fact that that
statically typed languages are the future and even Javascript won't be dodging
this evolution for much longer.

Ruby and Python were the latest victims of this trend, Javascript will clearly
be next, even if it might take years.

~~~
taeric
Isn't javascript younger than all of the poster static languages? Why didn't
inertia help any of them beat it? (It is amusing that it was called JavaScript
to capitalize the popularity of Java.)

I mean, ultimately, I think I agree with you. But at the rate things are
moving, I expect my children will still learn JavaScript. And probably C.

~~~
the_why_of_y
The reason why JavaScript has succeeded where many other languages, whether
statically typed or not, have failed, is that it was bundled with a runtime
platform - the web browser - that became ubiquitous.

Millions of people want to write programs that runs in a web browser, and it's
easiest to do that in JavaScript.

JavaScript is a textbook example of "worse-is-better", and you are right, for
compatibility reasons we are going to be stuck with it until long past its
best-before date, just like C.

~~~
taeric
That was the point I meant when I said the the ultimate tooling a language
needs is a runtime that is widely distributed.

------
messorian
A cached version:
[http://webcache.googleusercontent.com/search?q=cache:DPgtvIi...](http://webcache.googleusercontent.com/search?q=cache:DPgtvIipfi4J:chadaustin.me/2015/04/the-
long-term-problem-with-dynamically-typed-languages/&hl=en&gl=us&strip=1)

~~~
chadaustin
Thank you, I recently configured my blog software and clearly missed some of
the caching settings. Working on it.

------
Roboprog
This seems like one of those "Zen" things, where you eventually realize you
are more effective when you use both kinds (compile time types and runtime-
only types/tags) of programming together, rather than trying to pick only one
and label the other as evil.

Now I must "reflect" upon the wisdom of all the strong typing in my Java
programs, and how a simple refactor always safely finds all the use cases of a
class/method/variable for me. (NOT -- although IntelliJ is pretty good at
finding many common hiding places in various texts for program identifiers)

I really want one language that combines optional (dynamic) and mandatory
(static) compile-time type info, with some pragmas at the top of a module
warning me that the module uses or supports dynamic types, rather than having
to resort to XML DSL monstrosities.

One final rant: The author mentions an FP language (Haskell), and then talks
about data flow analysis. Strangely, however, he seems more concerned with
types than immutability and explicit data passing / folding. Favoring explicit
input/output values over side effects, is a huge factor in seeing data flow
(and orthogonal to compile vs runtime types). Alas, the "enterprise"
development squad seems to actively resists learning FP, preferring to cling
to "COBOL with namespaces and compilation units" as state of the art
programming methodology. I think this problem is the real (productivity)
killer.

(OTOH, he could tacitly assume pure functions, etc, are a good thing, and
should be the norm. Hard to say)

------
tosh
As far as I understand dynamically 'typed' languages are actually the way we
can get the best of both worlds since dynamically typed languages can be
'upgraded' to benefit from type annotations (see Dart, Hack/PHP, Python, …)
whereas languages with static typing are not easy to 'downgrade' to behave
dynamically (?).

The author runs into a few logical fallacies like underestimating how
important early agility is for making a product successful (if your product
isn't successful there is not much to 'fortify' using static typing) or
conflating static/dynamic with strong/weak.

The bottom line imho is that we want languages that are both easily toolable
(type systems can help here) as well as allowing us to do fast prototyping. It
seems like starting with a dynamic language and to add optional/gradual type
annotations is the way to go.

~~~
Retra
It shouldn't be that hard to add a 'variant' type to a statically typed
language. In fact, OO languages usually just use a common superclass for just
this purpose.

~~~
dllthomas
And of course Haskell now has Dynamic, it's just not very useful.

~~~
Retra
It's probably useful if you wanted to implement a dynamic language using
Haskell. :P

~~~
dllthomas
I'm not sure if this was intended in jest, but it's a bit interesting to treat
it seriously so I'm doing so... I think it would not be a very good choice to
_implement_ a dynamic language in Haskell, because what it makes flexible is
choice of _Haskell_ type, and you likely don't want to tie implemented-
language type to Haskell type like that. It would seem more likely to be
useful if you wanted to _host_ a dynamic language within Haskell.

------
Havvy
I do believe Hacker News killed the site by too much traffic.

~~~
xena
no, the oom_killer did

------
rjurney
Using PHP to characterize dynamic languages is like using a Lada to
characterize cars.

------
tacos
I think of it like typing the units in physics class. Sure, you can leave them
out. But how much time are you really saving?

A lot of these languages make for lovely blog posts and also happen to be
fantastic for gluing things together. But I fear there's an entire generation
that's unaware that C# looks like a lot of boilerplate in a textbook but
actually requires fewer keystrokes than most equivalents. And once you get
fast at it, it's pretty amazing.

I use lots of Python. And Matlab. And of course Javascript.

But as you get older you realize that tools matter. And the tooling around
dynamic languages by definition cannot beat what's possible when you declare a
more rigid contract of what you're actually trying to get the machine to do.

~~~
seanmcdirmid
If you are writing avionics and/or are dealing with lots of conversions, then
units are very useful in both dynamic and static languages. But if you are
writing a simple game without many or any unit conversions, you might not find
them useful at all.

~~~
tacos
Interesting choice as game engines are famously C++ and the scripting
languages -- even the one-offs custom made by the devs -- are less "scripty"
than you'd think given the development pressures. From Wolf3D to Unity they
land on a consistent set of squares here.

Games are an interesting example because of 1) strong tooling requirements 2)
small but diverse teams 3) cross-platform requirements and 4) performance
requirements.

Under these constraints they made their choices. And it wasn't because Python
wasn't available.

~~~
seanmcdirmid
Python has plenty of game too, as does c#, Java, and so on. Ask a game
developer if they need unit types, and I'd think it wouldn't be a top priority
(though indeed useful).

~~~
tacos
Ah, my metaphor wasn't clear.

I wasn't arguing for unit types (user-defined literals didn't appear in C++
until C++11...)

I was pointing out that reconciling units in physics is common sense. People
don't debate whether writing down "meters" or "seconds" next to a quantity is
useful or not. You just do it, then cancel the units as a basic sanity check.

Yet so much of the "strong typing is for people with weak memories" debate
incorrectly centers around the equivalent of "len = 3.1" vs "Kilometers len =
3.1" (or, heck, "auto Distance = 3.1_km").

I'm not sure why people think this is some sort of ordeal but my hunch is
they'll learn. Timezones, Unicode, Database Schema, Float vs Decimal: you can
deal with it now or you can deal with it later. If there were a lightweight
language that actually solved this we'd all be using it, not arguing about it.

~~~
seanmcdirmid
If type systems weren't so darn annoying, I'm sure everyone would be using
them. As it is now, it's a trade off and not always a clear win. Give game
developers easy access to unit types, for example, and they would probably use
and benefit from them. But if they are a PITA to use, then of course, they
would just say no way!

For type systems, we really need much better type inference than we have
now...something that works with the subtyping that many of us prefer to work
with.

~~~
tacos
Agreed. Nerds in generally tend to make a lot of ... odd ... short term
decisions. Perhaps time to admit that a lot of what we do all day is
"annoying" while balancing that with the fact that we're some of the best-paid
people on the planet.

Enjoying that economic windfall while doing what's all but scientifically
provable as a half-assed job raises issues around quality and ethics.
(Something as a community we're also a bit famous for tiptoeing around...)

~~~
seanmcdirmid
The current state of PL is very annoying, less so than a decade ago, but still
annoying. Most programmers don't really care, there are plenty of other
annoying ways to spend life for less money. But improvement is so possible,
not everything significant in PL was invented 20-30 years ago, yet that is
what we are stuck on.

------
dschiptsov
They are languages for quick prototyping (consider Arc's philosophy - a core
language for a quick, bottom-up prototyping).

Most of the time, the prototype is good enough for production. If not - there
are implementation languages (C, C++).

So, I cannot see any problem.

~~~
Havvy
I see a problem. Neither C nor C++ have garbage collection and other similar
runtime features that every scripting language has. As such, if you rely a lot
on these features, you could run into issues when translating into a lower
level - either in implementation or in memory safety.

~~~
GeneralMayhem
Modern C++ actually makes for a pretty nice prototyping language if you use
auto and std::shared_ptr everywhere, turn on RTTI, and make every method
virtual. That gives you mostly-hidden compile-time type induction, explicit
type-based dispatch, reference-counted garbage collection, and extensible
classes. Then, once you've got things working, you can refine the ownership
semantics and internal interfaces.

~~~
dschiptsov
No, thank you.)

------
UnoriginalGuy
I absolutely agree.

Look, you don't need every single type that C implemented to have a type
system. You can just have number, w_string, w_char, byte, object and maybe
DateTime as core types. Then build on those. But typeless languages are just
maintenance nightmares that just get worse as time moves on. They are also
inherently incompatible with any system which does use types (which is most),
like databases, XML, libraries, OS APIs, and so on.

I know I am going to get stomped into the ground for this, but JavaScript is
bad and I wish we had something, anything, else instead. JavaScript was made
in like a weekend and copied Java badly, that's fine, but we've carried this
legacy long enough and the longer it takes us to implement the replacement the
longer we'll have to keep using JavaScript until every browser/device catches
up (10-20+ years from now).

There are many things that could replace JavaScript, but all I want is a
strongly typed language, with real classes, strong focus on libraries, a MUCH
better core DateTime library, and with maybe some functional programming
concepts to make it more maintainable and more optimizable (at runtime).

PS - I am aware of ECMAScript 6, but it is only a bandaid on a bad language at
the core.

PPS - Dart is already dead. And "X converts to JavaScript" is also a bandaid.

~~~
peteretep
TypeScript takes an afternoon to learn, and is strongly typed JavaScrupt. It's
not perfect, but it's really very good. The JS produced is predictable, clean,
and makes sense with virtually zero overhead.

~~~
UnoriginalGuy
TypeScript as of today is supported by a total of zero browsers with zero
planned to add support in the near future. It doesn't replaces JavaScript in
any way, just builds a larger house on the sand.

~~~
michaelwww
You don't know anything about TypeScript, yet you choose to weigh in on it.
Interesting. I think you must be confusing TypeScript with something else,
like Dart maybe?

~~~
UnoriginalGuy
Please clarify what I said that was incorrect? I said that TypeScript doesn't
have browser support (true) and that they have no plans to add browser support
(true), and I added that TypeScript is like building a house on sand (i.e. it
is all built on top of JavaScript, since there is no browser support for
TypeScript).

Please, go ahead, and correct my ignorance. Since I don't know anything...

~~~
michaelwww
The stated goal of TypeScript was never to run in the browser. That's what
confused me about your statement and made me wonder if you were confusing it
with Dart. TypeScript wraps JavaScript with static type checking and some
other useful contructs. It compiles to very clean and readable JavaScript.
It's a tool, not a browser script.

