Dynamic Typing > Static Typing? « games.greggman.com
Not that we didn't already know this or that we don't feel like this (else you wouldn't be here), but it is nice to see a concise description and some fact based reasoning around this subject:
http://games.greggman.com/game/dynamic-typing-static-typing/ <http://games.greggman.com/game/dynamic-typing-static-typing/>
In summary: 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. Sven
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 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? 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. 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. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/
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
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.goubier@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...
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
Excerpts from Dimitris Chloupis's message of 2016-01-20 12:36:37 +0100:
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
that's a great observation! and you are right, dynamic typed languages have won and smalltalk and lisp had it right all along.
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.
that's a good point too. what i am interested in is the fact that having types available in these languages, research can finally look for conclusive evidence of how much advantage types really give, because all other differences between eg python and c++ are eliminated. i simply do not believe that any findings about types, by comparing python with c++ is valid because they are such different beasts of languages. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/
indeed python and C++ are not just diffirent but two languages going the exact opposite directions, Python emphasizing speed of development , C++ emphasizing speed of execution. In C/C++ every decision must be based upon performance, this not how any other language works , even Java is not that worried about performance, sure its important but it is not the main goal. Hence its not surprising that C++ is the undisputed choice for very performance orientated fields, like Gaming, audio , science that involves heavy calculation. Look at python how popular it has become for scientists but AFTER the fact that so many C++ libraries have been made for python like numpy/scipy and Blaze. So you are absolute to say that some people migrate to dynamic languages not just for dynamic types and is also to say that people stick with C++ and C not because of static types. If that was the case python would not implement optional static types and C++ would not implement generics. The important thing to note here is that we no longer at 80 and 90s , nowdays you can combine any language with anything else and the vast majority of projects are written in multiple languages. I dont agree with the remark "Smalltalk and Lisp were right all along" , obviously they were not because the entire world would have been using smalltalk and lisp which we dont. To claim so is to try to simplify coding and with every simplification it loses a part of the truth. On Wed, Jan 20, 2016 at 5:57 PM Martin Bähr < mbaehr@email.archlab.tuwien.ac.at> wrote:
Excerpts from Dimitris Chloupis's message of 2016-01-20 12:36:37 +0100:
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
that's a great observation! and you are right, dynamic typed languages have won and smalltalk and lisp had it right all along.
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.
that's a good point too. what i am interested in is the fact that having types available in these languages, research can finally look for conclusive evidence of how much advantage types really give, because all other differences between eg python and c++ are eliminated.
i simply do not believe that any findings about types, by comparing python with c++ is valid because they are such different beasts of languages.
greetings, martin.
-- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/
I will not argue whether or not Smalltalk and Lisp were right all along. However, the fact that Smalltalk and Lisp are where they are is not simply a matter of technical merit. There were many, many, political decisions made by the owners of the technology which participated in its successes and failures. Proprietary, commercial, expensive, and the varying corporate entities one had to deal with in order to use this software was a huge factor. Us small guys who would want to use this fantastic enabling technology had our limitations in acquiring this technology. You had to have money and really want to spend it in this manner. This is not to make derogatory statements about their decisions. But they did have an impact. Had the best of Smalltalk and Lisp been open sourced 20 to 30 years ago. Would this be a very different world? I think so. However, the income and profits of those corporations would have been different also. It wasn't our decision to make and we were not living in their shoes. We would have to become knowledgeable about the economics, the state of the competition, the state of their own business, etc. to become even reasonably qualified to judge. Even then different people make different decisions because they think differently or even possibly are looking for different results. Open source was a different and very foreign world back then. It was a very foreign thought to open source your intellectual property and believe that you could earn a living from it. You do have to think different to be a creator of open source software and to be successful at making a living from it. What if Sun put the effort into Strongtalk that they put into Java? Where would we be? I personally believe Smalltalk and Lisp had it right. Own the entire environment and machine. Turtles all the way down. Unfortunately the world isn't so clean. However, we do have a very nice open source Smalltalk inspired tool in Pharo. While the past was not in our control. We do have a say about the future. :) Lets make the future great! Shalom Aleichem Jimmie On 01/20/2016 10:13 AM, Dimitris Chloupis wrote:
indeed python and C++ are not just diffirent but two languages going the exact opposite directions, Python emphasizing speed of development , C++ emphasizing speed of execution.
In C/C++ every decision must be based upon performance, this not how any other language works , even Java is not that worried about performance, sure its important but it is not the main goal.
Hence its not surprising that C++ is the undisputed choice for very performance orientated fields, like Gaming, audio , science that involves heavy calculation. Look at python how popular it has become for scientists but AFTER the fact that so many C++ libraries have been made for python like numpy/scipy and Blaze.
So you are absolute to say that some people migrate to dynamic languages not just for dynamic types and is also to say that people stick with C++ and C not because of static types. If that was the case python would not implement optional static types and C++ would not implement generics.
The important thing to note here is that we no longer at 80 and 90s , nowdays you can combine any language with anything else and the vast majority of projects are written in multiple languages.
I dont agree with the remark "Smalltalk and Lisp were right all along" , obviously they were not because the entire world would have been using smalltalk and lisp which we dont. To claim so is to try to simplify coding and with every simplification it loses a part of the truth.
On Wed, Jan 20, 2016 at 5:57 PM Martin Bähr <mbaehr@email.archlab.tuwien.ac.at <mailto:mbaehr@email.archlab.tuwien.ac.at>> wrote:
Excerpts from Dimitris Chloupis's message of 2016-01-20 12:36:37 +0100: > 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
that's a great observation! and you are right, dynamic typed languages have won and smalltalk and lisp had it right all along.
> 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.
that's a good point too. what i am interested in is the fact that having types available in these languages, research can finally look for conclusive evidence of how much advantage types really give, because all other differences between eg python and c++ are eliminated.
i simply do not believe that any findings about types, by comparing python with c++ is valid because they are such different beasts of languages.
greetings, martin.
-- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se <http://pike.lysator.liu.se> caudium.net <http://caudium.net> societyserver.org <http://societyserver.org> secretary beijinglug.org <http://beijinglug.org> mentor fossasia.org <http://fossasia.org> foresight developer foresightlinux.org <http://foresightlinux.org> realss.com <http://realss.com> unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/
On 20 Jan 2016, at 19:27, Jimmie Houchin <jlhouchin@gmail.com> wrote:
I will not argue whether or not Smalltalk and Lisp were right all along. However, the fact that Smalltalk and Lisp are where they are is not simply a matter of technical merit. There were many, many, political decisions made by the owners of the technology which participated in its successes and failures.
Proprietary, commercial, expensive, and the varying corporate entities one had to deal with in order to use this software was a huge factor. Us small guys who would want to use this fantastic enabling technology had our limitations in acquiring this technology. You had to have money and really want to spend it in this manner.
This is not to make derogatory statements about their decisions. But they did have an impact. Had the best of Smalltalk and Lisp been open sourced 20 to 30 years ago. Would this be a very different world? I think so. However, the income and profits of those corporations would have been different also. It wasn't our decision to make and we were not living in their shoes. We would have to become knowledgeable about the economics, the state of the competition, the state of their own business, etc. to become even reasonably qualified to judge. Even then different people make different decisions because they think differently or even possibly are looking for different results. Open source was a different and very foreign world back then. It was a very foreign thought to open source your intellectual property and believe that you could earn a living from it. You do have to think different to be a creator of open source software and to be successful at making a living from it.
What if Sun put the effort into Strongtalk that they put into Java? Where would we be?
I personally believe Smalltalk and Lisp had it right. Own the entire environment and machine. Turtles all the way down.
Unfortunately the world isn't so clean. However, we do have a very nice open source Smalltalk inspired tool in Pharo. While the past was not in our control. We do have a say about the future. :) Lets make the future great!
Well spoken! Free software became a business enabler thanks to the web. Back then, there was no web, no ability to build global communities pushing forward a shared artefact. I think that is no coincidence that the oldest language that is still mainstream is C, which was used to build Unix, which was used to build the web. Now, let's do something awesome :-)
Well spoken!
Free software became a business enabler thanks to the web. Back then, there was no web, no ability to build global communities pushing forward a shared artefact. I think that is no coincidence that the oldest language that is still mainstream is C, which was used to build Unix, which was used to build the web.
Now, let's do something awesome :-)
Yes :) And business
- 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.
Thierry you see what I would love to have is a R to Pharo :)
Le 22/01/2016 19:35, stepharo a écrit :
- 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.
Thierry you see what I would love to have is a R to Pharo :)
You have I think a lot of the pieces already... SciSmalltalk and Roassal. But I wouldn't bet the R interpreter isn't faster than Pharo on some stats and numerical code: linking with BLAS and the mkl can do wonders... Now, what I'm working for is transparent heterogeneous GPU/Xeon Phi accelerated compute. I think the approach could be used for Pharo as well, but Eliot would be unhappy ;) Thierry
What is funny is that in general people do not believe us :). So I decided that I do not want to talk with type freaks. Stef Le 19/1/16 22:09, Sven Van Caekenberghe a écrit :
Not that we didn't already know this or that we don't feel like this (else you wouldn't be here), but it is nice to see a concise description and some fact based reasoning around this subject:
http://games.greggman.com/game/dynamic-typing-static-typing/ <http://games.greggman.com/game/dynamic-typing-static-typing/> In summary:
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.
Sven
On 20 Jan 2016, at 08:07, stepharo <stepharo@free.fr> wrote:
What is funny is that in general people do not believe us :). So I decided that I do not want to talk with type freaks.
Yes, that was something I forgot to add: it seems that both sides are really very different and opposed to each other. I also gave up this discussion. Personally, I am very much on the dynamic side, but I understand what typing offers. It is just that it does not offer enough: it fixes a small number of problems up front for an enormous cost in added code and loss of flexibility. What was also in the original article is the point that yes, refactoring is a bit easier, more correct and more powerful in a static typed language, but you need much more refactoring there because of all this extra coding to maintain the type constraints (again for little gain). Now, Common Lisp has, IMHO, the right approach to optional typing: not (so much) to catch errors, but specifically to instruct/help the compiler produce more efficient code.
Stef
Le 19/1/16 22:09, Sven Van Caekenberghe a écrit :
Not that we didn't already know this or that we don't feel like this (else you wouldn't be here), but it is nice to see a concise description and some fact based reasoning around this subject:
http://games.greggman.com/game/dynamic-typing-static-typing/ <http://games.greggman.com/game/dynamic-typing-static-typing/> In summary:
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.
Sven
Excerpts from Sven Van Caekenberghe's message of 2016-01-20 09:09:00 +0100:
What was also in the original article is the point that yes, refactoring is a bit easier, more correct and more powerful in a static typed language, but you need much more refactoring there because of all this extra coding to maintain the type constraints (again for little gain).
which extra coding do you mean here? can you give an example? i once translated code from untyped common lisp to typed pike, and the result was almost identical. there was no extra code whatsoever. the only really difference was that variables had type declarations. looking at typescript for example, it has a feature where you can take existing javascript libraries and add type annotations in a separate file. how would adding that type information lead to extra code? that simply makes no sense. if you talk about extra code in java or c++, then that's because those languages are different to dynamic languages in many other ways, not just types. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/
participants (7)
-
David Allouche -
Dimitris Chloupis -
Jimmie Houchin -
Martin Bähr -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier