Scala definitely needs more people like Bruce Eckel to start explaining it. I understood several concepts from this article that have eluded me so far because every other article I found descended in to abstract concepts of language or type theory without explaining what the practical uses of things were.
Unfortunately I think it may have missed it's peak opportunity to catch on because of this kind of problem - and a chronically buggy and unstable Eclipse plugin - but we'll see.
This post may garner some down-vote for being non-rigorous, but I will offer my opinion on Scala so far. I accept it's good points readily enough when they are presented in list form, but when I read the language and try to reason in it, I just don't like it.
Scala just doesn't feel like where I want to go. I do not want to embrace endless complexity in the form of hard-coded language features layered onto the language. XML literals instead of macros???? Please, I say. I have decided that Clojure will take the place in my dev life that Java and C# have occupied for the last 12 years.
I hope that is the right decision.
I'd encourage you to give some actual Scala coding a try. It can look dauntingly complex in short snippets and people often showoff complex stunts with the type system but once you actually start coding it makes a lot more sense.
You really can start by writing Java-in-Scala and then gradually making use of the more advanced features as you need them.
Clojure is great too, of course, but I think Scala is much more likely to gain a foothold in the programming mainstream.
I actually like that both Clojure and Scala have names that otherwise don't mean something else. This unambiguity means you can more easily search for related pages and get more meaningful data out of Google Trends. Java will bring up some coffee references and the island in Indonesia. Python is, well, obvious. Just as two examples.
I'd much rather everything not also be something else.
GIMP is actually appropriate because AFAIC the program is completely crippled.
Maybe I missed something, but there is nothing in there that gives me the feel of a dynamically typed language. What he describes feels more like Haskell than Python.
> "Dynamic" is technical jargon used by programmers, meaning "good". It derives from the Latin dyno mite, meaning "I am extremely pleased", and is first recorded in the historical work Bona Aetas of noted Roman sage and pundit J.J. Walker. Its meaning evolved in the 4th century after monks copying an obscure manuscript on programming linguistics in their ignorance tried to deduce its meaning from context. [...]
(the comment continues at the link; read the whole thing, it's pretty funny whether or not you agree with the sentiment)
The biggest thing that is still in the language that they should have removed early on is the native XML syntax support. If I were them I would take it out in 3.0 and break from that bad decision.
Summary: No. At the time that Scala was started, built-in support for XML showcased one area were object-oriented decomposition failed and functional programming proved quite useful. Today the benefits of FP are more well known, and it's generally agreed that if Scala were starting from scratch it would not include XML literals. However, given that XML literals are in the language already, that large code bases have come to rely on them, and that they generally don't get in the way if you don't use them, it's unlikely that they will be removed.
This is hard because Scala's XML support affects the parser. At the lexical level. Scala does have compiler plugins, but it doesn't have parser plugins.
To reiterate a point implied by other commenters: macro-expansion is a compile-time operation. If the language utilizes a typing system to help promote sound programming then the results of the expansion will be compiled in the context of type constraints - the expansion is either sound or unsound w.r.t. such constraints.
To some extent there is a continuing popular schism with the idea that "strongly typed" must be synonymous with the lack of "eval", which, at least in principle, cannot be true. In fact, StandardML does have the ability to extend the environment of a program at run-time (as well as Typed Racket). All the necessary typing and meta-data is retained at run-time so that newly evaluated code is checked for type-consistency just like when the "main code" was compiled. So, not only can one expand macros at compile time and verify that the expansions are sound, one can also do the same at run-time.
I used to agree, until I ran into a bunch of inline StringBuilder Java XML where no schema existed, and simply converting it to Scala at least ensured it was well-formed while we reverse-engineered a schema. I agree it's not something one should use much (well, maybe with Lift), but wow, is it ever useful when it's useful. I agree, doesn't hurt much; helps massively when you need it.
There are several decent Scala-esque alternatives to the built-in XML support (with has many things broken about it). For instance: Anti-XML http://anti-xml.org/ and Scala-Scales: http://code.google.com/p/scala-scales/ they can't replace the functionality of the built-in support (need to alter parser/compiler for that), but are considerably more sane than the default functionality in scala.xml
Putting XML literals in the language just feels wrong. On the other hand, they've turned out to be damn useful when you're writing the back end for a web application.
It was a mistake. A better effort would have been to implement a first-class Macro system a-la Lisp. You can see here that Nemerle supports macros and makes dealing with XML like relatively painless as if it were built in: http://nemerle.org/About/#ID0E6G
I'm curious how much you've actually used Haskell's templating system.
It is my understanding that a good macro system in a statically typed langauge is still an open research problem. I remember hearing that the Racket research group was still working on it for their typed Racket system, and that it was, at least as of a year ago, not possible to directly port macros from the standard language over to the typed language.
I also remember hearing that template Haskell is a relatively primitive macro system that very few Haskell developers currently actually use, but I'm not an expert in this area.
Scala is already cutting edge in a lot of ways. Expecting them to innovate in such a difficult and untrodden area on top of what they've already done is asking a little much, especially considering that it is meant to be a practical and not a research language.
Re: Template-Haskell - sadly not enough. I have used it to generate N-tuple-generalizations of functions in toys. I simply don't get enough time to hack around in Haskell. As far as being primitive, I guess you would have to compare that to the drudgery of emitting all the automatically generated code produced by macro expansions by hand. Yes, in Haskell TH is relatively infrequently used.
In no way am I trivializing the complexity of what would be involved in bringing a useful macro system to Scala, but compiler plugins for Scala are filling this role today, a good macro system could make meta programming more accessible. Already there are plugins for SBT to invoke FreeMarker on Scala-program templates to generate code, clearly a poor-man's solution, but it simply is more evidence that a macro-system would and would be put to good use were one available.
Taking Racket as an example, a good macro system would enable many kinds of experimentation in the Scala language without having to extend the core directly. In Typed Racket Hindley-Milner type-inference was added on-top of a dynamically typed-core, and Typed Racket targets Haskell-level (or better) typing infrastructure. All this enabled essentially due to support of Macros.
RE: Cutting edge - And Haskell isn't? While there are a number of language features where Scala may in fact outshine Haskell, I would hardly place Haskell in the old and well-trodden place on the programming language landscape. It is still evolving rapidly, and without the need to conform to any particular run-time-system (e.g. the JVM) the researchers working on Haskell are able to practically make the language warp space-time.
This comment on Typed Racket isn't correct. Lots of macros work just fine in Typed Racket, and XML literals would certainly be among them [1]. The macros that don't work yet are the most complex ones, like the one implementing an entire class system with Java and Beta style inheritance (both!).
[1] In Racket, we typically use s-expressions rather than XML literals.
Disagree. Scala's syntax is already complex enough and flexible enough to all but eliminate the need for macros. XML literals were a marketing gimmick. More conventional XML support in a library would have been adequate.
Interesting. This is a common perception but not an easily justified one. A macro-system a-la Lisp (or Nemerle) could easily replace compiler plugins, and there is an active compiler plugin community so extensions to the compiler are desirable. As someone who writes in Scala every day for a living and have used the built-in XML support here and there I do not consider Scala syntax to be complex, but the XML support is ~eh~.
Despite limitations and warts it's a pretty nice language to code in on a daily basis if you're going to code on the JVM. Macros would definitely enhance Scala's productivity. If you don't like them don't use them. Certainly doesn't mean that others could not put such a tool to good use.
That's the problem with macros. It's hard enough to read Scala code as it is if the author wants to be clever. Throw in macros and it's game over. In languages with relatively inflexible or primitive syntaxes macros are a blessing but I think they're unnecessary in Scala.
I believe JVM now supports some restricted form of class re-definition at run time in debug mode. But it is quite limited. This is probably old hat for JVM hackers, I do not keep myself updated on the Java/JVM side of things.
I came across Sun's (now Oracle's?) open-source(GPL) fork of the JVM that allows for changing class internals on the fly. The following analogy comes to mind DCE VM : JVM :: DLR : CLR
I quote:
The class data structures of the Java HotSpot virtual
machine are immutable during the execution of a program.
While new classes can be loaded, it is not possible to
change existing classes (e.g. add/remove methods or
fields). This projects tries to relax this condition to
allow arbitrary changes to existing Java classes
(including changes to the class hierarchy) while running
a Java program.
This looks interesting http://ssw.jku.at/dcevm/ and wonder if runtimes of dynamic languages could make use of this.
It is a library on top of the CLR, but it cannot function without CLR-specific capabilities.
For example DynamicMethod, which represents a method reference that can be created at runtime and garbage-collected when no longer in use; similar to the lightweight method handlers in JSR 292.
That said, modifying existing classes on top of the CLR is not possible, unless it inherits from something like ExpandoObject, but you can pull the same trick in Java (though not as easily until JSR 292 comes out).
one of the better written articles out there for some one new to the language. Also like the fact that some of the funamentals of functional programming are also briefly introduced in context.
> I find it one of the most promising things about Scala -- it is not determined to become an instant boat anchor by committing to early decisions that are later revealed to be suboptimal, or outright mistakes.
The fact that Scala uses the JVM, with a hacky workaround for type erasure, is suboptimal.
Depends on what is suboptimal to you. If "suboptimal" is "not optimal for the perfect programming language", then sure. If "suboptimal" is "not optimal for real world use", then no.
Scala's interop with Java libraries has been a huge, huge boon, and undoubtedly drove take-up where there otherwise would have been none. Scala has come this far in a decade. Python is 20 years old. Ruby is 16. Scala came a long way in a short time, and was probably resigned to the dustbin of "that would have been cool" languages without that interop.
Unless they get significant outside help I'm very skeptical that we'll see a usable Scala on LLVM or .NET any time soon. The core Scala team is very talented but they seem to have their hands full with the JVM version.
Last time I looked (early 2009), Scala compilation to the CLR was a bit of a joke. It targeted version 1.1 of the CLR, which had been superseded nearly 4 years earlier. I think the problem was with the predefined libraries. Supposedly you could get it to work with v2 but I never did.
They also did themselves no favours by having the Scala compiler dump out MSIL assembler code rather than a .NET assembly. You had to separately run the ilasm tool to get an executable. Obviously for a production environment you'd package this up in a build file, but for experimenting with the language it was a bit of a speed bump.
This is without even looking at the language features and libraries that were supported on the JVM but not on the CLR (e.g. structural types, parser combinators).
My experience may be out of date here, but the scala-lang page on .NET support is still datestamped July 2008, so I'm not too optimistic. A great pity, as Scala always seemed a great fit for the CLR and would provide some nice competition to C# and F#.
Gosu has the same dynamic feel in a statically typed JVM language, with much less complexity. (I should mention Fantom too, although I'm much less familiar with it.)
Artima appears to have gone all-scala-all-the-time at some point in 2010. Weird.
Scala looks complex on paper, but my experience has been that in practice it's not that bad. If you're designing a library you need to think hard about types but you can put together an app very quickly in Scala and with a lot fewer initial bugs than in a dynamically typed language.
I wonder if there is value in making it easy to make library? I feel like the ruby eco system gains a lot for the rate at which people can try out ideas for libraries.
Scala forces you to consider your library interface more carefully. This makes it more work to build a library but I think it pays off in a cleaner, more consistent and self-documenting library. Scala makes you think a little harder in general but, in my experience, you also write better code.
All that painful refactoring and modularization that went into Rails 3 would have been a lot easier and, I suspect, less necessary if Rails had been written in Scala.
I think of it more in terms of natural selection. If, and this is a big if, diversity is greater in language x than in language y due to ease of trying ideas, then there is more opportunity to hit on good ideas.
The barrier to entry in Scala is definitely higher, and I do think this has limited its growth. To be honest, I don't think Scala is going to be the FP lang that really goes big, although I wish it were.
I just hope Scala gets enough traction that I can find real work in the language. After using it for a while languages like Ruby and Python just feel primitive.
Followed up your suggestion of Gosu, which I hadn't heard about before. Looks interesting but this feature comparison chart is hilarious:
http://gosu-lang.org/comparison.shtml
It's the first time I've seen "not lisp" as a checkbox feature. :)
Unfortunately I think it may have missed it's peak opportunity to catch on because of this kind of problem - and a chronically buggy and unstable Eclipse plugin - but we'll see.