
Dynamically Typed Languages (2009) - dkarapetyan
http://tratt.net/laurie/research/pubs/html/tratt__dynamically_typed_languages/
======
orting
I dont like this paper. It makes statements based on references to opinion
style articles. F.ex

"in practice, run-time type errors in deployed programs are exceedingly rare
[TW07]."

If we look at [TW07] they state that

"even very simple approaches to testing capture virtually all, if not all, the
errors that a static type system would capture."

But provides no data or reference for that statement.

Another isue is that some references with data are based on small samples and
possibly oudated:

"they [dynamc languages] lower development costs [Ous98]"

[Ous98] Compares time-to-implement and code-size for 8 different programs
implemented in static and dynamic languages and shows that the dynamic
languages are supperior. It is however not clear how much actual
implementation is involved, so it may be the case that the difference is
caused by diferences in available libraries at the time. In any case, the
sample size is small and the article is old (1998) so it is not reasonable to
make generalisations for programming in 2009 (or 20014).

[TW07] Laurence Tratt and Roel Wuyts. Dynamically typed languages. IEEE
Software, 24(5):28–30, 2007.

[Ous98] John K. Ousterhout. Scripting: Higher-level programming for the 21st
century. Computer, 31(3):23–30, 1998.

~~~
judk
Informally, dynamically types languages are chosen when the programmer prefers
to get something running before getting something running correctly. Why would
we assume then that once a program is running, the programmer would "find
religion" and do the extra work to write a comprehensive test suite? If the
programmer is willing to do work in an effort to prove correctness, the
programmer would choose the far more efficient technique of rewriting the
program in a statically typed language.

A dynamically typed program by its very nature a prototype, a program that is
expected to fail when exposed to a non-trivial input. In many cases, that is
fine, just not when correctness over many invocations actually matters.

~~~
dragonwriter
> Informally, dynamically types languages are chosen when the programmer
> prefers to get something running before getting something running correctly.

I don't think that's at all true. I think that a major motive for choosing
dynamic programming languages is that programmers want to get things running
correctly and spend more time on the logic and less on making ritual
invocations to the type system that are redundant with other elements of the
code. (Haskell and other similar languages with very strong type inference are
making this a _less_ compelling reason to choose a dynamic language, but I
think it remains an important one for many real decisions, as Haskell hasn't
yet acheived the ecosystem and mind-share where its always likely to be
considered as an alternative, and not rejected for reasons other than its type
system.)

I think people who choose static languages do so because of concerns for
correctness, but I think it is a mistake to reverse that to conclude that
those who choose dynamic languages do so _because_ they aren't concerned with
correctness; many do so because the hoops you need to jump through in
mainstream static languages are perceived as being a too-expensive way to
_get_ the (often very limited, given the lack of expressiveness in the type
systems in many popular static languages) help in correctness that the static
nature of the language provides.

~~~
orting
I think that programmers reasons for choosing a specific language are as
varied as the languages.

Personally I like programming in C++ because the typesystem and abstraction
mechanisms allows me to write reasonably correct and concise code and at the
same time performance is predictable. I like programming in Python because of
the emphasis on readability, the "batteries included" standard library and the
scripting capabilities.

Both languages have failings, as do all the other I have tried, but what
matters most (for me) is availability (platform support, libraries etc), which
is the reason I occasionally write php code.

------
juliangamble
Robert Harper argues that dynamically typed languages are languages of a
single Type:

 _And this is precisely what is wrong with dynamically typed languages: rather
than affording the freedom to ignore types, they instead impose the bondage of
restricting attention to a single type! Every single value has to be a value
of that type, you have no choice!_
[http://existentialtype.wordpress.com/2011/03/19/dynamic-
lang...](http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-
are-static-languages/)

Bob in this same article also wrote the now oft quoted:

 _To borrow an apt description from Dana Scott, the so-called untyped (that is
“dynamically typed”) languages are, in fact, unityped._

Now the author of the linked article wrote another piece in 2012 that rebuts
this:

 _It therefore makes no sense to say that a language is unityped without
qualifying whether that relates to its static or dynamic type system. Python,
for example, is statically unityped and dynamically multityped; C is
statically multityped and dynamically unityped; and Haskell is statically and
dynamically multityped. Although it 's a somewhat minor point, one can argue
(with a little hand waving) that many assembly languages are both statically
and dynamically unityped._

