Log in

Previous Entry | Next Entry

Moving On

Reg Braithwaite was writing not long ago about how we can be the biggest obstacle to our own growth. It made me realize how I've dropped things that I was once a staunch supporter of.

I was once a Borland Pascal programmer, and I believed that it was better than C or even C++. I believed that the flexibility of runtime typing would win over the static typing of C++ templates, as computers got faster. I belived that RPC were a great idea, and even worked on an RPC system that would work over dial-up connections (because that's what I had back then). I put in a lot of time working on object persistence and databases. I thought that exceptions were fundamentally bad. I believed that threads were bad, and that event-driven was the way to go.

Now, I believe in message-passing and in letting the OS kernel manage concurrency (but I don't necessarily believe in threads, it's just what I happen to need in order to get efficient message-passing inside a concurrent application that lets the kernel do its work). I wonder when that will become wrong? And what is going to become right?

I like to think I had some vision, occasionally. For example, I once worked on an email processing system for FidoNet (thanks to Tom Jennings, a beacon of awesome!), and my friends called me a nutjob when I told them that I was designing the thing so that it was possible to send messages larger than two gigabytes. What I believed was that we'd get fantastic bandwidth someday where messages this large were feasible (we did! but that was an easy call), and that you'd be able to subscribe to television shows for some small sum, where they would send it to you by email and you'd watch it to your convenience. That's never gonna happen, they said! Ha! HTTP (which I think is used in the iTunes Store) uses the very same chunked encoding that I put in my design back then...

Note that in some cases, I was partly right, but the world changed, and what was right became wrong. For example, the 32-bit variant of Borland Pascal, Delphi, is actually a pretty nice language (ask apenwarr!), and while it isn't going to beat C++ in system programming, like I believed it could, it's giving it a really hard time in Windows application programming, and that level of success despite being an almost entirely proprietary platform is quite amazing. Even Microsoft is buckling under the reality that openness is good for language platforms, trying to have as many people from the outside contributing to .NET (another thing to note: C# was mainly designed by some of the Delphi designers). Imagine what could happen if Borland came to its sense and spat out a Delphi GCC front-end (and use it in their products, making it "the real one", not some afterthought)?

I doubt that's going to happen, though. For application development, I think it's more likely that "scripting languages" like Ruby, Python and JavaScript are going to reach up and take this away from insanely annoying compiled languages like C++ (and maybe even Java).

But hey, what do I know? I once thought RPC was going to be the future!


May. 28th, 2008 04:19 pm (UTC)
Soooo... should I be worried that (at work) I'm stuck with an API that forces us to use plain C and with tech leads that insist that RPC is a good thing? ;)

For frontends in the future I'm rooting for scripts since they're often less bulky to work with than full-fledged, compiled programs and only very few GUIs require hand-optimized GPU assembler code to give the user a satisfactory experience. When that's said, though, I have to mention that I somehow can't see large companies delivering their applications as scripts that the user can see. I'd like to see it happening, but just don't think it will.
May. 28th, 2008 08:04 pm (UTC)
C is dying, IMHO, especially as C++ is almost perfectly a superset (there's a few things that you might still need C for if you're doing something like XIP on some embedded platform, but the next version of C++ should fix this and make it entirely redundant).

If you count web applications, JavaScript is quite big, and the server-side is often scripted as well. There are things like PyPy for Python, and some applications either have big chunks of scripting that you don't really see (big games are a notable example). The client that BitTorrent.com makes is all Python, if I'm not mistaken, and it's pretty hard to tell.
May. 28th, 2008 08:07 pm (UTC)
C is dying? Tell that to the GNOME people.....

May. 28th, 2008 08:15 pm (UTC)
I'm not claiming people are reasonable!

What I am claiming, though, is this: if you take a non-trivial C application, rename all the .c to .cc, fix the incompatibilities (if any, things like variables named "class", for example, but by design, there should be very few), and you'll have a ton of warnings that are helpful and will make the program better.

That strategy alone made me look like a genius on a few occasions at the job I had in France, getting me a few "how did you catch that?!?" puzzled looks (oh, the subtlety of confusing two enums of differing types!). ;-)

And the GNOME people are often seen gasping at straws, with things like Python and Mono. I think there's quite a few of their people who know it too, deep down...
May. 28th, 2008 09:07 pm (UTC)
For embedded platforms there will always be occasions where some (time critical) applications will require specialised solutions. A while back seriously had to (ab)use the gcc for Atmel's AVR microcontrollers to be able to squeeeeze some code down to less than 30-something clock cycles. It would have been better to just do it directly in assembler... if you disregard the fact that my assembler experience is quite limited.

As for having to stick to C, well, for now that depends on whether OpenTV will make a C++ compiler for their API or not. Since their C compiler is based on gcc it should be possible to do a C++ compiler as well if you don't mind going into a friggin' horrible mess of legal entanglement :(

Have you ever looked at EVE Online? They use stackless Python for their backend. Not sure what they use for their frontend.
May. 28th, 2008 09:48 pm (UTC)
For those time critical applications you talk about, usually the C++ compiler will compile the C code to just about the same as the C compiler would have done. What people often forget is that it's not because you're in C++ that you suddenly have to start using classes, templates and exceptions (although if I don't have to implement another bloody linked list in my life, that'd be fine by me!). C++ is very much "pay for what you use", so if you don't use a feature, you don't pay for it.

If your platform doesn't have a C++ compiler, well, that's pretty sad, I suppose. Hmm, their source code is available, due to GCC being GPL... I wonder how hard it would be to wire their code generator to a more capable GCC (consider that GCC translates code to an intermediate language, and that adding targets is separate from adding front-ends)...

Stackless Python is pretty damned sweet, that's for sure. :-)
May. 28th, 2008 10:27 pm (UTC)
The thing with OpenTV is that while we develop for their middleware we're actually competitors so there's no way we can do anything that risks. We just got out of a $1 billion damage claim from someone else and while I wouldn't want the suits in Legal to get bored I can think of better things to occupy them with than another law suit... okay, actually I can't. Guess they'll just have to get bored ;)

I've never looked more than a little at Stackless but wouldn't mind finding an excuse for spending some time looking at it.
May. 28th, 2008 10:52 pm (UTC)
Well, really, if the compiler's under the GPL... But hey, you probably have better things to do with your time than splice in a backend for their wacky platform into a more sensible compiler. ;-)