For a balanced scala article

[Julio Faerman]

Everything i read about Scala nowadays is full of either passion or
hate. I would like to publish a balanced and updated assessment of the
language pros and cons, and for that i would appreciate your help.

I certainly have my point of view, but i would like to hear from you.
If you are a scala user with a couple minutes to spare, please tell me
what caused you most joy and/or trouble.

Thanks in advance,

Julio

[Aleksey Nikiforov]

Here is a quick summary of my experiences with Scala.

Pros:
Increased productivity, subjective factor of 2.
Fewer bugs due to less boilerplate and cleaner code.
The language flexibility allows to design APIs that are simply not possible in Java.
Ability to create compiler plugins to optimize existing libraries (I think this is an incredible feature).

Cons:
Unstable toolchain and IDEs.
Requires decompiling the bytecode to learn how to write performance-sensitive code (not an issue once learned).

Overall, I think Scala is great if you are not writing performance critical code, or if you have the time to learn how it compiles to Java bytecode.

[Seyed H. HAERI (Hossein)]

As a C++ person, I...

> Fewer bugs due to less boilerplate and cleaner code.

... expect this really to be the case, although I haven't given Scala
that much of real-world use yet. And,

> Overall, I think Scala is great if you are not writing performance critical code,

have the same impression so far. I need to state though that it is
only a few months since I've started learning Scala.

HTH,
--Hossein

--------------------------------------------------------------------------------------------------------------

Seyed H. HAERI (Hossein)

Research Assistant
Institute for Software Systems (STS)
Technical University of Hamburg (TUHH)
Hamburg, Germany

ACCU - Professionalism in programming - http://www.accu.org/
--------------------------------------------------------------------------------------------------------------

[Aleksey Nikiforov]

This is off the list.

I think you really misquoted that. The full quote has a very different meaning: "Scala is great if you are not writing performance critical code, or if you have the time to learn how it compiles to Java bytecode."

[Rex Kerr]

This is almost exactly my experience also.  I'll go into a bit more depth:

On Thu, Dec 1, 2011 at 9:28 AM, Aleksey Nikiforov <lex...@gmail.com> wrote:

Here is a quick summary of my experiences with Scala.

Pros:
Increased productivity, subjective factor of 2.

Ranges from 0.8 to about 10 for me; I try to avoid writing too much code in which I am less productive than Java.  For quick scripting tasks, it is often in the 5-10x range.  There are many, many reasons for the increased productivity, ranging from functional libraries to trivially easy nested method declarations that make it simple to reduce boilerplate to powerful matching capability to low-effort exception handling and so on.
 

Fewer bugs due to less boilerplate and cleaner code.

Indeed, and due to using features (e.g. Option) that make it much easier to handle corner cases, once you have mastered how they work.
 

The language flexibility allows to design APIs that are simply not possible in Java.

Indeed.  Especially being able to use operators for mathematics.  In Scala, if I have a vector operation, I write it down.  In Java, I write down the vector operation in a comment, and then produce an unreadable mess that implements it.
 

Ability to create compiler plugins to optimize existing libraries (I think this is an incredible feature).

I haven't personally used this.

I also find the REPL a huge advantage--both that it exists, and that the language features are such that it makes sense to have a REPL.  One could create a Java REPL, but it would be awkward to use.

And of course I appreciate that it runs on the JVM, because that means I can deploy it "anywhere" (major platforms).
 

Cons:
Unstable toolchain and IDEs.

Agreed, though I find the toolchain and IDEs much more dispensable than with Java.  However, I would not consider this problem solved until there is not just one build tool and IDE that is stable and delivers useful features, but a decent selection.  For example, I should be able to use make, ant, maven, or SBT, without having to worry that I will spend endless time getting the tooling right.
 

Requires decompiling the bytecode to learn how to write performance-sensitive code (not an issue once learned).

