Saying goodbye to Python
ianbicking.org
ianbicking.org
This sentence is worth pointing out as a good attitude. I think the healthiest place to be is using tools you like, but able to appreciate the good bits of other systems.
For instance, as long as I'm not actually working with it, I can appreciate the idea that PHP made it very easy for a lot of people to do something with the web, something that otherwise they might not have been able to do, because it is very easy to get started with. That is worth something, and worth thinking about for those who are building tomorrow's languages.
And his position is very reasonable. He doesn't seem to care if you use PHP, if it works for you. But he doesn't like using PHP himself, for whatever reason(s), and wishes to not use it. His abstinence from PHP doesn't prevent or affect your (or anyone else's) use of it.
PHPers like me know very well this kind of trolling (after years of suffering it), but we are also way above it already. Sometimes we want to reply, but then we remember that this trolling is born from bitterness and lack of success, so we just let it be.
Are you sure about that?
a lot of people != all php users.
a lot of people != the majority of php users.
That's not what I said.
I was trying to point out a good side of a language that I do not particularly care for.
Think about it this way: there are plenty of smart people with good ideas who, however, are not programmers. Doctors, accountants, architects, physicists... whatever. A system that has a low barrier to entry so that these people can create something is a positive thing to have.
And if programming PHP floats your boat, that's fine too.
Anyway, the point is: you completely read the OP wrong, in my opinion, and I'm the person that would be most offended if it was a dig...
Like what? I feel there are many reasons why it is a dangerous language for a novice, but if you can be productive with C/Java/Python/Go/YouNameIt, you can probably write nice, maintainable and reliable PHP.
If you're talking about technical difficulties or elegance or whatever, sure. I'll just go with the Facebook argument. I've bootstrapped many projects for companies who aren't made of über hackers, and going PHP guarantees them they can very easily find people who can pick-up the code later on. Also, any * hosting will run your code.
I think nowadays, ideally, I'd just use Go for everything. But in reality, productivity > idealism.
As a php programmer and a member of a php user group I can say that group seeems to have half of its talks on non php topics javascript, html5, css etc.
I like the community that doesn't fret about tools and only about how to build something interesting.
Scalability can be an issue, but honestly business scalability is a problem for most businesses long before technical scalability is. Ruby and Python are awesome, but it can be hard to scale a company with one of those languages because it's hard to find good programmers who know Ruby or Python. It's much easier to find good Java or C# developers.
At this point, given all the work the Apache foundation has done to make Java awesome, I don't really know I would consider another language from a business standpoint. Sure, from a technical standpoint Java isn't that exciting; but it's easy to scale, easy to hire for and relatively standard across a number of platforms. Java code is also relatively easy to maintain since it forces you into certain design patterns.
There are some domains where this wouldn't hold true (and data science is definitely one of them -- you'll have an easier time hiring a machine learning expert who knows Python than Java) but that's really just technology. In a production environment, you'd eventually wrap your Python code in REST APIs and write all the ETL and interface code in Java.
You're on the money with Apache foundation (and other great quality tools/libraries/software written in Java). The ecosystem is just too huge to ignore. The other day we saw ElasticSearch at the top of HN when they announced they just released v1.0.0. I know tons of hi-tech companies are using it.
Meanwhile, there's no group or organization that invest in Ruby or Python the way Apache does to Java.
It's kinda sad. I really really wish (and want to see) similar thing happen to Ruby/Python but it's 2014 and sadly it hasn't happened. Outside Rails, I don't see anything else in the Ruby world that reach that level of adoption (maybe Jekyll or Octopress). Django seems to become minority. Plone seems to quiet down. Turbogears is probably dead. Flask is on the rise. Twisted doesn't seem to be the defacto solution.
Just that in general, Ruby or Python community seems to be locked on CRUD for web-app but nothing else.
Good programmers usually become good python programmers quickly if it has become their day-to-day job. But maybe we have different levels in mind when we say "good".
While I would love to hire a bunch of elite hackers who are able to adapt to any language in a week, the reality is that most of those guys work for Google or Facebook and aren't interested in writing code for business apps (and probably wouldn't stick around anywhere early in their career for more than a year or so anyway). What you end up being able to hire are the B students from CS programs at good state schools (Texas, Michigan, etc.) They're not bad developers by any means, just not uber-hackers.
A lot of these guys are developers because it pays well and affords them a comfortable life for them and their (potentially future) family, not because they love technology. And there's nothing wrong with that.
Ian's participation in the Python community has been - and will continue to be - missed. I hope he brings the same wisdom and humility to the splintered Javascript community he brought to Python.
- I met a founder from Lytics (my current mostly-Go job) at a Go meetup.
- I met a couple of the founders from Urban Airship (my previous mostly-Python job) at a Python meetup.
So I guess going to meetups is what works for me, but I don't think that's a general solution. Sorry I can't be more help.
Personally I think it's a pretty good solution.
There are lots of people for whom it probably doesn't work. It takes a certain personality, and it really helps to be a white male. Minorities are often treated differently at meetups, so I don't want to presume that my experience in a privileged position applies universally.
I suspect those difference also apply in formal interview situations - and maybe even more difficult to overcome there. Maybe meetups have better potential to overcome negative sterotypes because people actually get to know each other a little?
But white male here too, so what do I know.
[1] http://www.slate.com/articles/technology/technology/2014/01/...
To pick out a few companies hiring, where I use their services so want them to succeed:
http://careers.mozilla.org/en-US/listings/
http://www.cloudflare.com/join-our-team
[1] https://code.google.com/p/go-wiki/wiki/GoUsers (Note that Google isn't on that list. Pretty sure they use it a bit, and are hiring..)
Oh by the way, this comment is not against the author, it's against humility-as-a-value. I think we've gone too far here. The creator of virtualenv and pip do not have to force himself showing humility, he should be proud. There's nothing wrong in being proud of one's achievements.
[grammar edited]
So, Ian Bicking aside, I think it is an interesting topic. Some notes:
- Like real generosity do not display itself, real humility hides itself. Or should.
- Humility (or some expressions of it) can be seen as a Middle-age Christian value. Jesus-Christ himself was all but humble, but in European Middle-Ages and after, there was a few movements trying to show unlimited submission to God's will, and humility was proposed as a core value.
- While I understand the pro-humility trend is a counterweight of the arrogance, which is quite annoying too, I think best would be to display none of them. In fact it means displaying less of the self, and more of interesting content. I think Peter Norvig's articles are good examples of writings letting the self in the back shade, which by ricochet raises curiosity and interest in the author's self. I think many other authors are also good examples.
Just anecdotal/personal opinion on JS and Python communities. I went to Python and JS meetups. Python meetups are usually people talking about different real-life projects they are building with Python with maybe 10% of talks about new frameworks/language. the one JS meetup I went was people comparing and arguing which frameworks/library is better and should we stop using this one or that one, which one is messy .. etc, talking about things that were solved long time ago in AS/Flash/Flex
With JS I'm afraid to spend on a hyped framework that will be obsolete in 6 months.
On the server side you have one designer - Google and its V8 engine which caused an explosion in innovation.
I see this and it bothers me as well. Sure, picking up new language syntax isn't that big of a deal, but to become reasonably proficient at solving problems with a programming language takes a huge investment of time and energy.
Languages like Go and Python take very little time to learn the language features even though mastering any language is quite an undertaking.
Or to put it succinctly, focus on problems, the constraints and forces shaping those problems, and not solutions. Different technologies will come up with different solutions depending on the specifics of their culture and where they're being used, but the underlying problems come up a lot, and understanding where you've seen it before can make reaching for the correct solution a breeze.
For example, I was just talking with some Polymer folks last week about how to manage global data that needs to be passed between components. They're largely from a client-side, web, JS-heavy background, but after listening to them sketch out this approach that they'd found very useful, I was like "Oh, it's like a Monostate pattern for HTML." That's made it dramatically easier for them to explain their solution to other people, because C++/Java/C# devs know what Monostates are, and now they can just plug in the syntax of HTML and semantics of Polymer elements into everything they know about why the pattern might be useful, what its drawbacks are, how it fits in with other patterns, etc.
One of the sibling comments here mentions how you really ought to know things like testing frameworks, in-code documentation practices, logging, etc. before you can be considered to "know" a language. I'd agree, but I'd argue that knowing that these things exist and why they're important is about 80% of the battle to using them effectively. I can pick up a new language in a few weeks and while I won't be an expert on it, I'll at least know to check out the preferred unit testing framework, read up on the logging APIs, see what the language's philosophy on error handling is, etc. I don't have to start from scratch, because I've worked on projects where these things were important and used a variety of frameworks that all solve these problems in subtly different ways. No, I'm not going to be as quick or elegant as someone who's been working with the language for 10 years - but I'll also be miles ahead of a fresh grad out of college who is just encountering the concepts for the first time and needs to learn the language mechanisms and why they're important. And when technology changes so fast, that knowledge is a lot less likely to go stale than whatever framework is flavor of the month.
They probably learn some of the syntaxes but they don't learn the idioms and proper ways of using the languages.
I've never met a developer who can pick up a book and be a master in relatively quick. They can hack something up but by no means the code is acceptable.
The only reason we believe someone can jump between languages quickly is because we _NEVER_ see their work and we _NEVER_ put them under microscope. We just believe the hype.
By acceptable I refer to the following criteria:
- Proper test automation
- Proper documentation (in-language doc)
- Proper idiom (that means logging properly, proper design pattern suitable for that language, using proper libraries/standard-lib correctly)
- Proper SCM (that means build, dependency management, folder structure, code style, code analysis tool in-place, etc)
Anything less than that is a sign of either the language ecosystem is not mature enough or the developer has yet reached the mastery level (or simply not enough data to measure the level accurately).
Also documentation frameworks may seem identical if you only program in C, C++, and Java. However when you start doing a lot in SQL, Perl, or Python, they start looking very different (and in fact these languages, assuming an SQL that supports COMMENT ON syntax) are more similar than any of them are to C or Java in this regard).
Move from there to TeX or LaTeX and you are in for another big shock.
In short, there are idioms for both test cases and documentation and those are remarkably language-specific.
For example: if one is deprecating a method, there are a bunch of proper JavaDoc ways to do this (starting with the @deprecated annotation, not to be confused with another @Deprecated annotation, don't forget to state since which version this method is deprecated, etc etc).
It requires a high level of discipline and knowledge of the javadoc idioms.
http://www.oracle.com/technetwork/java/javase/documentation/...
Occasionally, one have to insert HTML too...
I know C# support similar thing.
Like the old adage. Good programmers can write FORTRAN in any language.
One can read Perl code and say "this was written by a C programmer" for example, or "this was written by someone who knew Python better than Perl."
Switching between languages for me usually means at least one failed project which nobody ever sees.
Also I would not call myself superproductive, though I have been called that by others. A big reason some people think I am superproductive is they don't see where I spend most of my time.
It's not like I was the world's expert in those languages and at that point and I'd probably flub the sort of interview questions focused on the nitty gritty (heck, I've never been good at those regardless) but I knew what I wanted to do, had a good idea of how to do it and a minute or so with google would fill in the rest.
I don’t want to get caught up in the weeds again, building tools for something I never manage to make.
However, I ended up moving to other languages for what I was "making". First using Python, but now also venturing into native development using C. I guess part of it was wanting to not have limitations on what I could build. PHP was limiting in dealing with crappy hosts, Python less so, but the sky is the limit with C.
Everything you can do in Python, can be done in PHP too. For long running processes you can use libevent, and for threading (web server) you can use libcurl. You can write native C or C++ extensions for both Python and PHP. Facebook's HHVM PHP JIT VM is very scalable and there is PyPy (Python JIT).
Python has some similar issues. Ensuring that an end-user application written in Python is going to have access the the appropriate version of Python with the packages you need is still a challenge. Asking Joe user to install virtualenv and Python 3.3 is not viable.
Currently I'm working on an app that uses Python, but is written in C and embeds Python for some of the cross-platform components.
Javascript has Angular JS that I want to play with. Go is shaping up to be an efficient and easy-to-use server-side language. Rust is C++ that doesn't want to make me gouge my eyese out. But what about Python? Apart from throwaway command-line tools, I've got nothing.
I am not versed in Dutch culture, but considering Van Rossum's background, I thought it was an interesting statement.
And that's exactly what I want, these days.
When you program in any language of your expertise you don't really notice the language at all.
My code is a little more verbose in Python, but I notice I don't shoot myself in the foot by trying to be too clever too early, and ending up with a tangled mess a few days later.
Um, exactly? Not a horrid mess is high praise in programming languages.
I can't think of many languages I use that come in for that description. Look at which languages come with a decent language, a decent standard library and a decent community. That's a really small subset.
I'm currently keeping my eyes on both Julia and Rust and regularly try to do things in Haskell and Clojure, but basically every time I start a new non-trivial project in a new language I often end up at a point where I'm facing a language problem not a problem domain problem. How do I deploy language X on platform Y and make it talk to application Z, why is there no library to read/write .foo files, how to I make these two incomplete, buggy, almost-but-not-quite-overlapping libraries I found on github play together.
And don't get me wrong, that can be a fun challenge in its own way, but I don't always have time or desire to take 2 weeks out of what was really supposed to be a 2 week project to write a library to do something that would take me 2 minutes using a stable well tested python library.
I don't know, maybe it's just me getting old, but these days I'd much rather spend my time solving problems using programming than solve programming problems, doubly so when people are paying me to solve problems.
I do struggle with it though, because it is so bland.
Python as a language is uninteresting. It has no novel or exciting ideas other than its readability. Python 3 has shown nothing of importance to upgrade as the rate of adoption shows.
It lacks the flexibility of Ruby, general appeal of JS, philosophy of Clojure.
Maybe its boringness might be of value to some, as it has reached steady state, but I believe that if you are going to be where the puck is going to be, you need to consider languages other than Python. I am betting on JS and Clojure.
This feels like a cheap shot. What flexibility, general appeal, or philosophy?
Flexibility: Python is very flexible (I'll say dynamic), but not at the expense of clarity. This is a (IMO, correct) decision made by the Python community.
General appeal: What does this even mean? The only reason JS has a general appeal is that it ships with every modern browser.
Philosophy: What philosophy? Purity? Simplicity? Python is a pragmatic language ("get stuff done") while keeping simplicity in mind (although I definitely wouldn't argue that Python is as "simple" as some languages, it's simple enough)
Right, somewhat a cheap shot, that was partly a rant, as I don't have the motivation to explain it fully in a comment.
> Flexibility: Python is very flexible (I'll say dynamic), but not at the expense of clarity. This is a (IMO, correct) decision made by the Python community.
I would argue that it is not as flexible as Ruby or Clojure for building DSLs. I believe this is not only a decision, but the result of constraints of the language, like significant whitespace or lack of macros.
> General appeal: What does this even mean? The only reason JS has a general appeal is that it ships with every modern browser.
Exactly, but also due to significance of web, it is drawing lots of talent and there is a cambrian explosion in JS. There is so much energy and experimentation going on right now in JS world.
> Philosophy: What philosophy? Purity? Simplicity? Python is a pragmatic language ("get stuff done") while keeping simplicity in mind (although I definitely wouldn't argue that Python is as "simple" as some languages, it's simple enough)
Exactly, purity and simplicity. Lack of functional programming ideas in Python, broken lambdas, mutable state etc. Clojure tackles one of the major source of complexity, state, head on, while maintaining pragmatism.
Python is pragmatic too, I concur, but it is not a language that transforms the way one thinks about programming, it gets the job done, without giving you that much leverage.
I've never met a DSL that was better than a well designed API. They all start leaking at some point.
As a design goal Python aims to be as little flexible as possible to enforce its design goal of making code readable at any and every cost.
In fact its so brittle merely small time changes to a print statement has caused nearly a 8 year backward incompatible ecosystem which is still catching up.
I can't image what would happen when some new ideas have to bought in the language to keep pace. Keep going through migration cycle every 6-7 years to handle backward incompatible changes.
The story till now was some how okayish. Basically Python was playing a catch up game with Perl to get the popular features Perl has. It still hasn't succeeded completely, and yet has a heavily fragmented ecosystem between 2.x and 3.x dev branches. I don't see anything new going into Python any time sooner.
Python is as little flexible as it gets.
Something which can be automatically ported with full backwards-compatibility for the last couple releases of the 2.x branch isn't a good example. You'd do better discussing the bytes / unicode growing pains since that may require a human to think about the problem.
I think that's a very narrow way of defining flexibility.
By your definition of flexibility, C++ must be really flexible because its template system is Turing Complete and you can do whatever you like!
By the same definition, Scheme must be a pretty inflexible language because its syntax is extremely limited (simple).
Python is flexible in that:
- it can be used in many different fields (because libraries exist for science, web -- you can find a library in Python for pretty much any task you can imagine).
- there a number of different implementations of the language to suit your needs (CPython, Pypy for speed, now Micropython for embedded). It is (somewhat) easily ported to other platforms (e.g. ARM, JVM, .NET).
- the language still allows you to do imperative, OO and to some degree functional programming. I don't think allowing Python to do everything under the Sun makes it "flexible".
- Python's dynamism (look at something like the library "sh"), ducktyping, keyword arguments make it flexible.
--
Final point: I think using Python 3's print statement as an example of Python being inflexible is dishonest. Python 3 had major internal changes made to it. The backward incompatible jump between 2 and 3 (AFAIK) was more a choice and a requirement. Guido has recently (just last year) said that he will never do anything like Python 2 -> Python 3 transition again.
I remember reading the announcements on Usenet for early versions of Python over two decades ago. I wasn't excited about it then because I was so tied up in learning The Next Big Thing and Python, even when it was brand spanking new, never screamed sexy.
At some point though, I stopped chasing The Next Big Thing because I needed to actually get stuff done in such a way that didn't involve me or another senior engineer maintaining it forever. Nearly 15 years after I read the first announcement of Python, I actually started to use it in earnest and I liked it. At some point in one's programming career, one starts to become practical and Python, if anything, is a practical language.
I sometimes think the reason Python doesn't have the zealotry in its community like other languages is because it attracts such practical people that when faced with a problem that would be easier solved in another language, will simply use the other language.
It's existed for so long that it is a hugely high-functional tool, and many/most of it's hard edges have been filed off (either in the stdlib or in user-made packages).
Something I feel in using Python is that it's blandness/utility is itself beautiful, or at the very least, elegant. Like a well made tool, it doesn't get in your way, it works well for what it's designed for, making creation without thought easy.
That is one of the greatest joys of Python for me.
It's very similar for Clojure. It's based on ideas that go back many decades now. Its main selling point is that it's somewhat more practical than previous Lisp or Lisp-like language implementations. Other than that, there's nothing particularly innovative about it.
Python never really suffered from those kinds of problems. It has had a very sensible set of language features since its inception. It has had a very practical standard library since its inception.
Due to a general lack of past mistakes or omissions, there just isn't the need for significant and ongoing repairs that can be misinterpreted as "innovation". This is part of why Python 3's adoption hasn't been that rapid. There really wasn't much to fix, and the problems that did exist were generally quite minor and easy to work around.
I have a philosophy:
Innovate in either what you are building OR what you are using to build it, not both at once.
So if I'm working on a CRUD website, I'll happily push the boundaries on what tools I use. I can afford to burn some time because I know what I need to do.
If I'm working on something which no one is quite sure is possible, then I want boring, safe tools wherever possible.
There are exceptions, where you what you are doing is so innovative you need new tools to build it. Exceptions are exceptional (and often interesting...)
Of course, for some personal project I ignore my own advice. But then I know I'll be fighting my tools as well as what I'm trying to do, so that's my choice to be stupid.
It also explains why I see far too many shiny web 'frameworks'. People just must attempt doing something "cleverly" especially if the end goal is boring.
I'm in the opposite case right now, I have way too much complexity to want tricky dev or ops tools.
In this case, I would argue that's a feature, not a bug.
Python as a language is 23 years old -- older than quite a few people who program it. And while it has changed through the years (adding things like generators, comprehensions, dropping explicit member access control, etc.) it is still mostly the same language.
The fact you find nothing novel in it is mostly a reflection of your history, not Python's history; if I had to sum up Python's history, its novelty lies with distilling concepts into more limited but easily understandable, practical constructs - e.g., list comprehensions, generators, significant whitespace.
I started with Python in 1998, over 15 years ago. These days practicality and blandness is a virtue to me, not a shortcoming. I wouldn't say Python is not going where other languages are to be heading. It might do so with little fanfare and less heated discussions, but it still gets there. Or perhaps it has arrived "there" already, with a zen like presence.
Only place of pain is the web browser. It is the most interesting platform, but with a language with greatly annoying warts. I'm glad that Ian has chosen to work at Mozilla to help create a better web. Perhaps he can do things for JavaScript ecosystem like he did so well for Python with virtualenv and pip.
1) it is literally almost impossible to write unreadable code in Python,
2) most scientists are terrible programmers,
and
3) when a project matures, "real" programmers get involved, and the fact that the code is readable (and therefore amenable to maintenance and extension) vastly increases the chances that the project will succeed.
As for the rest, it seems very confined to the use of Python as a web programming language, if you try to use many web languages in domains outside of the web you will be writing a lot of things from scratch. Python has multiple competitive web offerings but they form part of a huge landscape of offerings in many areas few can match. I'd go so far as to say the top two languages for "is there a B+ or higher viable library for this random task" would be Python and Java. Clojure's promise is to swiftly address the flaw in all other Lisps by incorporating the Java ecosystem.
Programming language research gets an order of magnitude more coverage on HN than it does inside Computer Science as a discipline. It's a simplification, which has nitpicks people can use to derail the argument, but broadly speaking algorithms - in terms of practically being able to import and use them as well as to practically be able to talk and reason about them with other people - are vastly more important than language syntax.
Not only that, you'll also realize that you're wasting CPU cycles and RAM.
"There is no community that created Javascript like the Python community created Python. Python comes from the internet in a way Javascript does not; Javascript was built for the internet, but Python was built on the internet."
Hadnt it been for the browser noone would be using the mediocre language.
Actually I'm really glad for this conclusion. I've always thought it kind of counterproductive and useless to label ourselves as "Rubyists" or "Pythonistas" etc. Yes, we may use that language, we may even prefer that language over another, but it's not for the sake of the language itself, but because of what it allows us to do. So when a better replacement comes along, that kind of attachment to a language is only going to delay our adoption of it because of basically nothing but sentimentality. So yes, I prefer Clojure. But I also prefer C# and Objective-C and JavaScript. I'm not in any of these communities, I'm just a problem solver.
PS: I'm looking for an internship! Any suggestions?
My recommendation to people interested in software development and "building things" is to not get too upset and wrapped up in a particular programming language.
Also, my recommendation to people interested in software development is to study computer science, unless you just want to make WordPress templates, I guess.
I found this to be true about my experience too. I wanted to write GUI apps for Mac OS X so I embraced Objective-C. Now I want to write GUI apps for Windows, so I'm embracing C#. I guess it's just a really nice bonus that C# is awesome. Same thing when I have to do front-end work, I just use JavaScript (or ClojureScript if it's a big enough project).
Then he revealed Javascript. Even though I am putting out a ton of javascript and javascript-targeted languages, I found that a little disappointing!
It's so frustrating to see "Science-style bullshit" taken as gospel by intelligent, creative, and usually critically thinking people.
It's a useful poetic phrase to express the observation that mastery takes time. Sure you could call that a Captain Obvious observation. However he used it in opposition to the idea that great programmers can master a new language in a few weeks. Since that idea is so popular, its opposite apparently is not so obvious.
Also requires talent (or skill, genetic disposition, etc., call it what you will)
And the hype of Dart? I think there is always hype. Hype of Go, hype of Rust, hype of Scala.
There's no "perl hype" because (virtually) nobody is just discovering it as something new and useful.
As python came to have a robust web ecosystem, it started to get a lot of hype as it was getting a ton of converts from perl/php/etc.
Now as web tasks are changing, Go's niche is becoming larger, and people are excited to use it where Python was failing them.
This will continue forever, most likely.
(I say, as I work in Scala. But I think it's slightly different from your other examples; it's been around much longer than the other three languages you mention.)
A native language takes even longer sometimes, Objective-C just really hit it's stride with Apple/Next integration and the iPhone but it was made in 1983, same year as C++. Both with very different spikes/waves of interest.
From this we can see strict/native type languages in the 80's, more dynamic/scripted languages in the 90's, the ones in the last decade maybe are still in contention. All of them are pretty much products of their hardware environments at the time.
http://www.google.com/trends/explore#q=%2Fm%2F060kv%2C%20%2F...
If I input e.g. "PHP" I can select "PHP (programming language)", but the search suggestions for "Python" make it impossible to add "Python" (the programming language) :(
Search suggestions are for me: Python molurus, Monty Python, Python reticulatus, Burmese python
No, but it certainly has pushed for decent dependency management systems, and has led to more complex libraries.
Non-blocking IO is nothing new. Event-driven network app development frameworks are nothing new. Even using the same language server-side and client-side is nothing new. We were doing that in the 1980s when we wrote our clients and servers in C, and in the 1990s when we used C++, and in the 2000s when we used Java.
When it comes to JavaScript, what's seen as "innovation" is usually just the language and ecosystem desperately trying to catch up with where everybody else was many years in the past.
That's true up to a point, but you're being a bit uncharitable. I'm thinking of a couple of solutions specifically:
- npm [1], which I hear a lot of good things about, while this is definitely not the case about many languages-specific build systems/package managers
- react [2], which is a nice approach to DOM manipulation (if not, maybe, the first of its kind)
And obviously, more and more languages compile to JS nowadays, or are on their way there.
1: https://www.npmjs.org/doc/cli/npm.html 2: http://facebook.github.io/react/
"ECMAScript Harmony ... with a target release date of December 2014"
Yeah, the world is moving... So damn fast! Only takes 6+ years to release a new version of language.
I would appreciate such blog posts/comments too.
> And when I did step back there wasn’t anything in Python that excited me.
That said, for a production system I'd prefer Clojure (or possibly Haskell). It can be almost as fast as Java, has proper lambdas, and doesn't have mutable state in unexpected places.