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 will be a radical new official Python runtime, or an alternative one that becomes the de-facto standard (Pypy, Jython, Cython, Stackless, etc).

Or maybe that's just wishful thinking. I just want it to be so.

I totally agree with this. I think the Python community is becoming increasingly aware that this is the next major fix. I thinking 3-4 years before we see it, but we need to stay vigilant and make sure it happens.

A slightly leaner object model with a fast runtime would make it perfect.

Anything that breaks code AGAIN will kill the language for sure.

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.

the people using it for glue code really won't be upgrading their version anytime soon. My team uses python in production and we are still on 2.6

And you'd now have a 3-way split of resources (both learning materials and developers) between 2, 3 and (an imaginary) 4.

I completely agree. Fixing the run time would be a large effort to addressing one of the big complaints.

However I want to see packaging addressed as well, if not first.

Unfortunately packaging has gotten so wonky, it is easier for me to shove my small projects into huge docker containers and liberate my sysadmins from maintaining virtual environments on servers. Servers that need to be rebuilt with more modern versions of gcc and other system libs.

Interesting. What's the size / overhead of a Docker container? Not familiar with it, though know what it is, and that it is smaller than a complete VM.

It depends on the Linux distribution you use. Using Alpine Linux as a base can keep the overhead as low as a few megabytes.

Got it, thanks.

Have you tried nuitka or Conda?

It's unlikely unless someone with deep pockets steps up, such as a corporate benefactor. But it will continue to improve as it does every other year.

FATpython is starting to become some of this.

https://fosdem.org/2016/schedule/event/fat_python/

Yes, one reason for the success of Java was the huge amount of investment Sun put into it - in both marketing and tech improvements. I read that they spent millions on that. And it did result in benefits. Across the span of some years, anecdotally, the performance of Java apps improved a hell of a lot - I remember noticing it, say maybe from 1.2 to 1.6 or so. E.g. some servlet + JSP based app running a lot faster at the end of that period than at the beginning.

A pity that they did not seem to handle the business side of things well, and went down and were bought. (I'm sure there were external factors too, don't mean to say it was partly or wholly their fault. Just don't know.) Don't know much details on exactly why that happened, though I did read about it now and then, and follow Jonathan Schwartz's (last CEO of Sun) blog for a while.

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 Ruby, or Java, etc.) code, you still are stuck using libraries that have not been written with that in mind.

And yes, I'm talking broadly about the rise of FP.

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.

I don't think so, this time:

http://gamasutra.com/view/news/169296/Indepth_Functional_pro...

"My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible."

Well I don't think functional languages are something new and by reading the latest death and doom I'd wonder how we ever got this far and why suddenly it's so much harder to do concurrency. I confess that I don't write low level software for lunar modules but just the regular enterprise stuff and having worked with high level concurrent constructs like ConcurrentHashMap, LinkedBlockingQueue, RingBuffers on the jvm I've yet to experience the concurrency issues everyone is lamenting. I know it must be hard for the people developing the jvm to make those high level concurrency constructs available for me, but that is why I'm grateful for their work and "happy" that I can rely on them. I don't know maybe I've just been very lucky until now.

Most of the bugs I see in the wild are of the "runaway state" variety; in other words, a state the programmer(s) involved forgot to imagine might happen. This class of bugs includes EVERY bug or crash that is fixed by a restart of an app or system (because all that does is reset state to a "known" a.k.a. "modeled" state, bringing it back within the code's, i.e. programmer's understanding). Therefore, anything (whether it is a language, a methodology, or both) which mitigates or eliminates this class of bugs would be HUGELY valuable.

Functional paradigms/languages, and immutable values, and controlling side effects, greatly help with that, in my front-line coding experience. Therefore, I am a fan.

Do you enjoy doing needless extra work? In other words, are you a little bit lazy? (in the Larry Wall "laziness/impatience/hubris" sense). If so, you should be at least trying out functional paradigms and see if they work for you like they have for pretty much everyone else who has taken them on.

I'm going more pragmatic and I think most of the bugs were/ are NullPointerException the kind that today's IDE(due to their maturity of working for years and years with the language) can now even warn you about, compared to obscure ones that force you to do resets. On the other hand I don't see why the concepts of immutable values cannot be adopted in OOP languages. There is http://javaslang.com/ and immutable collections were long time present in Guava library. Sure immutability might not be enforceable in the language itself but you can do it. Java8 has streams for a functional approach to collections. Hell you can even use Akka if you cannot do without an actor framework in java.

