Comments on Programming Scala

Comment on 'A Taste of Concurrency'

2009-07-26T08:14:24-07:00

A Taste of Concurrency

The actor is declared to be part of the shapes package. Next, we have two import statements.

ShapeDrawingActor is also defined as a singleton (object). Assume that is necessary, but why?
— maddalab (2009-07-26 08:14:24)

Comment on 'A Taste of Concurrency'

2009-07-26T08:14:24-07:00

A Taste of Concurrency

The actor is declared to be part of the shapes package. Next, we have two import statements.

ShapeDrawingActor is also defined as a singleton (object). Assume that is necessary, but why?
— maddalab (2009-07-26 08:14:24)

Comment on 'A Taste of Concurrency'

2009-07-26T07:44:48-07:00

A Taste of Concurrency

Now that we have defined our shapes types, let’s return to actors. We define an Actor that receives “messages” that are shapes to draw.

since the implementations would depend on details like the operating system platform, graphics API

not when running on the JVM. I agree that draw should not be in the domain model classes for the reason in your comment above "separation of concerns" not for the reasons in the Notes section.

OS is a concern that is abstracted away by the virtual machine
— maddalab (2009-07-26 07:44:48)

Comment on 'A Taste of Concurrency'

2009-07-26T07:36:56-07:00

A Taste of Concurrency

Rectangle is also a concrete subclass of Shape that defines draw and overrides toString. For simplicity, we assume it is not rotated relative to the X and Y axes. Hence, all we need is one point, the lower left-hand point will do, and the height and width of the rectangle.

we assume it is not rotated relative to the X and Y axes

Ehh??? Do not understand what is being said and am not certain it needs to be said.
— maddalab (2009-07-26 07:36:56)

Comment on 'A Taste of Concurrency'

2009-07-26T07:34:03-07:00

A Taste of Concurrency

The body of Point defines one method, an override of the familiar toString method in Java (like ToString in C#). Note that Scala, like C#, requires the override keyword whenever you override a concrete method. Unlike C#, you don’t have to use a virtual keyword on the original concrete method. In fact, there is no virtual keyword in Scala. As before, we omit the curly braces "{…}" around the body of toString, since it has only one expression.

Not certain about this, however I also omit the () braces around methods with no args along with the {} braces as it enforces the uniform access principle in Scala. Clients of the code do not need to know that they are invoking a function or accessing a member

override def toString() = "Point(" + x + "," + y + ")"

would becode

override def toString = "Point(" + x + "," + y + ")"

not certain about its applicability to methods defined in the Java API being overridden in Scala.
— maddalab (2009-07-26 07:34:03)

Comment on 'A Taste of Concurrency'

2009-07-26T07:27:58-07:00

A Taste of Concurrency

The Shape class hierarchy is defined in a shapes package. You can declare the package using Java syntax, but Scala also supports a syntax similar to C#'s “namespace” syntax, where the entire declaration is scoped using curly braces, as used here. The Java-style package declaration syntax is far more commonly used, however, being both compact and readable.

Thought I would add that up until this point in the samples, it is possible to use the Scala REPL, which I find convenient. However with the introduction of packages it would not be possible to use the REPL as the REPL does not support packages. Might be worth noting for readers like me who type packages in the REPL.
— maddalab (2009-07-26 07:27:58)

Comment on 'A Taste of Scala'

2009-07-26T06:12:25-07:00

A Taste of Scala

Now the upper method has been renamed main. Because Upper is an object, this main method works exactly like a static main method in a Java class. It is the entry point to the Upper application.

In the example I believe it is good scala convention to omit the '=' sign as the main method finished with a println, i.e. has result type Unit (would be the same if println was omitted as foreach has a result type of Unit)

The convention is used to indicate "procedural" (relies on side effects, printf) behavior of main
— maddalab (2009-07-26 06:12:25)

Comment on 'A Taste of Scala'

2009-07-26T05:52:44-07:00

A Taste of Scala

The implementation of upper on the second line is also simpler. Scala can usually infer the return type of the method (but not the types of the method arguments), so we drop the explicit declaration. Also, because there is only one expression in the method body, we drop the braces and put the entire method definition on one line. The equals sign before the method body tells the compiler, as well as the human reader, where the method body begins.

The equals sign before the method body tells the compiler, as well as the human reader, where the method body begins.

Is this redundant, and possibly misleading? You already have a must better reason for the equals sign previously when you say

"Using an equals sign also reminds us that even functions are values in Scala, which is consistent with Scala’s support of functional programming"
— maddalab (2009-07-26 05:52:44)

Comment on 'A Taste of Scala'

2009-07-26T05:49:53-07:00

A Taste of Scala

Note that this code is fully thread safe. We don’t declare any variables that might cause thread-safety issues. The API methods we use are also thread-safe. Therefore, we don’t need multiple instances. A singleton object works fine.

Just a comment on the comment. ;)

I did not understand what was being said, until I read Bruce Leidl's comment about scala singletons not have concurrency considerations that you would have when implementing the same in Java.
— maddalab (2009-07-26 05:49:53)

Comment on 'A Taste of Scala'

2009-07-26T05:43:30-07:00

A Taste of Scala

