I have moved this blog elsewhere. It is the same Developer's Experience
but now powered by Ghost and self-hosted. See you there!
This blog will stay here but no longer updated.
I have moved this blog elsewhere. It is the same Developer's Experience
but now powered by Ghost and self-hosted. See you there!
This blog will stay here but no longer updated.
Many languages support union types, and it is high time Scala did. Union types are coming in upcoming version of Scala – Dotty. Union types (|
) are already being compared with Either
and Option
(disjoint unions).
In some ways, Either
and Option
may be expressed as union types.
// Option[String]
String | null
// Either[Int, String]
Int | String
Similar to disjoint union types, you can pattern match over Union types. However, the differences outshine the similarities.
Disjoint union types like Either
and Option
…
Left
and Right
, Some
and None
. There is only one Left
or Some
.Either[L, R]
, Option[T]
On the other hand, Union Types (|
) …
Not parameterized. Types are specific.
The types involved don’t have to be necessarily unique.
String | Int | String | Int
The above definition is valid although the universe of types is just String
and Int
.
Language syntax
There is one difference that stands out to me, in fact of disjoint union types. Either
and Option
are monads and so they give the niceties of map
, flatMap
and all those of a container. Can’t do that with Union types.
Update: Per phazer99‘s reddit comment, union types could be augmented with extension methods to get the
map
andflatMap
. That’s interesting although I feel it does not make it truly monadic. For instance, what is the unit value? Will the monad laws hold good? Happy to stand corrected.
However, Union types give you edge over one thing. In fact, the thing I don’t like about Either
or Option
; or JVM in general. Disjoint union types are allocated on the heap; every instance. Union types are compile time construct and do not require extra allocation.
As you can see, grass is greener on either side. Both disjoint union and Union types have their place and are here to stay. You gotta choose the right one for the job; Either
disjoint types |
Union Types!
Option
.get
at all costs. Forget there is even a .get
function on Option
. There is always an alternative to .get
. Same applies to .head
Option
in a test class1, prefer extending your test class from OptionValues
. Then you can use .value
on an Option
, which fails with a relatively better error message if the value is not defined.Option
maybe viewed as a sequence (of zero or one element). This is for convenience when working with Option
, which is why see a .head
on an Option
.It is common to see mocks being setup this way in unit tests.
scenario("Test Case 1") { ... when(addressResolutionService.resolve(...)).thenReturn(...) when(vendorInventoryService.checkInventory(...)).thenReturn(...) ... .... another bunch of when and then returns when(shipmentService.schedule(...)).thenReturn(...) ...thisIsTheActualCalltoTest(...) verify(vendorInventoryService, 1).checkInventory(...) ... other such verifications } scenario("Test Case 2") { ... when(addressResolutionService.resolve(...)).thenReturn(...) when(vendorInventoryService.checkInventory(...)).thenReturn(...) ... .... another bunch of when and then returns ...give or take one or more mocks compared to the previous test ... when(shipmentService.schedule(...)).thenReturn(...) ...thisIsTheActualCalltoTest(...) verify(vendorInventoryService, 1).checkInventory(...) ... other such verifications } ... other such test cases
A while ago, I wrote about online regex tools. Cyril (@CyrilBois) came across that post and mentioned about his regex tester tool.
I think every tool should have a name; not one that just goes by its function but a nickname, if you will. So, I am going to name Cyril’s regex tool – Cyrilex
. Don’t like it, don’t worry about it.
Instead of adding Cyrilex
to the list, which I have already, I took the liberty to sort of review the tool. Because it has got a few cool things that I love.
Sometimes you learn the best from others; by watching. This post is based on such an instance. A fellow engineer on my team was investigating a nagging issue – partially-successful operations or rather operations that left data in an inconsistent state. It goes without saying that I take no credit for the time and effort spent on the investigation nor for the fix. I am just the messenger. And as a responsible programmer 🤓, I am sharing it with the rest of the world.
We use Scala in my team and have been trying to be (pure) functional (as much). Hmmm … trying to be functional? Yeah, because the truth is not always black and white.
If you haven’t found a use for this script that uninstalls the second largest junk in the world next to Mac/iOS updates, you are either lazy or scared of breaking things. I am neither, so I polished this script from the different versions you will find on the internet. Oh, I am talking about node/npm.
Happy cleaning!
In the early years, software applications were tiny, compared to what we build today. In any given application, one could say, there were only a handful of error scenarios to deal with. Besides, error reporting, if not error handling, lacked finesse. Just slap the user with something red enough, and just say An error occurred.
Enough! JavaScript had us in its grip for long with its foot guns. The first time I heard the term Hoisting, I had no idea about it and misheard as hosting. You declare variables using var happily, and you have to come to peace with yourself that it is okay to hoist the var
s (lift’em all to the top-most scope). I can’t believe JS convinced the rest of us that it was okay. Then came ES6 and saved us. let
fixed the scoping. const
provided immutability. At least now, you can say JavaScript supports functional programming.
JavaScript got feathers on its hat –
let
andconst
.
Immutability, the cornerstone of functional programming, has many facets.
Not every (mainstream) language supports all the facets; at least not per what each facet stands for. That’s what I will talk about today. The various facets of immutability from a theoretical perspective, and briefly show how some of the mainstream languages have adopted and support these facets in their own way.