Scala Debate

Hi everyone,

I. Background

I've been looking closely at specialization bugs recently, trying to
figure out how to make the feature less buggy, and more able to handle
real-world situations that users might throw at it. (As a library
author trying to use specialization I feel like I have a reasonably
good idea of some important use cases.)

This has involved reading Iulian's thesis, working on fixing bugs, and
discussing it with others.

Recently there have been quite a few new languages coming out on the
JVM. Kotlin, Ceylon, Gosu, to name but a few. I think that's great.
Experimentation is good, and people who try out one new language will
have a tendency to try out others.

What's not so good is that some Scala advocates have been a little bit
too aggressive/defensive on the subject (soc, smcj, but sometimes also
others). There is absolutely no point in attacking a new programming
language. It will just make people hate you, and by extension the
language you are defending. I know that sometimes Scala advocates get
upset if other language communities ``sell'' their language by
comparing with Scala.

On 14/02/2012 16:57, Daniel Sobral wrote:

CpusQtiaSg7XdyVBaeTYuZYaw [at] mail [dot] gmail [dot] com" type="cite">[...]

CpusQtiaSg7XdyVBaeTYuZYaw [at] mail [dot] gmail [dot] com" type="cite"> Macros + Interpolation make it possible to remove XML while, at the same time, providing it as a library. And, like XML, one could likewise provide JSON, etc.

I am far from a Scala expert and I could be wrong, but to my naive eyes
it looks like two large projects are entering Scala which both
accomplish pretty much the same thing (or at least overlap to a very
large extent):

scala-macros and scala-virtualized

They are both mechanisms that allow you to write normal-looking Scala
code which does something else in the background, like generating SQL
queries and what not. In other words, both scala-macros and
scala-virtualized are mechanisms for creating domain specific languages
in Scala.

Having two distinct and complex mechanisms for doing essentially the
same thing seems wasteful and redundant.

I agree with you martin, but it just seemed to me that PaulP pointed out the sweet spot he asked for, himself :).

One quick-think limitation of this : the annotation won't work on internal methods, since they can't be overloaded. I find myself using default arguments a lot for internal methods (for example, recursive components of a bigger algorithm). It's not that relevant for the existential type bonus it could provide, but still.

---------- Forwarded message ----------
From: martin odersky <martin [dot] odersky [at] epfl [dot] ch>
Date: 2012/2/13
Subject: Re: [scala-debate] first make it real, then make it useful

Is there a sweet spot where something like this would be useful but not complicated? (Examples of complications I'm not real interested in: parameters are not each a completely distinct type, or you invent a language to communicate which expansions you want.)
class A {  @annotation.expandDefaults def f(x: Int = 2, ys: List[String] = Nil, z: Option[Float] = None): String = "" + x + ys + z}

I was wondering if there were any people interested in a friendly
little programming competition with a real cash reward.

> On 07/02/12 12:12, Ryan Hendrickson wrote:
> >> f(t: Option[T])
> >> g(t: T) = f(Some(t))
> >> h = f(None)
> >>
> >> I do it all the time. It is the most appropriate solution. Objectors
> to
> >> the new function names may like to take note that they are very
> >> different functions; as different as any others.
> > Doesn't scale.