I often hear people lamenting that C is little better than macro assembler. From a lot of perspectives they are correct. A great example of a powerful macro assembler is High-Level Assembler for the mainframe (mainframe, like OS/360). HLASM has a very long history of having a powerful macro language. Today programming in HLASM is not really so different from programming in C. They have macros for modernized function linkage (including recursion-friendly function calling and run-time dynamic linking) and the language even has built-in support for structs (called "DSECTs").
What's missing from HLASM that's in C? HLASM doesn't have a register allocator -- if your function has more variables than you have registers, you're going to have to be clever. HLASM doesn't have a decent type system (but, well, C's isn't that much better). HLASM isn't portable at all (Switching to Unix? Pay some guy like me dollars per line to convert your code to C). All of these things matter a great deal in our day to day lives, but they don't really change the way we think about programming in an abstract sense. It's still procedural programming close to the hardware.
Yet when you show a smart C programmer XML he yawns, and when you show a smart HLASM programmer XML he thinks of it as totally alien. What's the deal here? For a long time I thought that there was no such thing as a smart HLASM programmer, and I also thought that XML was overblown blah. But then I met a smart HLASM programmer and I realized XML is absolutely awesome because it's just the most popular way to introduce HLASM programmers to things C programmers take for granted.
The difference is a generational difference. Because I am a C programmer, I was introduced to recursion at a very young age. I remember being quite impressed with myself when I wrote my first recursive descent parser in my teenage years. It was for the following syntax:
expr: val + val | val - val | val * val | val / val | val val: number | variable | ( expr )To me this is very simple (like XML), but it wouldn't be if I hadn't been there when I was young. To HLASM programmers, really convenient recursion-capable function calls are just an inefficient novelty. As such, recursive descent parsers are an obscure miracle.
So the question is, what is the next generation of programmers going to be able to take for granted that the current generation of C programmers cannot wrap their mind around? There are lots of possibilities. Object-oriented and functional/descriptive programming come to mind. So why haven't these ideas found footing in some modern language and spawned a generation of programmers who are smarter than us?
Let's address OOP first. I actually did grow up in an OOP world. Of course I used C++ a lot in my youth, but my real OOP exposure comes from C, BASIC, and Java. VisualBasic 3.0 for Windows 3.1 turned me on to the idea that OOP is a good way to organize code for a GUI. Java AWT really made programatic OOP-style definition of a GUI practical for me. Today I use GTK in C for the same end. I'm sure OOP is better for some things other than GUIs, and I've even used it in a lot of other contexts, but I've never really found it to give much of a "killer app" sensation except for GUIs. But I suppose it is fair to say that I can't really imagine someone who wasn't exposed to OOP at a young age ever really "getting" GUI application development. So maybe this is our killer app? Think again. I have not found practicing OOP within a C context to slow me down any. It can sometimes be a little cumbersome, but not compared to by-hand register allocating in HLASM...
So what about functional programming? Well, what about it? It's clear that functional programmers can solve problems in neat ways that the rest of us can't. Not only is it difficult to implement these functional solutions in C, but it's pretty much unheard of for a C programmer to even understand the problem statement. On the other hand, most of the problems they solve are problems they invented. So....no killer app yet.
What's your next great thing?