views:

651

answers:

12

I am considering the possibility of designing an application that would allow people to develop C++ code graphically. I was amazed when i discovered scratch (see site and tutorial videos).

I believe much of C++ can be represented graphically, with the exceptions of preprocessor instructions and possibly function pointers.

What C++ features do you think could be (or not be) represented by graphical items ? What would be the pros and cons of such an application ? How much simpler would it be than "plain" c++ ?

RECAP and MORE :

Pros :

  • intuitive
  • simple for small applications
  • help avoid typos

Cons :

  • may become unreadable for large (medium?) - sized applications
  • manual coding is faster for experienced programmers
  • C++ is too complicated a language for such an approach

Considering that we -at my work- already have quite a bit of existing C++ code, i am not looking for a completely new way of programming. I am considering an alternate way of programming that is fully compatible with legacy code. Some kind of "viral language" that people would use for new code and, hopefully, would eventually use to replace existing code as well (where it could be useful).

How do you feel towards this viral approach ?

When it comes to manual vs graphical programming, i tend to agree with your answers. This is why, ideally, i'll find a way to let the user always choose between typing and graphical programming. A line-by-line parser (+partial interpreter) might be able to convert typed code into graphical design. It is possible. Let's all cross fingers.

Are there caveats to providing both typing and graphical programming capabilities that i should think about and analyze carefully ?

I have already worked on template classes (and more generally type-level C++) and their graphical representation. See there for an example of graphical representation of template classes. Boxes represent classes or class templates. First top node is the class itself, the next ones (if any) are typedef instructions inside the class. Bottom nodes are template arguments. Edges, of course, connect classes to template arguments for instantiations. I already have a prototype for working on such type-level diagrams.

If you feel this way of representing template classes is plain wrong, don't hesitate to say so and why !

+9  A: 

Much as I like Scratch, it is still much quicker for an experienced programmer to write code using a text editor than it is to drag blocks around, This has been proved time and again with any number of graphical programming environments.

anon
Of course drag-and-drop avoids typos..
Eclipse
The ones I've tried work beautifully for tiny projects, adequately for small to medium projects, and were *awful* at scaling up. The equivalent of a typo is grabbing the wrong module to drop in, and that gets easier as the project grows. That's the unavoidable complexity thing showing through.
dmckee
'proved time and again' -- have a source for this?
Andy
Personal experience only I'm afraid. But if you look around for succesful graphical programming environments, I don't think you will find even a single one.
anon
Interface Builder for mac is nice to use, though I have never done anything truly large scale in it.
cobbal
+1  A: 

I prefer hot-keys instead graphical menus and buttons.
And I think same thing will happen with graphical development tool. Many peoples will prefer manual codding.

But, source code visualizer - should be nice thing.

bb
I could see a colored background based on code section being useful..
Eclipse
A: 

I'm surprised you think function pointers would be a particular problem. How about anything at all to do with pointers?

A programming language can be represented by a hierarchy of nodes - that's exactly what the compiler turns it into. It is very strange that the UI for editing programs is still a sequence of characters that get parsed, because the degrees of freedom in the editor is way larger than the available set of allowed choices. But intellisense helps to reduce this problem a lot.

C++ would be a strange choice to base such a system on.

Daniel Earwicker
IDEs that present the code as a tree have been tried - the Gupta SQL Windows product did this long ago. And everyone hated it - I know, because I use to have to train people to use it.
anon
But the source code - if layed out in a "canonical" way - is hierarchical. Namespaces, classes, methods, codeblocks with nested codeblocks, and so on. An editor that restricted you from doing things that were nonsensical *could* make you more productive, if it had all the operations you needed.
Daniel Earwicker
Believe me - it doesn't work. SQL Windows was extremely competetive with the first versions of VB, but failed primarily because the editor was so inefficent. It had all the operations you could want (it was the _only_ way of writing an app) but the users detested it.
anon
I think VS 2010 may provide a breeding ground for advances in this direction, with the extensible WPF-based source editor.
Daniel Earwicker
+2  A: 

The complexity of a nontrivial program is usually too high to be represented with graphical symbols, which are low in their information content. Unless your approach is markedly different in some way, I am skeptical that this would be of value based on past efforts.

So, practically speaking, his will be useful only for instructional purposes and very simple programs. But that would still be a great target market for a product like this. sometimes people have trouble grasping the fundamentals, and a visual model might be just the thing to help things click.

John Feminella
A: 

I think the major problem of this kind of IDEs are that the code generated becomes unmantainable easily.

This happened to Delphi. It's a really nice tool to develop some kind of applications, however, when we start adding complex relationships between the components, start adding Design Patterns, etc. the code grows to an unmantainable size.