But suggesting we need to start from scratch with new untested 3rd party libraries(that other people take for granted) and rewriting some of them. Even the simpler stuff like suffering the quirks of the extra tooling(build tools, IDEs) for a new language and all because of the death and doom we are supposedly seeing today(which I dont and I've yet to see people doing nightly restarts of web servers for some years). Unless you do consultancy for that language(or are seeking employment in a niche market) I think it's a little mad.

For me to declare the defeat of OOP and win of a FP language I first need to hear the voice of people having to do maintenance work on legacy code in that language as I'm too old to only believe there is such a thing as panaceea or there are only upsides to an alternative.

If you're working a problem capable of being solved by two $10/mo DO VMs, you're working a problem that can be solved in /any/ language.

I'm amazed by the number of people that declare the shared mutable state of the current languages as their bottleneck. You'd think everybody is suddenly working with realtime stream analysis on huge datasets and are battling millions of concurrent users these days.

My thinking is that if you are so popular you can afford maybe to start 20 more 5$ instances. And really I find it hard to think of problems that cannot be solved with 20 x 5$ DO VMs at least in Java.

Your comments are probably not intended to make anyone laugh but I'm enjoying them. But what you're saying is so true. I'd like to take it a bit further and add there's a reason while the implementation is slightly barbaric, Node.js continues to thrive. While I don't use Node, I have, and tend to think making things even more 'regressive' than say, Java, is the right way forward for most work.

Writing multi-pthreaded Java apps is not my idea of a good time. I am very interested in Elixir, but at the same time recognize that in reality I use Python. And if folks want to knock themselves out writing multithreaded Java apps... to go use Java.

I think the Node model for most, if not almost everything, fits needs well with its single-threaded event loop and scaling by process. Explicitly spinning up pthreads should be reserved for systems-programming, and in which case you are probably going to be using C(++)/Rust(?).

>You'd think everybody is suddenly working with realtime stream analysis on huge datasets and are battling millions of concurrent users these days.

I almost want to archive this somewhere or put it on a plaque next to my desk.

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?

Being a "hybrid FP/OOP" language is like taking a pure soup and allowing anyone to put a little bit of fecal matter in it and still thinking the product is "A-OK." ;)

Opinion aside, it's still true that some classes of algorithms are still too slow in FP and benefit from procedural mutation of state. But those should be managed very carefully as they destroy concurrency. I linked it elsewhere here but I think John Carmack's comments on this are quite lucid, and he is merely talking about using a functional style within OO languages: http://gamasutra.com/view/news/169296/Indepth_Functional_pro...

The thing is, 16-core CPU's are coming out soon, and we still have 99% of software that cannot take advantage of that well, at least within a single process.

One clarification

> Erlang - Message passing as envisioned by Smalltalk

Smalltalk, despite being called an "OO" language, did not come up with the gigantic class inheritance chains which have been attributed to OO.

>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.

Polymorphism and extensibility are features of OOP, but Haskell implements them in a rather different way to most OOP languages.

I realise people disagree about what exactly should be considered OOP, but personally I think not including inheritance in the definition broadens the term beyond usefulness.

There is no disagreement, Smalltalk is the object system. Object-orientation was invented in Smalltalk. Other languages and systems are just poor imitations.

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?

Okay, TIL, still there's more OOP in Clojure beyond CLOS influences.

Object oriented does not require state: it requires encapsulation. I incorporate as much immutability into my code as possible and I would say most of our objects never have their state changed from instantiation and I write Enterprise Java all day long.

Interesting that FP started from as long back as the time of John Backus (of Backus-Naur fame):

https://en.wikipedia.org/wiki/John_Backus

Not taking any sides in this beef, though, just an interested bystander.

This either or thinking is not very productive. FP existed before OOP, it's hardly reasonable to think it will replace it.

WeddeddSsx

I really want ZiPy to take off, a fast Python 3.5 for the JVM would be lovely.

You mean "ZipPy": https://bitbucket.org/ssllab/zippy.

MicroPython is already pretty much there on some fronts.

Would it be possible to port it to the erlang-vm?

The Async stuff, generators & yields surely. Maybe even yield from.

One obstacle is that Python code is often not recursive nor makes use of pattern matching.

So it all depends on what kind of Python you want to port.

Not a good fit. Too imperative/oo to fit into Erlang's functional world.

A subset may be.

