3 ms·

Suprisingly, I have the opposite opinion All the people that preach about single project, contributing only to canonical project and having no alternative impl

Suprisingly, I have the opposite opinion All the people that preach about single project, contributing only to canonical project and having no alternative implementations need to check their egos, learn about existance of multiple approaches and why competition is better than monopoly As I see it, article shows how Python, Lua and Ruby failed many people by choosing this approach - causing thousands of devs and millions of users to have slower development and software. Not because it's not possible - but because administratively there's no insentive to do that

aleph_minus_one 2y ago
> All the people that preach about single project [...] need to [...] learn [...] why competition is better than monopoly Then tell me: why is competition better than monopoly for these [!] people?
aragilar 2y ago
At least in the case of Python, it's not obvious it's slower overall. PyPy has always had issues interfacing with C-extensions, and for lots of cases using something built on C-extensions is not only faster but easier to use (see the scientific ecosystem built on numpy). If core parts of your ecosystem don't run, or perform worse on your "faster" alternative, then don't be surprised it isn't widely adopted.
- mananaysiempre 2y ago
  The reason for the “issues” is that the Python/C API, as opposed to the Python language itself or e.g. JNI, has always been considered an implementation detail of CPython specifically; but because CPython is so dominant, essentially everybody tied themselves to it. That is, it’s once again a monoculture problem. (Then of course e.g. Unladen Swallow predates the wide adoption of NumPy but failed regardless.)
  - aragilar 2y ago
    I would suggest the C API is just as much a part of Python as the standard library, and numpy (and swig) predates Unladen Swallow (see e.g. https://stackoverflow.com/questions/2328267/unladen-swallow-with-numpy-scipy https://stackoverflow.com/questions/2328267/unladen-swallow-... for people trying to get them to work together). I don't think it's surprising that micropython/circuitpython have had more success, in many ways they are a port to an environment where the existing libraries wouldn't be used, so they can at some level build their own ecosystem.
    - mananaysiempre 2y ago
      > numpy (and swig) predates Unladen Swallow Sure, but that doesn’t contradict what I said. Numpy is surprisingly old, but in 2010 (my impression was that) supporting it was in no way table stakes for an implementation of Python. Hell, Jython was still occasionally taken seriously then, and Microsoft still pretended they cared about IronPython. > I would suggest the C API is just as much a part of Python as the standard library As things stand, yes, no question. The problem is, it was never designed that way. In particular, it cannot (or at least is not designed to) support any other memory management strategy but CPython’s, thus efforts like HPy[1]. For example, while the language docs admonish you not to depend on __del__ running at any particular moment, if we consider the Python/C API a part of the language, then the language has to behave as though it uses naïve reference counting and occasionally runs a cycle collector. And that’s the easy part—think about how deeply the GIL is rooted there. That is not good design for something that’s part of the language, as it effectively is. It was never intended to be and never received commensurate amounts of care. It just turned out that way—and ain’t that a sad thing to admit. [1] http://hpyproject.org/ http://hpyproject.org/
      - aragilar 2y ago
        I think even back in 2010 (which ironically when I was getting into scientific Python to replace MatLab scripts for labs), numpy was table stakes for any implementation that wanted to be used in scientific Python communities (note that these started in the 90s). Whether the scientific Python communities were big enough then to prevent Unladen Swallow succeeding I don't know, but it would be interesting to compare the Python C API, HPy, and the C APIs (if any) of Perl, Ruby and Tcl (given PDL existed but seemingly failed to be adopted, and Tcl was widely used in science software but also seems to have died out), and see if there was anything about Python's one that caused it to be adopted so widely (my feeling is Java's lack of scripting and baroqueness ruled it out no matter the state of JNI).

aleph_minus_one 2y ago

> All the people that preach about single project [...] need to [...] learn [...] why competition is better than monopoly Then tell me: why is competition better than monopoly for these [!] people?

aragilar 2y ago

At least in the case of Python, it's not obvious it's slower overall. PyPy has always had issues interfacing with C-extensions, and for lots of cases using something built on C-extensions is not only faster but easier to use (see the scientific ecosystem built on numpy). If core parts of your ecosystem don't run, or perform worse on your "faster" alternative, then don't be surprised it isn't widely adopted.

mananaysiempre 2y ago
The reason for the “issues” is that the Python/C API, as opposed to the Python language itself or e.g. JNI, has always been considered an implementation detail of CPython specifically; but because CPython is so dominant, essentially everybody tied themselves to it. That is, it’s once again a monoculture problem. (Then of course e.g. Unladen Swallow predates the wide adoption of NumPy but failed regardless.)
- aragilar 2y ago
  I would suggest the C API is just as much a part of Python as the standard library, and numpy (and swig) predates Unladen Swallow (see e.g. https://stackoverflow.com/questions/2328267/unladen-swallow-with-numpy-scipy https://stackoverflow.com/questions/2328267/unladen-swallow-... for people trying to get them to work together). I don't think it's surprising that micropython/circuitpython have had more success, in many ways they are a port to an environment where the existing libraries wouldn't be used, so they can at some level build their own ecosystem.
  - mananaysiempre 2y ago
    > numpy (and swig) predates Unladen Swallow Sure, but that doesn’t contradict what I said. Numpy is surprisingly old, but in 2010 (my impression was that) supporting it was in no way table stakes for an implementation of Python. Hell, Jython was still occasionally taken seriously then, and Microsoft still pretended they cared about IronPython. > I would suggest the C API is just as much a part of Python as the standard library As things stand, yes, no question. The problem is, it was never designed that way. In particular, it cannot (or at least is not designed to) support any other memory management strategy but CPython’s, thus efforts like HPy[1]. For example, while the language docs admonish you not to depend on __del__ running at any particular moment, if we consider the Python/C API a part of the language, then the language has to behave as though it uses naïve reference counting and occasionally runs a cycle collector. And that’s the easy part—think about how deeply the GIL is rooted there. That is not good design for something that’s part of the language, as it effectively is. It was never intended to be and never received commensurate amounts of care. It just turned out that way—and ain’t that a sad thing to admit. [1] http://hpyproject.org/ http://hpyproject.org/
    - aragilar 2y ago
      I think even back in 2010 (which ironically when I was getting into scientific Python to replace MatLab scripts for labs), numpy was table stakes for any implementation that wanted to be used in scientific Python communities (note that these started in the 90s). Whether the scientific Python communities were big enough then to prevent Unladen Swallow succeeding I don't know, but it would be interesting to compare the Python C API, HPy, and the C APIs (if any) of Perl, Ruby and Tcl (given PDL existed but seemingly failed to be adopted, and Tcl was widely used in science software but also seems to have died out), and see if there was anything about Python's one that caused it to be adopted so widely (my feeling is Java's lack of scripting and baroqueness ruled it out no matter the state of JNI).