7 ms·

Dynamic languages are static languages

54 points by gaiusparx 16y ago

kenjackson 16y ago
Good blog entry. I do like the direction C# is going with the dynamic type. I want a statically typed language, but I want the ability to have dynamically extensible type classification -- when I want it.
- lukesandberg 16y ago
  Are you referring to extension methods? Or the "dynamic" keyword/type? I've only used the dynamic type a little bit, can you use it to solve the type vs representation problem he is referring to? Thanks
  - kenjackson 16y ago
    Yes. Basically it works by using the class hierarchy to define types. And w/ subtype polymorphism you get new types that are also classified under their base types. And with dynamic you now get the ability to join the "uber type" and be classified dynamically.
rleisti 16y ago
One of the things that a 'dynamic' type system (or as the author would see it, a restriction to a single type) imposes on its creators is the need to make that single type as useful as possible. This includes things like being able to easily lookup an object's class, documentation, methods, properties, uses (is it a sequence? is it a map?, etc.). As a result, I find the design of the core libraries of dynamic languages like Clojure more well thought-out than say something like .NET. It's simple things like being able to treat a string as a sequence (Haskell, a statically-typed language, does this), an 'object' as a map, a map as a sequence, etc. I wonder if it has to do with a sort of de-centralization of control; being dynamic seems to make a language more malleable and open to experimentation. Accomplishing the same things in a statically-typed language requires more planning (which means that after it ships, its too late). I really appreciate a well-thought out static language like Haskell, but it still has some way to go for the common programmer. For now, I don't think that the practical outcome of this article is for programmers to abandon dynamic languages.
- regularfry 16y ago
  You could do that sort of classless message passing in a static language. In fact, isn't that how message dispatch in Obj-C works?
  - lloeki 16y ago
    The only statically typed part of Obj-C is the C part, while the Obj-C types are themselves dynamic.
- TimJYoung 16y ago
  "This includes things like being able to easily lookup an object's class, documentation, methods, properties, uses (is it a sequence? is it a map?, etc.)." Most decent OO, statically-typed compilers allow for runtime type information. Delphi (native) and the .NET compilers allow you to query all sorts of information about a given object instance, including its class name, properties, methods, etc. Here's some links on Delphi's native compiler RTTI and attributes: http://stackoverflow.com/questions/2217068/why-should-i-care-about-rtti-in-delphi http://stackoverflow.com/questions/2217068/why-should-i-care... http://robstechcorner.blogspot.com/2009/09/so-what-is-rtti-rtti-is-acronym-for-run.html http://robstechcorner.blogspot.com/2009/09/so-what-is-rtti-r... Object instances in environments like .NET and Delphi are inherently dynamically-typed. Statically-typed languages provide the safety of checking the "stupid stuff" during compilation without sacrificing the flexibility of using dynamic types in the form of classes. And many do so without any major compilation overhead (Delphi and .NET compilers are very fast).