[http://tratt.net/laurie/blog/entries/another_non_argument_in...](http://tratt.net/laurie/blog/entries/another_non_argument_in_type_systems)

It is worth noting:

 _Sam Tobin-Hochstadt argues the uni-typed classification is not very
informative in practice._

 _The uni-typed theory reveals little about the nature of programming in a
dynamically typed language; it 's mainly useful for justifying the existence
of "dynamic" types in type theory._

[https://medium.com/@samth/on-typed-untyped-and-uni-typed-
lan...](https://medium.com/@samth/on-typed-untyped-and-uni-typed-
languages-8a3b4bedf68c)

[http://stackoverflow.com/a/23286279/15441](http://stackoverflow.com/a/23286279/15441)

~~~
gw
Another way to look at it is that the "uni-typed" pejorative assumes that
types are intrinsic to the semantics of a language. Optional type systems
reflect the reverse -- that types are an extrinsic feature that should be
taken care of by an external library, potentially allowing the choice between
multiple competing type checkers or no type checker at all.

[http://www.lispcast.com/church-vs-curry-
types](http://www.lispcast.com/church-vs-curry-types)

~~~
groovy2shoes
The "unityped" descriptor is not meant to be pejorative. It's an observation
that, from a type-theoretic point of view every expression in an untyped
language can be given the same type. In a dynamically checked language, the
type is the sum of all possible dynamic types (in Lua, for example: [1]). In
an unchecked language, the type can be something else (in BCPL, for example,
it's simply _word_ ; in the untyped lambda calculus, it's _function_ ). It's
important to note that, according to type theory, types are a _syntactic_
feature, not a semantic one.

It's just an observation rather than a judgment, and -- again from a type-
theoretic perspective -- it's true. It's nothing to be offended about!

Note that if you were to write a type checker for a unityped language, then
every program would trivially type check. So, while technically accurate, the
notion of a language being "unityped" is not very useful. It's more of an
intellectual curiosity than anything.

[1]:
[https://github.com/LuaDist/lua/blob/lua-5.1/src/lobject.h#L5...](https://github.com/LuaDist/lua/blob/lua-5.1/src/lobject.h#L57)

~~~
gw
You may not mean it as a pejorative, but it's clear that Harper did, and so do
those who adopt the term as a rhetorical device. I also have to question your
use of the phrase "according to type theory". You are implying that there is a
single type theory with a single view on the nature of types. I recommend the
link I put in my previous comment.

~~~
tel
Harper is frequently pejorative. He's also accurate. He has an agenda and it
is difficult to interpret him unbiasedly without accounting for it. But if you
achieve it then you realize you can no longer argue with the factual points he
makes.

That said, it's a completely _true_ point in the notion of "static-types-as-
type-theory-defines-them" that dynamic typing is a mode of use of static
typing which is completely captured in large (potentially infinite/anonymous)
sums. Doing this gives dynamic languages a rich calculus.

Refusing to doesn't strip them of that calculus, it just declares that you're
either not willing to use it or not willing to admit you're using it. Both of
which are fine by me, but occasionally treated pejoratively because... well,
it's not quite clear _why_ you would do such a thing. There's benefit with no
cost.

Then sometimes people extend this to a lack of clarity about why you don't
adopt richer types. Here, at least, there's a clear line to cross as you begin
to have to pay.

\---

The "Church view" and "Curry view" are psychological—the Wikipedia article
even stresses this! So, sure, you can take whatever view you like.

But at the end of the day _type systems satisfy theories_. Or they don't. That
satisfaction/proof is an essential detail extrinsic to your Churchiness or
Curritude.

~~~
groovy2shoes
Can you elaborate a bit on what the benefits of embracing that calculus are?
Or maybe provide some pointers? I'm having trouble imagining what utility
there is in treating untyped languages as (uni)typed. I said in another
comment that it's pretty much a useless notion, but I'm genuinely curious if
I'm overlooking something.

~~~
tel
Probably the best one I can think of is that it gives you a natural way of
looking at gradual typing. Doing gradual typing well is still tough, but you
can see it as an obvious consequence of the unityping argument.

~~~
groovy2shoes
I see. Looks like I have some reading to do :) Thanks.

------
tosh
Interestingly the article also mentions optional type systems that recently
became popular again like in Dart and Hack among other languages.

Optional typing provides a great middle ground between not being restricted by
mandatory types when doing rapid iterations, yet getting the tooling benefits
for core parts of your code base by using types to annotate signatures.

~~~
howardlet03
@tosh true this is so interesting article it also mention all type of system
that became popular. but the most interesting are mandatory types by using
annotate signatures.

------
bch
> At the extreme end of the spectrum, the TCL language implicitly converts
> every type into a string

This isn't the full story. Since 1997, Tcl has used Tcl_Obj internally. These
are called "dual-ported objects", where there are two values contained
therein: a string value, to maintain Tcls logical model of "Everything Is A
String" (EIAS), and a native value of the last-used-type. For example, if the
object was last used as an integer, a native int value will be stored in the
"internalRep". If the next use of this value is in an int context, this native
internalRep value will be used. If one uses a value in an int fashion one
call, then a float the next, then an int, then a float, then an int... you
will incur what is called "shimmering", where the interalRep is recomputed
back/forth. Shimmering is something to avoid where possible.

------
the_af
I don't like the article very much, especially the "Disadvantages of dynamic
typing" section.

\- The first point is about performance, which I doubt is the most fundamental
difference between static and dynamic typing. The author even comments on
whether performance truly matters, except in very low-level tasks, so why list
it first?

\- The real difference between the two systems, program correctness and early
detection of errors, is hidden under the misleading title of "Debugging". It
repeats the classic claim from dynamic typing proponents that "runtime type
errors are rarely an issue", which is wrong in my experience (I've seen my
share of ClassCastExceptions and NullPointerExceptions on production). Also,
it advocates doing Unit Testing as a way to catch type errors, which I also
find wrong. I'd rather focus on writing unit tests for other types of errors
the compiler cannot help me catch.

Other parts also irk me:

\- It lists "interactivity" as a strength of dynamic typing, when lots of
languages with static typing have useful REPLs.

\- The section on Built-in datatypes is baffling.

\- Ditto for refactoring. Static typing for refactoring is a _strength_ , not
a weakness. About the only valid point here is that sometimes we want to
temporarily break static checking of the whole program when testing a small
section, but that probably can be handled by testing in isolation.

------
tegeek
Steve Yegge, famously linked the Software Engineering with political axis.
Interestingly he named people "Liberal" who prefer Dynamic languages over
static.

[https://plus.google.com/110981030061712822816/posts/KaSKeg4v...](https://plus.google.com/110981030061712822816/posts/KaSKeg4vQtz)

~~~
allegory
As a pragmatist, I take from both sides always and I think a lot of us do. To
apply it to politics:

[http://www.allmystery.de/i/t5be775_subgenius_big.jpg](http://www.allmystery.de/i/t5be775_subgenius_big.jpg)

Python with static type hinting is where I want to be.

~~~
mercurial
OCaml works for me: it's readable and about as succinct as Python. Though of
course the ecosystem is much smaller.

~~~
allegory
Good choice but I tried it but couldn't get on with it to be honest. That's
just down to me, not the language though.

~~~
mercurial
I'm not saying it's not clunky, but all in all it's fairly pragmatic. That
said, I'm a big Python fan as well. Of all the dynamic languages I work/worked
with, it's the one that tries hardest to be less of a footgun, and it has a
strong tradition of decent documentation (hear, hear, OCaml library
developers...).

------
graycat
His arguments for the advantages of statically typed language agree with mine.
So, for my programming, I continue to prefer static typing. Sorry 'bout that!

------
eru
Nice and in-depth.

------
swah
Sorry for going meta: does everyone also really enjoyed the formatting
(spacing) and font choice of this article? Its so, so good to read here
(Win7/chrome) I'm thinking of copying it for my websites.

~~~
illumen
Sarcasm?

Justified, with different spacing between words seems really hard to me. The
thin stems also make it hard to read the letters. Finally the column width is
not adjustable by the browser (double tap on mobile, or resize window on
desktop), which kills readability even more.

~~~
swah
Absolutely not. Fixed width is a problem but on Windows I usually have my
browser maximized. Are you on Windows (OSX rendering is much different)?

------
t1m
_Smalltalk is a small, uniform object orientated language,..._

"orientated"??

I hate to be a stickler, but you cannot say "object orientated" any more that
you can say "the object was instantiatated", or "Xerox inventated Smalltalk".

~~~
maxerickson
I dislike orientated, but it is clear enough that it has achieved broad usage
and is no longer a mistake.

~~~
dragonwriter
"orientated" may be a perfectly cromulent word -- and may generally be a
synonym for "oriented" \-- but the phrase describing the programming paradigm
is "object oriented" not "object orientated". Just as "functioning" is
indisputably a good word and may be a rough synonym for "functional", but if
you talk about about Haskell as a "functioning programming language", you may
be correct in a sense, but it won't be as a statement about the programming
paradigm it supports.

------
CmonDev
It seems the consensus is to try and avoid them where possible:

[http://programmers.stackexchange.com/questions/53878/dynamic...](http://programmers.stackexchange.com/questions/53878/dynamic-
vs-statically-typed-languages-for-websites)

[http://programmers.stackexchange.com/questions/10032/dynamic...](http://programmers.stackexchange.com/questions/10032/dynamically-
vs-statically-typed-languages-studies)

[http://programmers.stackexchange.com/questions/246762/is-
the...](http://programmers.stackexchange.com/questions/246762/is-there-a-real-
advantage-to-dynamic-languages?lq=1)

~~~
djur
None of those three links suggest a consensus against dynamically-typed
languages. All of them feature highly-rated arguments in favor of such
languages. How can you even begin to suggest a "consensus" from such a basis?

