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

41–50 of 58 posts

Re: Dynamic languages are static languages

#41

Post by Ingaz »

sophacles wrote: post #28

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…

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.

Re: Dynamic languages are static languages

#42

Post by jarin »

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

Re: Dynamic languages are static languages

#43

Post by jerf »

harshavr wrote: post #25
ScottBurson wrote: post #6

Earlier quoted context omitted.

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

Isn't this a property of the implementation rather than the language, though? Couldn't you have a compiler option to keep the type tags attached to the bits, sacrificing some of the speed benefits of static typing but keeping the primary advantage of proofs/testing?

You would still need to verify the data is still typed correctly. You just can't trust bits in general.

I've come to thinking of a strongly-typed program as being like a cell. Once you cross the cell boundary and it lets you pass, you can trust it and do all the wonderful type-based magic and optimizations that we know and love, but you have to get past that cell boundary first. And as annoying as that may be, poking a gaping wound in the cell wall and just jamming stuff in is likely to have bad results. Even between two cells of the same type, you really ought to do the checking, lest it turn out they not be quite as same as you thought (versioning issues).

(And of course in both theory and practice you still can't truly fully "trust" it even after it gets past the cell wall, but at some point you hit the limits of what you can verify. Real-world cells have the same problem too.)

Re: Dynamic languages are static languages

#44

Post by jerf »

sophacles wrote: post #28

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…

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

[2]: http://en.wikipedia.org/wiki/Type_inference

[3]: http://en.wikipedia.org/wiki/Type_inference#Hindley.E2.80.93...

Re: Dynamic languages are static languages

#45

Post by shasta »

effn wrote: post #36
bad_user wrote: post #24

Earlier quoted context omitted.

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

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.

Well it's not impossible. You could run them all and then decide which result to use. :)

Re: Dynamic languages are static languages

#46

Post by jasonwatkinspdx »

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.

Re: Dynamic languages are static languages

#47

Post by dhess »

kenjackson wrote: post #23
warrenwilkinson wrote: post #8

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.

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…

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

Re: Dynamic languages are static languages

#48

Post by Argorak »

xilun0 wrote: post #34
Argorak wrote: post #13

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

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

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.

Re: Dynamic languages are static languages

#49

Post by anamax »

alok-g wrote: post #37
tomp wrote: post #17

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/Ec…

I have not used dynamic languages enough to know what I say before for sure, but this is my current understanding: >> 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. As I think you note in your last sentence, "expressive" here is not meant to imply whether something can be expressed in the language or…

> 1. A program is run more times than it is compiled (hopefully). So the goal is really to make the effective combination of the two more efficient in a given usage scenario.

You're not counting development time, or rather, cost.

Even if I eventually need the efficiency of a statically typed language, dynamic languages let me save the time that I would have spent satisfying the type checker on code that didn't make it into that version.

> On the other hand, with a dynamic typed language, if N seconds are shoved away from compilation, at least N seconds will be added to run-time.

It's unclear that that's true. In fact, the cost of compile-time type checking is typically more than the cost of run-time type checking during much of development.

> Run-time errors take longer to detect and correct and the process of doing so is bound to see less automation.

Run-time errors aren't detected until run-time but since folks with dynamic languages get to run-time faster, they're often detected earlier.

As to "less automation", I don't see it. Do you have an automated system that corrects type errors?

Re: Dynamic languages are static languages

#50

Post by baddox »

regularfry wrote: post #11
baddox wrote: post #7

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

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.

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