5 ms·

The part that really surprised me was this: We only had 23 years of Python interpreter development, how would things look like when Python is 42, like C?

The part that really surprised me was this: We only had 23 years of Python interpreter development, how would things look like when Python is 42, like C? C, which I always think of as an ancient venerable systems language, is less than twice as old as Python, which I think of as a hot new kid on the block. In thirty years, when my career will probably be drawing to a close, Python will be 53 years old and C will be 72 years old. Barely any difference at all.

coldtea 13y ago
>We only had 23 years of Python interpreter development, how would things look like when Python is 42, like C? Well, mostly like it is today. Maybe a little better, maybe a little slower. Python hasn't progressed much. Compare it to the last 10 years and it's mostly a flatline, if not a slight decline with some 3.x versions. Whereas C was from the onset one of the fastest or THE fastest language on any machine. Getting fast is not usually due to some incremental effort. You either go for it or not. If you start from a slow language, incremental changes without a big redesign of the compiler/interpreter never get you that far. Javascript got fast in 3 years -- not by incrementally changing the Javascript interpreters they had before, but by each of the major players (Apple, Google, Mozilla) writing a new JIT interpreter from scratch. In 2007 it was dog slow, and then in 2008 all three major JS interpreters got fast. Sure, they have been enhanced since, but the core part was changing to JIT, adding heuristics all around, etc. Not incrementally improving some function here and some operation there.
- gizmo686 13y ago
  >Whereas C was from the onset one of the fastest or THE fastest language on any machine. You can't write performance critical code in C. C is great for high level code, but if performance is important there is no alternative to assembly.
  - jamesaguilar 13y ago
    True. The Linux kernel and most image processing libraries are written in assembly, after all. Actually, assembly will generally not give you much of a speedup over c. The exception is when you use assembly only features like vectorization in ways that compilers can't figure out.
  - codygman 13y ago
    Well, actually there is no alternative to machine code: http://www.setec.org/mel.txt http://www.setec.org/mel.txt
  - coldtea 13y ago
    >You can't write performance critical code in C. C is great for high level code, but if performance is important there is no alternative to assembly. That statement makes no sense. Of course you can write performance critical code in C. People write all kinds of performance critical code in C. Heck, kernels are written in C. What's more "performance critical" than a kernel? Ray traycers are written in C. Real time systems are written in C. Servers are written in C. Databases are written in C. Socket libraries. Multimedia mangling apps like Premiere are written in C (or C++). Scientific number crunching libraries for huge datasets are written in C (and/or Fortran). The kind of "performance critical code" you have to write in assembly is a negligible part of overall performance critical code. And the speed benefit is not even that impressive.
    - spc476 13y ago
      That's true now (and perhaps has been true for easily the past fifteen years). But up til the early-to-mid-90s, it was relatively easy for a decent assembly language programmer to beat a C compiler. In fact, it wasn't until the early mid-90s that general purpose CPUs broke 100MHz. Just be very thankful you don't have to deal with C compilers under MS-DOS what with the tiny, small, medium, compact, large and huge memory models (I think that's all of them).
      - ygra 13y ago
        Even now performance-critical code is assembly. Just take a look at your libc's memcpy implementation, for example. Most likely there's a default C implementation that is reasonably fast and a bunch of assembly versions for individual architectures.
        coldtea 13y ago
        >Even now performance-critical code is assembly. The problem I have with this statement is that it implies other code, like the kernel, a ray-tracer, video editor, number crunching etc, stuff usually done in C/C++, are not "performance critical". Let's call what you describe "extremely performance critical" if you wish. With that said, MOST performance critical code is written in C/C++. Code that's not that much performance critical is written in whatever.
- pekk 13y ago
  You assert that Python hasn't progressed much, but you thumb down the project to progress it (Python 3). Should Python try to improve, or just remain in the same state forever? You can't have both. Your assertion that optimization must always happen all at once is completely bogus.
  - rm445 13y ago
    Take a deep breath, I believe parent post's comment about python not progressing was referring to performance, not a general dig.
  - coldtea 13y ago
    >You assert that Python hasn't progressed much, but you thumb down the project to progress it (Python 3). I was talking performance wise. There are benchmarks from the Python devs out there that confirm what I wrote. I did not speak about Python as a language in general. That said, if you want my opinion, Python 3 is not much progress in that regard either. >Your assertion that optimization must always happen all at once is completely bogus That's good, because I never asserted that. I didn't say that "optimization must always happen all at once", just that incremental optimization doesn't yield much benefits compared to a thorough interpreter rewrite with optimization in mind. Python's history confirms this totally. And not only is Javascript a counter-example (all at once optimization getting huge results), but PyPy also is.
- andreasvc 13y ago
  Speedup is not the only kind of progress. Programming in Python has gotten more convenient due to more libraries, while avoiding buffer overflows in C will always require enormous care.
  - kzrdude 13y ago
    C still requires the programmer to know the language inside and out, but all kinds of static and dynamic checking tools have become available.
