> Everything looks perfect from far away

As an aid to learning Python I've begun writing a Bomberman clone for which I have an alpha state engine ready for download and prying eyes :-)

The long-term plan is to get it running as an event-based server which can then accept clients from anywhere, including a GUI written in Python that will be cross platform and based upon pygame, a console version for POSIX systems with ncurses, also written in Python, and finally, maybe, an Android client for mobile play. What I want is to allow multiple client types all playing on the same server.

Obviously some of this is quite ambitious for someone who is really still learning, and the goals are fairly up in the air as far as assurance of completion goes. What I do know is that I want to get something ready to play with very soon in order to keep the other half (Jenn) interested in what I'm doing.

Right now I'm reading up on Event Driven Programming in the hopes of learning from the mistakes of others, and to get a stronger grip on the problem at hand. More to come!

For the last week I've been enjoying EuroPython 2010, learning a whole lot of new stuff and having my mind exercised thoroughly with a whole load of things I mostly didn't understand. Still, it was a really good experience and the people were so friendly that I think it would be nearly impossible not to have a good time over there!

I've begun experimenting a bit more with Python and decided to write a Bomberman clone in order to test out some TDD and hopefully soon some event based coding using Monocle and eventually some network based stuff. As I state in the README I want it to be quite flexible as far as portability and client type (console/gui) are concerned.

I've never really done much event based stuff so I'm hoping that Monocle is gentle ;) What really inspired me to try this way Raymond Hettinger's wonderful talk on it, following his equally fantastic talk on Idiomatic Python. It's really great that the Python community has such eloquent and entertaining speakers to inspire me like this!

Colleague:

Not having time to respond myself, here are some musings of an obvious software "engineer" who respects the potential of C++ and quite succinctly explains why there will always be a need for it and why it's often a far better to choose if your tool belt only fits one language.

Wrap-up

This ended the debate as we both had too much work to do to continue, and had already made our points without too much repitition. I'm not going to provide a summary or a conclusion as I can't do so without introducing my bias, so you'll have to make your own mind up whose points chime most with your perspective on the issue.

Me:

I'm not talking about the benefits of non-OO languages; if anything I'm saying that of the OO languages C++ is too complex for its own good and has a minority of appropriate use-cases. There are lots of great OO languages around that don't have these problems. Most programs don't need the speed that C++ can give you, and for OO elegance I personally think there are better options.

I think you have become confused; I'm not heralding any language as the best; I'm saying that where power is needed I'd probably choose C, and where OO is needed I'd choose whatever language seems most appropriate to the job: Java, C#, perhaps Ruby or Python. If I was writing a game I might well choose C++, indeed, I have already made that choice for a Nintendo DS game I don't have any time to write ;-)

There's no point in you trying to win an argument around C++ where Operating Systems are concerned. It's unwinnable. In fact a quick check gives me a glorious fact; Microsoft's rather interesting Singularity OS has its interrupt code written in C and Assembly, and then skips way up the chain to a C# derived language for the rest of the OS. They used the right tools for the right jobs; C/Assembly for the thin core and managed code for the rest. So existing OSs (Windows, Linux, BSD -- and therefore MacOSX) use C, and a cutting edge OS uses a combination of C and managed code.

I don't really understand your perspective on C++ and memory leaks; you seem to think it's a good think that I should have to pay attention to trivialities that have been solved in other languages. I also complain that maintaining C++ code (unless it has severe code guidelines applied) can be more of a pain that other comparable (OO) languages. You're not being egotistical for believing a developer should understand the tools available to him; you're being naive: they don't. You're only being egotistical when you sound like you think you won't make the mistakes that C++ very kindly makes easy for you.

The point about memory leaks isn't that they are avoidable, it's that they're easy to create in the first place. Relying on time consuming processes to mitigate risks that can be avoided using a different language seems like a waste to me. Don't latch onto this as an indication that I'm now crusading against process; I just think that process can be used to find other problems that we haven't already solved in other languages. No point wasting resources on C++ unless it's delivering a crucial benefit -- like in required speed.

I'll let the point about safety critical or realtime systems slide; I don't think there are anywhere near as many such systems written in C++ as there are in C, but I have sufficiently little interest in that area having had to learn Ada that I'm not going to bother researching it further :-P I never once contested the use of OO -- just C++ -- I think you're becoming deluded in your confusion; there is a difference between OO and C++, you know ;-)