Indeed.  Writing high-performance Scala is very doable, but it takes rather a while to learn how to do it by design rather than by getting it working and then profiling (which is much more labor-intensive than doing it right the first time).  (That said, that you can write high-performance code at _all_ is almost unique among languages with Scala's expressiveness.)

Also: although simple uses of the collections library give you amazing power, mastering it is a lot of work, and doing anything sophisticated with it even when you are a master requires considerable effort.

And there are still spots in the library which are not documented well (scala.util.continuations) or possibly shouldn't be there at all (scala.util.automata).  This is being rapidly improved, so it's probably not true any more, but previously I'd often find something in the library that _looked_ like it did what I needed, except that it took so long to figure out how to use it that it was often better to re-implement the desired subset of functionality from scratch.

  --Rex

[Donald McLean]

On Thu, Dec 1, 2011 at 9:55 AM, Rex Kerr <ich...@gmail.com> wrote:
>> Cons:
>> Unstable toolchain and IDEs.
>
> Agreed, though I find the toolchain and IDEs much more dispensable than with
> Java.  However, I would not consider this problem solved until there is not
> just one build tool and IDE that is stable and delivers useful features, but
> a decent selection.  For example, I should be able to use make, ant, maven,
> or SBT, without having to worry that I will spend endless time getting the
> tooling right.

The IDEA plugin for Scala is already pretty good (better than any IDE
available in the 20th century) and continuously improving. (IMO)

>> Requires decompiling the bytecode to learn how to write
>> performance-sensitive code (not an issue once learned).
>
> Indeed.  Writing high-performance Scala is very doable, but it takes rather
> a while to learn how to do it by design rather than by getting it working
> and then profiling (which is much more labor-intensive than doing it right
> the first time).  (That said, that you can write high-performance code at
> _all_ is almost unique among languages with Scala's expressiveness.)

This indicates shortcomings in the Scala optimizations. It shouldn't
be necessary to do this.

> Also: although simple uses of the collections library give you amazing
> power, mastering it is a lot of work, and doing anything sophisticated with
> it even when you are a master requires considerable effort.
>
> And there are still spots in the library which are not documented well
> (scala.util.continuations)

Spots in the library? More like one big spot that covers pretty much
the entire library. ScalaDoc for collections is particularly
egregious.

Donald

[Rex Kerr]

On Thu, Dec 1, 2011 at 10:49 AM, Donald McLean <dmcl...@gmail.com> wrote:

Spots in the library? More like one big spot that covers pretty much
the entire library. ScalaDoc for collections is particularly
egregious.

Maybe you can give some examples?  For instance, I click on "scala.collections" and I get:

Contains the base traits and objects needed to use and extend Scala's collection library.

Guide

A detailed guide for the collections library is available at http://www.scala-lang.org/docu/files/collections-api.

Using Collections

// Brief description of how to use and create collections, etc.


Then I go click on scala.collections.immutable.Vector and see stuff like:

def drop (n: Int): Vector[A]

Selects all elements except first n ones.

Selects all elements except first n ones.

What do you think is missing?  (Now, not historically?)

  --Rex

[Donald McLean]

For starters, there shouldn't be a "detailed guide for the collections
library". All of that information should be in the ScalaDoc.

And yes, examples is one of the things that is missing. Doing a
foreach on a map is completely non-trivial, the ScalaDoc is completely
useless and the "detailed guide" is completely mute on the subject.

IMO

Donald

[Nils Kilden-Pedersen]

On Thu, Dec 1, 2011 at 8:28 AM, Aleksey Nikiforov <lex...@gmail.com> wrote:

Cons:
Unstable toolchain and IDEs.
Requires decompiling the bytecode to learn how to write performance-sensitive code (not an issue once learned).

The biggest con for me is the lack of descriptive names in the collections library. Every single time I have to look up the docs to find out how e.g. to add to a particular collection. Sometimes it's +, other times :+, and then there's ++ vs ++:, etc. I can haz descriptive names?

[Trond Olsen]

The good parts:

• mix of object-oriented and functional
  
• syntax
  
• traits
• pattern matching/extractors/algebraic-data-types
  
• closures/higher-order-functions
  
• actors (structuring my program as async components with message passing)
  
• collection library
• @specialized (full performance for generic code)
  
• immutability (transform instead of modify)
• type inference
• partial functions (defined on value range, orElse, andThen)
• parser combinators (useful for various text parsing)
• scala compiler
  

The not so good parts:

• IDE developers wasn't able to keep up with compiler since 2.7-2.8 (2009-2011). Eclipse and IntelliJ only one left with active development (Eclipse is of good quality now though).
  
• Twitter (too much publicity :)
• API documentation.
• Symbol usage (incredibly useful for established domain, and very terse for user-defined domain).
  
• Contributers don't maintain code. Partly caused by academics who shifts focus.
• Type system seems a bit ad-hoc.
  
• No scala-centric I/O library (but one in development for some time).
• scala compiler (not fun compiling it when you include it in your own project :)
  

The awsome parts:

• scalacheck
  

Writing my own code has been a very enjoyable experience (modulo time to acclimate myself to immutability, regretting not writing my earlier code this way). The "good parts" is basically what I stick to. Started using it in 2008 and didn't experience any problems beside the "not so good parts". If you're willing to learn you shouldn't have any problems with Scala (my background was C/C++ from CS in college).

[Sciss]

i find -, +, ++ very intuitive, but since the 3.5 years i use scala, my brain was unable to capture whether +: is append and :+ is prepend, or the other way round. i am shocked that i need to look that up virtually everytime i use it, or i just put it with 50:50 chance and wait for the compiler to complain so that i switch +: and :+. i hope nothing is damaged in one of my hemispheres.

:) having said that, working with scala collections is just phantastic, the design is just great. i think this is one of the keystones.

best, -sciss-

[Trond Olsen]

I should add my biggest concern is Oracle buying Sun.They are pretty much incompatible with open source, and small to medium businesses. It shouldn't affect your decision choosing Scala though if you've already chosen the Java-platform. In fact, an potential added bonus might be migration to other platforms due to the scala compiler.

[Matthew Pocock]

On 1 December 2011 16:43, Nils Kilden-Pedersen <nil...@gmail.com> wrote:

On Thu, Dec 1, 2011 at 8:28 AM, Aleksey Nikiforov <lex...@gmail.com> wrote:

Cons:
Unstable toolchain and IDEs.
Requires decompiling the bytecode to learn how to write performance-sensitive code (not an issue once learned).

The biggest con for me is the lack of descriptive names in the collections library. Every single time I have to look up the docs to find out how e.g. to add to a particular collection. Sometimes it's +, other times :+, and then there's ++ vs ++:, etc. I can haz descriptive names?

I know this is more of a discussion point, but it would really help if it was possible to annotate a symbolic name with an additional textual one. Some sort of 'this is the symbol for the textually-named function ...' may work, something like '@textualName ...' in the scaladoc or @aliasFor in the source? The reality is that in many situations there is a symbolic and textual name that are exact synonyms. Supporting this more directly would help both IDEs and scaladoc to make this more transparent to users. I'm Imagining something like:

trait List[T] {

  ...

  def cons(t: T): List[T]

  @aliasFor(cons) // compiler enforces that cons is a visible member

  def +(t: T): List[T] = cons(t) // compiler-enforced that + does chain through directly

}

Or, if you take this seriously,

trait List[T] {

  ...

  @aliassedAs(+)

  def cons(t: T): List[T] // generates: @synthetic def +(t: T): List[T] = cons(t)

}

Just thinking out loud, but this particular issue is both real and can be addressed through tooling in the documentation generation and minor tweaks to the compiler.

Matthew

 

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[Maxime Lévesque]

>   def cons(t: T): List[T]
>   @aliasFor(cons) // compiler enforces that cons is a visible member
>   def +(t: T): List[T] = cons(t) // compiler-enforced that + does chain through directly

I would love this to be available,
it's in my short list of high value / low effort improvements that
would make a difference
in my daily life.

[Geir Hedemark]

On 2011, Dec 1, at 5:43 PM, Nils Kilden-Pedersen wrote:
> The biggest con for me is the lack of descriptive names in the collections library. Every single time I have to look up the docs to find out how e.g. to add to a particular collection. Sometimes it's +, other times :+, and then there's ++ vs ++:, etc. I can haz descriptive names?

I second this, less the lolcats.

Geir

[Tim Pigden]

I don't agree. I'm entirely happy with a detailed guide if done well.
If it's on-line then the scaladoc can forego detailed descriptions if
it provides a link to an appropriate explanation. But I don't think
you should omit scaladoc and hope people will read the whole detailed
guide to find out what it is they should be using.

[Julio Faerman]

Wow, that is great feedback, thanks a lot and please keep sending :)

