I just want to add two experiences from my past and then 3 general statements and a conclusion.
Experience 1: First is a daemon I wrote. Version 1 was in pure C. Albeit some coworkers asked, why I didn't do it in something like Python or Ruby I said, well because its a daemon running in background, I want it to use as minor memory as possible and take at least system resources. Both languages come with a hugh impact if you need to have them installed just because of this. Also its working at close hands with kernel system services. So C! The configuration used to be in XML. I did classical memory management. And since there were a lot of pointers criss-cross going on, it was just the task needed it. I was on the edge of maintainable in my head to add new functionality without either introducing memleak or crashes due to false freeing.
BUt it was still okay by itself. On another front people kept asking me to add more and more options to XML. With more logic, like when this kinda that. It soon become a kinda strange language itself like <if condition="bla"></if> etc. As this grew, at one moment I said, fuck that. You're going to have version 2 and the new configuration file is going to be some established scripting language. Then you can do all that kind of wired wishes you have by yourself in your config file. I'll just maintain core functionality. After a few days reading up on scripting languages I decided for Lua, albeit i never heared of it before. Fast and very small memory footprint and it was supposed to be easy to integrate in existing systems.
After I've done that, I wondered, I got already the Lua enginge bound and loaded, and I got a lot of complicated logic in the core where memory managent become a burden. So why not move some of the more complicated stuff in the Lua world. This worked out great and at the end I only got that stuff left in C that directly worked with the kernel, child-process, signal and pipe management.
And now for the surprise end. It actually ran faster than my C code! Why? Because my C stuff sucked. The Lua code was using hashtables all the way, everywhere, natively, where I by most of the stuff just bothered with binary searches - if at all and not doing linear searches. Also a lot of double and triple checking around the data could be done away, since the garbage collector took care of it. Yes of course a good coder putting in major effort will always be able to replicate all that in C(++), but an average coder, or someone trying to be efficient in the amount of work done, may get even better results using some scripting language. Also there are garbage collectors for C(++) like gcc uses internally. But they are strange to setup and work a bit weird.
There are some obscure examples where a just in time compiled language is actually faster than C++, since the JIT can use live profile gathering to recompile on the fly, like rearranging then/else clauses on the fly so the pipeline and cache hits better. However as argument in a debate I consider these very artificial, any real life example will not hold true to that. Anyway, to the casually coded stuff, it really can get better, for real.
-
Experience 2: Another experience. C++ stops being funny or efficient when you got that one bug that keeps crashing your application you find impossible to find. At one company I worked at, we had a ton of compile-time of configuration in XML, which needed to be done into other stuff - automatically written code for example. Anyway, I was asked how we should approach that, and I suggested, after a day research, Python back then. I was overruled at the meeting to use C++. Why C++? Compile-time configuration?? Its the one place where speed hardly matters at all. It even can be cached. No, I was told we didn't have any Pythoncoders and people need to learn C++ anyway, since they'll need that for other projects. *Sigh*. A few months later, I was approached again. Hey, you. You got long coding experiences, our compiletime stuff (in C++) keeps crashing, can you take a look at it? Why me? It was I who told you not to use C++ for it. Anyway, job is job and if boss asks you to do something... Took me a good week to find a place, where a rogue pointer overwrote one variable on the previous stack and thus caused a crash when the code was backtracking later on...
-
statement 1: there is an argument that you are only a "real" coder when you went through the pointer shit. I don't know. I won't argue with this, thats kinda subjective. I suppose it depends where you eventually want to end up with. To say on rogue likes, you'll be able to code awesome roguelikes without bothering about pointers ever. If you want to become an expert at computer science, or studying computer science. I think one should have seen pointers at work at least once.
statement 2: I have a serious dislike about people coming up with cool little coding snippets to show how awesome their language of choice is, this includes contests. If you're going to code a project that keeps you more busy than a few weeks than overall structure is way more important, than if you can code this or that task in 1, 3 or 7 lines. In my experience this are also guys and gals who code little snippets, alone, and hardly had ever to bother with maintaining a project over several years and also having to work on a code base with others where understandable structure is getting even more important.
statement 3: I have some vicinity to people doing heavy number crunching for their research. Tell you what. They more often than not keep in Matlab or R. Both very high level scripting languages. Not that they not know how to do it in C(++). Not that it wouldn't run around 10-50 times faster in C(++). But they are going to design and implement some algorithm, test it out, proof their point and publish a paper about that. So when the algorithm runs in 8 hours through the task on their desktop, its enough. Why invest a few weeks of coding - or just days if you're that awesome - to have the same thing run in 30 minutes? After its done it done. And you're going to publish the equations anyway, so if someone is going to put it to practice then s/he can do it.
Concluding. Especially the last arguments is about language "having their place in this world". Yes! I mean I've been now coding for 2 decades in more than a dozens languages. I'm not emotional about any anymore. But for heavens sake, it was not the question of the top poster if language X is has its place! (If he is still reading / caring at all that is).