Next year has always been the year that functional programming will take over the world. It's been like that since I started programming in the early 90s. While functional concepts have leaked into imperative languages, Haskell is the only pure functional language that so far has come close to breaking out although Lisp has also gotten close a few times.

(see also next year will be the year of Linux on Desktop)

Clojure and Scala have gotten close as well. I've seen Scala in use at scale at both universities and corporations. Clojure is being used in production by at least a few well known companies, too. Both have the primary benefit of being backed by the JVM.

Scala seems to have some momentum. I've wondered if the companies that have adopted it are using it like jvm haskell or a just a better java?

Few people are treating it like jvm haskell in production, although a certain subset of really loud people wish it wasn't otherwise. They all tend to work in the same OSS projects, while the rest of the community does their best to pretend they don't exist.

I think that the reality of modern scala is that, while there is in no way a unified use of the language, the way to use Scala is in its own, intermediate location. Libraries have big gains from the most exotic features that make it be closer to FP, like higher kinded types. while business code tends to look more like java with case classes and algebraic data types. The difficult part is the fuzzy middle.

Another important part of adoption is that Scala's strengths lie in a few good libraries that underpin some great use cases. For instance, using Scalding or Spark as ways to do big data, or building other kinds of distributed systems on top of Akka. For other uses, like writing simple CRUD services, there are many options, and almost all of them are bad, which is why treating the language as just a better Java just doesn't fly.

Actually sealed traits and case object/case classes and pattern matching is really useful for http programming.

Verizon is one of the bigger scala shops (a few hundred scala programmers on a "project") and is much closer to the functional side than a better Java. However, micro services and good library support mean some of the less experienced teams (in FP) use it more of Java++. Both are very pleasant to maintain/work on though.

This is just one [massive] project, but HMRC are rebuilding in Scala atm, & from talking to the developers working on the project, bit of both: selling it as a better Java with all the associated interop with existing stuff, but individual devs attracted by the functional side. The Guardian seemed to have similar reasoning.

Third option: like a JVM ML.

With the popularity of Apache Spark in big data, Scala is definitely gaining a lot of traction.

Elixir is promising.

http://elixir-lang.org/

And really enjoyable... That's what really counts right?

Couple that with Phoenix (which looks and acts like most other MVC frameworks [and has good docs]), and we have a win I think.

And yes, it's quite fun (and mind-bending at the same time, in a good way).

Clearly you haven't worked with EXRM and the 'no documentation outside hello-world' Ecto query.

/s

Seems comprehensive: http://hexdocs.pm/ecto/Ecto.Query.html

Disclaimer: complete Elixir noob

F#?

It's used by a few big names (Bayard Rock, Tachyus, Jet.com, BlueMountain Capital, Microsoft Research, etc.) and it looks to be gaining more mainstream acceptance.

Jet.com does a ton of F# advocacy here in Silicon Alley

> While functional concepts have leaked into imperative languages, [...]

I predict we'll see more and more of that, but never a great breakthrough:

- appreciation of pure functions and immutability - optional typing even in Python - Garbage collection (mainstream since Java) - higher order functions - algebraic data types (in Scala, sort-of possible in C++ boost, and even in protobuf) - etc

Pure FP might not have taken over the world.

But those that read my Java, C# and C++14 code, better know their way around lambda calculus.

Take off the HN glasses and PHP, Java, C# and loads of other 'old' languages are still huge.

As for Python: I think it is starting to grow again in the Linux world.

Reasonable Python is much younger than that. (Only fair, if you make an adjustment for reasonable js.)

ES3 is probably the real cut off for JS.

October 16, 2000

Just googled it, it's the release date of Python 2.0.

What was so unreasonable about 1.5? That was my first python and it worked perfectly fine.

Old style classes. No way to subclass built-in types. No metaclasses.

Sure, but non of those things made it a bad language, or where really unreasonable things to have left out.

There is a big difference between unreasonable and bad.

Python was always a good language because it was basically the same pseudocode we all scribbled on blackboards anyway -- with the added advantage that computers could execute it.

I just found 1.x to be unreasonable. I also find 3.x unreasonable for unreasonable reasons.

For me it's lack of lexical scoping.

When people say dying, they never mean it's just going to disappear. The hit-and-run on Go being a new 7 year old language seems unfair. It has great performance and has proven itself in production.

There's a lot more competition for computer languages. It might end up like Perl. More people use Perl today than 15 years ago but its importance has waned.

