5 ms·

The idea that a certain programming language could be proven to be more productive than another is laughable. There are so many factors involved in that, I can

by vp8989 8y ago

The idea that a certain programming language could be proven to be more productive than another is laughable. There are so many factors involved in that, I can pretty much guarantee you it will never be studied to an acceptable level of rigor. The author presents some flimsy "study" about coding string processing algorithms with a straight face, and basically loses all credibility. What about lifetime productivity of a codebase? Speed of refactoring, onboarding, testing etc.. Why don't you just be honest and say you don't care Python is slow because you like using it? Performance doesn't matter? Of course it does. On the frontend, bad performance has been proven by many eCommerce companies to lead to lost business. On backend data pipelines, bad performance kills your flexibility. The longer it takes you to process N, the less times you can do it. The more times you can do it, the more times you can get it wrong. Also who says that time-to-market is everything? Tech history has shown that product quality/brand marketing win out in the long term. There are tons of forgotten shitty products that were first. Being first is over-rated.

reallydude 8y ago
> The idea that a certain programming language could be proven to be more productive than another is laughable. The idea that one chemical could be proven to be more effective than another is an equivalent problem. History, application, duration, there's a permutation of issues under that umbrella, as well. The problem is that nobody wants to argue about it very much. The Quorum project tried, to a small degree. > Why don't you just be honest and say you don't care Python is slow because you like using it? It's that and that you have an existing toolchain/codebase you don't want to rewrite in a potentially SLOWER way, because you don't know another language well enough. Python devs rather "solve real problems" than worry about a class of problems that their tool is inadequate for. There are always new trivial problems, where performance doesn't matter.
pjmlp 8y ago
Adlib and 3Dfx are two good examples how first to market doesn't mean success.
Someone 8y ago
”The idea that a certain programming language could be proven to be more productive than another is laughable.” I disagree. In the extreme, take python on the one hand and a variant of brainfuck that requires the hash (could be as simple as CRC-32 or as hard as SHA-256) of every source file to be zero on the other. I don’t think you have to go that far to get provable differences, though. Some features that, I think, can fairly easily be proven to make programmers more productive in large parts of the space of programming tasks: - assembler macros - variable names that can have more than two characters - direct support for floating point - support for complex numbers - local variables - structures - support for serialization and deserialization. Compare the way one can make simple structures serializable using Swift’s Codable protocol to whatever is ‘best’ for C (probably something macro-based) - generics - support for Unicode strings - iterators Of course, “python vs Java” or “python vs Perl” are much closer races where I expect measuring differences is way harder and results will depend on problem domain, experience of the subjects of the study, number of good and bad answers on StackOverflow, etc, but even for ‘normal’ languages, I expect some conclusions to be possible, given enough effort is spent. Python 1.0 didn’t have complex numbers, for example, so if your program needed them, python 1.4 was a huge improvement. I doubt evaluating productivity of languages is worthwhile, though.

by vp8989 8y ago

reallydude 8y ago

> The idea that a certain programming language could be proven to be more productive than another is laughable. The idea that one chemical could be proven to be more effective than another is an equivalent problem. History, application, duration, there's a permutation of issues under that umbrella, as well. The problem is that nobody wants to argue about it very much. The Quorum project tried, to a small degree. > Why don't you just be honest and say you don't care Python is slow because you like using it? It's that and that you have an existing toolchain/codebase you don't want to rewrite in a potentially SLOWER way, because you don't know another language well enough. Python devs rather "solve real problems" than worry about a class of problems that their tool is inadequate for. There are always new trivial problems, where performance doesn't matter.

pjmlp 8y ago

Adlib and 3Dfx are two good examples how first to market doesn't mean success.

Someone 8y ago

”The idea that a certain programming language could be proven to be more productive than another is laughable.” I disagree. In the extreme, take python on the one hand and a variant of brainfuck that requires the hash (could be as simple as CRC-32 or as hard as SHA-256) of every source file to be zero on the other. I don’t think you have to go that far to get provable differences, though. Some features that, I think, can fairly easily be proven to make programmers more productive in large parts of the space of programming tasks: - assembler macros - variable names that can have more than two characters - direct support for floating point - support for complex numbers - local variables - structures - support for serialization and deserialization. Compare the way one can make simple structures serializable using Swift’s Codable protocol to whatever is ‘best’ for C (probably something macro-based) - generics - support for Unicode strings - iterators Of course, “python vs Java” or “python vs Perl” are much closer races where I expect measuring differences is way harder and results will depend on problem domain, experience of the subjects of the study, number of good and bad answers on StackOverflow, etc, but even for ‘normal’ languages, I expect some conclusions to be possible, given enough effort is spent. Python 1.0 didn’t have complex numbers, for example, so if your program needed them, python 1.4 was a huge improvement. I doubt evaluating productivity of languages is worthwhile, though.