Language Goals

Sunday, February 8th, 2009

I have been giving some thoughts on what an ideal language would be like and have come up with the following list.

Flexibility.  There is no one ideal language.  Design, like many other fields, has always been about deciding between 2 alternatives.  What is good in one instance may be horrible in another.  Therefore, flexibility is important to make the language fit to the task.  This means there are mulitple ways of doing things.  It also means you can build the language up to the task.  Lisp and Forth based languages are commonly programmed in this manner.  To achieve this goal I believe the language will need to be circular and homoiconic.

Simplicity.  The most elegant solutions are usually the simpliest as well.  This could be thought of as the RISC of programming languages.  Again, languages like Lisp are known for their simplicity.  There is very little syntax to learn and yet it is very expressive and powerful.

Support for meta programming.  I’m not sure if this should be built into the language or if the flexibility of a language will automatically allow for it.  The latter would be more elegant.  Often when programming I find myself doing the same thing over and over again.  So called design patterns are often just artifacts of a language that doesn’t allow you to express your intent succintly.

Homoiconic.  This basically means the language data structures of the language are the language itself.  Lisp and Factor have this in common.

Multi-fix Syntax.  Postfix, prefix, infix should be allowed whenever it is most convenient to do so.  Each programming task may be written better in one of these forms.  The language should not be restricted to only 1 of them.

Dynamic Syntax.  This goes along with flexibility.  You should be able to configure the langugae / environment that best fits the task at hand.  Perhaps this means lots of languages in one (all of them homoiconic and sharing the same code contsructs internally).

Intentional Programming.  I’m not going to define what this is here.  You can google it to find out more about it.  The basic idea I want to borrow from it is that programming should not be about text only code.  You should be able to use tools and construct tools to create what you need.

Macros.  This may or may not be needed depending on how usable the langugae is already.  I need to spend more time working with Lisp to really understand how they are used and if they should be adapted to my language.

Interpreted.  There is tremendous flexibility and power when a language is interpreted.  Many things are simplified.  Speed and code security are the obvious drawbacks.

Runs inside common environments.  PHP, Javascript, Actionscript, and Java are the languages of the web.  If the environment is built to run inside these environments you gain all the API from them.  It is also much easier to deploy and distribute to others if you have a kernel that can easily be installed without any sysadmin work.  This will allow products to be sold without the need of complex environment requirements.

Mix environment with code.  I’m thinking of Squeak, the Factor listener, and Intentional Programming here.  Programming should not be about working with text only.  Often this is the only way it is done.  There is no reason why it needs to be that way.  There is much to be gained if we allow an environment to directly access the constructs of the language directly.

Think Outside the Box

Sunday, January 18th, 2009

There hasn’t been a paradigm shift in software development for quite some time.  I think the main reason for this is because of our myopic tendency to assume software development can only happen with programming languages based off some lexical syntax.  Visual Basic and the following rapid application development (RAD) IDE’s have shown us this is not true for some aspects of code.

I wish to explore Intentional Programming and talk about some of the new ideas it presents.  You can read the link for more details but basically Intentional Programming gets rid of the lexical code portion and allows the programmer or user direct access to the parse tree.  Lisp allows you to program the parse tree directly but Intentional Programming is a little bit different.  It says, yes, the program is eventually a parse tree but give the end user or programmer tools to build the parse tree for each particular problem domain.  Often times the “intention” of the programmer is easier expressed graphically, or maybe by recording a macro, or maybe by drawing lines between objects representing data objects.  For example, if you needed to read 5 columns from a database table, it would make much more sense to pop up that table in a GUI and then just click on each column.  From there it would store that “intention” in the parse tree.  Only the data and the intention would be stored.  The intention can be thought of as a function that operates on the data.  So instead of writing everything using code in a text editor, you use a lot of small tools to construct a parse tree in the most natural and intuitive means possible for each and every problem domain.

Why is it that we are only using text in such a limited fashion?  We are not using color, size or position to represent any additional syntatic meaning.  This makes for inefficient communication between the programmer and the computer.  It would be easier to read code if color, size, or position could be used to represent more.  This is readily seen when using color syntax highlighting in an editor.  It is much easier to scan code to understand the meaning.  The human brain can spot things quicker that it would have otherwise skipped over.

Why are we using only text and not graphics to represent our code?  The compiler takes some kind of input and translates that into machine code.  Why does it always have to be text.  Why can’t we use something that is easier to read and write code in?  I’m not exactly sure what this might be.  Perhaps it could be some kind of flow chart, or it could be wiring objects together like Legos.

I don’t claim to have all answers to these questions.  I am throwing them out there in the hopes that it triggers imagination in others.  I intend to share my thoughts on these questions as I have insights.

Programming in it’s essential nature is breaking down a problem and then specifying the solution to that problem in a way that a computer can repeat.  Why do we always use the same language most of the time?  We tend to have our favorite languages and we use them to solve our problems.  This greatly limits our ability to think about the problem.  We break the problem down into the components of the particular language we want to use.  This goes back to the saying, if all you have is a hammer, everything looks like a nail.  Programmers are often unaware there is a better way of solving their problem because they think they only have the tools the language provides them.

I think a better way to go about solving problems is to have a generic framework for building our solutions and then builidng the language to suit the problem.  This goes back to intentional programming.  A programmer should not just use what is in front of him to solve a problem but build the tools he needs to solve the problem as well.  This is top-down and bottom-up development at the same time.

Frequently programmers develop the same kinds of things over and over.  It is to the advantage of the programmer to learn more about building tools, especially about building his own small languages to express a problem in a manner that is concise and without needless syntatical artifacts.

I recommend programmers take a look into tools like ANTLR to get a better idea of what I am talking about and to expand their minds.

ANTLR in and of itself will not allow you to combine multiple languages together.  This is why I said some kind of general universal framework is needed.  I think intentional programming has a lot of ideas that can help advance us in that direction.

I will attepmt to cover these ideas more in future posts.  I apologize if my writing is difficult to follow or lacking in clarity or explanation.  This is my first time trying to write my thoughts down in any serious manner.  Hopefully, my writing will improve with each post.