Graphical Programming Languages

I have always fancied making a graphical programming language. I have also used a few of these as well as done some experimental development myself.

The first challenge is that graphics tend to take up a majority of your time, so you need to carefully select or build a graphic 2D foundation before you start. Unlike a text based language where you can start with any editor and experiment with syntax, you will have to create a complex, 2D graphical design tool before you see your errors. So in my previous attempts I ended up doing a lot of fun graphic work and very little programming language development.

The second challenge is that while some parts do very well in graphic tools, others struggle a bit more. Let me give you examples:

Screen based user interfaces will usually do very well on the design side and is well accepted. Graphic designers have had great success in this for years.

Database design do well because you have established diagram techniques that is well suited to describe a relational database. This is also an area where it is rather easy to auto-generate software due to the high repeatability of tables, columns, relations etc.

Logic is however more difficult. You have little or no auto-generation support, and while a diagram of some kind make the illusion that this is easy it also hides a lot of details. Experienced developers will often work faster in any text based editor, something that defeat the very purpose of our graphical toys.

My conclusion is that I still believe we can dramatically increase our productivity with graphical languages. But, a graphical Language needs to be merged with a text based one – and the graphical part need to be designed with input from a thoroughly study of what new challenges they create for the developers.

Leave a Reply