11 ms·

This blog post assumes Python is more productive than other languages. People like to make this claim about not only Python, but many other dynamic programming

by brabel 5y ago

This blog post assumes Python is more productive than other languages. People like to make this claim about not only Python, but many other dynamic programming languages, specially Ruby, PHP and Lisp... but there's very little evidence to support that... programmers tend to be most productive in whatever language they know best. If they know both Python and Java equally well, I would bet they would be almost exactly as productive in either.

rambojazz 5y ago
Granted, people come from different backgrounds, and "the right tool for the right job" always applies. But it's undeniable that generally speaking, ie. not considering any specific cases or requirements, some languages are definitely more productive than others.
josephg 5y ago
I doubt it, though if anyone has data I’d love to see it. At the moment I’m quite comfortable in both javascript and rust. But I find javascript (/ typescript) noticeably more productive for small to medium projects. I can get more done with less work. For a variety of reasons it seems to take more work to write good rust code than good javascript code. This isn’t a knock on rust - I just think rust trades off programmer productivity for correctness and performance. And it shows, on both sides.
- KronisLV 5y ago
  > I doubt it, though if anyone has data I’d love to see it. I recall a study being quoted in my university courses, which described the amount of code needed to get certain things done between different languages, which showed that Python, Ruby and others are on the less verbose side, the reasoning being that on average they'd also be more productive. This seems to coincide with my personal experience, where JavaScript with React was much easier to work with in smaller projects, whereas using TypeScript with React lead to much slower development because of all the typing that needed to be handled, especially in cases of union types. Now, one can say that it's worth the effort to be more confident in your code doing what you want it to both now and after X months, much like you could sometimes prefer the type systems of Java or .NET over Python, Ruby or PHP, but in my eyes those tradeoffs always come with slower development velocity. The sad thing, however, is that DuckDuckGo (and possibly other search engines) failed to return the original study or anything like it, only resulting in low quality blog content: - https://duckduckgo.com/?t=ffab&q=programming+language+comparison+amount+of+code - https://duckduckgo.com/?q=programming+language+comparison+verbosity - https://duckduckgo.com/?q=programming+language+lines+of+code+java+ruby - http://libgen.is/scimag/?q=programming+language+verbosity - http://libgen.is/scimag/?q=programming+language+lines+of+code Anyone have any better search queries for this? Any idea why the search result quality is generally so low? Any ideas which study it might have been referencing?
  - brabel 5y ago
    The research on this topic has been discussed on HN multiple times. It is indeed hard to look up previous discussions, but the conclusion is always inconclusive... one thing everyone seems to agree nowadays is that measuring LOC is a bad proxy for programmer productivity, specially when you take code maintenance into consideration (which very few research papers do), and that types do have a small, but measurable effect on improving quality (though whether that's at the cost of productivity is still unclear as far as I know - yes, programmers need to spend a bit more time to declare their types, but without them they have to spend more time every time they need to call anything).
  - eesmith 5y ago
    Google Scholar is a better method to find published papers. The first result for "program language comparison", at least when I view https://scholar.google.com/scholar?q=programming+language+comparison https://scholar.google.com/scholar?q=programming+language+co... is: Prechelt, Lutz. "An empirical comparison of seven programming languages." Computer 33.10 (2000): 23-29. There's all sorts of work which cite that paper, like "An empirical investigation of the effects of type systems and code completion on api usability using typescript and javascript in ms visual studio". For fun, here are some of those citation which themselves use the phrase "An empirical study" or similar in the title: "An empirical study on the impact of static typing on software maintainability" "An empirical study of the influence of static type systems on the usability of undocumented software" "Do developers benefit from generic types? An empirical comparison of generic and raw types in Java" "An empirical study on C++ concurrency constructs" "An empirical study on the factors affecting software development productivity" "An empirical study to revisit productivity across different programming languages"
- smt88 5y ago
  > But I find javascript (/ typescript) noticeably more productive for small to medium projects. This seems like a pretty apples-to-oranges comparison. Rust is intended to do things you couldn't/wouldn't use JavaScript for. If you're talking about a small-to-medium project where you don't care much about mishandling memory, of course JavaScript is going to be more productive. Rust is forcing you to tell the compiler a lot of things that JavaScript assumes you don't care about (and is, most of the time, correct).
blooperdoop 5y ago
You’d bet wrong. Say I want to add two numbers and ship it to prod. In Python, that’s one line and an scp. In Java, that’s at least three, a compile step, and an scp. By definition I’m more productive in Python due to the language tradeoffs. That’s reducing to absurdity but the principle holds to a solution of any complexity, particularly in SRE/ops. This really rears its head when Go and Rust shops say “oh let’s do all our operational scripting in the same language, too.” It seems nice in theory but is a complete mess in operations. As an SRE manager, I have data to back up the assertion that a compile step gets directly in the way, particularly in an outage situation (we need to recompile the script with a flag to change it - and we are usually pushed toward CI/CD for that outcome). If you are asking this of your operations teams, they absolutely hate you regardless of their experience with the language. I have 21 years writing Java and three writing Python and I’ll reach for Python for “move files from directory to other directory based on heuristics” loooooong before I touch Java for the same purpose, and that’s a high bar to even get there beyond doing it in a shell. Reducing this discussion to familiarity with a language is a complete red herring and dismisses every argument the other side has with “if you were just better at Java this wouldn’t be an issue,” which is flat out wrong. Right tool, right job. I see I’m -2 before I’m finished editing typos which I think speaks to the article’s point about language ideology more than anything.
- Dobbs 5y ago
  > Say I want to add two numbers and ship it to prod. In Python, that’s one line and an scp. This example ignores what is actually involved in production code. Yes there is a compile step involved in things like Java. In python you have to manage your dependencies on the deployment box. In Java (minus the runtime), Go, Rust, etc they all support managing dependencies on the client side. In my experience the messiness of that in python and ruby far outstrips the complexities of a compile step in the makefile or CI pipeline.
  - blooperdoop 5y ago
    Correct. I reduced the comparison to absurdity and intentionally overlooked several concerns, and pointed that out, to note that binary yes/no is more nuanced here and that the alternative opinion can be built from first principles without invoking familiarity with a language. I apologize that I led you to respond to an absurd argument. I’ll try harder to note it as an absurd argument in the future - should I use a better word than absurdity?
rich_sasha 5y ago
I used to work at a C++ for prod, Python for prototype place. Time and time again, a 1-2kloc Python prototype, the bulk of which was written in a week, would take months to translate to C++, at times longer than the whole process of research+prototype. I think it was 2 things: one, it is genuinely harder to write a valid C++ program. The language imposes non-trivial constraints on the programmer, for better and worse, and you have to navigate them for the thing to even compile. But two, C++ invites pedantry. I heard endless discussions about "ooh, template meta-programming", "struct or class", "but is this idempotent", "you should be using move semantics", "why on earth is this a unique_ptr". I'm not saying C++ is worse, or that its trade-offs are not worth it, but for sure, from my experience, translating an algorithm into code is done far more quickly in Python than in C++. YMMV Ah and also, this was definitely not a question of deficient C++ coders. The hiring standards for C++ were so high we were always short of devs. Meanwhile, Python prototypes were usually written by part-time ex-academia Python dabblers.
- andai 5y ago
  There should be one-- and preferably only one --obvious way to do it. -PEP 20 -- The Zen of Python
  - uranusjr 5y ago
    Although that way may not be obvious at first unless you're Dutch. —The next line This ZoP line is by far the most misused cliché of all things Python. How is it determine that “prototyping in C++ and rewriting in C++” is not the obvious “one” way? Because you don’t like it? A Zen is intentionally self contradicting to allow introspection, not judge others :)
  - michaelcampbell 5y ago
    Hold my beer. -- Django
    - bierjunge 5y ago
      Amateurs. -- Perl
CJefferson 5y ago
I think different languages do have sweet-spots, and it often has to do with library availablity (for me at least). I consider myself as someone who knows "far too much about C++", but recently when I had to spider some webpages and read some values out of them to populate a database, I did that in Python because it's a handful of lines due to high quality libraries that all work nicely together. I honestly wouldn't know how to do that in a short amount of time in C++.
- brabel 5y ago
  I admit that Python is more productive than C++, but the reason is mostly to do with memory management... a language with a GC, like Java or JavaScript, would use a very similar level of abstraction as Python and therefore, should "cost" about the same to write. Python and other dynamic languages don't use static types and that may give them a (very) small advantage in productivity as well, but only for very small programs... as program size increases, in my experience, statically typed languages take the lead in productivity... as OP is about writing general software, not just small scripts, I really have a hard time agreeing that Python is either the best tool for the job, or the most productive tool at all.
  - WithinReason 5y ago
    It's more than that. For example, converting a string to uppercase in C++: #include <string> #include <cctype> #include <algorithm> #include <iostream> int main() { std::string s("hello"); std::transform(s.begin(), s.end(), s.begin(), [](unsigned char c) { return std::toupper(c); }); std::cout << s; } Same thing in Python: print('hello'.upper())
    - Hizonner 5y ago
      That takes advantage of the fact that Python puts a bunch of relatively obscure functionality in scope by default... thus increasing the chance that programs will use the wrong method or rely on stuff they don't really intend to. Case manipulation isn't something most modern programs should even be doing at all, since it's almost impossible to internationalize it. In fact it's really mostly name space management. Python doesn't require you to pull in "upper" because it starts with a relatively big name space. It doesn't require you declare the main program because you're relying on the fact that Python executes a file on loading it (and that reliance is arguably bad Python style). All of the "std::" stuff is a name space management choice. ... and the rest has nothing to do with static typing either. The way the code is indented on multiple lines is a stylistic convention. The transform primitive requiring you to specify bounds is a library choice, related to the language's apparent lack of a universal way to map over a container. I'm not sure why you need the lambda. The rewrite in place is memory model stuff inherited from C. In Haskell, which is fully compiled and is about the most rigid static typed language you could ever imagine: import Data.Char(toUpper) main = putStrLn (toUpper <$> "hello") If you'd asked for something that didn't require oddball functionality, then that could probably also have been a one-liner.
eesmith 5y ago
The classic, now quiet dated citation, is "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl" by Lutz Prechelt. Recent-ish commentary (July 2021) about it at https://renato.athaydes.com/posts/revisiting-prechelt-paper-comparing-languages.html https://renato.athaydes.com/posts/revisiting-prechelt-paper-... , HN commentary at https://news.ycombinator.com/item?id=28108806 https://news.ycombinator.com/item?id=28108806 . Google Scholar gives about 476 paper which cite Prechelt's work. I have not followed other work in that field.
- npsimons 5y ago
  Norvig had a response to Prechelt as well: http://www.norvig.com/java-lisp.html http://www.norvig.com/java-lisp.html
  - eesmith 5y ago
    Mentioned and used as the Lisp baseline in the link I gave. ;)
    - npsimons 5y ago
      > Mentioned and used as the Lisp baseline in the link I gave. ;) Just saw that, nice. I like Norvig because he really cuts to the chase.
