3 ms·

The mishandled Python 3 transition sure created a lot of pain (I experienced some of it, even though I only started with Python in 2016), but I never realized h

The mishandled Python 3 transition sure created a lot of pain (I experienced some of it, even though I only started with Python in 2016), but I never realized how much it hurt the language’s momentum. This must be one of the reasons why JavaScript is so popular today. JS benefits here from being run in browsers, which the author points out are fantastic at back compat, even as the dev culture surrounding the language doesn’t value it at all.

mvn9 6y ago
Also: functional programming feels better in JS than in Python. On the other hand, it's nicer to write for-loops in Python.
- BossingAround 6y ago
  I really love the array.map( e -> e.doStuff() ) syntax. You can do similar in Java and other JVM languages of course. Not sure whether you can do that in Python.
  - magnio 6y ago
    There is map in Python, but nowhere near as nice as in JavaScript IMO.
  - JimDabell 6y ago
    You can do that in most languages. But map() (in either language) has the semantics of applying a transformation to each item in a collection to produce a new collection, so you wouldn’t really want to use map() to call something like doStuff(). That's what normal loops and forEach() are for. If you aren’t transforming the collection into a new collection, map() is the wrong choice; you’re telling anybody reading it that you’re doing something that you aren’t. But assuming doStuff() just has a bad name and is actually transformational, then the most direct translation would be to use map() and a lambda: new_array = map(lambda e: e.doStuff(), array) However it’s more idiomatic to use a list comprehension: new_array = [e.doStuff() for e in array]
Animats 6y ago
I never realized how much it hurt the language’s momentum. Yes. The combination of a botched transition with a high arrogance level was hell. Here's something I wrote in 2015 after porting a medium-sized system from Python 2 to Python 3.[1] I listed a number of package problems encountered during the conversion. Ones that indicated those libraries weren't being used much in production. I discovered that the SQL connector broke if you loaded a database of tens of thousands of records, for example. And oh, did I get hate mail. You can see the comments below mine. That's what led me to Go. Go is a mediocre language. That's a strength when you just need to get something done. It comes with a set of libraries which are heavily used internally within Google. So, if you're doing something that is server-side for some web-related task, the libraries for that are probably both present and well-debugged. And they don't seem to be deprecated rapidly. I'm not using them for any Google-specific services, so I can't speak to that. [1] https://lists.archive.carbon60.com/python/python/1187081/?page=1;mh=-1; https://lists.archive.carbon60.com/python/python/1187081/?pa...
- physicles 6y ago
  Yeah I have the same thoughts about go, which I've been using every day for the last four years. It's super rare for an upgrade to break anything (has happened though). When it comes to running stuff in prod, boring is good.

mvn9 6y ago

Also: functional programming feels better in JS than in Python. On the other hand, it's nicer to write for-loops in Python.

BossingAround 6y ago
I really love the array.map( e -> e.doStuff() ) syntax. You can do similar in Java and other JVM languages of course. Not sure whether you can do that in Python.
- magnio 6y ago
  There is map in Python, but nowhere near as nice as in JavaScript IMO.
- JimDabell 6y ago
  You can do that in most languages. But map() (in either language) has the semantics of applying a transformation to each item in a collection to produce a new collection, so you wouldn’t really want to use map() to call something like doStuff(). That's what normal loops and forEach() are for. If you aren’t transforming the collection into a new collection, map() is the wrong choice; you’re telling anybody reading it that you’re doing something that you aren’t. But assuming doStuff() just has a bad name and is actually transformational, then the most direct translation would be to use map() and a lambda: new_array = map(lambda e: e.doStuff(), array) However it’s more idiomatic to use a list comprehension: new_array = [e.doStuff() for e in array]

Animats 6y ago

I never realized how much it hurt the language’s momentum. Yes. The combination of a botched transition with a high arrogance level was hell. Here's something I wrote in 2015 after porting a medium-sized system from Python 2 to Python 3.[1] I listed a number of package problems encountered during the conversion. Ones that indicated those libraries weren't being used much in production. I discovered that the SQL connector broke if you loaded a database of tens of thousands of records, for example. And oh, did I get hate mail. You can see the comments below mine. That's what led me to Go. Go is a mediocre language. That's a strength when you just need to get something done. It comes with a set of libraries which are heavily used internally within Google. So, if you're doing something that is server-side for some web-related task, the libraries for that are probably both present and well-debugged. And they don't seem to be deprecated rapidly. I'm not using them for any Google-specific services, so I can't speak to that. [1] https://lists.archive.carbon60.com/python/python/1187081/?page=1;mh=-1; https://lists.archive.carbon60.com/python/python/1187081/?pa...

physicles 6y ago
Yeah I have the same thoughts about go, which I've been using every day for the last four years. It's super rare for an upgrade to break anything (has happened though). When it comes to running stuff in prod, boring is good.