The method body calls the map method on the strings array, which takes a function literal as an argument. Function literals are “anonymous” functions. They are similar to lambdas, closures, blocks, or procs in other languages. In Java, you would have to use an anonymous inner class here that implements a method defined by an interface, etc.

I understand function literals as syntactic sugar. Function literal syntax can be used to code either anonymous functions (do not capture variables in scope, as in the example here, lambdas) or closures.

This is the first time I have read function literals being directly referenced as functions (albeit anonymous).

Nitpicking may be, and I am not certain what is a better approach for someone reading on scala for the first time
— maddalab (2009-07-26 05:43:30)

Comment on 'Why Scala?'

2009-07-26T05:07:41-07:00

Why Scala?

Statically Typed

Surprised you did no mention type inference here (or any of the sub-sections below). Isn't Scala also one of the few "type-inferenced" languages on the JVM?
— maddalab (2009-07-26 05:07:41)

Comment on 'Why Scala?'

2009-07-26T04:53:24-07:00

Why Scala?

When using a static language, you have to think about appropriate type choices more often, which forces you to weigh design choices more carefully. While this may slow down daily design decisions, thinking through the types in the application can result in a more coherent design over time.

As you mentioned previously pro and cons of static and dynamic typing are subjective, but this paragraph is a flame bait

"forces you to weigh design choices more carefully."

Caring about your craft forces you to weigh design choices more carefully and lead to coherent design over time.

I have seen plenty of code in Java that returns Object and invokes methods using reflection over the returned typed. What was needed was an interface that all the returned types returned. Static typing does not by itself lead to better design.
— maddalab (2009-07-26 04:53:24)

Comment on 'Why Scala?'

2009-07-26T04:08:56-07:00

Why Scala?

The never-ending need to scale is driving architectures towards pervasive concurrency. However, Java’s concurrency model, which is based on synchronized access to shared, mutable state, results in complex and error-prone programs.

Just a comment on the writing, this line is difficult to understand

The never-ending need to scale is driving architectures towards pervasive concurrency.

I think you meant the following The never-ending need to scale "software" is driving "application" architectures towards pervasive concurrency.

and I would rather like The never-ending need to scale software is driving application developers towards concurrent architectures.

scale Hardware/Software? architectures Hardware/Software/

Am I to read the original line as

The never-ending need to scale software is driving software architectures towards pervasive concurrency.

The never-ending need to scale software is driving hardware architectures towards pervasive concurrency.

The never-ending need to scale hardware is driving hardware architectures towards pervasive concurrency.

or one of the alternatives
— maddalab (2009-07-26 04:08:56)

Comment on 'A Taste of Concurrency'

2009-07-12T18:22:16-07:00

A Taste of Concurrency

Now that we have defined our shapes types, let’s return to actors. We define an Actor that receives “messages” that are shapes to draw.

Not my intention. Rather I was talking "up" to them, because most experienced devs. would implement this separation of concerns and I want them to know we'll learn techniques for doing that later on.
— deanwampler (2009-07-12 18:22:16)

Comment on 'A Taste of Concurrency'

2009-07-12T18:13:33-07:00

A Taste of Concurrency

In this case, Shape declares an abstract draw method. We know it is abstract because it has no body. No abstract keyword is required on the method. Abstract methods in Scala are just like abstract methods in Java and C#. (See the section called “Overriding Members of Classes and Traits” in Chapter 6, Advanced Object-Oriented Programming In Scala for more details.)

Thanks. Oversight. Will fix.
— deanwampler (2009-07-12 18:13:33)

Comment on 'A Taste of Concurrency'

2009-07-12T18:12:25-07:00

A Taste of Concurrency

Good catch. Thanks. Will fix.
— deanwampler (2009-07-12 18:12:25)

Comment on 'A Taste of Concurrency'

2009-07-11T07:43:46-07:00

A Taste of Concurrency

Circle and Rectangle extend Shape, but Triangle extends Shape(). If this wasn't intentional, it might confuse readers.
— jwolski (2009-07-11 07:43:46)

Comment on 'A Taste of Concurrency'

2009-07-09T15:38:44-07:00

A Taste of Concurrency

Recall that we declared draw as an abstract method in Shape and we implemented draw in the concrete subclasses. Hence, the code in the first case statement invokes a polymorphic operation.

Thanks. We fixed that one ;)
— deanwampler (2009-07-09 15:38:44)

Comment on 'A Taste of Scala'

2009-07-09T15:34:49-07:00

A Taste of Scala

To run this script, go to a command window, change to the same directory and run the following command.

@Geoffrey, I didn't try it any of the IDEs. We tried to avoid any dependencies on using them.
— deanwampler (2009-07-09 15:34:49)

Comment on 'Why Scala?'

2009-07-08T14:29:10-07:00

Why Scala?

An alternative strategy is to combine several, simpler languages, e.g., Java for object-oriented code and Erlang for functional, concurrent code. Such a decomposition can work, but only if your system decomposes cleanly into such discrete parts and your team can manage a heterogeneous environment. Scala is attractive for situations where a single, all-in-one language is preferred. That said, Scala code can happily coexist with other languages, especially on the JVM or .NET.

You may want to point out that using Java and Erlang for the same project is most likely a poor alternative to using Java and/or Scala on their own. E.g. how would a Java class/component call an Erlang method (i.e. integration issues)?

