6 ms·

Do you have examples of lack of foresight?

jerf 14y ago
There are many examples of things that people now call "lack of foresight", but I think people quickly gloss over just how long Python has been around. It started in December 1989, when the first Pentium was still three years into the future. If Guido had tried to "foresight" his way to a language with an acceptable multicore solution at that point (on any hardware he could afford), the only possible result is total failure. I don't think there are many attributes the language currently possesses that were truly that avoidable. Most people's snap suggestions result in incurring costs to the language that it may not be able to recover from when it is young. Personally, I think the truth is that Python is what it is; a very, very, very good OO language that has reached the mature stage of its life. It probably won't be able to make the leap to "true" multicore, and besides, even if it does it won't be likely to be very successful anyhow because it'll still be a very slow-but-powerful language. (There's very little point in taking a language very near the bottom of the Shootout and adding 4 or even 8 way parallelism to it, when you could just rewrite the target hotspot in C and get the same performance on one core. The math just doesn't favor trying to add lots of "multicore" to such a slow language. Python's one of my favorite languages, but that doesn't mean I can't see where it is weak.)
- batgaijin 14y ago
  Haskell 1.0 was released in 1990.
  - hythloday 14y ago
    The "History of Haskell" paper, a fascinating read in and of itself, is replete with admissions of lack of foresight. The reason Haskell has fared better than Python is probably only that it has a much bigger emphasis on trying new ideas in the reference implementation. The biggest problems with "Python" (GIL, FFI, standard library) are mostly issues with the reference implementation. http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...
    - jerf 14y ago
      And where Python entered production usage in the late 90s and was building up a huge community and a base of code and continued building that base all the way to the present time, Haskell didn't really begin that until around the mid-200xs. It may be an older language in calendar terms, but in terms of libraries and tooling support it's basically 5 years old or so.
- fijal 14y ago
  PyPy (together with LuaJIT and tracemonkey) has been banned from shootout, partly because we complained about unfair rules. Looking at shootout to asses the relative performance of languages where you cannot compare high-performance implementations of a language is a very very bad idea. Looking at shootout to compare would very likely be a bad idea anyhow, but right now it's just completely useless.
  - lmm 14y ago
    Can you give details and/or a citation for the complaints and the banning? I use the shootout a lot to give me a rough idea of a specific language's properties, so if there are valid criticisms then I'd like to hear them, but your post doesn't really stand on its own to someone who doesn't know the backstory.
    - igouy 14y ago
      >>a rough idea of a specific language's properties<< No, but maybe a rough idea of a specific language implementation's properties. >> if there are valid criticisms << There are plenty ;-) http://shootout.alioth.debian.org/dont-jump-to-conclusions.php http://shootout.alioth.debian.org/dont-jump-to-conclusions.p... Readers obviously jump to conclusions based on box plots and summary statistics -- when they really need to look at the individual tasks and look at the program source code, because there's so much variation. I think there would need to be incredibly tight constraints on minimum program run-time, source code size, and memory use; before summary statistics could be taken at face value.
    - fijal 14y ago
      There is pypy-dev discussion about the subject that starts here: http://mail.python.org/pipermail/pypy-dev/2011-April/007139.html http://mail.python.org/pipermail/pypy-dev/2011-April/007139.... It's a long and boring read, but here you go. As in the actual complaints, as far as I remember, but this was a bit ago: * our versions got rejected because they perform slower on CPython (while being faster on PyPy) and because they're 'unobvious'. At the same time, the C implementation of a lot of things there is very unobvious. * we were not allowed to use array.array module, despite being in standard library. * you can use gmp library for C, CPython, but not PyPy via ctypes * C can use a bad random (that's fast, but also gives a really bad distribution), while PyPy not because Python comes with a random in stdlib * custom malloc libraries for C are fine, tuning JIT parameters per-benchmark is not. And various complaints like this. After some discussion, Isaac just kicked us out alltogether. Overall, my personal impression of the experience was that shootout is there to showcase things that are predetermined and we're trying to attack the status quo. This is obviously very personal, I don't have any actual data to back up this claim.

