Yes, Michael

a very interesting experience report why to move away from Scala to Java.


Some remarks caught my attention



"....engineers need to have an accurate mental model of how these
libraries work or
they shift into cargo-culting snippets of code as magic talismans of
functionality."


COMMENT: Do we sometimes experience the same in Smalltalk?




"Via profiling and examining the bytecode we
managed to get a 100x improvement by adopting some simple rules:

1. Don't ever use a for-loop. Creating a new object for the loop closure,
passing it to the iterable, etc., ends up being a forest of invokevirtual calls,
even for the simple case of iterating over an array. Writing the same code as a
while-loop or tail recursive call brings it back to simple field access and
gotos.
"

COMMENT: I think in Smalltalk much more optimization has happened in
the last 30 years and I am not aware of problems like this.




....
5. Avoid closures. Ditching Specs2 for my little JUnit wrapper meant that the
main test class for one of our projects (~600-700 lines) no longer took three
minutes to compile or produced 6MB of .class files. It did this by not capturing
everything as closures. At some point, we stopped seeing lambdas as free and
started seeing them as syntactic sugar on top of anonymous classes and thus
acquired the same distaste for them as we did anonymous classes.

COMMENT: Smalltalk blocks don't seem to bring this kind of problem.
Due to what?


--Hannes

On 11/30/11, Michael Haupt <mhaupt at gmail.com> wrote:
> Hi,
>
> for those interested in dynamic programming languages, here's one on
> Scala: https://gist.github.com/1406238
>
> The background info is here: http://www.infoq.com/news/2011/11/yammer-scala
>
> Best,
>
> Michael
>
>