Just to clarify, i will collect opinions from several sources, this
list being the most valuable, then check *all* the facts and write.

Is anyone using scala for .NET who could also share the experience?

[marc]

On Thursday, December 1, 2011 6:55:56 AM UTC-8, Rex Kerr wrote:

 

Requires decompiling the bytecode to learn how to write performance-sensitive code (not an issue once learned).

Indeed.  Writing high-performance Scala is very doable, but it takes rather a while to learn how to do it by design rather than by getting it working and then profiling (which is much more labor-intensive than doing it right the first time).  (That said, that you can write high-performance code at _all_ is almost unique among languages with Scala's expressiveness.)

Do you know of any references for  tricks and techniques to get the most of your scala code?  I am using scala in HPC

and could use a new bag a tricks for performance-critical areas.  So far, I have made great bounds by macro-optimizations

(algorithm improvement and parallelization), but am now getting into the situation where I have to go micro.

This could be a post itself and am happy to move this to its own question.

marc

[√iktor Ҡlang]

We have tons of experience on this topic, I just wished I had time to do more blogging :(
 

This could be a post itself and am happy to move this to its own question.

marc

--
Viktor Klang

Akka Tech Lead

Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

[marc]

On Thursday, December 1, 2011 10:02:46 AM UTC-8, √iktor Klang wrote:

On Thu, Dec 1, 2011 at 6:58 PM, marc <mill...@gmail.com> wrote:

On Thursday, December 1, 2011 6:55:56 AM UTC-8, Rex Kerr wrote:

 

Requires decompiling the bytecode to learn how to write performance-sensitive code (not an issue once learned).

Indeed.  Writing high-performance Scala is very doable, but it takes rather a while to learn how to do it by design rather than by getting it working and then profiling (which is much more labor-intensive than doing it right the first time).  (That said, that you can write high-performance code at _all_ is almost unique among languages with Scala's expressiveness.)

Do you know of any references for  tricks and techniques to get the most of your scala code?  I am using scala in HPC

and could use a new bag a tricks for performance-critical areas.  So far, I have made great bounds by macro-optimizations

(algorithm improvement and parallelization), but am now getting into the situation where I have to go micro.

We have tons of experience on this topic, I just wished I had time to do more blogging :(

You just spend to much time shipping awesome unicorns is the problem ;-) 

[Jason Zaugg]

On Thu, Dec 1, 2011 at 6:58 PM, marc <mill...@gmail.com> wrote:

Here's a relevant presentation from NEScala.

http://vimeo.com/20290504

https://docs.google.com/present/view?id=0AS8emH3-FLt3ZGRtbWJyOGdfMTFmcDZkcTk2cw&hl=en

This is definitely a topic that warrants a guide on docs.scala-lang.org.

-jason

[HamsterofDeath]

i don't really like "pros vs cons" lists. if you think of scala as a
tool like a hammer, you'd think it would be absurd to make a pros/cons
list to be able to compare it to a car and in the end decide "cars are
worse/better than hammers", wouldn't you?

what i use scala for:

+ when performance doesn't matter. under this condition, i can use all
the features scala offers without worries. i just love spamming closures
all over the place, chain collection calls and express anything as a
series of filters and transformations. under these conditions, i'm
*much* faster than in java despite java having superior ide support
(intellij idea).
i am not saying scala itself it slow - i'm saying that for high
performance code, you need to sacrifice the features i like the most. in
extreme cases, you're pretty much back to low level programming (as in
any language).

+ to create DSLs

[Josh Suereth]

Agreed.  Let's start putting together a docs.scala-lang.org article.   Who's willing to help?

[Rex Kerr]

2011/12/1 √iktor Ҡlang <viktor...@gmail.com>

On Thu, Dec 1, 2011 at 6:58 PM, marc <mill...@gmail.com> wrote:

On Thursday, December 1, 2011 6:55:56 AM UTC-8, Rex Kerr wrote:

 

Requires decompiling the bytecode to learn how to write performance-sensitive code (not an issue once learned).

Indeed.  Writing high-performance Scala is very doable, but it takes rather a while to learn how to do it by design rather than by getting it working and then profiling (which is much more labor-intensive than doing it right the first time).  (That said, that you can write high-performance code at _all_ is almost unique among languages with Scala's expressiveness.)

Do you know of any references for  tricks and techniques to get the most of your scala code?  I am using scala in HPC

and could use a new bag a tricks for performance-critical areas.  So far, I have made great bounds by macro-optimizations

(algorithm improvement and parallelization), but am now getting into the situation where I have to go micro.

We have tons of experience on this topic, I just wished I had time to do more blogging :(

I also have way more experience than I ever hoped to have, and also am starved for time.  Hopefully a few of us overly busy yet performance-minded folk can get together and write up some tips.

Ideally, one would like to cover profiling, benchmarking, low-level design patterns, how to help the JVM, patterns for high-performance threading, when to switch from high- to low-level patterns, and selection of algorithms based on use case.

But that's a lot of work.  I don't even have time to do half of one of those, let alone all of them, and you really need to know all of them to routinely produce high-performance code.

  --Rex

[Alex Cruise]

On Thu, Dec 1, 2011 at 8:55 AM, Sciss <con...@sciss.de> wrote:

i find -, +, ++ very intuitive, but since the 3.5 years i use scala, my brain was unable to capture whether +: is append and :+ is prepend, or the other way round. i am shocked that i need to look that up virtually everytime i use it, or i just put it with 50:50 chance and wait for the compiler to complain so that i switch +: and :+. i hope nothing is damaged in one of my hemispheres.

My mnemonic is basically "COLon goes on the COLlection side" -- I remember the colon-suffix-right-associative rule because it's bugged me since day 2--not that I have any well-thought-out alternative proposal.

 

:)  having said that, working with scala collections is just phantastic, the design is just great. i think this is one of the keystones.

Agreed wholeheartedly, except that the "everything is a library" philosophy, while unarguably a great achievement, can make some optimizations much harder (or unpalatable) compared to some languages that have collections as language features.

-0xe1a

[Patrik Andersson]

That still does not tell us where the element goes (first or last); just that the collection argument itself goes to the right or left of the element.

[Rex Kerr]

On Thu, Dec 1, 2011 at 2:10 PM, Patrik Andersson <pande...@gmail.com> wrote:

That still does not tell us where the element goes (first or last); just that the collection argument itself goes to the right or left of the element.

Indeed.  For that, you need the mnemonic, "Write it where you want it to go."

  x +: coll   // x is first
  coll :+ x   // x is last

--Rex

[Sciss]

!

[Brian Schlining]

>
> > "COLon goes on the COLlection side"

Wow! That should go into the scaladocs

--

Brian Schlining

[Bakos Gábor]

On 2011.12.01. 18:48, Julio Faerman wrote:
> Is anyone using scala for .NET who could also share the experience?

Hmm. Regarding the build tools, there is an MSBuild task[1], written in
C#. (There are some blocking bugs[2]: that prevent to implement the
simple build task in Scala.) The .NET generics are not supported yet.
The Visual Studio/MonoDevelop/SharpDevelop plugins are practically
nonexistent (I have started a VS plugin in C#/F#, but as Miguel told me
that they want to implement it in Scala, I abandoned it), so the (.NET)
native tooling support is not existent. (Also, there is no REPL
available.) I am sure it will be really great after .NET generics will
be supported (and the other blocking bugs are fixed), but till then I
would not recommend starting a development that have to interface with
other .NET libraries. I think to get it really useful, a CodeDOM[3]
implementation is also necessary (that would allow the users to use the
parts of tooling requiring code generation, like ASP.NET, WPF, LINQ to
SQL, ...).
According the Miguel Garcia soon there will be more work get available
(they were waiting till the github transition), so hopefully things will
be better. :)
Cheers, gabor

[1]: https://www.assembla.com/spaces/scala-msbuild/new_dashboard
[2]: SI-5095, SI-5094, SI-4966
[3]: http://msdn.microsoft.com/en-us/library/y2k85ax6.aspx

[Julio Faerman]

HamsterOfDeath,

On Dec 1, 4:55 pm, HamsterofDeath <h-s...@gmx.de> wrote:
> Am 01.12.2011 10:10, schrieb Julio Faerman:> Everything i read about Scala nowadays is full of either passion or
> > hate. I would like to publish a balanced and updated assessment of the
> > language pros and cons, and for that i would appreciate your help.
>
> > I certainly have my point of view, but i would like to hear from you.
> > If you are a scala user with a couple minutes to spare, please tell me
> > what caused you most joy and/or trouble.
>
> > Thanks in advance,
>
> > Julio
>
> i don't really like "pros vs cons" lists. if you think of scala as a
> tool like a hammer, you'd think it would be absurd to make a pros/cons
> list to be able to compare it to a car and in the end decide "cars are
> worse/better than hammers", wouldn't you?

I was thinking about this too.

I do not intend to write yet another pros and cons list, but a
realistic and up to date assessment of the language "appliability"
without the noise of enthusiasm or failure.

[Bernd Johannes]

+1
I'm waiting for this to have a quick bubble help in eclipse if I stumble over
a "what is this again?" operator. It would be a HUGE win in my eyes.

Just my 2 cents
Bernd

[Bernd Johannes]

Am Donnerstag, 1. Dezember 2011, 19:55:24 schrieb HamsterofDeath:
> Am 01.12.2011 10:10, schrieb Julio Faerman:
> > Everything i read about Scala nowadays is full of either passion or
> > hate. I would like to publish a balanced and updated assessment of the
> > language pros and cons, and for that i would appreciate your help.
> >
> > I certainly have my point of view, but i would like to hear from you.
> > If you are a scala user with a couple minutes to spare, please tell me
> > what caused you most joy and/or trouble.
> >
> > Thanks in advance,
> >
> > Julio
>

...

>
> what i use scala for:
>
> + when performance doesn't matter. under this condition, i can use all
> the features scala offers without worries. i just love spamming closures
> all over the place, chain collection calls and express anything as a
> series of filters and transformations. under these conditions, i'm
> *much* faster than in java despite java having superior ide support
> (intellij idea).
> i am not saying scala itself it slow - i'm saying that for high
> performance code, you need to sacrifice the features i like the most. in
> extreme cases, you're pretty much back to low level programming (as in
> any language).

