Sign In

Communications of the ACM


My Compiler Does Not Understand Me

man on couch talking to analyst


Until our programming languages catch up, code will be full of horrors.

The full text of this article is premium content


Tom Tervoort

You discuss some problems with "today's programming languages", but most of them are aimed directly at C, which is 30 years old. The problem with integer sizes, for example, is not present at all in most other languages that are popular by now.

While you do mention Ada as an example of how a certain problem is solved in the right manner, you don't explain why we just shouldn't all use Ada if we want our compilers to understand us.

Of course more modern languages like Java, Ruby, D or Haskell are still far from perfect; but I would've liked to see what should be improved about these kinds of languages in order to come closer to the ideal described as intentional programming, rather than what is wrong with the very old language C.

Poul-Henning Kamp

Compilers used to be constrained programs, they would soak up all machine resources just to generate code, and therefore languages have traditionally been low on redundancy and information which didn't affect code generation found no place in the syntax.

Not that the extra analysis was not found valuable, but it simply had to be in a separate program, like lint(1), because the compiler was too big and slow already.

Today compilers can do so much more, given all the CPU power and memory available, and many compilers routinely perform a lot of analysis not strictly needed for code generation, simply because they can.

For instance printf(3) format-string/argument type checking is totally unnecessary for code-generation, but it has closed more security holes than is comfortable to think about, by analyzing 'surplus' information from the programmer, to figure out if intent and source code matches.

The next natural task to hand the compiler, is to scrutinize source code for conflicts between intention and source code, but it can only do that, if the language supports passing in more information about intent.

Interestingly, lint(1) did analyse receive extra-syntactical information, for instance /*FALL-THROUGH*/ comments to divine programmer intent. It would have been much better to add "fall_though" as C keyword, (Python calls it "pass") even if the compiler just ignored it.

I used asserts as the vehicle for my message because I have yet to see any compiler, for any language, tell me "The assert in line 123 can trigger under these conditions ..." even if it knows.

Displaying all 2 comments

Log in to Read the Full Article

Sign In

Sign in using your ACM Web Account username and password to access premium content if you are an ACM member, Communications subscriber or Digital Library subscriber.

Need Access?

Please select one of the options below for access to premium content and features.

Create a Web Account

If you are already an ACM member, Communications subscriber, or Digital Library subscriber, please set up a web account to access premium content on this site.

Join the ACM

Become a member to take full advantage of ACM's outstanding computing information resources, networking opportunities, and other benefits.

Subscribe to Communications of the ACM Magazine

Get full access to 50+ years of CACM content and receive the print version of the magazine monthly.

Purchase the Article

Non-members can purchase this article or a copy of the magazine in which it appears.