I notice that there is a specific difference between how C
programmers use C as opposed to C++ programmers use C++.

This difference is a contrast to the more common
difference - the argument of overall simplicity. The
common argument has often been voiced in terms of how C
developers claim that they "can do everything in C that
others do in C++" and that they "can use C just like C++".

It is obviously true that C developers can make C++ like
objects by hand (instead of using C++ language features)
but what is not true is that this is really how they work
every day. In fact C developers use a different work
pattern from C++ developers.

When a C developer wants to synthetically model a problem
landscape they do the same kind of partitioning that a C++
developer does; they partition the functionality of their
solution up into clumps of locally associated behavior. A
single clump is any area where the density of relationships
is highest, and the relationships between clumps is often
lesser than the relationships going on inside of one clump
with itself. This is a typical colloquial human approach
to problem solving; divide and conquer - where division
occurs along the easiest cleaving lines. Humans are
particularly clever at finding ideal cleaving lines between
any two things - it is a powerful technique. For example
Democritus proposed the existence of the atom by simply
considering what would happen if one kept trying to divide
a grain of salt in two. (All of this is just classic
prototype based composition as well documented by George
Lakoff and friends).

In other ways a problem is often thought of by both camps
as some kind of dataflow or some kind of execution flow.
Typically these problems can be arranged as a stack, where
each of the clumps of functionality gets executed in turn,
and the whole thing is driven from the bottom or the top by
some kind of input. Clumps of functionality can be thought
of as belonging to layers, as one more step along a
pipeline. This design pattern is useful for representing
everything from user interface applications (where the
application is driven by user input) to state machines
(where the application is driven by state events such as
timeouts or external events).

When a C programmer implements a solution they will
typically define a formal API for each of the layer of
behavior, and traffic will flow between clumps by invoking
methods on each others global API's. If in some cases one
clump has to talk to an API method that isn't normally
nearby (such as say a user interface needing to set the
value of a cryptographic key that is closely associated
with a low level transport layer) then it can do that
because the design pattern at use is one of global API's
which are always visible all of the time and always
accessible.

As opposed to how a C programmer works, when a C++
programmer implements a solution they will typically define
objects to represent (or be in) each layer. Here we are
seeing quite a different design pattern at work. Because
these are real objects, as opposed to global API's, they
tend to be visible only to the layer above and the layer
below. When a C++ programmer wants to touch some low level
functionality from a high level area, they have to find a
way to promote the interfaces of the low level layer up to
the high level, or they have to resort to using global API
methods. There is a strong discouragement to use
statically global API methods because it is contrary to the
idea of an object altogether - and if one has a specially
shaped kind of implement that has been a significant
investment then to not use that implement seems wasteful.
There is at least a tendency towards complexity because of
the desire to use the tools at hand - but also a real sense
that if global objects are used then one loses the ability
to multiply instance the application because there may now
also be global state. C++ lacks an ability to fork off a
copy of global state although of course one can instance
another copy of the application.

To help C++ programmers not avoid some of the strengths of
C - there is a way of thinking about this problem that will
help C++ programmers to be more effective. Most things in
life seem to be persuasively represented best as spatial or
visual metaphors. In domains as disparate as music and
mathematics or in any kind of problem solving it is often
useful to conceive the system using spatial or visual
metaphors, the clarity of the right solution, or the
ability to predict next steps seems to jump out much more
strongly - probably because as humans we have so much
wetware dedicated towards spatial analysis.

In this case the spatial analogue of what C programmers are
doing in their code is to define API's that cleave
vertically through all layers of an application. Because
the API's are vertical, they are accessible to everybody,
and this tends to empower C programmers to actually make
those API's useful globally. The limiting factor affecting
C++ programmers is that their objects are only visible
horizontally. Clearly C++ programmers should think more
often of using static global classes to represent
functionality in some cases, and should think more about
aggregating related objects into a specific layer of
functionality, where that layer as a whole may itself have
some global methods - even if some of the contained objects
do not.

Every month or so I wander back to Advogato to see how
things are going here. I'm intrigued by community forums
and how effective they are at keeping the interest of their
members, engaging in a kind of praxis - not getting bogged
down in text and still remaining action centric. Advogato
looks like a moderately lively forum but still seems to
lack a bit of that real sense of community that I saw at
work on forums such as ryze.com or on Rich Persaud's addapt
forum. Is it really just that there are images associated
with persons on those other forums? And should advogato
really care about winning those kinds of popularity
contents? After all Advogato is mostly interested in
filtering away noise. But at the same time I think that
for many the issue is more community, and less quality;
after a certain age almost everything everybody says can be
recast in words or arguments one has heard before, the new
ceases to amaze - one looks for simpler more human values.
It isn't so much intellectual challenge that seems to be
missing, but simply a sense of a long term shared
persistent space; a space where the visibility of others
actions is present, a human shadow cast on the net.
Digital communities are already at a disadvantage because
they favor talk over action; it is too easy to protect the
physical flesh - and without putting the flesh on the line
there is no real risk - without risk there is no connection
to pre technological human values. All of the forums I see
today are essentially failures; small encampments of
hardened like minds but not generally straddling any broad
diversity of community and not truly persistent, not able
to organize large volumes of knowledge, not able to teach,
really in a sense kind of stagnant. I think this is
because they tend to be fiefdoms, and the community
knowledge isn't owned by the members of the community
itself. When a community is held hostage to somebody
pulling the plug, then it ultimately doesn't put its most
precious thoughts into that space. The whole net itself is
completely vibrant - one doesn't make a home page in
somebody elses space, one simply makes a home page and
retains ownership over it. What does it take for a more
controlled forum, with advanced noise filters etcetera, to
support that kind of distributed model?