tinco 5y ago
There's a great deal of evidence that supports that, it's just not scientifically organized. If you just look at the amount of high quality high polished projects out there for the dynamic programming languages it absolutely dwarfs those of static languages. And then add to that the fact that most of those are by solo devs in their free time. It's not just that they are more popular, Java reigned supreme for years when Ruby and PHP and later Node.js outpaced it's communities by miles. And you can't say Java developers are not open source oriented, because they 100% are. And the argument that programmers are simply most productive in the language they know best is trivially untrue. When I first learned of Ruby, I could dream in C#, I was absolutely fluent, knew the standard library by heart. I switched to Ruby and only looked back whenever I needed tight performance. And this is not just an anecdote, the whole Ruby on Rails movement was basically Java developers fleeing to greener pastures. I don't know a single highly experienced multi-lingual developer who does not reach for a dynamic language when they need to deliver something quick and easy. The only exception I know off is using Go for small networked services, which is quite comfortable and intuitive for a static language. Also outside that niche Go quickly loses its productivity edge.
- smt88 5y ago
  > I don't know a single highly experienced multi-lingual developer who does not reach for a dynamic language when they need to deliver something quick and easy. If you're picking from a popular language, the language itself rarely matters for this at all. Every popular language does roughly the same things. Writing speed (length of keywords, for example) is a non-issue. The ecosystem is by far the most important thing. It doesn't matter how efficient I am in Go if I'm missing a crucial library that I'll now have to write myself. JavaScript is a classic example where, even if you are pretty fast at writing your code, you will be dramatically slowed down by: 1) needing to add a new package every 5 min to do something trivial, 2) looking through five half-dead libraries to find one that seems maintained and usable, and 3) finding out that some of the libraries you chose are buggy. So for a quick prototype, I'd weight a language's qualities as follows: - ecosystem: 90% - static analysis/tooling: 5% - stdlib: 3% - syntax: 2% And for a long-term, complex project, I'd weight them closer to: - ecosystem: 50% - static analysis/tooling: 46% - stdlib: 3% - syntax: 1%