I don't think I've strayed; C++ has its place: mostly in making stuff like games run faster, though I believe even there there is a trend to develop minimal engines in such performant languages and drop to Lua or the like for logic and content. In most cases I think that Java or C# will get you what you need with less code and more safety -- basically my view is the inverse of yours: most of the time we don't need performance, we need to get a working application out there (that we can maintain easily in a conventional process); in the very few cases where we do need performance and OO in one place, I think you're right: we need C++.

I don't know what insight your parting comment about PHP is supposed to impart; Facebook's shareholders seem to think it's "worthwhile", after all. Here, again, I hear ego rather than sense.

Colleague:

Your responses confuse me!

On one hand you play the card that C++ is too hard to develop in and maintain and then go straight on to promote the glory of C and basically talk about the benefits of non-OO languages???

C is an absolute nightmare to develop and maintain because it lacks all the benefits to OO coding which is precisely there to provide code reuse, maintainability, scalability and encapsulation. I've had to write device drivers using C and it takes a million lines of code to do anything and is very unreadable and difficult to maintain because of the sheer amount of code needed to read through to get to the point.

Heralding C as the better language because it's faster and has a smaller footprint is obvious, because is it's like half of C++! If you really want you can start writing operating systems in machine code which you can optimise to every single instruction.... if YOU want to then go right ahead. The reason it's used in operating systems is mainly historic because the kernels already existed before OO concepts really hit the ground, some parts of windows are allegedly developed in C++ (ask Microsoft and I'm sure they'll be willing to share). At the end of the day it's all getting compiled to machine code so the difference between C and C++ lies simply in the ease of development and the ability of the optimizer.

As for C++ being unsafe and having memory leaks, these are again at the hands of the developer not automated processes like GC and it's standard practice to provide destructors and call them when an object is being dereferenced. It's not egotistical to believe a developer should fully understand and test his code before it goes live, it's the very least you can ask of an I.T. professional. I'm not infallible but you better hope the system of unit test, system tests, integration tests, capacity volume tests, performance tests and finally user acceptance tests is adequate to catch errors otherwise there is something very wrong with the process.

As for safety critical systems, I believe many projects have been created using C++. I know of one for the Navy that an old lecturer used to work on, which had to use a separate compiler because the Borland one (I think) used one machine instruction that was not in the instruction set deemed acceptable for the solution. Also some very complex systems around are nations intelligence is written in C++ as another lecturer of mine developed something in that area for GCHQ and it was then later employed in some remote voting system. Real time systems are usually developed at a much lower level so the obvious choice is a procedural non-OO language but surely you're not contesting that OO was the way forward for development?

I think we're straying away from the argument here, I was defending C++ against its contemporaries and promoting its benefits over its predecessor. I'm not saying every solution should be written in C++ because some time speed of development is actually more important that a fast reliable system. I like writing in PHP, it's great simple and easy. Would I develop anything worthwhile in it, probably not.

Me:

I'll address the main points:

Safety; you say that C++ is "safer" because it'll "kick you" rather than giving misleading results. As far as I know there is no "safe" version of C++, whereas C has versions such as Cyclone and MISRA-C which is used in safety-critical systems in a similar vein to Ada and C++ isn't used in weapon systems. Back to normal systems though, I don't think even then you can consider C++ to be anywhere near "safe": what about memory leaks? It's easy to create memory leaks in both C and C++, and pretty hard to detect them with seemingly random crashes. Yes, with experience you can avoid these problems, but most people don't have the necessary experience. Which brings me to my next point:

Ego; your assertions that developers are (or should be) competent enough to use the tools, and basically don't need babysitting. What about late nights? What about office distractions? It's hard to stay focused enough to avoid the abundance of pitfalls that you get in languages like C++/C when compared with "safer" or higher level languages I'm advocating. Most crucially though, what about code maintenance? You might be able to tell me that you're completely infallible (and I reserve the right to disagree!) but you can't tell me that the next guy maintaining your code will be. This can be extended to a normal development team; it's so easy to take someone else's code, misunderstand something in there (especially in C++ where there are so many idioms for the same damn thing) and introduce tricky bugs. So any chest beating about C++'s amazing power when used by an amazing programmer such as yourself is just ego over pragmatism.

As for access to the system; uhm, how many OS are written in C++? Popular ones? Thought so. Drivers? C wins again. With C you have something cleaner, smaller and with the same access. Granted, it's pretty messy to try doing OO in C, but given that C predates widespread OO usage and was never meant for OO this doesn't seem to me an omission.

