scala

Debate about making Scala classes final by default alvin March 21, 2019 - 12:59pm

contributors.scala-lang.org has become my favorite website this past week. It’s very interesting to read through the debates about new language features for Scala 3 (Dotty). For instance, in the Make concrete classes final by default discussion I think everyone agrees they wish they had gone that way with Scala 2, but it would cause too many problems if they tried to make this a new standard in Scala 3. The discussion — in addition to reading Effective Java — makes me wish I had used final before all of my classes.

In another discussion titled, Why does Scala need its own build tool (SBT), someone makes a claim that Martin Odersky and his team created SBT as a build tool solution, and Mr. Odersky replies, “Definitely not my answer. I was always very skeptical of SBT’s approach and remain so.”

Bloop’s compiler performance is ~29% faster than SBT (on at least one project) alvin March 20, 2019 - 8:42pm

I had read that Bloop was faster than Scala compiler tools like scalac and fsc, so I wondered if it was faster than SBT, and if so, how much faster. So I downloaded Eric Torreborre’s specs2 source code, which has 880 source code files, and compiled the entire project with both SBT and Bloop.

SBT performance

To test SBT’s speed, I ran all the commands from inside the SBT command prompt, which I usually do anyway to avoid the SBT/JVM startup lag time. I also ran clean and compile several times before recording SBT’s speed, because I thought that would be a better reflection of real-world usage and performance. I ran the tests four times, and the average time with SBT was 49 seconds, and that was very consistent, always coming in between 48 and 50 seconds.

Bloop performance

The Ammonite REPL logs number of times it starts and commands are run alvin March 16, 2019 - 1:10pm

I love, love, love the work Li Haoyi has done in the Scala community; he’s using the heck out of Scala to create some great tools.

Triplequote: A Guide to Amazon EC2 instance types alvin March 10, 2019 - 11:27am

The people at Triplequote looked at the performance of Scala compilers on different Amazon EC2 instance types in an effort to answer the question, “What is the (cloud) cost per build?”

Futureboard, a Flipboard-like Scala Futures demo alvin March 8, 2019 - 9:46am

I’ll write more about this shortly, but yesterday I created a little video of a demo application I call Futureboard. It’s a Scala/Swing application, but it works like Flipboard in that it updates a number of panels — in this case Java JInternalFrames — simultaneously every time you ask it to update.

The “update” process works by creating Scala futures, one for each internal frame. When you select File>Update, a Future is created for each news source, and then simultaneous calls are made to each news source, and their frames are updated when the data returns. (Remember that Futures are good for one-shot, “handle this relatively slow and potentially long-running computation, and call me back with a result when you’re done” uses.)

Here’s the two-minute demo video:

“Hello, Scala” on sale for $10 (paperback) alvin March 5, 2019 - 8:16pm

March 5, 2019: For a limited time only, I put the paperback version of “Hello, Scala” on sale for $10 (US) on Amazon.

P.S. - It won’t get any cheaper than this.

Java: How to get the name of the current thread alvin March 2, 2019 - 11:04am

When you’re working with multi-threaded programming in Java — such as when working with Thread, Runnable, SwingUtilities.invokeLater, Akka, futures, or Observable in RxJava — you may need to get the name of the current thread as a way to debug your code. Here’s how you get the name of the current thread in Java:

Scala: How to use higher-order functions with Option (instead of match expressions) alvin February 26, 2019 - 9:34am
Table of Contents1 - Sample data2 - From match expressions to higher-order functions3 - Notes4 - Resources5 - Comments

I originally wrote a long introduction to this article about Scala Options, but I decided to keep that introduction for a future second article in this series. For this article I’ll just say:

  • idiomatic Scala code involves never using null values
  • because you never use nulls, it’s important for you to become an expert at using Option, Some, and None
  • initially you may want to use match expressions to handle Option values
  • as you become more proficient with Scala and Options, you’ll find that match expressions tend to be verbose
  • becoming proficient with higher-order functions (HOFs) like map, filter, fold, and many others are the cure for that verbosity