Visula is a visual programming language (VPL). It is a programming language that uses a graphical notation to express programs. An overview of the language can be found here.
The purpose of Visula is to provide a full programming language for application development. This remains a challenge for visual programming, since mainstream application development is still based on text. It is an interesting question as to whether visual programming will eventually supersede text.
Some people really enjoy using visual programming languages, and use of visual languages is ultimately down to programmer preference. Subjectively, it provides a more tangible, cohesive, and perhaps a more natural representation of code.
Some other technical reasons for using Visula:
- Visula has dynamic typing. This is a better choice for novice programmers who do not need to learn vast and complicated rules governing types. Dynamic typing also overcomes some problems of covariance in class hierarchies, and problems such as fragile base classes. A lot of complicated OO workarounds are not needed with dynamic typing.
- Information is more clearly presented in Visula.
- Visula programs have fewer hidden dependencies.
- Visula is a pure object oriented language. Everything is achieved via object-orientation.
- Visula is simpler because it unifies the concepts of a class and a function.
- All functions have access to data in their parent objects. Information flows hierarchically.
- Visula programs have hierarchical rather than linear structure.
- Visula is a safe, garbage-collected language. There will be no nasty surprises from memory corruption.
- Visula supports native "object+method" pointers and classes may be passed around as objects.
- Visula integrates into C and C++ projects.
- Visula libraries are better organised because they are stored hierarchically.
- Generated programs are portable to any platform with a C compiler.
Some reasons to not use Visula:
- Visula is a new language, so it would be unwise to use Visula for serious work.
- The editor runs only on Windows and Intel architectures.
- Performance currently lags mainstream languages.
- Visual programming just may not be for you.
No, Visula is primarily a programming language, not an end-user language. Its syntax is abstract, since Visula programs do not correspond to visual things. The editor is also very unusual compared to a basic text editor.
While in the future, it would be nice to tell your computer "write me a program to play chess - here are the rules of the game", at the moment we still need to fill in the missing steps. A programming language must provide the ability to write algorithms and the data structures required to solve the problem - you can't just wave your hands at it.
Programming languages are often blamed for being "too hard" - actually it is the rigorous thinking that is hard, the language is just a facilitator. A change to graphical syntax will not per se change the information we need to provide a computer in order to specify software. Visula is based on today's technology - where programmers need to specify the computational steps by hand. At the moment, we can't "do science without the scientist", but we can give the programmer better tools to structure the work.
Writing software to replace the need for programming is of course very useful, but the distinction between "end-user programming", and "programs for end-users" is ill-defined, and if we consider "programming" to be "specifying the behaviour of a computer", then pretty much everything is programming. End-user languages seek to reformulate problems into a higher-level domain, but that can only work for specific problems, not in general. An extreme example is a word-processor document, which is written at a very high level, but could be regarded as a program to move the print head of the printer to produce the page. High level programming languages still need to perform the computational steps, but they can make some of them implicit.
As Einstein said, "Things should be as simple as possible. But no simpler." As Alan Kay said, "Simple things should be simple. Complex things should be possible." Unfortunately, taking the complexity out of programming is a challenge - but where complexity is unavoidable, the goal of a programming language is to mitigate the effects of complexity. An effective approach is "divide and conquor", where large problems are subdivided into manageable pieces. Programming is about finding the right abstractions, and the most generic approach to this is object-orientation. Making a language too simple by removing proven techniques that programmers find very effective, can render the language useless for general-purpose work.
So Visula makes no attempt to solve the problem of general-purpose end-user programming. That is beyond today's art. Visula makes the choice of being a programmer's language rather than an end-user language.
Obviously being a new and experimental language, Visula has not been used for any particularly large projects. However Visula is designed to be scalable, which it achieves through the following ways:
- Objects are folded, and the program is navigated hierarchically, not linearly.
- Local functions mean that functions may be defined where they are used.
- The notation is quite compact, between 80-200% the size of text.
- A text mode can tame spaghetti-like functions.
- Visula supports independent module compilation, each module being easily in excess of several thousand lines long.
There are two ways that Visula programs execute:
- Interpreted in the environment. This is the slowest, and types determined at run-time. External C functions are loaded from DLLs.
- Compiled to C. This is not as fast as native C code, since the language is still dynamically typed. External C functions are statically linked into a stand-alone executable. Modules are compiled independently.
No performance tests have been carried out, however I don't expect Visula to break any speed records.
Graphics and text are better at displaying different types of information. Graphics can show structure and interrelationships, and alternative graphical forms can provide different information and browsing capabilities. However, text is also a graphical medium (from Greek graphikos - writing), and provides information about structure through indentation, and graphical navigation can augment, rather than replace the textual medium. Text also scales well, since it only grows in one dimension.
The purpose of a language is to communicate, and it is important to remember that this is a two-way process: from the computer to the programmer (visual display), and from the programmer to the computer (input, editing). Our inputs to the computer, though via the mouse and keyboard, are nevertheless a language. Therefore for a language to be effective, it must display information clearly, and be easy to input.
There are some reasons to suppose that Visula's notation is better. Some things are displayed more clearly in Visula than in an ordinary textual programs:
- Program structure. Objects are drawn in a box, which emphasises the start and end of each object.
- Navigation - programs are organised as a tree.
- Variables, inputs, outputs and dependencies. These are drawn in the border of each box, clearly distinguished from the body of the function.
- Hidden dependencies are prevented since the programmer must explicitly declare any object used - there are no complex scoping rules, global scope, inherited names, or names of types.
- Localisation. Because functions may be nested, functions can be declared where they are used, and prevented from being used elsewhere.
- Variable usage. When a variable is used, an arrow leads from the variable's line, and when a variable is assigned to, an arrow leads to the variable. The use of the variable is absolutely clear from this notation.
- Control flow is perhaps easier to understand? Only the horizontal dimension is used for control flow, and looping and conditional constructs are brightly coloured.
There are of course weaknesses in Visula's notation as well.
- Functions can become very wide. This could be reworked as a benefit - it encourages large functions to be split into smaller ones. This is easy to do since local functions are permitted. Hundred-line functions are simply bad design, languages like Prolog and Haskell strongly discourage this style of programming.
- When a function/class has many members, arrows between members can become very long. This can be alleviated by reordering the variables which is easy to do in the editor, but sometimes the result can look still look scrappy.
- There is no for or switch statement.
These potential weaknesses in Visula's notation have necessitated the implementation of text and semi-text modes. Semi-text mode removes the lines in the operations, and uses variable names instead. Full text mode presents a textual view of the function - operations are organised vertically and the editor has the scalability of an ordinary text editor. Perhaps the text modes will ease the transition from fully textual to fully visual programming.
- Visual notation is not suitable for every function.
This question can be divided into two sections: language and notation.
The language is actually very simple, and resembles Smalltalk, or even Simula. Due to the constraints of visual programming, the syntax needs to as simple as possible, to reduce the amount of visual clutter and input required by the user. Thus Visula is dynamically typed - types of variables do not need to be declared, rather they depend on the value actually assigned. Visula has no concept of global scope (except for the special std object), all classes in Visula are nested. This is intended to improve encapsulation.
Another simplification Visula manages is the unification of the function and the class. A class is simply treated as a function that persists beyond its return. Apparently, this was first done in Simula. Methods are provided as nested functions, and actually all classes and functions are nested. Visula also supports class-variables, function pointers and pointer-to-method+object variables - they are all the same thing.
Visula's notation is new, though it occupies a similar niche to Prograph. They are both object-oriented VPLs intended for applications programming. It is always interesting when two completely different solutions solve the same problem.
While Prograph splits the program up into lots of sub-diagrams, Visula programs reside in a single diagram. Prograph is based on data-flow, while Visula has a hybrid notation expressing control flow and data flow. Visula's layout is automatic, Prograph's is manual. The notation is reminiscent of a UML sequence diagram, with messages passing between objects. It might even resemble musical notation, insofar that the horizontal axis is used for time.
All works are copyrighted. Currently there is only one copyright holder, Calum Grant. The development environment may be distributed freely in binary format, providing that the installation files are not modified in any way. There are no restrictions on commercial use for the current release.
The libraries and the Visula run-time are open source, and may be distributed freely under the terms of the LGPL. All works created using Visula are the copyright of their creators. Thus programs written in Visula may be freely distributed.
Calum Grant. I suppose everyone involved with VPLs is motivated by the intuition that graphics must be a "better" way to program, so I wanted to see what I came up with. It's been mostly developed in my spare time. So two years hard at play, here it is.
(Review question from VL/HCC 2006)
Why for example is there no gap in between the condition and the body of a loop or a control?
This is because a gap would not add any information to the diagram. Excess or unnecessary decoration is best avoided. On the other hand, if there were more types of control, such as a do-while, until, do-until and exception handlers, then some kind of decoration would be entirely appropriate to distinguish the different types of control, since adding new colours would start to break down.
(Review question from VL/HCC 2006)
Yes - RFTM! Visula does not have a built-in notation for arrays. Instead it treats arrays as objects, and uses method calls to access the array. This is better because it does not introduce a (redundant!) notation for arrays, and because dynamic typing allows an algorithm to work on any type of container (e.g. a linked list) without hard-coding the fact that we are dealing with an array. This kind of flexibility was introduced in the C++ standard template library.
(Review question from VL/HCC 2006)
This is getting things totally the wrong way around. End-user/novice programming is the niche, whilst programming is the mainstream activity. Usually the only thing an end-user wants to program is his or her video recorder.
This is just the classic power-struggle between programmers and their managers. Managers feel threatened by maverick programmers and therefore constantly try to control and undermine programmers. COBOL was the first attempt to replace programmers. It failed because programming is a specialist skill. Luckily, software practices have improved and programmers and managers can coexist much more happily.
We live in a world of specialists, and I do not feel threatened by that.
The reality is that there is a spectrum of programming languages, from easy to hard. Generally, scripting languages are considered easier and more productive, and are the more appropriate for "end-users". Visula is definitely at the easy end of the scale with its use of dynamic typing and object-orientation.
(Review question from VL/HCC 2006)
There is almost no possibility of confusion. A gap separates adjacent expressions. It is also possible to put a vertical line in between expressions.
The only time you could every get confused is when there is some kind of operator that combines two expressions. For example a=1, a=-1 could be confused with a=1-1. However in real life, you are unlikely to assign to the same variable in two successive expressions.
(Review question from VL/HCC 2006)
Yes, very many. The underlying concepts are familiar, but that's because I'm not intelligent enough to come up with something superior to dynamically-typed object-orientation. Maybe the reviewer isn't either?
However the notation is completely unlike any other VPL, so therefore it is new. Sequence diagrams are well proven in other contexts, yet have not been used as a basis for a VPL before.
The way nesting and folding works is also completely new. The way classes and functions are nested, and the way functions and classes share much of the same syntax, is also new.
(Review question from VL/HCC 2006)
Ouch! That's a bit like going to a conference on ML and saying "why don't you just use C++"? Very many niche languages show off something without aiming to be a replacement for mainstream programming. Put it like this: if you come up with a new way of interacting with a spreadsheet, what are your chances of replacing Microsoft Excel?
A programmer wanting to do a real programming task is obviously better off using a mainstream language. That should not stop people exploring new programming languages.
(Review question from VL/HCC 2006)
This depends on where the function comes from. Objects (boxes) on the left of a life-line are generally inputs, whilst objects (boxes) on the right of a life-line are generally outputs or are locally defined. This has nothing to do with how a function is called.
(Review question from VL/HCC 2006)
Agreed, but define success. A lot of early VPLs did not "succeed" in so far as they did not become widely used. Also there were a lot of genuine usability issues with early VPLs, since they simply weren't as usable as they claimed to be. However they were successful in that they adequately explored a notation, and made us understand usability a lot better. Without pioneering efforts, we would not understand VPLs as much as we do today.
If you set your objective to be "replace C++ within 5 years", then unless something very strange happens, you will fail. Only once in a blue moon does a language make it. On the other hand, if your objective is to "further the understanding of VPLs", then you have a much greater chance of success.
Since Visula really is general-purpose, it won't have a niche with which to capture the public imagination.
(Review question from VL/HCC 2006)
Personally I think this is the fastest and most convenient way of entering expressions. Remember, Visula is a programming language not an end-user language. Maybe an expression builder would be beneficial, however it's fairly low down on the list of priorities.
This question suggests that a "purely" visual language is desirable. Maybe it is, however being visual is not really the objective here. The objective is to improve programming.
A lot of VPLs don't visualise expressions at all. Even Prograph has "expression nodes" (e.g. a+b/c) to inline an expression using text. Visula actually visualizes the expressions, however it is odd in that its input method is text, although this is due to the particular implementation of the environment.
(Review question from VL/HCC 2006)
It is far too simplistic to say that VP does not work. It is also far too simplistic to say that VP is superior to text. There are benefits and disadvantages to VP, see any text on Cognitive Dimensions. The objective is to overcome these apparent tradeoffs.
It is far too easy to criticize early works on VP. Without these pioneering efforts, we wouldn't know as much as we know today.
You aren't just going to pull the perfect VPL out of a hat, and suddenly the world will be using VP. You need real VPLs in order to refine and improve the art. Paper mock-ups will only get you so far. If you have too much fear of failure because of the nay-sayers, then you'll never create any new VPLs, and the whole subject will stall.
I just simply don't believe that in the long term, text is the best way to program. Therefore, you need to keep on trying. Why don't the nay-sayers use their superior intellect to write some decent VPLs? Any takers? I thought not.
(Review question from VL/HCC 2006)
Visula has classes. However, it does not have types - there is a difference.
In dynamic typing, the "class" of an object is almost completely irrelevant. You call a method on an object, and it either works or it doesn't.
A prototype implies a "cloning" mechanism. This is not how Visula works. To construct an object, you call the "class" as a function, which executes the expressions in the class to perform initialization. Initialization is performed independently for each instantiation. This notation is shared with function calling, however it is nothing to do with prototyping.