Dynamically Typed Languages (2009)

http://tratt.net/laurie/research/pubs/html/tratt__dynamically_typed_languages/

by _qc3o • 12 years ago

55 56 12 years ago

tratt.net

eru• 12 years ago

Nice and in-depth.

CmonDev2• 12 years ago

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

http://programmers.stackexchange.com/questions/53878/dynamic...

http://programmers.stackexchange.com/questions/10032/dynamic...

http://programmers.stackexchange.com/questions/246762/is-the...

mkesper• 12 years ago

Depends on whom you ask, I'd say. These questions don't seem to be unbiased.

djur• 12 years ago

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?

tegeek• 12 years ago

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

allegory5• 12 years ago

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

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

mercurial2• 12 years ago

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

lmm3• 12 years ago

That was what I wanted before I found Scala. If your dislike for OCaml was about syntax or ecosystem then you might also like Scala.

CmonDev2• 12 years ago

Or even better: opt-in dynamic as in C#.

kyllo• 12 years ago

Clojure + core.typed sounds like an ideal balance to me. I haven't actually used it yet but I might for my next side project.

http://typedclojure.org/

judk3• 12 years ago

Let's not humiliate him by dragging his past mistakes into the limelight

orting2• 12 years ago

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.

judk3• 12 years ago

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.

dragonwriter2• 12 years ago

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.

juliangamble• 12 years ago

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

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

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

http://stackoverflow.com/a/23286279/15441

gsg• 12 years ago

That rebuttal is confused and unconvincing. It's easy, although clumsy and verbose, to write a very close equivalent of his "impossible to type check" code example in a static language. Define a sum type that ranges over the necessary values, define a few functions over that type that perform a case analysis corresponding to dynamic type checks, etc. That it's possible to do this is exactly the basis of Harper's argument that dynamic languages are subsumed within static languages.

Here's an concrete didactic example of the approach:

    http://okmij.org/ftp/Scheme/scheme.ml

Static languages are not good dynamic languages (as currently designed), but they do subsume them.

hyperpape• 12 years ago

This is not precisely about Tratt's response, but there was a great discussion on another Bob Harper post where Matthias Felleisen argued that while dynamic languages are semantically unityped, at the level of pragmatics (in the linguistic sense) they allow the programmer to freely mix various implicit type disciplines (http://existentialtype.wordpress.com/2014/04/21/bellman-conf...). The cost is of course that the programmer gets essentially no assistance in verifying that their implicit types are consistent.

tel6• 12 years ago

It's not meant to "inform" very much. Just contextualizes what type safety means!

tel.github.io/2014/08/08/six_points_about_type_safety/

http://tel.github.io/2014/07/08/all_you_wanted_to_know_about...

briantakita3• 12 years ago

I appreciate your coverage on type systems. One thing I want to point out is type systems are "a way" to model an information system. Type systems have become the dominant way in the past 30 or so years, but Type systems are not the only way.

For example, lets look at genetics. Genetics are based on the lineage of reproduction & mutations. The genetics of each organism in the lineage tree is essentially information. This information can be combined with another organism (sexual reproduction) to create a new organism. Also, an organism's genetics change over the lifetime of the organism.

A Type system could model the lineage of each organism in the tree, however it does not seem beneficial to model it in such a way from an abstract point of view. There may be practical reasons to model genetic lineage with types, but I can't think of any. My main reason is types ultimately reduce the resolution of the genetic information.

I feel like Type systems are akin to imposing a bureaucracy on individuals.

gw2• 12 years ago

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

groovy2shoes4• 12 years ago

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

briantakita3• 12 years ago

This notion of dynamically typed languages being a unityped static type system is how a static type system models a dynamic type system. If anything, it shows that dynamic type systems have nuance that can only be modeled as a "unitype" in a static type system, thereby exposing limits to static typing. The "unitype" also shows that types are orthogonal & incidental to solving the real problem. Types may or may not help the programmer, but types are not the direct solution.

I also object to Robert Harper's convoluted rationalization that dynamic type systems are less flexible because it goes against my practical experience. I'm not claiming that I'm the authority when it comes to programming languages. However, I gravitate toward dynamic languages in my career because I feel they offer me more flexibility & less incidental complexity than static languages.

tosh• 12 years ago

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• 12 years ago

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

swah2• 12 years ago

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• 12 years ago

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.

swah2• 12 years ago

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)?

mcguire2• 12 years ago

Looks like it has a color attribute of #333, making the text annoyingly light to me (Linux, Firefox), particularly with the slender font.

I get that black text on a backlit white background has too much contrast for some (many?), but I prefer it to a kind of fuzzy grey.

The font itself and the layout are pretty good, although I'm also looking at it full-screen.

t1m3• 12 years ago

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

judk3• 12 years ago

https://www.google.com/search?q=orientated

How's the weather over there in America today?

Arrogance is unbecoming. If you must be a jerk, you ought also be correct.

t1m3• 12 years ago

https://news.ycombinator.com/item?id=5293748

I am neither a jerk nor an American nor incorrect.

maxerickson• 12 years ago

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

t1m3• 12 years ago

I don't dislike the word "orientated" (it is a real word), nor would I discourage it's use on either side of whatever pond. It's simply not correct to use it in the particular and very specific "object oriented" context. Much like the often mis-camel-cased "SmallTalk", it is incorrect.

Had Alan Kay coined the term "object orientated", I would use it without question.

mcguire2• 12 years ago

Very well, we gift you with the ability to utilize it as much as you like.

dragonwriter2• 12 years ago

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

bch• 12 years ago

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• 12 years ago

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.

graycat• 12 years ago

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!

Dynamically Typed Languages (2009)

Related Stories