Dick, Thanks for dropping in. And I thought you loved the groovy!
> 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 Granted. Thats the problem with translating C# to Scala. Going the other way I might be bitching about C#. > 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 Sure, why not. Personally, I think that its easy enough to do just dropping into something like groovy or jruby or jython for some high level application DSL. Thats what those dynamic language method_missing functions are so good at. But I've never really had to do alot of that builder stuff for real. > 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 had seen Linq for Scala briefly but it looks very sql specific. But not the Continuations stuff so thanks for pointing that out. ScalaQL http://www.cs.uwm.edu/~dspiewak/papers/scalaql.pdf by Daniel Spiewak and Tian Zhao describes something that looks like it can do some of what linq can without compiler modifications. Unfortunately no code has been released on the back of it. What rocks my boat is linq-to-objects, not linq-to-sql. Linq-to-sql is a secondary sideshow compared to Linq to Objects. Linq to objects has by far the most potential: It brings the declarative power of set operations to sequences of in memory objects. The great power of this, is that you express what you want, (and not how to do it), using a familiar syntax plagarised from sql. Write this in imperative Java or C#! var sexyStats = from listOfPeople p, join c in listOfCompanies on p.com_id equals c.com_id where p.isOfWorkingAge equals true group by c.name, p.sex select new { c.name, p.sex, max(p.income) as maxincome min(p.income) as minincome } Wouldn't *you* like to have that in your toolbox? Which brings us neatly to the multicore revolution and PLINQ next. Once you have code expressing *what*you*want (not how*to*get*it) via high level sql like set operations as shown above, the job can be split up across multiple cores. This is what .net4 Plinq is trying to do. Not easy maybe, but a noble goal. Don't get me wrong I love the Scala too but you have to admit the .NET world has some pretty original stuff going on. If something-linq like appears in Scala then I'll be a happy bunny. The syntax does not have to be the same, just as long as its similarly expressive and noise free. > And, of course, finally there is the question of platform > independence. C# 4 would be more interesting if it was available > everywhere Yes, and ran on a very kick ass JVM like Scala does. > 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#. S# here we come! I suppose Martin et al. wouldn't mind a 6 beeeellion dollar settlement in 7 or 8 years time. I hope that they have good lawyers. No really, thats nice to hear. Kinda. With Sun a dead duck and Oracle and IBM in a head to head battle over enterprise-web-db- servers running a deadLikeCobol-Java, there is not going to be a corporate sponsor for Scala anytime soon. (How come Google is so quiet these days?!) Thanks again for your comments Tim (PS ex UKC '83-'86) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
