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

41–50 of 58 posts

Re: The Once and Future Visual Programming Environment

#41

Post by lispm »

joe_the_user wrote: post #39

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

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?

Re: The Once and Future Visual Programming Environment

#42

Post by arvidj »

mkl wrote: post #37
SoftwareMaven wrote: post #27

Earlier quoted context omitted.

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.

The thing about coding is there's lots of thinking. I can write code efficiently because after a point, raw typing speed is not very important. I'm much less efficient at, say, copying out prose that's already written (unless my prediction engine is familiar with it...). My software is like an on-screen keyboard with context-sensitive prediction, more sensible orientation and layout, and lots of shortcuts overloaded…

Screenshots and more information would be very nice!

Re: The Once and Future Visual Programming Environment

#43

Post by 6ren »

joe_the_user wrote: post #39

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

  > 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)

Re: The Once and Future Visual Programming Environment

#44

Post by deskamess »

jamesbritt wrote: post #38
taliesinb wrote: post #35

Earlier quoted context omitted.

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!

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

Agreed.

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.

Re: The Once and Future Visual Programming Environment

#45

Post by mkl »

arvidj wrote: post #42
mkl wrote: post #37

Earlier quoted context omitted.

The thing about coding is there's lots of thinking. I can write code efficiently because after a point, raw typing speed is not very important. I'm much less efficient at, say, copying out prose that's already written (unless my prediction engine is familiar with it...). My software is like an on-screen keyboard with context-sensitive prediction, more sensible orientation and layout, and lots of shortcuts overloaded…

Screenshots and more information would be very nice!

As far as looks go it's as you'd expect, a grid of letter and symbol buttons, and a list of predictions. I don't think it's a good idea to disclose the few interesting features until I have something on sale (right now they're a competitive advantage), so sorry, no screenshots :-P

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.

Re: The Once and Future Visual Programming Environment

#46

Post by kragen »

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…

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...

Re: The Once and Future Visual Programming Environment

#47

Post by rbanffy »

signalsignal wrote: post #40
rbanffy wrote: post #24

Earlier quoted context omitted.

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.

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.

I think it's a matter of attitude. Your response didn't add anything to the discussion, you seemed to refuse perfectly valid advice (by your message, you didn't read - or understand - the original article and the advice I gave you, while given in a more than a little condescending tone - sorry for that - would enlighten you) and people around here don't really welcome that.

I regard it as a feature rather than a bug.

Re: The Once and Future Visual Programming Environment

#48

Post by kristopolous »

fractallyte wrote: post #22
kristopolous wrote: post #12

Earlier quoted context omitted.

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.

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.)

I toss the "take notice" into the execution pile. That's why it's 90% of the work. That includes understanding why brands fail regardless of the quality of the good or service. It includes understanding the pains of your userbase, the expectations they have going in, and what you have to do in order for them to converge and spread your technology in an organic manner.

It is the holistic picture that constitutes success. That's the "other 90%" and it's a black art.

Re: The Once and Future Visual Programming Environment

#49

Post by kristopolous »

seanmcdirmid wrote: post #31
kristopolous wrote: post #12

Earlier quoted context omitted.

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.

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.

Surely. I think I'm a bit bitter from all of the would-be-CEOs that have a wonderful idea and just need the rock-star programmer to um, do the design, engineering, QA, customer feedback loop, product definition, you know, the actual work.

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.

Re: The Once and Future Visual Programming Environment

#50

Post by silverlake »

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…

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.

Post reply on HN