Scala Debate

More relaxed discussions: questions and suggestions on Scala's future, discussions that start elsewhere become but become too specific, topics that are not of general interest.

Re: Yammer moving away from Scala

On 30 November 2011 22:55, Russ Paielli wrote:
>
> I assume that compiling with -optimize takes longer, and that is why it is
> not the default. If it takes no longer to compile (and it works reliably),
> then yes it might as well be the default.

It does take significantly longer to compile large code bases with
-optimize enabled.

Yammer moving away from Scala

I'm surprised I haven't seen this mentioned by now:

Email critique of Scala: https://gist.github.com/1406238

A sample new story on it: http://www.infoq.com/news/2011/11/yammer-scala

It's a very detailed email from an employee at Yammer on why they are
migrating from Scala back to Java. I know it was intended to be private,
but it's gone public now, and there's nothing personal in the email anyways.

Re: Re: Example Issue with Scala API Documentation and Scala Complexity

agreed

On Wed, Nov 30, 2011 at 9:22 AM, Daniel Sobral wrote:
> I'd go with ResultType. Yes, it is a bit redundant in that the
> namespace for it *is* the type namespace, but I think it makes reading
> it easier.
>
> On Wed, Nov 30, 2011 at 13:45, Rex Kerr wrote:
>> I would go with something shorter than ResultCollection; the signatures are
>> long enough already to be hard to parse.  "Result" at most, I'd say.
>>
>>   --Rex
>>
>> On Wed, Nov 30, 2011 at 10:38 AM, Josh Suereth
>> wrote:
>>>
>>> "That" is used an awful lot in the collection library, and I agree that
>>> better name (like ResultCollection) could be used.

Example Issue with Scala API Documentation and Scala Complexity

I was trying to figure out how to start up a process and capture and
went to

Re: Human perception of complexity

Am 27.11.2011 16:21, schrieb Rex Kerr:
8OFiuTSMRWy9Jai+ThP5obZ_+cdEe0cLiwg [at] mail [dot] gmail [dot] com" type="cite">

On Sun, Nov 27, 2011 at 5:08 AM, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star [at] gmx [dot] de> wrote:

Passing associative parameters to a method?

Hi All

I have a slightly weird thought that I would like to get your opinion
on. Please consider a use case of sending emails as an example. Lets
say I have a "send" method on a Email class. Now the method signature
could look like:

def send(template:String, params: Any*) { }

where template is the name/path of the template I would want to use
and params are the objects that should be bound on the template for
generating the email text.

Re: Actual complexity in Scala that warrants simplification

Or to put it differently: Why should match only take a PartialFunction?

On Tue, Nov 22, 2011 at 1:12 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
On Tue, Nov 15, 2011 at 12:28 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

Language improvement proposal - dynamic mixins

Hi everyone,

Currently we can mixin traits either when defining a new class or at
object construction. E.g. I like the fact how I can decorate the Map
with MultiMap:

scala> import collection.mutable._
import collection.mutable._

scala> val map = new HashMap[String, Set[String]] with MultiMap[String,
String]
map:
scala.collection.mutable.HashMap[String,scala.collection.mutable.Set[String]]
with scala.collection.mutable.MultiMap[String,String] = Map()

scala> map.addBinding("first", "1a")
res5: map.type = Map(first -> Set(1a))

scala> map.addBinding("first", "1b")
res6: map.type = Map(first -> Set(1b, 1a))

This is really cool.

Syndicate content

Copyright © 2013 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland