Which programming language should I learn?

[OwlHoot]

As for the comment someone made about PHP ...yes it is massively popular and that does attract me to it. However, last time I looked, PHP wasn't owned or controlled by Microsoft, which is a big plus point for me. ...

An open source skill can become obsolete too. For example, I spent a long time mugging up and practicing on Dojo, and got a contract on the strength of that; but everyone seems to be using JQuery these days, and sadly Dojo seems to be fading away practically to insignificance.

[VectraMan]

I think the key thing to look at is programmer productivity. My personal take is that by leaving out little used features that over complicate things and removing the need to perform memory allocation housekeeping C# and Java offer a massive improvement in programmer productivity and make it easier to write correct code that is less prone to a lot of common security issues.

I agree with you on the first point, but I don't think I'm at any productivity disadvantage using C++ (though I have to admit C++ generally involves more key presses, and MS's attempts and C++ intellisense are still only 50/50 at best). However strong types do improve productivity by finding the errors at compile time, and const correctness is a major part of that, and certainly not little used. I found it a big problem when doing C#, because I was so used to working that way. A bit like somebody taking away private and protected members and saying it doesn't really matter as it's a little used language feature and productivity is better if you can access everything willy nilly.

In modern C++, memory allocation and housekeeping isn't something the programmer does often. In fact you work pretty much the same way as a C#'er or Java'ist would. Inevitably a lot of C++ detractors have a hopelessly outdated idea of what C++ is like, and think it's all casting void* pointers and static fixed sized memory buffers with no overrun checks.

the frameworks offer huge wedges of common functionality in a standard way

Which is not the language. As we've said elsewhere, I often do C++ .NET and have full access to the same frameworks in C++.

I also think the performance argument is a bit spurious these days, I used to believe this myself but a friend of mine (who at the time was dev team leader on a derivatives pricing system that run on one of the supercomputers that appears as "financial institution" in the top500 list i.e. fairly performance critical code) pointed out that a modern JIT compiler will compile to native code that is just as fast and has potential for making runtime optimisations that a static compiler doesn't, so can actually come out ahead. They had actually measured this, although obviously this is a fairly extreme server side example where there isn't any interaction with the desktop and so on.

What exactly are the runtime optimisations that a static compiler can't do? If anything you'd have to say a static compiler has much more time to do a better job of optimisation.

The point is about the level of control. HTML5 ists will claim that JS too has native code performance, because it's JIT innit, but fundamentally, the general case can never be as good as a specialised one, and C++ means you have much more control in order to get that last 1%.

[VectraMan]

Look what happened with VB ...it got replaced with VB.Net, which isn't so bad, except that they also released C# which then drew a lot of people away who otherwise probably would have learned VB.Net.

My C# experience is in Winforms, which nobody uses anymore. So it's the same thing, but it's not the language that's become obsolete but the platform, and my C# skills and .NET knowledge are transferable to whatever the latest API MS have come up with (I've lost track a little).

[doodab]

What exactly are the runtime optimisations that a static compiler can't do? If anything you'd have to say a static compiler has much more time to do a better job of optimisation.

Well, don't forget that C#, Java (or C++.NEt) has a static compile phase that has just as much time to do all of the optimisations that any other static compiler can. At runtime the JIT can additionally take advantage of machine specific optimisations and use live profiling data to perform automatic inlining, trade speed for size and so on. You might be able to do that during a static compile but it requires multiple compilation & profiling cycles and the final executable is only going to give optimum results on the specific hardware it's tuned for. I think the runtime also has some advantages when it comes to inlining because it has access to type information that the static compiler doesn't.

[d000hg]

@VM: a very experienced C++ guy will doubtless be more productive in C++ than some new language. It's not really a fair comparison.

[Sysman]

But if we're talking languages, to pick two examples Java and C# left out multiple inheritance, and (somewhat incomprehensibly) left out const correctness.

Dumbing down in response to "We can't find the staff"?

These are advanced features that the authors of the language either didn't understand themselves, or felt that their target audience weren't capable of understanding. And of course garbage collection is just a way of making programming easier for people that can't handle the concept of memory allocation. This is why C++ programmers like to look down on Java/C#'ers; no matter how you look at it to be a good C++ programmer requires a greater degree of technical understanding and ability.

Snobbery and elitism play their part. Not much different from the transition from assembler to HLLs.

OTOH it has to be said that the C++ world often turns into "look at me aren't I clever" programming, rather than just getting on with the job.

I stumbled into that on a forum once upon a time. For most commercial development, maintainability should be a greater priority.

[minestrone]

This is a 'hello world' thread gone wrong.

[d000hg]

But if we're talking languages, to pick two examples Java and C# left out multiple inheritance, and (somewhat incomprehensibly) left out const correctness. These are advanced features that the authors of the language either didn't understand themselves, or felt that their target audience weren't capable of understanding

MI is left out because it's widely regarded as a bad idea, most C++ people dislike it and often it's banned. The exception being for interface classes... note that Java/C# allow implementing multiple interfaces so it's not quite as simple as "C++ has MI, Java doesn't".

And of course garbage collection is just a way of making programming easier for people that can't handle the concept of memory allocation. This is why C++ programmers like to look down on Java/C#'ers;

No it isn't, no they don't. Not the good ones anyway. GC is for people that don't want to be bothered with memory allocation when there isn't a need to, which is most of us. Not to mention even in C++ it's considered bad habits to use new/delete rather than STL/boost except in special cases, so manual memory allocation isn't used in day-to-day C++ coding anyway. And C++ coders who look down on other languages are typically just jerks, often ignorant and trotting out lines like "Java is slow because it's interpreted". I'm a C++ coder so pointers and all that stuff are 2nd-nature to me, but I enjoy using Java/C# when I can because it's less things to add bugs... and the best C++ coder in the world still risks introducing bugs by forgetting to delete memory, sometimes.

[minestrone]

MI is wrong on so many levels.

[NickFitz]

I came across an old notebook (the paper kind) of mine yesterday, sitting in a box of stuff. The first page was full of uncommented 8086 assembly language written in ballpoint pen.

After a couple of seconds of gazing at it, I realised it was a first draft of the core routine ("next") of an indirect-threaded implementation of Forth that I never actually got around to implementing (although I did on the 68000).

Anyway, what was it somebody was saying about high-level language A being cooler than high-level language B because A involved knowing more about the nitty-gritty of memory allocation than B? I lost track of the discussion as I was busy remembering the reasons for my register allocations in that bit of code I wrote in the pub around 1988 but never bothered using