Python is awful. There are so many one offs in libraries, none agree on a style, it’s slow, and it’s way too easy to do the wrong thing. I often work with data scientists and have to productionize their jupyter notebooks which is pure suboptimal hell. I guess it must be a good easy learning curve for research/scratchpad
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.
Ruby has such a nice holistic consistency to it. With a few exceptions, it feels like it was conceived of by one person with a core idea in mind. Python feels like a mess.
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.
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.
> 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.
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 ... Then you fix it and it runs the wrong version of Python.
> 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.
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.
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.)
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.
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.
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.
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.
You don’t like working with data scientists. The data science Python ecosystem is really a separate beast that’ll have “normal” coders scratching their heads at the best of times, some of the most popular packages do all sorts of metaprogramming, and the standards for code quality are very different. Don’t blame the language. Well, blame it only in that it allows such things in the first place, which does have some very nice precipitations now and again, as well as some very bad ones.
In an age where people are still standing by C over memory-safe systems programming languages, I feel quite comfortable depending Python for the great many things that Python is good at.
The performance hell thing is also also kind of a virtue, though. The language is awful, so everything that does any amount of compute is FFI'd into third party libraries (numpy, torch, sympy, etc). Those libraries are for the most part pretty well designed... or, at least, keep you in a few pretty well-constrained patterns that are easy enough to translate.
If you've ever read through FORTRAN code from a mathematics department or MATLAB/C/C++ from (non-software) engineering disciplines, then you probably understand why productionizing a jupyter notebook is definitely not the worst of all possible worlds.
Python is a language for "consenting adults". It doesn't try to prevent you from doing awful things so you can do great things. People who can't program well are given plenty of rope to hang themselves. It shares that with Perl and Ruby.
That said, I find it the nicest, cleanest option of the three. I still wouldn't use it for large and complex projects. I really like it for stuff where one might otherwise use shellscript. It's way way better than shellscript... except if it's all about files and running external commands.
>language for "consenting adults". It doesn't try to prevent you from doing awful things so you can do great things. People who can't program well are given plenty of rope to hang themselves.
This is exactly what I remember being said about C (which I agree with) and often given as a reason why higher level languages like Python or Java have so many protections against things C/C++ allowed (memory management being the biggest one of course). Very funny, and I assume not coincidental, to read this about Python in the modern programming landscape.
Well, there are plenty of safety mechanisms that Python doesn't have and dangerous (usually powerful, occasionally badly designed) mechanisms that it does have.
When one writes jupyter notebooks for DS you are not writing python. If you ask 10 DSs explain to me what python's attribute lookup model is and why is it different from other OO languages like say Java or C++, they would not care about it. The only thing DSs care about is the rich DS Library support and fast speed of protoyping. To a DS using jupyter this is almost the same feedback loop as a type system at compile time.
Have you tried using `uv`'s newer tools? They help a lot e.g. with linting speed, lock management, package dependency separation, correct python version mgmt and no need to fudge with venv.
How is that a language problem? Data scientists are not engineers. No matter what language you give them, they will hand you something you are going to have to polish for production.
The fact that Python has become the language of choice for machine learning and data science is not a language issue.
I used to build quant investment notebooks that had to be deployed in production. Lots of problems with that. Mine were: Notebook cells run out of order, so you often have something that works in a session, but not in a fresh run. Developing against limited datasets, so you fail against things you didn’t know to test for. Small adaptions that have to be made every time the notebook is translated into a code file.
We streamlined it by making a graph-structured Computation a first class object that tracked staleness as code or data was updated. Then that class could be directly published, and when failures happened in production, the graph could be serialized with the inputs and intermediate calculation data that caused failure, for investigation in a notebook.
Relatively new, scripts can define dependency metadata now adays to achieve that to some degree. Any pip style versioning including an exact match works there.
The imports/packages situation is terrible in general. This was basically broken until uv, and uv is still not the default.
And it's weird how you import files. They're dot-separated packages that resemble file structure but not exactly. NodeJS has a self-explanatory require("./foo.js") or "../foo.js". The newer JS `import` syntax is annoyingly different from `require` but not terrible.
I've never become a fan of the language syntax, but otherwise I've become quite smitten with the total Python ecosystem. The Agents/LLMs + uv combo have made Python so useful and productive for me.
My CLI tools publish from Github to PyPI so that I can run tools with just `uvx sql-agent-cli` or `uvx dlna-here. Nothing for me to handle downloading (directly myself), no environment to manually setup, portable (Linux, Windows, Mac, ARM, x86). Easy for agents to run from a skill.md file without any other prereq than uv.
Really useful library ecosystem to leverage. No more shell scripts, or TS/JS/PHP backend services. I've even used Python on devices I've built around Raspberry Pi Zero 2 boards.
> I often work with data scientists and have to productionize their jupyter notebooks
I'm not a huge Python fan, despite working with it fulltime, but this feels like mixing correlation and causation. Data scientists would not be writing good, optimized code in any language.
Why wouldn't we? It's still a very relevant distinction, even if the terminology is a bit weird (since scripting is by definition programming). A programmer has very different needs when he writes a script to automate some server tasks versus a complex piece of software. It makes perfect sense that different tools will be more or less effective at meeting those different needs.
There is no reason why automating a server task cannot be a complex piece of software. I think you’re not aware of just what server automation is used for nowadays in countless cases. Also, Python is more popularly used in ML and web-development areas compared to server automation, so that would mean it’s not a scripting language by your logic.
Spoken like someone who hasn't tried to get data scientists to use other languages productively, where they'll be missing half the libraries, will have to triple their dependency count because you can't count on large common libraries and will have to dig to the ends of GitHub to find random functionality etc.
Python is amazing compared to writing bat/sh scripts. Different languages are for different purposes, using eg. Rust to write system scripts would just be mental. Whether people abuse those languages for purposes they were not intended for is another story, but that doesn't mean the language is inherently bad. And I mean,
> and it’s way too easy to do the wrong thing
is there another programming language where you believe a data scientist is going to have an easier time writing correct code than Python? Do you think C or Rust or JavaScript or C# make it harder to do the wrong thing?
C'mon man, I don't know any mid and above python developer who seriously has ever considered programming in Jupiter Notebooks. Python is not slow, it's you being the issue. If you are an amateur then it's easy to do the wrong thing, that's true.