You really haven't addressed the issue. You simply did that dance that developers do when debating a topic. e.g. "This one is too new..." I remember when the iPhone was released, that similar misguided logic was used. Microsoft owns 20% market share and Blackberry is huge. Android was junk in its first couple of releases. Now they rule the world.

Languages like Python will have a problem because Swift and Go, for example, provide performance and type inferencing. They both just need lots of 3rd party packages. Something like a well-done cross platform F# could also prove popular. Higher level programming means safer code.

The age makes a big difference for at least these reasons:

- given I have a problem, how likely is it that it's a problem in the runtime nobody saw before?

- given I want to do X, how likely is it that there's a library doing it already present? (and how likely that there's one established library rather than 10 trivial attempts?)

- if I can't find a solution to X, how likely is it that there's a solution in the first link on google? (and how likely is it that it still applies to current version?)

These have everything to do with the maturity and popularity of a language.

The iPhone / Android move is exactly what I meant about predicting popularity being like stockmarket. You've got as much information as the next person normally. If you believe the logic was misguided and you knew better, I assume you made lots of money as one of the first people to invest in the right ecosystem, right? Unless you have the weight to move the whole ecosystem, you can just choose the right solution for yourself - and most of the time it's going to depend on popularity.

Scala, F#, Kotlin, OOC, Swift, C#, OCaml have performance and type inference, and that's just some more popular ones. Python didn't have a problem because of them. (and 3 of them have a massive amount of libraries ready to be used)

Massive library. That was Perl's big advantage. Why do more people use Python over Perl? F# isn't really cross-platform yet. Swift is 18 months old. Scala is a bit complicated for many and slow to compile. C# was a Windows only language for a long time, with Xamarin for those who really really need limited cross platform support. OCaml never gained much traction. If Microsoft had used it instead of a slightly different F#...

Once again, you're doing that dance. Do you think I'm learning anything here? Watch out for Go and Swift. These statically typed languages are better for large projects.

Please skip the part where you explain Python's optional typing.

Thought-provoking post. The responses below are my opinion, but I do think there is a good chance they're the opinion of the majority.

>Why do more people use Python over Perl?

Two factors, it came packaged by default on Linux distros and OSX. That was really a king maker in itself. Then add that the language itself is that much better in most people's eyes. People don't really like obfuscated code unless it's the only game in town (ie. the 1990's and Perl).

>Watch out for Go and Swift. These statically typed languages are better for large projects.

It will be interesting. But both have pretty big flaws so any extraordinary claims will demand extraordinary evidence of success. Neither language has exceptions. Go is controversial in its conservatism and this is likely due to the fact the entire team had to agree to add features to it. So it did end up odd in some ways because of that. Swift is in a constant state of change. Both are missing a lot of libraries. I've tried to use Go and see many abandoned projects like Martini and newer projects seemingly abandoned like Revel. The Go faithful will tell you this is because frameworks are not The Go Way, and point you to the Gorilla toolkit instead. I'm not sure I buy that story unquestioned, or not. On the whole, I'm unconvinced due to their language characteristics, that Go or Swift are ideal replacements for either Python or Ruby for webapps.

>These statically typed languages are better for large projects.

Yes, but I wouldn't want to write poorly engineered, bloated and difficult to port code even with static typing. I don't write massive 500KLOC projects so it's not a problem for me, but I have a policy of modularization with my code that would stem the issue (regardless of static typing or not). When you get to 500KLOC, there is no magic fix. Static typing, modularized code, nothing is a cure and hardly even a band-aid.

As a result of all this, I'm still onboard the Python train. I honestly do not see myself hopping off with PyPy being here today and Pyjion, Nuitka, and Pyston all up and coming. I would not be discouraged if a Rubyist either.

Of particular interest is that Microsoft is working on Pyjion and if it works out, API changes will be made to so that you download a module and JIT right from CPython3.

I'm probably more interested in Rust over Go and Swift at this point. Go is an island, similar to Java that way and not C ABI compatible, this makes it a less than ideal wholesale replacement of Python or Ruby. Swift is just too young on both the server and iOS. Rust itself is the best language I will likely never need to use, but its existence unlike most languages, makes an enormous amount of sense.

Thanks for the post. I share your frustration with the way developers discuss these issues.

Not to mention, the question sounds like this:

Is smartphone dying? You can use digital camera for photos, mp3 player for music, scientific calculator for math. Looks like a smartphone is being assaulted from all fronts.

We use python it is our primary language