This is the advantage of using Groovy or Scala (or other JVM-compatible languages) for integration with existing JEE or .NET systems.
— asookazian (2009-07-08 14:29:10)

Comment on 'A Taste of Scala'

2009-07-08T14:16:24-07:00

A Taste of Scala

It takes an argument list with a single String argument named s. The body of the function literal is after the “arrow”, =>. It calls toUpperCase() on s. The result of this call is returned by the function literal. In Scala, the last expression in a function is the return value, although you can have return statements elsewhere, too. The return keyword is optional here and it is rarely used, except when returning out of the middle of a block (e.g., in an if statement).

"=>" suggests a function mapping. In this case, the function maps from the set of all strings to the set of upper case strings. "=" implies that the set of all strings is equivalent to the set of upper case strings, which obviously is not true. So, I think the choice of "=>" over "=" is appropriate.
— derekmahar (2009-07-08 14:16:24)

Comment on 'Why Scala?'

2009-07-08T14:11:34-07:00

Why Scala?

Developers want languages that are more succinct and flexible to improve their productivity. This is one reason why so-called “scripting” languages like Ruby and Python have become more popular recently.

what about Groovy? we can use Groovy in Seam apps...

"I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."

http://java.dzone.com/articles/scala-long-term-replacement
— asookazian (2009-07-08 14:11:34)

Comment on 'Why Scala?'

2009-07-08T14:07:08-07:00

Why Scala?

To meet these challenges, many developers are looking for new languages and tools. Venerable standbys like Java, C#, and C++ are no longer optimal for developing the next generation of applications.

as I understand it, the significant advantage that Erlang and Scala offer over Java and C#, for example, are concurrent programming for use in multi-core envmts. And Scala is even more attractive in a J2SE or J2EE platform because it runs in a JVM (compiles to Java bytecode).

Microsoft .NET has just recently implemented the MVC design pattern in ASP.NET:

http://weblogs.asp.net/scottgu/archive/2008/07/14/asp-net-mvc-preview-4-release-part-1.aspx

In many ways, .NET is far behind but traction in JEE frameworks other than Spring and Hibnerate (e.g. Seam 2.x) is very low and EE 6 with Web Beans may not have a high adoption rate in the enterprise deployments either...
— asookazian (2009-07-08 14:07:08)

Comment on 'Why Scala?'

2009-07-08T06:25:02-07:00

Why Scala?

Despite their productivity advantages, dynamic languages may not be the best choices for all applications, particularly for very large code bases and high-performance applications. There is a longstanding, spirited debate in the programming community about the relative merits of dynamic vs. static typing. Many of the points of comparison are somewhat subjective. We won’t go through all the arguments here, but we will offer a few thoughts for consideration.

Given the headings, a Java programmer may skip this section thinking that it is not relevant to them. If they do, they will miss the whole Static vs Dynamic discussion.
— gedb (2009-07-08 06:25:02)

Comment on 'Why Scala?'

2009-07-07T11:02:59-07:00

Why Scala?

Scala is a language for professional developers. Compared to languages like Java and Ruby, Scala is a more difficult language to master, because it requires competency with OOP, FP, and static typing to use it most effectively. It is tempting to prefer the relative simplicity of dynamically-typed languages. Yet, this simplicity can be deceptive. In a dynamically typed language, it is often necessary to use metaprogramming features to implement advanced designs. While metaprogramming is powerful, using it well takes experience and the resulting code tends to be hard to understand, maintain, and debug. In Scala, many of the same design goals can be achieved in a type-safe manner by exploiting its type system and mixin composition through traits.

Put a different way: how do you measure the level of difficulty of a programming language and how this may translate to programmer productivity or suitability to solve particular problems? Experience? Empirical evidence? Anecdotal evidence? Programmer surveys? Programming language popularity?

Unfortunately, programming language choice seems largely driven by familiarity, popularity, and perceived ease of learning rather than by suitability to task and longer term program maintainability.
— derekmahar (2009-07-07 11:02:59)

Comment on 'Why Scala?'

2009-07-07T10:04:55-07:00

Why Scala?

Scala is compelling because it feels like a dynamically typed scripting language, due to its succinct syntax and type inference. Yet, Scala gives you all the benefits of static typing, a modern object model, functional programming, and an advanced type system. These tools let you build scalable, modular applications that can reuse legacy Java and .NET APIs and leverage the performance of the JVM and CLR.

Scala is succinct relative to Java. Which ML languages run on the JVM? Is Clojure, a LISP dialect for the JVM, more concise than Scala?
— derekmahar (2009-07-07 10:04:55)

Comment on 'Why Scala?'

2009-07-07T09:57:51-07:00

Why Scala?

Scala was started by Martin Odersky in 2001. Martin is a professor in the School of Computer and Communication Sciences at the Ecole Polytechnique Fédérale de Lausanne (EPFL). He spent his graduate years working in the group headed by Niklaus Wirth, of Pascal fame. Martin worked on Pizza, an early functional language on the JVM. He later worked on GJ, a prototype of what later became Generics in Java, with Philip Wadler of Haskell fame. Martin was hired by Sun Microsystems to produce the reference implementation of javac, the Java compiler that ships with the Java Developer Kit (JDK) today.

