[penguicon-general] A couple of thoughts about programming

[Garrett Kajmowicz]

On Tuesday 01 May 2007 11:55, Rob Landley wrote:

> Also "the advantages of C over C++".

*sigh*

I'm trying to decide if I'm being baited to post on the list.

I'll let (most) of the opinion slide by, but I have a few technical 
objections.


> When modern languages started to emerge, C++ went "oops, THAT'S what we
> should have been thinking about" and started retrofitting the new concepts.
>  But it didn't have a runtime (instead it links in a big library).  Its'
> attempt at exceptions bloated the heck out of both the stack and the code. 
> Garbage collection is really hard in C++, because it requires references
> instead of pointers.  (A reference is a pointer you can't do math on, it
> _always_ points to either a valid object or to NULL; without this property
> doing garbage collection is insanely complicated.)  But C++ can't give up
> pointers without losing the underlying C, which was part of the definition
> of the language, so garbage collection never made it into the standard.

You can do garbage collection in C++.  Most people don't because it's simply 
better to write proper code - you know.  Like you would in C.  Your own code 
can clean up after itself.  Still, arguing that C is better than C++ because 
C++ doesn't have a feature that's also not in C doesn't make much sense.  
It's ranting in a vague sort of "and your mother wears army boots" kind of 
way. (No offense meant to people who's mothers' actually wear army boots)

> And then there's templates, which are C++'s attempt to do runtime type
> identification at compile time.  This makes about as much sense as
> attempting to do garbage collection at compile time.  Templates pretend to
> hide complexity, but you have to understand exactly what the template
> expands to in order to have any hope of reliably using (or debugging) it.

Your first statement is close enough to correct that I'll let it pass.  The 
second part is completely wrong.  Templates are easy enough to debug and very 
easy to use reliably.  Don't assume that your experiences in 1996 (2 years 
before the standard came out) were even a useful datapoint.

> C++ tried to leverage the popularity of C (it's the universal assembly
> language everything else is written in), but got the disadvantages of C too
> (pointers, manual memory allocation, static typing fixed at compile time).
> As a result C++ wound up in a weird no-man's land between C and Python,
> neither fish nor fowl and sucking at both niches.  It has managed to con
> some people into thinking it's as good as C++ for writing low level
> infrastructure (qt is a big case in point), but when successful such
> projects generally refuse to use things like templates and instead use C++
> it in its original "C with classes" intent, as a slightly smaller syntax
> for doing object orientation and nothing more.

C++ supports much more than just templates, though templates are a great 
feature, they aren't appropriate in all contexts.  There is also support for 
exceptions, namespaces, classes (virtual or non).  Templates are best when 
used for container classes.  Too bad Qt doesn't provide examples of container 
classes.  Oh, wait:

http://doc.trolltech.com/4.2/qlist.html

> C++ has grown lots of mechanisms to "manage" complexity, and in doing so
> actually _encourage_ complexity.  (For example, classes weren't enough so
> they had to add scopes.)  In C, the solution to this problem is to step
> back and clean up the code, removing stuff to REDUCE complexity.

Hmm.  Python has added the equivalent of namespaces.  So has Java, C#, etc.  
In short, C++ is complex because it has the same features that other 
languages that you prefer also have.  Namespaces have de-factor arisen in C 
as well. 

http://equalarea.com/paul/alsa-audio.html

Nearly all of the ALSA function calls start with snd.  Why?  So that you don't 
have function name collisions with other libraries you might want to link 
against.  Great.  It also shows that all of the functions are related to each 
other.  Are C++ namespaces the best answer?  Probably not.  But they are *an* 
answer, and a decent one at that.

> "public/protected/private" are based on a mindset of not trusting
> programmers to be any good or to understand how the thing actually works. 
> Not only is hiding the implementation antithetical to both good programming
> and to open source, but if you expect bad programmers you GET bad
> programmers.

You seem to mistaking the principle of "data hiding", that an implementation 
should be separate from its implementation, and actually not making source 
code visible.  The public/protected/private markings are designed to allow a 
developer to mark certain code as "this is part of the implementation", 
defining an interface while the whole time making more details of the 
implementation available.

As for getting what you expect, that's independent of programming language, or 
field of endeavor for that matter.

> C++ is popular in corporate environments for the same reason cobol is: it's
> designed to satisfy managers, not programmers.  It's a "drone language",
> aimed at faceless worker bees.  The fundamental assumptions are that
> programmers are interchangeable cogs, and programmers can't be trusted.  If
> it was actually true that a random programmer off the street couldn't do
> much worse than the people who originally wrote the code (which
> public/protected/private attempt to enforce), this would not be an
> _advantage_ of the language.  But it seems like one to pointy-haired types.

As far as I can tell, this is a gigantic appeal to authority.  This must be 
true because you say it is.  Yes, programmer mills use C++.  Most of them are 
now going to Java and C#.  The fact that the language has been used by 
clueless people doesn't mean that it causes clueless people.


> The other big corporate assumption is that once code is written and
> working, it should never be touched again.  Corporations treat code as an
> asset, which means that existing code, once written, has a dollar value
> attached. Therefore, removing old code is a waste of money.  If throwing
> old code away makes no economic sense, then the only thing you can ever do
> is add more code, layer upon layer of subclasses, to get the behavior you
> want.  This sounds crazy but it's VERY common in corporate environments: we
> paid for that code, and you WILL use it.  Corporations LOVE subclassing.

To summarize:  Bad management will do stupid things.  And this has *what* to 
do with programming language design?

<snip - more of the same>

> Oh, don't combine C++ and shared libraries.  Just don't.  That's a can of
> worms that would require a whole post of its own to even START to address,
> but the big one is you have to build the library and everything using the
> library with the exact same compiler version.  And no, wrapping "extern C"
> around a function that returns a pointer to a class instance doesn't
> actually help matters, and yes I've seen this.  C++ pretends you don't have
> to understand what's going on under the covers (so it gets people who don't
> even try) and then makes 10 times as much stuff happen under the covers
> because nobody's watching to keep the complexity down...

Hmm.  This can be resolved by using the same compiler to compile all the 
source code.  Which means we should have the source code to everything.  I 
know, we can start this movement where we can ship the source code to 
everything we produce.  This way people can compile it with their own 
compiler.  Maybe even port it to different platforms or different compilers 
with minimal changes.  Yeah, then they could modify the source code to their 
own needs.  We could call this idea "Open Source".

Other languages are adding complexity "under the covers" in order to increase 
functionality and developer productivity.  This is true of Python, Java, C#, 
etc.  Yes, C is simpler (less feature-full?).  Right tool for the job, I 
suppose.


-     Garrett