Le 20/01/2016 05:53, Martin Bähr a écrit :
Excerpts from Sven Van Caekenberghe's message of 2016-01-19 22:09:44 +0100:
http://games.greggman.com/game/dynamic-typing-static-typing/ <http://games.greggman.com/game/dynamic-typing-static-typing/> In a dynamically typed language you write (a lot) less code for a shorter program that is easier and faster to write and debug, which gives you more time to think about what you are doing, resulting in more reliable programs.
Static typing catches only a (very) small amount of typing errors, that are just as easy to handle as dynamic typing exceptions, but they are a bit faster.
if that is the case, then why are people working on typescript, why are both python and ruby getting optional types?
I see two reasons - Static typing believers trying to retrofit types into successfull dynamic languages, because it is impossible to write software without static typing - Performance: for a compiler, having access to static types makes compiling and performance optimisation a lot easier. This is my current project (R compilation to heterogeneous targets) and I find that type inference over R code is a hard (and interesting) subject.
i think this is a comparison of apples with oranges. even without typing languages like java, c and c++ are significantly different from dynamic languages like python, ruby, smalltalk and others.
adding typing to javascript, python and ruby means that we can have our cake and eat it too.
so i'll wait for this study to be redone in the next decade, to compare typed with untyped javascript, python and ruby. and only that will show us the real truth. does adding types, with everything else being equal, really make a difference, or not?
Will it? We already have meta-publication studies, and I must say that even arguments like "static types reduces errors" are not even confirmed. I now wonder if type inference is even a good idea. I do think that having explicit (static) typing has benefits; and having the ability to remove those types declarations in specific places (APIs, for example) seems to be a bad idea... Ocaml is a good example: large Ocaml systems are very hard to extend, because types are often not written in the APIs and extension points, and you rely on the IDE to scan the type inference results to be able to understand how you are supposed to use a module... I would really prefer to have incremental/optional typing to use types at API entry points, to document and freeze the code.
btw: the guys at rubyrogues make an interesting argument why lack of typing works better in smalltalk than it does in ruby: http://devchat.cachefly.net/rubyrogues/transcript-155-rr-why-ruby-sucks-ruby... read page 8 of that transcript.
basically they are saying that because java and c/c++ are compiled they can be analyzed statically and you can build great refactoring tools for them because the tools can predict which methods are the same. and in difference to that smalltalk and lisp only know the code at runtime and so they can't make those predictions. but they make up for that because they are always running. there is no such thing as not runtime. you can simply ask the system about its state, like find out which object in the whole system would respond to a particular message. and in ruby you can't do either of those.
This is an interesting argument, except that if you had a correct model of the code set, being able to run it doesn't seems as mandatory to reason on it. Now, maybe Ruby need a Ring like implementation?
disclaimer: for the last 20 years, my main programming language has been pike, a dynamic language like smalltalk, but with declarative typing. (it's optional, in the sense that you can declare a type as "mixed" which can be anything, so just like typescript, and how python and ruby will be once they have optional types)
greetings, martin.
Regards, Thierry