Favour active over passive voice: change "Scala was started by Martin Odersky in 2001" to "Martin Odersky started Scala in 2001".
— derekmahar (2009-07-07 09:57:51)

Comment on 'Why Scala?'

2009-07-06T15:06:14-07:00

Why Scala?

Statically Typed

Statically typed languages also bind a type to every value (or object). Otherwise, polymorphism through dynamic binding would not be possible.
— derekmahar (2009-07-06 15:06:14)

Comment on 'A Taste of Scala'

2009-06-23T08:32:57-07:00

A Taste of Scala

To be clear, these two uses of ‘_’ are completely independent of each other. Method chaining and function-literal shorthands, as in this example, can take some getting used to, but once you are comfortable with them, they yield very readable code with minimal use of temporary variables.

It is difficult to tell that the character before the underscore here is a comma, not a period. Perhaps it should be mentioned explicitly in the text. As well, function parameters are usually separated using a comma and a space, so the curried function here would appear better as:
printf("%s ", _)
An off-hand reference to the arguments could include the word comma to differentiate this from the _.functionName syntax above: "Here the underscore is given as the second parameter of the function, separated from the print format string by a comma, as usual."
— TimMacEachern (2009-06-23 08:32:57)

Comment on 'A Taste of Concurrency'

2009-06-23T07:42:58-07:00

A Taste of Concurrency

Now that we have defined our shapes types, let’s return to actors. We define an Actor that receives “messages” that are shapes to draw.

In "Of course, in a real..." you're talking down to your readers. There's no need for that, certainly at the start of the book. Just drop the "Of course".
— TimMacEachern (2009-06-23 07:42:58)

Comment on 'A Taste of Concurrency'

2009-06-22T13:56:54-07:00

A Taste of Concurrency

The first case does a type comparison with the message. (There is no explicit variable for the message instance in the code; it is inferred.) If the message is of type Shape, the first case matches. The message instance is cast to a Shape and assigned to the variable s, then the draw method is called on it.

A reference to a section that talks about how this inferrence works would be useful; I'm curious, but I've got no link to click.
— diathesis (2009-06-22 13:56:54)

Comment on 'A Taste of Scala'

2009-06-20T21:09:34-07:00

A Taste of Scala

To run this script, go to a command window, change to the same directory and run the following command.

This example doesn't seem to work in the current Eclipse IDE; it's fine at the command-line, but shows that the IDE support is still suspect. :/
— diathesis (2009-06-20 21:09:34)

Comment on 'A Taste of Concurrency'

2009-06-20T09:57:37-07:00

A Taste of Concurrency

The last case clause handles any other message instance, thereby functioning as the default case. The actor reports an error and then drops the message. Any is the parent of all types in the Scala type hierarchy, like Object is the root type in Java and other languages. Hence, this case clause will match any message of any type. Pattern matching is eager; we have to put this case clause at the end, so it doesn’t consume the messages we are expecting!

Okay, no you don't mean that. But maybe you could emphasize 'at the end' a bit more, and point out that unexpected messages would still be consumed (but silently) if it wasn't included.
— robcd (2009-06-20 09:57:37)

Comment on 'A Taste of Concurrency'

2009-06-20T05:05:53-07:00

A Taste of Concurrency

Don't you mean, 'if we don't want it to silently consume the messages we aren't expecting'?
— robcd (2009-06-20 05:05:53)

Comment on 'A Taste of Scala'

2009-06-20T03:57:29-07:00

A Taste of Scala

The first line inside the main method uses the same short-hand notation for map that we just examined.

Note .. main must be a (possibly inherited) method in an object?
— robcd (2009-06-20 03:57:29)

Comment on 'A Taste of Scala'

2009-06-20T03:34:48-07:00

A Taste of Scala

The method return type appears after the argument list. In this case, the return type is Seq[String], where Seq ("sequence") is a particular kind of collection. It is a parameterized type (like a generic type in Java), parameterized here with String. Note that Scala uses square brackets […] for parameterized types, while Java uses angle brackets <…>.

Note ... when you omit the colon

Note ... than when you omit the colon

— robcd (2009-06-20 03:34:48)

Comment on 'Why Scala?'

2009-06-19T19:13:08-07:00

Why Scala?

Mixed Paradigm - Object Oriented Programming

As a Java programmer, I don't find the idea of unifying interfaces with implementations to be an illuminating metaphor. It just makes traits sound like classes. Mixin is a clearer term, as is the reference to Ruby modules.
— diathesis (2009-06-19 19:13:08)

Comment on 'A Taste of Concurrency'

2009-06-19T06:02:01-07:00

A Taste of Concurrency

Maybe a quick explanation of "Unit" here?
— bfollek (2009-06-19 06:02:01)

Comment on 'A Taste of Scala'

2009-06-12T18:54:58-07:00

A Taste of Scala

I know that you don't want to add any further details into this introduction, so I'm writing this comment with that in mind. For some perspective, I'm fairly new to Scala, coming to this book after a plethora of assorted blog posts and tutorials.

As someone who is familiar with Ruby, I'm a bit more interested in why => is used rather than =, and not so much in the fact that the last value of a function is the implicit return value. I think both should be mentioned, but even after reading lots of introductory information, the =/=> distinction still confuses me. Maybe a bit less real-estate for return and a bit more to explain => quickly?
— nolan (2009-06-12 18:54:58)