- 5y ago
nodejs_rulez_1 5y ago
Python, like all dynamic languages, works best to bash out a new project into production ASAP, get a bonus and move on, while poor folks maintaining after you are trying to untangle it.
- david38 5y ago
  Python’s “one right way to do it” is specifically designed to avoid this. This isn’t Perl.
  - Zababa 5y ago
    Current Python doesn't reflect this philosophy though. You have lots of options for strings and string formatting. There is pattern matching and if statements. The standard library often isn't the best option for stuff (like HTTP requests) so you use another library. Package management and deployment is far from solved, with lots of different tools.
    - dragonwriter 5y ago
      > You have lots of options for strings and string formatting. “Strings and string formatting” is a very broad domain. For most specific tasks, there is one low-impedance approach and it takes very little (but not zero) reflection and/or experience to find it. Most new Python features directly address specific tasks for which there are currently multiple relatively high-impedance approaches taken because there is not one obviously correct way. Python's “one obviously correct way” is not “one possible way” (the latter approach is closer to Go.)
    - klyrs 5y ago
      Pet peeve: there is no right way to do type annotations. Two major projects aren't even compatible: https://www.cs.rpi.edu/~milanova/docs/dls2020.pdf https://www.cs.rpi.edu/~milanova/docs/dls2020.pdf
  - woah 5y ago
    Python has multiple different ways to do things even in the standard library lol
