4 ms·

I agree with the sentiments of this post (you can't "just" add generics; there are serious trade-offs), but I think his assertion that Python is "on the wrong s

I agree with the sentiments of this post (you can't "just" add generics; there are serious trade-offs), but I think his assertion that Python is "on the wrong side of history" is untrue. More people are using Python now than ever before, in more and more problem domains. It's great for certain things, just not very good at concurrency (alleviated by async) and particularly parallelism (though in practice you can often work around it with C extension modules and multiprocessing). But to say Python has "missed the boat" and is "on the wrong side of history" is not true.

usuallybaffled 9y ago
The author was specifically talking about concurrency. You just repeated his point.
SideburnsOfDoom 9y ago
If my experience with c# is anything to go by, you can't "just" add async either. The details of how it works are very complex, the syntax requires a lot of noise words all over the code, and there are many ways to get it wrong. That's just a cost of retrofitting a paradigm-changing feature.
- dhd415 9y ago
  I would say, based on some experience with async capabilities in Python, Java, Go, and C#, that C#'s async/TPL implementation is among the more elegant. Its internals may be complex and it is not without some caveats that must be understood, but I find that it introduces the least amount of extraneous keywords and code constructs in the business logic of an application. And unlike some languages such as Java, C#'s async capabilities are well-supported throughout its core libraries. As someone who builds a lot of data processing applications in Java that benefit from both high concurrency and non-blocking IO, I find myself wishing Java's async capabilities were more like C#'s.
pdimitar 9y ago
Anecdotal evidence from the Pythonistas I've known in my career -- they stick to it because they like it, it's old (to them that means it's a proven tech) and because there's too much intertia in their organization to move on to something else. Technologies aren't only popular because of their quality, or shall we bring PHP once again to prove this point?
- kodablah 9y ago
  Yup, this is what I hate about all of the we-must-be-right-look-at-our-adoption-rate arguments. From the blog post: > There is a reason Go programmers choose to program in Go, and I believe that reason stems from our core tenets of simplicity and readability Not the reason I choose it, I choose it for tight cross platform binaries and nice stdlib. Arguments made against generics should be technical, not political... complexity may be subjective, but the justification for the definition can still be technical.
  - pdimitar 9y ago
    As I mentioned in my more lengthy comment right here -- https://news.ycombinator.com/item?id=14563597 https://news.ycombinator.com/item?id=14563597 -- popularity is very loosely correlated to the quality of the popular thing. There's ease to pick up, there are pressing business needs fixed by a creative junior Python dev, there's the businessmen loving quick solutions (and future be damned of course), there's inertia, there's skepticism ("but our current system is working! why switch?"), there are tens of other such phenomena that can be attributed to the very buggy automatic brain processes. So yeah, I hate the we-must-be-right-look-at-our-adoption-rate arguments as well. :)
- currymj 9y ago
  Anecdotally, it seems to me that it's increasingly common to see Python as the language of choice in greenfield projects. I've seen this in organizations -- scientific, academic, industrial -- that aren't primarily software-oriented. This involves both internal applications/utilities and general use for statistical analysis, machine learning, and data processing. It may be that choosing Python for a customer-facing web service would only be done now because of inertia or risk aversion, but there's tons of new users who don't care about the GIL and who like Python for its pleasant language design, good libraries, and ease of interfacing with C. PHP got popular because it was easy to use, and then because of inertia and path dependence. I don't think anyone was really happy to "grow with" PHP, in terms of gaining in expertise and creating increasingly complex code. I don't see this problem with Python -- leaving aside issues with concurrency, the language largely doesn't get in the way of writing quality code.

usuallybaffled 9y ago

The author was specifically talking about concurrency. You just repeated his point.

SideburnsOfDoom 9y ago

If my experience with c# is anything to go by, you can't "just" add async either. The details of how it works are very complex, the syntax requires a lot of noise words all over the code, and there are many ways to get it wrong. That's just a cost of retrofitting a paradigm-changing feature.

dhd415 9y ago
I would say, based on some experience with async capabilities in Python, Java, Go, and C#, that C#'s async/TPL implementation is among the more elegant. Its internals may be complex and it is not without some caveats that must be understood, but I find that it introduces the least amount of extraneous keywords and code constructs in the business logic of an application. And unlike some languages such as Java, C#'s async capabilities are well-supported throughout its core libraries. As someone who builds a lot of data processing applications in Java that benefit from both high concurrency and non-blocking IO, I find myself wishing Java's async capabilities were more like C#'s.

pdimitar 9y ago

Anecdotal evidence from the Pythonistas I've known in my career -- they stick to it because they like it, it's old (to them that means it's a proven tech) and because there's too much intertia in their organization to move on to something else. Technologies aren't only popular because of their quality, or shall we bring PHP once again to prove this point?

kodablah 9y ago
Yup, this is what I hate about all of the we-must-be-right-look-at-our-adoption-rate arguments. From the blog post: > There is a reason Go programmers choose to program in Go, and I believe that reason stems from our core tenets of simplicity and readability Not the reason I choose it, I choose it for tight cross platform binaries and nice stdlib. Arguments made against generics should be technical, not political... complexity may be subjective, but the justification for the definition can still be technical.
- pdimitar 9y ago
  As I mentioned in my more lengthy comment right here -- https://news.ycombinator.com/item?id=14563597 https://news.ycombinator.com/item?id=14563597 -- popularity is very loosely correlated to the quality of the popular thing. There's ease to pick up, there are pressing business needs fixed by a creative junior Python dev, there's the businessmen loving quick solutions (and future be damned of course), there's inertia, there's skepticism ("but our current system is working! why switch?"), there are tens of other such phenomena that can be attributed to the very buggy automatic brain processes. So yeah, I hate the we-must-be-right-look-at-our-adoption-rate arguments as well. :)
currymj 9y ago
Anecdotally, it seems to me that it's increasingly common to see Python as the language of choice in greenfield projects. I've seen this in organizations -- scientific, academic, industrial -- that aren't primarily software-oriented. This involves both internal applications/utilities and general use for statistical analysis, machine learning, and data processing. It may be that choosing Python for a customer-facing web service would only be done now because of inertia or risk aversion, but there's tons of new users who don't care about the GIL and who like Python for its pleasant language design, good libraries, and ease of interfacing with C. PHP got popular because it was easy to use, and then because of inertia and path dependence. I don't think anyone was really happy to "grow with" PHP, in terms of gaining in expertise and creating increasingly complex code. I don't see this problem with Python -- leaving aside issues with concurrency, the language largely doesn't get in the way of writing quality code.