IBM and Red Hat Linux

The news that IBM had an agreement to purchase Red Hat (the distributor and supporter of a Linux distro for commercial use) was followed quickly by a series of comments from the tech world, ranging from anger to disappointment.

I'm not sure that the purchase of Red Hat by IBM is a bad thing.

One can view this event in the form of two questions. The first is "Should Red Hat sell itself (to anyone)?". The second is "Given that Red Hat is for sale, who would be a good purchaser?".

The negative reaction, I think, is mostly about the first question. People are disappointed (or angered) by the sale of Red Had -- to anyone.

But once you commit to a sale, the question changes and the focus is on the buyer. Who are possible buyers for Red Hat?

IBM is, of course, a possibility. Many people might object to IBM, and if we think of the IBM from its monopoly days and its arrogance and incompatible hardware designs, then IBM would be a poor choice. (Red Hat would also be a poor acquisition for that IBM, too.)

But IBM has changed quite a bit. It still sells mainframes; its S/36 line has mutated into servers, and it has sold (long ago) its PC business. It must compete in the cloud arena with Amazon.com, Microsoft, and Google (and Dell, and Oracle, and others). Red Hat helps IBM in this area. I think IBM is not so foolish as to break Red Hat or make many changes.

One possibility is that IBM purchased Red Hat to prevent others from doing so. (You buy something because you need it or because you want to keep it from others.) Who are the others?

Amazon.com and Microsoft come quickly to mind. They both offer cloud services, and Red Hat would help both with their offerings. The complainers may consider this; would they prefer Red Hat to go to Amazon or Microsoft? (Of the two, I think Microsoft would be the better owner. It is expanding its role with Linux and moving its business away from Windows and Windows-only software to a larger market of cloud services that support both Windows and Linux.)

There are other possible purchasers. Oracle has been mentioned by critics (usually as a "could be worse, could be Oracle" comment). Red Hat fills a gap in Oracle's product line between hardware and its database software, and also provides a platform for Java (another Oracle property).

Beyond those, there are Facebook, Dell, and possibly Intel, although I consider the last to be a long shot. None of them strike me as a good partner.

Red Hat could be purchased by an equity/investment company, which would probably doom Red Hat to partitioning and sales of individual components.

In the end, IBM seems quite a reasonable purchaser. IBM has changed from its old ways and it supports Linux quite a bit. I think it will recognize value and strive to keep it. Let's see what happens.

It won't be Eiffel

Bertrand Meyers has made the case, repeatedly, for design-by-contract as a way to improve the quality of computer programs. He has been doing so for the better part of two decades, and perhaps longer.

Design-by-contract is a notion that uses preconditions, postconditions, and invariants in object-oriented programs. Each is a form of an assertion, a test that is performed at a specific time. (Preconditions are performed prior to a function, postconditions after, etc.)

Design-by-contract is a way of ensuring that programs are correct. It adds rigor to programs, and  requires careful analysis and thought in the design of software. (Much like structured programming required analysis and thought for the design of software.)

I think it has a good chance of being accepted as a standard programming practice. It follows the improvements we have seen in programming languages: Bounds checking of indexes for arrays, function signatures, and type checking rules for casting from one type to another.

Someone will create a language that uses the design-by-contract concepts, and the language will gain popularity. Perhaps because of the vendor (Microsoft? Google?) or perhaps through grass-roots acceptance (a la Python).

There already is a language that implements design-by-contract: Eiffel, Meyers' pet language. It is available today, even for Linux, so developers can experiment with it. Yet it has little interest. The Eiffel language does not appear on the Tiobe index (at least not for September 2018) at all -- not only not in the top 20, but not in the top 100. (It may be lurking somewhere below that.)

So while I think that design-by-contract may succeed in the future, I also think that Eiffel has missed its opportunity. It hasn't been accepted by any of the big vendors (Microsoft, Oracle, Google, Apple) and its popularity remains low.

I think that another language may pick up the notion of preconditions and postconditions. The term "Design by contract" is trademarked by Meyers, so it is doubtful that another language will use it. But the term is not important -- it is the assertions that bring the rigor to programming. These are useful, and eventually will be found valuable by the development community.

At that point, multiple languages will support preconditions and postconditions. There will be new languages with the feature, and adaptations of existing languages (C++, Java, C#, and others) that sport preconditions and postconditions. So Bertrand Meyer will have "won" in the sense that his ideas were adopted.

But Eiffel, the language, will be left out.

C without the preprocessor

The C and C++ languages lack one utility that is found in many other languages: a package manager. Will they ever have one?

The biggest challenge to a package manager for C or C++ is not the package manager. We know how to build them, how to manage them, and how to maintain a community that uses them. Perl, Python, and Ruby have package managers. Java has one (sort of). C# has one. JavaScript has several! Why not C and C++?

The issue isn't in the C and C++ languages. Instead the issue is in the preprocessor, an external utility that modifies C or C++ code before the compiler does its work.

The problem with the preprocessor is that it can change just about any token in the code to something else, including statements which would be used by package managers. The preprocessor can change "do_this" to "do_that" or change "true" to "TRUE" or change "BEGIN" to "{".

The idea of a package manager for C and C++ has been discussed, and someone (I forget the person now) listed a number of questions that the preprocessor raises for a package manager. I won't repeat the list here, but they were very good questions.

To me, it seems that a package manager and a preprocessor are incompatible. If you have one, you cannot have the other. (At least, not with any degree of consistency.)

So I started thinking... what if we eliminate the C/C++ preprocessor? How would that change the languages?

Let's look at what the preprocessor does for us.

For starters, it is the mechanism to include headers in programs. The "#include" lines are handled by the preprocessor, not the compiler. (When C was first designed, a preprocessor was considered a "win", as it separated some tasks from the compiler and followed the Unix philosophy of separation of duties.) We still need a way to include definitions of constants, functions, structures, and classes, so we need a replacement for the #include command.

A side note: C and C++ standard wonks will know that it is not required that the preprocessor and not the compiler handle "#include" lines. The standards dictate that after certain lines (such as #include "string") the compiler must exhibit certain behaviors. But this bit of arcane knowledge is not important to the general idea of elminating the preprocessor.

The preprocessor allows for conditional compilation. It allows for "#if/#else/#endif" blocks that can be conditionally compiled, based on what follows the "#if". Conditional compilation is extremely useful on software that has multiple targets, such as the Linux kernel (which targets many different processors).

The preprocessor also allows for macros and substitution of values. It accepts a "#define" line which can change any token into something else. This mechanism was used for the "max()" and "min()" functions.

All of that would be lost with the elimination of the preprocessor. As all of those features are used on many projects, they would all have to be replaced by some form of extension to the compiler. The compiler would have to read the included files, and would have to compile (or not compile) conditionally-marked code.

Such a change is possible, but not easy. It would probably break a lot of existing code -- perhaps all nontrivial C and C++ programs.

Which means that removing the preprocessor from C and C++ and replacing it with something else is a change to the language that makes C and C++ no longer C and C++. Removing the preprocessor changes the languages. They are no longer C and C++, but different languages, and deserving of different names.

So in once sense you can remove the preprocessor from C and C++, but in another sense you cannot.