The Once and Future Visual Programming Environment

http://techcrunch.com/2012/05/27/hey-kids-get-off-my-lawn-the-once-and-future-visual-programming-environment/

by NelsonMinar • 14 years ago

76 51 14 years ago

chubot• 14 years ago

I'd be interested to hear, from people who have experience with these older systems, why they didn't take off.

Maybe it's that they were developed almost pre-web? I was using the web in 1994 on windows 3.1 but certainly never heard of smalltalk. I think it must have been the Microsoft ecosystem and then later the Linux ecosystem that kept "better" tools in the shadows. In 1994 windows was a fantastic upgrade from DOS. You could not just have multiple windows, but multitask!

These days it seems like programming platforms like node.js can take off astonishingly quickly because of faster and faster dissemination on the web. It's not just more adoption, but more contribution too.

NelsonMinar• 14 years ago

VisualAge for Java is another example of a Smalltalk-inspired visual programming evnrionment that never quite caught on. It had a lot of cool advanced IDE features, particularly for its time. It was also slow and kind of crashy, a complex program in its own.

seanmcdirmid4• 14 years ago

VisualAge Smalltalk begot VisualAge Java which then became Eclipse, although over the transition some things changed a lot (more interop, no images). I think in turn IBM got VisualAge from their acquisition of OTI; Dave Thomas has the history, you could ask him if you ever attend OOPSLA .

kristopolous3• 14 years ago

Execution. Execution. Execution.

Really. Ideas are 1% of the work. Doing the idea is 9%. Doing it well is the other 90%. Different things matter every time, that's what makes it so hard.

fractallyte• 14 years ago

And the missing 'other' 100% is getting anyone to take notice!

One can have the most wonderful, state-of-the-art, mature product - that remains largely unknown by the 'majority' because... well, why?? I still can't figure out this last bit...

(Modern Smalltalk is, unfortunately, a perfect example of this.)

seanmcdirmid4• 14 years ago

This is not useful. Great execution on a bad idea still results in a bad experience. Truly, you need both: great ideas and great execution, you can't just brush ideas off to 1% of the work and expect to win.

sehugg2• 14 years ago

The Microsoft dev tools were important for PCs, but they weren't the only game in town. Lots of people were still using Turbo Pascal and later Delphi -- there weren't a lot of tools that could generate Windows binaries yet. Some people were using DBASE, Foxpro, etc. Watcom C targeted 32-bit DOS extenders which were important for games.

The most important thing was (and still is) that you could easily integrate your the OS and UI framework of choice. Smalltalk couldn't provide that because it tried to replace all that with its own code -- which the implementor would probably further tweak into unrecognizability.

UNIX of course was its own world at this point, but it also was driven by pragmatics. You aren't going to write your MUD in Lisp if its going to thrash your swapfile, or if your friend down the hall can't hack on it with you.

It's also questionable whether these tools were "better". The one time I tried to use VisualAge all I could think about was getting back into my comfy text editor. I am hopeful however that we can eventually improve on the age-old compile/edit/debug cycle.

rbanffy3• 14 years ago

Most of this predates PCs and Microsoft dev tools (unless we are talking about Microsoft BASIC) by a good couple years. When Smalltalk was conceived there was no OS or GUI framework to integrate because all the OS did on a personal computer was file IO and start programs.

jasomill• 14 years ago

One interesting reference on the subject is the final seection of Richard Gabriel's Patterns of Software[1].

And just to play devil's advocate: both Smalltalk and Lisp were designed ex novo to do things that had never been done before on machines that didn't yet exist. In contrast, node.js was built on top of pre-existing languages and tools already familiar to its target audience, to solve broadly similar problems in familiar environments.

Not that there's anything wrong with that — but it's hardly a fair comparison.

[1] http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf

Nutella2• 14 years ago

Most languages were proprietary and expensive through the 80s. When C took off it wiped out (or much reduced) the use of expensive proprietary languages. C was free so a lot of people learned it in university and wanted to use it on the job later because they were used to it. Since it was free it was easy to introduce to companies. It established a base and then when Java came out in 1995, also free but a higher level language than C, it took off like a rocket. Now the idea of expensive proprietary languages seems absurd.

Many tools have been developed that support C-family languages and most programmers depend on those tools. It's a huge job to move out of that and into an image-based language like Smalltalk because everything changes at once. That's a major reason why new frameworks like node.js or Rails can take off quickly now: They fit into most programmers' normal workflow so they are easy to adopt.

