Log in

No account? Create an account

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!


( 16 comments — Leave a comment )
May. 28th, 2008 03:49 pm (UTC)
Borland tried to make Delphi on Linux. It was Kylix and was a spectacular failure. The main issue is that the compiler was proprietary.

There are 2 implementation of Pascal in Free Software and at least one of them implement the Delphi extensions to object pascal:

The other seems to be willing to standardize on something:

Having done programming in Modula-2 I can attest that C is sometime very clumsy and too low level and Modula-2 provided a lot of facilities impossible to get with C.
C++ is a different story, but in a lot of cases it is probably not the right tool, despite the fact there is nothing else (ie Java or C# are far too slow / bloat, thanks to the VM). And that's a niche that could full-filled.
May. 28th, 2008 07:49 pm (UTC)
Oh, I know about Kylix (and how it's dead now), but that's not what I said: a libre GCC front-end, contributed back to the FSF and using that in their product (similar to how Xcode uses GCC).

I've used both "popular" free Pascal compilers, back then (find me!). FPK Pascal is kind of wacky, and is suffering from not having enough attention on its back-end (as in "it's not GCC"). It would need to open up and leverage the work of outside experts, I think (maybe use LLVM as a back-end, for example).

GNU Pascal is not too bad, but quite backward, having only very minimal support for Delphi, the most recent thing that's fully supported is Borland Pascal 7.0 (ISO Pascal is a useless joke, a teaching tool at best, nothing like ISO C or C++).

No, I think that in order to get enough traction, it would need to be the Delphi compiler, not a second-up, and only Borland has that power. I'd be very surprised if they did.

Don't underestimate what the VMs can do! Nowadays, the fastest VMs give native code a run for their money, and are even able to do better, in some cases. The biggest problem with both Java and C# is the garbage collection: using it can make some things faster, but you need five or six times as much memory to do the same work (got that from some paper that I can't locate now), so if that makes you dip into the swap, your performance goes down the toilet, but if you don't, it's actually excellent...

One excellent example that is very hard to do without a VM is inlining virtual method calls. Now, combine that with virtual method calls being one of the biggest pervasive overheads in Firefox (thus the so-called "deCOMtamination"!), and you can see how that could be made to go fast!
May. 28th, 2008 08:06 pm (UTC)
Today I'd go with Free Pascal. They also have Lazarus which seem to do the other part. One of their aim is really to be Delphi compatible, but not only.

Free Pascal is also the compiler that saved the old fart Pascal developers on Mac after Metrowerks dropped Pascal support a while back.
May. 28th, 2008 08:18 pm (UTC)
Just not enough weight behind any of the Pascal ones, I'm afraid... Borland has the key to changing that, but they're too afraid to use it.

If someone was totally twisting my arm and forcing me to use Pascal, I'm not sure which one I'd take... A decent Pascal support with Free Pascal, or a decent backend with GNU Pascal? I guess I'd try Free Pascal first, hoping that fast machines will cover up any optimization suckage. ;-)
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. ;-)
May. 29th, 2008 03:56 am (UTC)
hihihi, what i love about you is that with anyone else, this beginning :

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.

would have been the prelude to talking about letting go of being shy, or certain personal habits, or whatever.

But no -- you go right on to talk about pascal programming. this made me laugh so much!!!! :-)
May. 29th, 2008 01:54 pm (UTC)
Well, it's not like I've ever been a staunch supporter of being shy!
May. 30th, 2008 04:40 am (UTC)
Ou c'qui a de la gene, y'a pas de plaisir!
May. 30th, 2008 02:03 pm (UTC)
( 16 comments — Leave a comment )