I believe it's also because graphical tools don't apply the concept of MVC (or if they do, it's only in the way that the IDE understands).

It can be really helpful for prototypes and very small applications that don't tend to grow, otherwise it can become a mess for the developer(s)

Edison Gustavo Muenz
+1  A: 

What C++ features do you think could be [...] represented by graphical items?

Object Oriented Design. Hence classes, inheritance, polymorphism, mutability, const-ness etc. And, templates.

What would be the pros and cons of such an application?

It may be easier for beginners to start writing programs. For the experienced, it may be get rid of the boring parts of programming.

Think of any other code generator. They create a framework for you to write the more involved portion(s). They also lead to bloated-code (think of any WYSIWYG HTML editor).

The biggest challenge, as I see it, is that any such UI necessarily hinders the user's imagination.

How much simpler would it be than "plain" c++ ?

It can be a real pain, when you wade through truckloads of errors which is typical of code generators.

Further, since a lot of code is generated, you have no idea of what is going on -- debugging becomes difficult.

Also, for the experienced there may be some irritation to find that the generated code is not per their preferred coding style.

dirkgently
Object Oriented Design can be represented graphically. From wikipedia: "The fully object-oriented character of LabVIEW code allows code reuse without modifications: as long as the data types of input and output are consistent, two sub VIs are interchangeable."
grieve
And the link itself: http://en.wikipedia.org/wiki/LabVIEW
grieve
I meant that OOD *can* be represented.
dirkgently
+4  A: 

The early versions of C++ were originally written so that they compiled to C, then the C was compiled as normal.

What it sounds like you are describing is a graphical language that is compiled to C++, which will then be compiled as normal.

So really you are not creating a graphical C++, you are creating a new language that happens to be graphical. Nothing wrong with that, but don't let C++ restrict what you do, because eventually you may want to compile the graphical language straight to machine code, or even to something like CIL, Java ByteCode, or whatever else tickles your fancy.

Other graphical languages you may want to check out are LabVIEW, and more generally the category of visual programming languages.

Good luck in your efforts.

grieve
+1  A: 

Interesting idea. I doubt I'd use it though. I tend to prefer coding in a flat text editor, not even an IDE, and for tough problems I prefer a pad of paper. Most of the really experienced programmers I know work this way, Maybe it's because we grew up in a different environment, but I think it's also because of the way we think about programming. As you get more experience, you start seeing the code in your head more clearly than any GUI tool will show it to you.

As for your question, I'd nominate templates as one of the harder / more interesting sort of thing to try to represent well. They are ubiquitous and carry information that you won't have access to as you are designing your tool. Getting that to the user in a useful way should pose an interesting challenge.

MarkusQ
+1  A: 

I like the idea, but I suspect there comes a point where things get far too complicated to be represented graphically.

However, given recent experience at work; it would be useful to give such a graphical interface to a non-techie person to use to create basic drag-and-drop programs, leaving myself free to get on with some "proper" programming ;-) If it can do the job of allowing somebody non-skilled to build something functional it can be a very good thing (even if programming logic escapes them)

There comes a point in such a system where it becomes easier to define what you want to do using literal C++ code, rather than have a user interface getting in the way; it can get frustrating to the sessioned programmer knowing the precise code that needs to be written but then only being limited to the design GUI. I'm specifically thinking about a more common application, such as html editors/designers in which they allow newbies to build their websites without knowing any html at all.

It would be interesting to see how such a system would handle the dynamic allocation of memory, and the different states of a program as time progressed; I suspect that there are some very basic programming concepts that may be difficult to represent graphically.. Polymorphism..? Virtual Classes, LinkList, Stacks/Circular Queues. I wonder for a moment how you would explain an image compression algorithm (such as jpg) successfully too without the help of a gigantic display screen.

I also wonder if such a system would even go to such a low level, and whether you would be dealing with abstracted concepts and the compiler would be working out the best way to do something.

Phill
You can do what you want with ABSE. You can define Atom Templates as low- or high-level abstractions of your concepts. The end-user instantiates the Templates as per your specifications, and is free to create, but under your pre-defined constraints. At the end, the generated code ends-up being like you wanted in the first place. ABSE is good for large projects too because it's not graphical. See more info here: http://www.abse.info Disclaimer: I am the project lead.
Rui Curado
A: 

It is hard to replace scratch type codes with written codes since they can be customized according to people needs but its good beginners . professionals will always prefer writting code textually i think .

but your idea is also good)

M3taSpl0it
+3  A: 

Writing code is the easiest part of a developers day. I don't think we need more help with that.Reading, understanding, maintaining, comparing, annotating, documenting, validating is where - despite a gargantuan amount of tools and frameworks - we still lack.


To dissect your pro's:

intuitive and simple for small applications - replace that with "misleading". it makes it look simple, but it in't: As long as it is simple, VB.NET is simpler. When it gets complicated, visual design would get in the way.

help avoid typos - that's what a good style, consistency and last not least intellisense are for. The things you need anyway when things aren't simple anymore.


Wrong level

You are thinking on the wrong level: C++ statements are not reusable, robust components, they are more like a big bag of gears that need to be put together correctly. C++ with it's complexity and exceptions (to rules) isn't even particulary suited.

If you want to make things easy, you need reusable components at a much higher level. Even if you have these, plugging them together is not simple. Despite years of struggle, and many attempts in many environments, this sometimes works and often fails.


viral - You are correct IMO about that requriement: allow incremental adoption. This is closely related to switching smoothly between soruce code and visual representation, which in turn probably means you must be able to generate the visual representation from modified source code.


IDE Support - here's where most language-centered approaches go astray. A modern IDE is more than just a text editor and a compiler. What about debugging your graph - with breakpoints, data inspection etc? Will profilers, leak detectors etc. highlight nodes in your graph? Will Source control give me a Visual Diff of yesterdays graph vs. todays?


Maybe you are on to something: a better way to visualize code, a way to put different filters on it so that I see jsut what I need to see.

peterchen
+1. Very interesting post. I believe i still don't agree with you, but i'll try and think about the arguments you provided. I'll get back to you on that :-)
Benoît
I might disagree with your solution, but I agree with the question: Is there a better representation than C++ source code? I am quite conservative and concerned with my day-to-day work - don't let us grunts stop you building something great :)
peterchen
+1  A: 

I've been working on a new model-driven software development paradigm named ABSE (http://www.abse.info) that supports end-user programming: It's a template-based system that can be complemented with transformation code. I also have an IDE (named AtomWeaver) implementing ABSE that is in pre-alpha stage right now.

With AtomWeaver, as an expert/architect, you build your knowledge Templates, and then the developers (or end-users if you make your meta-models simpler) can just "assemble" systems by building blocks, and then filling template parameters in form-style editors.

At the end, pressing the "Generate" button will create the final system as specified by the architect/expert.

Rui Curado