IDE – How to Develop in More Languages with Fewer IDEs

Smalltalk - a highly dynamic language - has always had a superb IDE, in which little things like automatic refactoring, SUnit (the grandparent of all *Unit frameworks), "who sends this message?", "who implements this method?" and the like were pioneered. So yes, IDEs can indeed support dynamic languages to a level that, until very recently, far surpassed those of statically typed languages.

S. Lott says that "Dynamic languages cannot have the same kind of code completion that static languages do. It's essentially impossible."

"Essentially impossible" in a theoretical, absolutist sense? Sure. In a practical sense? Not really. There are many ways to infer type for dynamic languages, statically (k-CFA, RoelTyper), at run time (PICs), and other methods, like using a programmer's recent history - "How Program History Can Improve Code Completion".

Certainly the Pharo and Squeak communities are very happy with their code completion tools.

I prefer your colleagues way because your process:

• Creates a lot of clutter on your desktop
• Switching/creating branches has more work involved. Have to pull branch into new directory, create a new workspace, switch IDE to new workspace
• Arguably just as messy and confusing as the alternative. You will probably forget to switch workspaces from time to time and accidentally make a bunch of changes that you have to migrate to another directory.

The upside to your method is that you can have changes to the working copy on multiple branches without committing them, but for your colleague they would have to either commit their changes or try to temporarily stash them before switching branches.

Once you migrate to Git using the stash feature or committing locally is a great solution to that one drawback to your colleague's preference, and definitely using one workspace is the most common way in Git.

It's ignorant of your colleague to grill you on this. SVN doesn't have an "intention" for Eclipse workspaces. They're completely unrelated. Developers should choose the process that is most comfortable to them and least likely to make mistakes with.