Engineers are not fans of technologies
jerf.org
jerf.org
That said, engineers don't always get as much choice as they should either. Often there is pressure to pick a popular technology because it is popular, over a more 'boring' technology. There is no perfect choice, and it isn't always just a matter of the best technology fit.
I would put 'picking the right technology' up there with 'naming things' and 'off by one errors' for these reasons.
Later on, author goes and says "At the highest level, tool choice decisions are complicated." and "You can write something similar about any useful technology" - but that does not really work with the first half of the post being very simplistic and one-sided.
(Note this might work much better with some context. There are some projects where speed really matters, like high-performance message server, but there are no context-setting markers in this post, it is written in general tone)
The whole point is that if you read something like that and all you glean is "this guy doesn't like Python", rather than "I will take those results into consideration if and when appropriate", you stunt your own ability to learn new information.
It reminds me of the book The Scout Mindset.
For example, take the first two sentences:
> Pure Python is generally a slow language. Written for performance, it will often be around 40-50 times slower than C, and Python “written for performance” is Python that is very straightforward and does not use many of its features.
It gives correct fact ("pure python is generally slow language") and then talks about Python "written for performance". See the deception? Most readers on reading this sentence would assume that people write pure python for performance. That is simply not the case - high performance Python projects are never pure Python.
If author really thought that "tool choice decisions are complicated", they would have followed up with something like:
... Python project which deal with massive data sets do majority of their logic in C or C++. For example a math simulation which spends most of the time multiplying matrixes in BLAS/LAPACK would be almost as fast as C++ version. So will neural networks which wrap Python around C++ core, or a video processing app which does all the actual work via OpenCV library. But if your use case deals with many small objects (like if you are writing message server), then Python's overhead can be a really big problem.
but I don't see anything like this in the text. And this is why people call this text is "abrasive" and "one-sided" - because it is.
Yeah. It is. I think the first half of the blog post is deliberately not a "good" blog post - it is deliberately written as if by someone with an agenda to push. I don't think the author necessarily has that agenda, I think he's role-playing it, as a set-up to his real point.
Reread the whole second half and it is clear. "You can write something similar about any useful technology."
EDIT: I'm not saying the whole theatrical presentation was good persuasive writing, I'm just interpreting it.
...of python or of anything else.
Well, with the possible exception of bash, which is my go-to for those first few rounds of hacking, and which sometimes gets me into trouble when I stick with it too long, unless and of course it is obvious that something else is better suited.
(Like two years ago when I wrote a queue management orchestrator for our core security product using C because it HAD to be fast, and since I am stronger in C than Rust. I would have preferred Rust, for traits and safety, but I didn’t know it well enough and needed to get to 1.0 fast, so C it was.)
Anyway, my point is that while perhaps wordier than it needed to be, TFA is spot-on: don’t use your favourite tool unless it also happens to be a right tool for the job (and there are almost always more than one right tool).
Seems like something we should all know.