On 2 June 2011 16:04, Ricky Clarkson <[email protected]> wrote:
> > Akka
>
> Akka has a Java and a Scala API.
>
> > Such as adding closures, adding type inference, allowing symbolic method
> > names
>
> Very limited type inference. Not all Scala's fault, it's partly
> because of the interop with Java.
>
True, H-M just can't be used in the face of subclassing
> > and removing checked
> > exceptions?
>
> I'm not sure that's an advantage. Better syntax for rethrowing would
> be, but as it stands that's like saying Groovy is better because it
> removes your compile errors.
I'm not starting again on how many ways checked exceptions are wrong, it's
an old argument.
We'll doubtless start to see the problems really happen once Java gets
closures and parallel arrays.
> > Okay, this one is more subjective. Scala is certainly different from
> Java
> > (but not crazily so, like Clojure is). It's hard to imagine how those
> > differences could be reduced without hobbling the language though.
>
> Not especially.
>
> val x: String = foo
> becomes
> final String x = foo
>
> var x: String = foo
> becomes
> String x = foo
>
This difference is a feature. If you're making mutability easier by default
then you have some nast problems with thread safety and concurrency in your
future.
> Int, Double, Float, etc.
> become
> int, double, float, etc.
>
But they aren't the same. You could equally have said Integer instead of
int.
Old versions of Scala did actually allow int as well as Int. This has now
been deprecated as people were continuing to think of the things as
primitives. It also breaks consistency with the pattern that class names
start with an uppercase letter.
> val f: Int => Int = x => x * 2
> becomes
> final (int => int) f = x => x * 2
>
and
val x = "Hello World"
becomes
x = "Hello World"
I suppose?
Except that's not a declaration, it's an assignment. Type inference changes
the rules somewhat,
The ridiculous _root_ for imports should just disappear; all imports
> outside classes or package blocks should be absolute.
>
> _root_ is now deprecated, The current solution is to specify multiple
package statements
package com.mycompany.myproject
package sub1.sub2
package sub3
Thus avoiding the problems that necessitated _root_, and also allowing the
convenience of relative package names
> for (x -> 1 to 5)
> becomes
> for (x: 1 to 5)
This beaks a convention that : is used to specify types.
There's a running pattern here, that Scala places a far higher premium on
internal consistency than Java does. This is a Good Thing
> > Typesafe, Google, Twitter, LinkedIn, FourSquare, Amazon
>
> How are Google backing Scala?
>
Today and tomorrow, they're sponsoring ScalaDays:
http://days2011.scala-lang.org/
Jeff Huber is also an investor at Typesafe: http://typesafe.com/company/team
<http://days2011.scala-lang.org/>
> >> - statically typed
> >
> > Yes.
>
> Minus exceptions.
>> - similar performance to Java
> >
> > Slower in some cases, faster in others
>
> In which cases is Scala faster, and why?
>
>
It's faster in cases where it's easier to take advantage of parallelism, and
where generic types can avoid boxing/unboxing costs via specialization (
http://www.scala-lang.org/sid/9)
> > So add to the list of requirements:
> > - Must be well suited to handle concurrency on a large (100+ core) scale?
>
> Perhaps multi-process architecture, like Chrome, is a good natural
> step there, without having to switch languages. Also, Scala doesn't
> enforce anything that helps in concurrency. It only provides useful
> libraries. There's not even a good way of looking for unsafe code
> like there is with Haskell (literally, look for the word unsafe).
Haskell rocks, but I was specifically limiting this discussion to the Java
platform.
Jaskell exists, but doesn't seem mature yet.
> Because that's where the next big driver will be for people to shift away
> > from Java
>
> I think the big driver will be Apple, and possibly Microsoft+Nokia.
>
I hope not. Biology has shown time and time again that Monocultures are
risky and fragile things. It's a beautiful thing that Java works across so
many operating systems.
--
Kevin Wright
gtalk / msn : [email protected]
<[email protected]>mail: [email protected]
vibe / skype: kev.lee.wright
quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda
"My point today is that, if we wish to count lines of code, we should not
regard them as "lines produced" but as "lines spent": the current
conventional wisdom is so foolish as to book that count on the wrong side of
the ledger" ~ Dijkstra
--
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.
