Re: Dynamic languages are static languages
20/03/11 14:02
Just got done with
http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/
via Hacker news.
Wittgenstein was wrong. Anyone with a layman’s knowledge of Godel (which is all I have) is aware of that. Wittgenstein couldn’t accept it, but it’s clear that Godel demonstrated philosophical logical problems that stand outside of grammar. While it’s been a useful device for academics to dismiss problems as “merely grammar” and strike the oh-ho-ho-read-some-Wittgenstein-you-prole pose, it just isn’t true. (In fact, I think that Godel calls into question all sorts of relativist “truths” that most academics take for granted, but that’s another blog post I will never write.)
Only an academic could read, let alone write, something like that and not break out in howls of laughter.
Admittedly, this is true in a philosophical sense. But the practical difference between dynamic languages and statically typed languages is huge. Someone with a passing familiarity with, say, ruby and java knows this in their bones.
The platonic academic blur tool does not help clarify things here. Yes, yes. At some level everything reduces to a Turning machine, right, we’ve got it. But if you are trying to get things done, each class of language is going to offer distinct advantages and disadvantages.
Just saying “X is a subset of Y in the philosophical sense, so use Y” is not useful.
This is the academic conceit: because I can come up with a conceptual model encompassing both X and Y, I do not need to pay attention to the dirty, practical but philosophically “accidental” differences between X and Y as actual instances within my conceptual model.
I can’t totally disagree with this conclusion: after all, Gosu is statically typed, but has a flexible enough type system to allow you to create dynamic types (as well as statically typed duck types.)
However, I doubt the author would approve of Gosu’s approach. That’s because Gosu is a practical language: rather than strengthening type contracts and heaping more complexity into the language, we decided to just leave hard typing problems alone and focus on the places where they add the most practical value (tools, mostly.) This will offend most academic advocates of static typing, but, due to our observations of actual humans, writing actual code, we think it’s the right thing.
And, in any event, there is a cost to offering a language that “supports the delicate interplay between static and dynamic types.” Namely, that a human brain, when dealing with this kind of code, has to also deal with the interplay between static and dynamic types. That imposes a permanent cognitive load on real world developers that academics almost always ignore.
You see the same problem with generics in Java (or Scala) or the insanity of the type system in Haskell: if only a small, dedicated portion of humanity can understand your machine for making code, your machine ain’t making much code.
So, if you are a practitioner, beware academics bearing theories of programming languages. Look at the instances, ignore the platonic concepts.
In programming languages, as with most things, the guy on the right was correct:
http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/
via Hacker news.
Wittgenstein said that all philosophical problems are problems of grammar.
Wittgenstein was wrong. Anyone with a layman’s knowledge of Godel (which is all I have) is aware of that. Wittgenstein couldn’t accept it, but it’s clear that Godel demonstrated philosophical logical problems that stand outside of grammar. While it’s been a useful device for academics to dismiss problems as “merely grammar” and strike the oh-ho-ho-read-some-Wittgenstein-you-prole pose, it just isn’t true. (In fact, I think that Godel calls into question all sorts of relativist “truths” that most academics take for granted, but that’s another blog post I will never write.)
Dynamic typing is but a special case of static typing
Only an academic could read, let alone write, something like that and not break out in howls of laughter.
Admittedly, this is true in a philosophical sense. But the practical difference between dynamic languages and statically typed languages is huge. Someone with a passing familiarity with, say, ruby and java knows this in their bones.
The platonic academic blur tool does not help clarify things here. Yes, yes. At some level everything reduces to a Turning machine, right, we’ve got it. But if you are trying to get things done, each class of language is going to offer distinct advantages and disadvantages.
Just saying “X is a subset of Y in the philosophical sense, so use Y” is not useful.
This is the academic conceit: because I can come up with a conceptual model encompassing both X and Y, I do not need to pay attention to the dirty, practical but philosophically “accidental” differences between X and Y as actual instances within my conceptual model.
Why should you care? Because, I argue, that a fully expressive language is one that supports the delicate interplay between static and dynamic techniques. Languages that force only one perspective on you, namely the dynamic languages, hobble you; languages that admit both modes of reasoning enable you and liberate you from the tyranny of a single type. Let a thousand flowers bloom!.
I can’t totally disagree with this conclusion: after all, Gosu is statically typed, but has a flexible enough type system to allow you to create dynamic types (as well as statically typed duck types.)
However, I doubt the author would approve of Gosu’s approach. That’s because Gosu is a practical language: rather than strengthening type contracts and heaping more complexity into the language, we decided to just leave hard typing problems alone and focus on the places where they add the most practical value (tools, mostly.) This will offend most academic advocates of static typing, but, due to our observations of actual humans, writing actual code, we think it’s the right thing.
And, in any event, there is a cost to offering a language that “supports the delicate interplay between static and dynamic types.” Namely, that a human brain, when dealing with this kind of code, has to also deal with the interplay between static and dynamic types. That imposes a permanent cognitive load on real world developers that academics almost always ignore.
You see the same problem with generics in Java (or Scala) or the insanity of the type system in Haskell: if only a small, dedicated portion of humanity can understand your machine for making code, your machine ain’t making much code.
So, if you are a practitioner, beware academics bearing theories of programming languages. Look at the instances, ignore the platonic concepts.
In programming languages, as with most things, the guy on the right was correct:
|