smt88 5y ago
> programmers tend to be most productive in whatever language they know best This is true, but most software is built by multiple people (for corporations) and will eventually be maintained by multiple other people. Whether an individual is "most productive" in a language is rarely important.
moksly 5y ago
I spent 7 years working with C#, I like C# and I think what they’ve done in the past few years is amazing. I’m much more productive in Python. Not as in “I feel” more productive, but as in measurably more productive. Where Python falls short of something like .Net and C# is that I probably wouldn’t have been more productive in Python if I didn’t have 7 years experience with a rather strict environment, and as far as using Python on major projects, well let’s just say that there is a reason people use TypeScript instead of JavaScript and Python doesn’t fall into that category. But for most programming and for most minor systems or services, Python is just wildly good.
- harpiaharpyja 5y ago
  I also spent many years working with C# before working with Python professionally. I've also spent a lot of time with Lua, though not for paid work. The second point matches my experience with dynamic languages as well. To use them well really takes a certain level of discipline, but it pays off. It's why I'm a bit skeptical of Python as a beginners language, which it sometimes has been touted as. About large projects, presently I am working with Python on a somewhat large project (currently 53k sloc, I guess large is relative). Its been great, though we are pretty strict about almost absolutely everything being type-hinted.
  - goohle 5y ago
    53k SLOC is tiny project. 5 senior developers at 1k SLOC per day will generate 53k SLOC in two weeks, just one sprint.
    - mynameisash 5y ago
      How many people are writing 1k SLOC/day? And doing so consistently? If you're banging out that much code, I'd be severely concerned for the quality of the code itself as well as overall design.
      - goohle 5y ago
        Senior developers (really seniors, not 3 year seniors) can trivially produce such amount of code, because they wrote almost same code dozen times already.
flohofwoe 5y ago
Sometimes you just want to throw entirely differently shaped data into the same array or dictionary and be done with it instead of creating a "proper" type-safe design which most likely means writing lots of pointless boilerplate code. IMHO that's the whole point of a scripting language like Python, to write quick'n'dirty scripts, not "real programs".
taylodl 5y ago
I've been programming for nearly 40 years now and I've used all the popular languages in that time (popular for microcomputers) and I've mastered a few. I just started Python for the first time last year. Am I a Python expert? No. But I can tell you right now I can get a project done faster in Python than using any language in which I'm an expert. It's that productive. Does that mean Python has all the performance you would ever need? No - we know it doesn't, but we also know that you rarely need that kind of performance and when you do it's usually localized to a very narrow portion of your code. Take that portion of code and implement in C and optimize to your heart's content. Even with that you'll still get your project done much faster. Python is the tool of choice for those developers who just want to get stuff done.
- lvass 5y ago
  I've used Python for 15 years and I'm far more productive with Clojure. Don't generalize.
  - alexeiz 5y ago
    I love Clojure. As with Python, Clojure comes with batteries included. It's dynamic typing and REPL makes development really quick and the JVM runtime allows to achieve better performance than Python in many cases. You can even go as far as compiling to native executable with GraalVM.
  - taylodl 5y ago
    I agree with you on Clojure, but I'm not going to be able to get my team to adopt Clojure - unless you're going to tell me how you convinced your team to adopt Clojure! :)
  - ubercore 5y ago
    Presenting a specific experience refuting an earlier generalization is reasonable here, I think.
    - shadowfox 5y ago
      I mean it is not just mentioning a specific experience to refute a generalization when there is also this: "Python is the tool of choice for those developers who just want to get stuff done."
deltaonefour 5y ago
I'm a C++ programmer and a python programmer. I assure you your conclusion is incorrect. Python with type checking is by far more productive. Many people who know python and another language can testify to this general truth.
- simiones 5y ago
  C++ is probably the least productive non-joke language ever created: it has deterministic destruction which requires (manual) ownership tracking, it has an extremely slow compiler with horrible error messages, it has massive performance differences between debug and optimized builds, it's focus on performance brings lots and lots of extraneous concepts to its libraries when just seeking to get something working (std::allocator, std::string_traits and many other similar examples). Comparing Python to Java, C#, Haskell, Erlang, Go, maybe even C or Rust, would show a much smaller performance difference.
  - shepardrtc 5y ago
    > requires (manual) ownership tracking Have you tried RAII? Would you like to know more? https://stackoverflow.com/questions/2321511/what-is-meant-by-resource-acquisition-is-initialization-raii https://stackoverflow.com/questions/2321511/what-is-meant-by...
    - simiones 5y ago
      RAII is exactly what I mean by "manual ownership tracking and deterministic destruction". RAII is better than completely manual memory management (C style malloc/free), but it still requires you to design your program such that every piece of memory is owned by some pointer with the correct properties. You have to choose between copying, bare pointers/references, unique_ptr and shared_ptr whenever two pieces of data are related to each other, or whenever you pass a piece of data to another function. Rust is a little better since at least the ownership concept is known to the compiler and automatically enforced. (Tracing/Copying/Compacting) GC is much easier since this entire concept goes away. You always pass references to data, and the physical storage is "owned" by the GC itself. It's also much faster for certain workflow patterns, though it always consumes more memory than deterministic destruction schemes.
