26 ms·

Funny how emergence works with tools. Give a language too few tools but viral circumstances - the ecosystem diverges (Lisps, Javascript). Give it too long an it

Funny how emergence works with tools. Give a language too few tools but viral circumstances - the ecosystem diverges (Lisps, Javascript). Give it too long an iteration time but killer guarantees, you end up with committees. Python not falling into either of these traps should be understood as nothing short of magic in emergence. I only recently discovered that python's reference typechecker, mypy, has a small side project for typed python to emit C [1], written entirely in python. Nowadays with python's rich specializer ecosystem (LLVM, CUDA, and just generally vectorized math), the value of writing a small program in anything else diminishes quickly. Imagine reading the C++wg release notes in the same mood that you would the python release notes. [1] https://github.com/mypyc/mypyc https://github.com/mypyc/mypyc

anttihaapala 4y ago
Well, the mypyc was not a side project originally, as mypy was conceived to be a complete programming language with optional static typing (https://www.slideshare.net/jukkaleh/mypy-pyconfi2012 https://www.slideshare.net/jukkaleh/mypy-pyconfi2012), but still (almost) 100 % python compatible and that variant was supposed to be transpileable into C.
Yoric 4y ago
I haven't followed development of the Python language in a while but this article was featured last week [1] and it does feel like committees. I have followed development of C++ and... yeah, committees and subcommittees. [1] https://chriswarrick.com/blog/2023/01/15/how-to-improve-python-packaging/ https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth...
- wirrbel 4y ago
  Well, in reality it’s more complicated there always were approaches through committee and approaches outside (conda being an initiative, and lately there is an explosion of tools making use of the pyproject.toml interface). with packaging there are things the committee is good at (making sure that a change to packaging does not break packaging for certain configurations and use cases) and individual initiatives outside of the committee often had drawbacks improving packaging in some area and making it worse in others. But the “committee” then was able to take inspirations into the committee which means there is the best of both worlds. IMHO the python PEP process is a good example of python going the middle way.
  - Yoric 4y ago
    Frankly, yes, the PEP process looks great!
heavyset_go 4y ago
I might be wrong, but I believe that Mypyc is like Nuitka in that you're still using an interpreter that will end up being your bottleneck even after compiling your code. Nuitka gives a ~4x speedup for most code, the bottleneck being the Python VM. You might want to reach for something else if you need better performance than that.
roenxi 4y ago
> Imagine reading the C++wg release notes in the same mood that you would the python release notes. Which mood are we talking about here? Mild dread? They keep adding new features to the language. The Python programming language is around 30. The release notes at this point should be "wow, we found a bug this year! Didn't expect to see one of those!". The secret of Python is it is actually a large community all learning to program together. They all discovered static typing together, they're all learning about functional techniques together (removing reduce() from core Python was a really interesting move), yada yada. It is a happy, productive and cohesive community. Probably a study in how to build a community around a programming language. But one of the reasons I like Clojure is they don't have release notes any more, the release notes are basically "hey we're working on some libraries". They built something extremely powerful and it is done, because there isn't any more power needed in the core. If you invest in learning a tool, the tool shouldn't sprout a new handle and expect to be held differently.
- knighthack 4y ago
  My mood when reading the PEPs is of excitement. While I'm not too keen on hardcore feature divergences, most of the new features have been really nice things to have, and which are never imposed. (E.g. the walrus operator, type hints, dataclasses, etc). I don't see the need to be so outright hostile to changes, unless they were clearly breaking features.
  - aranelsurion 4y ago
    > "and which are never imposed" I'm not sure about that part. Even if one personally ignores something new, someone else within the same project or a dependency will employ the new shiny, and invent one or a couple more ways of doing the same thing in a different way. That means if it's in the language, you'll have to account for it. Not saying Python is, but given enough new features a language may become a kitchen sink of ideas over time. -- (At the risk of contradicting myself a bit here, I actually agree with the features you mentioned here are all nice to have, and I like using them. IDK if nice to have is a high enough barrier to clear though.)
- 4y ago
pjmlp 4y ago
You mean the mood to find out what breaks in every minor Python release? I have been using Python in and out for system administration since version 1.6.
amelius 4y ago
I think the reason that Python made it this far is that from the beginning it had a very well-documented and capable C interface. From this, people started making lots of libraries that accelerated code and provided bindings to other software. At a certain point the ecosystem reached a critical mass, and the rest is history.

anttihaapala 4y ago

Well, the mypyc was not a side project originally, as mypy was conceived to be a complete programming language with optional static typing (https://www.slideshare.net/jukkaleh/mypy-pyconfi2012 https://www.slideshare.net/jukkaleh/mypy-pyconfi2012), but still (almost) 100 % python compatible and that variant was supposed to be transpileable into C.

Yoric 4y ago

I haven't followed development of the Python language in a while but this article was featured last week [1] and it does feel like committees. I have followed development of C++ and... yeah, committees and subcommittees. [1] https://chriswarrick.com/blog/2023/01/15/how-to-improve-python-packaging/ https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth...

wirrbel 4y ago
Well, in reality it’s more complicated there always were approaches through committee and approaches outside (conda being an initiative, and lately there is an explosion of tools making use of the pyproject.toml interface). with packaging there are things the committee is good at (making sure that a change to packaging does not break packaging for certain configurations and use cases) and individual initiatives outside of the committee often had drawbacks improving packaging in some area and making it worse in others. But the “committee” then was able to take inspirations into the committee which means there is the best of both worlds. IMHO the python PEP process is a good example of python going the middle way.
- Yoric 4y ago
  Frankly, yes, the PEP process looks great!

heavyset_go 4y ago

I might be wrong, but I believe that Mypyc is like Nuitka in that you're still using an interpreter that will end up being your bottleneck even after compiling your code. Nuitka gives a ~4x speedup for most code, the bottleneck being the Python VM. You might want to reach for something else if you need better performance than that.

roenxi 4y ago

> Imagine reading the C++wg release notes in the same mood that you would the python release notes. Which mood are we talking about here? Mild dread? They keep adding new features to the language. The Python programming language is around 30. The release notes at this point should be "wow, we found a bug this year! Didn't expect to see one of those!". The secret of Python is it is actually a large community all learning to program together. They all discovered static typing together, they're all learning about functional techniques together (removing reduce() from core Python was a really interesting move), yada yada. It is a happy, productive and cohesive community. Probably a study in how to build a community around a programming language. But one of the reasons I like Clojure is they don't have release notes any more, the release notes are basically "hey we're working on some libraries". They built something extremely powerful and it is done, because there isn't any more power needed in the core. If you invest in learning a tool, the tool shouldn't sprout a new handle and expect to be held differently.

knighthack 4y ago
My mood when reading the PEPs is of excitement. While I'm not too keen on hardcore feature divergences, most of the new features have been really nice things to have, and which are never imposed. (E.g. the walrus operator, type hints, dataclasses, etc). I don't see the need to be so outright hostile to changes, unless they were clearly breaking features.
- aranelsurion 4y ago
  > "and which are never imposed" I'm not sure about that part. Even if one personally ignores something new, someone else within the same project or a dependency will employ the new shiny, and invent one or a couple more ways of doing the same thing in a different way. That means if it's in the language, you'll have to account for it. Not saying Python is, but given enough new features a language may become a kitchen sink of ideas over time. -- (At the risk of contradicting myself a bit here, I actually agree with the features you mentioned here are all nice to have, and I like using them. IDK if nice to have is a high enough barrier to clear though.)
4y ago

pjmlp 4y ago

You mean the mood to find out what breaks in every minor Python release? I have been using Python in and out for system administration since version 1.6.

amelius 4y ago

I think the reason that Python made it this far is that from the beginning it had a very well-documented and capable C interface. From this, people started making lots of libraries that accelerated code and provided bindings to other software. At a certain point the ecosystem reached a critical mass, and the rest is history.