jerf 14y ago

There are many examples of things that people now call "lack of foresight", but I think people quickly gloss over just how long Python has been around. It started in December 1989, when the first Pentium was still three years into the future. If Guido had tried to "foresight" his way to a language with an acceptable multicore solution at that point (on any hardware he could afford), the only possible result is total failure. I don't think there are many attributes the language currently possesses that were truly that avoidable. Most people's snap suggestions result in incurring costs to the language that it may not be able to recover from when it is young. Personally, I think the truth is that Python is what it is; a very, very, very good OO language that has reached the mature stage of its life. It probably won't be able to make the leap to "true" multicore, and besides, even if it does it won't be likely to be very successful anyhow because it'll still be a very slow-but-powerful language. (There's very little point in taking a language very near the bottom of the Shootout and adding 4 or even 8 way parallelism to it, when you could just rewrite the target hotspot in C and get the same performance on one core. The math just doesn't favor trying to add lots of "multicore" to such a slow language. Python's one of my favorite languages, but that doesn't mean I can't see where it is weak.)

batgaijin 14y ago
Haskell 1.0 was released in 1990.
- hythloday 14y ago
  The "History of Haskell" paper, a fascinating read in and of itself, is replete with admissions of lack of foresight. The reason Haskell has fared better than Python is probably only that it has a much bigger emphasis on trying new ideas in the reference implementation. The biggest problems with "Python" (GIL, FFI, standard library) are mostly issues with the reference implementation. http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...
  - jerf 14y ago
    And where Python entered production usage in the late 90s and was building up a huge community and a base of code and continued building that base all the way to the present time, Haskell didn't really begin that until around the mid-200xs. It may be an older language in calendar terms, but in terms of libraries and tooling support it's basically 5 years old or so.
fijal 14y ago
PyPy (together with LuaJIT and tracemonkey) has been banned from shootout, partly because we complained about unfair rules. Looking at shootout to asses the relative performance of languages where you cannot compare high-performance implementations of a language is a very very bad idea. Looking at shootout to compare would very likely be a bad idea anyhow, but right now it's just completely useless.
- lmm 14y ago
  Can you give details and/or a citation for the complaints and the banning? I use the shootout a lot to give me a rough idea of a specific language's properties, so if there are valid criticisms then I'd like to hear them, but your post doesn't really stand on its own to someone who doesn't know the backstory.
  - igouy 14y ago
    >>a rough idea of a specific language's properties<< No, but maybe a rough idea of a specific language implementation's properties. >> if there are valid criticisms << There are plenty ;-) http://shootout.alioth.debian.org/dont-jump-to-conclusions.php http://shootout.alioth.debian.org/dont-jump-to-conclusions.p... Readers obviously jump to conclusions based on box plots and summary statistics -- when they really need to look at the individual tasks and look at the program source code, because there's so much variation. I think there would need to be incredibly tight constraints on minimum program run-time, source code size, and memory use; before summary statistics could be taken at face value.
  - fijal 14y ago
    There is pypy-dev discussion about the subject that starts here: http://mail.python.org/pipermail/pypy-dev/2011-April/007139.html http://mail.python.org/pipermail/pypy-dev/2011-April/007139.... It's a long and boring read, but here you go. As in the actual complaints, as far as I remember, but this was a bit ago: * our versions got rejected because they perform slower on CPython (while being faster on PyPy) and because they're 'unobvious'. At the same time, the C implementation of a lot of things there is very unobvious. * we were not allowed to use array.array module, despite being in standard library. * you can use gmp library for C, CPython, but not PyPy via ctypes * C can use a bad random (that's fast, but also gives a really bad distribution), while PyPy not because Python comes with a random in stdlib * custom malloc libraries for C are fine, tuning JIT parameters per-benchmark is not. And various complaints like this. After some discussion, Isaac just kicked us out alltogether. Overall, my personal impression of the experience was that shootout is there to showcase things that are predetermined and we're trying to attack the status quo. This is obviously very personal, I don't have any actual data to back up this claim.