Ivan Čukić

dr Ivan Čukić

Author of "Functional Programming in C++", KDE developer and Free/Libre software enthusiast

For inquiries about KDE projects (requesting features, submitting bugs, asking general questions etc.), you can use:

KDE Community Forum
Bug reporting site
#plasma IRC channel

You need to contact me directly?

KDE related:
ivan.cukic [at] kde.org

Non KDE related things:
ivan [at] this domain

IRC Network: libera.chat
Nick: ivan|home
Channel: #plasma

Projects

Blog categories

Functional Programming in C++

If you like C++, you might be interested in my book. It contains quite a few gems of modern C++ programming.

It is available for purchase at:

Patronage

C++ and KDE in CERN

Published by Ivan Čukić in the KDE development section, on 9 March 2016

Some time ago, I saw that CERN people had their own clang tree with a few addons, most notable one being the C++ REPL (C++ interpreter) called cling.

Now we had a presentation by Pere Mato from CERN who talked about their ROOT data analysis framework. It seems like a really nice and powerful piece of software.

The software is around 50 million lines of code, mostly C++. Some of it is python, but it is only used for quick-and-dirty testing of new ideas.

Another cool thing is that they use Qt for writing UIs, and that they also run Linux and KDE Plasma.

Comments:

Matteo Italia
> Now we had a presentation by Pere Mato from CERN who talked about their ROOT data analysis framework. It seems like a really nice and powerful piece of software.

Oh please, is one of the ugliest libraries I have ever had the displeasure to use. It has been initially written by people who knew Fortran and its limitations, and tried to learn C++ and OOP along the way. The result is obviously both a pain to watch and to use.

It sports a confused memory model, a confused *object* model, lots of square wheel reinvention, impossibly large interfaces with great confusion between "real" methods of the objects and devious forwarders to related objects, serious confusion about OOP and consequent absurd class hierarchies (with inheritance used for random reasons), *huge* global state and action at distance, plus lots of crashes if the planets aren't correctly aligned (especially due to the confused memory model above).

Don't get me started on the C++ interpreter. The idea itself is pure madness, but for some reason someone liked it and want on to build "cint", a mostruosity which was able to parse and somewhat execute a badly defined subset of C++, with very little respect for the C++ type system and, again, extremely liberal memory management. I suppose this was done once someone realized that the C++ build/compile/debug cycle doesn't lend itself well to small scale experimentation, but instead of wrapping the algorithms to make them usable from a real scripting language (which they later did with Python), they grew this monster. The sad part of this is that the interpreter encourages extremely sloppy coding style, which is then borrowed to compiled programs with tragical results. Also, the limitations of the interpreter seriously hindered the usage of more advanced C++ techniques in the library interface. Now they are trying a reboot with clang - when will they learn that it's a lost cause, and that the python wrapper is both simpler to implement and maintain and way easier to use than a friggin' C++ interpreter?

But the real problem underlying this mess is that it has never been clear what root is intended to be - it claims to be a library, but is more like a crossover between a C++ library and an interactive environment, thus not doing neither of these tasks with any coherency, and encouraging a deadly mix between GUI state and algorithm state.

What *really* bothers me is that this train wreck is what almost any Italian physics student is exposed to immediately after learning C++ - actually, the diffusion of ROOT at CERN is probably one of the reasons why they teach C++ to physics undergraduates, which in itself would be a bad idea, since C++ is a notoriously bad language to start programming.

