5 ms·

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

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 me to integrate external tools easily. • Make everything easily customizable and replaceable. 1. http://www.kickstarter.com/projects/568774734/emacsy-an-embeddable-emacs 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.

seanmcdirmid 14y ago
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 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.
- SoftwareMaven 14y ago
  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.
  - seanmcdirmid 14y ago
    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.
    - SoftwareMaven 14y ago
      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.
- JohnQPasserby 14y ago
  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.
mkl 14y ago
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.
- joncooper 14y ago
  Tell us more about your mouse-driven custom typing system, please. Sounds interesting.
- SoftwareMaven 14y ago
  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.
  - mkl 14y ago
    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).
taliesinb 14y ago
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!
- jamesbritt 14y ago
  This is why I insist on having a trakpoint mouse. It's not simply close to the keyboard, it's part of it.
  - deskamess 14y ago
    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.
Sandy_Klausner 14y ago
Sandy_Klausner 14y ago
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.

seanmcdirmid 14y ago

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

SoftwareMaven 14y ago
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.
- seanmcdirmid 14y ago
  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.
  - SoftwareMaven 14y ago
    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.
JohnQPasserby 14y ago
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.

mkl 14y ago

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.

joncooper 14y ago
Tell us more about your mouse-driven custom typing system, please. Sounds interesting.
SoftwareMaven 14y ago
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.
- mkl 14y ago
  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).

taliesinb 14y ago

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!

jamesbritt 14y ago
This is why I insist on having a trakpoint mouse. It's not simply close to the keyboard, it's part of it.
- deskamess 14y ago
  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.

Sandy_Klausner 14y ago

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.