<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://lambda-the-ultimate.org">
<channel>
 <title>Lambda the Ultimate - Scala</title>
 <link>http://lambda-the-ultimate.org/taxonomy/term/32/0</link>
 <description></description>
 <language>en</language>
<item>
 <title>Communicating Scala Objects</title>
 <link>http://lambda-the-ultimate.org/node/2970</link>
 <description>&lt;p &gt;I wouldn&#039;t normally think a library is LtU material, but since this one lives at the intersection of embedded DSLs, process calculi, and a spotlight language, I think it fits: &lt;a href=&quot;http://users.comlab.ox.ac.uk/bernard.sufrin/CSO/cpa2008-cso.pdf&quot;&gt;Communicating Scala Objects&lt;/a&gt;, Bernard Sufrin, Communicating Process Architectures 2008.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;In this paper we introduce the core features of CSO (Communicating Scala Objects) – a notationally convenient embedding of the essence of occam in a modern, generically typed, object-oriented programming language that is compiled to Java Virtual Machine (JVM) code.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;If you would like to play with it, the library can be downloaded &lt;a href=&quot;http://users.comlab.ox.ac.uk/bernard.sufrin/CSO/&quot;&gt;here&lt;/a&gt;.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/24">DSL</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/16">Parallel/Distributed</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/32">Scala</category>
 <pubDate>Wed, 03 Sep 2008 18:47:28 -0400</pubDate>
</item>
<item>
 <title>Generics of a Higher Kind</title>
 <link>http://lambda-the-ultimate.org/node/2579</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://www.cs.kuleuven.be/~adriaan/files/genericshk/tcpoly.pdf&quot;&gt;Generics of a Higher Kind&lt;/a&gt;. Adriaan Moors, Frank Piessens, and Martin Odersky.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;With Java 5 and C# 2.0, first-order parametric polymorphism was introduced in mainstream object-oriented programming languages under the name of generics. Although the first-order variant of generics is very useful, it also imposes some restrictions: it is possible to abstract over a type, but the resulting type constructor cannot be abstracted over. This can lead to code duplication. We removed this restriction in Scala, by allowing type constructors as type parameters and abstract types. This paper presents the design and implementation of the resulting type constructor polymorphism. It combines type constructor polymorphism with implicit parameters to yield constructs similar to, and at times more expressive than, Haskell’s constructor type classes. The paper also studies interactions with other object-oriented language constructs, and discusses the gains in expressiveness.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;Many readers will already be aware that Scala has added support for higher-kinded generics, related to Haskell&#039;s type constructor classes. I believe Scala is the first language to provide this capability in an OO &quot;generics&quot; framework. This ECOOP submission presents this work, with many practical examples.&lt;/p&gt;
&lt;p &gt;(Consider this penance for my last post...)&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/12">Object-Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/32">Scala</category>
 <pubDate>Thu, 20 Dec 2007 14:54:02 -0500</pubDate>
</item>
<item>
 <title>David Pollak on lift</title>
 <link>http://lambda-the-ultimate.org/node/2536</link>
 <description>&lt;p &gt;The video and slides of David Pollak&#039;s BayFP presentation on &lt;a href=&quot;http://demo.liftweb.net/lift/&quot;&gt;lift&lt;/a&gt; are available &lt;a href=&quot;http://www.bayfp.org/blog/2007/11/09/david-pollak-on-lift-videos-slides/&quot;&gt;online&lt;/a&gt;.&lt;p &gt;
While the thrust of the talk is on lift as a web framework, you get a very nice intro to Scala along the way, and David even mentions a quick way to get a PLT PhD, for those interested in that sort of thing...&lt;br &gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/31">Javascript</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/30">Ruby</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/32">Scala</category>
 <pubDate>Wed, 14 Nov 2007 19:03:00 -0500</pubDate>
</item>
<item>
 <title>A Real-World Use of Lift, a Scala Web Application Framework</title>
 <link>http://lambda-the-ultimate.org/node/2147</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://blog.lostlake.org/index.php?/archives/45-A-real-world-use-of-lift.html#extended&quot;&gt;A Real-World Use of Lift&lt;/a&gt;&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;