Comment on 'Why Scala?'

2009-06-06T21:21:52-07:00

Why Scala?

We feel that the extra effort required day to day to use Scala will promote more careful reflection about your designs. Over time, this discipline will yield more coherent, modular, and maintainable applications. Fortunately, you don’t need all of the sophistication of Scala all of the time. Much of your code will have the simplicity and clarity of code written in your favorite dynamically-typed language.

Ah, by "extra effort" do you mean proper design to begin with?
— psalvitti (2009-06-06 21:21:52)

Comment on 'Why Scala?'

2009-06-06T21:20:38-07:00

Why Scala?

I might tone this down a bit ... I mean comparatively speaking, C++, Java, Ruby, et al (statically typed languages) all require competency in OOP, FP and static typing that you indicate for Scala. As Henrik said, what does "mastering" really mean? I can point to "experienced" developers (name the language) that still write horrible code.
— psalvitti (2009-06-06 21:20:38)

Comment on 'A Taste of Concurrency'

2009-06-03T08:25:55-07:00

A Taste of Concurrency

Five messages are sent to the actor, using the syntax actor ! message. The first message sends a Circle instance. The actor “draws” the circle. The second message sends a Rectangle message. The actor “draws” the rectangle. The third message does the same thing for a Triangle. The fourth message sends a Double that is approximately equal to Pi. This is an unknown message for the actor, so it just prints an error message. The final message sends an “exit” string, which causes the actor to terminate.

Thanks!
— deanwampler (2009-06-03 08:25:55)

Comment on 'A Taste of Concurrency'

2009-06-03T08:24:00-07:00

A Taste of Concurrency

All the methods and public fields from Actor are imported. These are not static imports from the Actor type, as they would be in Java. Rather, they are imported from an object that is also named Actor. The class and object can have the same name, as we will see in the section called “Companion Objects” in Chapter 6, Advanced Object-Oriented Programming In Scala.

Missing links now fixed.
— deanwampler (2009-06-03 08:24:00)

Comment on 'A Taste of Concurrency'

2009-06-03T08:23:36-07:00

A Taste of Concurrency

The Point class represents a two-dimensional point on a plane. Note the argument list after the class name. Those are constructor parameters. In Scala, the whole class body is the constructor, so you list the arguments for the primary constructor after the class name and before the class body. (We’ll see how to define auxiliary constructors in the section called “Constructors in Scala” in Chapter 5, Basic Object-Oriented Programming in Scala.) Because we put the val keyword before each parameter declaration, they are automatically converted to read-only fields with the same names with public reader methods of the same name. That is, when you instantiate a Point instance, e.g., point, you can read the fields using point.x and point.y. If you want mutable fields, then use the keyword var. We’ll explore variable declarations and the val and var keywords in the section called “Variable Declarations” in Chapter 2, Type Less, Do More.

Another production problem that has since been fixed. Sorry.
— deanwampler (2009-06-03 08:23:36)

Comment on 'A Taste of Concurrency'

2009-06-03T08:20:46-07:00

A Taste of Concurrency

There are many reasons to be seduced by Scala. One reason is the Actors API included in the Scala library, which is based on the robust Actors concurrency model built into Erlang [Haller2007]. Here is an example to whet your appetite.

Good points. Will fix.
— deanwampler (2009-06-03 08:20:46)

Comment on 'A Taste of Scala'

2009-06-03T08:20:11-07:00

A Taste of Scala

The -cp . option adds the current directory to the search “class path”. You should get the following output.

Thanks! Will fix
— deanwampler (2009-06-03 08:20:11)

Comment on 'A Taste of Scala'

2009-06-03T08:12:01-07:00

A Taste of Scala

That's all I'm really saying.
— deanwampler (2009-06-03 08:12:01)

Comment on 'A Taste of Scala'

2009-06-03T08:08:54-07:00

A Taste of Scala

On the first line, Upper is now declared as an object, which is a singleton. We are declaring a class, but the Scala runtime will only ever create one instance of Upper. (You can’t write new Upper, for example.) Scala uses objects for situations where other languages would use “class-level” members, like statics in Java. We don’t really need more than one instance here, so a singleton is fine.

I'll drop the word "class" from "singleton class" and maybe add some more text.
— deanwampler (2009-06-03 08:08:54)

Comment on 'A Taste of Scala'

2009-06-03T08:06:48-07:00

A Taste of Scala

We cover this topic in the next chapter. I'd rather not go into more details (even a link...) in this cursory introduction.
— deanwampler (2009-06-03 08:06:48)

Comment on 'A Taste of Scala'

2009-06-03T08:02:58-07:00

A Taste of Scala

Will do. Thanks.
— deanwampler (2009-06-03 08:02:58)

Comment on 'A Taste of Scala'

2009-06-03T08:02:21-07:00

A Taste of Scala

Let’s examine the code in detail, so we can begin to learn Scala syntax. There are a lot of details in just six lines of code! We’ll explain the general ideas here. All the ideas used in this example will be explained more thoroughly in later sections of the book.

Yea, I know... Always a struggle to decide how much really needs to be said...
— deanwampler (2009-06-03 08:02:21)

Comment on 'A Taste of Scala'

2009-06-03T08:01:42-07:00

