Complete Software Engineering: De-textifying programming languages

De-textifying programming languages

November 22, 2004 at 06:04 AM
by rgrzywinski | 8 Comments

When reading source code the developer has to make a mental picture of the concepts. Likewise, when writing source code the developer has to translate her mental picture into text. What if we simplified and enhanced this process by making source code more visual (pictorial)?

There are a number of concepts in modern programming languages that have been shoe-horned into text which may be better portrayed using a pictorial representation. Two such concepts are the ternary operator and block delineators.

Ternary Operator

Imagine all of the developer time that would be made available if there was no more bickering about brace placement! (Wesner Moise has an entry about graphical source code editors and code blocks.)

Statement Block

It is possible to decorate existing textual components to help emphasize their purpose and scope. The following image combines a number of features: comments, ternary operator and if icon.

Decorated if-statement

Graphical Comments, Ternary Operator and if with Icon

This decoration can be carried another step. In the previous image, the if keyword and icon appear together. If icons are used to replace keywords, if can be removed entirely. In a similar fashion, the final keyword can be replaced with a decoration on each variable reference.

The final case demonstrates that the decoration provides benefit over the keyword. When the keyword is used, there is no way to know which variables are final without looking at their declarations. With a decorated variable, each time that the variable is entered into the editor the decoration will appear indicating the constraints on it. One can imagine this decoration idea extended even further by indicating type, scope (local versus class) and access modifiers. If the decorations become too cluttered then the editor can allow decorations to be disabled as needed.

Further Decorated if-statement

Decorated Variables

Rather than providing insight some might believe that replacing the if with an icon obfuscates the code. There are going to be a number of attempts that are made in the upcoming years that seem to bring us backwards rather than forward. We must walk before we run and we are certain to get a few scraped knees along the way.

Daniel O'Connell brings up an interesting situation in this post's comment: instead of language lock in, you could easily end up with IDE lock in. It is certainly possible that we would end up with IDE lock-in but recent history has shown us that the various IDE's feed off of one another to create relatively similar products. If Eclipse has a useful feature that IntelliJ does not have then the next version of IntelliJ will likely have it. If on the other hand, Eclipse has a feature that is not useful then it will likely receive less attention and be pulled from the product. In this time of great innovation as long as we steer well clear of "protecting" concepts by legal means (i.e. patents) then the theory of natural selection will cause a relatively level playing field and will eliminate the possibility of lock-in.

I welcome new ideas regardless of their ability to demonstrate immediately clear and attainable results. There are times when it takes two blind steps forward before we can reach our destination. And there are times when we must travel part way down a path before we determine that it is not the correct one.

The ideas that I am proposing are by no means new. (I was surprised to find that Roedy Green has written an extensive list of features that is a superset of mine.) Finding the ideal balance between textual and graphical representations will allow these ideas to flourish where they have withered before.

This entry is continuing the thread on separating the presentation (view) of a programming language from its storage format (model). There are also entries on annotating, internationalizing and adding images to source code as well as simplifying the understanding of code structure.

Read about Code Views.

Comments

Comment by Sam Post at May 13, 2005 10:47 AM

I love your ideas about Graphical Comments, basically this page is awesome. BUT, I can't tell from this page whether these images are mockups or screenshots of a real product. I'm looking for a product that does what this page describes -- can you point me in the right direction?

Thanks,

Sam

Comment by rgrzywinski at May 13, 2005 01:27 PM

The images are mockups. There is currently work underway for a working product -- and the look of that product blows all of this away.

I must admit that we are far from a usable product.

We will be releasing a prototype in near future to get people excited about the concept. From your kind remarks we wont have too much trouble *grin*.

As for current working products ... I know of no such thing. If you do stumble on one please let me know!

Take care!

Comment by Andy at December 4, 2005 05:24 AM

Hey, this stuff looks amazing! Ok, to be quite honest I have been thinking for years about this concept, but haven't got the time or inclination to do anything about it! If you were to provide something that really worked then I for one would definately but it.

Looking at your ternary operator, I think a n-ary operator would be preferable, where the condition is placed where you currently have the T and F above. In your ternary case above this would be something like:

{ widthHint > 0: -1
{ widthHint <=0: 0

The compiler could figure out that only one comparison (widthHint < 0) is needed in this case. Another case might read:

{ i < 0: -1
{ i = 0: 0
{ i > 0: 1

But onto the things that *really* annoy me about Java source at the moment. It might be worth pointing out my field is numerical including 3d maths - but I see you are familiar with these already...

Why do I have to write:

float length = a.cross(b).dot(c);

when I mean:

float length = (a x b) . c

In a graphical language the cross and dot operators would not be confused with anything else, as they could be based on different unicode characters to the full-stop (period) and x characters. This leads onto other operators, should as the perp and modulus operators. And why in a modern editor do we still use * for the multiply operator?!

Also why not define a matrix (e.g. Matrix4x4f) as it looks on paper?

Quaternion operators?

User definable operators, including operator precedence?

Enough. One last thought - you can circumvent the issue of being able to load the 'source document' up in a text editor by using XML as your serialisation format.

I wish you all the success that a product like this clearly deserves,
Andy.

Comment by Andy at December 4, 2005 05:33 AM

I meant 'buy it' of course.

And please, can we have properties that look like properties, rather than getProperty(), setProperty(). I'm sick of typing:

this.setX(vectorA.getX() + vectorB.getX());
this.setY(vectorA.getY() + vectorB.getY());
this.setZ(vectorA.getZ() + vectorB.getZ());

instead of:

this.x = vectorA.x + vectorB.x
this.y = vectorA.y + vectorB.y
this.z = vectorA.y + vectorB.z

Keep the accessor and mutator methods, but make them look like simple properties!

Comment by Andy at December 4, 2005 05:52 AM

Maybe properties (x,y,z, e00, e01) could be displayed as subscripts, as they are in mathematical notation?

Comment by rgrzywinski at December 4, 2005 08:32 AM

Thanks for all of the thoughts and feedback Andy.

Unfortunately this is only a side project for me and paying work takes precidence. I'm hoping that by publishing all of this information (as well as the CodeViews stuff on the RI site) someone that has more will get the bug too and help out.

Take care and keep the ideas coming!

Comment by Kirill Osenkov at September 15, 2007 11:22 AM

Hi Rob,

I'm obviously 3 years late, but I just discovered this page and WOW!! The screenmocks look really impressive.

I'm also trying to build a structured editor and you can read about it here if you're interested: http://www.guilabs.net
BTW we're not alone: http://del.icio.us/KirillOsenkov/StructuredEditors

Have you had any progress on this since 2004? I'm so curious.

Anyway, best of luck!
Kirill

Comment by rgrzywinski at September 19, 2007 07:01 AM

Hello Kirill!

Thanks for stopping by and taking a look.

Progress has come to a stop unfortunately. There just aren't enough hours in the day to work on every project that I want to work on. One of the primary reasons for my stopping was conceptual difficulties that I was having in coming up with novel / usable approaches to editing within a block-based editor. Cutting and pasting for example are much more difficult especially across block boundaries.

Best of luck to you and I hope that you keep moving forward with your project!