I worked in an image-based language in the 80s and it drove me crazy that I didn't have diff and grep. I was glad to leave that language when I moved on to a job that used a conventional text-file language. I'm sure I'm not the only one who found it awkward.

gruseom• 14 years ago

This is interesting:

the closest anyone has ever gotten to creating a full dynamic environment for a C-language platform is Alexia Massalin’s Synthesis operating system. If you are a programmer of any kind, I’ll wager that Alexia’s dissertation will blow your mind

There have to be people on HN who know about this. Tell us more!

Wikipedia [1] says that the Synthesis kernel relied heavily on self-modifying code and that adoption of its techniques was inhibited by its being written in assembly language. That makes sense; it probably relied on the code=data aspect of assembly language, something that (Forth aside) you mostly don't get back until you've left the lower levels well behind.

[1] http://en.wikipedia.org/wiki/Synthesis_kernel#Massalin.27s_S...

delinka• 14 years ago

Is it just my phone or does this Wikipedia link forward iOS devices to the self-modifying code article?

Edit: Not just my phone. But I tend to expect Wikipedia articles to have a title matching the URL unless there's a "redirected from..." subheading and it's just the mobile site that doesn't have that subheading.

spc476• 14 years ago

He wrote special assembly language templates that allowed constant propagation, constant folding and code inlining at run time quickly (at a time when state of the art machines ran around 33MHz to 50MHz).

The actual thesis is mindblowing (I'm currently reading it now). Not only does it create kernel syscalls on the fly, but specialized interrupt handlers that handle only the devices required (if a new device requires an interrupt handler because it's being used, a new interrupt handler with the existing code and the new code is generated).