A Taste of Scala

In this example, the upper method in the Upper class (no pun intended) converts the input strings to upper case and returns them in an array. The last line in the example converts four strings and prints the resulting Array.

I don't see it, but it might have been a production error where the "Command Line Tools" link disappeared in a prior build of the book. If you are STILL seeing this, could be a browser issue. Let us know with a new comment.
— deanwampler (2009-06-03 08:01:42)

Comment on 'Why Scala?'

2009-06-03T07:58:36-07:00

Why Scala?

Both Scala and metaprogramming like in Ruby take time to master. Assuming equal teams of "experts", I'm asserting that Scala code will be easier to maintain and evolve over the long-term than roughly-equivalent ruby metaprogramming code. That's my gut feeling...
— deanwampler (2009-06-03 07:58:36)

Comment on 'Why Scala?'

2009-06-03T07:51:27-07:00

Why Scala?

The name Scala is a contraction of the words scalable language. While this suggests that the pronunciation should be scale-ah, the creators of Scala actually pronounce it scah-lah, like the Italian word for “stairs”. That is, the two “a’s” are pronounced the same.

Not sure where to discuss it either. I guess the "default" answer is that Scala fills the same niche as Java, C#, etc. while perhaps also covering some territory for which a "pure" scripting language like Ruby would be an optimal fit.
— deanwampler (2009-06-03 07:51:27)

Comment on 'Why Scala?'

2009-06-03T07:46:44-07:00

Why Scala?

It might appear that OOP and FP are incompatible. In fact, a design philosophy of Scala is that OOP and FP are more synergistic than opposed. The features of one approach can enhance the other.

@Marek. Good point. We cover this later in the book, but I'll add a paragraph about it here.

@Ricky, I'll clarify to say one of the "few"...

@Henrik, I'll add a disclaimer that there can be areas where performance is poor.
— deanwampler (2009-06-03 07:46:44)

Comment on 'Why Scala?'

2009-06-03T07:35:12-07:00

Why Scala?

I think we'll see clojure style mutability approaches, like STM, work their way back into Scala and maybe even Java, as options.
— deanwampler (2009-06-03 07:35:12)

Comment on 'Why Scala?'

2009-06-03T07:31:28-07:00

Why Scala?

Will make this statement more 'inclusive".
— deanwampler (2009-06-03 07:31:28)

Comment on 'Why Scala?'

2009-06-03T07:30:42-07:00

Why Scala?

However, Java was a child of its time. Now it shows its age. In 1995, Java provided a syntax similar enough to C++ to entice C++ developers, while avoiding many of that language’s deficiencies and “sharp edges”. Java adopted the most useful ideas for the development problems of its era, such as object-oriented programming (OOP), while discarding more troublesome techniques, such as manual memory management. These design choices struck an excellent balance that minimized complexity and maximized developer productivity, while trading-off performance compared to natively-compiled code. While Java has evolved since its birth, many people believe it has grown too complex without adequately addressing some newer development challenges.

Yea, our intention isn't to provide a detailed comparison between C++ and Java, but just to indicate the sea change Java represented at the time and to argue that we need another sea change now.
— deanwampler (2009-06-03 07:30:42)

Comment on 'Why Scala?'

2009-06-03T07:28:41-07:00

Why Scala?

To meet these challenges, many developers are looking for new languages and tools. Venerable standbys like Java, C#, and C++ are no longer optimal for developing the next generation of applications.

It's true that Microsoft has kept C# moving forward at a faster rate than Java. However, It is still based on design choices that I think are sub-optimal, like not using type inferencing from the very beginning. C# won't be able to move to more comprehensive type inferencing than it supports now because of the potential parsing ambiguities its syntax would cause.

— deanwampler (2009-06-03 07:28:41)

Comment on 'A Taste of Concurrency'

2009-05-30T12:24:30-07:00

A Taste of Concurrency

Typo: it says "The four message sends...", it should say "The fourth message sends...".
— chifazo (2009-05-30 12:24:30)

Comment on 'Why Scala?'

2009-05-29T07:33:31-07:00

Why Scala?

oops. Page 8: http://books.google.com/books?id=VGT1_UJzjM0C&pg=PA1371&dq=.NET+Apress#PPA8,M1
— ederandres_an (2009-05-29 07:33:31)

Comment on 'Why Scala?'

2009-05-29T07:30:15-07:00

Why Scala?

Java solved many plumbing problems related with C++ programming such as static and dynamic memory management. Also, Java developers had a more legible, well looked sintaxis. So we can say that Java is a cleaner version of C++.

-- this is based on Andrew Troelsen's book: http://books.google.com/books?id=VGT1_UJzjM0C&pg=PA1371&dq=.NET+Apress#PPA7,M1
— ederandres_an (2009-05-29 07:30:15)

Comment on 'Why Scala?'

2009-05-26T09:00:30-07:00

Why Scala?

Don't quite know where to put this comment, but would be nice to see mention of where a scalable language fits within a cloud filled internet. I like things to scale (duhhh) and it may be worthwhile to include how scala could fit within an ASP cloud model of deployment.
— prawsthorne (2009-05-26 09:00:30)

Comment on 'Why Scala?'

2009-05-23T22:09:28-07:00

Why Scala?

