Hacker News Reader

Comment by allendoerfer | Hacker News Reader

Python is not dying and if so, Go would not be the reason why. Sure, Python is not functional, not compiled, not mobile, not Rails and not in the browser.

But I can not imagine the languages, which are all this, to spread so nice and readable from command line scripts to scientific computing to big server applications.

Python's use cases will not go anywhere, so don't panic: Python is doing just fine and improving in many areas while holding on to its core values.

View on HN

> Python is not dying and if so, Go would not be the reason why

It is a death by multiple paper cuts. Go is just one of the cuts.

Besides Go (and others have mentioned so I am just repeating them). There is Node.js (Javascript), Rust, Dart, Clojure, Julia, C++11, Java (due to Python never making it far on Android). Not one is enough to eat Python's lunch as they say, but they all are taking a little nibble and soon enough Python stays hungry.

Another aspect is that there are multiple forms of deaths. It doesn't have to be an abrupt and dramatic death. But I am afraid it will eventually become like PERL. Still there, still usable, still jobs for it, but not many articles about it. Not much innovation. Not many new developers considering it as an option. It will just be a decline of sorts.

My personal view is also that once someone (or a team) seats down and thinks about cleaning up and doing a re-factoring, of their code, maybe in hopes to move to Python 3, they will be looking at other platforms, and languages as well.

You could as well say that Ruby is a one trick pony destined to have its lunch eaten by nodejs, or that Go can't stand the competition from Rust as a systems language. It's not easy to predict language evolution, and everything so far points towards python maintaining a healthy evolution rate and a quiet but dedicated user base.

I'd say python took the place that would today be Perl's, were it not for the whole Perl 6 fiasco, and that none of the supposed contenders actually vie for that exact spot,

I'd say people took Python over Perl because of readability, not because of the Perl 6 saga.

If you take the time to learn the language, it's quite readable.

I used to know a guy who'd freak out about not being able to read Perl. He couldn't write ("speak") it either, so I'm not sure what he was expecting.

I've met many developers who had never written Python or spent any time learning it, but still found it very readable.

I think many programmers (myself included), use more than one language at the same time. At the moment I use VB, python, flex and java, for different environments and different problems within those environments. If I want to quickly do something, for instance manipulating a CSV file, Python is my goto tool. And this is the reason Python will be popular for many because it can do certain things very fast and with minimum of fuss. Therefore I think Python will be around for awhile.

You can write pretty functional python, though. There are python compilers like Nuitka (I'm sure there is an llvm frontend somewhere...), mobile is kind of a pickle, yeah, I'd say Django is pretty rails but I always use bottle because I've never needed the kitchen sink before, and the reason its not in the browser is not pythons fault.

On that topic, I'd spend a day writing cobol or C++98 if I could get QML + Python in browsers. Python as a script/python, and QML as a uri schema (ie, http://foobar.com/baconwitch.qml)

You can use Ruby outside Rails, too, or Java outside of enterpricy applications. Last time i checked (few years ago) you could even use PHP for GTK desktop apps. You can write laggy mobile apps in pretty much every major language.

My point is: Most successful languages have their point, why you use them. They are successful, because of their focus on not because they try to beat every other language imaginable.

Python's use cases are already pretty diverse. So I have trouble to understand the constant fear Python could miss out on any platform or paradigm.

The main problem with functional programming in python is the bizarre neutered version of its lambdas. It really limits the expressiveness of using anonymous functions in python, as compared to, say, JavaScript. It's by far my biggest complaint with what is otherwise one of my favorite languages.

Since you can define a function inside a function, why does it matter that it isn't anonymous?

Having done a lot of python and JavaScript, all I can say is it does matter. It is an extra redirect as you try to find out what is happening as part of a callback (repeated over and over). It is also additional cognitive load as you now need to mentally parse the function's name (which you don't actually care about) and the function's purpose. Finally, it is more time consuming.

I really like coding in python, but the weak-sauce lambdas are on of my least favorite things about it. I would like tail call optimization, but living without it doesn't bother me on a daily basis. Lame lambdas do bother me on a daily basis.

Is tail optimization a language or an implementation issue? Couldn't that be implemented in the compiler without changing the language?

Don't try to fake anonymous functions in Python. Use its strengths: decorators, generators, etc.

Anonymous functions work well (err, passably) in JavaScript and Perl. They don't really work in Python, and of course you'll just run into pain if you try to force them to.

Perhaps also make some noise about this PEP: http://legacy.python.org/dev/peps/pep-0403/

Reply on news.ycombinator.com