The generalized system call (TRAP #15, since his machine used the Motorola 68030) was fast, but a user-mode program could designate up to fifteen system calls (per thread) to be called directly via TRAP #0 to TRAP #14. The end result---a system call was about twice as expensive as a native subroutine call (whereas in contemporary Unix systems it was more like 40x-100x times as expensive).

Another reason why the technique of run-time code generation isn't used that much (and is mentioned in the thesis) is that instruction caches are hideously expensive to flush.

But given stuff like TCCBoot (http://bellard.org/tcc/tccboot.html) I think this could be a viable approach to kernels.

(Edit---grammar)

kragen• 14 years ago

Her (at the time, his) kernel had several interesting features. One was run-time code generation. Another was an object system much less indirect than the standard C++ vtable approach; you know,

    mov (%eax), %eax
    mov 16(%eax), %eax
    call *%eax

That involves two memory fetches.

One step less indirect would be to copy the vtable into every object, which of course means that every object could have a separate vtable. Synthesis's quajects are two steps more indirect: every object has a separate copy of every method. So a method call looked like (the 68030 equivalent of)

    add $32, %eax
    call *%eax

No memory fetches.

The fact that every object had its own copy of each method meant that the method could be optimized for that object. If it was more than a few instructions long, you'd want to factor the main body of the method into a regular function, but many methods are not.

One of the interesting features of Quajects is that you can instantiate a quaject not only with its own data but with its own "callouts". In a traditional object system, wherever you have a simple little object, that object implicitly carries within it this whole pyramid of things that it calls, and things that those things call, and so on — allocators, file buffers, system calls, and so on. More flexible languages like Ruby have facilities for temporarily replacing some part of that pyramid, say, for testing. But each call out of a quaject is just as overridable as an instance variable. When you instantiate the quaject, you supply callouts to it.

There are several more interesting features in Synthesis, including lock-free synchronization (not a new invention at the time, but popularized by Synthesis) and PLL scheduling for soft-real-time response. Also, the dissertation is a rollicking good read.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4...

signalsignal3• 14 years ago

There are plenty of Visual Programming paradigms in development today. The XCode Interface Builder, and Visual Studio's stuff as well, handle the tricky layout and placements before it is converted to text for the compiler. But the rest of the development is done through purely textual coding as the visual paradigm becomes exponentially more difficult to manage as the project "grows". So what happens is a hybrid.

rbanffy3• 14 years ago

The tools mentioned have very little with GUI design and a lot with being able to explore and modify the whole system - not just the program - while everything runs.

Do the Squeak by Example tutorial and come back when you finish it.

signalsignal3• 14 years ago

No. ;)

Edit: I just got down voted for replying "No." to a comment on HN. Hah! That's this site in a nutshell for you.

twelvechairs2• 14 years ago

This article has a host of interesting points and references which are great to read, but the one-upmanship of 'its probably been done before' (which seems omnipresent when discussing visual programming) really annoys me, because the upshot of it is to discourage anyone who is interested in this kind of work from pursuing it.

My point is that whilst lots of ideas have been tested before, what hasn't been 'done' is a a visual programming environment that really takes off. And when/if that happens, it will be worth more than 1000 well written research papers and PARC prototypes, and its creators will deserve more success than 1000 academics who have tested some idea (or merely seen someone else try) but never seen it through to widespread adoption....

silentbicycle2• 14 years ago

I came away from it with a very different message: This has been tried many times before, by teams of brilliant people, and you can still find their notes.

Half the problem is that every N years, people bravely try it again...and start from zero, because they didn't do much research. History is full of great ideas that didn't take off because computers weren't fast enough, because touchscreens weren't popular yet, because wireless didn't exist, etc. They often used different names, but there are many brilliant ideas waiting for another dance.

twelvechairs2• 14 years ago

Yes, the article is supportive of new work (like lighttable), but its still very heavy on "we've done it before". The title "Hey Kids, Get Off My Lawn", and the closing sentence "when that new thing comes along, I’ll tell you we built an early version of it at the Media Lab..." pretty much sum up this sentiment that irks me.

silverlake• 14 years ago

You need to learn from the mistakes of the past. Urs Holzle at Google knows more about these systems (he did Self) than most, yet he's not advocating their use either. And certainly Google has the resources to try.

The problem with Smalltalk and Lisp IDEs was no one was using those languages. The other problem is that it didn't help that much when writing code. It helped a lot to navigate and learn a new code base, but after that you just want to stare at text. That's why SLIME is the preferred IDE for Lisp today.

Visual Studio is making steady incremental progress with visual programming. Their Workflow graphical environment is useful for building flowcharts and state machines. Their DB viewers can help construct SQL queries. And GUI builders are visual programming environments. You get help whenever you write a method, it shows all the method signatures, etc. VS and IBM's Rational IDE generates code from UML models. You have a special environment for creating unit tests. I haven't used Eclipse, but they must do many of these things too.

So only some of the Emacs and Vim guys are pining for visual programming. Everyone else is using an adequate tool already.

SoftwareMaven5• 14 years ago

The biggest problem I have with tools like Visual Age and XCode is they want to replace my tool chain. I want it to tie into my tool chain comfortably (I really hope Emacsy[1] succeeds; I would contribute time to that project!).

As I look at Light Table, I really hope they learn a LOT from Emacs:

• Editing is not secondary. In many IDEs, it feels like actually writing code is an afterthought.

• Mice suck[2].

• Allow me to integrate external tools easily.

• Make everything easily customizable and replaceable.

1. http://www.kickstarter.com/projects/568774734/emacsy-an-embe...

2. They are fine for detail-oriented, fine-motor-control work. Coding is not one of those.

seanmcdirmid4• 14 years ago

We can think of desktop modular PCs to small highly integrated ultra books: one allows me to buy my own graphics card, change the harddrive and RAM easily, add new cards, and interface with anything; the other provides some USB ports and calls it a day.

A more integrated experience necessarily means less compatibility with external tools. This can be a big turn off if you need those tools, but it can be a better experience if you don't, so its a trade off. We got a lot of integrated functionality with a Smalltalk IDE and no support for external tooling, they didn't even support the file system and instead went with an integrated image; the experience was completely different than and even diametrically opposed to Emacs. Modern IDEs like Eclipse and Visual Studio make more compromises between the two extremes.

I don't really disagree with your first two points. But mouse/menus has one important purpose: you don't have to remember a bazillion different key bindings to get work done. Ya, developers actually prefer that. Also, there should be some focus on the debugging experience, not just the editing experience, because we spend a lot of time there also.

SoftwareMaven5• 14 years ago

If you want to change software development (as opposed to just making another cool IDE), you have to solve for the modular case. The leaders of the software developer pack are tinkerers and customizes and extenders. Give them a USB port, and you become a tool they put in their tool box, but you haven't changed anything.

On mice/menus, this is a place where emacs got things better than ANY other piece of software ever written: don't make me leave the editing environment. There is no reason navigating hierarchical information and commands needs to be done in menus. In emacs, I can navigate using all the same tools I've already learned for navigating my code, I can search for both command names and command context and execute the command in that context. Especially for something like Light Table, with it's mini-window-things, there is little need for menus. [a note: I'm discussing menus as a UI element, not the abstract notion of hierarchically structured commands implemented another way. Menus are ugly, out of context, and annoying to use. A good information architecture for commands is good.]

A focus on debugging would be good. A tool that could make debugging more efficient would be very valuable.

