About Me

I'm just someone struggling against my own inertia to be creative. My current favorite book is "Oh the places you'll go" by Dr. Seuss

Thursday, January 15, 2009

New Paradigms in programming.

In programming, I think we need more than just a new input method, there needs to be a new metaphore to go with it. It's a three teired thing. Model-Metaphore-Interface.

I've been thinking more and more lately that language is a poor metaphore for representing a computation. Language is something we use for communication. You could look at a program as a communication to a computer, and simultaneously a communication to other programmers. But there are other ways to communicate other than just the written word. I'm working on a list here, let me know if I'm missing anything.

Methods of Communication *Speech *Body Language *Gestures *Facial Expressions *Sign Language *Painting/Drawing *dials, buttons, sliders, pointing, dragging (gui)

Another metaphore for programming is building. Here's some possible ways of building functional things, that could form the basis for a programming interface

Methods of building functional things *Gears/springs and other mechanics *paper folding/cutting/gluing *patch cords *electronic circuits *hinges, ball bearings, wheels *fountains valves and pipes *Archimedes machines: pulleys, levers, screws *Lego

Yet another way of specifying a computation is by definition.

Methods of Definition *Constraints *Categorization *Set Theory *Properties *Symptoms *Logic tables *Rules *Railroads

But keep in mind why we're doing this. There's obviously some weaknesses in the way programming languages work now, (otherwise we wouldn't want to make new languages) so let's keep them in mind while we're designing our new languages

problems with current languages The interface is hidden

the apis are hidden

Side effects are a huge cause of bugs- Any part of a program can effect any other part.

Refactoring- Sometimes you find that you're repeating yourself, so you need an easy way to factor out the repetition into a macro, or a function, or some other metaphore. This is largely done by hand (or semiautomatically in java) by a massive text manipulation effort. Is there a new metaphore that would make such a thing look utterly silly?

You need an easy way to define your own building blocks, or "words" or idioms, to use to build more complex structures. Your own tools, your own parts of the environment. A lot of languages don't let you do this in a first class way.

compilers punish the programmer severely for the slightest mistake.

Variables lack a sense of time- There's no way to query the history of all the values a variable has been set to in the past. In other words, can we have a programming language where we can "rewind" the progress of our program? The fact that a variable can change, frequently to unexpected values is another source of bugs. This is the other half of the side effects problem

most programming languages have a fairly steep learning curve

Making reference to library or widget X throughout your code largely marries you to that library- Making it difficult to switch to a similar equivelent library without a lot of refactoring. This is largely to do with the fact that libraries have names, and in order to use a library, we're hardcoding the name of that library and its methods throughout our code. Is there a better way?

Poor parrallelism, multithreading leads to bugs, race conditions, deadlocks. Is there a better approach to parallelism that makes such bugs impossible?

Think beyond the computer screen people. Maybe the keyboard is the most efficient interface for entering in complex relationships and symbols. Are you sure? There are more alternatives than just a mouse, or a touch screen, or a tablet. Zillions of ways of interacting with a computer- We have just all settled on one or two rather ordinary ways.

1 comment:

David Broderick said...

I couldn't agree more. I've been working for many years on a new programming language that eliminates the language aspect. To program, you just set attributes.

I've finished the language and the first application I'm working on for it is a 2D physics simulator that you can use to make simple games. So you set attributes like gravity and velocity, and you set what happens if there's a collision, etc.

I like what you've written. You have a keen intuition for thinking about it in the right way. At the core is the model, and we've been using languages too long as both the metaphor and interface for the exact reasons you mentioned. Really, perfectly put.