- lucian1900 13y ago
  Not really, PyPy happened. We do have a nice JIT for Python, we just need to use it more.

coldtea 13y ago

>We only had 23 years of Python interpreter development, how would things look like when Python is 42, like C? Well, mostly like it is today. Maybe a little better, maybe a little slower. Python hasn't progressed much. Compare it to the last 10 years and it's mostly a flatline, if not a slight decline with some 3.x versions. Whereas C was from the onset one of the fastest or THE fastest language on any machine. Getting fast is not usually due to some incremental effort. You either go for it or not. If you start from a slow language, incremental changes without a big redesign of the compiler/interpreter never get you that far. Javascript got fast in 3 years -- not by incrementally changing the Javascript interpreters they had before, but by each of the major players (Apple, Google, Mozilla) writing a new JIT interpreter from scratch. In 2007 it was dog slow, and then in 2008 all three major JS interpreters got fast. Sure, they have been enhanced since, but the core part was changing to JIT, adding heuristics all around, etc. Not incrementally improving some function here and some operation there.

gizmo686 13y ago
>Whereas C was from the onset one of the fastest or THE fastest language on any machine. You can't write performance critical code in C. C is great for high level code, but if performance is important there is no alternative to assembly.
- jamesaguilar 13y ago
  True. The Linux kernel and most image processing libraries are written in assembly, after all. Actually, assembly will generally not give you much of a speedup over c. The exception is when you use assembly only features like vectorization in ways that compilers can't figure out.
- codygman 13y ago
  Well, actually there is no alternative to machine code: http://www.setec.org/mel.txt http://www.setec.org/mel.txt
- coldtea 13y ago
  >You can't write performance critical code in C. C is great for high level code, but if performance is important there is no alternative to assembly. That statement makes no sense. Of course you can write performance critical code in C. People write all kinds of performance critical code in C. Heck, kernels are written in C. What's more "performance critical" than a kernel? Ray traycers are written in C. Real time systems are written in C. Servers are written in C. Databases are written in C. Socket libraries. Multimedia mangling apps like Premiere are written in C (or C++). Scientific number crunching libraries for huge datasets are written in C (and/or Fortran). The kind of "performance critical code" you have to write in assembly is a negligible part of overall performance critical code. And the speed benefit is not even that impressive.
  - spc476 13y ago
    That's true now (and perhaps has been true for easily the past fifteen years). But up til the early-to-mid-90s, it was relatively easy for a decent assembly language programmer to beat a C compiler. In fact, it wasn't until the early mid-90s that general purpose CPUs broke 100MHz. Just be very thankful you don't have to deal with C compilers under MS-DOS what with the tiny, small, medium, compact, large and huge memory models (I think that's all of them).
    - ygra 13y ago
      Even now performance-critical code is assembly. Just take a look at your libc's memcpy implementation, for example. Most likely there's a default C implementation that is reasonably fast and a bunch of assembly versions for individual architectures.
      - coldtea 13y ago
        >Even now performance-critical code is assembly. The problem I have with this statement is that it implies other code, like the kernel, a ray-tracer, video editor, number crunching etc, stuff usually done in C/C++, are not "performance critical". Let's call what you describe "extremely performance critical" if you wish. With that said, MOST performance critical code is written in C/C++. Code that's not that much performance critical is written in whatever.
pekk 13y ago
You assert that Python hasn't progressed much, but you thumb down the project to progress it (Python 3). Should Python try to improve, or just remain in the same state forever? You can't have both. Your assertion that optimization must always happen all at once is completely bogus.
- rm445 13y ago
  Take a deep breath, I believe parent post's comment about python not progressing was referring to performance, not a general dig.
- coldtea 13y ago
  >You assert that Python hasn't progressed much, but you thumb down the project to progress it (Python 3). I was talking performance wise. There are benchmarks from the Python devs out there that confirm what I wrote. I did not speak about Python as a language in general. That said, if you want my opinion, Python 3 is not much progress in that regard either. >Your assertion that optimization must always happen all at once is completely bogus That's good, because I never asserted that. I didn't say that "optimization must always happen all at once", just that incremental optimization doesn't yield much benefits compared to a thorough interpreter rewrite with optimization in mind. Python's history confirms this totally. And not only is Javascript a counter-example (all at once optimization getting huge results), but PyPy also is.
andreasvc 13y ago
Speedup is not the only kind of progress. Programming in Python has gotten more convenient due to more libraries, while avoiding buffer overflows in C will always require enormous care.
- kzrdude 13y ago
  C still requires the programmer to know the language inside and out, but all kinds of static and dynamic checking tools have become available.
lucian1900 13y ago
Not really, PyPy happened. We do have a nice JIT for Python, we just need to use it more.