Interesting, I was looking at this page that says he last logged in on July 21st. Obviously wrong if he posted 16 days ago. It seems development on the plugin has slowed of late and I thought an absence of one of the devs might explain it.
Ah. I was wrong about being able to tell when people log in here.
But I was referring to the Scala-Tools mailing list. Surely if you're serious about Scala you monitor the primary communication forums for Scala programmers? This board is really just about the IDEA plug-in.
See http://www.scala-lang.org/node/199 for a full list of the Scala-related mailing lists.
Thank you for the link, Randall. I'm serious enough about Scala to have read Pollak's _Beginning Scala_ and Odersky, Spoon and Venners' _Programming in Scala_, but I am waiting to invest more energy until a mature Scala IDE develops. So far neither the IntelliJ, Eclipse nor Netbeans Scala plugins are comprehensive enough (IMHO) for me to suggest that my group at work consider Scala as a language to explore for our commercial projects.
I very much appreciate that all the major Java IDE platforms have Scala plugin development, but have found that, in each case, that development is sadly lacking in production.
Don't get me wrong, I've read that Scala is a very difficult language to develop a high quality IDE for. And I recognize that each platform's Scala plugin team is sorely lacking in developers - not developer skill. It is precisely for that reason that when one of those few developers appears to have dropped off the grid, I take unhappy notice.
Well, personally I think you have the cart before the horse. IDE support is a poor criterion for choosing a language. Scala is a lot harder for an IDE to support than it is to learn to use well enough to reap its advantages. Anyway, IDEA's Scala support is more than adequate to facilitate day-to-day programming. My project is currently at about 15 KLOC (all Scala) and all written over the past 8 months using IDEA (and SBT). I'd never use Java again, I don't think, if it were purely up to me.
Let me address two of your points:
1. IDE support is a poor criterion for choosing a language
I'm not a programmer from "back in the day", but I have been around long enough to see the transition of the majority of software developers from "light" IDEs like Emacs to the current generation IDEs that: refactor, auto-compile, warn of suspect code, generate test cases, etc. These features are indispensable to productive software development. Yes, we could do it like was done 15+ years ago, but we'd hamstring ourselves by incidentally introducing silly bugs doing those things IDEs are much better doing - and, in the process, we'd be wasting time we could be spending on "real" development (not the menial stuff). Without IDEs: increased development time and more bugs - that's a double whammy!
Now I'd agree with you if you said after reading the last statement that, "but that's why Scala is so great. It cuts out on so much boilerplate code that you don't need an IDE that wipes your nose for you!" And If I were a CTO who could command my developers to learn Scala (and wait for the ramp up period), I'd be mighty tempted. I do think Scala is a more readable and expressive language. But I will never be able to convince my colleagues to invest the energy learn Scala if it is not immediatly seen to be markedly better than Java. When one of my colleagues saw my Scala book the other day and asked about it, he rolled his eyes when I excitedly told him how much better and cleaner Java bytecode can be written in Scala versus Java and said, "Groovy, Clojure...this Scala... They're all the next magical language, right?"
If Scala has any change to become more than an academic or hobbyist language (Twitter notwithstanding) it needs to be supported by an IDE that proves to existing Java developers that they can easily migrate to it without more than a minor short term loss in productivity. Otherwise they'll say, "I can already write and real Java code just fine. You're saying I should learn another language that compiles to the same darn bytecode as the language I'm already familiar with AND I won't get the same refactoring support either? Thanks, but I'll keep my SUV, you can have your Segway."
So, I think IDE support (or lack of it) is a fine criterion for choosing a language (once other more substantive criteria are evaluated). But, for choosing Scala over Java? IDE support is key. The sad reality of commercial software development is that it's extremely difficult to get developers to move from their primary language. Adding barriers like stripped-down IDE support is a showstopper.
2. IDEA's Scala support is more than adequate to facilitate day-to-day programming
I guess we'll have to agree to disagree on this one. I desperately want the IntelliJ Scala plugin to be sufficient, but I repeatedly run up against issues that annoy me on even small projects. (Here's an issue I recently raised.) There is no way I would trust it with a refactoring that would touch many files. And, for me, just that lack of trust - and thus the need to verify it did the right thing - is a time sink (and morale sink) that puts the bloom off the Scala rose for me.
I will be first in line to stand on that soap box in my office and shout, "Scala really is the next magical language!" once I feel comfortable with the quality of the tools that exist to facilitate its development of production-caliber code. But, for me, that time has not yet come.
Well, off to write another for-comprehension ... darn it, I mean for-loop...
I completely agree with Sean. IDE support (aka refactoring) is the key
feature, because we are accustomed now to IDEA's Java support. I always feel
moved back into stone-age if I have to write C code which lacks refactoring
Sean Crotty wrote on 31.8.2009 11:05:
There is no way I would trust it with a refactoring that would touch
That's what automated tests are for. Especially when using TDD, you
automatically end up with a comprehensive regression test suite, so you
will notice in a few seconds (how long it takes to run all the tests)
whether a change broke something.
For me, IDEA's Scala plugin would still need to support the Extract
Method and Inline Method refactorings. After renaming, those two are the
refactorings that I use the most.
But even more important than any refactorings, is the speed to the IDE.
Right now typing Scala code in IDEA is annoyingly slow.
I've also sometimes noticed that IDEA needs to be restarted or the whole
project recompiled, because of weird compiler errors. So
stability/reliability would need to be improved some.
Because of the above issues, I don't yet consider the Scala plugin to be
ready for production use. But it's still better than any other Scala
IDE, so I use it at least in my hobby projects.
Sean Crotty wrote on 31.8.2009 11:05:
There is no way I would trust it with a refactoring that would touch many files.
That's what automated tests are for.
Well, really, a bad refactoring will mostly be caught by the compiler except for configuration and properties file impact. But, regardless, I have two thoughts about your statement. First, As much as I strive to create a comprehensive test suite, I'm kidding myself if I think it's really complete - things will fall through the cracks. Second, even if the compiler or a test does catch the problem, you still have to manually fix the problem. Thus the time and emotional burden remains when developing with a sub-par IDE.
I agree with you on the slowness. I really, really want a good Scala IDE and I will adopt whichever platform (IntelliJ, Eclipse, Netbeans) implements it first (but would likely move back to IntelliJ if its Scala plugin eventually matured apar with the other). Unfortunately, none of them is ready for prime time.
I'm happy to notify you, that I'm still alive but in the last couple of months I was kind of a little bit busy with my current PhD work. Usually I forget to track forums (by some reasons automatic notifications don't work correctly for me), but as you may see by revisions to Scala plugin repository I continue working on Scala type system support in the plugin.