To meet these challenges, many developers are looking for new languages and tools. Venerable standbys like Java, C#, and C++ are no longer optimal for developing the next generation of applications.

C# venerable? Please qualify... Given the evolution of C# language from 1.0 - next major version 4.0, not to mention enhancements to the class library and the CLR, it is not clear to me how C# can be viewed as venerable...
— jungho (2009-05-23 22:09:28)

Comment on 'A Taste of Concurrency'

2009-05-23T16:48:03-07:00

A Taste of Concurrency

"built-in Actors library" reads a bit like as if Actors were part of the Scala Language definition; a stronger hint, that Actors in Scala are "just" a library would IMHO be good. Together with Steven's comment above, maybe: "One reason is Scala's Actors library, a concurrency API based on the Erlang's Actors concurrency model." ... removed "robust" due to the "New Lift Actor code" Mail by David Pollak in the Lift Google Group ... which might make a nice side note showing off Scala's flexibility :-)
— battisti (2009-05-23 16:48:03)

Comment on 'A Taste of Scala'

2009-05-23T16:30:45-07:00

A Taste of Scala

On the last line, using an object rather than a class simplifies the code. Instead of creating an instance with new Upper, we can just call the upper method on the Upper object directly (note how this looks like the syntax you would use when calling static methods in a Java class).

Adding a little note explaining that this is also the actual syntax when accessing static methods in Java libraries from Scala code would informative for Java converts or people interested in Scala because of the large number of available (Java) libraries.
— battisti (2009-05-23 16:30:45)

Comment on 'A Taste of Scala'

2009-05-23T16:23:40-07:00

A Taste of Scala

This is probably just some nitpicking, but is "declared as an object, which is a singleton class" correct? According to the Scala Reference it: "deﬁnes a single object of a new class", while a "singleton class" is a class used to implement the singleton pattern... these two concepts are of course related, but in Scala object definitions are also used as a mechanism for creating modules (which AFAIK is usually not the case when using a Singleton Pattern, which got a bad reputation in the last years).
— battisti (2009-05-23 16:23:40)

Comment on 'A Taste of Scala'

2009-05-23T16:03:41-07:00

A Taste of Scala

Using the following "Note" to explaining why "return" is rarely used in scala (interfering with type inference, with an appropriate reference to the section explaining type inference) might be informative for readers only accustomed to Java
— battisti (2009-05-23 16:03:41)

Comment on 'A Taste of Scala'

2009-05-23T15:57:44-07:00

A Taste of Scala

If you're hinting at the similarity with lambdas/blocks in Ruby, adding "closures" at this point might be helpful for readers not familiar with Ruby.
— battisti (2009-05-23 15:57:44)

Comment on 'A Taste of Scala'

2009-05-23T15:49:15-07:00

A Taste of Scala

Is this paragraph really helpful? Of course you're going to explain the ideas contained in this first program more thoroughly later :-)
— battisti (2009-05-23 15:49:15)

Comment on 'A Taste of Scala'

2009-05-23T08:16:04-07:00

A Taste of Scala

To run this script, go to a command window, change to the same directory and run the following command.

Of course you point this out half a page down. Ah well. :-)
— delitescere (2009-05-23 08:16:04)

Comment on 'A Taste of Scala'

2009-05-23T08:12:15-07:00

A Taste of Scala

To run this script, go to a command window, change to the same directory and run the following command.

As it's one of Scala's selling points, might as well keep things as concise as possible (or at least make a note of not being so to aid with initial learning).

(s:String) the type specification is redundant

Console. is also redundant

— delitescere (2009-05-23 08:12:15)

Comment on 'A Taste of Concurrency'

2009-05-21T09:41:51-07:00

A Taste of Concurrency

Recall that we declared draw as an abstract method in Shape and we implemented draw in the concrete subclasses. Hence, the code in the first case statement invokes a polymorphic operation.

Hopefully we also implemented draw in Triangle!
— generex (2009-05-21 09:41:51)

Comment on 'A Taste of Scala'

2009-05-21T08:20:04-07:00

A Taste of Scala

The last line is the prompt that is waiting for your input. The interactive mode of the scala command is very convenient for experimentation (see the section called “The scala Command Line Tool” in Chapter 14, Scala Tools, Libraries and IDE Support for more details). An interactive interpreter like this is called a REPL: Read, Evaluate, Print, Loop.

Test
— bz7 (2009-05-21 08:20:04)

Comment on 'A Taste of Scala'

2009-05-20T19:02:47-07:00

A Taste of Scala

You can also use this short-hand syntax in some more complex function literals, as we will see in Chapter 3, Rounding Out the Essentials.

@Marek: This was just a bug in the rendering system that was dropping the cross reference text. It's been fixed.
— abdelazer (2009-05-20 19:02:47)

Comment on 'A Taste of Concurrency'

2009-05-20T17:08:05-07:00

A Taste of Concurrency

Typo: "auxiliary constructors in in "
— steven807 (2009-05-20 17:08:05)

Comment on 'A Taste of Concurrency'

2009-05-20T17:06:45-07:00

A Taste of Concurrency

In Erlang, there is no "Actors" library -- the concurrency in Erlang is part of the language.
— steven807 (2009-05-20 17:06:45)

Comment on 'A Taste of Scala'

2009-05-20T14:04:02-07:00

