Live data from Hacker News

Ask HN: Is Python dying?

news.ycombinator.com

271–280 of 369 posts

Re: Ask HN: Is Python dying?

#271
post #5

That may be a view through the distorted HN lenses. Spend some time on Lambda the Ultimate and you'll think imperative programming is dying. Go is new and has lots of issues. It's annoying on many fronts and badly needs improvements in packaging area. It's good for some things and worse for others. JS is for frontend, because it's the only supported language. (although there are python-to-js compilers available if yo…

My prediction is that one day some alternative Python interpreter (Stackless, or GIL-less, or which compiles ahead of time to machine code, or something like that) will go from being merely an interesting concept to a dominant runtime. Python is such an excellent language, and it only has a small handful of elements holding it back from being even better. I feel like eventually something has to give, and either there…

MicroPython is already pretty much there on some fronts.

Re: Ask HN: Is Python dying?

#272

Earlier quoted context omitted.

My prediction is that one day some alternative Python interpreter (Stackless, or GIL-less, or which compiles ahead of time to machine code, or something like that) will go from being merely an interesting concept to a dominant runtime. Python is such an excellent language, and it only has a small handful of elements holding it back from being even better. I feel like eventually something has to give, and either there…

Object-oriented languages are Dead Men Walking due to the problem of global mutable state management in any medium- to large-sized codebase, coupled with dependency/inheritance hell, leading to complexity hell, leading to geometric progression of tech debt. Compounding this is the lack of good unit test suites across the board, meaning that even if you write absolutely perfectly tested and maintainable Python (or Rub…

Yeah they will still probably be labeled as dead man walking for the next 20 years long after your FP langue de jour will have outlasted it's pristine days and got damned to hell by the devs having to maintain the programs written in it. Don't get me wrong if you are currently doing consultancy business for a niche FP language far for me to blow the wistle to companies that instead of paying your fees and hefty salary for that rare programer(who might be me) who would have dabbled in your obscure language they would be better of paying 10$ a month and get 2 more DigitalOcean instances to support the rise in traffic your non sharable state code is solving.

Re: Ask HN: Is Python dying?

#273
post #262

Earlier quoted context omitted.

Object-oriented languages are Dead Men Walking due to the problem of global mutable state management in any medium- to large-sized codebase, coupled with dependency/inheritance hell, leading to complexity hell, leading to geometric progression of tech debt. Compounding this is the lack of good unit test suites across the board, meaning that even if you write absolutely perfectly tested and maintainable Python (or Rub…

You mean all those FP languages that happen to support OOP as well? Lisp, Clojure - CLOS OCaml - The O is for Objective, e.g. Objects Scala, F# - Hybrid FP/OOP Haskell - Type classes support polymorphism and extensibility. Erlang - Message passing as envisioned by Smalltalk So what are FP languages that have zero support for OOP concepts and are on the rise?

To be pedantic, Clojure has nothing to do with CLOS. It does leverage JVM and lets you use objects and OOP patterns though.

Re: Ask HN: Is Python dying?

#274
post #262

Earlier quoted context omitted.

You mean all those FP languages that happen to support OOP as well? Lisp, Clojure - CLOS OCaml - The O is for Objective, e.g. Objects Scala, F# - Hybrid FP/OOP Haskell - Type classes support polymorphism and extensibility. Erlang - Message passing as envisioned by Smalltalk So what are FP languages that have zero support for OOP concepts and are on the rise?

To be pedantic, Clojure has nothing to do with CLOS. It does leverage JVM and lets you use objects and OOP patterns though.

So where do you think multi-methods and protocols come from?

Re: Ask HN: Is Python dying?

#275
post #19

Interesting stats regarding version 2/3 usage from a moderator of /r/python today: Here's the breakdown by which Pythons were used to download from PyPI in the last two weeks: 2.7 85.90% 2.6 6.66% 3.4 4.64% 3.5 2.09% 3.3 0.56% 3.2 0.12% (Two weeks was ~133 million downloads) https://www.reddit.com/r/Python/comments/45sm94/what_are_the...

I'm disinclined to use it, partly because it shows a community that's slow to evolve, but mostly because the Python project decided that 2.7 was the last 2.x.

You're contradicting yourself.

Re: Ask HN: Is Python dying?

#277
post #237
post #227

Earlier quoted context omitted.

Not sure why you're getting downvotes. The 2 vs 3 has already split part of Python's userbase. Another change that broke significant amounts of code would just make things even worse.

I'm not sure that's true. My objection to 3 was it did nothing for me. All I got out of it was work dumped in my lap just so my code would continue running. Giving us a GIL-less pypy with jvm-scale performance would be worth a lot of hassle.

> My objection to 3 was it did nothing for me...Giving us a GIL-less pypy with jvm-scale performance would be worth a lot of hassle.

worth a lot of hassle to you. I imagine there are people who wouldn't find it worth the hassle. e.g. people who use python as a glue language where it's not close to being near the performance bottleneck - breaking the language to make it 'faster' would do nothing for them.

Re: Ask HN: Is Python dying?

#278

Earlier quoted context omitted.

I wouldn't say Python is dominant in startups across the board. Though it is strong in data-heavy environments (with all it's issues nonetheless). I've been a Pythonista for over a decade, and the API scene isn't quite as utopian as you describe. Date/time handling in particular is a really poorly handled area, but there's quite a few out there. That said, in general I agree the 'batteries included' approach is good,…

> Date/time handling in particular is a really poorly handled area Just use Arrow http://crsmithdev.com/arrow/ everywhere, all the time(s). Now your date/time problems are solved.

Couldn't agree more. Developing for the last couple of years code that is highly sensitive to dates and time, and Arrow saved my life.

Re: Ask HN: Is Python dying?

#279
post #262

Earlier quoted context omitted.

Object-oriented languages are Dead Men Walking due to the problem of global mutable state management in any medium- to large-sized codebase, coupled with dependency/inheritance hell, leading to complexity hell, leading to geometric progression of tech debt. Compounding this is the lack of good unit test suites across the board, meaning that even if you write absolutely perfectly tested and maintainable Python (or Rub…

You mean all those FP languages that happen to support OOP as well? Lisp, Clojure - CLOS OCaml - The O is for Objective, e.g. Objects Scala, F# - Hybrid FP/OOP Haskell - Type classes support polymorphism and extensibility. Erlang - Message passing as envisioned by Smalltalk So what are FP languages that have zero support for OOP concepts and are on the rise?

>Haskell - Type classes support polymorphism and extensibility.

While most of your examples are valid, I don't think Haskell is remotely object oriented. Type classes are not classes.

Re: Ask HN: Is Python dying?

#280
post #262

Earlier quoted context omitted.

You mean all those FP languages that happen to support OOP as well? Lisp, Clojure - CLOS OCaml - The O is for Objective, e.g. Objects Scala, F# - Hybrid FP/OOP Haskell - Type classes support polymorphism and extensibility. Erlang - Message passing as envisioned by Smalltalk So what are FP languages that have zero support for OOP concepts and are on the rise?

>Haskell - Type classes support polymorphism and extensibility. While most of your examples are valid, I don't think Haskell is remotely object oriented. Type classes are not classes.

Any Haskell coder knows that.

Quoting myself

> ... support polymorphism and extensibility.

OOP isn't only the C# and Java view of the world.

Post reply on HN