"And, of course, Ruby itself is written in C."

http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-c-and-c-/

You are ofcourse absolutely correct when it comes to desktop programming but a lot of development nowdays happen on cellphones where (obviously, at least for now) there are certain restrictions when it comes to processing power, I/O etc. So, i wouldn't count out c (or even assembler) just yet.

But yes, we are certainly going in the direction you described. I have been working with Java from 19997 to maybe 2004, mostly doing webwork but i got tired of it and wanted to get closer to the "metal" i so much prefer coding c than Java or C#.

Interesting post, Andrew.

However, I think you are a bit unclear: First, you talk about C++ (besides others) not taking advantage of modern CPus and then you seem to indicate that dynamic languages like Ruby seem the way out.

Modern CPUs grow (as you pointed out in a previous post) in cores and not in Ghz. Ruby and Python on the other hand have no native multithreading (Ruby, so one core pre process only) or a global compiler lock (Python, better but still not good) - so where do they come in with new CPUs? Sure, they suck more CPU power than a C++ program (static vs. dynamic, full control vs. unsecureness relating where stuff gets created in memory, cache local programming is possible vs. you are at the VMs mercy which do not deal with cache locality to my knowledge tc.) but are more productive.

What is the real point of your post? Mainstream languages do not allow us to write parallel code easily (parallel progrmaming is hard, deadlocks are not believed to be automatically detectable in practice before they occur, for example). So, throw them away in favour of dynamic languages which burn through CPU power beyond good and evil (sure, I'm exaggerating here)?

Uhm, no offense meant, I just want to underline some controversies you pointed out in your article.

Sure, now we have fast computers, we can waste some CPU power in favour of lower engineering costs (and we should since computers are dirt cheap).

However, if you really want to be able to take your hardware to its limits then you need something as low level as C and C++: As far as I know, Java does not allow you to store object arrays cache efficiently, for example, but C(++) allow you to do exactly this (AFAIK .NET allows you to do this).

Anyway: Nice rant again.

I'm thinking that the languages I mentioned aren't really all there yet, but moving in the right direction. If I had a choice today, I would rather waste a few cycles on improving my productivity; after all an application sitting on the shelf not completed isn't running at all.

Great points. I'd add that the languages that will make people's lives easier in the future are those that enable their tools to help programmers more. This means leaning more on tools so that the source code is less cluttered; letting the tools take care of the hard stuff like concurrency and parallelism; letting the tools take care of the error-prone fragile stuff, like making sure you've checked the user permissions before giving access to restricted data. There is really awesome practical work being done right now implementing this kind of stuff in real-world programs; but not in C and C++!

Although your idea seems wrong at first, it really carries a glimpse of truth. It really is a tip for those who are beginning on the programming world. Maybe the beginners should choose a different path .

@Chris

C will outlive all the languages mentioned because it's the only system programming language available that is portable.

Common problem. It's not just Java and C/C++ it pertains to even PHP, if you really want to get best out of your team they shoudl be using a framework. Even if its just an inhouse one, at least it will help them cut the time to delivery down. Its the old mind set and fear of the new and the unknown that is stopping this process. Larger the organisation the more conservative they are.

The point you're trying to make sounds quite valid (taking advantage of multi-core systems), but I stopped reading when you seemed to propose Javascript as a solution to that.

Are you serious???

What constructs does Javascript has to take advantage of multi-core systems? Both Java and .NET have tons of support for threading and concurrency, while Javascript has next to nothing. In addition to that, the most basic number crunching algorithms execute more than a factor 400 slower on even the fastest Javascript implementations, negating any supposedly superior support Javascript may have for multi-core systems.

Either you made a typo, or you totally don't know what you're talking about.

The point is about productivity not multi core support. I was merely mentioning languages as examples of dynamic and functional languages not proposing that those specific ones are the ultimate solution. It's the trend that I'm proposing of improving productivity while benefiting from faster hardware. Think Ruby vs Java EE on web apps, Erlang vs C++ on servers.

Javascript the wave of the future? Are you serious?

What you say about dinosaur languages is true, but you're missing the dinosaur development methodologies that go along with them.

One of the reasons big software shops can't produce good software is because the development processes hobble the programmers at least as much as the language does. Requirements (including the choice of language and environment) are dictated from above, and often based on fantasy, advertising, and misperception; the large-scale design is done by a team of architects; and by the time the worker-bee programmers touch the code, their job is fairly well constrained. Then once the code is written, it goes to a testing group that makes sure it conforms with the spec. Any changes, for good or bad, have to go through layers of bureaucracy and management. And that's assuming everyone's competent: large companies are reticient to fire (but oddly enough, do not seem to mind promoting) incompetent programmers, and so every team in a big Java shop is likely to have at least one.

By contrast, startups tend to be made up of smaller groups, all of whom are directly involved with the end product. People who aren't competent and motivated never come on board in the first place, most of the time. There's no room for politics, and decisions get made based on whether they will get to the desired goal faster rather than because they got good reviews in Computerworld. If they use a formal development strategy at all (rather than just "write code, check it into version control, hope it's better than it was when you got up that morning) it's likely to be one of the team-focused agile methods rather than the big shop's big ball of mud.

I'm not disagreeing with your point, but I think that if you took a big software shop and a small startup team and gave them the same tools and environment, the small startup would still get farther faster. Not as far or as fast as they would if they got to choose their own language and environment, but far enough fast enough to show that organizational structure and team process matters.

I've blogged about dinosaur methodologies before, I fully agree with you.

I wish I had never used Javascript as an example of a dynamic language, people seem to react negatively to it. Perhaps Ruby and Python would have been better. In any case these are examples not meant to be definitive.

The only reason big shops are so slow is because they're big. If you put 40 offshore developers coding a Ruby on Rails app with all the controls of a big IT shop, their progress will be just as slow as they would have been on a Java app.

My mind is for changing. But so far, I'm not impressed with the productivity of the likes of Ruby. I will keep looking, but until I find something that convinces me from a language point of view, I'm not going to give up all the libraries I already know. Software you don't have to write yourself is after all the most productively written software. Not ever Java or C# program is bloated or over architected, so the difference is more in the design than in the platform I supposed. But as I said, my mind is for turning...

Absolute nonsense! The problem is not the languages but the development methodologies that have to change. Right now we aren't doing anything that is outside the core competencies of the major languages and platforms. Of course, 50 years from now, we'll have new domain spaces that will likely require new paradigms and languages, but we're not at that point yet.

Dude, you are a complete bozo. Like you are part of a new wave. You are just another in a long line that goes back through VB, basic, powerbuilder, etc., pitching your little crack pipe of choice, telling all the kiddies you wrote a whole site in 10 lines of code.

You've been doing Java for 10 years? I bet you would fail the most basic OO tests. Doing something wrong for a long time does not make you experienced.

Interesting post. It touches on something I see alot. The biggest cost for most development that I see and do is programmer time. Frameworks dramatically reduce that cost once the framework is understood. It allows programmers to spend less time on basics and get to the specific problem at hand. I program alot of web applications and I find Rails or Django to be quite useful for such projects. Its not that they really help me solve specific business problems substantially faster, its that they allow me to get to the bit of the code that deals with the business, instead of the plumbing, quicker.

Frameworks have a cost though, they require time to learn, they change, they may stagnate, they may not work for every situation and it may be difficult to ascertain that before hand. They may also impose cpu overhead. In some cases this is no big deal, in some, its a deal breaker (i.e. scalability). By way of analogy, just because a construction project may not call for a reciprocating saw, it doesn't follow that its not a useful tool to have for the other 10 that do.

As for your Javascript reference, an intersting blogger and google coder Steve Yegge might agree with your inclusion of Javascript as part of the next wave (not necessarily because its the best language out there). An interesting read.

http://steve-yegge.blogspot.com/2007/02/next-big-language.html

http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html

Would javascript really get so much hate if it wasn't for webaps and IE quirks? That's not to suggest it deserves love.

JavaScript is a terrific example of a dynamic language. Don't feel bad about it. I believe the problem of JavaScript (that most people hate) is that the standard is weak. All the browsers have their own evil quirks and the syntax has an "optional" feel to it.

If you follow some rules in JavaScript, you can make some gorgeous code with some surprisingly elegant solutions to hard problems.

I think you're only partly right, codist. I get what you're saying about the dynamic languages, but there are application domains in which those languages and their associated tools will simply never take hold (in a mainstream way, anyway). HPC and embedded systems, I think, will rely on statically-typed languages for the foreseeable future. C in particular, but C++ and Fortran to lesser degrees, respectively.

Additionally, I think you'll see C++, Java, and .NET make their way into web applications as well; if nothing else, the dynamic languages will be implemented in the others.

Javascript - well, as Jeff A. <a href="http://www.codinghorror.com/blog/archives/000857.html">said</a>, it's now the "Lingua Franca" of the web. I think there will be more attention given to Javascript implementations both in browsers and otherwise, and desktop applications will increasingly be hosted and served over the web - and that's one of the things all these dynamic languages (i.e., Ruby, Javascript, Python, Lisp) can be really good at.

Why are so many overly critical dinosaurs even reading and commenting on this post? There are a lot of comments here, bashing what was said, with not very educated opinions. You people should look at Ruby, or maybe JRuby, and real javascript (look at what Steve Yegge is doing rather than browser hacks). And if you had read about Scala and Haskell it would have been obvious that these are the languages designed to deal with multiple processors.

There is a lot of obvious ignorance here in the comments here because people aren't keeping up. Put some relevant feeds in your rss reader, or just retire.

While Javascript may have a few nice tricks, I fail to see how it would improve productivity for development of medium to large software projects. It works rather nicely for scripting the browser, but what does it really offer for software development?

People have been trying to implement a sense of OO for Javascript itself, but it was clearly designed to only consume objects made available to it by the environment (in this case the browser). Defining classes in Javascript is awkward at the very least and plain stupid if you'd ask most people.

Ever seen how you must accomplish things like inheritance, private/protected/public members, a true typeof operator, true reflection, namespaces, etc in Javascript? You must implement all those features yourself in code! In fact, it strongly reminds me of how people had to build an object system by hand in C some 20 years ago. Now who's the dinosaur?

>The point is about productivity not multi core support.

I still wouldn't agree with you that Javascript offers better productivity, but that's beside the earlier critique I had on your blog. Didn't you write this? :

"It's the languages that easily support the multi-core, [...] that will ultimately claim victory. [...] dynamic languages like Ruby, Javascript, etc. [...] are the first wave of a future where programming gets more productive."

Maybe it's just an unfortunate writing style, but I think this paragraph gives the reader a very strong impression that you're saying Javascript is easily able (or will be able) to take advantage of multi-cores. Like I pointed out, that's simply not true, nor is there any current development that indicates this will change in the foreseeable future.

Don't get me wrong, I agree that current mainstream languages can't easily use many cores. Functional languages actually have an advantage here by virtue of their "no-side effects" functions; this makes it a lot more easier for a compiler or runtime to automatically schedule parts of a single program for execution on multiple cores.

Javascript is no functional language and has no specific multi-core support. It does has closures though, so maybe that's your connection? It might be interesting for you to learn then that both the "dinosaur" languages C# en Java will be getting closures too in version 3 resp. 7. I think I learned in high-school that one of the reasons dinosaurs are extinct is that at some point in time they weren't able to evolve and adapt anymore. Seems this is not really the case for Java and certainly not for C#.

Yeah, my words were poorly chosen. I plan another stab at this to make more clear the point about productivity.

"And, of course, Ruby itself is written in C."

Exactly.. Now, imagine if that was a specific Ruby engine written to create a multitude of threads?

Without a worry, the Ruby programmer would thus be able to write a script/program harnessing more of the CPUs than a Java,C or C++ programmer would.

I like javascript more myself.

I can't believe some of the responses here that seem to imply (like Ian) that all programming languages are inherently the same, and choosing one or the other has no effect on programmer productivity.

Do you really believe that???

"dynamic languages like _____ and _____ are the first wave of a future where programming gets more productive."

i've been hearing some version of this for 40 years now