The Once and Future Visual Programming Environment • Hacker News Board

Re: The Once and Future Visual Programming Environment

#21

Post by mkl » Mon, May 28, 2012, 2:03 AM UTC

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…

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

Re: The Once and Future Visual Programming Environment

#22

Post by fractallyte » Mon, May 28, 2012, 2:04 AM UTC

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.

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

Re: The Once and Future Visual Programming Environment

#23

Post by Nutella2 » Mon, May 28, 2012, 2:16 AM UTC

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…

Most languages were proprietary and expensive through the 80s. When C took off it wiped out (or much reduced) the use of expensive proprietary languages. C was free so a lot of people learned it in university and wanted to use it on the job later because they were used to it. Since it was free it was easy to introduce to companies. It established a base and then when Java came out in 1995, also free but a higher level language than C, it took off like a rocket. Now the idea of expensive proprietary languages seems absurd.

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.

Re: The Once and Future Visual Programming Environment

#24

Post by rbanffy » Mon, May 28, 2012, 2:41 AM UTC

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.

Re: The Once and Future Visual Programming Environment

#25

Post by rbanffy » Mon, May 28, 2012, 2:49 AM UTC

sehugg wrote: post #15

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

Re: The Once and Future Visual Programming Environment

#26

Post by joncooper » Mon, May 28, 2012, 3:04 AM UTC

mkl wrote: post #21

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…

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…

Tell us more about your mouse-driven custom typing system, please. Sounds interesting.

Re: The Once and Future Visual Programming Environment

#27

Post by SoftwareMaven » Mon, May 28, 2012, 3:19 AM UTC

mkl wrote: post #21

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…

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.

Re: The Once and Future Visual Programming Environment

#28

Post by SoftwareMaven » Mon, May 28, 2012, 3:30 AM UTC

seanmcdirmid wrote: post #18

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

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

Re: The Once and Future Visual Programming Environment

#29

Post by JohnQPasserby » Mon, May 28, 2012, 3:57 AM UTC

seanmcdirmid wrote: post #18

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

It can be a better experience, but in the vast majority of cases I have encountered it is not.

It was also my understanding that IDEs like Smalltalk/Emacs seem to be favored because they are highly modifiable, not because they are integrated.

Re: The Once and Future Visual Programming Environment

#30

Post by seanmcdirmid » Mon, May 28, 2012, 4:02 AM UTC

SoftwareMaven wrote: post #28

seanmcdirmid wrote: post #18

Earlier quoted context omitted.

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

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 commands, but this would have its own usability problems. I think the Cloud9 team is getting this more right by simply being more minimal in their design.

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.