I actually think it's a strength of scala to be able to feature both. The
higly productive chain-them-all approach with the collection library with is
absolutely awesome. It's simply cool to see even some involved processing fall
apart into some map filter flatMap zip grouped andwhatnot chains which simply
work in the end - without all the fuss.
On the other hand if performance is the first concern one can always resort to
javaish style and walk on par with java performance.
The ability to do this within one language is amazing.

Greetings
Bernd

[Chris Marshall]

We should include it in the scaladoc for ::: also.

> Date: Thu, 1 Dec 2011 12:04:46 -0800
> From: bschl...@gmail.com
> To: con...@sciss.de
> CC: al...@cluonflux.com; scala...@googlegroups.com
> Subject: Re: [scala-user] For a balanced scala article

[Stefan Wagner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 01.12.2011 20:09, schrieb Alex Cruise:

> My mnemonic is basically "COLon goes on the COLlection side" --

codelicious!

- --

Tsch���--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7YGhgACgkQQeATqGpDnRplEACginYA2wxzmIekC2VyVFOeWzFi
UzIAn0UaFFvK9RAH9iP103qJC/vcnnWm
=ljmV
-----END PGP SIGNATURE-----

[Nils Kilden-Pedersen]

On Thu, Dec 1, 2011 at 1:09 PM, Alex Cruise <al...@cluonflux.com> wrote:

On Thu, Dec 1, 2011 at 8:55 AM, Sciss <con...@sciss.de> wrote:

i find -, +, ++ very intuitive, but since the 3.5 years i use scala, my brain was unable to capture whether +: is append and :+ is prepend, or the other way round. i am shocked that i need to look that up virtually everytime i use it, or i just put it with 50:50 chance and wait for the compiler to complain so that i switch +: and :+. i hope nothing is damaged in one of my hemispheres.

My mnemonic is basically "COLon goes on the COLlection side" -- I remember the colon-suffix-right-associative rule because it's bugged me since day 2--not that I have any well-thought-out alternative proposal.

That's a good rule, except when the COLlection is a Set (which is not the fault of your mnemonic of course).

[Daniel Sobral]

On Thu, Dec 1, 2011 at 18:04, Brian Schlining <bschl...@gmail.com> wrote:
>
>>
>> > "COLon goes on the COLlection side"
>
> Wow! That should go into the scaladocs

It's a good one indeed. I'm opening a pull request for that.

--
Daniel C. Sobral

I travel to the future all the time.

[Sébastien Bocq]

2011/12/1 Rex Kerr <ich...@gmail.com>

I also have way more experience than I ever hoped to have, and also am starved for time.  Hopefully a few of us overly busy yet performance-minded folk can get together and write up some tips.

Ideally, one would like to cover profiling, benchmarking, low-level design patterns, how to help the JVM, patterns for high-performance threading, when to switch from high- to low-level patterns, and selection of algorithms based on use case.

But that's a lot of work.  I don't even have time to do half of one of those, let alone all of them, and you really need to know all of them to routinely produce high-performance code.

  --Rex

This would be a very useful resource. I saw some detailed performance analysis passing by on scala-user mailing list but unfortunately these ultimately get lost in the traffic. For example, I remember one where Paul Phillips reported how he improved performance critical sections by avoiding RichString but I can't find it anymore.

Maybe we can:
- create a scala-performance mailing-list.
- add a "Designing for Performance" page to the Scala Wiki under learning resources. We could collect progressively tips, observations, benchmarks or even links to email discussions over there.

Would that help?

--
Sébastien

[Kevin Wright]

+1 for both points.

So... +2 overall I guess :)

