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

51–58 of 58 posts

Re: The Once and Future Visual Programming Environment

#51

Post by joe_the_user »

lispm wrote: post #41
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.…

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.

Re: The Once and Future Visual Programming Environment

#52

Post by joe_the_user »

davesims wrote: post #32

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?

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.

Re: The Once and Future Visual Programming Environment

#53

Post by signalsignal »

rbanffy wrote: post #47
signalsignal wrote: post #40

Earlier quoted context omitted.

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.

> Do the (thing above) and come back when you finish it.

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

Re: The Once and Future Visual Programming Environment

#54

Post by SoftwareMaven »

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…

Sounds interesting, and a step in the right direction for re-thinking the way people write software. I look forward to seeing something in the future.

Re: The Once and Future Visual Programming Environment

#56

Post by Sandy_Klausner »

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…

No post body was provided.

Re: The Once and Future Visual Programming Environment

#57

Post by Sandy_Klausner »

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…

Gentlemen,

A Google alert brought your forum to my attention this morning and it all makes for an interesting read. My reference to graphical programming dates back over 25 years when I used a homegrown icon-based language to develop a distributed building automation platform that has sold over $2B worth of systems across 40,000 facilities worldwide. After I sold www.Novar.com to Honeywell, I have been developing a future software development infrastructure that fully utilizes visual computing for the emerging Internet of Things (IoT). www.CoreTalk.net provides a list of the Cubicon IoT Infrastructure Capabilities. Your thread points are well taken and I am familiar with all the issues including knowing and interacting with the likes of Dave Thomas and Dick Gabriel who can attest to the credibility of my work.

Let me start by making two points: First, why is software development the ONLY domain left that does not fully utilize visual representations? I claim that all the examples that you cite remain early attempts at mastering visual abstractions for ‘software engineering’ that desperately needs to evolve to a ‘systems engineering’ discipline to manage modern complexities. Many objectors to graphical programming point to the ease of editing with text when there are SO many other issues that need to be addressed in current and future complex network computing ecosystems such as the IoT.

Re: The Once and Future Visual Programming Environment

#58

Post by Sandy_Klausner »

jasomill wrote: post #19
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…

Gentlemen,

A Google alert brought your forum to my attention this morning and it all makes for an interesting read. My reference to graphical programming dates back over 25 years when I used a homegrown icon-based language to develop a distributed building automation platform that has sold over $2B worth of systems across 40,000 facilities worldwide. After I sold www.Novar.com to Honeywell, I have been developing a future software development infrastructure that fully utilizes visual computing for the emerging Internet of Things (IoT). www.CoreTalk.net provides a list of the Cubicon IoT Infrastructure Capabilities. Your thread points are well taken and I am familiar with all the issues including knowing and interacting with the likes of Dave Thomas and Dick Gabriel who can attest to the credibility of my work.

Let me start by making two points: First, why is software development the ONLY domain left that does not fully utilize visual representations? I claim that all the examples that you cite remain early attempts at mastering visual abstractions for ‘software engineering’ that desperately needs to evolve to a ‘systems engineering’ discipline to manage modern complexities. Many objectors to graphical programming point to the ease of editing with text when there are SO many other issues that need to be addressed in current and future complex network computing ecosystems such as the IoT.

Post reply on HN