The first problem with this is it leads to insanity. Remember those arguments developers had about style before we adopted auto-formatting? Those arguments will happen about what is and what isn't a distinct type.
But the main problem for me is the cost is too high for such little benefit. Understanding and maintaining a type system like that is hard. You are not going to eliminate all bugs. Wouldn't the effort be better spent on writing more tests? I feel like developers prefer creating more types over writing more tests because it's easier, though.
Some of these problems have good, practical solutions already:
> Good luck figuring all of that out from the following signature: > CompletionStage<String> x(String s, int i);
I agree, but you could just use good naming: `fetchAddress(postcode, housenumber)`
> functions with two or more arguments of the same type
Use keyword arguments, ie. `kwargs` in Python or pass an object in JS.
> UUIDs as method argument, a customer uuid is not the same as an order uuid.
This contradicts the Universal part of UUID. If they're not the same then why use UUID at all?
> using a List instead of a NonEmptyList when at least one element is expected.
I'm not sure why this is a problem. An empty list is a perfectly valid list. It strikes me that what you really wanted to pass was an object, not a list.
It's not that types are "easier", it's that they give you things that tests either can't provide or don't provide without serious discipline (often lacking in general, but even when present it's easy to let things slip through).
The thing to aim for is both. Since, short of dependently typed languages, it's practically impossible to encode everything into the type system, tests will remain. But types allow you to express things that become tedious in tests and get the same at least as many guarantees as a comprehensively tested code base but without the same dependency on discipline, which doesn't scale.
> This contradicts the Universal part of UUID. If they're not the same then why use UUID at all?
UUID = Universally Unique Identifier. Not "Universal", "Universally". That extra bit is important, it's qualifying the "Unique" part and not the "Identifier" part. But, importantly in the context of the article, UUIDs could refer to different "types" of things (users, inventory items, addresses, transactions, etc.). By adding a shallow (in this case) wrapper around it it prevents trying to do something like receive a User ID (as a UUID) and trying to find it in the inventory database (using the same UUID value).
But rest assured, the rest of the bugs are still around so you still need tests. Just not those.
I've worked like this for years now and there's just no turning back.
Do you know how many "null checks" and similar sanity checks are in my code? Close to zero. Do you know why? Do you think I'm a moron or because _those_ things are _actually_ impossible that way.
But rest assured, etc.
It simply cuts down on the amount of certainty that has to be incessantly (re)verified and tested.
Also: when you sit down to model your whole domain in this manner, do you know what you discover? All the things that would be anyway - just further down the line.
"Oh, we don't always have a contract number in these scenarios so _that_ case will have to have a constructor. Oh - that means that this purchase function has to stop "lying" about being able to process any invoice becauase some of them won't have a contract number. Shucks!"
How do you solve that? 4 000 lines of tests and 20 lines of assert hasContractNumber.
I'm not sure why this is a problem. An empty list is a perfectly valid list. It strikes me that what you really wanted to pass was an object, not a list. ------- Not in every domain. For example - common pattern in FP is to return an Either[NonEmptyList[Error], SomeResult] when parsing. You can clearly see why the list of errors should never be empty
This effectively locks you into writing pure code (you can extend the linter to cover other things like not using `Future` or not using Java libs outside of `MonadError` from cats[4]). The linters operate on typed ASTs at compile time, and have plugins for the most popular scala build tools. Coupled with `-XFatalWarnings', you can guarantee that nothing unexpected happens unless you explicitly pop the escape hatch, for the most part.
You can still bring in external libraries that haven't been compiled with these safties in place, so you aren't completely safe, but if you use ZIO[5]/Typelevel[6] libraries you can be reasonably assured of referentially transparent code in practice.
There are three schools of thought, roughly, in the scala community towards the depth of using the type system and linters to provide guarantees and capabilities, currently:
1) Don't attempt to do this, it makes the barrier to entry to high for Scala juniors. I don't understand this argument - you want to allow runtime footguns you could easily prevent at compile time because the verifiable techniques take time to learn? Why did you even choose to use a typesafe language and pay the compilation time penalty that comes with it?
2) Abstract everything to the smallest possible dependency interface, including effects (code to an effect runtime, F[_] that implements the methods your code needs to run - if you handle errors, F implements MonadError, if you output do concurrent things, F implements Concurrent, etc.) and you extend the effect with your own services using tagless final or free.
3) You still use effect wrappers, but you bind the whole project always to use a concrete effect type, avoiding event abstraction, thus making it easier to code, and limiting footguns to a very particular subset (mainly threadpool providers and unsafeRun or equivalent being called eagerly in the internals of applications).
My opinion is that smallest interface with effect guarantees (#2) is best for very large, long maintenance window apps where thechoice of effect runtime might change(app), or is out of the devs' control (lib); and #3 is best for small apps.
TL/DR; You can go a really, really long way to guaranteeing effects don't run in user code in scala. Not all the way like Haskell, but far enough that it's painful to code without conforming to referential transparency.
1. https://github.com/scalacenter/scalafix
2. https://github.com/scalaz/scalazzi
3. http://www.wartremover.org/
