I am a bit in the middle, I never cared or saw a practical benefit from static typing and neither I saw a practical benefit from using dynamic types. So its a matter that has little interest to me , but then I was never a language orientated person and I cared a lot more about IDEs and visual coding in general.
However there is no doubt that dynamic types have won the war before the war started by the fact that in the history of coding at least the last 30 years I have been around we have witnessed 3 great migrations of coders 1) The migration from Assembly to C/C++ and other high level languages 2) The migration from C++ as the dominant force of coding to Java 3) The migration from static types languages to dynamic typed languages On the matter of python getting optional static typing I can say this and predict this, static type will never become anywhere as big for python as generic types are in static type languages and I say that because I have a good understanding of the python culture. In the end , does it really matter ? Languages are 99.9% personal preferences 0.1% practical needs. If you love coding with static types and you want to use them with your favorite dynamic language , go for it, code any way you want , if there is one thing that the coding field generally needs is to brake away from stereotypes , status quo and embrace innovation and alternative thinking. But I wont hold my breath for that :) On Wed, Jan 20, 2016 at 11:02 AM Thierry Goubier <thierry.goub...@gmail.com> wrote: > 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-rogues.pdf > > 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 > >
