What a Great, long-expected speech encouraging to co-operate instead of fighting against each other... Inspiring and really kind talk, thank you Guido!
Oddly enough, Python got really popular on the theory that it's fundamentally better than Perl. Then, of course, when Ruby started getting popular, suddenly Python, Perl, and Ruby were all the same thing, somehow.
I started learning python just a little bit after python 3 came out and I remember people were so mad about the transition. I also had people saying I should learn python 2.7 instead of 3, but luckily I decided to stick with 3+.
Awesome talk. I definitely agree that the whole eventloop problem isn't something that needs to be in core. We already have Queue, futures, and loads of event loop implementations that rely on native code (pick a GUI toolkit). If you really need event loops, you probably need something else in a GUI toolkit anyway. There are loads of if you need threading, you're probably doing it wrong and should be using processes observations floating aroung the interwebs. Loved it.
Worth watching! Glimpsed over few interesting and key topics. Some good arguments, especially threads, IO and GIL, cpython vs pypy and some not so good ones IMHO such as static typing, which he seems to underestimate. All in all a cool guy.
From personal experience. Guido's sinus congestion/drainage is dependent on a high fat diet. Cut the dairy/meat for a week while on a low fat diet and be amazed.
@caffeinephreak I read his explanation as "nondynamically typed languages alse have errors, so who cares if there are few bugs more?". Then he says 'go and hire wise people', but wait, lion's share of their job could be done (w/o costs) by a compiler... if you gave it some tips (static typing?).
Parallelism means that there is an actual speed up, because the processes are running in the same time frame on different cores. Concurrency and parallelism have some overlapping features. I think the future lies in parallelism. The compiler of a pure language can easily parallelize tasks automatically, because he know when a function is pure (and doesn't have to share resources). This is a huge advantage.
"...if you use them for what threads were originally meant for, OS level threads are meant for parallel level IO, not for doing parallel computation" It's 2012, not 1980, we all have dual-core or better machines. Aside from Python I'm hard pressed to think of a single language (or for that matter OS) that designs threads solely for parallel I/O and not parallel computation.
That is only a basic necessity, but yes it is possible. The only thing about mutable data is, that it makes concurrency and parallelism more complex. E.g. In a purely functional language, you don't have to work with mutexes, which are a major source of headaches. Also note that there is a difference between parallelism and concurrency. Concurrency means simple that the processes are interleaved, this can be simulated on a single core system.
I liked the answers to many of my own questions.. good to hear it from the source. His argument that statically typed languages are moving more towards dynamic are true. What I'd like to have him answer is how Python, and any language for that matter- will hold up to a future that includes something *like* Go. While it's not really popular enough to matter, I can't see how someday everything could simply use Go or Javascript. I'm diehard Python but being honest.
He states that dynamic languages are not inherently inferior to statically typed languages. That's a huge statement, and he doesn't even bother to back it up. Why would I not take advantage of static typing to catch errors that would otherwise get caught at runtime or not at all. Then he mentions that statically typed languages would not catch unit conversion errors from centimeters to inches. So I should throw away all of the benefits of static typing because it does not cover all cases? And he mentions that the purpose of test is to catch these sorts of errors. But tests will only catch a fraction of the errors. At least with static typing a certain class of errors are made impossible, which compared to a dynamic typed program, would require fewer tests to be written.
+crcaccounts I guess, the complete story is that in a dynamic language, while you lose some benefits such as type checking, you also gain some others, such as the better ability to express levels of abstraction. So at the end of the day, it's a tradeoff.
+Prashant Sohani I would like to hear more about the ability to perform better abstraction. I find the idea of mixin interesting, but this can be achieved in static languages with composition. Duck typing is also interesting, but this is basically a static type language interface. I would've also liked to hear about using python within an IDE. I find refactoring java in eclipse effortless. Want to rename a method that has 100 calls sites? One hotkey and 2 seconds later you're done. If I understand python correctly, grep or sed are your only tools, but doing so is not possible safely since two different classes can share the same method name.
+crcaccounts Well, dunno much about your other points; but regarding abstraction, static languages could achieve similar things, but the aim of Python is to express a lot of those features using a few common and simple paradigms such as dynamic typing; which BTW also extend to the under-the-hood 'dunder' methods. (For instance, imagine a @validate decorator that can wrap around any function to pre-validate its arguments based on some criteria.) So again, the aim is to make such levels of abstractions possible with visually minimal and beautiful changes in coding patterns. I'm not claiming that static languages wouldn't find ways to achieve the same thing ; it just that they may look a bit artificial, as if it's something that has been hacked on top of, and not evolving naturally from the language itself. Anyway, just a thought.
The kind of things that Java IDEs do today was pioneered in Smalltalk, a wonderfully dynamic language. Eclipse even began it's life implemented in Smalltalk for Smalltalk (ancestry traces back to VisualAge). Refactoring is very possible in dynamic languages, it just makes inference harder. Look for Alan Kay, Gilad Bracha, David Ungar and Carl Hewitt on dynamic typing, they all have some good points on it. There's also very interesting talk between Felleisen and Bracha about types here on yt. Of course you can do the same stuff, you just do it differently, and that's the whole point. You can implement static types on top of a dynamic language, or you can implement a dynamic language on top of a static one. I'd rather go static on top of dynamic if I really have to.
+crcaccounts Dynamic languages(DL) can do everything that static typing languaes(SL) do; DL and SL is not mutually exclusive and SL is simply a restriction on DL. For example, python supports static typing with mypy library, and I heard that Dropbox resort on this feature to a large degree and improved performance and got ride of typing bugs.
Guido's comments on typing suggest he's never coded in Haskell. This "the compiler can't catch every bug so I declare it should catch none" mantra is nonsense.
Did you listen to the talk? He has other comments about Haskell than the type system - he likes it but thinks it's not the right tool for all kinds of problems, mainly, when you deal with code that's impure by definition (because of the resources it needs to use). Basically, Python is a Swiss army knife while Haskell is more like universal 3D printer - you can solve all problems with it as well, but for the stuff that a Swiss army knife is fine your development time will skyrocket.
but go is a compiled language... or is that your point i can't tell. Anyway, I think python being a dynamically typed language that is far cleaner than javascript I really think that python is more representative of the "future language".. i really think/hope javascript will die before python..
python is awesome except for the excessive parsing yeesh...i used to hate c# because every time id make an error it wouldn't run but with python....if you kinda get it....the program runs the function.....sees something that doesn't make sense. thinks to itself and goes "" meh" looks off but whatever.....changes a critical value to what it thinks it was and you spend hours hunting through mystical magical forests of white-space only to notice the one Tiny semantic mistake error on line 4009
What a Great, long-expected speech encouraging to co-operate instead of fighting against each other...
Inspiring and really kind talk, thank you Guido!
No, he's trolling and repeating FUD about static typing.
What he's saying about Python vs. Perl vs. Ruby is so true, their communities and approach to programming are all pretty similar.
+Adam Jimenstien His approach is really good! I Agree!
Oddly enough, Python got really popular on the theory that it's fundamentally better than Perl. Then, of course, when Ruby started getting popular, suddenly Python, Perl, and Ruby were all the same thing, somehow.
And now, Python 3 is excellent. Python 2.7 should only be used when using old libraries or modules.
Python 3 is the now and future.
Running Guido presentations in 1.25 speedup turns out to be a great deal!
1.5x is better. 1.75x would be better yet, but that's not an option in any of the current browsers, unfortunately. 2x is just a little too fast.
Thanks for this idea.
The "Faster Video" Firefox extension makes this possible. github.com/ispedals/Faster-Video
Actually one has to be very careful about not calling every criticism he hears as "trolling".
I started learning python just a little bit after python 3 came out and I remember people were so mad about the transition. I also had people saying I should learn python 2.7 instead of 3, but luckily I decided to stick with 3+.
Awesome talk. I definitely agree that the whole eventloop problem isn't something that needs to be in core. We already have Queue, futures, and loads of event loop implementations that rely on native code (pick a GUI toolkit). If you really need event loops, you probably need something else in a GUI toolkit anyway. There are loads of if you need threading, you're probably doing it wrong and should be using processes observations floating aroung the interwebs. Loved it.
Guido van Awesome!
Worth watching! Glimpsed over few interesting and key topics. Some good arguments, especially threads, IO and GIL, cpython vs pypy and some not so good ones IMHO such as static typing, which he seems to underestimate. All in all a cool guy.
So, the Python 2 hell never came to an end, even though it is no longer supported.
Soon it will be 5 years in the future... 11:42
Great keynote! so much fun~
Agreeing with ancientrussian: great talk, great ideas and great arguments against trolls!
Thanks Guido
From personal experience. Guido's sinus congestion/drainage is dependent on a high fat diet. Cut the dairy/meat for a week while on a low fat diet and be amazed.
Thanks for you Guido - python best language programming
Which isn't an argument against static typing. Those "hard bugs" are there regardless, so why not have static typing?
the t shirt he is wearing hahaha i want one
I hope he is trolling about not being able to switch slides and coughing into his hand... ;)
+Embeh He should have not used a better presentation tool. He should know how to use 90% of presenation tools.
Awsome !!
@caffeinephreak I read his explanation as "nondynamically typed languages alse have errors, so who cares if there are few bugs more?". Then he says 'go and hire wise people', but wait, lion's share of their job could be done (w/o costs) by a compiler... if you gave it some tips (static typing?).
Awesome talk
Parallelism means that there is an actual speed up, because the processes are running in the same time frame on different cores.
Concurrency and parallelism have some overlapping features.
I think the future lies in parallelism. The compiler of a pure language can easily parallelize tasks automatically, because he know when a function is pure (and doesn't have to share resources). This is a huge advantage.
"...if you use them for what threads were originally meant for, OS level threads are meant for parallel level IO, not for doing parallel computation"
It's 2012, not 1980, we all have dual-core or better machines. Aside from Python I'm hard pressed to think of a single language (or for that matter OS) that designs threads solely for parallel I/O and not parallel computation.
BEN FOLDS built PYTHON?! My hero!
Nice shirt!
What about Go!?
That is only a basic necessity, but yes it is possible. The only thing about mutable data is, that it makes concurrency and parallelism more complex. E.g. In a purely functional language, you don't have to work with mutexes, which are a major source of headaches.
Also note that there is a difference between parallelism and concurrency. Concurrency means simple that the processes are interleaved, this can be simulated on a single core system.
Because it isn't needed? I'm not saying statically typed languages are bad - just that dynamically typed languages aren't necessarily bad either.
"I see I scared you all".... lol !!!
11:00 yeah when we look back to the days we where worried no-one wanted python 3 we will laugh at that and then worry about python 4 instead
I liked the answers to many of my own questions.. good to hear it from the source. His argument that statically typed languages are moving more towards dynamic are true. What I'd like to have him answer is how Python, and any language for that matter- will hold up to a future that includes something *like* Go. While it's not really popular enough to matter, I can't see how someday everything could simply use Go or Javascript. I'm diehard Python but being honest.
sometimes the solution to a problem depends on how you look at it.
there is already pylint
18:44 Responds to complaints that a dynamically typed language is not safe.
He states that dynamic languages are not inherently inferior to statically typed languages. That's a huge statement, and he doesn't even bother to back it up. Why would I not take advantage of static typing to catch errors that would otherwise get caught at runtime or not at all. Then he mentions that statically typed languages would not catch unit conversion errors from centimeters to inches. So I should throw away all of the benefits of static typing because it does not cover all cases? And he mentions that the purpose of test is to catch these sorts of errors. But tests will only catch a fraction of the errors. At least with static typing a certain class of errors are made impossible, which compared to a dynamic typed program, would require fewer tests to be written.
+crcaccounts I guess, the complete story is that in a dynamic language, while you lose some benefits such as type checking, you also gain some others, such as the better ability to express levels of abstraction. So at the end of the day, it's a tradeoff.
+Prashant Sohani I would like to hear more about the ability to perform better abstraction. I find the idea of mixin interesting, but this can be achieved in static languages with composition. Duck typing is also interesting, but this is basically a static type language interface. I would've also liked to hear about using python within an IDE. I find refactoring java in eclipse effortless. Want to rename a method that has 100 calls sites? One hotkey and 2 seconds later you're done. If I understand python correctly, grep or sed are your only tools, but doing so is not possible safely since two different classes can share the same method name.
+crcaccounts Well, dunno much about your other points; but regarding abstraction, static languages could achieve similar things, but the aim of Python is to express a lot of those features using a few common and simple paradigms such as dynamic typing; which BTW also extend to the under-the-hood 'dunder' methods. (For instance, imagine a @validate decorator that can wrap around any function to pre-validate its arguments based on some criteria.) So again, the aim is to make such levels of abstractions possible with visually minimal and beautiful changes in coding patterns. I'm not claiming that static languages wouldn't find ways to achieve the same thing ; it just that they may look a bit artificial, as if it's something that has been hacked on top of, and not evolving naturally from the language itself. Anyway, just a thought.
The kind of things that Java IDEs do today was pioneered in Smalltalk, a wonderfully dynamic language. Eclipse even began it's life implemented in Smalltalk for Smalltalk (ancestry traces back to VisualAge). Refactoring is very possible in dynamic languages, it just makes inference harder.
Look for Alan Kay, Gilad Bracha, David Ungar and Carl Hewitt on dynamic typing, they all have some good points on it.
There's also very interesting talk between Felleisen and Bracha about types here on yt.
Of course you can do the same stuff, you just do it differently, and that's the whole point. You can implement static types on top of a dynamic language, or you can implement a dynamic language on top of a static one. I'd rather go static on top of dynamic if I really have to.
+crcaccounts Dynamic languages(DL) can do everything that static typing languaes(SL) do; DL and SL is not mutually exclusive and SL is simply a restriction on DL. For example, python supports static typing with mypy library, and I heard that Dropbox resort on this feature to a large degree and improved performance and got ride of typing bugs.
shirt by Yoshitomo Nara?
Con cuantos años creo Python ?
Awesome Guido and thanks."trolls" have good answers
in'st haskell better that any one of those?
You can run Python scripts on Android using "android-scripting":
code.google.com/p/android-scripting/
Guido's comments on typing suggest he's never coded in Haskell. This "the compiler can't catch every bug so I declare it should catch none" mantra is nonsense.
Did you listen to the talk? He has other comments about Haskell than the type system - he likes it but thinks it's not the right tool for all kinds of problems, mainly, when you deal with code that's impure by definition (because of the resources it needs to use). Basically, Python is a Swiss army knife while Haskell is more like universal 3D printer - you can solve all problems with it as well, but for the stuff that a Swiss army knife is fine your development time will skyrocket.
2.9????????
2.7 is the latest at this moment (2.7.5).
His point is that this is not the lion's share of their job. Instead the hard bugs that require a lot of work are not found by static typing.
Can u imagine browsers support Python?
34:47 "There are people running Python on machines with sixty-four thousand cpu's." Does he mean 2**10 when he says "thousand"?
Keynote 2012 (Respuestas a preguntas de Trolls): Guido Van Rossum
Explicación amena y sencilla de características básicas del lenguaje.
"your argument is invalid"
Thanks a lot for your detailed and fruitful comment
That is far far far on the future my friend javascript now days is the king of the web.
but go is a compiled language... or is that your point i can't tell. Anyway, I think python being a dynamically typed language that is far cleaner than javascript I really think that python is more representative of the "future language".. i really think/hope javascript will die before python..
what is not for noob
python is awesome except for the excessive parsing
yeesh...i used to hate c# because every time id make an error it wouldn't run
but with python....if you kinda get it....the program runs the function.....sees something that doesn't make sense.
thinks to itself and goes "" meh" looks off but whatever.....changes a critical value to what it thinks it was
and you spend hours hunting through mystical magical forests of white-space only to notice the one Tiny semantic mistake error on line 4009
+Light Bringer Lol. why in a modular language would you have a 4009 line file?
22:00 I see this all the time with male programmers. Know-it-alls.
Fair enough, all I'm saying is that Guido's argument is pretty weak.
Awsome !!