4 ms·

Another less popular take is that people (yes me too at times) should check their ego. It can definitely be easier to make "your own" parallel project vs contri

Another less popular take is that people (yes me too at times) should check their ego. It can definitely be easier to make "your own" parallel project vs contributing to an existing open source project, but ask yourself who you're serving. Is it the project maintainers? The project itself? The users? Your own ego? Hint: if that last suggestion makes you mad it's probably in play ;-) Adding a JIT to an existing language is a major undertaking, so the canonical implementation will have a high bar for acceptance. But you should probably still aim for that. Forking or rolling your own can provide freedom to do big things too, but that should often be regarded as temporary. If your goal is to show what you can do, it probably won't go far. If your goal is to make something better for its good, you'll learn to work within others constraints.

konstantinua00 2y ago
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/
Smaug123 2y ago
Pff, sometimes the official things are just completely cursed and you need to create your own little garden. Even if it does turn into twenty acres and a crop-rotation schedule, sometimes that's better than a volcano.

konstantinua00 2y ago

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/

Smaug123 2y ago

Pff, sometimes the official things are just completely cursed and you need to create your own little garden. Even if it does turn into twenty acres and a crop-rotation schedule, sometimes that's better than a volcano.