A Taste of Scala

Typo in blue box above:

"We discuss these subtleties in in ."
— joebowbeer (2009-05-20 14:04:02)

Comment on 'Why Scala?'

2009-05-20T12:31:53-07:00

Why Scala?

It might appear that OOP and FP are incompatible. In fact, a design philosophy of Scala is that OOP and FP are more synergistic than opposed. The features of one approach can enhance the other.

Can you really trust Scala's speed, for example: http://villane.wordpress.com/2008/02/13/scala-for-avs-while-update/

I think there is some other issues like reflection based implementation on structural types, boxed primitives are not well optimized (afaik).

It's unfortunate thing, but you just can't blindly depend that compiler optimizes things to Java-speed; you have to code Java-like.
— clojure (2009-05-20 12:31:53)

Comment on 'Why Scala?'

2009-05-20T12:24:38-07:00

Why Scala?

Don't you have kind of a contradiction there: "Scala is more difficult to master" and "While metaprogramming is powerful, using it well takes experience, etc"

What does mastering really mean anyway. To get the same thing done in Scala or Ruby can be as hard if done properly (with good maintainability etc), or do you disagree?
— clojure (2009-05-20 12:24:38)

Comment on 'Why Scala?'

2009-05-20T12:21:11-07:00

Why Scala?

Scala's syntax is not particularly succinct, even for statically typed language, compare it to Haskell, or ML based languages.
— clojure (2009-05-20 12:21:11)

Comment on 'Why Scala?'

2009-05-20T12:19:27-07:00

Why Scala?

We have worked with both static and dynamic languages, at various times. We find both kinds of languages compelling for different reasons. We believe the modern software developer must master a range of languages and tools. Sometimes, a dynamic language will be the right tool for the job. At other times, a static language like Scala is just what you need.

This paragraph could be made much concise without losing meaning.
— clojure (2009-05-20 12:19:27)

Comment on 'Why Scala?'

2009-05-20T12:18:45-07:00

Why Scala?

It might appear that OOP and FP are incompatible. In fact, a design philosophy of Scala is that OOP and FP are more synergistic than opposed. The features of one approach can enhance the other.

"Of the set of newer JVM languages, Scala is the only one that is statically typed."

With the exceptions of CAL and JavaFX.
— ricky_clarkson (2009-05-20 12:18:45)

Comment on 'Why Scala?'

2009-05-20T12:15:42-07:00

Why Scala?

Scala is OO based which is almost inherently embraces mutability. This is a long way from Clojure's approach. Actors model is sufficient only for a limited segment of problems.
— clojure (2009-05-20 12:15:42)

Comment on 'Why Scala?'

2009-05-20T12:15:02-07:00

Why Scala?

I'd say that static typing isn't only about what types variables have, but also what types expressions have.
— ricky_clarkson (2009-05-20 12:15:02)

Comment on 'A Taste of Concurrency'

2009-05-20T07:14:53-07:00

A Taste of Concurrency

Typo last sentence: as we will see in ...
— jasonh (2009-05-20 07:14:53)

Comment on 'A Taste of Scala'

2009-05-20T06:49:03-07:00

A Taste of Scala

The -cp . option adds the current directory to the search “class path”. You should get the following output.

Typo above. Should read ... adds the current directory...
— jasonh (2009-05-20 06:49:03)

Comment on 'A Taste of Scala'

2009-05-20T01:08:38-07:00

A Taste of Scala

You can also use this short-hand syntax in some more complex function literals, as we will see in Chapter 3, Rounding Out the Essentials.

The chapter reference is missing here (mentioning it in case you have missed it).
— Leonidas (2009-05-20 01:08:38)

Comment on 'Why Scala?'

2009-05-20T01:00:51-07:00

Why Scala?

It might appear that OOP and FP are incompatible. In fact, a design philosophy of Scala is that OOP and FP are more synergistic than opposed. The features of one approach can enhance the other.

You could elaborate about the OOP bits a litte bit more, since it is most likely the thing that Scala beginners coming from most other languages are most familiar with. You could for example say that there are no primitive types which makes the OOP types integrate better into the code freeing the programmer from bothering with this (or just say "everything is an object" which is more relevant to OOP than FP).
— Leonidas (2009-05-20 01:00:51)

Comment on 'Why Scala?'

2009-05-20T00:54:36-07:00

Why Scala?

I'd say that not only Ruby has become more popular, but also Python and Clojure, another new popular language for the JVM.
— Leonidas (2009-05-20 00:54:36)

Comment on 'A Taste of Scala'

2009-05-19T19:45:44-07:00

A Taste of Scala

It's not clear at all how the example code could possibly not be thread-safe in Scala or any other language since state has not even been introduced yet.

I think the point you are trying to make is that it is a little bit tricky to implement the Singleton pattern in Java without introducing subtle concurrency problems, while in Scala you can just use an 'object' as a singleton without such concerns.

— brl (2009-05-19 19:45:44)

Comment on 'Why Scala?'

2009-05-19T18:38:12-07:00

Why Scala?

It seems a little bit strange to describe garbage collection as 'discarding more troublesome techniques such as manual memory management'. Maybe you could name garbage collection directly as one of the useful ideas that Java adopted.
— brl (2009-05-19 18:38:12)