In my early 90’s, I was mostly programming in Fortran for my PhD. I learned C as a side-project, and it was one of the best decisions I ever made. Not that there is anything “wrong” with Fortran, only that the job market widened for me as a result.
In the late 90’s I was mostly programming in C, although I also did some C++ and Java. I discovered Perl on the PC, and I did not like it. It seemed that one had to do a lot of compilation, and I never properly figured out what all those sigils meant. Then I discovered Python, and it quickly became my go to language for personal projects.
I had a variety of beefs with C++. One problem was where I had an array of file readers. There were different reader classes for different file format types. So the readers were polymorphic. That’s good, except you can’t have an array of polymorphic types, which completely undermined the simplicity of my solution.
There were other problems, including having to increase the stack size to get the project to compile. I was suspicious of that, but it seemed to get the job done.
At another company I worked for, there was an arrogant, but atrocious, lead programmer who obviously went to the Cut’n’Paste School of Programming. The code base was a shocking mess, so I guess that further soured my opinion in C++.
I had also inspected a couple of other code bases in the 2000’s, and found some fairly nasty looking code. Object-orientation seems to be a siren song which draws in programmers like sailors to rocks. You end up with a lot of flotsam. It’s not that object-oriented code is necessarily bad, it’s just that programmers cannot seem to help not making a mess of their code.
I also learned a lot of other languages in the 2000’s, including Lisp, Scheme, Forth (yuk!), some Haskell, Ocaml, Rust, and a few others which I forget.
I found Haskell to be an amazing language. Although I found it more difficult to formulate code initially, I also found that it was much easier to reason about the code afterwards. You will never write more maintainable (and correct) code than when writing Haskell.
I have a few beefs with Haskell, though. It mainly revolves around packaging. There’s the Haskell Platform, which a lot of people seem to say to avoid. There’s Cabal, which seems to sometimes conflict with some of the internal libraries of Platform.
Then there’s Stack, which seems to tout itself as The Final Solution. When I have used Stack, it often seems to want to download a Haskell compiler. I am completely confused. I already have a Haskell compiler. Just use that! Surely I’m not expected to download a compiler for each project I create.
So Haskell the ecosystem can be like a jigsaw sometimes. Lots of pieces, and it’s often difficult to see how they are supposed to fit together. I suspect many of them don’t.
Now back to C++. In my latest experiments, I have tended to adopt the C mindset, where there are many issues as to who owns what resource, has it been allocated, is it duplicated or shared, has it been deallocated, is a reference dangling? I find myself worrying about that in C++ where I would worry less in C. C does so little for you that it’s usually clear what to do: everything is YOUR problem, so you have to deal with it. With C++, it seems that things are going on behind your back, so it’s never really clear what is my responsibility. Can I return objects? Does it blow up the stack? Am I returning a copy, or a free’d object created on the stack?
It seems that C++ has come a long way since I last used it, and I am perhaps worrying too much. I saw a very interesting Youtube video by Bjarne Stroustrup (https://www.youtube.com/watch?v=1OEu9C51K2A). It’s an area that he looks keen to address.
He is trying to move towards the goal of allowing people to create correct code, even for people like me who are relatively new to it. It’s easy to become overwhelmed by all the features of C++, including such things as auto, shared_ptr and all their friends. It’s very difficult to be confused as to their rationale. Some features also look deprecated.
Help is at hand. Microsoft have a project on Github: (https://github.com/Microsoft/GSL) GSL (Guidelines Support Library) which is a style guide tool. It is geared towards writing correct code, rather than formatting conventions. It is like a “lint” for C++. It is not exclusively a Microsoft project. Stroustrup contributes too it, as do JP Morgan (?) and a few other institutions. It is very much meant to be an open project, and apparently welcomes patches from others.
In the video, Stroustrup also talked about ownership models. Maybe it’s a feature that could obsolete Rust.
So, despite my reservations and earlier scepticism of C++, I think there are beginning to be real reasons to use it. I found that the C++ program I wrote recently was reasonably high level, and really getting up there with Python. That’s quite an achievement.
My C++ program also used a few “gotos”. I wish more languages supported them. Now, I know what you’re all thinking: “A witch! A witch! We have found a witch. May we burn her?”.
But there’s nothing wrong with a judicious use of gotos. I used them in a hand-rolled parser. Gotos are a natural mechanism for handling state transition. The parsing was straightforward. I like messing around with lexers and parser generators at least as much as the next guy, but sometimes it is better to adopt a simple solution to a simple problem.
In conclusion, I am finding that C++ has a place in my programming armoury. C++ compilers are ubiquitous, and have the advantage of not requiring a lot of infrastructure like you would need with high-level languages. The experiment continues.