ScottBurson 16y ago
"Since every value in a dynamic language is classified in this manner, what we are doing is agglomerating all of the values of the language into a single, gigantic (perhaps even extensible) type." Yes, that's right, but you're overlooking the upside of doing things this way. What this gives us is the ability to define new types -- to extend the universal type, if you want to put it that way -- at runtime. No longer do we need this strict separation between compilation time and runtime; no longer do we need the compiler to bless the entire program as being type-correct before we can run any of it. This is what gives us incremental compilation, which (as I just argued elsewhere, http://news.ycombinator.com/item?id=2345424 http://news.ycombinator.com/item?id=2345424) is a wonderful thing for productivity. "[...] you are depriving yourself of the ability to state and enforce the invariant that the value at a particular program point must be an integer." This is just false. Common Lisp implementations of the CMUCL family interpret type declarations as assertions, and under some circumstances will warn at compile time when they can't be shown to hold. Granted, not every CL implementation does this, and the ones that do don't necessarily do it as well as one would like; plus, the type system is very simple (no parametric polymorphism). Nonetheless, we have an existence proof that it's possible at least some of the time (of course, it's uncomputable in general). "[...] you are imposing a serious bit of run-time overhead to represent the class itself (a tag of some sort) and to check and remove and apply the class tag on the value each time it is used." For many kinds of programming, the price -- which is not as high as you suggest, anyway -- is well worth paying. In particular, dynamicity is necessary whenever data live longer than the code manipulating them. If you want to be able to change the program arbitrarily while not losing the data you're working with, you need dynamicity. In dynamic languages, the data can remain live in the program's address space while you modify and recompile the code. With static languages, what you have to do is write the data into files, change your program, and read them back in. Ah, but when you read them in, you have to check that their contents are of the correct type: you've pushed the dynamicity to the edges of your program, but it's still there. For this reason, database systems -- the prototypical case of long-lived data -- have to be dynamic environments, in which types (relational schemata, e.g.) can be modified without destroying the existing data. So to argue -- rather arrogantly, I might add -- that dynamic languages are really static languages is to overlook an operational difference that is a commonplace to anyone who uses both.
baddox 16y ago
This is an impressive and informative argument. It's a shame that it's aimed at a straw man. I use the term "dynamic language" to refer to a well-recognized (though not perfectly agreed upon) set of languages. I didn't choose the term "dynamic," and I've never tried to argue that since they're dynamic, they're better/more fun/more expressive than non-dynamic languages. Hence the straw man. I use the term simply to distinguish between, say, the set {Java, C, C++} and the set {Python, JavaScript, Ruby}. Most people are aware of this usage and immediately understand the distinction. You could call the latter set "cranberry languages" instead of "dynamic languages" and it would be okay. As long as everyone understands the usage, it's a functional (no programming language pun intended) term.
- regularfry 16y ago
  It's not so much a straw man as it is a misnomer. What he's calling a "dynamic language," I (and I think most others) would call a "dynamically typed language." It's possible to have a dynamically typed, static language - with the dynamic keyword, that's what C# is, for example.
  - baddox 16y ago
    I try to avoid any discussion of "typing" when I comes to programming languages because I recognize both my own ignorance in the nitty gritty of language design and the general lack of consensus in the meaning of "x typing" terminology.
warrenwilkinson 16y ago
Funny how he treats 'static typing' as the natural order and 'dynamic typing' as the special case. I would have pegged it the other way round. Machines are typeless, its all numbers until somebody puts (or doesn't put) a type system on it. Plus it's rather meaningless. Bald is a hair color. Clear is a paint color. Silence is a syllable.
- kenjackson 16y ago
  Your assumption is the natural order of computation are digital computers. I think some will argue that type systems are inherent in the world. Mass has a type, velocity has a type. mv has a type that is a function of mass and velocity. Computation is about expressing the type system that is inherent in the computation. Modern computers not having types are an artifact of their implementation, but not of computation per se.
  - dhess 16y ago
    Whoa there. Church-Turing tells us that everything that is computable is computable by a universal Turing machine. It also tells us that a universal Turing machine and the lambda calculus are computationally equivalent. The lambda calculus is untyped. (There are typed lambda calculi, but they are not computationally more powerful than the lambda calculus. Some of them are less so.)
    - kenjackson 16y ago
      Right. Computability says that you can compute any computable function with the lambda calculus. But I'm saying something broader, which is that anything you're trying to model with computation has a type system. IOW, computability theory says that one can model any computable function, while type theory says that one can properly constrain it. In essence you need both. You can compute if the number five is greater than the color red, but you may want to ensure that you never do.
fedd 16y ago
> That’s one argument, and, to be honest, it’s quite a successful bit of marketing. who markets the dynamic languages? pls show me this person/firm. i'll try to hire them
Argorak 16y ago
To paraphrase an old joke about mathematicians: "He must be a computer scientist!" "How do you know?" "His answer is absolutely correct, but has no practical value." Most of the points he makes do not touch any practical problems of this devide. For example: How do I get my XUnit tests to run if one of the functions/methods/whatever in a file does not compile because the software has changed? Ruby really excells at that: it fails at runtime. Java? Not so, it will break my whole test file at compile time. Any other number of similar examples can be found. Yes, its a problem that the language marrying both of these properties has not been found yet. But Haskell certainly isn't the one. Also, the much respected Erik Meijer made a similar point long ago in a much better fashion: http://lambda-the-ultimate.org/node/834 http://lambda-the-ultimate.org/node/834
- xilun0 16y ago
  As for you comment, if I were in the mood for trolling I would say: likewise. If you introduce a static error in a file, hopefully a tool will detect it, and the sooner the better. That you can't even run any code in the file because it makes no sense any more won't prevent your unit tests from running on other files (or at least a subset) if your program has at least a semi-correct architecture. At this point you just have to use the diagnostic information the compiler gave up to fix the syntaxic/typing problem, instead of trying to fix it at a latter stage for a greater cost. There is absolutely no point in trying to test a program that statical analysis has proved to be wrong.
  - Argorak 16y ago
    In a theoretical sense: yes. But for practical reasons, I do not have one test per compilation unit, but multiple. Thats why I chose XUnit as an example: classes are groups of tests, while the actual tests are written in methods. So it makes sense to defer (or at least to be able to defer) "broken parts" to have a better understanding of how much is exactly broken. And "just have to use" is sometimes not that easy if for example your task is ripping out a whole subsystem and fitting a new one. You would really like to see progress there instead of "tiny feature Y is not provable by your compiler, so I won't tell you whether feature X,Z and B work". So I am interested in whether only a part of the compilation unit makes sense. Ruby does that: I can tell my test suite that I fully expect this test to be broken at the moment and that I want that reported. In Java, I'm lost until I satisfied the complainer - ehm - compiler. Thats actually the reason why I know more then one Java and C shop that use Ruby/Python/similar for their test suite.
mcantor 16y ago
I found this article extremely difficult to read, as he seemed more concerned with enunciating through italics than with expressing his point in a clear and unambiguous manner.
- squidsoup 16y ago
  This and the comment suggesting that if you went to Carnegie Melon this would all be obvious were a bit of a turnoff.
  - oct 16y ago
    I am pretty sure the Carnegie Mellon remark was just saying that a CMU CS graduate would have learned this already. Which is true, since the blog author (Bob Harper) teaches a course there which covers this very topic!
stefano 16y ago
"Now I am fully aware that “the compiler can optimize this away”, at least in some cases, but to achieve this requires one of two things (apart from unreachable levels of ingenuity that can easily, and more profitably, be expressed by the programmer in the first place). Either you give up on modular development, and rely on whole program analysis (including all libraries, shared code, the works), or you introduce a static type system precisely for the purpose of recording inter-modular dependencies." Or you can use a tracing jit. You monitor at runtime the actual values taken by the variables and produce type-specialized code.
kunley 16y ago
Author apparently knows has knowledge and experience, but attributing psychological traits to tools like programming languages is a poor trick and a fallacy.
tomp 16y ago
This article is full of FUD and completely misses the point of static/dynamic distinction (flame-war, if you want). It's a perfect example of someone arguing to make a point without even trying to understand the opposite position. No one has ever argued that dynamic languages are more expressive than static languages. This is impossible, as long as we're considering Turing-complete languages. The fact that Harmony/EcmaScript 5 reference compiler was implemented on OCaml. However, it is equally futile to argue that they are less expressive[1]. "you are imposing a serious bit of runtime overhead to represent the class itself [...] and to check [...] the class [...] on the value each time it is used." Users of dynamic languages simple trade runtime efficiency for compile-time efficiency. What's wrong with that? The point of having multiple languages is that different languages make different things simple and easily expressible. Sure, you can do dynamic programming in Haskell or OCaml, but the language is going to work against you in some way, requiring you to specify your intension in a particularly lengthy and awkward way (think Java, except Java makes you do that for any kind of programming). [1] Ironically, the author fails to point out the one way in which static languages are more "expressive" than dynamic languages: overloading on function's return type. I have yet to see that in a dynamically typed language. tl;dr: All Turing-complete languages are equally expressive, but different languages make different things simple.
- bad_user 16y ago
  About your [1] ... dynamic languages can support multimethods (i.e. method overloading on steroids) so I don't get how a dynamic language can't do overloading based on return type. The difference between a static and a dynamic language would be when this dispatch is made (compile-time versus runtime).
  - effn 16y ago
    Overloading on return type is fundamentally impossible in dynamic languages, since they dispatch on values, and the return value can not be known before the function is called.
    - shasta 16y ago
cscheid 16y ago
As pointed out in a comment on the original, this is a well-known source of holy wars. The interesting bit is that this argument is one of the sides of an equivalence. Dig up the old archives of LtU, http://lambda-the-ultimate.org/classic/lambda-archive.html http://lambda-the-ultimate.org/classic/lambda-archive.html and search for the big threads. This direction of the argument (dynamic languages are static languages) was made most forcefully, in my recollection, by Frank Atanassow. However, the other direction _also_ applies: static languages are dynamic languages. This was first pointed out in LtU, to the best of my memory, by Kevin Millikin, here: http://lambda-the-ultimate.org/node/100#comment-1197 http://lambda-the-ultimate.org/node/100#comment-1197 Someone ought to write up the old days of LtU holy wars somewhere. They taught me more about programming languages than everything I ever read anywhere else. (edit: minor wording)
- bad_user 16y ago
  And as in most holly wars, most arguments thrown around are dumb and without consequence to us, the developers that have to work. Fact: I know of a single statically typed language that could be used for real-world usage and that gets operator-overloading right, and that is Haskell, a language who's authors list contains many PhDs. Another fact: it is perfectly within reach of a talented sophomore student to implement a dynamically typed language with support for multimethods, which would get operator-overloading right, in the course of a single semester. And yet another fact: dynamic versus static really is runtime versus compile-time and many languages to which we refer as being "static" or "dynamic" are in fact somewhere in between. That's because -- real language designers ship. And it would be perfect if the compiler would tell you all kind of things about your algorithm at compile-time, but you have to draw the line somewhere and start making compromises. And did I mention the halting problem? Yes, that's a problem for compile-time too.
sophacles 16y ago
Here is why the article doesn't make sense to me: I frequently find that languages in the "dynamic" group (python, ruby, js, smalltalk etc) feel much, much more similar to languages in the "ultra strict" type group (haskell, ocaml, etc), than either do to say, the medium group (c(#|+)*, java). If the case were really that there is some sort of natural order along the type strictness lines, wouldn't it be that python felt closer to c than to haskell in terms of power and expressiveness?
- codebaobab 16y ago
  How does Smalltalk get lumped with C and Java and not with Python and Ruby?
  - sophacles 16y ago
    Because I thought of it later and clicked in the wrong place and didn't notice. Thanks for the pointer. Editing parent.
- Ingaz 16y ago
  Totally agree. I think it's because "ultra strict" and "dynamic" both oriented on programmer. "Non-strict" oriented on compiler. "Ultra strictness" and dynamic typing in different ways, but both gives help to programmer. Non-strict is just a pain without benefit.
- jerf 16y ago
  What you're seeing there is the distinction between "manifest typing" [1] and "implicit typing" [2]. With manifest typing, you actually have to tell the compiler the specific type. With implicit, it will figure it out, either because (as discussed in the article) everything is the same type "Object", or because it will do type inference. Most modern type inference has started with Hindley-Milner [3], but move beyond it in various ways with varying degrees of justification and success. Raw HM doesn't seem to be enough to work with in practice, but moving beyond it gets you into the realm of undecidability unpleasantly quickly. But some progress is being made. The C(/#/++)/Java languages had a lot of people convinced that being statically typed required manifest typing. Including me. I thought I was against static typing, what I was against was manifest typing. [1]: http://en.wikipedia.org/wiki/Manifest_typing http://en.wikipedia.org/wiki/Manifest_typing [2]: http://en.wikipedia.org/wiki/Type_inference http://en.wikipedia.org/wiki/Type_inference [3]: http://en.wikipedia.org/wiki/Type_inference#Hindley.E2.80.93Milner_type_inference_algorithm http://en.wikipedia.org/wiki/Type_inference#Hindley.E2.80.93...
jarin 16y ago
"Another part of the appeal of dynamic languages appears to be that they have acquired an aura of subversion. Dynamic languages fight against the tyranny of static languages, hooray for us! We’re the heroic blackguards defending freedom from the tyranny of typing! We’re real programmers, we don’t need no stinking type system!" I don't know anyone who prefers dynamic languages who actually thinks this way. I program in both statically- and dynamically-typed languages, and I prefer dynamically-typed languages because it's less code I have to write.
- loup-vaillant 16y ago
  Have you tried real statically typed languages, like ML or Haskell? They're really concise. Sometimes even more so than Python or Ruby.
jasonwatkinspdx 16y ago
While the basic perspective of this post is interesting, I find the authors rhetoric entirely off-putting. Example: "There are ill-defined languages, and there are well-defined languages. Well-defined languages are statically typed, and languages with rich static type systems subsume dynamic languages as a corner case of narrow, but significant, interest." I would like to see justification for the claim that there does not exist a single well defined language with runtime type enforcement. This tone runs through the entire article, which is mostly begging the question rather than supporting the premise. I'd love to see the author's point illustrated by contrasting Haskell/ML and Python/Scheme/Ruby code listings or something similar. Instead the article merely restates its premise in an attempt to make an impression, rather than to inform. Disappointing.

54 points by gaiusparx 16y ago

Good blog entry. I do like the direction C# is going with the dynamic type. I want a statically typed language, but I want the ability to have dynamically extensible type classification -- when I want it.

lukesandberg 16y ago
Are you referring to extension methods? Or the "dynamic" keyword/type? I've only used the dynamic type a little bit, can you use it to solve the type vs representation problem he is referring to? Thanks
- kenjackson 16y ago
  Yes. Basically it works by using the class hierarchy to define types. And w/ subtype polymorphism you get new types that are also classified under their base types. And with dynamic you now get the ability to join the "uber type" and be classified dynamically.

rleisti 16y ago

One of the things that a 'dynamic' type system (or as the author would see it, a restriction to a single type) imposes on its creators is the need to make that single type as useful as possible. This includes things like being able to easily lookup an object's class, documentation, methods, properties, uses (is it a sequence? is it a map?, etc.). As a result, I find the design of the core libraries of dynamic languages like Clojure more well thought-out than say something like .NET. It's simple things like being able to treat a string as a sequence (Haskell, a statically-typed language, does this), an 'object' as a map, a map as a sequence, etc. I wonder if it has to do with a sort of de-centralization of control; being dynamic seems to make a language more malleable and open to experimentation. Accomplishing the same things in a statically-typed language requires more planning (which means that after it ships, its too late). I really appreciate a well-thought out static language like Haskell, but it still has some way to go for the common programmer. For now, I don't think that the practical outcome of this article is for programmers to abandon dynamic languages.

regularfry 16y ago
You could do that sort of classless message passing in a static language. In fact, isn't that how message dispatch in Obj-C works?
- lloeki 16y ago
  The only statically typed part of Obj-C is the C part, while the Obj-C types are themselves dynamic.
TimJYoung 16y ago
"This includes things like being able to easily lookup an object's class, documentation, methods, properties, uses (is it a sequence? is it a map?, etc.)." Most decent OO, statically-typed compilers allow for runtime type information. Delphi (native) and the .NET compilers allow you to query all sorts of information about a given object instance, including its class name, properties, methods, etc. Here's some links on Delphi's native compiler RTTI and attributes: http://stackoverflow.com/questions/2217068/why-should-i-care-about-rtti-in-delphi http://stackoverflow.com/questions/2217068/why-should-i-care... http://robstechcorner.blogspot.com/2009/09/so-what-is-rtti-rtti-is-acronym-for-run.html http://robstechcorner.blogspot.com/2009/09/so-what-is-rtti-r... Object instances in environments like .NET and Delphi are inherently dynamically-typed. Statically-typed languages provide the safety of checking the "stupid stuff" during compilation without sacrificing the flexibility of using dynamic types in the form of classes. And many do so without any major compilation overhead (Delphi and .NET compilers are very fast).

ScottBurson 16y ago

"Since every value in a dynamic language is classified in this manner, what we are doing is agglomerating all of the values of the language into a single, gigantic (perhaps even extensible) type." Yes, that's right, but you're overlooking the upside of doing things this way. What this gives us is the ability to define new types -- to extend the universal type, if you want to put it that way -- at runtime. No longer do we need this strict separation between compilation time and runtime; no longer do we need the compiler to bless the entire program as being type-correct before we can run any of it. This is what gives us incremental compilation, which (as I just argued elsewhere, http://news.ycombinator.com/item?id=2345424 http://news.ycombinator.com/item?id=2345424) is a wonderful thing for productivity. "[...] you are depriving yourself of the ability to state and enforce the invariant that the value at a particular program point must be an integer." This is just false. Common Lisp implementations of the CMUCL family interpret type declarations as assertions, and under some circumstances will warn at compile time when they can't be shown to hold. Granted, not every CL implementation does this, and the ones that do don't necessarily do it as well as one would like; plus, the type system is very simple (no parametric polymorphism). Nonetheless, we have an existence proof that it's possible at least some of the time (of course, it's uncomputable in general). "[...] you are imposing a serious bit of run-time overhead to represent the class itself (a tag of some sort) and to check and remove and apply the class tag on the value each time it is used." For many kinds of programming, the price -- which is not as high as you suggest, anyway -- is well worth paying. In particular, dynamicity is necessary whenever data live longer than the code manipulating them. If you want to be able to change the program arbitrarily while not losing the data you're working with, you need dynamicity. In dynamic languages, the data can remain live in the program's address space while you modify and recompile the code. With static languages, what you have to do is write the data into files, change your program, and read them back in. Ah, but when you read them in, you have to check that their contents are of the correct type: you've pushed the dynamicity to the edges of your program, but it's still there. For this reason, database systems -- the prototypical case of long-lived data -- have to be dynamic environments, in which types (relational schemata, e.g.) can be modified without destroying the existing data. So to argue -- rather arrogantly, I might add -- that dynamic languages are really static languages is to overlook an operational difference that is a commonplace to anyone who uses both.

baddox 16y ago

This is an impressive and informative argument. It's a shame that it's aimed at a straw man. I use the term "dynamic language" to refer to a well-recognized (though not perfectly agreed upon) set of languages. I didn't choose the term "dynamic," and I've never tried to argue that since they're dynamic, they're better/more fun/more expressive than non-dynamic languages. Hence the straw man. I use the term simply to distinguish between, say, the set {Java, C, C++} and the set {Python, JavaScript, Ruby}. Most people are aware of this usage and immediately understand the distinction. You could call the latter set "cranberry languages" instead of "dynamic languages" and it would be okay. As long as everyone understands the usage, it's a functional (no programming language pun intended) term.

regularfry 16y ago
It's not so much a straw man as it is a misnomer. What he's calling a "dynamic language," I (and I think most others) would call a "dynamically typed language." It's possible to have a dynamically typed, static language - with the dynamic keyword, that's what C# is, for example.
- baddox 16y ago
  I try to avoid any discussion of "typing" when I comes to programming languages because I recognize both my own ignorance in the nitty gritty of language design and the general lack of consensus in the meaning of "x typing" terminology.

warrenwilkinson 16y ago

Funny how he treats 'static typing' as the natural order and 'dynamic typing' as the special case. I would have pegged it the other way round. Machines are typeless, its all numbers until somebody puts (or doesn't put) a type system on it. Plus it's rather meaningless. Bald is a hair color. Clear is a paint color. Silence is a syllable.

kenjackson 16y ago
Your assumption is the natural order of computation are digital computers. I think some will argue that type systems are inherent in the world. Mass has a type, velocity has a type. mv has a type that is a function of mass and velocity. Computation is about expressing the type system that is inherent in the computation. Modern computers not having types are an artifact of their implementation, but not of computation per se.
- dhess 16y ago
  Whoa there. Church-Turing tells us that everything that is computable is computable by a universal Turing machine. It also tells us that a universal Turing machine and the lambda calculus are computationally equivalent. The lambda calculus is untyped. (There are typed lambda calculi, but they are not computationally more powerful than the lambda calculus. Some of them are less so.)
  - kenjackson 16y ago
    Right. Computability says that you can compute any computable function with the lambda calculus. But I'm saying something broader, which is that anything you're trying to model with computation has a type system. IOW, computability theory says that one can model any computable function, while type theory says that one can properly constrain it. In essence you need both. You can compute if the number five is greater than the color red, but you may want to ensure that you never do.

fedd 16y ago

> That’s one argument, and, to be honest, it’s quite a successful bit of marketing. who markets the dynamic languages? pls show me this person/firm. i'll try to hire them

Argorak 16y ago

To paraphrase an old joke about mathematicians: "He must be a computer scientist!" "How do you know?" "His answer is absolutely correct, but has no practical value." Most of the points he makes do not touch any practical problems of this devide. For example: How do I get my XUnit tests to run if one of the functions/methods/whatever in a file does not compile because the software has changed? Ruby really excells at that: it fails at runtime. Java? Not so, it will break my whole test file at compile time. Any other number of similar examples can be found. Yes, its a problem that the language marrying both of these properties has not been found yet. But Haskell certainly isn't the one. Also, the much respected Erik Meijer made a similar point long ago in a much better fashion: http://lambda-the-ultimate.org/node/834 http://lambda-the-ultimate.org/node/834

xilun0 16y ago
As for you comment, if I were in the mood for trolling I would say: likewise. If you introduce a static error in a file, hopefully a tool will detect it, and the sooner the better. That you can't even run any code in the file because it makes no sense any more won't prevent your unit tests from running on other files (or at least a subset) if your program has at least a semi-correct architecture. At this point you just have to use the diagnostic information the compiler gave up to fix the syntaxic/typing problem, instead of trying to fix it at a latter stage for a greater cost. There is absolutely no point in trying to test a program that statical analysis has proved to be wrong.
- Argorak 16y ago
  In a theoretical sense: yes. But for practical reasons, I do not have one test per compilation unit, but multiple. Thats why I chose XUnit as an example: classes are groups of tests, while the actual tests are written in methods. So it makes sense to defer (or at least to be able to defer) "broken parts" to have a better understanding of how much is exactly broken. And "just have to use" is sometimes not that easy if for example your task is ripping out a whole subsystem and fitting a new one. You would really like to see progress there instead of "tiny feature Y is not provable by your compiler, so I won't tell you whether feature X,Z and B work". So I am interested in whether only a part of the compilation unit makes sense. Ruby does that: I can tell my test suite that I fully expect this test to be broken at the moment and that I want that reported. In Java, I'm lost until I satisfied the complainer - ehm - compiler. Thats actually the reason why I know more then one Java and C shop that use Ruby/Python/similar for their test suite.

mcantor 16y ago

I found this article extremely difficult to read, as he seemed more concerned with enunciating through italics than with expressing his point in a clear and unambiguous manner.

squidsoup 16y ago
This and the comment suggesting that if you went to Carnegie Melon this would all be obvious were a bit of a turnoff.
- oct 16y ago
  I am pretty sure the Carnegie Mellon remark was just saying that a CMU CS graduate would have learned this already. Which is true, since the blog author (Bob Harper) teaches a course there which covers this very topic!

stefano 16y ago

"Now I am fully aware that “the compiler can optimize this away”, at least in some cases, but to achieve this requires one of two things (apart from unreachable levels of ingenuity that can easily, and more profitably, be expressed by the programmer in the first place). Either you give up on modular development, and rely on whole program analysis (including all libraries, shared code, the works), or you introduce a static type system precisely for the purpose of recording inter-modular dependencies." Or you can use a tracing jit. You monitor at runtime the actual values taken by the variables and produce type-specialized code.

kunley 16y ago

Author apparently knows has knowledge and experience, but attributing psychological traits to tools like programming languages is a poor trick and a fallacy.

tomp 16y ago

This article is full of FUD and completely misses the point of static/dynamic distinction (flame-war, if you want). It's a perfect example of someone arguing to make a point without even trying to understand the opposite position. No one has ever argued that dynamic languages are more expressive than static languages. This is impossible, as long as we're considering Turing-complete languages. The fact that Harmony/EcmaScript 5 reference compiler was implemented on OCaml. However, it is equally futile to argue that they are less expressive[1]. "you are imposing a serious bit of runtime overhead to represent the class itself [...] and to check [...] the class [...] on the value each time it is used." Users of dynamic languages simple trade runtime efficiency for compile-time efficiency. What's wrong with that? The point of having multiple languages is that different languages make different things simple and easily expressible. Sure, you can do dynamic programming in Haskell or OCaml, but the language is going to work against you in some way, requiring you to specify your intension in a particularly lengthy and awkward way (think Java, except Java makes you do that for any kind of programming). [1] Ironically, the author fails to point out the one way in which static languages are more "expressive" than dynamic languages: overloading on function's return type. I have yet to see that in a dynamically typed language. tl;dr: All Turing-complete languages are equally expressive, but different languages make different things simple.

bad_user 16y ago
About your [1] ... dynamic languages can support multimethods (i.e. method overloading on steroids) so I don't get how a dynamic language can't do overloading based on return type. The difference between a static and a dynamic language would be when this dispatch is made (compile-time versus runtime).
- effn 16y ago
  Overloading on return type is fundamentally impossible in dynamic languages, since they dispatch on values, and the return value can not be known before the function is called.
  - shasta 16y ago

cscheid 16y ago

As pointed out in a comment on the original, this is a well-known source of holy wars. The interesting bit is that this argument is one of the sides of an equivalence. Dig up the old archives of LtU, http://lambda-the-ultimate.org/classic/lambda-archive.html http://lambda-the-ultimate.org/classic/lambda-archive.html and search for the big threads. This direction of the argument (dynamic languages are static languages) was made most forcefully, in my recollection, by Frank Atanassow. However, the other direction _also_ applies: static languages are dynamic languages. This was first pointed out in LtU, to the best of my memory, by Kevin Millikin, here: http://lambda-the-ultimate.org/node/100#comment-1197 http://lambda-the-ultimate.org/node/100#comment-1197 Someone ought to write up the old days of LtU holy wars somewhere. They taught me more about programming languages than everything I ever read anywhere else. (edit: minor wording)

bad_user 16y ago
And as in most holly wars, most arguments thrown around are dumb and without consequence to us, the developers that have to work. Fact: I know of a single statically typed language that could be used for real-world usage and that gets operator-overloading right, and that is Haskell, a language who's authors list contains many PhDs. Another fact: it is perfectly within reach of a talented sophomore student to implement a dynamically typed language with support for multimethods, which would get operator-overloading right, in the course of a single semester. And yet another fact: dynamic versus static really is runtime versus compile-time and many languages to which we refer as being "static" or "dynamic" are in fact somewhere in between. That's because -- real language designers ship. And it would be perfect if the compiler would tell you all kind of things about your algorithm at compile-time, but you have to draw the line somewhere and start making compromises. And did I mention the halting problem? Yes, that's a problem for compile-time too.

sophacles 16y ago

Here is why the article doesn't make sense to me: I frequently find that languages in the "dynamic" group (python, ruby, js, smalltalk etc) feel much, much more similar to languages in the "ultra strict" type group (haskell, ocaml, etc), than either do to say, the medium group (c(#|+)*, java). If the case were really that there is some sort of natural order along the type strictness lines, wouldn't it be that python felt closer to c than to haskell in terms of power and expressiveness?

codebaobab 16y ago
How does Smalltalk get lumped with C and Java and not with Python and Ruby?
- sophacles 16y ago
  Because I thought of it later and clicked in the wrong place and didn't notice. Thanks for the pointer. Editing parent.
Ingaz 16y ago
Totally agree. I think it's because "ultra strict" and "dynamic" both oriented on programmer. "Non-strict" oriented on compiler. "Ultra strictness" and dynamic typing in different ways, but both gives help to programmer. Non-strict is just a pain without benefit.
jerf 16y ago
What you're seeing there is the distinction between "manifest typing" [1] and "implicit typing" [2]. With manifest typing, you actually have to tell the compiler the specific type. With implicit, it will figure it out, either because (as discussed in the article) everything is the same type "Object", or because it will do type inference. Most modern type inference has started with Hindley-Milner [3], but move beyond it in various ways with varying degrees of justification and success. Raw HM doesn't seem to be enough to work with in practice, but moving beyond it gets you into the realm of undecidability unpleasantly quickly. But some progress is being made. The C(/#/++)/Java languages had a lot of people convinced that being statically typed required manifest typing. Including me. I thought I was against static typing, what I was against was manifest typing. [1]: http://en.wikipedia.org/wiki/Manifest_typing http://en.wikipedia.org/wiki/Manifest_typing [2]: http://en.wikipedia.org/wiki/Type_inference http://en.wikipedia.org/wiki/Type_inference [3]: http://en.wikipedia.org/wiki/Type_inference#Hindley.E2.80.93Milner_type_inference_algorithm http://en.wikipedia.org/wiki/Type_inference#Hindley.E2.80.93...

jarin 16y ago

"Another part of the appeal of dynamic languages appears to be that they have acquired an aura of subversion. Dynamic languages fight against the tyranny of static languages, hooray for us! We’re the heroic blackguards defending freedom from the tyranny of typing! We’re real programmers, we don’t need no stinking type system!" I don't know anyone who prefers dynamic languages who actually thinks this way. I program in both statically- and dynamically-typed languages, and I prefer dynamically-typed languages because it's less code I have to write.

loup-vaillant 16y ago
Have you tried real statically typed languages, like ML or Haskell? They're really concise. Sometimes even more so than Python or Ruby.

jasonwatkinspdx 16y ago

While the basic perspective of this post is interesting, I find the authors rhetoric entirely off-putting. Example: "There are ill-defined languages, and there are well-defined languages. Well-defined languages are statically typed, and languages with rich static type systems subsume dynamic languages as a corner case of narrow, but significant, interest." I would like to see justification for the claim that there does not exist a single well defined language with runtime type enforcement. This tone runs through the entire article, which is mostly begging the question rather than supporting the premise. I'd love to see the author's point illustrated by contrasting Haskell/ML and Python/Scheme/Ruby code listings or something similar. Instead the article merely restates its premise in an attempt to make an impression, rather than to inform. Disappointing.