12 Jun 2002

Wed, 12 Jun 2002 19:13:54 GMT

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.

29 May 2002

Wed, 29 May 2002 05:03:17 GMT

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?

20 Apr 2001

Fri, 20 Apr 2001 03:32:35 GMT

the sublime and perfect order of all things?

22 Feb 2001

Thu, 22 Feb 2001 07:30:22 GMT

here are some words... how about going outside and getting away from the computer for a while?

Advogato blog for anselm

12 Jun 2002

29 May 2002

20 Apr 2001

22 Feb 2001