TL;DR – Scala lets you expose internal data, then later change underpinnings while maintaining the same interface. The functional Way is an open Way. Internal data is available to anyone who wishes to extract it. “But what about encapsulation??” – horrified OO programmer“We do not fear your code, for you cannot screw up our immutable … Read moreData Exposure and Encapsulation
Applicative functor: you wrap some food in a tortilla, you wrap the microwave in a tortilla, and you get hot food in a tortilla!— Jessica Kerr (@jessitron) September 10, 2013 But why would you do that?? Say you have a collection of document IDs and you are going to retrievethe documents from the database. Not … Read moreA realistic use case for applicative functors
TL;DR – use def all the time, and things just work. Remember that old adage from Java, “Never call a nonfinal method in your constructor”?Yeah, that still applies in Scala, and it keeps biting me. It’s easier to get wrong in Scala. Here’s a refresher:When a class is instantiated, the superclass is initialized first. Its … Read moreDef and Val in Scala constructors
Your home and your bank account: one of these is an asset, and one is money. Enter the real estate market, and they become interchangeable, with substantial effort. Matter and energy: they’re the same at some level. If it were easy to go back and forth, we’d all move around at the speed of light. … Read moreProgram relativity: F = d*c^2
When code doesn’t behave the same way every time, it’s tough to unit test it. Sometimes we want a random element in the code. For instance, maybe we want an error report now and then when a certain problem occurs, but every time would be too much. How can we test that something occurs 10% … Read moreA trick for deterministic testing of random behavior
I postulate that comments are a code smell. Craig Buchek suggests a possible counterexample: # Let this raise its exception if the fields don’t exist as expected.user = c.get_setting(‘username’) How else could one express the intention here, he asks? I say, the output of a function should be expressed in its return value. Exceptions are … Read moreWhat’s dirtier than comments? Exceptions!
Writing tests first forces you to think about the problem you’re solving. Writing property-based tests forces you to think way harder.— Jessica Kerr (@jessitron) April 25, 2013 What is this property-based thing? Property-based tests make statements about the output of your code based on the input, and these statements are verified for many different possible … Read moreProperty-based testing: what is it?
TL;DR: before it’s initialized. Do vals in Scala always contain the same value?Not quite. I hit this the other day when I used a val inside a def inside a val. In the superclass: abstract class GeneralTestCase { def createArray = Array(1,2,3,4) val defaultInput = createArray // defaultInput = [1,2,3,4] } and then in the subclass, customized behavior to make … Read moreScala: when is a val not a val?
TL;DR – trait T[A } In a Scala trait, how can one refer to “The type that is implementing this trait”? (to the tune of Jingle Bells) [1] Swishing to and fro, amoebas like to play In a petri dish, dividing once a day I thought that there were two, nothing less or more But … Read moreScala: talking about yourself
Functional style makes code more maintainable. How? One way makes processing into a flow of data with discrete steps. Another way separates flow from context, making the context swappable. This post illustrates both. We’ll go from an imperative style to a more and more functional style. Scala is a good language for this illustration, since … Read moreFrom imperative to data flow to functional style