Home » forums » LtU Forum

Visualisable Languages

What is the potential of visualisable languages?

A visualisable language is one whose code is written as text,but the interpreter can visualise(in 2D/3D graphic medium) the execution details of the code with the semantics of the language intact.

A feature like this will make it a lot easier to write,learn(from examples) and maintain software. If the visualisation can be done right, i see a lot of advantages of such an approach.Allowing cutomisation of the visualisation and advanced user interaction will be a bonus for such a language.

I also feel that this approach is better than Visual Programming Languages as almost all of them lack the expressive power compared to text.Infact, its is the best of both worlds(textual and graphical).

I also feel that visualisation caters well to everyone.It helps systems designed badly (tightly coupled systems being an example) stay in game because they can be managed even if it is with great difficulty.At the same time it allows good designs to prosper faster because it will be easy for people to understand the design and (re)use it.

I also feel that it will help manage complexity. From my understanding people define something as complex, when they do not understand it well.In software, we define something as complex, when we do not know what the system is exactly doing or cannot predict what the system would do given a set of parameters.Going by this definition of complexity,visualisation helps reduce complexity because it tells us what the system is exactly doing.

Comments on this issue are welcome.Also,Did someone already try this?

By mansu at 2006-03-10 19:28 | LtU Forum | previous forum topic | next forum topic | other blogs | 7377 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hands on programming

I want to program with my hands with a tool that's something like this. :-)

By Chris Rathman at Fri, 2006-03-10 19:47 | login or register to post comments

Oh yes! I want I want one NOW!

Where can I lay my sticky paws on a chunk of FTIR hardware. My email to the originator of that video (Han) got no reply.

By John Carter at Wed, 2006-03-15 00:04 | login or register to post comments

No magic bullet

I guess a lot of people have had this idea, but in reality visual languages haven't provided effective tools for managing complexity except in some special contexts. Visual representations can be very succinct, but that succinctness is quickly lost unless you can provide an effective way of telling which details can be omitted or abstracted away from (lest the visual representation becomes a tangled mess). Figuring out how to do this has not been easy.

By Charles Stewart at Fri, 2006-03-10 20:02 | login or register to post comments

linear use once variables and graphical programming

in the paper http://home.pipeline.com/~hbaker1/Use1Var.html there is a discussion of the relation between linear use one variables (explained quite thoroughly in the paper) and graphical programming languages, and how they make the idea of graphical programming in a data flow style (simlar to pd) quite a bit easier and how certain programs are much easier to impliment using them.

after reading this paper and letting it sink in for a while, i figured out a modern term for what he's talking about: pipes. anyways, an interesting read for fixing some of the problems associated with graphical programming and the types of problems that can be solved with them.

--
kruhft

By kruhft at Fri, 2006-03-10 22:21 | login or register to post comments

Either/or

I'm a visual thinker, so I'd love to use more visual languages. However, I get the impression (having looked at LabView a little) that there is a tipping point where they perhaps stop being manageable - although I'm sure that could be debated by folks who really know and love the system.

So, anyway, what I'd posit as a good goal (and there are folks working on such things, and such things are even a little bit available in good IDEs) would be the ability to apply different views to any code - graphical, textual, whatever else somebody invents. The idea that there is one programming language that best solves all problems is bunk, and I should think the idea that one representation is sufficient is similarly to be poo-pood.

By raould at Sat, 2006-03-11 00:03 | login or register to post comments

