views:

121

answers:

4

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

+3  A: 

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.

Uri
A: 

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!

Duracell
You mean SubEthaEdit? http://www.codingmonkeys.de/subethaedit/index.html
ddimitrov
@ddimitrov: Yipee!
Duracell
um, current systems are git and hg. svn was the previous generation, and stuff like cvs or tfs are the generation before that. the technology is way better now, don't need to deal with locked files like cvs, and barely ever have to manual merge like svn, and if i want to get the changes of someone else before they push to the mainline, i can.
Matt Briggs
@Matt Briggs: If you work in a Microsoft house, you are stuck with TFS.
Duracell
If you work at TFS house, you're stuck with TFS. I work at a company that uses a Microsoft software stack (C#/.NET, IIS, Windows Server, etc.) and we use Hg, and love it. Works great on Windows.
Ken
I worked at a microsoft gold partner for years, where they were using svn when I got there, and started looking at moving towards mercurial by the time I left. The svn change happened before I got there, but the hg change was prompted by our source repo getting corrupted (and the week of hell that followed), and dealing with horrible merging when coordinating changes with our designers. I would agree that it is pretty common to see TFS, but that doesn't mean its universal (we were the kind of shop that even used the bad stuff, as long as it came from ms)
Matt Briggs
+1  A: 

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.

Matt Briggs
Your comment about compiler speed is a strange one. If your language has a repl (by D.1), then I'm betting it can do incremental compilation, and I don't know why you'd ever want or need to compile 500KLOC at one go. For example, I'm using SBCL now, and it isn't the fastest compiler in the world, but I can't remember the last time I needed to compile more than 20 lines (1 function) at a time. Sure, it takes a whopping 40ms to compile one function on my laptop, but alternatively, it does all that I need in only 40ms.
Ken
I've never used a language with incremental compilation before, but that would mitigate the issue I was talking about. If you are tracking down a bug by doing the code/compile/test dance, every second that middle step takes is a big deal. I am a web guy, my last job, compile times for our projects were anywhere from 45 seconds to 2 minutes. 2 minutes makes it hard to keep momentum up, especially compared to the experience of code change, alt-tab, reload experience.
Matt Briggs
after wikipedia-ing sbcl (and finding out it is a cl dialect), it turns out I HAVE experienced incremental compilation before (with clojure), I just have never used any lisp in serious way. You are completely correct though, issues with compilation times go away. Also, the whole REPL oriented development thing you get with emacs + SLIME is (IMO) the most advanced way of doing this that anyone has come up with yet. Really wish there were more lisp jobs available...
Matt Briggs
A: 

Zero Button Testing is my entry.

Carl Manaster