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

31–40 of 58 posts

Re: The Once and Future Visual Programming Environment

#31

Post by seanmcdirmid »

kristopolous wrote: post #12
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.

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.

Re: The Once and Future Visual Programming Environment

#32

Post by davesims »

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?

Re: The Once and Future Visual Programming Environment

#33

Post by sehugg »

rbanffy wrote: post #25
sehugg wrote: post #15

Earlier quoted context omitted.

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

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.

True enough, and there's an interesting history of Smalltalk on early Apple computers that I wasn't aware of: http://basalgangster.macgui.com/RetroMacComputing/The_Long_V... Makes sense, since you can see the Smalltalk influence today in Objective-C.

Re: The Once and Future Visual Programming Environment

#34

Post by silentbicycle »

vinodkd wrote: post #20
twelvechairs wrote: post #16

Earlier quoted context omitted.

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

Another example: APL used a bunch of mnemonic symbols for operators -- for example, the "reverse" operator is a circle with a vertical line through it. Mirror image. This made sense back in 1962, with Mad Men-era Selectric typewriters* , but it never sat comfortably with ASCII. Very dense, expressive code. Like thinking in kanji, after a lifetime of alphabetic hackery.

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

Re: The Once and Future Visual Programming Environment

#35

Post by taliesinb »

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…

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!

Re: The Once and Future Visual Programming Environment

#36

Post by SoftwareMaven »

seanmcdirmid wrote: post #30
SoftwareMaven wrote: post #28

Earlier quoted context omitted.

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…

I think you are voicing an opinion and not facts. Emacs is the ultimate modular IDE, yet its not that popular! I was a big emacs fan in the past; but I've gotten used to graphical IDEs enough that I wouldn't consider going back. I'm sure many developers feel the same. Menus...you don't use them very often and I could imagine replacing that with an emacs like shell line with appropriate auto-completion for finding com…

I'm totally expressing opinion. :) I believe it is opinion grounded in 20 years of experience, but it is opinion none the less. In that time, I've gone from emacs to Visual Studio to multiple java IDEs and finally landed back on emacs.

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.

Re: The Once and Future Visual Programming Environment

#37

Post by mkl »

SoftwareMaven wrote: post #27
mkl wrote: post #21

Earlier quoted context omitted.

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

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

Re: The Once and Future Visual Programming Environment

#38

Post by jamesbritt »

taliesinb wrote: post #35
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…

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.

Re: The Once and Future Visual Programming Environment

#39

Post by joe_the_user »

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.

Re: The Once and Future Visual Programming Environment

#40

Post by signalsignal »

rbanffy wrote: post #24
signalsignal wrote: post #6

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.

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.

Post reply on HN