The result is that people get used to work with a completely unforgiving language, with horrible libraries and never learn a thing about proper programming, and end up misusing a sledgehammer for every little problem they have to deal with (it's either Excel or ROOT). Sigh, I hope one day numpy/scipy will start to be taught around instead of this pile of shit.
Ivan Čukić
@Matteo

We haven't seen the implementation, but the ideas behind it seemed nice.

I don't agree with your stance on REPL. If it worked properly, it would be quite useful. Or was your comment only regarding cint?

Unfortunately, a lot of 'academia' projects tend to be 'unfinished' to say the least, so I don't find it hard to believe what you said. And due to lack of resources, they are never rewritten/refactorred and become awful beasts. But, in all fairness, this even happens with real-world projects as well. Experimenting is fine, but after the experiment is finished, the code usually needs to be written in a more sane way.

C++ is a bad language to teach programming in, if you are a bad teacher. At least, this is true now with the current C++ standard. All languages have warts, even python and other 'popular' languages.
Goran Vinterhalter
@Ivan

C++ is a bad language for physics freshmen.
Or any other non computer science / engineering affiliations.

From a programmers perspective yes you can object to some inefficiency, no type checking (at least when running the code), a bit weird OO implementation but that's not important. With numpy, matplotlib, scipy, pandas and other packages they can accomplish a lot. NASA uses numpy and python instead of matlab. If it's good enough for them...

Then on master classes you can talk about C++ and extending and building libraries for python or stand alone applications.
Matteo Italia
REPL: my comments are about CInt (the one I actually used), but in my opinion the idea that is flawed is even just with the idea of doing a C++ REPL. Besides introducing significant ambiguities (you are adapting a language thought with a completely different compilation and execution model), you are embarking in a complicated enterprise (writing a C++ compiler is all but trivial) with the result having the dubious value of sharing the verbosity, awkward syntax, undefined behavior and slow compilation times of C++ with the slowness of interpreted code.
Again, for quick experimentation there are lots of way better suited languages that you can use as a glue between calls to your highly-optimized C++ code, and typically the creation of bridge code is way easier than maintaining a C++ interpreter.

Academia: another big problem sadly is lack of competence; take a typical physics department, maybe there are two people who have enough proficiency in C++ to even understand the challenges involved in designing a big library. However there are many people who *dabble* in programming and try to put together stuff that barely compiles just to get their work done. You don't want to have a serious library like this to be designed by people who learned programming in this kind of environment.

C++: nope, languages are not all the same in regards to "learnability".
Warts are one thing, but:
1. there's a problem of quantity; C++ has *lots* of warts accumulated during years of evolution, so there's lots of incongruities to deal with. When you are learning your first programming language you are actually first and foremost learning *programming*, and in this process you want the language not to get in your way, and map in the most logical way the concepts on the implementation. If you put a lot of artificial obstacles on the way of someone who is learning programming you are making things needlessly complicated, and you are confusing matters between what are the *real* problems and what are just artificial cruft.
2. C and C++ have a big honking problem that puts them in a way worse position in respect to most other languages: undefined behavior.
Threading issues aside, in Python or C# or Java or whatever if I get stuff wrong typically I get either an error or, at least, a consistently bad result.
In C++ if I read uninitialized memory today I get a result, tomorrow another one, the day of the demo a segfault, and in production silent corruption of the database. This kills the feedback loop that we as humans are used to have when learning - i.e. getting a clear indication when we are doing wrong -, and allows bad behavior to become ingrained on beginners (of course, especially if they have bad teachers).

Besides, C++ is an *extremely* complicated language; I write C++ since 12 years and have ~65K of rep on StackOverflow mostly in the C++ tag, but there are still corners of the language that surprise me. Most importantly, while the current standard introduced many useful features which really help in everyday programming, it also introduced a *lot* of extra complexity (even just move semantics introduced a lot of subtle rules, changed significantly the rvalue/lvalue semantics, complicated further the madness that is overload resolution and added extra traps for the programmer to fall in).

Also, most abstractions that C++ provides are extremely leaky (http://www.joelonsoftware.com/articles/LeakyAbstractions.html), so you are not excused from understanding how they work internally. Besides, if you have to deal with ROOT you can kiss your modern C++ idioms goodbye anyway, because the provided interfaces are... extremely pre-C++11 to say the least.
Ivan Čukić
@Matteo

As far as I remember, cling uses clang and libtooling, so they are not implementing a c++ compiler. Just using existing tools to simulate a REPL. For me, REPL is a really nice tool that can allow executing something quickly to check what/how it works while writing something. I don't think it belongs to the production environment, I don't think that anyone should write scripted C++ programs, but it does have its place during the development.

I agree that C++ is a complicated language. But you should not teach the whole C++ (not to physics people, not to CS people, not to anyone). C++ has an easily teachable subset. With the new standard, you can use UDLs to define strings, and you can teach that to the students so that they never get the "asd" + "bsd" problem, etc.

> Besides, if you have to deal with ROOT you can kiss your modern C++ idioms goodbye
> anyway, because the provided interfaces are... extremely pre-C++11 to say the least.

This is unfortunate. And unfortunately true for most existing C++ projects...

> You don't want to have a serious library like this to be designed by people who
> learned programming in this kind of environment.

This is a bit of an cop-out - I also wouldn't want people like those writing python libraries, or for any other language for that matter. It seems that we all think C++ is a serious language and that we should allow only serious people to use it, and python is just for quick-and-dirty things, so we can give it to anybody (remoinds me of Basic from the old days).

@Goran

I'm not saying that Python is bad (it is not even relevant to this topic whether I do or do not think it is).

> accomplish a lot. NASA uses numpy and python instead of matlab. If it's good enough for them...

In the same way, I could say CERN uses obsolete C++ techniques with ... If it's good enough for them... It is not really a valid argument. Discussions like these, need more concrete examples - like those provided by Matteo.

p.s. Even python can be thought in a /strange/ way - a few days ago I saw the introductory lesson to python which contained a.append(a) (with a being a list).

p.p.s. Unfortunately, I can't remember where it was, but it was on some respectable university where they decided to teach Haskell as the first language. Haskell is, I'd say, one of the rare languages that can compete with the complexity of C++. And the results were quite positive. You just need to pay attention to what you teach.
Links 13/3/2016: KDE at CERN, FCC Versus FOSS | Techrights
[...] C++ and KDE in CERN [...]

Write a new comment...