3 ms·

Selecting a programming language can be a form of premature optimization

PaulHoule 5y ago
Almost all of my side projects and volunteer work involves Python. My work revolves around two other languages: Javascript on the front end, and Java on the back end. The thought of writing GUI code in Python makes me wretch -- and it's not for lack of trying. Similarly, threads "just work" in Java and it is possible to build up big configuration structures in RAM that support every request. Call me crazy, but I like writing compilers and stuff like that in Java, particularly in JDK 17 where you have pattern matching, data classes, sealed classes, etc. I write C for Arduino. Half of me wishes I was writing AVR8 assembler, the other half knows better, because the only way I am going to get a better board is switch to some architecturer (or hmmm... burn an AVR8 on an FPGA and make the FPGA do the hard work, but talk about getting thrown in the Briar patch) My N+2 side project involves a crossover between video games and reality and I'm dreading that I'll get sucked into C++. Like Java, Erlang/Elixir was written by adults and fixes most of the deficiencies of Python, but it doesn't have the comfortable ecosystem Python has.
pkolaczk 5y ago
That blog post is based on a silent assumption that software development cost is somehow lower for Python than for other "faster" languages. This is not what I observe in practice. I was not more productive in Python than I was in Rust, despite having similar amount of experience in both. Python is optimized for easy learning, but not for actual productivity and long term maintenance. Lack of static type system makes it hard to safely refactor code and forces one to write crazy amount of tests for even trivial things. Keeping 100% coverage in a huge project is simply expensive and impractical. And even with a high number of tests you'll be running in stupid errors of "who put a None in that field?" kind occasionally and that could be a larger slowdown than Rust lifetime checker complaints ;) I think Python could be a win only if you already have a library that solves your problem available only in Python and you're just gluing things together (so just a better bash) or if you target extremely low/cheap-end of quality (hiring undergrads, being ok with crashes on prod, etc).

Almost all of my side projects and volunteer work involves Python. My work revolves around two other languages: Javascript on the front end, and Java on the back end. The thought of writing GUI code in Python makes me wretch -- and it's not for lack of trying. Similarly, threads "just work" in Java and it is possible to build up big configuration structures in RAM that support every request. Call me crazy, but I like writing compilers and stuff like that in Java, particularly in JDK 17 where you have pattern matching, data classes, sealed classes, etc. I write C for Arduino. Half of me wishes I was writing AVR8 assembler, the other half knows better, because the only way I am going to get a better board is switch to some architecturer (or hmmm... burn an AVR8 on an FPGA and make the FPGA do the hard work, but talk about getting thrown in the Briar patch) My N+2 side project involves a crossover between video games and reality and I'm dreading that I'll get sucked into C++. Like Java, Erlang/Elixir was written by adults and fixes most of the deficiencies of Python, but it doesn't have the comfortable ecosystem Python has.

pkolaczk 5y ago

That blog post is based on a silent assumption that software development cost is somehow lower for Python than for other "faster" languages. This is not what I observe in practice. I was not more productive in Python than I was in Rust, despite having similar amount of experience in both. Python is optimized for easy learning, but not for actual productivity and long term maintenance. Lack of static type system makes it hard to safely refactor code and forces one to write crazy amount of tests for even trivial things. Keeping 100% coverage in a huge project is simply expensive and impractical. And even with a high number of tests you'll be running in stupid errors of "who put a None in that field?" kind occasionally and that could be a larger slowdown than Rust lifetime checker complaints ;) I think Python could be a win only if you already have a library that solves your problem available only in Python and you're just gluing things together (so just a better bash) or if you target extremely low/cheap-end of quality (hiring undergrads, being ok with crashes on prod, etc).