This is an interesting discussion nucleus for sure, but the article
does tend to conveniently ignore some features in Scala that really do
push Scala ahead in those areas. One such example is traits. Unless I
have missed something, C# still doesn't have traits or mixins and
relies on the interface model like Java. When you use traits you are
suddenly opened up to a world of possibilities that, generally
speaking, require bytecode manipulation, source code generation, or
other such tricks in a language without them. For example, right now I
am working through an idea involving a hybrid model for dependency
injection (that is, somewhere between the cake model popular in the
Scala world, and something more like Guice). The whole thing is made a
lot easier with traits for enabling the injection behavior. It's easy
to imagine other more complex abstractions being equally served by
this feature. Many developers don't get traits if they come from a
Java background (many python or ruby developers of course do get them
straight away), but when you get used to them, they enable a new
vector of problem solving.
As far as things I would love to see in Scala, top of my list would be
some choice or convention to allow the "builders" that Groovy has. I
believe that this could be done in a fairly straightforward manner
although admittedly I have not thought through all of the implications
properly yet - but the idea would be to adopt a similar approach to
Python - as in having a getAttr() or invokeMethod() method added to a
class through some kind of uber-trait, and then have that called on
the class if another method or property did not satisfy the request.
This would of course sidestep some of the static type checking for
those methods, but only in cases where the trait was specified in the
class, e.g. something like this:
class XmlBuilder extends Builder {
def invokeMethod(methodName : String, args : Any*) {
// do clever stuff here
}
}
This would then allow the sort of builder cleverness that ruby has -
with a suitable compiler plugin, e.g.
val xmlBuilder = new XmlBuilder
xmlBuilder.doc() // calls the invokeMethod in this case with the name
"doc" passed in
With a bit of fiddling, a separate form of the method that takes a
function parameter for example, you could get:
xmlBuilder.doc() {
xmlBuilder.address()
}
and extending it further, maybe build up the full builder support that
Groovy has (weave named parameters in from Scala 2.8 for example).
It's worth noting that this can be done with a compiler add-on in
Scala, which, while the usual concerns about non-standard forms of the
language with different add-ons are upheld, does provide an excellent
playground for trying out new ideas to see if they should maybe be
added (I believe this will stir a lot of experimentation and energy to
extend the language). It is also worth taking a look at Continuations
(used by Swarm) and LINQ for Scala, both of which use this feature
already.
http://permalink.gmane.org/gmane.comp.lang.scala.announce/154
http://www.scala-lang.org/node/2096
I did find Neal Gafter's talk on Dynamic types in a statically typed
language great at the JVM language summit, and I think that would be a
fine idea in Scala long term as well, just as long as both of these
features do not break all the static typing goodness if you don't use
them (which they shouldn't). Certainly the builder idea would make it
impossible for the IDE to predict all of the methods you might call
for those classes, but shouldn't affect any others.
And, of course, finally there is the question of platform
independence. C# 4 would be more interesting if it was available
everywhere (and moreover that the libraries were consistent between
platforms). I do see that Miguel de Icaza is promising C# 5 (more
features than 4) when Mono 3.0 arrives, and that will be great, but I
still am not seeing a lot of cross platform apps in Mono/.NET. Right
now, Scala seems to be the sweet spot for cross platform development.
Anyway, good discussion, but personally I still place Scala ahead - at
least for me. Microsoft would seem to agree at least in some form,
since they are currently funding an effort to get Scala up to date on
the CLR again, a very interesting move for the company that makes both
C# and F#.
Cheers
Dick
On Nov 1, 8:24 am, Noctiluque <[email protected]> wrote:
> Poor etiquette, posting a link to my own blog, but in the last couple
> of weeks I've realized just how far Java is behind C#. Maybe I should
> have realized this long ago! The post is about my experience
> translating a nice self contained C# .NET4 (in beta 2) program into
> Scala 2.8 (pre release). The tragic thing is that the C# code is
> pretty much equivelent to idiomatic Scala and (debatably) outclasses
> Scala in a couple of areas. Java does not even come close to C#
> anymore from a language features/expressivity point of view. Sniff. No
> really.
>
> http://quoiquilensoit.blogspot.com/2009/11/scala-almost-as-good-as-c-...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
