Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic languages are static languages

existentialtype.wordpress.com

Post reply on HN
Print view View original

1–10 of 58 posts

Re: Dynamic languages are static languages

#3

Post by rleisti »

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.

Re: Dynamic languages are static languages

#4

Post by lukesandberg »

kenjackson wrote: post #2

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.

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

Re: Dynamic languages are static languages

#5

Post by ScottBurson »

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

Re: Dynamic languages are static languages

#6

Post by ScottBurson »

ScottBurson wrote: post #5

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

Let me expand just a little on my point about files. When your data are in files, they're just "raw seething bits" (to quote a colorful phrase I once heard); they have no type structure. To turn them into structures in memory, you have to parse and validity-check the contents. (This can be an expensive operation!)

Dynamic languages give you a middle ground: the stuff in memory is more structured than "raw seething bits", but less structured than data in a statically typed program. This is often very handy, as it's much more convenient to operate on data in memory; the slight performance cost relative to fully statically typed data is often no big deal.

Re: Dynamic languages are static languages

#7

Post by baddox »

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.

Re: Dynamic languages are static languages

#8

Post by warrenwilkinson »

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.

Re: Dynamic languages are static languages

#10

Post by regularfry »

rleisti wrote: post #3

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 languag…

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?
Post reply on HN