The Once and Future Visual Programming Environment
techcrunch.com
techcrunch.com
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.
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.
My software is like an on-screen keyboard with context-sensitive prediction, more sensible orientation and layout, and lots of shortcuts overloaded on the buttons, operated by the other mouse buttons and the scroll-wheel. So, for example, moving a word/page at a time, selecting lines/files, unindenting, etc. are just done by scrolling in the right place, control-A is middle-clicking A, and so on (the program just sends the appropriate keystrokes to make things happen). Selecting and toolbars/menus are fast because you're already using the mouse, and copy and paste is just select and middle click on Linux.
RSI basically forced me to develop the system (I can't use a physical keyboard, and no existing software was or is good enough), and I have been using it for all my typing since 2003. I'm now working on making a commercial version aimed primarily at touch screens (gestures will replace different mouse buttons).
I'm not sure that there's much more to it than what I've already described. I think what it's got going for it is refinement driven by nine years of dogfooding day in day out, and that refinement isn't easy to describe as it's just many tiny little choices.
Navigate around and target code with the mouse, edit with keyboard -- it's super effective!
If a trackpoint was not available, I would prefer the following layout:
1) Keyboard with the number pad moved to the left and an integrated trackpad on the right side (centered slightly above home row).
OR (w/out integrated trackpad)
2) [For right handed folks] Keyboard with number pad on left and mouse on right.
The goal being to minimize the distance moving your fingers to the 'mouse zone' while still remaining on home row. The number pad on the right (for right handers) takes up too much space.
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.
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.
Now, whether developers would prefer a more integrated experience is either unknown or known to be false (wrt current technology). One of the reasons my version of the Scala IDE failed was that I was focusing too much on the editing experience whereas the community really wanted integration with every little dinky Java tool you could imagine.
Emacs is not perfect (far from it!). There are many places where some graphics would go a long way towards improving the UI. Re-implementing emacs would be a bad idea, but learning what works (eg everything is a buffer, everything is easily [for a prorammer] extensible) will go a long way towards making an improved replacement.
My rant on menus is not about "it should be in the shell". I'm fine with the context being different. I just want my interactions to be the same. If I am searching for some code or searching for some editor command, the context is different but the interaction is the same. Every other piece of software makes the interaction different.
I point at emacs, but vi is another good example (just with a different implementation). And I don't want to disparage what the VisualAge folks did (I never saw the smalltalk stuff, but even the much-less-mature java stuff was amazing). But it didn't stick. Why is that? Once they answer that (I've given my opinion, but I could very easily be wrong), they'll be able to change the software development.
The kickstarter made it sound like Light Table would revolutionize programming. I'm all for that, but what I've seen so far doesn't do this. Instead, it makes a really cool tool. There is nothing wrong with that (I use a lot of them), and if that's the case, I'll shut up. :)
I'm passionate about this because, in the end, emacs, vi, and every IDE I've used are far from ideal. I want to uninstall emacs and never look back.
Deleted comment
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.
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?
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.
> You want to look at as much code as 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.
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...
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)
mov (%eax), %eax
mov 16(%eax), %eax
call *%eax
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
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...
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.
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....
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.
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.
* http://en.wikipedia.org/wiki/Selectric
The idea has many things going for it, and is worth another go in the era of touchpads and graphic interfaces. APL has always had a die-hard following, and intriguing ASCII offshoots such as J and K, but it's time for a second chance.
The APLs have many other interesting aspects (they're all about data-parallelism and functional programming of a different flavor than Lisp and Haskell), but to my knowledge nobody has sincerely retried the glyph-based language thing again.
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.
Do the Squeak by Example tutorial and come back when you finish it.
Edit: I just got down voted for replying "No." to a comment on HN. Hah! That's this site in a nutshell for you.
I regard it as a feature rather than a bug.
Do you even know what advice(1) is? That's not advice as I understand it. That's an order. You're giving orders to a complete strange on a web forum. Think about the intelligence behind that for a second.
My comment on this site was referencing the comment by Paul Topping(2) on the TC link. His opinion, and one I agree with, is that Visual Languages become too cumbersome for anything but small projects, and my example is using Visual Programming for layout. The XIB's are XML in XCode.
1) http://dictionary.reference.com/browse/advice
2) http://techcrunch.com/2012/05/27/hey-kids-get-off-my-lawn-th...
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.
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.
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.
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.)
It is the holistic picture that constitutes success. That's the "other 90%" and it's a black art.
Let's take youtube; "I want to watch a video on demand". Really? What a brilliant 1920s style idea I've never heard before. It was how they pulled it off that matters.
What about an iphone/android? "I want one device that works as a PDA and a phone that does everything I need." Really? Never heard that idea before.
Every now and then someone comes along with a truly innovative and truly brilliant idea; and may God Help Their Soul.
I've personally suffered from being ahead of the curve many times. Or was it bad execution? In 2002, I had this AIM bot that you would send small messages too, then it would be posted on a website under your AIM name. You could follow your AIM buddies and see their messages.
Yeah, it's called twitter. I did it on top of AIM in 2002. In 2003 I did another bot that would proxy messages between anonymous users. Yep, you heard of that too, it's called Omegle.
Then in 2003 I did a multiplayer extension to an NES emulator that utilized DCC irc connections so that you could in an Fserve style, play random people well known games in IRC.
Sounds familiar? not yet. There will be a node.js/socket.io version of this soon by someone, I know it.
So yeah, even with novel ideas, I still think the 1/9/90 rule plays. In the 90 here is the very important element of timing, along with, of course, target audience.
So I'm not trying to brush off the necessity of true ideas, just trying to minimize the importance of it. Look around, many of the successful things that we use are totally void of true innovation (as in, I'm not using the First One). The desk I sit at, the monitor I use, the keyboard I type on. They are just decently executions of old ideas.
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.
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.
Deleted comment