mkl3• 14 years ago

Mice suck[2].

2. They are fine for detail-oriented, fine-motor-control work. Coding is not one of those.

As someone who has written tens of thousands of lines of code with only a mouse, I would modify this statement to "Mice suck when you are primarily using a keyboard." Editing code is detail-oriented, fine-motor-control work, and in my experience a mouse is better than a touch screen for editing (with current interfaces), and worse for typing code in. I have not done any coding with a keyboard for many years, so I can't directly compare, but I think mouse, with my custom typing system, is easier for many situations. The problems come when you are using both mouse and keyboard.

joncooper• 14 years ago

Tell us more about your mouse-driven custom typing system, please. Sounds interesting.

SoftwareMaven5• 14 years ago

I, too, would be interested to hear more as I'm having difficulty picturing what you mean. My mental picture is "iPad with a mouse", but there is obviously something missing. I'm dubious of the ability to code at least as efficiently with no keyboard as with, but that may be my lack of imagination.

taliesinb• 14 years ago

Am I the only one whose attitude to mice changed when they got a Macbook Air? Having the touchpad so close to the keyboard makes it practically instantaneous to switch modes.

Navigate around and target code with the mouse, edit with keyboard -- it's super effective!

jamesbritt• 14 years ago

This is why I insist on having a trakpoint mouse. It's not simply close to the keyboard, it's part of it.

Sandy_Klausner2• 14 years ago

davesims• 14 years ago

On the other hand, is it possible that the slew of visually-driven programming environments we've seen in the last 30 years or so, running the gamut from Visual Age to Rational Rose, were novel, innovative, and helpful in many ways, but ultimately just not as effective as a coder that knows what she's doing with a lightweight editor and increasingly speedy runtimes on faster and faster CPUs?

joe_the_user3• 14 years ago

That's possible.

But "why" is the sixty-four dollar question.

I think it is reasonable to say these environments gave some programmers the information they thought they needed. But the bare text was more useful. Text and GUI dook-hickies are both pixel-based information. What makes one superior to the other.

joe_the_user3• 14 years ago

This struck me:

Third, screen real estate matters. The traditional “everything is a file” approach is wonderfully portable. You can build an environment for working with files even for a very small display. Heck, you can work with files if all you have is a line-mode terminal. But flexibly arranged code snippets and fully interactive graphical debuggers require a lot of pixels.

I'd go even further. Programming requires a lot of pixels. You want to look at as much code as possible no matter what. Maybe a 10' x 10' screen would be enough but otherwise, there's no limit to what I want for myself, not for some GUI eye-candy. As another post says Editing is not secondary but for me its a matter of never, ever crowding my precious screen real estate, ever.

But by that token, anytime someone tells you their application needs lots of screen real estate is a time when they're admitting they'll waste that real estate doing something I don't care about.

lispm• 14 years ago

I wonder if that really is the case? Are there any useful experiments done comparing screen size?

I would have two questions:

1) how much screen size is ideal? 2) are there better ways to deal with information display than large screens?

I use laptops a lot. I have used 17" laptops and now I have a small one. I don't feel that productive on the small screen. That's subjective.

I use an external screen. A 30" screen. Am I more productive? On larger screens my main field of view is not much larger. I have to move the head to see things at the edges.

One thing which might be more productive is instant switching between contexts on the screen. For example switching between a debugger view and an editing sessions easily and fast. That might be better on a certain screen size, than having both the debug and edit version on the same screen - but each smaller. Sometimes programmers add another monitor, so they can put these things on different monitors. But is it really better to look to another monitor, instead of just switching the context on the one you are currently looking at?

joe_the_user3• 14 years ago

You know, I really don't know whether more screen space makes you more productive. I actually suspect that question matter less than you'd think in terms of the question at hand (whether "visual" workspace will be accepted by programmers).

I was simply saying that I and I suspect many typical programmers want this screen space and will become annoyed at programs which stand against it. IE, put a widget between me and the data I really want and you'll soon see me not using your application. Will this preference make me more or less productive? That's a further question.

On the other hand, I happen to think a second monitor is a great recipe for disabling neck injuries. But that is my rather particular view based on my studies of effective and ineffective postures.

6ren• 14 years ago

  > You want to look at as much code as possible

I'm a big-screen skeptic. An art in programming is abstraction, enabling you to grasp complexity in small pieces. Seeing more doesn't enable me to grasp more. (There are non-code exceptions: rendered output, docs, etc)

Sandy_Klausner2• 14 years ago

The Once and Future Visual Programming Environment

Related Stories