npsimons 5y ago
> but there's very little evidence to support that Not if you don't go looking for it: http://www.norvig.com/java-lisp.html http://www.norvig.com/java-lisp.html ETA: And don't get me started on Design Patterns: https://norvig.com/design-patterns/design-patterns.pdf https://norvig.com/design-patterns/design-patterns.pdf

by brabel 5y ago

rambojazz 5y ago

Granted, people come from different backgrounds, and "the right tool for the right job" always applies. But it's undeniable that generally speaking, ie. not considering any specific cases or requirements, some languages are definitely more productive than others.

josephg 5y ago

I doubt it, though if anyone has data I’d love to see it. At the moment I’m quite comfortable in both javascript and rust. But I find javascript (/ typescript) noticeably more productive for small to medium projects. I can get more done with less work. For a variety of reasons it seems to take more work to write good rust code than good javascript code. This isn’t a knock on rust - I just think rust trades off programmer productivity for correctness and performance. And it shows, on both sides.

KronisLV 5y ago
> I doubt it, though if anyone has data I’d love to see it. I recall a study being quoted in my university courses, which described the amount of code needed to get certain things done between different languages, which showed that Python, Ruby and others are on the less verbose side, the reasoning being that on average they'd also be more productive. This seems to coincide with my personal experience, where JavaScript with React was much easier to work with in smaller projects, whereas using TypeScript with React lead to much slower development because of all the typing that needed to be handled, especially in cases of union types. Now, one can say that it's worth the effort to be more confident in your code doing what you want it to both now and after X months, much like you could sometimes prefer the type systems of Java or .NET over Python, Ruby or PHP, but in my eyes those tradeoffs always come with slower development velocity. The sad thing, however, is that DuckDuckGo (and possibly other search engines) failed to return the original study or anything like it, only resulting in low quality blog content: - https://duckduckgo.com/?t=ffab&q=programming+language+comparison+amount+of+code - https://duckduckgo.com/?q=programming+language+comparison+verbosity - https://duckduckgo.com/?q=programming+language+lines+of+code+java+ruby - http://libgen.is/scimag/?q=programming+language+verbosity - http://libgen.is/scimag/?q=programming+language+lines+of+code Anyone have any better search queries for this? Any idea why the search result quality is generally so low? Any ideas which study it might have been referencing?
- brabel 5y ago
  The research on this topic has been discussed on HN multiple times. It is indeed hard to look up previous discussions, but the conclusion is always inconclusive... one thing everyone seems to agree nowadays is that measuring LOC is a bad proxy for programmer productivity, specially when you take code maintenance into consideration (which very few research papers do), and that types do have a small, but measurable effect on improving quality (though whether that's at the cost of productivity is still unclear as far as I know - yes, programmers need to spend a bit more time to declare their types, but without them they have to spend more time every time they need to call anything).
- eesmith 5y ago
  Google Scholar is a better method to find published papers. The first result for "program language comparison", at least when I view https://scholar.google.com/scholar?q=programming+language+comparison https://scholar.google.com/scholar?q=programming+language+co... is: Prechelt, Lutz. "An empirical comparison of seven programming languages." Computer 33.10 (2000): 23-29. There's all sorts of work which cite that paper, like "An empirical investigation of the effects of type systems and code completion on api usability using typescript and javascript in ms visual studio". For fun, here are some of those citation which themselves use the phrase "An empirical study" or similar in the title: "An empirical study on the impact of static typing on software maintainability" "An empirical study of the influence of static type systems on the usability of undocumented software" "Do developers benefit from generic types? An empirical comparison of generic and raw types in Java" "An empirical study on C++ concurrency constructs" "An empirical study on the factors affecting software development productivity" "An empirical study to revisit productivity across different programming languages"
smt88 5y ago
> But I find javascript (/ typescript) noticeably more productive for small to medium projects. This seems like a pretty apples-to-oranges comparison. Rust is intended to do things you couldn't/wouldn't use JavaScript for. If you're talking about a small-to-medium project where you don't care much about mishandling memory, of course JavaScript is going to be more productive. Rust is forcing you to tell the compiler a lot of things that JavaScript assumes you don't care about (and is, most of the time, correct).

blooperdoop 5y ago

You’d bet wrong. Say I want to add two numbers and ship it to prod. In Python, that’s one line and an scp. In Java, that’s at least three, a compile step, and an scp. By definition I’m more productive in Python due to the language tradeoffs. That’s reducing to absurdity but the principle holds to a solution of any complexity, particularly in SRE/ops. This really rears its head when Go and Rust shops say “oh let’s do all our operational scripting in the same language, too.” It seems nice in theory but is a complete mess in operations. As an SRE manager, I have data to back up the assertion that a compile step gets directly in the way, particularly in an outage situation (we need to recompile the script with a flag to change it - and we are usually pushed toward CI/CD for that outcome). If you are asking this of your operations teams, they absolutely hate you regardless of their experience with the language. I have 21 years writing Java and three writing Python and I’ll reach for Python for “move files from directory to other directory based on heuristics” loooooong before I touch Java for the same purpose, and that’s a high bar to even get there beyond doing it in a shell. Reducing this discussion to familiarity with a language is a complete red herring and dismisses every argument the other side has with “if you were just better at Java this wouldn’t be an issue,” which is flat out wrong. Right tool, right job. I see I’m -2 before I’m finished editing typos which I think speaks to the article’s point about language ideology more than anything.

Dobbs 5y ago
> Say I want to add two numbers and ship it to prod. In Python, that’s one line and an scp. This example ignores what is actually involved in production code. Yes there is a compile step involved in things like Java. In python you have to manage your dependencies on the deployment box. In Java (minus the runtime), Go, Rust, etc they all support managing dependencies on the client side. In my experience the messiness of that in python and ruby far outstrips the complexities of a compile step in the makefile or CI pipeline.
- blooperdoop 5y ago
  Correct. I reduced the comparison to absurdity and intentionally overlooked several concerns, and pointed that out, to note that binary yes/no is more nuanced here and that the alternative opinion can be built from first principles without invoking familiarity with a language. I apologize that I led you to respond to an absurd argument. I’ll try harder to note it as an absurd argument in the future - should I use a better word than absurdity?

rich_sasha 5y ago

I used to work at a C++ for prod, Python for prototype place. Time and time again, a 1-2kloc Python prototype, the bulk of which was written in a week, would take months to translate to C++, at times longer than the whole process of research+prototype. I think it was 2 things: one, it is genuinely harder to write a valid C++ program. The language imposes non-trivial constraints on the programmer, for better and worse, and you have to navigate them for the thing to even compile. But two, C++ invites pedantry. I heard endless discussions about "ooh, template meta-programming", "struct or class", "but is this idempotent", "you should be using move semantics", "why on earth is this a unique_ptr". I'm not saying C++ is worse, or that its trade-offs are not worth it, but for sure, from my experience, translating an algorithm into code is done far more quickly in Python than in C++. YMMV Ah and also, this was definitely not a question of deficient C++ coders. The hiring standards for C++ were so high we were always short of devs. Meanwhile, Python prototypes were usually written by part-time ex-academia Python dabblers.

andai 5y ago
There should be one-- and preferably only one --obvious way to do it. -PEP 20 -- The Zen of Python
- uranusjr 5y ago
  Although that way may not be obvious at first unless you're Dutch. —The next line This ZoP line is by far the most misused cliché of all things Python. How is it determine that “prototyping in C++ and rewriting in C++” is not the obvious “one” way? Because you don’t like it? A Zen is intentionally self contradicting to allow introspection, not judge others :)
- michaelcampbell 5y ago
  Hold my beer. -- Django
  - bierjunge 5y ago
    Amateurs. -- Perl

CJefferson 5y ago

I think different languages do have sweet-spots, and it often has to do with library availablity (for me at least). I consider myself as someone who knows "far too much about C++", but recently when I had to spider some webpages and read some values out of them to populate a database, I did that in Python because it's a handful of lines due to high quality libraries that all work nicely together. I honestly wouldn't know how to do that in a short amount of time in C++.

brabel 5y ago
I admit that Python is more productive than C++, but the reason is mostly to do with memory management... a language with a GC, like Java or JavaScript, would use a very similar level of abstraction as Python and therefore, should "cost" about the same to write. Python and other dynamic languages don't use static types and that may give them a (very) small advantage in productivity as well, but only for very small programs... as program size increases, in my experience, statically typed languages take the lead in productivity... as OP is about writing general software, not just small scripts, I really have a hard time agreeing that Python is either the best tool for the job, or the most productive tool at all.
- WithinReason 5y ago
  It's more than that. For example, converting a string to uppercase in C++: #include <string> #include <cctype> #include <algorithm> #include <iostream> int main() { std::string s("hello"); std::transform(s.begin(), s.end(), s.begin(), [](unsigned char c) { return std::toupper(c); }); std::cout << s; } Same thing in Python: print('hello'.upper())
  - Hizonner 5y ago
    That takes advantage of the fact that Python puts a bunch of relatively obscure functionality in scope by default... thus increasing the chance that programs will use the wrong method or rely on stuff they don't really intend to. Case manipulation isn't something most modern programs should even be doing at all, since it's almost impossible to internationalize it. In fact it's really mostly name space management. Python doesn't require you to pull in "upper" because it starts with a relatively big name space. It doesn't require you declare the main program because you're relying on the fact that Python executes a file on loading it (and that reliance is arguably bad Python style). All of the "std::" stuff is a name space management choice. ... and the rest has nothing to do with static typing either. The way the code is indented on multiple lines is a stylistic convention. The transform primitive requiring you to specify bounds is a library choice, related to the language's apparent lack of a universal way to map over a container. I'm not sure why you need the lambda. The rewrite in place is memory model stuff inherited from C. In Haskell, which is fully compiled and is about the most rigid static typed language you could ever imagine: import Data.Char(toUpper) main = putStrLn (toUpper <$> "hello") If you'd asked for something that didn't require oddball functionality, then that could probably also have been a one-liner.

eesmith 5y ago

The classic, now quiet dated citation, is "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl" by Lutz Prechelt. Recent-ish commentary (July 2021) about it at https://renato.athaydes.com/posts/revisiting-prechelt-paper-comparing-languages.html https://renato.athaydes.com/posts/revisiting-prechelt-paper-... , HN commentary at https://news.ycombinator.com/item?id=28108806 https://news.ycombinator.com/item?id=28108806 . Google Scholar gives about 476 paper which cite Prechelt's work. I have not followed other work in that field.

npsimons 5y ago
Norvig had a response to Prechelt as well: http://www.norvig.com/java-lisp.html http://www.norvig.com/java-lisp.html
- eesmith 5y ago
  Mentioned and used as the Lisp baseline in the link I gave. ;)
  - npsimons 5y ago
    > Mentioned and used as the Lisp baseline in the link I gave. ;) Just saw that, nice. I like Norvig because he really cuts to the chase.

