Stick to Your Principles

I’ve been using Fortran for a long time, but I’ve only recently started interacting with people trying make changes to the language. It’s been a bit of an eye opening experience. I had intuitions about what it would be like and how things happen in language design, but now I’ve got first hand experience, and I think I understand why Fortran has gotten to be the way it is.

First, a bit of history. Fortran was the first “high-level” language ever developed. It was developed at a time that it was widely believed it wasn’t even possible to write a program that could turn a different syntax and structure into assembly language that would be as efficient as a human could write. The first Fortran compiler proved that it was. This was at a time before terminals, before consistent processor instruction sets, even before hard drives. A giant leap forward and very impressive.

I don’t know when exactly Fortran became design by committee, or which version was the first standard. I’m sure it was before the 1977 standard, and so even by then the language had seen significant changes. Hollerith’s as an intrinsic type had come and gone, to be replaced by the character type. Loops had been introduced. Even goto was starting to lose favor to more structured code with functions and subroutines, if statements, loops, etc.

But even then, there was still a lot of techniques and strategies that hadn’t been invented and language features that couldn’t even be conceived. The 1990 standard introducing free format syntax was a revolution to the language, and the 2003 standard enabling some object oriented techniques was just starting to catch up to newer languages. And even since then, there have been significant changes in programming language theory and design, with functional programming and more powerful type systems gaining popularity.

And so now we have experience from the rest of the software development industry that we can bring to bear on the problems we see in Fortran. Now we know what are some qualities that make a language design good, and why design by committee can lead to poor designs. Language design is hard. It’s nearly impossible to create a language that is both powerful enough and flexible enough for seasoned veterans, and yet easy enough for new developers to pick up and be productive in. Syntax and features are hotly debated topics with no clear winners on any side.

So design by committee tends to lead to what is referred to as a “kitchen sink” language. Every feature wanted by anybody seems to get added to the language because they seem highly desired by at least a few people, but nothing can ever be removed from the language because at least one person will have high value production code that depends on it. The syntax tends to get more and more complicated, trying to deal with all the edge cases to support every feature, and even naming conventions of standard procedures are inconsistent with each other because they were written by different people.

All this isn’t to say that it is impossible to do design by committee. In fact there are examples of languages and projects that I think are doing design by committee well. Rust I think is a good example. But I think there is a very good reason that they are able to do well. They have well thought out and written down goals and principles that they can use as a framework when deciding what proposals to entertain. Keeping things consistent and knowing when not to add things can be just as valuable as having every feature that happens to be the latest fad.

This is why I think Fortran (and any design by committee language) should adopt a “vision” document. It should lay out the things the language values, and in what order they are valued, and some guidelines on judging how trade-offs can be made. For Fortran, my guess at it’s values based on history and experience are as follows.

  1. Backwards compatibility
  2. Run time performance
  3. Minimum compiler writer cost

That’s not to say that these things aren’t important, but they have often come at the cost of developer productivity, consistent syntax, and feature coherence. I think these priorities should be rethought, and I think they should be formalized. If not, I think Fortran has no hope of becoming anything other than an incoherent, “kitchen sink” language. I really hope I can help in making Fortran better.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s