Dynamic languages are static languages • Hacker News Board

Re: Dynamic languages are static languages

#31

Post by ScottBurson » Sun, Mar 20, 2011, 9:07 PM UTC

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?

Yes, you could actually, but I've never seen anyone do it.

Re: Dynamic languages are static languages

#32

Post by codebaobab » Sun, Mar 20, 2011, 9:19 PM UTC

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…

How does Smalltalk get lumped with C and Java and not with Python and Ruby?

Re: Dynamic languages are static languages

#33

Post by sophacles » Sun, Mar 20, 2011, 9:22 PM UTC

codebaobab wrote: post #32

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…

How does Smalltalk get lumped with C and Java and not with Python and Ruby?

Because I thought of it later and clicked in the wrong place and didn't notice. Thanks for the pointer. Editing parent.

Re: Dynamic languages are static languages

#34

Post by xilun0 » Sun, Mar 20, 2011, 9:27 PM UTC

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

Re: Dynamic languages are static languages

#35

Post by TimJYoung » Sun, Mar 20, 2011, 9:42 PM UTC

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…

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

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

Re: Dynamic languages are static languages

#36

Post by effn » Sun, Mar 20, 2011, 10:04 PM UTC

bad_user wrote: post #24

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…

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.

Re: Dynamic languages are static languages

#37

Post by alok-g » Sun, Mar 20, 2011, 10:20 PM UTC

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 not. It's rather about being able to express the concept in the language in a way that is no more or less complex than the concept itself, and expresses no more or less than the concept itself. So the Turing-complete argument does not really apply. (John McCarthy in fact had to say the same thing about Tuning-machines themselves -- that while they help to understand limits of any machine, for AI programs they are at too low a level to help real humans build new insights into AI beyond understanding those limits.)

>> Users of dynamic languages simple trade runtime efficiency for compile-time efficiency. What's wrong with that?

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

2. The bigger issue I have is that dynamic languages often turn compile-time "errors" into run-time errors. Run-time errors take longer to detect and correct and the process of doing so is bound to see less automation. This is not to say of course that dynamic typing is always an issue.

Re: Dynamic languages are static languages

#38

Post by oct » Sun, Mar 20, 2011, 10:25 PM UTC

squidsoup wrote: post #30

mcantor wrote: post #14

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.

This and the comment suggesting that if you went to Carnegie Melon this would all be obvious were a bit of a turnoff.

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!

Re: Dynamic languages are static languages

#39

Post by plesn » Sun, Mar 20, 2011, 10:26 PM UTC

ScottBurson wrote: post #31

harshavr wrote: post #25

Earlier quoted context omitted.

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?

Yes, you could actually, but I've never seen anyone do it.

Haskell's Data.Typeable kind of does this. (http://haskell.org/ghc/docs/latest/html/libraries/base/Data-...). It does not feel like python though…

Re: Dynamic languages are static languages

#40

Post by vorg » Sun, Mar 20, 2011, 10:45 PM UTC

ScottBurson wrote: post #29

kgo wrote: post #12

Earlier quoted context omitted.

1) If CL can only sometimes enforce invariants about type sometimes, and in special cases, I'd argue that the original statement was true. You'll still be deprived in many (probably most) cases. (People have survived falls where their parachutes didn't open, but in an essay most people wouldn't say "You can of course jump out of a plane without a parachute" despite the existence proof. And saying "Although there have…

1) I think the right question to ask here is, how often is the lack of compile-time checking a problem in practice, and how big a problem is it? I've worked extensively in both static and dynamic languages, and my experience has been that in dynamic languages, while I do miss static type checking occasionally, it happens quite a bit less often than your parachute analogy would lead one to imagine. Look at it this way…

Programs written in Python are often augmented with programs written in C. Didn't Python become popular BECAUSE it worked seamlessly with C programs? Use both types of languages together.

But I'm interested in whether type-inferring languages will ever take off, bringing the best of both worlds, i.e. the code tersity of "dynamic" and the compile-time checking of "static". I'm not sure if types can be changed dynamically in these types of languages, though.