Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Once and Future Visual Programming Environment

techcrunch.com

Post reply on HN
Print view View original

11–20 of 58 posts

Re: The Once and Future Visual Programming Environment

#11

Post by delinka »

gruseom wrote: post #4

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 tha…

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.

Re: The Once and Future Visual Programming Environment

#12

Post by kristopolous »

chubot wrote: post #3

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…

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.

Re: The Once and Future Visual Programming Environment

#13

Post by spc476 »

gruseom wrote: post #4

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 tha…

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)

Re: The Once and Future Visual Programming Environment

#14

Post by silentbicycle »

twelvechairs wrote: post #9

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…

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.

Re: The Once and Future Visual Programming Environment

#15

Post by sehugg »

chubot wrote: post #3

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…

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.

Re: The Once and Future Visual Programming Environment

#16

Post by twelvechairs »

silentbicycle wrote: post #14
twelvechairs wrote: post #9

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…

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, b…

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.

Re: The Once and Future Visual Programming Environment

#17

Post by SoftwareMaven »

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.

Re: The Once and Future Visual Programming Environment

#18

Post by seanmcdirmid »

SoftwareMaven wrote: post #17

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…

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.

Re: The Once and Future Visual Programming Environment

#19

Post by jasomill »

chubot wrote: post #3

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…

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

Re: The Once and Future Visual Programming Environment

#20

Post by vinodkd »

twelvechairs wrote: post #16
silentbicycle wrote: post #14

Earlier quoted context omitted.

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, b…

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.

if you're interested in visual programming environments and try to look up prior efforts at all, you WILL find this sentiment to be true. It's somewhat depressing actually. You'll not just find all these cool sounding environments from the 80s that seemed light years ahead of today (or even something like Light Table), but you'll also find studies on the difficulties people faced with them and why they failed.

Text is not an easy thing to dislodge from the programmer's toolset.

My personal opinion keeps switching between "Text is basic and elemental, so it's the most natural way to represent code and therefore is the preferred" and "We havent built tools good enough or representations revolutionary enough (or scalable enough) and that's why text remains preferred".

I can see how someone who's built a non-textual programming environment can come to a "been there, done that" kind of attitude. Just take his enthusiasm at new attempts at the problem as a more pertinent response and ignore the rest.

Post reply on HN