Here is my stream of consciences as I take notes and share thoughts on the Scala book.
Scala book redux
Reading through the book Programming in Scala: A Comprehensive Step by Step Guide, but this time I am actually using Scala in my day job so I think it will be more meaningful. Also I have written two of my own Python envy, Scala envy, Groovy envy, functional programming libs in Java with tons of other utilities (one I threw away, it was horrible, and the other one is Boon). Also now I have some experience with Java 8 lambda expressions and functional programming, and some experience with Python functional programming so I feel like the book makes more sense then it did when I attempted a few goes at it before.
Java vs. Scala
The Scala book which predates Java 8 uses a name exists example and shows a forloop vs. Scala exists.
Clearly Scala still wins. Scala is easier to read and smaller. But the difference is smaller if you choose Java 8. (Or a library like Boon where this type of operation would be a one liner in Java as well.)
Scala's big win here (in this small example) is mainly due to its implicit typing, andString.chars returning an IntStream instead of a ChararacterStream. Java would lose less bad with a more complete lib for handling Strings.
For instance, 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." We hope to convince you in this book that Scala's type system is far from being a "complete pain." -- Odersky, Martin; Spoon, Lex; Venners, Bill (2010-12-13). Programming in Scala: A Comprehensive Step-by-Step Guide (Kindle Locations 536-538). Artima Press. Kindle Edition.
I find that larger systems always need strong typing which could be less of an issues with Microservices. Perhaps. But I find when I wrote code in Groovy that I use types. When I write code in Python, I add type information to the here docs and to the comments so I often wonder if I always feel the need to add type information (from being burned a lot on larger Python projects) then why not have types in the system. If you are going to have types in the system, then why not make the implicit like Scala (and others).
I agree with the Scala approach.
This book is older so again it misrepresents Java by not including implicit typing added in Java 7 and present in Java 8. This book did come out after Java 7.
Clearly, it should be enough to say just once that x is a HashMap with Ints as keys and Strings as values; there's no need to repeat the same phrase twice. --Odersky, Martin; Spoon, Lex; Venners, Bill (2010-12-13). Programming in Scala: A Comprehensive Step-by-Step Guide (Kindle Locations 564-567). Artima Press. Kindle Edition.
finalMap<Integer, String> x =newHashMap<>();
Note that I prefer the Scala syntax here. This has been adopted by the two other Java programming langauges that adopted Scala's implicted typing. Implicted and strong typing will be Scala's legacy. It is terse, yet unlike Dynamic typing, exact.
What I don't like about Scala is this:
Scala operators instead of methods
x += (1->"foo")
Java methods instead of operators
finalMap<Integer, String> x =newHashMap<>();
At least I don't like it yet. Strangely I feel that Python's operators for Maps make sense as do Groovy's. But Scala's look weird. There is so much prior art dealing with associative arrays, dictionaries and hash maps, that this seems to be an odd choice at best. Also, I am not a fan of using operators when a method will do. I saw this in C++ and in Python. It tends to make code very hard to read, unless you are working with a real well known lib. I feel this has so much potential for abuse and leads to undreadable code. This goes against my instincts to comment and carefuly think about method names. I would likely use the standard built-in libs operators (no choice for many things), but shy away from using this feature (mis-feature).
I also wonder why Scala supports non-implict types. You can specify the type.
valy:Map[Int, String] =newHashMap[Int, String]()
One wonders what dark corners of the langauge exist where you would want to use an explicit type when an implicit one seems to work so well. My guess would be interface design. We will see. Still on chapter 1.
I did write my first real world microservice in Scala. But I have to admit. There are things that I wrote to make the compiler happy that I do not fully understand which is why I am reading the book (other times I more skimmed it). I can't stand using a language the wrong way. Unless I do it for a good reason (performance).
At the surface level, Scala adopts ... syntax from Java and C#, which in turn borrowed ... from C and C++. Expressions, statements, and blocks are mostly as in Java, as is the syntax of classes, packages and imports. (What did it borrow from C#?) (Basic type system from Java, libs, execution model.) ... (Its) uniform object model (is from) Smalltalk (mention of Ruby to make Ruby guys happy I suppose). Its Universal nesting ...(is from) in Algol, Simula (Beta and gbeta). Its uniform access principle for method invocation and field selection... from Eiffel. Its ... functional programming is ... similar... to ML family of languages (SML, OCaml, and F#)... Many higher-order functions in Scala's standard library are also present in ML or Haskell. --Odersky, Martin; Spoon, Lex; Venners, Bill (2010-12-13). Programming in Scala: A Comprehensive Step-by-Step Guide (Kindle Locations 577-585). Artima Press. Kindle Edition.
I can see why so many CS majors love Scala. It incorporates many of their favorite langauges that they are forced to learn in school which are not used in the industry very much at all. Lookup all of those languages other than C#, Java and Ruby on the Tiobe index, and they are not very popular. What no mention of Icon? You are missing out on the Tucson AZ market. (Scala is 27th on the list with .7 percent. Groovy is at .5 percent. Scala is the only "cool" langauge that makes it in the top 50. I imagine Scala is going to keep climbing due to Apache Spark.
defmax (x : Int, y : Int):Int=if (x > y) x else y
valabc= max(1, 2)
Those are roughly equivalent at this point. I prefer the return type after the parameter list. This makes reading/finding the method name easier. (Point goes to Scala).
The Scala version can be simplified further as Scala can infer the type. The book does not mention this (older book, or covered later).
defmax (x : Int, y : Int) =if (x > y) x else y
I am very used to the C/C++/Java terenary operator so its use does not bother me. I can see how the Scala if/else would be more appealing to Python and Ruby developers.
Performance wise: The Java version is using primitives not objects so unless Scala does some magic in a tight loop the Java version is going to be much better with a lot less GC pressure. This will not concern Python and Ruby devs. It concerns me. I do write things that at times need a bit of punch when it comes to performance (parsers, event system, queue systems, etc.). If I did adopt Scala, I would still use Java for core things that needed performance.
Book just covered how the return type was optional. :)
While loops says the book are not the preferred style. I had to use a while loop once. I was moving Java code to Scala. Good to know that there is a better way.
They just covered imperative while loop style vs. foreach. There are times in Java when I get the underlying array and I iterate using a for / loop. I do it when I know something is going to iterate in one or more loops. The difference when you are working with millions of users per node can be pretty large. I can see where I would write some features in Java to avoid the extra GC just like where I would avoid iterators and streams in Java 8 in certain places. It is good there is a Java escape valve in Scala. You won't need it often, but when you do. :)