OO frameworks, especially in the C++ world, have usually shipped with source. This is often highly educational and sometimes a life-saver. Until, Apple didn't ship the Cocoa source.

Given a solid OO education and C++ background but having missed some of the traditional CS language theory, what is a minimum required reading list, especially when designing a non-traditional language?

Namespace processing seems to be the 'will do later' entry on every XML toolkit author's list. Following from discussion in the recent thread "Simplifying XML Manipulation" I wanted to emphasise that namespaces are the key to reuse in schemas and hence any chance of rich data interchange. Don't ignore them!

What if you could write Python code with an alternate interpreter/preprocessor that allowed you to use different keywords in your native tongue, including ideogrammic languages? This proposition comes from a thought that Python semantics may be flexible enough to act as a VM for the new CEDSimply language.

I recently had reason to work on some code a few years old and used Object Master and an older CodeWarrior IDE. I'd forgotten how much more productive coding could be with the assistance of a Smalltalk-style 3-pane browser. Here are a few points I've picked from my revisit.

If you don't speak English, what programming languages are the best fit and does this radically change how you develop Domain-Specific Languages?

Introducing the CEDSimply project and some thoughts on a clean way to assign pointers using safe multiple dereferences of possibly nil pointers: CurrentLogger = gRS.runner.UI.LogTo unless nil

Business Object Notation, the analysis and design method from the Eiffel community, has its own graphic language. The BON Dynamic Diagrams can be easily represented in a UML diagram or with any simple Visio-like tool and provide a succinct way to document system interactions that appeals to both visual and verbal thinkers.

Goldstein & Alger developed an OO design method that was clearer than UML or Booch and better founded in theory. It was a standard in EDS but has vanished into obscurity. Maybe it's time to look backwards for some insight or at least pick up an old copy of their book for the pleasure of a clear read of what OO development is all about.

Barriers to taking up a product or language are much smaller than people think, like the almost-invisible height difference in a sidewalk (pavement) over which you trip. Tool vendors and proponents of languages find themselves staring in disbelief at an apparently irrational rejection of their favourite.