This should be interesting

| 2 Comments

Richard Hale Shaw is writing some blog entries about moving away from C++ (to .Net). But then he would say that, wouldn't he. His job includes providing courses for people learning .Net... ;)

Anyway, I'm sure it'll be an interesting series of articles, especially given his current views on C++...

I think Richard's being a bit harsh to say that C++ is just a procedural language with an OO retro-fit. Sure, you can write procedural code in C++, but then you can do the same in most OO languages if you try hard enough. In fact, just this morning I commented over on CodeBetter.com on how the new ParameterizedThreadStart() delegate simply encourages procedural code and a lack of abstraction...

I find the digs about Java and C# being C++ without the "routinely unused features" amusing, especially since both languages are now trying to add in support for generic programming (and, from a C++ point of view, both are doing it pretty poorly) and the fact that .Net's object cleanup model actually seems to be MORE complex than C++'s once everyone realised that memory wasn't the only thing that deterministic destruction was good for managing... ;)

I'm especially interested in hearing about the "myth" of C++'s greater power, control and performance. Especially since "the power and control of C++ are a myth, and the features that give you that power and control are..." (hmm, either he's missing an "allegedly" in there somewhere or he's confused himself... ;) )

I, personally, don't tend to find myself debugging at 3am but I've found that it's unit testing rather than language features (or a lack of them) that has been the biggest help in keeping the code doing what it should be doing. I'm also a bit confused as to how those of us who write in C++ could prevent "the rest of us" shipping solutions to customers... In my opinion, programmers can write crap code in any language and sometimes it seems that making a language more accessible to more people just leads to more crap code being written in it, rather than less...

So, anyway, enough of my nitpicking, I'm on the edge of my seat here waiting for the next instalment. Lets hope that once he gets into this Richard can cover why .Net TCP/IP server apps seem to be limited to a small number of concurrent connections...

2 Comments

What i find particularly amusing is that if you do a google search on "memory profiler" almost all links are about Java and .NET.

The only exception being the interesting valgrind leak checker for linux. Interesting becauses it requires no special instrumentation of your program.

Personally, I think that both .Net and Java are pretty useful tools to have in quite a lot of situations and it is harder or impossible to make some of the mistakes that you make in other languages (like C++). BUT, and it's a very big but, they're not always appropriate and just because you cant make the classic C++ mistakes it doesn't mean you cant make a whole raft of new mistakes.

Garbage collection is great when it works and less great if you accidentally create a group of objects that have cyclical references ... The mistake, IMHO, is to think that just because you've hidden pointers away from the programmers, all your memory problems are over. Likewise GC and resource management. It's still an issue and it's still complicated to get right.

Successful programming is about attention to detail. Successful programmers can, usually, work in pretty much any language. Successful programmers usually adopt idioms that make managing the detail a managable problem.

Making a language easier to work with is great but if you don't reduce the amount of detail that the programmer needs to track then it's only superficially easier... A numpty can write bad code in any language and can usually write MORE bad code in an 'easier' language ;)

Leave a comment