[martin odersky]

On Thu, Dec 1, 2011 at 3:55 PM, Rex Kerr <ich...@gmail.com> wrote:

This is almost exactly my experience also.  I'll go into a bit more depth:

On Thu, Dec 1, 2011 at 9:28 AM, Aleksey Nikiforov <lex...@gmail.com> wrote:

Here is a quick summary of my experiences with Scala.

Pros:
Increased productivity, subjective factor of 2.

Ranges from 0.8 to about 10 for me; I try to avoid writing too much code in which I am less productive than Java.  For quick scripting tasks, it is often in the 5-10x range.  There are many, many reasons for the increased productivity, ranging from functional libraries to trivially easy nested method declarations that make it simple to reduce boilerplate to powerful matching capability to low-effort exception handling and so on.
 

Fewer bugs due to less boilerplate and cleaner code.

Indeed, and due to using features (e.g. Option) that make it much easier to handle corner cases, once you have mastered how they work.
 

The language flexibility allows to design APIs that are simply not possible in Java.

Indeed.  Especially being able to use operators for mathematics.  In Scala, if I have a vector operation, I write it down.  In Java, I write down the vector operation in a comment, and then produce an unreadable mess that implements it.
 

Ability to create compiler plugins to optimize existing libraries (I think this is an incredible feature).