i once posted a link (which

i once posted a link (which i can no longer find) to a visualisation of the runtime execution of code - the source text was highlighted as the program ran. the general opinion was that it wasn't very useful.

for visualising structure in oo languages, uml tools support reverse engineering. this does work - i've reverse engineered code and where it looks a mess generally coincides with where i am worried about the code.

also, eclipse has a plugin that gives a number of code quality mesaurements (i think i have the wrong term - everything from lines of code to number of methods to complexity measurements) and that includes a visualisation tool that shows package interdependencies.

someone commented that just as there should be many laguages, there should be many visaualisations. i'm not sure if they meant NxN or 2N - i don't think that each language should have many visualisations; rather the visualisation will reflect ths tructure in a similar way to the language, because the structure of the program remains the same, whether it is expressed graphically or in text. in other words - graphics don't show you much that is new, the structure is already there and, because of the way (most?) languages are designed is also apparent in the text.

i'm not sure that's clear. programs, as "platonic entities" have structure. many kinds of structure are possible. language design involves choosing what kind of structures you want to support and provding a textual (usually) means of describing them. so the language restricts programmers (unless they are particularly bloody-minded or stupid) into generating a program with certain structures - structures that are reflected in the program source. those same structures can be shown graphically, but you're not going to see exciting new structures, i suspect, because they're simply not there.

maybe i'm contradicting what i said about the usefullness of uml reverse engineering. i think the advantage of graphics in that case is that you can get a higher level view; so i am wrong above in that graphics have a wider dynamic range. perhaps you can combine the two by having an editor that zooms in and out - when zoomed out you see something rather like a class diagram, but zooming in shows you the text for the class.

rambling a bit, but there was also a discussion ages ago about visualising functional languages. why is there not a uml for functional languages (apart form the fact there's a cultural bias against it; i wonder what academic whiteboards are covered with when people are roughing out a design - lambda calculus? or maybe it's just objects and arrows?)? anyway, iirc someone did propose a graphical representation, and it was linked here - it may have been a thesis. and, remembering even more vaguely, i seem to remember that one of the problems was again linked to this idea of seeing different levels - what does that mean in recursive code? do you have infinite zoom? escher woodcuts?

[after reading what i posted:] i think, then, that ides are a convergence of textual and graphical visualisation. what you are looking for already exists, largely, in something like eclipse. some details, like uml-source integration (there is already a uml tool) still need to be fleshed out, but a lot of it is there.

By andrew cooke at Sat, 2006-03-11 12:10 | login or register to post comments

UML can only represent the

UML can only represent the static view of code.It cannot show us the dynamic aspects of the code.

For example, you cannot answer the question:
"What are the values of the method parameters of this function?"
by looking at a UML diagram.

There are many more questions like this for which dynamic visualisation is an answer.

For many such questions a debugger is an answer, but a debugger is too low level and cannot answer questions like "How did i get here" or in other words, it cannot be used to pinpoint the cause.It can only show the symptom.

A visualisable language would be nothing more than a language designed for enabling sophisticated debugging, but the sophistication to an extent that you can see what you want to see.

By mansu at Sat, 2006-03-11 15:47 | login or register to post comments

not sure what you mean, but

not sure what you mean, but almost any debugger will give you a stack trace and some (ocaml, iirc) will let you "time travel" (step backwards). again, it's not clear to me that you get to see anything new with a graphical interface compared to a good ide - where you can click on the stack trace and see the code in question, examine variable values etc.

By andrew cooke at Sat, 2006-03-11 16:21 | login or register to post comments

I mean that a stack trace is

I mean that a stack trace is not an ideal way of understanding the source code.

This is how i look at it:

We are not able to inspect source code intuitively because, a stack trace is not an ideal way to look at it.There should be a better way to do things. Thats the reason many people do not use a debugger to read source.

IDE's are a solution/work arounds and do not cure the root. If debuggers are done right we should be able to look at the source at multiple levels through a debugger.

I have designed a language such that a visualiser(a sophistiocated debugger) can be built from the source.This will also allow us to view the source code at many levels.

I posted a topic here, so that i can present my work in the context of this forum and also get some feedback on the idea.I think that visualisation is not done the right way,which made it look useless.

I also feel that visualisation does not change the way(significantly) we write code, it changes the economics of writing code.

By mansu at Sat, 2006-03-11 16:57 | login or register to post comments

Check out CoreTalk

Along the lines of visualization / seeing different perspectives, check out CoreTalk.

By raould at Tue, 2006-03-14 01:33 | login or register to post comments

not enough

I haven't work with time travel debuggers, maybe they do this...

Speaking from experience, a stack trace is not enough. I have seen several bugs where the failure was obvious and easily stopped in one function. However that function was not at fault, it was getting bad data as an input, and the bad data was caused by a bug many function calls back, but that particular function was no longer on the stack, because some other function called it, and then called the one that detected the failure. (Separated by many other unrelated calls, some of which manipulate the same data) Of course anyone who has ever worked in the failing function was not longer with the company so I couldn't get help.

By Henry Miller at Wed, 2006-03-15 17:35 | login or register to post comments

Hardware Design

Hardware design was done with graphic language (schematic) and now is done with textual language (Verilog, VHDL, System-C, ...) for digital design and even for analog seems to be going that way.

I think that everybody wanting to use a more graphic language should first think about that and propose an explanation of why the change did occur in that domain and how it doesn't apply for his proposition.

By Jean-Marc Bourguet at Sat, 2006-03-11 15:25 | login or register to post comments

Championed by a gut feeling

If visualization was good for everything, then analytic geometry wouldn't find any use. Since a visual language is meant to aid humans only, how does, say, a non-turing-complete visual language fare against plain quasi-mathematical notation at describing predicates, relations, etc? Do we read it faster and/or more accurately? Do we modify it easier?

I'd love references to any scientific research that answers these questions with a resounding yes. Otherwise, it's a bit like stating OO is good for you because we're good at dealing with objects.

By Koray Can at Tue, 2006-03-14 19:32 | login or register to post comments

MDD for/against

Interesting (I thought) ACM article debating model driven development, which tends to be something chock-full-o-diagrams.

By raould at Tue, 2006-03-14 21:49 | login or register to post comments

Conflicting argument by Dr.Pro

S/He says:

On the other hand, you cannot deny that graphical models excel in conveying static information: a two-dimensional layout of the structure of a system is much more easily understood than any linear form, in which links (the lines) need to be resolved symbolically.

... then follows in the summary:

Models are ideal for people who know what they want, but are (and want to remain) unconcerned with realization details. ... But, abstraction—as opposed to (over)sim­pli­fi­ca­tion—is definitely our only known means to master the ever-growing demands on the construction of complex software.

If models do have an advantage, then it's minimized at the 30000-ft abstraction level due to the small (relative to the underlying code) information content. In other words, if a graph has only ten edges, how much difference does it make whether one lists the edges and vertices or draws a diagram?

Otoh, I like elitist tools that make me feel like an architect.

By Koray Can at Wed, 2006-03-15 00:05 | login or register to post comments

Don't forget zoom

Graphical models allow you to zoom in. So you can start at 30,000 feet, but once you know you need to look you can zoom down to the level needed to understand a problem in more detail.

When I worked with UML based systems I started with the high level graphical view, and then worked down. (Part of this is because that is how the tool worked) When I work on systems with UML I have to figure out which source code file to look at, and this is harder on a large project where you don't know the entire layout (30,000 foot view) because there is no good way to get that.

By Henry Miller at Wed, 2006-03-15 18:04 | login or register to post comments

Nothing to zoom into

For zoom to work (or at least remain in the same language), low level details should be programmed using the visual language as well. If you're looking into java code when zoomed into a UML diagram, any possible advantages of a visual representation are minimized again.

By Koray Can at Wed, 2006-03-15 20:47 | login or register to post comments

So print the 30,000 foot view on a poster

Back when I was working with Schlear-Mellor UML, in their tool, that is how I worked. Start at the 30,000 foot view, print it on 11x17 paper (the bigest our printer had), paste that on a wall, and then zoom in. You could zoom in on several areas at once, but screen space was a limitation, thus the poster on the wall (which was printed off at least weekly to keep up with the latest changes).

Yes the deepest levels were not graphical, but "java" (though not java itself).

The graphical views had to support the text views, and vice-versa. I understand that most UML uses do not work like that. If your UML is allowed to get out of date with respect to your code, then the UML is worthless. If you keep the UML up to date with the code (the tool we used enforced this), you draw your daily guidance from the 30,000 foot view.

There were plenty of problems with the tools, but the ability to start at 30,000 feet and quickly zoom into details was not one. True it was no longer a graphical representation (There was a mid level with graphical flow charts), but it did go down nicely.

By Henry Miller at Thu, 2006-03-16 15:22 | login or register to post comments

I'd love to see a video of a

I'd love to see a video of this :)

By Michael Walter at Fri, 2006-03-17 16:20 | login or register to post comments

Planarity

In the ACM article:

a two-dimensional layout of the structure of a system is much more easily understood than any linear form, in which links (the lines) need to be resolved symbolically

The only graphs which are easier to grasp with a pure graphical description than with symbolic references are those which are mainly planar. I don't think my programs can be often be represented with a planar graph.

That's probably why the schematic descriptions I've seen are full of symbolic references: grouping lines in bus and then taking something out of a bus by name; lines which are connected only because they have the same names (the most common cases are for power, clock and reset signals, but it is also used for others); ...

By Jean-Marc Bourguet at Wed, 2006-03-15 10:45 | login or register to post comments

Visual languages for process automation (factory automation)

A lot (maybe most?) of process automation programs (running on programmable logic controllers) are written in a visual language (such as LADDER, GRAFCET, etc.) GRAFCET (a.k.a. Sequential Function Chart) is a particularly interesting one; it is a specification language used to describe complex sequential processes, with roots in Petri nets and finite state machines. All development tools generate C or assembly language from GRAFCETs, so you can write the whole program using graphical languages. Usually, you describe the process in GRAFCET and you express the constraints (often, security constraints) in LADDER or logic equations. The development tools allow you to see the state of the system (using colors/emphasis on the graph) while it is running (either on the real thing or in a simulator).

See http://japura.lurpa.ens-cachan.fr/grafcet/

By Corentin at Sun, 2006-03-12 08:02 | login or register to post comments