Summary
A lot of programmers have preconceptions about C++, and very fixed ideas about what can and should be done with it. I plan on shaking this up a bit with an upcoming column called Agile C++, as well as through my work on the Object Oriented Template Library.
Advertisement
At the behest of one of my colleagues, I wanted to outline my short and long term plans with regards to the OOTL (Object Oriented Template Library), and an upcoming column on C++ called Agile C++.
It seems that almost every programmer has a set of opinions on C++, and on what can and should be done with it. Most of it is superstitious nonsense. This is almost as true for experienced C++ programmers as for people who have never tried using the language at all. It is my goal to shatter some of the misconceptions.
People unfamiliar with C++ get the impression that it has to be obfuscated but that is an entirely artificial problem, which I think is mainly due to teachings by popular C++ gurus. I commonly see many problems with C++ code: overuse of the generic programming at the highest level of abstraction, avoidance of traditional OOP techniques, designs which do not reflect the problem domain, insufficient use of abstraction, designs which are too loosely coupled, and the list goes on. You can write C++ which is as clean and elegant as Java.
Many inexperienced programmers say things like you can't do functional programming in C++. I plan on completely destroying this particular myth, by releasing a very powerful functional programming language which is entirely a subset of C++. I've already written a prototype for the language, called Unimperative, which I plan on re-releasing sometime this month.
Another misconception is that C++ is not good for high-level programming. When people use a language like Python, they see it has built-in lists of untyped objects and are impressed with how powerful that is. The fact is that with the right library (a future release of the OOTL. for instance) you can have the same type in C++ with precisely the same semantics and almost identical syntax. This is true for many types and features found in all of the so-called "high-level" languages.
This appears to even be a popular preconception of experienced C++ programmers. Many professional C++ programmers resort to using other languages like Python/Ruby/Perl/etc. to do simple tasks rather than writing small programs in C++. This seems to be primarily due to the fact that there are tradtionally no good high-level libraries in C++, and for some reason C++ programmers always require their C++ code to be maximally efficient, whereas their expectations are considerably loosenesed when using another language. I think this is a quirk of programmer psychology.
I guess the theme is pretty obvious here, C++ has the potential to make an excellent high-level programming language and over the next while (until I get Heron stable enough for my full-time C++ replacement language) I plan on showing techniques, and writing libraries for more rapidly producing easy to understand, debug and maintain C++ programs.
I'm looking forward to this. I cut my teeth on C++ and am still impressed by the variety of things you can do in the language and the vast power of it. I, like many others, have inherited plenty of code which is likely responsible for many of the myths you plan on shattering.
I am curious though about this statement "until I get Heron stable enough for my full-time C++ replacement language" being included right in the column that says you are going to be describing how you can do all these wonderful things in C++. So we're going to talk about how C++ can be a great high level language, yet you say that you are busy writing a high level language to replace C++! That has to be an interesting perspective to write from.
Related to this, I was wondering if you could take a few minutes at some point (I realize this may not be the place) to contrast Heron with D. I tried doing a search to see if I could find anything, as the goal of the two languages seems similar in some respects and some of the design decisions regarding arrays, single inheritance, etc. seem to be made along the same lines. I didn't come up with anything.
Sadly I don't use C++ very much anymore. We've since moved on to more "advanced" things like C#, pick your favorite flavor of VB, etc. I really dig Python and at home when I'm working on stuff I usually reach for Python, C or C++. I probably suffer some of the preconceptions you're going to be shattering, so I can't wait to read the upcoming entries.
Actually, all of my conceptions of C++ are post-conceptions. I've concluded that its more of a brain toy than practical language (except for certain low level high performance programming - which does not typically include the application domain).
So far as I can see, the key problem with C++ is that the language adheres to the principal of most surprise. It is impossible to view any single line of C++ and be certain that you know what it does. The existence of compiler written functions, automatic type conversion, operator overloading, templates and template specialization all conspire to prevent a developer from having any kind of clue what a line of code does or costs to execute unless the developer has conceptually absorbed the entire code base.
This just isn't practical or even possible on a large project. Thus, I maintain the C++ doesn't scale up well to programming in the large. If you can't hold the entire code base in your head you will eventually thrash or be frequently surprised by unexpected behavior.
Thus, I have abandoned the language for application work.
"You can write C++ which is as clean and elegant as Java."
> I commonly see many problems with C++ code: overuse of the > generic programming at the highest level of abstraction, > avoidance of traditional OOP techniques, designs which do > not reflect the problem domain, insufficient use of > abstraction, designs which are too loosely coupled, and > the list goes on.
That's an interesting point -- and I suppose it explains why you're working on the OOTL. But I look at Java/C# and think the exact opposite: overuse of OOP, refusal to see the problem in larger contexts, abstractions in the wrong directions, too tightly coupled designs, etc. For me, the epitome of software design should be completely seperable pieces, that when put together just magically works. Change the configuration of those same pieces, and get a completely different program, which also works. Of course, it never really happens that way, but the I still think the general idea of orthogonal components is a good one. It's also completely baseless -- so I'm interested in how OOTL will turn out.
> You can write C++ which is as clean and elegant as Java.
> > You can write C++ which is as clean and elegant as > Java. > > I second the motion to raise the bar on that one.
That is interesting. I like reading and writing Java code (with generics). I find it clear and understandable compared to the obfuscated C++ I am accustomed to reading. I am surprised others disagree.
But really my favourite language to read is Delphi.
> I am curious though about this statement "until I get > Heron stable enough for my full-time C++ replacement > language" being included right in the column that says you > are going to be describing how you can do all these > wonderful things in C++. So we're going to talk about how > C++ can be a great high level language, yet you say that > you are busy writing a high level language to replace C++!
Yes, C++ has many known problems. I want a language which is cleaner and more efficient.
> That has to be an interesting perspective to write from.
I hope so ;-)
I definitely get into a lot of debates with C++ programmers.
> Related to this, I was wondering if you could take a few > minutes at some point (I realize this may not be the > place) to contrast Heron with D.
D is more mature than Heron, and thus has a higher chance of survival. There is a very active community advancing and promoting the language. In terms of technical comparisons, I am too biased to make a fair comparison. I will say that I am satisfied that D does make a language like Heron obsolete.
> The existence of compiler written functions, automatic type conversion, > operator overloading, templates and template specialization...
And you didn't even mention macros (unless that's what you mean by "compiler written functions," after all, you did mention templates separately).
I think the worst bane of C++ is all the C code that's considered "C++" because it is compiled with a C++ compiler. Of course, the ability of C++ compilers to compile C was an essential ingredient to its early adoption, but now it just means there are a lot of C programmers in the world who think they are C++ programmers, because they are using a C++ compiler.
> D is more mature than Heron, and thus has a higher chance > of survival. There is a very active community advancing > and promoting the language. In terms of technical > comparisons, I am too biased to make a fair comparison. I > will say that I am satisfied that D does make a language > like Heron obsolete.
Whoops! This should have been "I am satisfied that D does not make a language like Heron obsolete"
Previous Topic