tinco 5y ago

There's a great deal of evidence that supports that, it's just not scientifically organized. If you just look at the amount of high quality high polished projects out there for the dynamic programming languages it absolutely dwarfs those of static languages. And then add to that the fact that most of those are by solo devs in their free time. It's not just that they are more popular, Java reigned supreme for years when Ruby and PHP and later Node.js outpaced it's communities by miles. And you can't say Java developers are not open source oriented, because they 100% are. And the argument that programmers are simply most productive in the language they know best is trivially untrue. When I first learned of Ruby, I could dream in C#, I was absolutely fluent, knew the standard library by heart. I switched to Ruby and only looked back whenever I needed tight performance. And this is not just an anecdote, the whole Ruby on Rails movement was basically Java developers fleeing to greener pastures. I don't know a single highly experienced multi-lingual developer who does not reach for a dynamic language when they need to deliver something quick and easy. The only exception I know off is using Go for small networked services, which is quite comfortable and intuitive for a static language. Also outside that niche Go quickly loses its productivity edge.

smt88 5y ago
> I don't know a single highly experienced multi-lingual developer who does not reach for a dynamic language when they need to deliver something quick and easy. If you're picking from a popular language, the language itself rarely matters for this at all. Every popular language does roughly the same things. Writing speed (length of keywords, for example) is a non-issue. The ecosystem is by far the most important thing. It doesn't matter how efficient I am in Go if I'm missing a crucial library that I'll now have to write myself. JavaScript is a classic example where, even if you are pretty fast at writing your code, you will be dramatically slowed down by: 1) needing to add a new package every 5 min to do something trivial, 2) looking through five half-dead libraries to find one that seems maintained and usable, and 3) finding out that some of the libraries you chose are buggy. So for a quick prototype, I'd weight a language's qualities as follows: - ecosystem: 90% - static analysis/tooling: 5% - stdlib: 3% - syntax: 2% And for a long-term, complex project, I'd weight them closer to: - ecosystem: 50% - static analysis/tooling: 46% - stdlib: 3% - syntax: 1%
5y ago

