The Rise and Fall of Languages in 2012(drdobbs.com)
drdobbs.com
The Rise and Fall of Languages in 2012
http://www.drdobbs.com/jvm/the-rise-and-fall-of-languages-in-2012/240145800
24 comments
Someone else posted this another thread and I agree: any methodology that determines that JavaScript is "treading water" is suspect. Even if you ignore JS on the server side, I would be very surprised if its importance and use was not increasing pretty rapidly.
I agree...I couldn't trust an article that thinks JS is "treading water' ... It's so far from the truth it's not funny. Keep in mind things like MongoDB use JavaScript with map/reduce and other commands. Then of course look no farther than the mobile world. If anything I would expect JavaScript to become one of the top most used and popular languages out there. Given that it can be used for many, many, things including some decent graphics work. Desktop apps, mobile, server, databases, and of course (and always since the 90's) blinky text in HTML documents =)
Or it could be you're in a bubble, and the greater world has not heard about the great and wonderful javascript yet.
The article says those figures were from Google Trends, which tracks searches on certain keywords. It failed to mention if this was explicitly for "javascript" or if it included other keyword variations as well. Add in searches for jQuery and the names of any popular library or MV* framework and I would bet you see a much different story.
Why, if we ignore it on the server, would it be increasing suddenly?
Nothing's changed. Only node.js is new.
Nothing's changed. Only node.js is new.
It's not increasing suddenly -- it's been increasing for the last 5+ years. Or really increasing for the last 15 years continuously, but in the last 5 years it's gotten a boost with new libraries and so forth, fast Chrome enabling rich experiences, etc. JavaScript is just being used for more and more things, and there are more of the things that it has always been used for.
To say it's "treading water" means it was flat between 2011 and 2012, which I don't think is true.
To say it's "treading water" means it was flat between 2011 and 2012, which I don't think is true.
Does anyone else see a lucrative consulting opportunity in declining languages? I know a LOT of people still writing COBOL for a very good living, so who's to say in 10-15 years you won't be re-factoring enterprise Java in the same way.
Of course, you might want to just kill yourself first.
Of course, you might want to just kill yourself first.
A couple of years ago they actually started a one year COBOL education program here in Stockholm. Mostly backed by banks and insurance companies and from what I have heard most graduates have gotten relevant jobs. I doubt that the demand will be larger than the supply for much longer but it is quite fascinating nonetheless.
I would want to make sure that the declining languages had a good foothold in a lucrative industry.
COBOL programmers are increasingly valuable both because of their scarcity, and the fact that the small number of places that will need to continue maintenance on old legacy COBOL applications are mostly financial companies, who are using said COBOL applications for integral parts of their banking systems. It's a good market to cater to.
I don't necessarily have a crystal ball, but I'd bet that in 10-15 years Java will be a long way from a declining language; and I say that as someone who has never particularly liked it (the language itself, I think the JVM is actually a pretty badass virtual machine).
COBOL programmers are increasingly valuable both because of their scarcity, and the fact that the small number of places that will need to continue maintenance on old legacy COBOL applications are mostly financial companies, who are using said COBOL applications for integral parts of their banking systems. It's a good market to cater to.
I don't necessarily have a crystal ball, but I'd bet that in 10-15 years Java will be a long way from a declining language; and I say that as someone who has never particularly liked it (the language itself, I think the JVM is actually a pretty badass virtual machine).
There's nothing wrong with writing COBOL. It isn't new and shiny, but is that all everyone looks for in a job?
I look for enjoyment, which involves a lot of things, but feeling that I'm doing something constructive is a big part of that, and when I spend days trying to write something that I could do in two minutes (or wouldn't be necessary at all) in a better language it gets very demoralizing.
I personally wouldn't plan a business model around technology laggards.
"Out of the ~250 programs I wrote last year, 2-3 would have benefited from being written in a functional style."
Donald Knuth
Donald Knuth
One of the things Knuth is famous for is writing a lengthy program for word counts that was equivalent to no more than 6 lines of shell script.
I highly doubt that he's wrong regarding his own programs, but it's most certainly wrong for the majority of programmers.
PS if we're going to appeal to authority, Church and Lambda Calculus were there first.
I highly doubt that he's wrong regarding his own programs, but it's most certainly wrong for the majority of programmers.
PS if we're going to appeal to authority, Church and Lambda Calculus were there first.
Discussion of the word count problem Knuth vs. McIlroy http://news.ycombinator.com/item?id=4304696
And out of the ~250 programs that Knuth wrote last year, 2-3 would have solved a similar problem that your typical professional programmer would solve.
Functional programming strikes me as most useful for software engineering. I'm not sure how that applies to Knuth, but my understanding is that most of the programs he writes are more oriented towards computer science than software engineering.
It seems a shame about TCL. It has some cool ideas, including at least some degree of homoiconicity. I don't suppose a new replacement with the design warts removed would get much traction, either.
Yes, Tcl has it's problems but it seems a shame to see it appear to approach end-of-life,especially with the recent 8.6 release - although it is only in 8.6 that an 'official' object system has been added so maybe that says something.
Obviously Tcl has Tk which I think was for a long time a significant attraction - certainly was for me in the 1990's. The ability to script, cross platform GUI applications that glued bits of existing c code was exciting at the time. I had a significant amount of image processing stuff working this way with some very workable Tcl/Tk interfaces using OpenGL. That was fun too.
However, I've been using Lua for some of the same reasons that I used to use Tcl. In particular I like the simple nature of the language especially allowing a multi-paradigm approach to development. Although I have heard some argue it just supports many paradigms equally badly on single person projects, it's expressive enough. It's code base is small and neat - Tcl was always kept in good shape - and it is obviously designed for extendibility but with just enough of a core language to be of value on the vast number of platforms on which it runs. There are a reasonable number of addons and libraries available but the small core is a primary characteristic of Lua. Thus to get greater functionality you need to 'craft' your own setup which allows you to deploy just what you need for the task - the language is uber dynamic in that respect. LuaJIT is a nice bonus and the performance figures certainly suggest some stunning improvements are possible - not used it myself. Whilst understandable, it is a shame that LuaJIT isn't totally compatible with 5.2. Lua even has a pretty close approximation to Tk in IUP [http://www.tecgraf.puc-rio.br/iup/].
Obviously Tcl has Tk which I think was for a long time a significant attraction - certainly was for me in the 1990's. The ability to script, cross platform GUI applications that glued bits of existing c code was exciting at the time. I had a significant amount of image processing stuff working this way with some very workable Tcl/Tk interfaces using OpenGL. That was fun too.
However, I've been using Lua for some of the same reasons that I used to use Tcl. In particular I like the simple nature of the language especially allowing a multi-paradigm approach to development. Although I have heard some argue it just supports many paradigms equally badly on single person projects, it's expressive enough. It's code base is small and neat - Tcl was always kept in good shape - and it is obviously designed for extendibility but with just enough of a core language to be of value on the vast number of platforms on which it runs. There are a reasonable number of addons and libraries available but the small core is a primary characteristic of Lua. Thus to get greater functionality you need to 'craft' your own setup which allows you to deploy just what you need for the task - the language is uber dynamic in that respect. LuaJIT is a nice bonus and the performance figures certainly suggest some stunning improvements are possible - not used it myself. Whilst understandable, it is a shame that LuaJIT isn't totally compatible with 5.2. Lua even has a pretty close approximation to Tk in IUP [http://www.tecgraf.puc-rio.br/iup/].
TCL never knew what it wanted to be: replacement shell? embeddable command language? embeddable scripting language? general purpose programming language? GUI language?
The "everything is a string" design principle is a hindrance to most (but not all) of those use cases. The only place where it really doesn't create problems is in shells but TCL never did shells right (tclsh sucks).
The "everything is a string" design principle is a hindrance to most (but not all) of those use cases. The only place where it really doesn't create problems is in shells but TCL never did shells right (tclsh sucks).
Anyone else thought this would be a report on the number of moribund human languages in 2012?