I haven't personally used this.

I also find the REPL a huge advantage--both that it exists, and that the language features are such that it makes sense to have a REPL.  One could create a Java REPL, but it would be awkward to use.

And of course I appreciate that it runs on the JVM, because that means I can deploy it "anywhere" (major platforms).
 

Cons:
Unstable toolchain and IDEs.

Agreed, though I find the toolchain and IDEs much more dispensable than with Java.  However, I would not consider this problem solved until there is not just one build tool and IDE that is stable and delivers useful features, but a decent selection.  For example, I should be able to use make, ant, maven, or SBT, without having to worry that I will spend endless time getting the tooling right.
 

Requires decompiling the bytecode to learn how to write performance-sensitive code (not an issue once learned).

Indeed.  Writing high-performance Scala is very doable, but it takes rather a while to learn how to do it by design rather than by getting it working and then profiling (which is much more labor-intensive than doing it right the first time).  (That said, that you can write high-performance code at _all_ is almost unique among languages with Scala's expressiveness.)

I know that Erlang has a very detailed "performance guide" that developers are expected to know. I think it's time to write something similar for Scala. Bytecode disassembly can be fun but is not for everyone the fastest way to learn how to code efficiently. 

Cheers

 -- Martin

[Dave]

Good rule indeed.
Isn't it possible to implement it consistently for all collections in
2.10 since it is binary incompatible anyway?

On 2 dec, 03:16, Nils Kilden-Pedersen <nil...@gmail.com> wrote:
> On Thu, Dec 1, 2011 at 1:09 PM, Alex Cruise <a...@cluonflux.com> wrote:

[Doug Tangren]

-Doug Tangren
http://lessis.me

I know there is a performance characteristics chart for the various flavors of the scala collections library floating around but it would be nice to have recommended patterns and tuning doc. If such a doc ever grows into a book (which I would totally buy), please do not hire the person that Sun hired to do this cover

http://ecx.images-amazon.com/images/I/41hkbXHCRrL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_.jpg 

[Tomás Lázaro]

To me the most important 'feature' of Scala is that it made me a better programmer in a direct as well as indirect manner. There is no depth in Java, you learn it and you are stuck, after 5 years of writing Java you get totally stuck. Scala enables to easily write equivalent Java and also gives you the power and encourages you to actually learn programming.

For people who already know about Haskell, Lisp, Prolog and whatever cool language not used at most jobs it might not be so eye-opening. In my case, being self taught in Java, C++, Actionscript and similar languages bumping into Scala made me realize I knew nothing at all.

The usually negative comment 'Scala is too complicated' is actually a blessing to me and I would not have it any other way. I really appreciate the depth of Scala as much as it's simplicity.

[Tony Morris]

Please be sure to include Runar's trampolining in such a guide.
http://apocalisp.wordpress.com/2011/10/26/tail-call-elimination-in-scala-monads/

It is immensely useful for doing functional programming in Scala while
maintaining reasonable performance.

--
Tony Morris
http://tmorris.net/

[Simon Ochsenreither]

Until now I didn't really see any big binary compatible changes against 2.9 (except dozens of methods from the collection library now gone after the deprecation cycle has ended).

Maybe 2.10 will stay compatible to 2.9?

I'll check trunk against 2.9.1 and report back.

[nicola...@gmail.com]

> Please be sure to include Runar's trampolining in such a guide.
> http://apocalisp.wordpress.com/2011/10/26/tail-call-elimination-in-scala-monads/
>
> It is immensely useful for doing functional programming in Scala while
> maintaining reasonable performance.

As I understand it, this is not about performance but correction.
I think trampolining is slower than a standard call.
But it allows not to overflow the stack.

Best,

Nicolas.

[Rex Kerr]

On Fri, Dec 2, 2011 at 6:04 PM, Tony Morris <tonym...@gmail.com> wrote:

Please be sure to include Runar's trampolining in such a guide.
http://apocalisp.wordpress.com/2011/10/26/tail-call-elimination-in-scala-monads/

It is immensely useful for doing functional programming in Scala while
maintaining reasonable performance.

This is a very interesting pattern, with certain nice characteristics.

But to the extent that I am writing some portion of a *performance* guide--and I agree to write something, as soon as I have time (which might even be before the end of the year)--I won't be including this because it violates one of my top "how to write high-performance code" principles, which is _don't create lots of objects every iteration_.  Trampolines create two objects per iteration (the trampoline itself and the function object); only a good idea if each iteration is already highly expensive _and_ the garbage collection burden of the program is otherwise relatively light.

If someone can demonstrate that escape analysis catches and omits these object creations, then I might change my mind, but I think that's well beyond the capabilities of current JVMs.

If you want genuinely high-performance code (instead of simply higher-performance-than-you-would-have-gotten), then at times you simply have to accept that at least for the time being you will have to learn how to write robust mutable and/or imperative code.  The trick is in developing patterns that let you do this in a robust rather than a fragile manner, and in knowing when this is called for.

  --Rex

[Ken McDonald]

The biggest con for me is the lack of descriptive names in the collections library. Every single time I have to look up the docs to find out how e.g. to add to a particular collection. Sometimes it's +, other times :+, and then there's ++ vs ++:, etc. I can haz descriptive names?

This is one of the higher-order elements of Scala that I _didn't_ have trouble with :-). : is right-associative, so +: means, "the rhs does something with the lhs", which can only mean the lhs is prepended to the rhs in the context of collections.

Also works great for remembering how /: and :\ work. Just remember that these operators take a collection and an element, and return something that takes a function that mushes everything together.

Ken 

[Julio Faerman]

Once again, thanks everyone for the input. I have considered each
opinion and the first draft of the article is ready for review:

https://docs.google.com/document/d/1VHEImTA8poNg6o56eoSDL0CwOtJ2kBxHftDdRlNMBaM/edit

The link is open for editing and commenting. Please forgive (or
correct) the non-native english.

Comments and suggestions are a favor to me and to future readers, the
article will be published on the web shortly.

Thanks in advance,
Julio