Live data from Hacker News

Dynamic languages are static languages

existentialtype.wordpress.com

51–58 of 58 posts

Re: Dynamic languages are static languages

#51
post #47

Earlier quoted context omitted.

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

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.

Re: Dynamic languages are static languages

#52
post #49
post #37

Earlier quoted context omitted.

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

I partly agree to what you said, but just for sake of completeness:

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

This conversion does not sound so trivial to me generally. At times converting from a dynamic language to a statically typed language requires either a change of code architecture or a massive refactoring operation.

>> Do you have an automated system that corrects type errors?

Not corrects, just detects. I have at times faced issues when code runs for half-an-hour and then crashes just because a the given object could not be converted to the needed new type at run-time. My reaction: "Sigh! I wish the compiler told me earlier during compile-time!"

Re: Dynamic languages are static languages

#53

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…

Please don't use "strict" regarding a language's type checking. It's already used in domain theory for functions which rely on arguments being well-defined and computable. It is one of Haskell's defining features that by default, functions and data structures are not strict.

http://en.wikipedia.org/wiki/Domain_theory

http://en.wikibooks.org/wiki/Haskell/Denotational_semantics

Re: Dynamic languages are static languages

#54
post #45
post #36

Earlier quoted context omitted.

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

That doesn't work either, since then you will have more than one result. Which one will you dispatch on?

Re: Dynamic languages are static languages

#55
post #36

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.

Oh come on, all you need to do is to (OPTIONALLY) tag the function with the return type.

And it's still a dynamic type system ;)

Re: Dynamic languages are static languages

#56
post #42

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

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

Re: Dynamic languages are static languages

#57
post #52
post #49

Earlier quoted context omitted.

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

I partly agree to what you said, but just for sake of completeness: >> 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. This conversion does not sound so trivial to me generally. At times converting from a dynamic language to a statically typed language requ…

> This conversion does not sound so trivial to me generally. At times converting from a dynamic language to a statically typed language requires either a change of code architecture or a massive refactoring operation.

I didn't claim that it was necessarily trivial. However, I'm happy to claim that it is very rarely required. What is it that they say about premature optimization?

That said, I think that you're overstating the amount of work. As our python friends keep demonstrating, the amount of code that is actually performance-critical is usually fairly small and can be handled by special means once you get things relatively stable.

And, when it is required, it may be an indication of massive success. If you wrote the first version, said massive success may make the conversion someone else's problem. :-)

> Not corrects, just detects. I have at times faced issues when code runs for half-an-hour and then crashes just because a the given object could not be converted to the needed new type at run-time. My reaction: "Sigh! I wish the compiler told me earlier during compile-time!"

No optimization produces speedups in every situation.

As to that particular problem, I develop in dynamic languages so I "never" have that problem after a significant amount of run-time.

To me, it's important to remember that dynamically and statically typed languages give you different rope with which to hang yourself, so it's best to program with that in mind.

To put it another way, it is generally agreed that it's a bad idea to write fortran in other languages even though it is possible. Why would you think that it would be a good idea to write static in a dynamic language or the reverse?

Re: Dynamic languages are static languages

#58
post #54
post #45

Earlier quoted context omitted.

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

That doesn't work either, since then you will have more than one result. Which one will you dispatch on?

Presumably, you'll have some rules that determine which is the best match and then error if it's ambiguous - just like the static case
Post reply on HN