nodejs_rulez_1 5y ago

Python, like all dynamic languages, works best to bash out a new project into production ASAP, get a bonus and move on, while poor folks maintaining after you are trying to untangle it.

david38 5y ago
Python’s “one right way to do it” is specifically designed to avoid this. This isn’t Perl.
- Zababa 5y ago
  Current Python doesn't reflect this philosophy though. You have lots of options for strings and string formatting. There is pattern matching and if statements. The standard library often isn't the best option for stuff (like HTTP requests) so you use another library. Package management and deployment is far from solved, with lots of different tools.
  - dragonwriter 5y ago
    > You have lots of options for strings and string formatting. “Strings and string formatting” is a very broad domain. For most specific tasks, there is one low-impedance approach and it takes very little (but not zero) reflection and/or experience to find it. Most new Python features directly address specific tasks for which there are currently multiple relatively high-impedance approaches taken because there is not one obviously correct way. Python's “one obviously correct way” is not “one possible way” (the latter approach is closer to Go.)
  - klyrs 5y ago
    Pet peeve: there is no right way to do type annotations. Two major projects aren't even compatible: https://www.cs.rpi.edu/~milanova/docs/dls2020.pdf https://www.cs.rpi.edu/~milanova/docs/dls2020.pdf
- woah 5y ago
  Python has multiple different ways to do things even in the standard library lol

smt88 5y ago

> programmers tend to be most productive in whatever language they know best This is true, but most software is built by multiple people (for corporations) and will eventually be maintained by multiple other people. Whether an individual is "most productive" in a language is rarely important.

moksly 5y ago

I spent 7 years working with C#, I like C# and I think what they’ve done in the past few years is amazing. I’m much more productive in Python. Not as in “I feel” more productive, but as in measurably more productive. Where Python falls short of something like .Net and C# is that I probably wouldn’t have been more productive in Python if I didn’t have 7 years experience with a rather strict environment, and as far as using Python on major projects, well let’s just say that there is a reason people use TypeScript instead of JavaScript and Python doesn’t fall into that category. But for most programming and for most minor systems or services, Python is just wildly good.

