There was a very interesting question posted on TheServerSide, "What would make you change languages?" and for me the answer is simple, Tool Support. I have used Groovy and it was kinda neat, but content assist didn't work very well. Possibly because of some bugs or maybe the language is just too dynamic to fully support this feature. I have used JavaScript and 3 of us spent a 1/2 hour tracking down a extra character (we tried to call a method Foo=(arg1, arg2)), bad place to put an equal sign.
Back in my undergraduate days, life was simple. All I needed was vi and a command line. I was happy and I figured if you needed a tool to do your job then you were never going to be a "real" software engineer. Seven years later (and the Eclipse influence) this has changed. What does looking up a method signature somewhere really do for me? What does spending my time tracking down a runtime error that really should have been caught at compile time accomplish?
Sure, a lot of new languages have shorter syntax for common operations, all intended to save me a few keystrokes. Let's count:
var person = new Person; (about 15 keystrokes)
Person person = new Person(); (about 10 keystrokes)
See, with proper tool support I would use content assist and type P(content-assist) p(content-assist) = (content-assist) P(content-assist);[enter].
And it is not just content assist. It is refactoring, search, navigation, debugging, analysis and collaboration. It seems that some languages are easier to write tools for than others. Java and Javascript are almost the same age; why isn't there top notch tooling for Javascript (something like the JDT)?
I'll continue to try out new languages, but without excellent tool support, I'm not changing languages anytime soon.
Anyways, to each their own!
Back in my undergraduate days, life was simple. All I needed was vi and a command line. I was happy and I figured if you needed a tool to do your job then you were never going to be a "real" software engineer. Seven years later (and the Eclipse influence) this has changed. What does looking up a method signature somewhere really do for me? What does spending my time tracking down a runtime error that really should have been caught at compile time accomplish?
Sure, a lot of new languages have shorter syntax for common operations, all intended to save me a few keystrokes. Let's count:
var person = new Person; (about 15 keystrokes)
Person person = new Person(); (about 10 keystrokes)
See, with proper tool support I would use content assist and type P(content-assist) p(content-assist) = (content-assist) P(content-assist);[enter].
And it is not just content assist. It is refactoring, search, navigation, debugging, analysis and collaboration. It seems that some languages are easier to write tools for than others. Java and Javascript are almost the same age; why isn't there top notch tooling for Javascript (something like the JDT)?
I'll continue to try out new languages, but without excellent tool support, I'm not changing languages anytime soon.
Anyways, to each their own!
4 comments:
Take a look at JSDT in Webtools 3.0 for JDT like Javascript editing.
Thanks David, I will check it out... I am always interested in how developers are creating tools for languages that have much looser rules than Java. In my example (Foo=(arg1, arg2)) this is syntactically correct, but probably not what you want to do.
A while ago, some people were tossing out the idea of have a "strict" mode in the editor, so things like this could be flagged as potential errors. Not sure how well that would work in practice.
I agree. Scala is a cool language, but the IDE support isn't there right now; at least, from a finished/polished perspective. It will take availability of a decent editor to make people want to use it.
I agree mostly, although I've started to use Scala on personal projects and I hope that Scala gets the same level of tool support as Java and ends up being the best of both worlds.
Post a Comment