Monthly Archives: December 2012

Read it here

He keeps referring to programs’ size in pages, rather than bytes or any capacity. It means he thought about programs in terms of their length, rather than how much space they’d require on the machine.

I think he’s decoupling a program’s “length”, as a human perceives it in his head, from a program’s “size”, as a computer perceives it in order to execute it.

It’s a subtle distinction, but I think it’s pretty useful. It means for performance reasons, programmers shouldn’t care about the “size”, but they should care about the “length”. I suspect this is where the mantra of “code should be for humans to read, not for computers to execute” is born. If you can rely on “turtles all the way down” (such as LISP’s functions all the way down), then the computer execution is something you shouldn’t worry about. Let the system’s builtin functionality make it executable.

This keeps the goal of amplifying human abilities as priority number one, and especially concerns about where our locus of attention should be: always on the work, never on the interface. Facilitate flow.

Englebart used the term “concept space”, and I think it’s a good term.

Version control, for example, is a relic of the past. It assumes we’re editing files, and that we’re editing them in isolation.

What if we were editing objects in memory, or in “concept space”?

How could we work without stepping on each other’s toes, and yet still be productive, while maintaining a history of our work?

Imagine a group of people at computers collaborating in realtime on the things in the “concept space”! It could allow us to bypass the language and communication barriers by directly outputting our ideas, using programming languages (which one?) into the concept space.

Perhaps the concept spaces could be overlaid. Instead of existing in isolation, you could toggle other concept spaces and immediately see the differences, intersections, and what was the same. Data visualization could produce interesting numbers and statistics between people and their ideas.

Is it possible to achieve a level of nonverbal communication (akin to playing music with band members) that could facilitate an emotional connection using a concept-space-like system?

I’ve thought this for some time, but I want to get it in writing now.

I believe Bloc’s mission is twofold, or at least we have a two-fold opportunity to really change the world.

First, our stated goal is to change education. We’ve started with web development, because that’s what we know. Along the way, we’ve had to dissect everything we do, as programmers, on a daily basis. Some of these things are difficult, some are easy, some are simple but difficult, etc. Mostly it’s horrible tedious work, with moments (hours) of flow, followed intermittently by frustration and debugging and stress.

There are two ways, as I see it, to teach people to code. You can:

1) Bring the student to a level of competence (literacy, if you will) that matches “the industry”

2) Make programming easier for more people.

If you can accomplish #2, #1 becomes trivial.

So, perhaps the biggest problem we’re solving is not that learning to program is hard.

It’s that programming is hard.

If we continue to use the literacy analogy (which I think is an excellent one, more and more), reading and writing were easy enough that children could be taught, even if they weren’t intrinsically motivated to learn.

If we’re to realize the full capability of the computer-human symbiosis we seek, and allow future generations to build upon our shoulders, we must make programming easier.

It’s a future exercise to compare and contrast what MAKES learning to read/write easier, and what MAKES carpentry easy to begin (as compared to programming).