harpiaharpyja 5y ago
I also spent many years working with C# before working with Python professionally. I've also spent a lot of time with Lua, though not for paid work. The second point matches my experience with dynamic languages as well. To use them well really takes a certain level of discipline, but it pays off. It's why I'm a bit skeptical of Python as a beginners language, which it sometimes has been touted as. About large projects, presently I am working with Python on a somewhat large project (currently 53k sloc, I guess large is relative). Its been great, though we are pretty strict about almost absolutely everything being type-hinted.
- goohle 5y ago
  53k SLOC is tiny project. 5 senior developers at 1k SLOC per day will generate 53k SLOC in two weeks, just one sprint.
  - mynameisash 5y ago
    How many people are writing 1k SLOC/day? And doing so consistently? If you're banging out that much code, I'd be severely concerned for the quality of the code itself as well as overall design.
    - goohle 5y ago
      Senior developers (really seniors, not 3 year seniors) can trivially produce such amount of code, because they wrote almost same code dozen times already.

flohofwoe 5y ago

Sometimes you just want to throw entirely differently shaped data into the same array or dictionary and be done with it instead of creating a "proper" type-safe design which most likely means writing lots of pointless boilerplate code. IMHO that's the whole point of a scripting language like Python, to write quick'n'dirty scripts, not "real programs".

taylodl 5y ago

I've been programming for nearly 40 years now and I've used all the popular languages in that time (popular for microcomputers) and I've mastered a few. I just started Python for the first time last year. Am I a Python expert? No. But I can tell you right now I can get a project done faster in Python than using any language in which I'm an expert. It's that productive. Does that mean Python has all the performance you would ever need? No - we know it doesn't, but we also know that you rarely need that kind of performance and when you do it's usually localized to a very narrow portion of your code. Take that portion of code and implement in C and optimize to your heart's content. Even with that you'll still get your project done much faster. Python is the tool of choice for those developers who just want to get stuff done.

lvass 5y ago
I've used Python for 15 years and I'm far more productive with Clojure. Don't generalize.
- alexeiz 5y ago
  I love Clojure. As with Python, Clojure comes with batteries included. It's dynamic typing and REPL makes development really quick and the JVM runtime allows to achieve better performance than Python in many cases. You can even go as far as compiling to native executable with GraalVM.
- taylodl 5y ago
  I agree with you on Clojure, but I'm not going to be able to get my team to adopt Clojure - unless you're going to tell me how you convinced your team to adopt Clojure! :)
- ubercore 5y ago
  Presenting a specific experience refuting an earlier generalization is reasonable here, I think.
  - shadowfox 5y ago
    I mean it is not just mentioning a specific experience to refute a generalization when there is also this: "Python is the tool of choice for those developers who just want to get stuff done."

deltaonefour 5y ago

I'm a C++ programmer and a python programmer. I assure you your conclusion is incorrect. Python with type checking is by far more productive. Many people who know python and another language can testify to this general truth.

simiones 5y ago
C++ is probably the least productive non-joke language ever created: it has deterministic destruction which requires (manual) ownership tracking, it has an extremely slow compiler with horrible error messages, it has massive performance differences between debug and optimized builds, it's focus on performance brings lots and lots of extraneous concepts to its libraries when just seeking to get something working (std::allocator, std::string_traits and many other similar examples). Comparing Python to Java, C#, Haskell, Erlang, Go, maybe even C or Rust, would show a much smaller performance difference.
- shepardrtc 5y ago
  > requires (manual) ownership tracking Have you tried RAII? Would you like to know more? https://stackoverflow.com/questions/2321511/what-is-meant-by-resource-acquisition-is-initialization-raii https://stackoverflow.com/questions/2321511/what-is-meant-by...
  - simiones 5y ago
    RAII is exactly what I mean by "manual ownership tracking and deterministic destruction". RAII is better than completely manual memory management (C style malloc/free), but it still requires you to design your program such that every piece of memory is owned by some pointer with the correct properties. You have to choose between copying, bare pointers/references, unique_ptr and shared_ptr whenever two pieces of data are related to each other, or whenever you pass a piece of data to another function. Rust is a little better since at least the ownership concept is known to the compiler and automatically enforced. (Tracing/Copying/Compacting) GC is much easier since this entire concept goes away. You always pass references to data, and the physical storage is "owned" by the GC itself. It's also much faster for certain workflow patterns, though it always consumes more memory than deterministic destruction schemes.

npsimons 5y ago

> but there's very little evidence to support that Not if you don't go looking for it: http://www.norvig.com/java-lisp.html http://www.norvig.com/java-lisp.html ETA: And don't get me started on Design Patterns: https://norvig.com/design-patterns/design-patterns.pdf https://norvig.com/design-patterns/design-patterns.pdf