Well, &lt;i &gt;lift&lt;/i&gt; is actually being used in production. I converted a Rails app to &lt;i &gt;lift&lt;/i&gt; and it was a very interesting experience...&lt;/p&gt;
&lt;p &gt;Then we did some benchmarking.  For single request processing, the &lt;i &gt;lift&lt;/i&gt; code, running inside Tomcat, ran 4 times faster than the Rails code running inside Mongrel.  However, the CPU utilization was less than 5% in the &lt;i &gt;lift&lt;/i&gt; version, where it was 100% of 1 CPU (on a dual core machine) for the Rails version.  For multiple simultaneous requests being made from multiple machines, we&#039;re seeing better than 20x performance of the &lt;i &gt;lift&lt;/i&gt; code versus the Rails code with 5 Mongrel instances.  Once again, the &lt;i &gt;lift&lt;/i&gt; code is not using very much CPU and the Rails code is pegging both CPUs.&lt;/p&gt;
&lt;p &gt;In terms of new features, we&#039;ve been able to add new features to the &lt;i &gt;lift&lt;/i&gt; code with fewer defects than with the Rails code.  Our Rails code had 70% code coverage.  We discovered that anything shy of 95% code coverage with Rails means that type-os turn into runtime failures.  We do not have any code coverage metrics for the &lt;i &gt;lift&lt;/i&gt; code, but we have seen only 1 defect that&#039;s been checked in in the 2 weeks since we started using &lt;i &gt;lift&lt;/i&gt; (vs. an average of 1 defect per checkin with the Rails code.)&lt;/p&gt;
&lt;p &gt;So, yes, I&#039;m pimping my own framework, and yes, I&#039;m able to do with &lt;i &gt;lift&lt;/i&gt; what guys like DHH are able to do with Rails, so the comparison is, in some ways, unfair.&lt;/p&gt;
&lt;p &gt;On the other hand, Scala and &lt;i &gt;lift&lt;/i&gt; code can be as brief and expressive as Ruby code.   &lt;i &gt;lift&lt;/i&gt; offers developers amazing productivity gains vs. traditional Java web frameworks, just as Rails does.  On the other hand, &lt;i &gt;lift&lt;/i&gt; code scales much better than Rails code.  &lt;i &gt;lift&lt;/i&gt; code is type-safe and the compiler becomes your friend (this does not mean you should not write tests, but it means that your tests can focus on the algorithm rather than making sure there are no type-os in variable and method names.)
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p &gt;I &lt;em &gt;promise&lt;/em&gt; that &quot;Dave Pollak&quot; is not a pseudonym for &quot;Paul Snively.&quot;&lt;/p&gt;
&lt;p &gt;&lt;b &gt;Update:&lt;/b&gt; I guess the self-deprecating humor hasn&#039;t worked, some 400+ reads later. Although the caveat that Dave offers about trying to objectively compare his own framework with Ruby on Rails is well-taken, I think that this nevertheless is an important marker in applying a very PLT-driven language and framework, Scala and lift, to a very realistic application, especially given that it&#039;s a rewrite from a currently-popular language and framework, Ruby and Rails. We admitted proponents of static typing and weird languages are constantly being asked for this sort of thing, and while it&#039;s doubtful that this adds anything to the PLT discussion &lt;i &gt;per se&lt;/i&gt;&amp;mdash;at least until we have a chance to dig into lift and see how Scala&#039;s design uniquely supports it&amp;mdash;I thought people might find the Scala connection worth commenting on.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/12">Object-Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/32">Scala</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/17">Software Engineering</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/27">XML</category>
 <pubDate>Thu, 22 Mar 2007 12:06:24 -0400</pubDate>
</item>
<item>
 <title>Matching Objects With Patterns</title>
 <link>http://lambda-the-ultimate.org/node/1960</link>
 <description>&lt;p &gt;&lt;a href=&quot;http://lampwww.epfl.ch/~emir/written/MatchingObjectsWithPatterns-TR.pdf&quot;&gt;Matching Objects With Patterns&lt;/a&gt;. Burak Emir, Martin Odersky, and John Williams.&lt;/p&gt;
&lt;blockquote &gt;&lt;p &gt;Data in object-oriented programming is organized in a hierarchy of classes. The problem of object-oriented pattern matching is how to explore this hierarchy from the outside. This usually involves classifying objects by their run-time type, accessing their members, or determining some other characteristic of a group of objects. In this paper we compare six different pattern matching techniques: object-oriented decomposition, visitors, type-tests/typecasts, typecase, case classes, and extractors. The techniques are compared on nine criteria related to conciseness, maintainability and performance. The paper introduces case classes and extractors as two new pattern-matching methods and shows that their combination works well for all of the established criteria.&lt;/p&gt;&lt;/blockquote&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/12">Object-Functional</category>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/32">Scala</category>
 <pubDate>Thu, 04 Jan 2007 15:01:08 -0500</pubDate>
</item>
<item>
 <title>Video: The Scala Experiment</title>
 <link>http://lambda-the-ultimate.org/node/1837</link>
 <description>&lt;p &gt;An hour long presentation by Martin Odersky on &lt;a href=&#039;http://video.google.com/videoplay?docid=553859542692229789&#039;&gt;The Scala Experiment&lt;/a&gt; is available on Google Video.  Covers a lot of territory, including (naturally) integration of FP/OOP, Erlang style Actors, Components vs. APIs, ML Functors, mixins, self-types - to name a few.  The video is fuzzy on the slides, so it helps to have the &lt;a href=&#039;http://lampwww.epfl.ch/~odersky/talks/google06.pdf&#039;&gt;pdf of the slides&lt;/a&gt; handy.&lt;/p&gt;
&lt;p &gt;I can&#039;t say that I groked all the implications of the ground covered, much less the exact syntax, but at least it gave me a better feel for some of the PL problems that the Scala project is trying to address.&lt;/p&gt;</description>
 <category domain="http://lambda-the-ultimate.org/taxonomy/term/32">Scala</category>
 <pubDate>Wed, 15 Nov 2006 18:41:37 -0500</pubDate>
</item>
</channel>
</rss>
