Programming in Scala Quotes

“As of Scala 3, the indentation-based style, called "quiet syntax," is recommended over the curly brace style.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“difference from Java is that you can optionally leave off the curly braces on a block, even if it has more than one statement, so long as you indent each line appropriately.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Note that in Scala, unlike in Java, you need not put the boolean expression for a while or an if in parentheses.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Note that Java's ++i and i++ don't work in Scala.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Scala's innovations come primarily from how its constructs are put together.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Furthermore, compilers and integrated development environments (IDEs) can make use of type annotations to provide better context help.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Likewise, unit testing cannot replace static typing.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“The argument goes that since such type systems can only detect simple errors, whereas unit tests provide more extensive coverage, why bother with static types at all?”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“the classical benefits of static type systems can be better appreciated. Among the most important of these benefits are verifiable properties of program abstractions, safe refactorings, and better documentation.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Alan Kay, the inventor of the Smalltalk language, once remarked: "I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“The functional programming style also eliminates aliasing problems encountered in imperative programming. Aliasing happens when multiple variables refer to the same object. It gives rise to some thorny questions and complications. For instance, does changing a field r.x also affect s.x?”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“The functional programming style also eliminates aliasing problems encountered in imperative programming. Aliasing happens when multiple variables refer to the same object.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“The functional programming style also eliminates aliasing problems encountered in imperative programming.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Methods like replace are called referentially transparent, which means that for any given input the method call could be replaced by its result without affecting the program's semantics”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Another way of stating this second idea of functional programming is that methods should not have any side effects.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“The second main idea of functional programming is that the operations of a program should map input values to output values rather than change data in place.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“Functional programming is guided by two main ideas. The first idea is that functions are first-class values. In a functional language, a function is a value of the same status as, say, an integer or a string. You can pass functions as arguments to other functions, return them as results from functions, or store them in variables. You can also define a function inside another function, just as you can define an integer value inside a function. And you can define functions without giving them a name, sprinkling your code with function literals as easily as you might write integer literals like 42.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“The great idea of object-oriented programming is to make these containers fully general, so that they can contain operations as well as data, and that they are themselves values that can be stored in other containers, or passed as parameters to operations. Such containers are called objects.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“It runs on the standard Java and JavaScript platforms”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“the language specification tries for precision at the expense of readability.”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“implicits were seen by many as the unique and powerful feature of Scala that essentially no other language had,”
― Martin Odersky, Programming in Scala Fifth Edition: Updated for Scala 3.0

“A method that is executed only for its side effects is known as a procedure.”
― Martin Odersky, Programming in Scala: A Comprehensive Step-by-Step Guide

“that works”
― Martin Odersky, Programming in Scala

“allCategories, but since they can use an arbitrary definition, the methods”
― Martin Odersky, Programming in Scala

“The one exception to the precedence rule, alluded to above, concerns assignment operators, which end in an equals character. If an operator ends in an equals character (=), and the operator is not one of the comparison operators <=, >=, ==, or !=, then the precedence of the operator is the same as that of simple assignment (=).”
― Martin Odersky, Programming in Scala

“The << method starts with the character <, which appears lower in Table 5.3 than the character +, which is the first and only character of the + method. Thus << will have lower precedence than +, and the expression will be evaluated by first invoking the + method, then the << method, as in 2 << (2 + 2). 2 + 2 is 4, by our math, and 2 << 4 yields 32.”
― Martin Odersky, Programming in Scala

“works. Scala decides precedence based on the first character of the methods used in operator notation (there's one exception to this rule, which will be discussed below). If the method name starts with a *, for example, it will have a higher precedence than a method that starts with a +. Thus 2 + 2 * 7 will be evaluated as 2 + (2 * 7), and a +++ b *** c (in which a, b, and c are variables, and +++ and *** are methods) will be evaluated a +++ (b *** c), because the *** method has a higher precedence than the +++ method.”
― Martin Odersky, Programming in Scala

“Postfix operators are methods that take no arguments, when they are invoked without a dot or parentheses. In Scala, you can leave off empty parentheses on method calls. The convention is that you include parentheses if the method has side effects, such as println(), but you can leave them off if the method has no side effects, such as toLowerCase invoked on a String:”
― Martin Odersky, Programming in Scala

“Inheriting from Application is shorter than writing an explicit main method, but it also has some shortcomings. First, you can't use this trait if you need to access command-line arguments, because the args array isn't available. For example, because the Summer application uses command-line arguments, it must be written with an explicit main method, as shown in Listing 4.3. Second, because of some restrictions in the JVM threading model, you need an explicit main method if your program is multi-threaded. Finally, some implementations of the JVM do not optimize the initialization code of an object which is executed by the Application trait. So you should inherit from Application only when your program is relatively simple and single-threaded.”
― Martin Odersky, Programming in Scala

“When a singleton object shares the same name with a class, it is called that class's companion object. You must define both the class and its companion object in the same source file. The class is called the companion class of the singleton object. A class and its companion object can access each other's private members.”
― Martin Odersky, Programming in Scala