开发者

Experimental IDE concepts

I am interested in building a new style IDE for a side project. Mainly to do away with the normal notepad on steroids IDE. I am looking for some inspiration for things that have been tried or that you have seen (or not) that looked cool and would be useful to have in an IDE. Things th开发者_如何转开发at I can up with are:

http://digitaltools.node3000.com/blog/1052-field-experimental-programming-suite

http://www.cs.brown.edu/people/acb/codebubbles_site.htm


Andrew Ko (formerly CMU, now professor at U Wash) focused much of his dissertation on allowing folks to debug by asking "Why did something happen" or "why he did not". The project was called WhyLine and he even had a version for Java.


I am probably a terrible person to talk about this, since I find using IDEs like programming with lead weights on my arms, but I figure it may be useful to get the perspective of that side of the fence. Any interesting or experimental ideas people come up with still need to deal with the basic needs of developer tools.

An IDE is typically an editor of some sort, a debugger, and a compiler. Since those are three distinct parts of the tool, I'll run through them seperately

Here is what I want from an editor

  1. be fast. i never want to be waiting for things to load. ever.
  2. give me powerful ways to manipulate and jump around in the code. I don't care about learning curves when it is a tool I use for probably 10 hours a day on average, the flip side is I don't want to waste my time getting good at tools that aren't powerful.
  3. give me a decent way to open files. open file dialogs aren't good enough, neither are project trees.
  4. good support for having many things open at the same time. i have a 27" screen, tabs are nowhere near enough. currently I live with splits, but it wouldn't be hard to come up with something better.
  5. never make me touch a mouse while editing code. again, I don't care about learning curve, what I want is speed, efficiency, and power.
  6. If you give me a visual designer, it better make me more productive then typing, while producing code with the same level of flexibility as I am able to produce with text. I have yet to find a visual designer that does this, every one I have ever used basically lowers the bar to learning how to do something, but makes you pay down the road in maintainability and flexibility. I consider every single example of programming by drawing pictures that I have so far as a failure, if used for serious purposes (i.e. not just banging something out and not caring about quality)
  7. automated refactorings. I am using vim now, and the one thing I miss is being able to extract methods from other methods, or hit a button to rename something and feel safe with what the tool will do.
  8. code analysis. I want to see syntax errors as they happen, see if I am typing redundant code, or see suggestions if there is a better way to do something.
  9. great test runner. I practice TDD, and poor test runners drive me up the wall, since it has such an impact on everything I do.

what I want from a debugger

  1. a REPL. this drove me insane when I was stuck with visual studio, and I probably spent more time in the immediate window then anyone else on the team. The whole point of a debugger is the ability to explore what is going on during execution, if I can't type arbitrary code and see what it evaluates to, I feel like I have one hand tied behind my back
  2. ability to change code on the fly, although with a decent REPL and language, that sort of takes care of itself
  3. ability to move backwards and forwards in execution.
  4. speed, dont make me wait
  5. good ways to jump around in the code. if I am at line 1, and want to jump to line 500 to see what is going on, I should be able to do that

what I want from a compiler

  1. speed, at least in development mode. google go is able to compile 500, 000 loc in milliseconds on a laptop, that is what I am talking about. If the language needs to be compiled, every second staring at compiler output is just making it harder to do whatever it is you are doing (tracking down a bug, testing a feature, running tests, etc)
  2. you need some way to hook into arbitrary methods for pre and post execution, or pre processing of your code files in a more general way (think lisp reader macros). if you can't do it with the language, you need to be able to do it with the compiler
  3. good analysis. tell me where i screwed up at compile time if you can't catch it before
  4. transparency. i really don't even want to know its there, unless I am directly interacting with it.

What I have

Currently, I use vim, which gives me 1, 2, 3 (with fuzzyfinder.vim/rails.vim), 4, 5, and a very poor 8 (with syntastic.vim). I don't have refactorings or code analysis, and I really miss it, but IMO it is more then worth the tradeoff.

for debugging, I use ruby-debug, which really isn't that great. basically you get 1, 2 (more cause of ruby then ruby-debug), and 3, but thats it.

Don't use a compiler anymore (thank god), but not using one after having to use one for 7 years (at least professionally) really highlights what a terrible impact they have on the development process.


How about interactive code changes across networks? So you make a change to the code and the change is automatically updated on your buddy's machine across the room. Could make for some interesting development techniques. Would probably result in complete chaos, but hey! It's an idea!

Edit: I'll expand on this. Current repository systems like SVN or TFS can get just plain annoying when dealing with conflicts. If changes that another developer made could be immediately reflected in your system, possibly highlighted in some way, then it would be easier to know what not mess with.

Further, it's a real pain when I edit one function of a class and another developer adds a function to the class so TFS detects a conflict and I have to manually resolve it. What would be cool would be the ability to obtain a lock not on a specific file but a specific scope. So I could check out a function and leave the rest of the file open to editing!


Zero Button Testing is my entry.


The ideas that I add to the mix, are:

TouchDevelop, Real-time and grid based Continuous Integration, Formal Verification (Why3, ITI0060)

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