Saturday, May 17, 2008

QWERTY Considered harmful?

An interesting observation from Daniel Berger:
Larry Wall’s first rule of computer language design is, “Everybody wants the colon”3. Maybe the problem is that we just don’t have enough symbols on our darned keyboards. The result is that we’re left fighting over the scraps that QWERTY gives us, e.g. the colon. My opinion is that a limited number of usable characters limits our thinking and our expressiveness. (emphasis mine)

In my recent quest to push forward awareness of capabilities, the notion of expressiveness seems to be at the crux of everything. If you don't have a conventional way to express something, it takes a lot of work to come up with something to get your point across.

I believe that rich source code is overdue. The idea first came to me via Chuck Moore's ColorForth, but I think it could be applied in a wider array of places. The ability to simply highlight a section and make it a comment without worrying about syntax would be cool, but I'm sure there are far more powerful uses that would quickly arise, such as the ability to do literate programming, freely mixing source and documentation and content.

The arguments against any new programming technique usually tend towards the fact that pretty much any language can already express any program. These arguments always miss the expressiveness that a new language brings to making it easier to solve a certain class of problem.

1 comment:

Dean Landolt said...

Interesting point -- I'd kill for rich source. Take Python even -- it's amazing how much effort goes into bitching about the whitespace. Or PEP8. It seems like it would be trivial to come up with an xml dialect that captures the semantics inherent to a standard .py file. You could work in any style that's comfortable to you, as long as the ultimate source is tokenized xml.

This could of course apply to curly brace languages too. The style arguments in these worlds are even more varied. But none of it matters...none of it has any semantic meaning.