Thinking REBOL is fun (and Good-ness) but not completely immersive. Thinking Forth is both. Thinking Lisp is Emacs and well, I chose vi many many moons ago. Thinking C is an impossible hodge podge of tools and “assistants”.

So far, in my experience, Forth is the only environment where the crayons and the map come in the same box. In the box in cuisinart form but you get to live in the box.

REBOL is so close it drives me nutters some days, the map is glued to the box and the box is the cuisinart. But it has no console editor (or way of finding source code), so you have to leave the box with the one 4-colour crayon to get to the map glued to the side. The wall of the box is thin, but you still have to leave and go outside to apply the colour.

I kinda scoff at the expression ‘think outside the box’. I wanna think inside the box and when finished thinking the box is the thing.

And all this to leave you with; Make sure you check out Piet. Mostly harmless, but colourful.
http://www.dangermouse.net/...
http://www.dangermouse.net/... I’m fascinated by the last sample on this page. A program that approximates Pi and literally the bigger the program, the better the approximation.

Cheers and keep up the Art.

Regarding API and language being a matter of: “making that which should be done often terse, and that which shouldn’t be done often, verbose or impossible”…absolutely. Most programmers are vaguely aware of it and might nod along when you say so, but their code betrays the fact that they haven’t truly absorbed the Truth. When they’re up against a wall and find an object needs a method, they tend to just add it—rather than think about what assurances or invariants they might be losing in the overall design.

It’s a bit like people who run red lights at intersections, and then try to explain to the cop who pulls them over that “no one was coming”. Programmers in a hurry make a RunRedLight() method on Car and trust it’s ok because they know (or think they know) it’s safe in the case they need it for. But right answers are more like going to the StopLight object and tuning it so that its red/green cycles are sensitive to the existing traffic conditions—breaking no rules and benefitting the entire code base.

This notion is not emphasized so much in computer science education. One reason is probably because API designs are harder to grade than whether an algorithm accomplishes a certain result in a certain amount of time. You can grade a programming problem by giving it a set of pathological test data and assume that a correct program which solves that test is probably correct overall…but how do you easily grade someone’s evolution of an API or language?

(Still another way of talking about the balance of making some things verbose-or-hard as the only way to get real “power” in computation systems is here: Freedom To and Freedom From in Software Architecture.)

Few thoughts, hope they aren’t too abstract.

One of my hobbies is collecting metaphors and design patterns, both of which I consider ways to exploit symmetries in a complex system in order to identify and compress it. Similar to identifying isomers, are different arrangements of the same atoms, by casting a finite number of shadows, the shadows can act as hashes of sorts.

One of the key insights for me is that like powers of 10, these patterns exist in strata, typically as frameworks and object hierarchies are built up to ‘automate’ away the redundant aspects of programming (growing skin to protect itself) hide away the details from the user, and form another black box. By this act of defining their 4 colors (say blue and yellow), force the user to have to work hard to recreate other colors (say green) or be impossible (say black). This is the essence of API and language…making that which should be done often terse, and that which shouldn’t be done often, verbose or impossible.

In the end (as we’ve discussed) I really wish there were a few more colors built in. The fundamental usage patterns like do/undo/redo, state management and transition is typically left as an exercise to the programmer, and I think that is a mistake, and thus we constantly reinvent the wheel, axles, etc., and have spent likely trillions of dollars in broken code by getting it wrong, and/or attempting to add it in as an after-fact. Much like the large amounts of changes to get an additional color in on the graphic you’ve shown.