C++14: A different view on a couple of issues

I'm back from the C++ meeting and Bristol. And the great news as you probably may know is that we will be issuing a new CD (Committee Draft) for a new version of the C++ standard. That is we hope to have something called C++14.

We have had a huge success in terms of participation in the standard meeting with one hundred people working during a six days week starting at 8:30 and with after-dinner evening sessions. Really impressive work from many people. For further information on the C++ Committe you can get a lot of useful information at isocpp.org.

Other committe members write excellent reports on every meeting, and I always recommend to read the really good trip reports from Herb Sutter. Here you have the latest one.

So I thought I could right a different view on a couple of tiny details. I will give my very personal view on two issues one that got accepted (generic lambdas) and one that got rejected (digit separators).

Concepts lite and generic lambdas

The committee decided that concepts lite required to be in a separate Technical Specification (TS) and not in the standard to give opportunity for fruther experimentation. I tend to agree with this view, although there is a working implementation.

However, the committe decided to put generic lambdas in the International Standard for C++14. I like generic lambdas a lot. They are great! I have already felt the need of generic lambdas in some of my current implementations. But I feel that the safest path would be to put them in the same TS than concepts lite.

Although I know it is unlikely, it could happen that later in the process we could find that we wanted a tighter integration of generic lambdas and concepts. I hope we do not regret of our dicision here. I agree that the risk is low, but it is still a risk.

Moreover, I think that having generic lambdas in a TS rather than in the IS, would be the safest path, and implementors still may deliver their products with TS implementations.

The recurring digit separators discussion

We discussed a lot of options about digit separators. The idea behind is to make easier writing long numeric literals so that they are more readable and code is easier to maintain.

Today if you want to use the speed of light in your code you do something like:

constexpr double speed_of_light = 299792458;

With the digit separator proposal that could be written:

constexpr double speed_of_light = 299_792_458;

Unfortunately this proposal did not pass, because there was an argument about its interaction with UDL (user defined literals). The case that arised during the discussion was:

x = 0xFF_EB; // 255 Exabytes or 0xFFEB?

I do not think that writing Exabytes in hexadecimal is so common to justify not making a service to user communities that use long literal numeric constants. But I may be wrong.

The harms of Java

I have always considered a tremendous error using Java as first language for teaching programming to Computer Science and Engineering students at University. I have a bunch of reasons for this. How
ever, many schools do it, including my own University.

Some day I may write something about this, but I am afraid that I would need more space than a plain blog post.

I have used Java in industrial projects. The most common reason has been customer requirement to do so. In those cases I have always warned customers of the dangers of such a decision.

Today I was thinking a little bit about the latest Java vulenrability and how Oracle has been managing it. I was reading this post from CERT at Carnegie Mellon reccomending to disable java from your browser now.

This has brought to my mind two principles that I think are very important when making a selection on a language. Both can be mainly summarized in: "Always try to avoid single way of thinking".

Prefer standardized programming languages

I think that standardized programming languages should be preferred over others. Specifically I am thinking in programming languages with an International Standard. The reason behind is openness.

Many argue that design by committe is not the best way of designing a language. I may partially buy that argument. However, I think is much better, that the model where a single company designs a programming language and makes changes (sometimes incompatible changes) when they want. 

At least, any specification going through a standardization process involves industry providing the technology (i.e. compiler providers), academics and end users. It is true that sometimes some group may be underrepresented in a standards committee, but there are clear rules on how to become a member of a committee.

Anybody can implement an environment for a standard programming languages. Just have a look on the number of different implementations for languages like C, C++, Ada, COBOL or FORTRAN. However, in the recent years we have seen lawsuits about who has what right with a language owned by a company.

Prefer compiled languages over virtual machine based languages

My usual argument for preferring truly compiled languages has always been performance. I know. Not everybody is concerned about performance but I am.

However, security and safety emerge as another strong reason. We have seen how recent updates on Java Virtual Machines have made that usable applications have become unsecure applications without any intervention of the developer. This has brouth the new acrony WOBE (Write Once Break Everywhere) as opposed to the promised WORE (Write Once Run Everywhere).

In contrast, with a truly compiled application where you deploy binaries, it is much more difficult that such a thing happens. I will not say impossible, because "impossible is nothing". But at least, very difficult.

Is there room for Java-like languages?

Sure there it is. Java has proven to be excellent in combination with application servers. You can get cheap programmers to do so. Hey. Wait a minute! That is true as long as you are not concerned with energy efficiency. Surely this has a huge environment impact for data centers and for the life of your battery.

Then what. Well, I really don't know.

NOTICE: I am happy to get comments for this posts. However I will remove any comment that I consider offensive or is not supported by some sort of reasoning.