Or maybe that's just wishful thinking. I just want it to be so.
Or maybe that's just wishful thinking. I just want it to be so.
Another change that broke significant amounts of code would just make things even worse.
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.
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.
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.
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.
And yes, I'm talking broadly about the rise of FP.
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?
While most of your examples are valid, I don't think Haskell is remotely object oriented. Type classes are not classes.
Quoting myself
> ... support polymorphism and extensibility.
OOP isn't only the C# and Java view of the world.
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.
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.
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.
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.
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."
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.
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.
https://en.wikipedia.org/wiki/John_Backus
Not taking any sides in this beef, though, just an interested bystander.
A subset may be.
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.