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

Tuesday, April 10, 2007

Programming Language

1. Why create a new programming language?
I have an idea for a programming language. There are hundreds already though, why create a new one? I firmly believe that the bulk of programming languages are missing the point. They don't lack effort or thought, many are theoretically sound, many aren't. Some of my favorites are Lisp, Ruby and APL.

What's lacking in the world of programming languages though, is the perspective of a designer, because frankly, every programming language I see is ugly. Every programming language I have seen, to one extent or another flagrantly disregards the history and culture of punctuation and symbology. They abuse symbols, assigning them meaning they were never meant to have. These programming languages force their readers to cross their eyes, and ignore their years of cultural training to follow the specific and unique logic which applies only to the world of programming. The relatively high density of brackets, and nesting lead to a visual ambiguity which requires an expert, and a good code formatter to decipher. Code should not be code.

And why should code be beautiful, you may ask? The end users don't have to look at it, and the programmers should be clever enough to deal with any sort of cryptic obfuscation, and difficult to type out structure. They are professionals after all! Sure, but the key point is, they are also human. Difficult to read, and hard on the eyes code leads to more mistakes, more fatigue, and over all a more grueling experience. Your average person can usually look at a gramatically incorrect sentence, and immediately sense that something is wrong. Your average programmer doesn't necessarily have this ability with a line of code. Due to the haphazard and thoughtless design of programming languages, you still have to read through word for word, symbol for symbol to figure out why something doesn't work, why something is illogical.

I think there's a better way. I think there is room for a humanistic programming language. I think it's time for one too. There is currently no technical reason it is not possible. The *only* reason we still code using these brutal machine languages, is due to the short history of computers, and their original strict limitations. These limitations no longer exist, but the assumptions that we built from those limitations still do. Let's work to improve this.

2. Design goals

It's easy to lose sight of your goal, in the midst of the process of creation. See my earlier post about creative briefs. Ruby on Rails has a number of design principles. there's Don't Repeat Yourself, and the principle of least surprise, for a couple of examples. A humanistic programming language should have some basic guidelines to enforce a certain amount of self consistancy.

Here is the space where I will keep my working list of HPL ideals.

Respect the punctuation

Don't violate the history, culture and meaning of symbols. We are no longer limited to just what's at the top of the keyboard, above the numbers. Nowadays, we have the entire Unicode symbol library at our command. Let's find appropriate symbols, and use them for their appropriate meanings.

Whitespace is not irrelevant

Having a standard indentation style has proven invaluable to the open source projects that have enforced it. Having a common visual expectation for the code makes collaboration that much easier. Let's not rely on humans to enforce the visual style. We have computers for droning repetetive tasks like that.

Dielects over Bloat

In the real world, different professions each have their own specific languages. Think about the show ER, and the sheer amount of latin they use just to get around having to tediously describe in detail every little thing. Verbal shortcuts. The same should apply to programming. If I'm making a web application, don't make me tediously describe the process of retrieving information from a form, or persisting data in a database. We know in advance we need to do these similar tasks many times. Provide shortcuts for doing them.

Loops are a bad solution to an old problem

The typical tasks which need to be performed by loops is well understood by now. Some task needs to be performed on a list of things, a tree needs to be traversed to find a needle in a haystack, etc. Make syntax for the task, not the computer's method of performing it.

Syntax for the task, not the method

nuf said

Brackets are bad, nested brackets are worse

Brackets are actually visually useful, as long as the opening and closing bracket are on the same line, and there are no other brackets nesting in or around them. Once you break them out into multiple lines, nest them, and worst of all, have a line with nothing but a bracket, things start getting confusing and visually ugly. A closing bracket visually points to the left. If it's on its own, it is pointing at nothing. It is closing and resolving nothing. Combine it with nesting, and reading a page of code becomes a game of matching opening brackets to closing brackets. How can you debug your code, if you have no idea what is going on in it, and it is not visually obvious that you have made a typo? XML endevoured to solve the matching problem. How? More brackets! MANY MORE BRACKETS. Great. I think we can do better.




3. Parallelism


4. Relational integrity

5. MVC enforcement

6. Event Model

7. REST architecture provides a means for sharing work, without working to share.

8. Internet provides a means for automatic distributed super computing.

2 comments:

carbon said...

You write you like Lisp and you want to have a language that looks good, so I recommend you my work - the Harpoon syntax:
http://harpoon.sourceforge.net
It can be used as a basis for a homoiconic languge (as Lisp) with syntactic sugas for better readibility.
I know, this may be considered a spam, but I really think Harpoon may be at least interesting for you.

Gaga said...

You are right in what you say that things should be more intuitively and more cultural relevant in programming languages. Just two minor additions to this:
1. Culture and intuition are based on previous experience. After all the transition from the roman to arabic system of numerals in Europe took several hundred years. Now we use the arabic one and it would be highly counter-intuitive to use binary or hexa. Just give it time...
2. There is a general niche behavior for programming languages with these parameters: application writing time, ease of use, re-usability, execution speed, etc. This way, ASM will be used to speed up critical sections as long as we have limited computing power while high level solutions tend to lack in speed due to overhead.