The only real situation where you need that level of access to the system that C++ can give you, ignoring embedded systems (which, let's face it, are more likely to use C anyway), is in writing games. To be fair to you, this is a winning argument for your side: iD's Tech 4 engine made the switch from C (which all the Doom/Quake games used) over to C++ after they'd written the renderer, I believe this is because John Carmack decided that C++ compilers had finally caught up with C in their optimization routines; this is unsubstantiated though.

Now for the addendums (addendi?) don't be dubious; Linus has a long history of that kind of rant. I don't necessarily think he's right, but I'm a lot more inclined to believe someone maintaining an OS kernel of a few million lines of C than someone whose first decision in a reply is to construct a straw man argument...

Colleague:

That article has one single problem with C++; that it's hard to parse so making tools for it are difficult (while openly admitting they haven't tried using the Eclipse IDE for C++)!

Basically saying that the developers aren't competent enough to do it by themselves, I know it's a pain because you have to "know" a lot more than with other languages that basically do everything for you but that's what causes so many software errors: developers using tools they don't fully understand. Where Java will probably let you get away with some errors and give you misleading results C++ will kick you square in the nuts and go tell you to read the user manual properly.

I never said it was easy but C++ is efficient, powerful, logical, safe (if used correctly), gives you direct access to the machine and the OS and overall you explicitly control everything the language is doing, no endless searching for memory leaks because the garbage collection is being a little too relaxed or performance issues because of an overzealous GC.

I was shocked and am a little dubious about Mr Linux's supposed article but this response adequately counters in a far more succinct, less "mad rant" manner.

Introdution

At work I had a bit of a discussion with a colleague about C++ where I expressed an opinion that it is a language made up of too many design ideas that, while powerful, ends up being confusing and hard to maintain. Our discussion moved to email and it is from those original emails that I will create a series of posts, appropriately anonimised, illustrating the discussion.

The first part is from me, being quite antagonistic.

Me:

As promised; this captures most of my concerns around the C++ language. More amusing/inflammatory is Linus Torvalds' opinion.

Personally I don't have a problem with C++, I've used it a little and poked around a bit. I think what bothers me most about it is the way it was built; on top of C. Then add STL. Then add Boost. Now you have lots of ways of doing the same thing, which as far as I can see is only useful to inflate the user's ego when something finally works.

I don't dispute that it's fast or that it can pretty much anything that any other language can do (even closures, nudge nudge), but there is a lot about the design, or lack thereof, of the language that feels uncomfortable.

Disclaimer: I know that Boost isn't a core element of the language, it is however a core element of many C++ projects.

I messed around a little more with my CMS, adding a simple action director and modding apache's config so that the director is called when files are not found, for interpretation and resolution. This means that all 404s (unless specifically excluded by the apache config) are handled through the templating engine. Another reason for doing this was to have an overall try/catch construct to pleasantly display any exceptions that trickle down.

In the background I'm now using CKEditor to make editing posts a bit more pleasant, though of course all of its output is being filtered by my custom routines for security. This should eventually make its way through to comment adding, which I expect I'll implement with OAuth in a similar manner to Stack Overflow have done.

No news yet on the Android front, but the ideas are pilling up!

I'm pretty happy with how the site backend is coming along and will now be shifting my focus to Android development, which was my prime interest in fixing up the site.

Of course, I'll continue fiddling with the style of the site as I see things that niggle!

Having messed with Markdown a little I've decided that it's really not worth the extra language requirement. The text output from this blog is always going to be in HTML so I may as well just write in HTML.

Of course there are some issues with allowing people to post comments in full HTML (when comments are supported) because they can muck around with the flow of the page. I tried alleviating this using strip_tags() but this really didn't help all that much because if I want to exclude inline javascript (e.g. for use in an onclick XSS attack) I'd have to strip all link tags. I wanted higher control over the stripping process so I wrote my own that uses the DOM parser and my own Node classes.

Having tried to switch over to SQLite I've realised that my table aliases are incompatible; they are generated to be of the form "0__0__tablename" and apparently SQLite doesn't support aliases beginning with an integer. Meh.

So, that'll be another issue for my ORM to deal with.

I've also added Markdown to my Blog frontend via Michel Fortin's PHP port, although I've begun to consider writing a "Node"-based version of reStructuredText for PHP driven output, so if I ever get bored and wish to write another text markup parser, that's what I'll be working on!

As part of my ongoing work on a helpful Object Relational Model for PHP, for use in rapid prototyping and speedy development, I've begun a blog application to test it out on.