My experiment with Scala is not working out. It’s just not ready for prime time, and is overkill for my needs. Reluctantly, I am falling back to Java.
Scala is a tour de force of language design. In my mind, it is two languages in one. First, it is a clever fusion of OO and strict functional programming (ala ML). For those coming from OO, I think it is a more natural fusion than that of OCaml & F#. Secondly, it is the ultimate language to date for writing libraries and embedded DSL’s with static types. Many things that are specialized syntax in other languages are just library code in Scala. You can warp the syntax to many uses, all within a static type system. Libraries can be modularly extended and composed without modifying their sources. These abilities go way beyond any prior statically typed language.
The problem is that these abilities come at a high cost in complexity. The syntax has so many ways of doing things that it can be bewildering. As with Macro-based languages, you are always a little uncertain about what your code is really doing underneath. The type system is just too complicated for me. The docs include “use cases” that approximate the real types to make them simpler and more understandable. That pretty much says it all.
If you need to build big complex libraries for a large group of application programmers, this might be a good tradeoff. But I don’t need to do that. All I really want is the nice simple part of the language that cleans up Java and gives me first class functions and algebraic data types and pattern matching. For me, that part of the language is 80% of the benefits and 20% of the complexity. I predict someone will do a “ScalaScript” that hits that sweet spot, but which compiles to JavaScript instead of Java.
I mostly wanted functional programming because it is a powerful way to do parsing and compiling. But I have decided to try Stratego/XT for my parsing and compiling instead.
Actually I could live with all of the above problems. The killer problem with Scala is that the tools are just not ready for prime time. The Eclipse plugin is a total fiasco. They have been working on it for years, with not much progress to show for it. They are screwed because Eclipse won’t add hooks into the JDT for them. IntelliJ is way ahead, but still has a long way to go to be production quality. The scala compiler is agonizingly slow. They have a “fast” compiler that runs preloaded in a daemon, but it mysteriously dies every 30 minutes or so. I hit my final breaking point when I wanted to debug one of my unit tests. Intellij doesn’t let you set breakpoints in tests. So I arrange to catch the assertion exception and I am warped into a bizarro world where everything has been mangled and boxed and thunked and I can’t find any of my variables.
I wish Scala the best of luck, but I have work to do.
Could you perhaps add a little more detail about the statement that “As with Macro-based languages, you are always a little uncertain about what your code is really doing underneath?” This isn’t something that I’ve encountered with Scala; usually the type signatures tell you all you need to know.
Also, I’d recommend NetBeans with the Scala plugin over both Eclipse and IDEA. In my experience it’s both faster and less buggy that either of the others.
Kris – I don’t want to start an argument about personal preferences. I just find Scala too clever by half with its implicit conversions and implicit parameters. If your goal is to create embedded DSL’s this is great. Thanks for the tip on Netbeans. If Stratego/XT fails me I may be back.
I have a hard time believing Stratego/XT will fail you, since it has already been used for two Web DSLs – WebDSL (which I believe Eelco pronounced “Web Diesel”) and Mobl (which I believe Eelco pronounced “Mobe-L”).
What Eelco told me is that the big mistake he made with WebDSL was designing the whole system in pieces and then trying to integrate everything afterward (WebDSL is actually a collection of DSLs or “Models” that handle various parts of web programming for the user), because the integration pains simply became too hard to manage and the user experience suffered. He is hoping for a different outcome with Mobl.
Did you see the recent comments on LtU where Martin Odersky publicly promised me a better Eclipse IDE plug-in sooner rather than later? I suggested to him, in response, that he should write a paper on lessons learned developing an IDE plug-in for a sophisticated language with a deep compiler pipeline like Scala.
My problem with that is finding the time to write papers, when there are so many pressing things to do 🙁
If you think that a ScalaScript -> JavaScript would be an appealing alternative, and since you’re already about to change horses … have you considered the compile-to-JavaScript route yourself? You cite first-class functions and flexible data types. Since the central use case of your language is web applications, perhaps a better question is: Why not target JavaScript?
Jeremy, I do want to target JavaScript. Right now I am building a compiler into a kernel language and interpreting that. I plan to put the interpreter into a Java applet and do the UI in JavaScript. An all-Javascript implementation would be ideal, but I just don’t think the language/tools/libraries are ready. Java may be the past, but it is a stable and richly supported platform. I am hoping to use Harmony or CoffeeScript in the future, once they are solid and tooled up. So keep up the good work!
If you want to target JS for the UI, and the core of what your are building is Java, you may want to consider GWT. If you can stand writing all your code in Java, it cross-compiles the front-end to JavaScript for you. There are a lot of benefits to that — static type checking from top to bottom, and the ability to unit test everything with simple JUnit and EasyMock, and staying in one language means easy re-use in both domains…less code to write, etc.
I’ve found exactly the same thing. For me the breaking point was the implicits. I changed a class that was basically a partial function so that it mixed in the PartialFunction trait, so that I could inherit methods for lifting to function-to-option, function composition, and so on. With that one change, the behaviour of my system completely changed. Luckily I had written extensive automated tests that caught the regression, because the type system did not detect a problem. The powerful, convenient type checking is made redundant by the powerful, convenient implicits.
Sounds like you would’ve enjoyed Scala’s predecessor “Pizza”:
http://pizzacompiler.sourceforge.net/
Yeah, that’s what I’m talkin about.
I agree with every point you made in this article:
Scala is an impressive piece of language design.
Scala fuses OO and functional programming better than F# and Ocaml
Scala has a high complexity cost — might be worth it on a big team, probably not for a single developer.
Tools are awful, even though years have been spent developing them.
Well written, thoughtful post. Thanks!
I’ve been using Clojure to bring a little functional sanity into my Java life. The tools aren’t wonderful there either, but I find them more stable than Scala’s, especially if you’re willing to use Emacs. However, I’m not sure if Clojure’s dynamic typing would be a good fit for your particular use case.
This is Martin, the language designer. I am sorry that your tool experience was so frustrating.
I just wanted to say that my company Scala Solutions has taken the over development of the Eclipse IDE for Scala. We should have a first beta out together with the release of Scala 2.9, in a couple of weeks. I have personally spent quite a lot of time improving the interface with the compiler. I have now switched for all of my development work to our as yet unreleased version of the Scala plugin for Eclipse. That’s after 20 years of emacs. And I am not looking back.
The new Eclipse IDE is not yet as feature complete as Java’s, but we have made great progress in terms of stability and responsiveness in large projects.
Regarding fsc, failing after 30 minutes looks very mysterious to me — I ever have seen that one reported by anyone else. A firewall problem, maybe?
If Jonathan is referring to the option in the Scala plugin for IntelliJ then I suspect this is the plugin and not fsc itself. I *have* encountered this but I haven’t tried it now for a long time.
Is Scala Solutions going to open source the code to the Eclipse IDE, or will it remain proprietary?
I don’t see much benefit to your company to keeping it closed source, since the amount of people who can wrap their minds around such a huge environment is vanishingly small (in my experience); opening it would make it easier for you to find employees for Scala Solutions.
The code will remain open source, as it always was.
Good to hear that you will be keeping up with the Scala plugin for Eclipse. Will it be a complete rewrite, or will you be basing it on the existing version that uses AspectJ?
Hi Andrew,
Since this work is all publicly done in the Scala SVN trunk and the Git repository for the Scala plugin (in the wip_experiment branch), I can tell you as an observer that it’s not a complete rewrite at that level. It still uses AspectJ.
A lot of work is happening at the presentation compiler level, dependency manager and others to fix various reliability and latency issues as I understand.
Best,
Ismael
Martin, that is very good news. I will certainly check out the next release. Scala is an impressive accomplishment. Beyond its specific advances, it may also set a new precedent for carefully designing and refining a language before releasing it on the world.
Since you were gracious enough to reply to me, let me be bold enough to offer a suggestion. The impression that Scala is too complicated for average programmers may be a big obstacle. As you said in a recent post, Scala can be subsetted for different levels of sophistication. A frequent complaint about C++ was that while everyone agreed on the need to subset the language, no one agreed on what that subset should be. Perhaps you should define an official language subset for application programming, and enforce it on a package basis.
Thanks for taking the time to reply, and best of luck with your new venture.
.NET already does that (subsetting). It is called the Common Language Specification. There is no need for Martin to re-invent the wheel. The system has worked really well in .NET land so far.
Jonathan, I agree with your suggestion for defining subsets that correspond to different levels of sophistication. We have taken a first stab at this. See:
http://www.scala-lang.org/node/8610
We are thinking of having tool support for enforcing some of this, but have not yet started working on it in earnest.
How difficult would it be to have the compiler enforce the different levels according to a compiler option?
I’m the author of a Sip Server written in Scala, and so far I haven’t even ventured into “L2” or “L3”.
I’d sleep easier at night knowing that my build scripts could enforce that no one checks in a module with some unnecessary complexity best reserved for core library designers or seriously complex java interop.
Despite the tools being a little green (I switched to Vim from Eclipse recently), I’m loving Scala and see it as the future of programming languages!
Thanks so much for this Martin. As a newer (~6 mo) Scala programmer, this helps establish some comfort zones for me. I’m probably around your “A2” level but have been spending some much unnecessary time on L[x] topics that I didn’t have any business with yet.
FSC exits after 30 minutes of idle time. This is hardcoded in the compiler:
http://stackoverflow.com/questions/4426465/how-do-i-turn-off-the-scala-compilation-servers-timeout/4429883#4429883
Thanks Ittay. I was puzzled that I couldn’t google the answer to this problem, but I see that post doesn’t actually mention “FSC” in it.
I haven’t managed to document it yet, but sometime in the last few weeks I made that timeout configurable. Don’t expect this to be the final name, but it’s let’s see here system property scala.config.fsc.idle-minutes.
Thanks Paul
fsc have timeout of 30 minutes of inactivity. That’s very irritating:
http://stackoverflow.com/questions/4426465/how-do-i-turn-off-the-scala-compilation-servers-timeout/4429883#4429883
Scala is definitely a language that can be both easy and complicated depending on how you use it. I think I was lucky enough to spend a lot of time on the easy stuff before I encountered anything too mind boggling. Martin Odersky quite helpfully talks about this here: http://www.scala-lang.org/node/8610 . For me Scala *really is* Java without the pain, over the last two years I have gradually adopted more of the language features and each one seems to bring some exciting new freedom. But from time to time I delve into someone else’s terse and undocumented code and feel lost.
My preferred tools to date are IntelliJ with the latest Scala plugin here: http://confluence.jetbrains.net/display/SCA/Scala+Plugin+Nightly+Builds+for+IDEA+X . But doing continuous compilation with sbt (http://code.google.com/p/simple-build-tool/) *not* IntelliJ which I completely agree is very slow and a bit flaky. This combination seems to fairly popular right now. Unfortunately I can’t say much about debugging, by luck or intent I’ve always managed to avoid debugging tools and make heavy use of logging instead.
IBM has put JDT into maintenance mode and they are focusing newer efforts on collaboration with X10, as well as meta-environment researchers like Eelco Visser. As always, follow the money trail to researchers and you can figure out politically where things stand. IBM does not want to make major changes to the JDT API, since it is more or less stable and has a happy customer base, and anybody who wants a better IDE can pay for IntelliJ instead. Go read the Eclipse IMP proposal on the Eclipse website to see where things are headed. See how X10 is using the IMP. From the proposal: “Our ultimate goal is to assist language implementers in creating IDEs with a richness and usability on par with the Eclipse Java Development Toolkit (JDT).”
It is not about luck, but you are right that you have to make progress.
The perspective shouldn’t be about luck. It should be about excitement. This is the first time in about 15-35 years that IDE developers have been challenged by a mainstream programming language to provide a good user experience. Borland developer Barry Kelly told me once on LtU all the tricks IDE developers use with traditional ALGOL-like languages to provide good interactive performance, but with Scala that stuff has not worked. I find the brickwall Scala presents to be sort of exciting. For the first time since Tom Reps thesis, we have a language that has changed some of the major assumptions about how IDEs perform effectively.
There is a JDT incubator project on e4 (http://eclipse.org/e4), but there has been no work done on it yet. This project is meant to explore ways that JDT can be opened up for other languages. It is a project that is open for contributions, but no one has stepped up to it yet (and I am part guilty for that since I am ostensibly a committer on this project).
That being said, we have had good success in opening up the JDT for both AspectJ and for Groovy. The downside is that we have essentially had to fork JDT in order to get there.
I am not sure why Scala poses a fundamentally different problem than these two. In some ways, it must be easier. Scala is statically types (and so no type inferencing must be done by the editor (it should all be done by the compiler)), and there are no intertype declarations like AspectJ (and so external types are not affected by crosscutting). What makes Scala challenging to work with?
The problems relate mostly to ambition: Scala is a great replacement for Java, and one would like all the things that work for the JDT to work for Scala also. Compared to Scala, AspectJ is an auxiliary language while Groovy is Java + dynamic typing, a very different beast. Additionally, decisions were made not to hack the JDT directly, rather to trick Eclipse into thinking that Scala was Java. This works well in simple cases, but falls down very quickly. I think after I left the project efforts were made to hack the JDT at runtime via AspectJ, but this seems fragile, it could have fall down also.
Scala is statically typed, there is a lot more for the IDE to do to surface those types in the editor. Not only that, but you need to find a fast/robust way of computing those types during editing. Not easy.
“This is the first time in about 15-35 years that IDE developers have been challenged by a mainstream programming language to provide a good user experience”
I think this is backwards. For the last 15 years have seen a complete change in the way programmers actually go about the activity of programming. IDEs have changed from being glorified text editors with a button to run the compiler to be language-aware editors with continuous compilation, analysis and testing running in the background. The user can perform huge program transformations as fast as they can think. Extensive indexing lets them navigate through the program by following links through the conceptual model of the language.
Has language design kept up? I don’t think so.
For over a decade, the cutting edge of programming (as an activity) has not been about text editing. But, with a few exceptions*, all new languages are first presented in terms of text editing and batch compiling, with tool support thought about long afterwards.
The user experience should come *first*, and the language features to support that user experience should follow.
* Factor for example.
I completely agree with you Nat. The programming experience should come first. I am bootstrapping with a textual syntax out of necessity. It is the easiest way to get started, and I have learned the hard way that people just can’t understand a language unless you show them syntax. But I plan to discard the syntax once I have bootstrapped enough libraries to self-host a meta-model IDE.
Perhaps it’s just its Smalltalk roots, but Newspeak was also developed in conjunction with a development environment.
The whole Smalltalk family tree has emphasized the importance of good IDEs, yet none of those languages have achieved broad popularity. Perhaps the problem is not lazy/foolish language designers, but (as Jonathan discovered), the expectations of early adopters.
I don’t think language designers are lazy or foolish. I think Scala is a towering intellectual achievement. Rather, I think the academic language design community operates in a bubble, isolated from changes to programming practice.
Martin’s comment that he has only just switched to Eclipse after programming in Emacs for 20 years is telling. In that time, the cutting edge of Java programming practice has changed from being performed by editing text and compiling at the command-line to become mostly done by program transformation in powerful language-aware editors such as IntelliJ or Eclipse JDT that have battled each other for feature supremacy over the best part of a decade.
The language design decisions you’ll make if you think of programming as text editing plus batch compiling are going to be very different from those you make if you think of programming as program transformation with continual, rapid feedback.
I wholeheartedly agree with this statement. However I also happily use Scala from IDEA’s (free) community edition. I feel a lot more productive than I was in Java.
Hopefully Martin’s efforts to boost the Eclipse plugin will spark a new feature-war with IDEA
Since there’s been a significant aspect of this thread on the difficulties of implementing IDEs, and since the X10DT and IMP were mentioned, I thought a couple of comments might be warranted…
[Disclaimer: I’m the project lead for the IMP project at eclipse.org, and for the X10DT project at IBM Research, so my perspective is almost certainly at least a bit biased. 😉 ]
Having spent a few years working on language-independent IDE support for Eclipse, and having worked on some specific IDEs, I can completely empathize with the pain of anyone who’s attempted to build an Eclipse-based IDE. It’s hard work, no question about it. [And I don’t think this problem is really unique to Eclipse; other frameworks I’ve seen in the past didn’t seem to provide much better language-independent building blocks.]
I also agree whole-heartedly with Martin when he says that an IDE developer needs to understand the compiler front-end intimately. Part of the reason that my current team (working on the X10DT) has had any success in the endeavor is that some of our team members have spent considerable time working on the front-end. Also, we work fairly closely with the compiler team to make sure we have API and behavior of the right shape. And the compiler team is actually responsive to our needs! (Not all that common, I’m afraid…) Without this, we’d be in a much more difficult position. There are just so many ways in which a compiler can be structured sensibly for a non-interactive context that simply don’t work in an interactive context. Likewise, it’s quite easy for the IDE to place unreasonable burdens on the compiler, in terms of CPU or memory performance. Some of these issues are fairly simple to address, but others are deeper and require real work to fix.
I don’t know that having a compiler that’s the “wrong shape” is entirely avoidable, at least until the lessons learned get folded into your average “Compilers 101” course. Maybe that will start to happen, now that IDEs are more of a requirement for language adoption than when I took my first compiler course.
Yes, the X10DT is built on IMP, and although we’ve spent time improving and fixing IMP in the process, IMO (remember the disclaimer above?), the basic structure we started with was essentially sound, still makes sense, and has helped us quite a bit. The short version: the IMP IDE framework takes care of most of the UI aspects and the “orchestration” of services, and the language-specific code worries mostly about the compiler and the “model” (i.e., the ASTs, the type objects, and semantic analyses). That said, we still have a ways to go before anyone would say the X10DT is truly on a par with the JDT’s level of functionality. But we’ve definitely made solid headway, and the IMP language-independent framework has definitely helped us make that happen.
It’s been a while since I looked at Scala anything more than passingly, so I honestly can’t comment as to whether IMP would offer any concrete help in dealing with the unique(?) problems Scala presents to an IDE implementer. That said, staging of scanning/parsing/analyses, indexing, dependency management, and “consumability” of analysis results are all certainly big parts of what can go right or horribly wrong in the IDE context. We do have techniques for dealing with these aspects, and they’ve worked out pretty well for us so far.
Oh, and FWIW, in case the above makes it sound as though I’m drawing conclusions from a single IDE’s experience, there are IDEs out there built on IMP for a nontrivial variety of languages, including Eelco Visser’s aforementioned Spoofax IDE (and I believe his WebDSL IDE as well).
So: Is IMP “where things are headed”? I have no idea. I’d like to think so, but there’s still a lot of engineering left to do to get “there”, wherever “there” is, and we’re not the only ones forging a path…
Robert – thanks for the thoughtful comments. I am glad that IBM seems to be taking X10 seriously, and wish you and it the best of luck.
I agree that the advent of IDE’s requires us to rethink what a compiler is, and that we are just at the beginning stages of that process. I see it as trying to find the correct intermediate representation between the IDE and the compiler. The problem is that this intermediate language is currently a stew of AST’s and ad hoc semantic information. My approach is to define the language not as a BNF grammar, but as a meta-model similar to that presented by language reflection facilities.
In any case, this problem won’t be solved until language designers also become experienced IDE implementors. Unfortunately this is not generally the case now, and the separation is being enforced by the structure of academic computer science, where PL’s and IDE’s are done in different fields.
Regards,
Jonathan
I loved Scala when I was using it (and working on it). Then Scala became more complicated, I could barely understand it or keep up, the user base came increasingly from the FP crowd (e.g., Haskell refuges) rather than my OO crowd, which influenced the style of the language greatly. Still a great language, but not for everyone.
As for the IDE, it requires more resources than building the compiler. IBM has a staff of what…4 people working on the JDT compiler and 20+ people working on the JDT-everything else. It is just unrealistic to think Scala could get away with anything less than that, while hacking the JDT hasn’t proven feasible so far. The other IDEs are less ambitious in their feature sets (probably a good thing) and are better bets, but I don’t think you’ll find anything very satisfying.
Today…if you design a language, you have to think about tooling from day one. Don’t just think about what IDE you want to integrate with, design the IDE used for your language and implement that around your compiler (reuse Eclipse components if need be, don’t integrate into Eclipse). This whole interop crap is pragmatic but hopelessly out of reach for a small team.
Good points Sean. I would go even further. Design the IDE first, then build a language that does what it needs. That is what I have been doing for the last 5 years.
Sean, I think your perception of Scala’s change might be more a community phenomenon than grounded in the language. The language itself has been pretty stable over the last years. Some libraries were changed, with the aim of removing a lot of accidental complexity. It’s true that functional programming folks are increasingly picking it up. This is a good thing, IMO, because it pushes the envelope of what you can do with the language. At the same time, we have to make sure that traditional OO programmers also feel at home.
Regarding IDEs, there’s more than one way to do a good integration. Designing IDE and language together makes things more complicated. I prefer a separation of concerns here. But what’s absolutely necessary is that the people who work on the IDE have an intimate knowledge of the compiler internals. JDT and Java IntelliJ both have their own presentation compiler. Scala uses the standard scalac compiler, and it’s a major engineering effort to make that work well.
Martin,
I agree with you and I’m very happy that a lot of effort is being put into making Eclipse work reliably and with a good response time as it’s one of the major pain points I hear about. Of course, the work on the presentation compiler will benefit many tools (including Netbeans and Emacs via Ensime).
Best,
Ismael
Community is very important in a PL: PL design is some theory, some hacking, and a whole bunch of user understanding. I got a lot of flack for being OO, especially towards the end where my deep layering of mixins was seen as horrible even though it was completely inline with what Scala was good at doing (as the best mixin language ever). I went in one direction while the community was going in another; we were pushing different envelopes, the standard style for Scala was increasingly unrecognizable while the library was evolving according to that style.
The JDT has one core compiler and a bunch of heuristic compilers for the sake of response time and error robustness. Heuristic compilers would not work well for Scala, and of course the alternative is to turn the core compiler into a strong presentation compiler. Great, it requires some tricks and a lot of engineering effort, but its doable and definitely within your means. What bothers me more are the factors you can’t control: I was very hopeful about eventually taming Scalac, but I had lost all hope of ever taming Eclipse or the JDT.
Once you separate your concerns, you always need duct tape to glue them together. If you design your IDE and language concurrently, you can think of them as one complete user experience. Features of the IDE can enhance the language, they lead to a broader area for making tradeoffs; e.g., good support for autocomplete allows for denser/flatter namespaces.
Language design should be very close to interaction design, consider the whole path that the user takes in making a program and provide an experience that is as integrated as possible. That includes the user interface (syntax, semantics, environment) and social factors (e.g., intended audience, collaboration). One could go even further, tightly integrating all of this, sounds like a good research topic.
Its a shame you wish to make a decision like that, please turn back! Scala is complex if you wish to look at all of its features. C++ is also complex if you look at all of its features, virtual destructor, operator overloading, etc.
As a long time and up to senior level C++ programmer I used to keep myself programming within the simple sub-set of C++ rather than using operator overloading or any complex features for the specific reason of making the code maintainable. Of course I could write my code as complex as I liked, but I wanted to keep it simple and “dumb” for that reason. The same can be done with Scala.
Scala has a large community around it, it has great libraries around it, its not simple to understand it totally but its not difficult to understand the basics. Its also very powerful. I use IntelliJ which is very good for myself.
Scala somehow reminds me of the problems C++ had. It wanted to be the successor of C. C was small and nice. C++ tried to include every language feature which was en vogue then.
Nowadays everybody who uses C++ seems to be just using a subset of the language. But everybody uses a different subset which makes it difficult to understand others code.
C++ lost mind share more due to timing and a lack of standard libraries than having too many language features. My memory of switching to it from C circa 1995-6 was not having a standard string library. You had to either make your own, which became a thin wrapper around C functions and typedef’ing char * within a class definition, or use the proprietary library from the compiler vendor. At the time, we wrote application servers – commercial and open source ones were not on the horizon – and worked with TCP sockets. Again, to do it in C++, you had to write your own class encapsulating the C structs and API calls because C++ didn’t have its own. By the time Java started catching on (1997?), we were very ready to have standard libraries that we didn’t have to support for things like strings and sockets.
Scala has many libraries by virtue of its compatibility with Java. It does not share the same problems C++ had during its adoption.
By the way, my memory of using C is not as romantic as other people’s. You could easily learn to code non-idiomatic C with little time: there are no deeper mathematical groundings for it. However, it also forced you into too much debugging of one-off errors, memory leaks, and dangling pointers. Those issues really took the fun out of developing.
Hi Jonathan,
your first sentence (“Scala is not ready for prime time”) actually is very funny, as we just finished a time tracking tool in Scala that’s called PrimeTime.
Nice post! I wish Java would be valid Scala, so you can just add Scala as a spice, reducing the complexity.
Thomas.
Also I use SBT, Simple Build Tool to build my Scala code.
I use it within IntelliJ. It is quick, also – if you type ~compile in SBT, whenever I save the file it re-compiles immediately.
An example of SBT is here – http://www.getslimstack.net which I also created – but this is just an example of SBT working. It can be set up within IntelliJ easily, so that whenever you save a Scala file it re-compiles immediately.
SBT is similar to Maven but faster and more concise.
Don’t use Maven, its too slow – SBT is concise and fast, but not so well documented. A easy way to get started is to follow the instructions for a new Liftweb project as it uses SBT by default. I have some OLD instructions here which are not really valid now, but may be worth reading http://www.philipandrew.com/?p=1, but its misleading now, don’t follow my instructions there.
Follow the instructions for Liftweb here – http://liftweb.net/download then you should be able to open an IntelliJ project in the directory.
About SBT and IntelliJ, the easiest way to get started is to get the IntelliJ Community Edition, download the SBT plugin. Go to plugins in the settings of IntelliJ and download it there and install it there, and restart IntelliJ.
IntelliJ does some understanding of the code, some syntax and auto-complete while SBT compiles and shows errors, so SBT picks up more errors than IntelliJ. SBT shows the errors in the SBT console window which is a window at the bottom of the screen. When you double click on the error you can jump to the line which has the error.
If you start the SBT console and type ~test-compile it will automatically run compile and the unit tests whenever you save a file. This process takes about two seconds on my machine after I save a file. I can wait 2 seconds.
If you use JRebel as well, you can save a file and see the changes immediately in your running program just like a PHP program.
About Mac vs PC, the usual argument, I have a PC as its cheaper and faster but it doesn’t look as good as the Mac and not as fun. I have a Mac but its PowerPC and too old for writing code and I don’t need to spend the money to buy a wonderful Mac just to write Java code (but would like to).
Can’t figure out if you’re having problems with the language or the tools or both. I agree the tools more or less suck, though you can have a workable solution using Eclipse plugin and Maven plugin..
If the language is a problem, I suggest you buy (yes, buy) Oderskis book, and take some serious time (yes, not skimming) to really learn..you can’t just look example code and understand it, like it was Groovy or something.
Remember when you first learned C++ (or Java) ? You would have to make a similar effort to learn Scala. This is something that isn’t just handed to you just because you already have 10 years of experience in some other language.
So roll up your sleeves and goto work, and stop complaining !
Mike, you are implying that I am stupid or lazy. Further impolite and unconstructive comments will be deleted.
Also Scala allows you to make your own languages, ie – http://www.philipandrew.com/?p=72
Perhaps give Fantom a look? http://fantom.org/
Looks nice for cross-platform app development. But JVM and .NET are already becoming legacy. Now it is all about JavaScript, Android, and iOS.
I agree 100%. Although here is where I think Fantom stands out: the designers’ original vision was to have not only a portable language across VM’s, but a portable, well-designed standard library. They have their own IL bytecode, and they have refocused their initial work on cross-compiling to the .NET CLR, to cross-compiling to the Javascript platform. Which means it’s possible to code with the same language against the same API for both client-side and server-side. I’m not sure what other solutions are attacking the web client/server bifurcation problem, but Fantom looks to me a promising contender.
Actually Fantom already compiles to JavaScript – you can write an entire GUI in straight Fantom and have the compiler output JavaScript, HTML, and CSS files. The guys who wrote the language are already using this in a production app for their clients.
It’s also a very well-designed language and is a blast to use. Personally I think Fantom is the future of OO languages, which is not something I’ve ever said about any other language.
This may be close to what you are looking for:
xbase-new-programming-language
It’s not 100% ready for prime time, but many of the issues you’ve mentioned are things we’ve tried to address in the Gosu language (http://gosu-lang.org). The language core itself is usable, though startup is too slow, and unfortunately we have a ways to go on the Eclipse plugin, though we’re actively working on it. Basically, the language is similar enough to Java that the tools can actually work properly, and if you drop into a Java debugger or profiler, the bytecode we generate for the classes is pretty sane. It has local type inference, first-class properties, closures, and the ability to enhance existing types and classes, though no pattern-matching. Toolability, and compatibility with Java tools, is primary design point for the language.
Looks nice Alan. But please think about targeting JavaScript instead of the JVM. That is where the money is going now, and everything follows the money.
I’m not convinced that JavaScript is really where the money is going; even web-apps that use JS on the front-end tend to use something different for the back-end logic, and while there have been plenty of attempts to bridge that gap from both directions (i.e. GWT to compile Java to Javascript, or Node.js to run javascript server-side), I remain unconvinced that it’s really the way forward. At the end of the day, even if you have some other language compile down to javascript, your client-side code is still going to consist of the standard mix of HTML, CSS, and JS, and you’re going to have to debug and tweak it as such. Unless browsers change significantly, I just don’t see the tool-chain extending all the way there, and I think that significantly reduces the utility of compiling a non-JS language down to JS. I also don’t personally see any great reduction in the need for server-side code, so I think the JVM itself is going to be around for a long, long time. Enterprise shops like Guidewire (where I work) are going to be around for a while, selling big systems for large amounts of money, and most of those shops are going to be on Java (or C#) for the forseeable future. There’s plenty of interesting things happening in the mobile space, but for iOS devices you’re not allowed to use anything other than C/C++/Objective-C anyway, so there’s no chance to innovate there, and for Android/Dalvik compiling down to standard Java .class files is really the right thing to do if you want another language that runs natively there.
I agree with Alan, but wanted to add one additional point that devs often forget about: operational management and monitoring.
Having had some ops responsibilities (I’m what the kool kids might call “devops”) for most of the last decade, one compelling advantage of the JVM over any other runtime I’ve been forced to work with is how open it is to monitoring, triage etc. at runtime.
When wearing an ops hat, I don’t particularly care what the language on top is, provided I’m dealing with a JVM, since the JVM gives me so much to work with (unlike, say, node.js, to pick on an immature starlet of the moment).
Now I’m sure there are other runtimes out there that come close to being as operationally mature (.NET for example – I haven’t used the MS development technologies since ye olde ASP days and I’m sure it’s improved a lot since then), but I shudder when I hear about these new runtimes and how they’re throwing the operational baby out with the language bathwater.
Please check out Fantom :
http://www.fantom.org
It does compile to javascript by the way, as well as run on the JVM.
It will be much less painful than going back to Java, yet avoids a lot of the over-complexity of Scala.
I said it with tongue in cheek, sorry if it came out wrong. What I meant is, Scala takes much more to learn than most other “normal” programming languages, you have to change your way of thinking into a hybrid of FP and OO. This is what makes most people give up, they skin a few examples, don’t get, then give up.
I did that myself at first, until I realized, I can’t learn this just by glancing at examples here and there. So I took out about 2 month to really study and purchased Oderskis book (since it’s the only real good tutorial out there right now)
So don’t give up on it just yet, realize what it takes, then give it another go..and I promise that it will be ever rewarding.
Most language designers are well versed in both OO and FP, the fusion of the two isn’t our problem. No one is arguing that Scala isn’t a good language. Its a great OO language and a great FP language. Being a hybrid necessarily introduces complexity, Scala is the great successor to C++ with the addition of more safety, garbage collection, and a strong standard library. Definitely not for everyone, but appealing to many.
Couple this with immature tool support, people just expect good IDE support these days; you just can’t navigate vast standard libraries and components without good autocomplete/Intellisense support. Java may be less powerful, but it has good tool support and you can “see” the libraries you are using. I think Scala with a great IDE could take over the world. But without there are many reasons not to choose Scala and go with something more conventional like Java.
Hi Sean,
“Most language designers are well versed in both OO and FP, the fusion of the two isn’t our problem.”
Oh please, then tell me, why it such a PITA in almost every other language which claims it can do both? Look at C#, F# for examples on “fusion gone wrong”.
“Scala is the great successor to C++”
Nice insult, this is the way to be taken serious, Sean.
“I think Scala with a great IDE could take over the world.”
So what exactly is missing from IntelliJ’s plugin in your opinion?
What is missing from the Eclipse Plugin planned to be released together with 2.9?
Hi Steve,
C# does not try to unify FP and OO in any interesting way with the type system like Scala does. C# simply has FP via lambdas and LINQ, which is very useful and pragmatic. F# fuses OO programming in its own way, but the emphasis is on FP (more so than Scala) and performance.
As a serious hybrid power language, Scala is the successor to C++, which was the last serious hybrid power language (in different ways of course). The two languages share the emphasis of power and flexibility with paradigm in their design. I don’t see that as an insult, C++ has needed a successor for a longtime and Java didn’t really fill that void.
Tooling is still the main pain point for Scala users these days, I’m sure there isn’t much arguments about that. If this will be fixed in 2.9, great.
I totally agree. I came across scala in 2006. I was at first very excited, but then found out how complex it is and gave up. Last year a client wanted to switch to Scala (which I was against) and forced me to learn it. Now I’m a great fan of it.
I think the Scala site needs to contain a more gentle introduction track where the emphasis is on the productivity bits of Scala: inference, case classes, public var/val for accessor methods, maybe traits. It should show syntax and examples (and how to run them, e.g., in the REPL). In another track the concept of functions should be explained in more detail and only as a gateway to the collection library (meaning, not delving into function composition etc.)
Jonathan,
Did you know that Peter Fisk has reappeared? He’s doing smalltalk again but this time it is implemented in javascript plus ExtJS:
http://silversmalltalk.wordpress.com/
Peter (no relation)
Fun hobby. Wonder what it’s good for?
I had the same feeling about scala. And searched for a statistically typed functional language but which is much simpler than scala.
A year a go I found one it is Yeti http://linux.ee/~mzz/yeti/intro.html.
It has less features than scala but IMO does functional better, runs on the jvm and has an ML-style typesystem with typeinference.
(Unfortunately the toolsupport and community is still smale)
Sorry the link to the main-page to yeti is: http://mth.github.com/yeti/
If you need a language that has invariant generics, case class matching, first-class functions, etc and outputs to JavaScript, ActionScript/Flash, PHP, C++, and soon Java, then you could consider:
http://Haxe.org
I am not recommending it, just sharing the link.
What the world really need is just Java w/o the boilerplate.
I’m not saying that Scala won’t find its own place. But, let’s face it… it is not what the corporate market need.
They need a, just a little bit more expressive java.
They need Patterns implemented in the language definition itself. No more very similar code repeated over and over again. If Patterns are so good (and they really are) the language has to support it in a standard way.
They need to transform the most useful / successful annotation into language features. The reason its simple: annotation are basically run-time frills. We need the same features at design-time.
They need dynamic factory pattern that work at design-time.
I.E. dynamic dependency injection at language level and goodby Spring or Juice.
Last but not least they need ala delphi property support: definitely.
They need J2EE to think about deploying 24×7 web applications. They really need to be able to deploy pieces of application.
This is basically what corporate programming (the market of java) needs; they need to be more productive. All the other features are just make-the-developer happy dreams that can be just useful in other contexts but not in the mainstream.
Just my opinions.
Having repeatedly tried to integrate Scala into legacy Java-based enterprise projects, I have to agree. It was unusable in the Eclipse J2EE tool chain that our team required and had to be abandoned. The complexity of the language already makes it a hard sell in existing environments, but failure to integrate with tools already in heavy use forces it to be used for small one-off research projects. (this is a common theme with many other open-source projects, but more fatal when it’s a language IMO.) Debugging the languages implementation, rather than the program being written in the language, also creates too much work for the program developer. I have not written off the language yet, and I eagerly await Martin’s next iteration where he is forced to use Eclipse like the rest of us! (and I hope it works within the JEE configuration too!)
How was it not able to be integrated? I’m writing a Java SEAM framework app with some Scala code called from the Java code, it works fine for me.
I want to say that I’m very happy with Scala, I use SBT (Simple Build Tool) with IntelliJ on Windows with Consolas font for editing. I don’t have any complaints. I can program “Java” style in Scala or add Scala type functional code when I want…
I sort of know that if you are a 10+ year developer everything look simple, because you already have the right hooks into your brain to attach new concepts.
But give the same language to people fresh of school and look at the results.
It like if someone give you a pc and tell you: “Hey, you can use it as a calculator if you want!”. He was definitely right, also, he totally miss the point.
But, again, these are just my idea. 🙂
After 10 years, everything looks wrong, I mean, we are not God’s of the bit – we running a bureaucracy instead.
All good, but what does this say for the increasing number of people who are managing to use it successfully? Did we all just get lucky? A little perseverance goes a long way and you get the rewards in the long run…
Also, I find it hard to swallow completely, given that you can pretty much start to write basic Scala in a Java style, to get going. If you did nothing else in the short term, at least you’d then have the power that Java does not have right at your fingertips when you finally do come to understand it.
Anyway, I’ve been working with Scala for 1+ years on commercial & enterprise stuff, no going back to Java for me, I’d be kicking and screaming 😉
I can say I’ve seen it be a success, but of course you might need to learn a few new things along the way. I’ve rarely seen this be a bad thing, but I guess people may have different perspectives on this.
Louis
What about writing in IDST & OMETA? Sounds like it might be worth it.
If you’re fond of Stratego/XT and have any affinity for Scala, check out Tony Sloane’s Kiama.