4 ms·

I’ll never not be bitter than Python “won” the scripting language war over Ruby, more or less just because someone did a bit of AI work in it first and it took

• Revanche1367 2mo ago
  Long before AI work, numerical data crunching is what Python became popular for among non-computer scientists and this led directly to the AI use cases. The reason was obviously the lower barrier to entry without having a software engineering background. I also share with you that feeling about Ruby in particular.
• frollogaston 2mo ago
  Python's strength is that it's easy to make C libs work in it. That's also why CPython is de facto the only Python implementation and stuff like PyPy never took off.
  • AdieuToLogic 2mo ago
    > Python's strength is that it's easy to make C libs work in it. SWIG[0] makes working with C libraries trivial for over a dozen programming languages; Perl, Python, and Ruby included. 0 - https://www.swig.org/ https://www.swig.org/
    • frollogaston 2mo ago
      There are reasons all those Py libraries with C code didn't just do it in SWIG.
      • AdieuToLogic 2mo ago
        > There are reasons all those Py libraries with C code didn't just do it in SWIG. And those reasons are?
        • frollogaston 2mo ago
          The point of SWIG is it works across many langs, but this comes at a cost. The SWIG .i and autogen'd C wrapper are extra layers that can get annoying, particularly during debug. Always hated dealing with SWIG'd libs at work. And Python C modules give easier control over Python specifics.
          • AdieuToLogic 2mo ago
            There's no doubt that hand-written language adapter libraries are less noisy than those generated by a tool such as SWIG. The thing is, debugging tool-generated adapter code is typically more category-based than individual use-case based. IMHO, both approaches have merit depending on the situation. I lean towards using SWIG until and unless the situation warrants a hand-written solution due to the boilerplate nature of these types of libraries.
  • kccqzy 2mo ago
    Yeah and I would say that another important factor is Cython, which compiles Python with minimal modifications to C extensions that can in turn be imported in Python. It really makes it easy to get started in Python and worry about performance of the computation later. (Doesn’t help with concurrency I know but that’s a different story.)
  • dismalaf 2mo ago
    Ruby can interface with C (or Odin, or anything that can export C style functions) just as easily.
    • hetman 2mo ago
      I would argue more easily.
  • hetman 2mo ago
    I like Python but this was always actually one of my pain points. The CPython C API is full of foot guns, the API surface is expansive, and writing against it requires a lot of careful care. Anyone who's ever written C modules for both languages would be able to attest how much more pleasant the experience was for Ruby than Python.
• gucci-on-fleek 2mo ago
  > I’ll never not be bitter than Python “won” the scripting language war over Ruby, more or less just because someone did a bit of AI work in it first and it took over that space by default. This is just my personal opinion with no data to back it up, but I suspect that Python "won" because it has excellent Windows support, while Ruby doesn't. Even a decade ago, Python's website offered an official native Windows installer [0], while Ruby's website [1] still points you to a third-party installer, which doesn't even have native support since it uses MSYS2 [2]. Most non-developers use Windows, so if you're choosing the first language to teach a large group of people, good Windows support is fairly important. Python being the "default" introductory language gave it a huge number of users, then I suspect that everything flowed down from there. [0]: https://web.archive.org/web/20160824235759/https://www.python.org/ https://web.archive.org/web/20160824235759/https://www.pytho... [1]: https://www.ruby-lang.org/en/downloads/ https://www.ruby-lang.org/en/downloads/ [2]: https://rubyinstaller.org/ https://rubyinstaller.org/
  • Izkata 2mo ago
    > but I suspect that Python "won" because it has excellent Windows support, while Ruby doesn't. Even a decade ago, Python's website offered an official native Windows installer I think you might be able to go an additional decade backwards. Back in college most of my friends were on windows and one of them was using python for class projects.
    • gucci-on-fleek 2mo ago
      > I think you might be able to go an additional decade backwards Yeah, Python has had good Windows support at least 15 [0] or 25 years [1], depending on how you count it. > Back in college most of my friends were on windows and one of them was using python for class projects. Well it's always been possible to install Ruby on Windows too, it's just that Python supports it so much better. [0]: https://peps.python.org/pep-0397/ https://peps.python.org/pep-0397/ [1]: https://peps.python.org/pep-0277/ https://peps.python.org/pep-0277/
  • frollogaston 2mo ago
    This could be it. The classic student with a Windows laptop and git-bash installed, where they think git and bash are the same thing, also PuTTY. I also wonder how many people gave up on Python just because the installer doesn't put it in your PATH. You'd install Python then no python, wtf. Ok so https://discuss.python.org/t/python-command-not-found/22255 https://discuss.python.org/t/python-command-not-found/22255 ... Then you fix it and it runs the wrong version of Python.
• Daishiman 2mo ago
  How is a language that has different semantics for referring to lambdas vs other functions consistent? Ruby's most important error is that it does not support namespaces. This by itself makes it a far less scalable language than Python.
  • hetman 2mo ago
    Did you mean to say that Ruby doesn't link name spaces to file system paths? Ruby has namespaces and they're far more flexible than Python's... too flexible in my opinion, making it harder to find things.
    • Daishiman 2mo ago
      Ruby namespaces force requiring everything and don't allow for relative imports among other features that are very important for larger software.
• hetman 2mo ago
  Ruby is beautiful in its design, but it made imports and namespaces (a.k.a. modules) separate concepts. This is so flexible it became hard to ever find anything easily in practice. Likewise, it made classes incredibly easy to extend, which led to a monkey patching bonanza and far too much magic everywhere (Rails being by far the worst offender but not the only one). It meant having to keep too much stuff in your head and needing deep framework/library familiarity just to be able to understand basic code. In the end, I feel like the incredible flexibility was Ruby's undoing, not just lack of library availability for a specific popular application. I was a Ruby zealot at one point but it began to lose its lustre not because it wasn't beautiful in theory, but because it was inconvenient in practice. In some ways, Python's restrictiveness became its greatest attribute. Then Python 3 helped to fix a lot of the inconsistency. Both Python and Ruby have a consistent logic to them, just not consistent with each other. Just as all attributes are methods in Ruby, so all methods area attributes in Python, etc. Things get much easier in either language if you stop fighting their internal logic.