DEV Community: O.F.K.

The death of a QA profession

O.F.K. — Thu, 18 Dec 2025 21:26:37 +0000

If you've been looking for a job as a QA or even automation developer in the last few months, you probably know it yourself: there are two professions that seem to have all but vanished completely from job boards: junior software developers, and quality professionals, both manual and automation developers, of all seniority levels.

(You want to nit-pick? Fine... Three professions. You are right, manual QA testers are not the same as automation developers, as much as FE software developers are the same as BE developers. I stand corrected).

The root cause of this Houdini act, and we quality professionals always seek the root, as you can imagine, is the same: the meteoric rise in LLMs capabilities (no way I'm calling that "intelligence", artificial or not).

I mean, historically companies always skimped on quality: "Let the developers test one another's code, it'll be fine"... until, "displeased" customers, let's call them that, start threatening taking their money to the competitor unless the product they've paid for started producing the value promised by sales...

(That is, of course, only true for B2B companies. B2C companies have, and I guess will, treat their users as QA testers. Even paying customers!)

But with the ever improving LLMs, even companies that did hire quality professionals,manual and/or automation, do so at reduced rate now.

And, loath as I am to admit it - for valid reasons!

Sure, as a QA professional when I prompt one of those tools for assistance I do better than one of my colleague's go-to prompt of "test this function" - I know how to describe the system under test, what's more likely to cause issue, what to pay extra attention to, you know, being a quality professional.

But I have to admit... it has come to that that the LLM routinely suggests cases I didn't think about, and they're not always obscure, hard-to-recognize, no-SANE-user-would-do-THAT, edge cases.

Sometimes they're mundane and simple, and had slipped my mind as I was grand-standing and coming up with cases for the 1-in-1000000 edges.

(Yeah, my test plans are my art, and like every artist, I like my art to be awe striking!)

And they produce good implementations, too!

Not always perfect, but usually good enough that a senior developer (remember, there're no more juniors to be found) can tweak and fix with very little effort.

To top things off, like any non-human entity, LLMs don't take coffee breaks, don't get the cold, don't rest on Saturdays (or at all for that matter)...

And, costly as these tools are getting to be, the tools manufacturers want to turn a profit after all, they're still ten-fold cheaper than even a junior quality professional, let alone senior one.

I'd ask if that was the optimal move on the account of companies, in the long run.

Discussions about companies refusal to hire junior software developers rage over the internet, with many claiming the short-term savings on manpower today will create a generation of non-senior seniors in 10 years or so: developers who never had the chance to be junior, learn from seniors, make mistakes... and fix them - and yet companies are still cutting back on junior software developers.

With that in mind, and an industry's history-long disdain for software quality, until it starts costing, I'm not optimistic about the future of the quality professional trade as a whole.

What will be the long-term effects of these two trends that have always been there, but exasperated by the rise of LLMs: lack of junior hiring, and lack of quality hiring, on software that already controls every aspect of our lives? Only time will, eventually, tell, but I'm willing to bet my modest savings that nothing good.

Will these trends change? Likely not, at least not any time soon.

With LLMs becoming better and subscriptions costing half the salary of a junior developer, and VCs pressuring companies' executives to turn a profit any way possible, C-levels are finally vindicated: a handful of senior developers can produce quality software (or at least, not as many obvious, show-stopping issues).

Personally, I suppose we all will pay the price sometimes in the future, when poor quality software will cause horrific results, but as the known meme goes: "Yes, we ended all humanity as we knew it... but for one bright moment in time, we created a lot of profit for the shareholders".

2000 just called, it can't believe you're STILL using L33tC0d3!

O.F.K. — Sat, 11 Oct 2025 15:53:41 +0000

The path to hell is paved in good intentions

Just had a technical take-home test for a position I've applied for.

I know of many senior folks who, in better days, maybe even today, who knows, refused taking any sort of assignment as part of their candidacy flow.

None whatsoever.

"I'm a senior with 15+ years of experience", they reasoned, "my abilities are proven by my tenure in the industry".

Personally, I don't think years of tenure are a valid metric of skill, but I always encouraged those folks to stick to their beliefs... it meant folks like myself, a little more modest, a little less vain, had the shot those folks forfeited - a win-win situation. 😁

But today's test has me questioning the industry.

Questioning the industry's ability to gauge candidates correctly, its ability to evolve, ability to admit its mistakes.

The industry's willingness to learn and better itself.

We do, after all, consider ourselves the industry of meritocracy, of disrupt, of change, of the future.

Well, the prevalence of tests like I had to take today make me doubt that.

You see, the test I took consisted entirely of LeetCode (often styled “L337C0d3”, and from now on in this post, LC) programming puzzles.

And puzzles they are.

The thing about LC puzzles, the empirically proven thing, is that they are worse than useless as a measure for a candidate's potential to perform well in the day-to-day production setting of a modern software development/engineering department, in fact producing a noise that pollutes the signal!

How so?

Candidates can train for LC puzzles.

There are literally countless sources dedicated to showing how to tackle these puzzles, all exploiting the fact that LC puzzles all rely on some clever trick that, once recognized, allows for a swift, efficient, solution.

Once a candidate memorized the finite list of trick, learning to recognize each, and also memorized the “trick buster” implementation, all that’s left is to “parrot” the solution and they’re done.

Further, LC puzzles are usually self-contained: one function, one optimal implementation.

There’s no software engineering involved in solving them. No tradeoffs (e.g., he “trick buster” dictates what data structures to use). No ambivalent, dodgy spec document (to the contrary, LC puzzles descriptions are some of the best spec-ed documents I ever saw, right down to specifying the types and sizes of the input arguments, the expected outputs, and the system’s memory/storage/computation constraints).

And, since those are automated systems, scoring a candidate’s solution based on the number of unit tests it passed, public and private, hidden, edge-case, ones - there’s no chance of discussion between candidate and evaluator.

It’s an evaluation by not even LLM, rather a crude pass/fail “bean counter”. The more tests you passed, the better the submitted solution must be.

And the platforms for running those tests?!

"You must have a webcam turned on and facing your screen for the duration of the test - taking your eyes off your own screen is an automatic disqualification”.

“You must have your browser in "Full screen" mode - taking your browser off of full screen mode will result in an automatic disqualification”.

“You can't copy-paste, this functionality has been disabled. Finding a way to circumvent this will result in an automatic disqualification”.

The list of constraints and limitations goes on and on.

Any infringement of those constraints is referred to as “cheating”, and in the end report you are scored, among your professional capabilities, on “honesty”.

Now, maybe it’s me, but I find it degrading and demeaing that I’m even considered a potential cheat, and then given an “attaboy” for not.

I mean… going in to a test, a stressful enough situation as it is, knowing the people administering the test suspect you of cheating, a-priory, and it’s on you to prove them wrong - that is, come to think of it, humiliating!

I also wonder what do the test administrators think they’re actually testing for? What “signal” do they think these tests produce?

Because I'll tell you what they do test: not my coding abilities, not my software engineering skills.

Nope.

What LC puzzles actually test, especially being denied access to Google and LLMs, and under strict time pressure, is my memory.

Period!

Ask any software developer, especially senior ones, to implement a simple, but not trivial, task - they will, every single one of them, turn to the following tools for help, in order:

IntelliSense
LLMs
Software development Q&A sites (you know which one).
Official documentation for the language/framework/technology

Exactly the tools these stupid test platforms deny the candidate - some actually don't have even IntelliSense turned on, a glorified online notepad!

I wish I was joking, but sadly, I'm not.

The more senior you become the less you memorize specific APIs and commands, instead honing your engineering skills: the trade-offs of different data-structures, tighetning a loop by using collection functions instead of imperative constructs, manging state.

Implementation details are exactly that, details - that’s what all the above mentioned tools are for.

I don’t care to remember the exact syntax of a “forEach” function, or maybe it’s called “map” in this particular programming language?

I just know I’d be better off using it then implementing an imperative “for loop” by hand, but without access to my tools of the trade I’m forced to use what my pressure blacked-out brains knows by heart - exactly the sub-optimal, error-prone, hand-rolled, imperative loop!

And by the way... my code did pass all the unit tests!

I mean, sure, I submitted my code “on the buzzer” (each question has a time limit, ‘cause why not pressure the candidate some more?!), and the submitted code is hand-rolled, unmaintainable, imperative, non-idiomatic, sub-optimal performing, using obsolete APIs, that wouldn't pass a real-world’s production-grade code review.

But it did pass all the unit tests, including the private, hidden, ones.

Guess that means I'm a great software developer and engineer.

I'd be expecting your offer, at premium rates, any day now.

My way

"So, mister smarty-pants, if you're soooo smart, how would you have us evaluate candidates?"

Wow, I'm so happy you asked.

A little unexpected, I didn't prepare anything, but let me see what I can come up with on the spot.

Well, to begin with - ditch those stupid LC puzzles and platforms!

I know, they're easy: you select a bunch of questions from the platform’s literally endless supply, the platform's automated judge gives a pass/fail score to each question, crunches all the numbers for you, and displays the top N percent candidates (possibly also factoring speed of completion - ‘cause there’s nothing suspicious about a candidate completing a perfect solution to a puzzle in under 2 minutes from the clock starting to count. Everything’s Kosher).

Easy.

Fast.

Convenient.

Requires you to spend no time whatsoever personally getting to know the candidate.

Wrong!

You want to evaluate a candidate's real software engineering skills - ask them to engineer some software.

I know… what a total 🤯!

Have the candidate implement a small feature you already have running in production for years - no one like doing free work, or even feeling like it!

And I mean small: an optimal solution will have at most 2-3 classes, each with 2-3 methods.

Already you got a signal about how the candidate:

Organizes their code
What naming convention do they use - robust and legible, or the dreaded int i
Did they bother adding tests, and if so, were those test high-quality, or basic, low-hanging fruit

Isn’t this kind of signal already ten-folds better than LC puzzles? Of course it is!

But we’re just getting started!

Let the candidate take their time... no time constraint, no pressure.

You continue interviewing candidates all the time, up to when one has signed the contract.

If a candidate is too lax, taking their time - that's their problem. The opportunity will slip right through their fingers.

Also, let the candidate use whatever tools they feel like.

You put it in the assignment spec: "Use whatever tools you want. For all we care, if you can summon the occult to help you with the task - go right ahead, and don't forget to draw a pentagram on the floor first!"

You'd be surprised what a good chuckle where you least expect it will do to a candidate's morale.

By the way, speaking of "the spec", the assignment's actual text, the one the candidate needs to implement - make it vague on purpose. Omit key details. Leave out acceptance criteria for certain test cases.

You know, like the spec your own PM hands you. Every... single... sprint.

And, know what? You don't have to be super-responsive either, when, if, the candidate comes a-knocking on your email box’s door asking for clarifications - excellent signal if they do, excellent negative signal if they don't.

Is your PM just waiting at your beck and call? No?! What a shocker.

You don’t have to be at the candidate’s either. Just make sure to get back to them eventually.

In essence, you extend the candidate the same respect, and expectations, you will once they sign the contract and come onboard your engineering team.

Once the candidate submitted their work have your LLM of choice review it.

What for, what are the review criteria, you decide - only you know what skills and engineering best practices make your team vibe like the pit crew of a premium F1 championship team.

Of the candidates who passed the LLM verdict, you have a long discussion, regarding their solution.

This is the time to find out if they truly understand the code they submitted, what made them take the design choices, the data structure compromises - the engineering.

Again, I can't tell you how to run such a conversation, but experience taught me that when facing another like-minded engineer, the conversation flows of its own accord.

A jittery conversation, especially if the candidate is senior and has been around the block, is in itself an excellent signal. A negative one, but excellent all the same.

After the round of personal, technical, interviews, the only real hard decision left for you to make is which of the candidates who made a positive impression gets the offer.

Hey, that's why you're getting paid the manager's salary... big bucks for big decisions.

Yes, this flow is time consuming.

It's not easy.

Nor is it convenient.

It will “eat up” into your already tight schedule (another deadline was moved up a week?! Geez!)

It will require you to interact with the candidates, plural, for an extended period of time (in the process, giving you an insight about their personality, not only their coding skills. How’s about that?!)

It’s definitely not fun.

But… you need to ask yourself what are you optimizing for when recruiting - your own momentarily leisure, or your team's future success?

Like I said, big bucks for big decisions.

It's a cultural thang

As I conclude this post I'd like to say to those companies that in 2025, coming on 2026, still use LC puzzles, on restrictive platforms - don't call me, I won't call you.

Yes, economy is in the gutter right now, coming by interview opportunities is harder than winning the PowerBall. Still, that's fine, you do your thing, I’ll do mine.

I'm probably not a good cultural fit for you anyway - I like airing my grievances, not just pretending everything is fine, smiling and waving my hand.

I speak up when I feel I've been wronged, and I don't mince my words either.

I also like working with, and for, smart people, people that appreciate advanced, modern, technology, and know how to take advantage of it.

I don't like dinosaurs, never got the fascination.

And I especially don't like being judged unfairly, by lazy folks too complacent to step up their own game, and put in the work.

We’ve already established I am a technical fit - all my solutions to your LC puzzles passed all unit tests.

But culture is as important - and I don’t like yours!

KTHXBYE

From CAP to GAP?

O.F.K. — Fri, 10 Oct 2025 07:02:04 +0000

Humble beginnings

Testing a piece of existing code is easy. That is, at least, the common wisdom: you know what the code is supposed to do, you craft inputs to trigger certain, deterministic, behaviors in the code, and assert the output for each is as expected. Like I said - easy.

Well, sorta...

Even if we discount hardware issues, e.g., network loss in the middle of multi-GB file downloading, or hard drive on logging server becoming full (and who's idea was it to forgo monitoring on that server?!), one needs to account for edge cases such as invalid user input, which the application should handle gracefully, or worse, seemingly valid input - that might cause some really weird behaviors if left unchecked - I'm looking at you "divide by zero", you sneaky bastard.

So, smart folks, when faced with this, eh, uneasiness, came up with a new, complimentary testing paradigm: property-based testing: you identify the invariant of the piece of code, the underlying behavior, the "what is this code all about, like, deep down", and you let the computer generate inputs, both valid-but-fishy, and outright invalid, to stress that understanding of what the function is really all about.

Easy.

So easy, in fact, that the simple addition function, you know, good ole' + operator, is... let's say, complex.

And do I even dare consider load and stress testing, requiring intimate understanding of the domain, the available resources, and knowing how to analyze the results to make the call if our system has hit a peak, has hit a fail-point, or, ideally, can take even more abuse?

And don't even get me started on "pentesting", i.e., "Penetration testing", the act of actively looking for security breaches in the application and exploiting them to prove they exist!

So, to reiterate, testing a given piece of code is easy, it's what mathematicians call a "solved problem".

After all, we all do it all the time with impeccable implementation and results - it's what we call "unit testing".

Artificial intelligence is no match for human stupidity

Stage enter left, LLMs.

I mean... how do we even QA, test, and verify this new Golem we unleashed upon ourselves?!

But that's a loaded question, isn't it?

If by testing the LLM we mean verifying the code it outputs does what we expect (what a strange goal to have, I know), without non-existing APIs (an affliction I still experience every now and then, especially in less mainstream technologies where training code was, still is, scarce, and the LLM is forced to extrapolate from the rest of its training), that it's idiomatic (for the technology we're using), in a performant and secure way - well, that's back to testing 101, our solved problem.

Easy.

I'll even see my previous claim and raise - I further claim I can, to a great degree of confidence, verify an LLM's response, in natural language, to questions to which the expected response should follow some pattern and structure within a certain context.

In other words, questions whose answer conforms to some formal specification - but said answer may be expressed in natural language, not necessarily in code.

For example: say I'm a network engineer trying to partition my current intranet into subnets, each allowing only certain organizational users, and only certain protocols, and I prompt the LLM for help, identifying the issue ("need to partition the intranet to subnet allowing only given users and protocols") and the inputs (i.e., list of users, protocols, and mapping.)

I now expect the response to include the word "subnets", though I'd also be looking for "groups" or "sets", and in the context of subnets, I expect to, eventually, encounter all the inputs I listed: all the usernames and protocols.

Further, I expect to find some code to actually carry out the network partitioning.

All this should be given in some flow, some context, that is continuous, flows from idea to implementation naturally.

I now claim that if I find all of the above expected text in the LLM's response I can claim with high confidence its response is correct, but missing even one detail from that list immediately disqualifies the response.

A logical Bloom filter.

Yes, obviously, the verifier is an LLM itself, but I posit it needs to be a very simple, nerfed, model, not some beast requiring a cluster of GPUs to run, having been trained on Petabytes of domain-specific data.

The verifier's only job would be to sniff out the expected keywords and validate they are in a semantic structure, context, that makes sense.

Again, not straight forward, but definitely doable using today's technology and current models, and can be run against all domains, generally.

Which brings us to ask how can we verify an LLM's response to open-ended questions, questions whose response is, by definition, not governed by spec?
How do you verify a response that is deliberately fashioned to mimic human thinking and intelligence?

I encourage you to think about this question for a couple of seconds: how do we verify an answer by our human colleagues?

That is, after all, what we're trying to achieve here: an application to verify a human-like response, to any question, in any domain.

Can we do it? Probably not, but why not?

Fundamentally speaking

The reason we can't, and there's no "probably" about it, no one single person can verify all open-ended responses, to any and all domains, is that in order to be able to validate an answer given by someone else, the verifier has to be two things: as intelligent as the one giving the answer, so as to distinguish a valid answer from ear-pleasing mumbo-jumbo, have as much domain expertise as the person providing the answer.

When thinking about a so-called "universal LLM verifier" we'd like to impose two more constraints: the system needs to be generalized enough to be able to validate responses in any domain, and it needs to be automated with no human intervention or interaction.

Tasty, low calories, cheap - pick only two

But that, alas, is not possible!

We've hit the "GAP theorem of LLMs".

Yes, yes, I can hear your "the what now?!" gasps all the way here.

As we all know today, with the advent of distributed systems' engineering, a fundamental limitation of such systems arose: the CAP theorem of distributed system, stating that in such systems there can only ever be two attributes guaranteed by the system's design, out of three possible: Consistency (data is correct across all components of the system at the same time), Atomicity (operations either succeed end-to-end, or, upon failing, leave the system unchanged), and Partition (data can be split across several nodes in the system without degrading system's operation).

Consistency, Atomicity, Partition - choose any two.

Well, in the emergent realm of LLMs we face a similar problem: GAP - Generality (a verifier's ability to verify responses of any domain), Automation (no human intervention/interaction required), and Precision (verifier's decision is correct, to a very high degree of confidence) (yes, I know... "Accuracy". Precision lends the "P" to make the cool acronym. Humor me,constraint why don'tcha?!)

And, much like CAP theorem, so is the GAP theorem not solvable by doing the thing we humans love doing when in dire straits: putting more force into the matter.

Generality isn't solved by adding more nerfed, equivalent, LLM servers. It may cut down the time to reach a consensus whether the text being verified is valid or not, but using more of the same can't, by definition, upgrade the outcome.

Automation can't be solved by putting more servers in play, period. If a domain is deemed so risky that any and all LLM responses must be verified by a human expert in the domain, than it must.

Precision, like generality, can also not be mitigated by adding more servers of the same ability: they all have the same training, none is an expert on the domain in question, none can be an authoritative answer.

Much like CAP theorem is a fundamental limitation on distributed system stemming from current technologies used to implement said systems, so is GAP theorem a fundamental limitation on a "Universal LLM verifying" machine... at least given current LLM technologies.

I'm willing to concede that if, say, you have an Alibaba-like model, running 405B parameters, probably GAP theorem does not apply to your model, it being general and precise by sheer power of computation... so, yeah, I guess with enough additional power we can overcome GAP theorem.

Then again, considering the costs of running even a straight forward question on that model... I doubt even Alibaba is using their monster model for anything but the most pressing, urgent, profit-driving issues.

So, not as general as it may seem at first.

GAP theorem stands tall.

The future's calling

Much like CAP theorem doesn't prevent us from building distributed systems, merely forces us to make compromises in their design, and be honest about it, so will GAP theorem not prevent us from building LLM verifiers... it does mean there can never be a "universal verifier", though, and it forces anyone building such a verifier to make a compromise, and be honest about it, to themselves, and to potential clients!

Some of these future tools will choose to forgo generality - those will be tools used in high-risk domains, highly regulated, high-stakes, lives on the line domains.

Tools will be built trained on domain-specific data, regulated by human domain experts until the model shows an extreme confidence in the domain.

Some will choose to compromise the verifier's precision - being "close enough" will be good enough.

I'm guessing those will be the bulk of these tools. We need to make sure our original LLM's answer is plausible-sounding, we're not in the business of splitting hairs. We need time-to-market, not the rigor of a mathematical proof.

I don't believe any of these tools will forgo automation, though, that would be counter-productive and purpose-defeating.

Well, perhaps some of the high-risks domain mentioned above will be made to give up automation, as well as generality, by regulations. Maybe not.

Whichever way each of these tools will sway, it will not be able to disguise - and that's a win for the entire industry.

Since a universal verifier is unattainable, each of these tools will have to concede which of the three "legs" of GAP it gave up, allowing its users to better evaluate whether that tool is the right tool for their use-case.

Are we there yet?

The realm, and it is a realm, not "just a new technology" by even the slightest chance, of LLMs is in its infancy, and already showing just how vast and grand it will be. And it will.

As with anything new, uncharted, unknown, nothing is really worked-out yet. Nothing is a "solved problem".

Heck, we don't even know what we don't know about this... thing.

It's good, therefore, to at least know its limits. To know they actually exist. That, vast as it is, even this realm does have a line in the sand that can't be crossed.

Maybe it's just me, but I find it reassuring. As a father to a toddler, I know all too well how much limits are something every infant needs to have... even one made up of bits. 😃

The function not dispatched

O.F.K. — Sun, 28 Sep 2025 10:49:07 +0000

Reading the Julia language's documentation, it says that unlike many traditional languages, Julia support multiple dispatching of functions (from here on, MD), as opposed to traditional OOP languages' single dispatch, or even the more modern function overloading (onwards, FO.)

I know what single dispatch is, anyone who ever "dotted into" a method call in an OO language knows what single dispatch is.

I also know what function overloading is (thank you Elixir for that.)

But multiple dispatch?

So I did some digging and now would like to post about it too, adding my own two cents. 😉
I'll start with single dispatch, for completeness sake.

You had one task

As mentioned earlier, if you ever "dotted into" a method call in most dynamic OO languages - congratulations, you executed a single dispatch operation.

What single dispatch simply means is that when a function is called, the compiler knows exactly what implementation of the function to call, because there is only ever one such implementation!

Furthermore, even if there are several similarly named functions across the system, even if all those functions take the same number of arguments and the same types for those same arguments, its arguments' shape - the compiler still knows which unique function to call.

How? Due to the function's first argument - the receiving object, the object we "dot-into".

For example, in Ruby:

[1, 2, 3].reverse # => [3, 2, 1]
"Hi".reverse # => "iH"

It looks like we're calling the same method, reverse, with the same shape, i.e., no argument at all, on both a string and an array instances, yet Ruby's interpreter is able to discern which implementation to use for each.

This is because the receiver, a string in one case, and array in the other, dictates which implementation would be called!

More so, since Ruby allows "monkey patching", we could try to "get creative" and do:

class String
    def reverse
        ""
    end
end

One might now ask, which method is dispatched when "A string".reverse is called, but the answer is that the last implementation (in terms of code hierarchy, not chronological order) wins, so in this case, our patched version is the one that's called and would return the empty string.

There is only ever one possible method implementation for any given method name for a given type!

By "qualifying" the method with its receiver, the instance being invoked, we let the compiler know exclusively which implementation to dispatch.

Most of the popular dynamic OO languages support only single dispatch - JavaScript (TypeScript allows multiple dispatch, but since TS is eventually compiled down to JS, this is risky and error prone in subtle, hard to catch, ways), both Python and Ruby, as does Go.

On the other hand, language such as Java, and C#, for example, support a form of function dispatching where the compiler has to decide which implementation is the correct one - function overloading.

Two methods diverged in a code

Suppose I'm malcontent with the previous languages' inability to let me define just one function, but one that can take several different arguments' shapes, and return different outputs according to the arguments provided.

Put another way, I want to define a "family" of similarly named functions, differing in their arguments' shapes, and outputs.

For example, I want to to define a custom type, i.e., a class, say Sum, with a member method sum that sums its arguments. I also want the function to operate only on the following arguments' shapes are:

Two integers
Two floats
An integer and a float (or vice-versa, a float and an integer)
A single integer
A single float

Generics (AKA "ad-hoc polymorphism") won't do.

A generic function sum<'T>, by definition would allow 'T to be any type: a string, a tuple of an arbitrary shape, a custom type, etc.

There can't be a single implementation that supports all possible inputs.

What I want is actually the diametric opposite of a generic function - I want a specialized function that only allows a very specific enumeration of arguments' shapes, allowing the compiler to give me compile-time type safety guarantees!

You may have also noted that just as I was talking about dynamic languages when talking about single dispatch, with Go being the notable exception, I am now speaking of "compile-time guarantees", since we're talking about function overloading.

That's because you only get FO in compiled languages that support static typing (not necessarily strong though: Elixir, for example, is statically but weakly typed, and supports FO.)

Luckily, in the languages listed above (and many others), we can implement the following (example in Java):

class Sum {
    public int sum(int x, int y) {return (x + y);}

    public double sum(double x, double y) {return (x + y);}

    public double sum(int x, double y) {return ((double) x + y);}

    public double sum(double x, int y) {return (x + (double) y);}

    public int sum(int x) {return x;} // Well... technically, it is

    public double sum(double x) {return x;}
}

// And use it...
class Main {
    public static void main(String args[]) {
        Sum s = new Sum();
        System.out.println(s.sum(1, 2)); // => Prints 3
        System.out.println(s.sum(1.0, 2.0)); // => Prints 3.0
        System.out.println(s.sum(5)); // => Prints 5
        System.out.println(s.sum(7.2)); // Prints 7.2
        // But...
        System.out.println(s.sum(1, 2, 3)); // => Compile-time `IllegalArgumentException` - too many arguments
        System.out.println(s.sum("Hello, ", "world!")); // => Compile-time `IllegalArgumentException` - illegal argument type(s)
    }
}

This method does exactly what we defined earlier:

It sums its arguments
It only accepts arguments of specific shape
- Note how we had to define, and implement, the cases for "integer-and-float" versus "float-and-integer" separately!

The compiler knows which implementation of the function to dispatch not due to its first argument, the receiver, s, since it's the same one for all these functions, but rather by knowing what arguments were provided and dispatching the implementation that takes that arguments' shape.

Now, contrast that with Julia's multiple dispatch:

function sum(x::Int, y::Int)
    x + y
end

function sum(x::Float64, y::Float64)
    x + y
end

function sum(x::Int, y::Float64)
    float(x) + y
end

function sum(x::Float64, y::Int)
    x + float(y)
end

function sum(x::Int)
    x
end

function sum(x::Float64)
    x
end

Are you kidding me?

Yes, I admit, it does kinda seem like I'm making a fool of you.

I mean, other than the expected syntax differences, those implementations are virtually identical, down right to having to define, and implement, a separate case for the int-and-float versus float-and-int shapes.

But you shouldn't be surprised.

After all, conceptually both what FO and MD were developed to do was the same: allow us to develop many finite implementations of the same function, according to its possible inputs.

So, what is the difference?!

The answer, and the root difference, lies in how each of this two features, is implemented, at what part of the code execution, and what are the costs.

Slow and steady wins the race?

As mentioned, FO is only possible in compiled language with static type system.

When the compiler encounters a method for the first time it compiles it and keeps a reference to the compiled form in its functions lookup table.

To that extent, encounter a function for the first time is both the function's name (but not its receiver), and its inputs' shape.

It's allowed for a class to have several implementations of the same method, as long as their inputs differ.

The compiler is dutiful and obedient: it sees a method that's not already on the lookup table - it compiles the method.

Simple.

And costly: as mentioned, there might be the case that a certain implementation is never actually called.

Yet the compiler took the time to compile it, and now holds a reference to it in its memory.

Both time and memory have been effectively wasted!

Even though the compiler is what's referred to as "Ahead of Time" (AOT), meaning, among other things, that it knows all the code at compile-time, and knows whether a method is, or is not, invoked - it doesn't matter.

Everything is compiled.

Fast and loose

With multiple dispatch things are vastly different!

To begin with, MD is only available in interpreted languages, which should make sense as we just mentioned the compiler of compiled languages "assimilates" all code at compile-time.

Since interpreted languages parse the code line-by-line (with the exceptions of flow control structures), nothing is pre-compiled and computed.

When the Julia interpreter encounters a function it checks against its lookup table for a function with the same name and same arguments' shape.

If it isn't found on the table the function is compiled in a manner known as "Just in Time" (JIT), which is exactly what it sounds like: it's compiled just in time for it to be used.

A reference to this compiled instance is then stored on the lookup table, so the next time the same function is encountered the performance would be comparable to an AOT-compiled function call.

And, just to make it abundantly clear: only when the interpreter encounters a new function for the first time, does it compile it. As long as we're only calling functions already met or functions from the core library nothing gets compiled, and all functions calls are O(1), as they're already on the functions lookup table of the interpreter.

They STILL look like the same picture

So, what's the gain? It still sounds like a "to-mato/to-ma-to" argument.

Let me say it again, and if it still doesn't click for you, think it over for a second: in MD languages there no work is done until a function is first encountered: no CPU cycles are used to handle, e.g., tokenize, parse, compile, store a reference, etc., a function that may never even be called, no memory is wasted holding a reference to a function that, from the interpreter's point-of-view, doesn't even exist.

Yes, there is a price to pay on initial encounter of the function: JIT compilation is usually a bit pricier than AOT compilation because a JIT compiler lacks knowledge about the entire code, that AOT compilers have, but that's a rather small price to pay... as can be evident by Julia's performance that routinely matches that of C, though that's also due to Julia's extremely smart design and implementation, employing every performance optimizing trick in the book, on top of MD.

And then again, Julia programs don't have to wait for compilation to finish. Or start, for that matter. They just run... 🤪

Another forte of MD is its built-in propensity for "monkey patching" - extending code we don't have direct control of, e.g., a library:

Assume a library we use exports a given function utilFunc. The function however is defined only for certain arguments's shapes, but we want to use it with our own arguments' shapes.

In languages like C# we'd have to use "extension methods", a hack that was invented exactly for this purpose, and like all workarounds it feels bolted on the language syntax, and is verbose to code.

In Julia we simply add in our own code something alone the lines:

function utilFunc(our::Int, arguments::Float64, list::String)
    # Implementation goes here
end

Et voila. That simple.

We don't need the library's source, in fact the only reason we're naming our function the same as the library's is because they serve the same purpose so it makes sense.

In actuality, and unlike extension methods in C#, our function could've been called whatever name we wanted, and it would work the same. Zero coupling!

Why don't they build the entire airplane from the materials of the black box?

A question comes to mind, "if MD is so good, why aren't all programming languages implementing it? Especially if, as Julia proves, you can have an interpreted, JIT-compiled, dynamic, language, and get C-like performance..."

And the answer is twofold.

First, as mentioned, Julia's performance is not only due to MD. Sure, it helps, but under Julia's hood there is some remarkable software engineering. Julia's maintainers took every page of the "How to make computers faster" book... and then wrote a few more chapters themselves.

Second, safety.

For the small(?) price of AOT compilation and its consequences, statically typed languages offer the developer something an interpreted language simply can't: compile-time type safety!

Really is that simple. Personally, I'm more than willing to pay the "AOT tax" when using my loved F#, knowing the compiler will smack me on the nose anytime I try to do something stupid in my code.

Is it worth it? I think so. Others may disagree. I like my types strong and static.

Fin

That's it.

Not quite two sides of the same coin, they're two ways to implement the same concept in differing environments.

I hope you now have a better understanding of the difference between multiple dispatch and function overloading than when you started reading this post.

Say what you mean

O.F.K. — Sun, 21 Sep 2025 11:25:40 +0000

Use your words

Most programming languages today, barring EsoLangs and the APL family of languages, use English for their APIs.

Some languages' designer, like for Python and Ruby, went to great lengths to make those languages' APIs read like a valid English sentence (more or less.)

The thing with using a spoken language for APIs to be consumed by a computer, is that sometimes the meaning of words in the natural language get hijacked into meaning something not quite the same.

A great example for that is the word 'private'.

In English, the word 'private' means one very particular thing: something that is personal, not to be interacted with by anyone other than its owner. Not quite, but not too far removed from a secret.

What's the point?

Lately, as part of my Elixir-to-F# reimplementation journey, I defined several private types.

In F# when a type is private it requires a public constructor to create instances of, but it also requires a public getter to access its members, so they can be viewed or updated.

All that added boilerplate got me thinking, "is it worth it?!"

When I created the private types, and their public constructors, I had a notion of the word 'private' like that in the English language: the type is a secret, any attempt to create an instance of it must be allowed by the type owner - me.

No team member, and for that matter me, two months in the future, having forgotten the context and implementation details, is such a "team member", can create an instance of the private type without my say so - no instances showing up in places I don't expect them.

But then it struck me: the constructor is public!

Any member can easily just code privateType.create args and have an instance of that type, no permission needed.

Rogue instances can crop up everywhere in my otherwise pristine code!

What's the point?! What did I gain by making the type private?

And more importantly, why is my favorite language lying to me?

"Private" doesn't mean secret, only accessible by whom I trust and allow.

It means something else!

A trusted gatekeeper

So I asked ChatGPT, obviously.

And the answer I got really made sense to me, so I'm sharing it here in my own words and style.

In programming, and that's true for all languages that implement the "private" accessibility control, no matter what it is actually called, that words means something not quite the same as the English meaning.

Close, that's why it was chosen, but not entirely the same.

In programming when you define something as private, and assuming you do want it to be accessible to the other code, you must also provide APIs (e.g., methods, functions, etc.) to create and access that something. Those implementations must be public.

But, how those public APIs look like and behave... that's entirely up to the implementor!

Are you already seeing where I'm going with this? What's the gain?

By controlling the only ways to create and get the private "something", we make sure that whoever is creating and getting is only able to create and get what we want them to!

For example, in one of my private types the age must be a positive integer, greater than 0.

By making the type private and only exposing a public constructor of my doing, I made sure that no team member can just do privateType (age=-10) and create an invalid instance of that type.

Oh, no. The only way to get an instance is doing privateType.create (age=XYZ), and if that XYZ is invalid, e.g., negative integer or zero, the instance will simply not be created.

(What happens then is also the responsibility of the private type - no concern of whomever is trying to instantiate the type!)

Same for getting data from the instance.

No longer can anyone do privateTypeInstance.internalDataNooneShouldHaveAccessTo!

The getter is public, sure, but I, the implementor of it, decide what data is accessible through it.

"Private" in programming means something on the lines of a trusted gatekeeper: it only allows interactions with the data it guards in certain, permissible, ways.

So, the same as the English definition?

Coming to think about it, looking at my own definition of the word "private" in English, I can see the resemblance.

As in English so in programming, "private" denotes something to be kept away from the public, not interacted with by those not permitted.

But unlike English, it doesn't mean a secret, simply something that is fenced off, and only allowed access via the gate, that is being guarded by a trusted guard.

The issue of what's to gain has given me a lot of headaches in the last few days, trying to understand what's to gain by it.

If you had that same question, hope I just cleared it away for you (otherwise, I'm sure ChatGPT can. 🤪)

My hovercraft is full of Rubies

O.F.K. — Thu, 18 Sep 2025 14:13:51 +0000

Ruby, the Python we deserved

My first "real" programming language, if we don't count Matlab and Mathematica (today, Wolfram language) I used in school while majoring chemistry, was Ruby, which is why I guess have I a soft spot for it even today.

I'm also well aware there is no real contest any more between Ruby and Python, the latter having taken over the programming world by storm, while the former is diminishing by the day, sadly.

Yet I still think Ruby is the better dynamic, "scripting", programming language.

The Python we deserved, but not going to get.

Yeah, well, you know, that's just like YOUR opinion, man

Yes, Dude, it is. Not too surprising as this is my blog. 🤪

Of course every opinion here is mine, and only mine. You can agree, or disagree, it's your right.

I just hope whether you're a Pythonista, a Rubyist, or a Gopher (FSM have mercy on your soul), you think about what I'm saying before you'll dismiss me and my writing as nonsense.

Objects all the way down, consistently

The most glaring, not sole, but definitely the poster child of Python's wrong design is the ambiguity between its pronounced "Everything is an object" paradigm, and its implementation, especially with regard to built-in functions.

Take for example the function to get an iterable object's length, of which the most common is an array, or list as it's known in Python (in itself a bad decision: a list in computer science has come to denote a singly-linked list. Python's lists are what other languages call array, and for a good reason: they denote a contiguous memory section.) The Python code is:

myLst = [1, 2, 3, 4, 5]
len(myLst)

This begs the question, "why?!?!"

Especially given that other list methods, e.g., appending, are accessed in the "dot-method" syntax, i.e., myLst.append(10), and are defined on the list class.

In contrast, in Ruby:

myArr = [1, 2, 3, 4, 5]
myArr.length # Can also use `myArr.size`, and even `myArr.count` (without any arguments to the `count` method)

The answer to the question "why?" is somewhat interesting.

In Python everything is indeed an object, lists included, and every object has its own methods.

There are, however, certain generic functions, not methods, that are not defined on any specific class.

Because those functions may be used on many data structures, of differing types, it was decided to group them inside a special dictionary: __builtins__.

When a function is called that is not in any other scope, the Python interpreter looks those functions in that special dictionary, and if it is indeed there, the built-in function being referenced by the key is called.

len() is one such function, and any object that implements the __len__ "magic method", as lists do, can call it (which, for lists, is exactly what the magic method does!)

Ruby, on the other hand, has its roots firmly in the Smalltalk programming language - the original language to coin such term as "class", "object", and "object-oriented"!

A core tenant of Smalltalk was how it defined objects: a data container that can only communicate with its environment via message passing. When an object receives a message it checks against its own finite list of known messages. If the incoming message is on its list, it carries out the corresponding action.

(Smalltalk's messages are not the same as today's methods since they're external to the object, and are more in tune with modern actor frameworks, but the concept is valid.)

It's clear, therefore, that in Ruby, length (or size, or count) are methods on the array object. Also on, for example, the string object too!

Each class that needs its derived objects to return their size implements the appropriate methods, in a way that's correct for it.

There's no one, central, generic, function because that would mean that an array object wouldn't know how to respond to a length method call passed to it!

The difference is less pronounced in, for example, mathematics where addition in both languages is implemented as a method on the corresponding numeric class with the + operator being syntactic sugar over a method call.

For example in Python:

3 + 5 # => (3).__add__(5), the `add` methodn is implemented on the int class

3.0 + 5.0 # => (3.0).__add__(5.0), the `add` method is implemented, seperately, on the float class, too!

And in Ruby:

3 + 5 # => 3.+(5), `+` is the **actual** method name, implemented on the Integer class

3.0 + 5.0 # => 3.0.+(5.0), `+` is the **actual** method name, implemented, seperately, on the Float class, too!

I feel like Ruby's way of implementing object-orientation, rather Smalltalk's way, is better: whenever you "dot into" an object in your IDE you get the full list of what the object is capable of handling. No "magic" functions hidden in a global scope to have to guess.

Truly, "What You See Is What You Get" (WYSIWYG).

"Come up and see me, make me smile"

One of Matz's (Dr. Yukihiro Matsumoto, Ruby's creator) stated goals in inventing Ruby was to "optimized for programmer's happiness", what now days is known as "Developer Experience" (DX).

To that end, Ruby has, from inception, been a language more concerned with convention over anything else: if the community figured out that doing some task is best achieved in a particular way, that way became the norm. Matz never tried enforcing his opinion on the shaping of the language and its use.

More over, even if a certain way did become convention, Ruby almost always offers more ways of getting things done, as can be seen in the previous array length example: there are 3 such ways. Granted, two are simply an alias of each other, while the third is a bastardization of a different method all together, but there are options!

Another, complementary, goal of Ruby was "the principle of least surprise" (AKA "principle of least astonishment"): for a skilled developer in Ruby, there should be no code, no behavior, no quirk, that makes the developer go "huh?!". Once someone becomes acquainted with Ruby, coding in it should feel streamlined because one can reason about the code before even coding in a predictable way!

(Contrast that notion with, say, JavaScript, and nowadays TypeScript too, as can be seen in the now classic WAT video.)

Python's creator, Dr. Guido van Rossum, had another idea about what constitutes developer's happiness, and in Python we have "The Zen of Python" - a set of 19 dictates how Python code should be laid out and coded, that has some very strict ideas.

The Zen of Python was considered such an important part of the language's design that it was made into the 20th official PEP - Python Enchancment Proposal, the official way the community can suggest improvements to the language to van Rossum, who takes a very active charge of his creation's evolution, being its BDFL - benevolent dictator for life.

The Zen of Python is so central to the language that in the Python REPL you can view it by typing import this.

Personally I prefer Ruby's convention-by-community over Python's "there should be one, preferably only one, obvious way of doing things".

Coding is a creative process as much as it is a technical endeavor. Ruby encourages freedom and exploration, Python leans toward strict correctness.

I see what you mean

One complaint anybody who ever coded in Java has about it is how verbose it is.

Well, neither Ruby nor Python are as verbose as Java, thank the FSM, actually feeling more dynamic while being on the JVM was one design goal of the Groovy programming language, but between them there's a clear winner for succinctness.

(Yes, I am well aware of the irony, me talking about succinctness. I like it in my programming languages, not in my own writing. 🤣)

Not so much about LoCs, but rather about readability, a few examples will clarify the subject.

We'll start off with something simple: read in a text file, and print the 3 most frequent words in it.

In Python:

counts = {}
with open("input.txt") as f:
    for word in re.findall(r'\w+', f.read()):
        word = word.lower() # Normalize for sotring and getting from the dictionary
        counts[word] = counts.get(word, 0) + 1
top3 = sorted(counts.items(), key=lambda x: -x[1])[:3]
for word, count in top3:
    print(f"{word}: {count}")

And Ruby:

counts = Hash.new(0)
# Ruby's `File.read` closes the file once out of scope, as does Python's `with`, but that's external to the file opening: `open(fileName)`
File.read("input.txt").scan(/\w+/).each { |w| counts[w.downcase] += 1 } # `w.downcase` is the normalizer as in the Python example`
counts.sort_by { |_, v| -v }[0,3].each { |w, c| puts "#{w}: #{c}" }

By the way, did you catch how in Ruby the last expression is returned by default? No need to remember to call return... or bang your head in frustration, trying to debug the code, figuring out why our function returns None.

Another all too common example: initializing a class constructor with instance variables.

In Python:

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

And Ruby:

class Person
    def initialize(name, age)
        @name = name
        @age = age
    end
end

While one may comment on Ruby's use of def...end, I like its human-readable initialize over the magic method __init__, and the fact that the @ is an instance variable definition, making short change of having to reference self both in the constructor's parameters, and in assigning them values.

And, lastly, one more example: given an array of JSON-like objects, find those who are over 18, and capitalize their name.

In Python:

people = [{"name": "alice", "age": 17}, {"name": "bob", "age": 22}, {"name": "carol", "age": 19}]
adults = []
for p in people:
    if p["age"] > 18:
        adults.append(p["name"].capitalize())
print(adults)

And Ruby:

people = [{name: "alice", age: 17}, {name: "bob", age: 22}, {name: "carol", age: 19}]
adults = people.select { |p| p[:age] > 18 }.map { |p| p[:name].capitalize }
puts adults

Notice also that Ruby supports the notion of symbols as keys in dictionaries, so no need to quote the keys, unlike in JSON, and the keys aren't strings, but symbols which are singletons, making hashing them a touch faster than Python as they're placed in Ruby's symbols table on creation.

Also, visible in the above examples is Ruby's excellent block syntax for anonymous functions: blocks can be chained together to form a compound function, something simply impossible with Python's lambda expressions.

Block can also be written in a line-by-line fashion, for example, for readability:

people.select do |p|
  p[:age] > 18
end

Of course, this format does not compose.

A Functional (Programming) language

Ever since I learned of the Functional Programming paradigm I started detesting the Object-Oriented paradigm (as can be seen by my other post series on transforming code from Elixir, an FP language, to F#, another FP language.)

Aside from such attributes as immutability by default, FP languages have one more trait that makes them a treat to work with, it's in the name: they're functional. They consider functions as first-class citizens, making passing them as arguments to other functions, getting them back as a result, binding them to a value, etc. as easy as it gets.

Now, true, Python does allow some FP even at its core, without 3rd-party libraries, chief example of which is the afore mentioned lambda expressions. But that's pretty much the extent of things. A Python list, for example, doesn't have built-in, core library, facilities to map over its elements, filter them, etc.

Ruby, on the other hand, as we saw before, does. Out-of-the-box.

But Ruby takes it one step further with its Procs, shorthand for procedures: blocks of code, anonymized functions, that can be bound to a variable and passed as arguments to other functions (that can then call on the procedure using the keyword yield):

# First a simple example, directly calling a `Proc`, also showing the `.select` (AKA `.filter`) functionality of arrays
isEven? = Proc.new {|n| n.even?}

evenNums = [1, 2, 3, 4, 5].select(&isEven?)

# More involved: the `Proc` is passed to a **method** (here on the `Global` object as an argument)
def processNums(num)
  nums.each do |n|
    yield n # This calls the `Proc`
  end
end

isEven? = Proc.new {|n| n.even?}

processNums([1, 2, 3, 4], &isEven?) # `Proc` pass explicitly, even though not in function's signature, because function expects it!

# We don't like signatures to "lie". Let's fix that
def processNums(nums, proc)
  numbers.each do |n|
    proc.call(n)
  end
end

isEven? = Proc.new {|n| n.even?}

processNums([1, 2, 3, 4], isEven?)

It was actually in Ruby that I first grasped the power of Functional Programming, even though at the time I didn't know that's what it's called.

Ruby is a very much OO language, as we saw in an earlier section, but it always had, since its beginning, a strong FP streak to it which amplifies the joy of its developers, in line with its design goal.

Eat my dust

And now we should probably talk about performance, and, as much as I don't like admitting it, performance-wise, Python always had, still does, and probably always will have, the upper-hand.

Of course, if hyper-performance is an issue, neither language is a good fit, as they're both interpreted languages that require runtime compilation (i.e., JIT compilation) via their respective virtual machines.

But, assuming a subjectively "reasonable" performance is sufficient, yeah... Python usually beats Ruby by a factor of x2-3.

(I'm referring to the canonical implementations of each: CPython for Python and MRI for Ruby.

Experimental compilers such as PyPy for Python and TruffleRuby for Ruby are cool, but are not mainstream, and in that case, TruffleRuby, running on the GraalVM comes very close to native speeds!)

The way of the world

Ruby just got a bad deal, and its community missed out on opportunities.

Originating in Japan in a time when commercial internet was just budding, and being created by a reserved, soft-spoken Japanese man, in line with his culture and heritage, Ruby was not well positioned to take over the world by storm. It didn't help that for a very long time its official documentation were only in Japanese, either.

Contrast that with Python being developed by a Dutch with no reservations about promoting his creation, in the middle of Europe at a time when a good, succinct, relatively performant alternative to Java, itself an infant back then, not the performance powerhouse it is today, was sought for.

Ruby's community also missed out: after creating Ruby on Rails, which for a time dominated the web framework scene the community rested on its laurels, oblivious to how data science was picking up steam.

Python's community, on the other hand, saw clear and started creating multiple, competing DS libraries, and in the process pushing each library to become better, until the efforts were consolidated into a single DS stack that we know today (e.g., NumPy, Pandas, SciKit-learn, Numba, Matplotlib, PyTorch, and others.)

Python's grasp on the DS community is so strong today that even specialized languages for doing DS like Julia and R are losing the fight to Python, if they ever stood a chance to begin with.

As Python is rising, for DS, for web frameworks, for backend business logic, Ruby is declining.

That's just the way of the world: bad luck, bad timing, and yes, bad decision-making make for the suboptimal alternative taking the lead. We've seen it happening so many times, what's another one?

Personally in my hobby-coding and side projects, I've moved to Functional Programming and never looked back.

But if I was asked to start a new, greenfield, project today and use one of the more orthodox languages, I wouldn't take JS, nor TS, not Go (yeccch!), and no, not Python either.

I'd vote for Ruby knowing it will do the project proud, and give its developers joy.

Death of a lens(man)

O.F.K. — Sun, 14 Sep 2025 10:36:38 +0000

Focusing on the issue

Taking a break from my Elixir-to-F# implementation, I encountered an issue when dealing with some other code I had lying around, that made me think, and admire, how F#'s syntax evolved lately, in response to actual problems folks developing in it had - a real living language, that puts its users' needs front and center.

Imagine an F# domain that has a deeply nested record structure, e.g. record-of-record-of-record..., not too far removed from a JSON of JSONs, for example:

// Indeed, this domain is as contrived as they get, and excessively sub-optimal... a perfect example!
type PersonName = {FirstName: string; LastName: string}
(*
Not related to the post's topic, but `HouseNumber` is a `string`! **Never** use numeric types (e.g., int, float, decimal) to denote quantities that can't be acted upon mathematically, even if they are **represented** as numbers. Numeric types should only be assigned to numeric quantities! A valid exception is `Id`, and even then, in production, prefer using `System.Guid`
*)
type Locale = {Street: string; HouseNumber: string}
type Address = {City: string; Locale: Locale}
type Details = {Name: PersonName; Address: Address}
type Employee = {Id: int; Details: Details}

let sherlockHolmes = {
    Id = 1
    Details = {
        Name = {
            FirstName = "Sherlock"
            LastName = "Holmes"
        }
        Address = {
            City = "London"
            Locale = {
                Street = "Baker"
                HouseNumber = "221B"
            }
        }
    }
}

Now, suppose the good detective decided to rent a more cost-effective apartment on the opposite side of the street, making his new address 222 Baker street.

How would we represent this in our data structure?

Seeing what the problem is

An interesting question to ask is "why is that a problem in the first place? Just update the nested member and be done with it!"... which is a great suggestion, really, no cynicism implied, except that in F# that used to be not exactly straightforward. To put it mildly.

The thing is records in F#, like all F#-native data structures, are immutable.

That means a couple of things:

When "updating" the dear detective, we will not be updating the current memory object that holds the data, instead we'd be creating a new data structure that is a clone of the current one, with any of our updates applied to said new data structure.
There is no way to tell the F# compiler "take this object and update the HouseNumber member, that is three-levels deep nested, leaving the rest of the data intact". This operation, easily done in C# with a single line of code, albeit a long-one, it is three-levels deep, would take us in F# considerable effort.

Eyeing the solution

In the "classic" F# syntax, prior to version 8, and of course, still valid today for the "classist" amongst us, the way to do that would have been:

let sherlockHolmesUpdated = {
    sherlockHolmes with
        Details = {
            sherlockHolmes.Details with
                Address = {
                    sherlockHolmes.Details.Address with
                        Locale = {
                            sherlockHolmes.Details.Address.Locale with
                                HouseNumber = "222"
                        }
                }
        }
}

That is, using F#'s record update method we need to specify all the nested level up to and including the level we want to change. As the change is more deeply nested, the number of time we need to specify the entire chain grows, leading to a very accurate, true, but highly unreadable "pyramid of change", so to speak.

Surely, there is a better way of doing this?

Seeing with pinpoint accuracy

Well, the answer is "yes, of course". But also "not quite, no".

Which is a great time to introduce the subject of optics.

In Functional Programming languages, optics is a name given to a set of functions dealing with nested data structures. The tongue-in-cheek reasoning is that "optics let the user focus their code with pinpoint accuracy on the data of interest".

I will not be explaining optics in the post, but we need to know they exist, check, and that the first such pattern, the most used of them all is lenses, that allow getting, and setting, data in said highly-nested data structures. Check too.

The rub? Well, I said it... optics libraries need to be implemented before we can use them, they're not built-in into the language!

Indeed, how could they? There's no telling what are data structures would look like.

Even the existing libraries don't implement specific lenses, but rather give the user a framework to implement their own, according to their data.

I'm keeping the discussion on lenses, and optics in general, vague and hand-wavy on purpose: it's a huge one, complex, and while using them isn't too hard to grok, implementing them is worse than a root canal without anesthesia!

Still, for those interested: you can read, some more, and here too, for starter.

(For the very inquisitive minds, FSharpPlus has a very robust optics module, one such sub-module is Lens. You can look up the code on GitHub and see just how complex implementing a lens framework is.

Let's just say that applicatives is the least complex implementation detail!)

Rose-tinted glasses to all

So, updating deeply nested data is a chore in F#, whether using the classic approach, or using a lens library and implementing them for our specific data using the framework afforded by the library.

That was true, as I hinted earlier, till F#8 (for reference on November 2025 Microsoft will release F#10) when an update to the syntax of the most used case of the optics, the lens, was delivered.

Let's see just how easy it is to let dear Sherlock move out now:

let sherlockHolmesUpdated = {
    sherlockHolmes with
        Employee.Details.Address.Locale.HouseNumber = "222"
}

Yup, that's it!

Using the "classic" record update syntax, instead of updating each nested level on its own, we now simply build a chain of the nested levels up to the change location and... that's it, presto magic!

The only caveat in this new syntax is that it must start at the top-most level of nesting: Sherlock is an Employee, so we must start our chain with it (some texts seem to omit this initial level, which will result in type error.)

Multiple changes in one go also behave the same:

let sherlockInLiverpool = {
    sherlockHolmes with
        Employee.Details.Address.City = "Liverpool"
        Employee.Details.Address.Locale.Street = "Something St."
        Employee.Details.Address.Locale.HouseNumber = "5"
    }

And, for comparison with the classic method, that would be:

let sherlockInLiverpoolClassicApproach =
    { sherlockHolmes with
        Details =
            { sherlockHolmes.Details with
                Address =
                    { sherlockHolmes.Details.Address with
                        City = "Liverpool"
                        Locale =
                            { sherlockHolmes.Details.Address.Locale with
                                Street = "Something st."
                                HouseNumber = "5"
                            }
                    }
            }
    }

Was blind but now can see

The new syntax turned out to be so good at cutting down the burden of updating records that several optics libraries maintainers stopped maintaining their projects.

F# now has imperative-style nested records update method, with clean, comprehensible syntax.

It's really fun when language maintainers, in the case of F# that would be Microsoft, listen to its users' qualms and issues and fix them (even if it takes some time.)

Which reminds me... eat F#'s shorts, Go! 🤪😂

One... Two... Testing

O.F.K. — Sat, 13 Sep 2025 09:59:05 +0000

Nobody `Expecto` the Spanish Inquisition

On our previous hike, we modelled the domain of FunPark - our miniature theme-park management application.

It's wise to also test our code.

F# has a bunch of testing frameworks: starting from NUnit, the more generic .Net port xUnit.net, going through FsUnit, and several others of varying levels of adoption, or ease-of-use (yes, while I love it for trivial cases, I'm looking at you Unqoute.)

I decided to go with Expecto, One of F# community's most loved testing framework.

Expecto is truly a framework, not a library: it has a built-in test organizer, a test runner, and lastly, it has its own extensive assertion library.

To top things off, its documentation is top-notch (though, sadly, not perfect - there are some parts no longer compatible with current APIs, so caveat emptor, and lean on the great F# community for help!)

Let me give you an example

Expecto is an example-based testing framework.

What that means is that we run assertions on concrete instances: we run our functions-under-test with pre-defined inputs that we expect would yield a deterministic result. We then assert that the function's output matches the expected result.

Yes, that probably sounds like the testing you're used to, that you simply call "testing", and what's with the "example-based" nonsense?

That will be explained later.

FYI

There isn't much to say about Expecto that its documentation, and the code examples in test/server/FunParkTest folder don't cover.

Take a look.

Push comes to shove, example-based testing is mostly a “solved problem” in the domain of software engineering, what changes are the implementation details.

I personally love Expecto, as does most of the F# community, though I listed some alternatives you may want to tinker with to see what tickles your fancy.

Property of <entity under test>

All the frameworks and libraries in the previous section were, as noted, example-based.

Example-based testing is actually very well suited to Functional Programming languages due to those languages' attributes such as immutability-by-default, and pure functions having no side effects.

But what if we could test our function on a deeper level? What if we could identify some core invariant(s) of our function, that are true no matter what input argument(s) we pass it?

This is what property-based testing is about.

Standing on the shoulders of giants

F# guru, and all-round stand-up guy, Scott Wlaschin, has a series on PBT, a true masterpiece, showing Scott's uncanny humor, as well as giving a thorough tour of PBT basics, and then some.

Check it out!

The hedgehog can never be buggered at all

Current to this post publication date, F# has two well-established libraries for property-based testing:

On the left corner, weighing in at v3.x, hailing from the OG PBT library, Haskell's QuickCheck, of which it's a direct port, we have FsCheck - F# premier PBT library, well established, battle-tested, community-driven, just solid.
On the right corner, weighing in at v0.13.0, but very actively developed by its maintainers, Hedgehog - a multi-language PBT library (available also for Haskell and... sorry, I have to say a bad word, Scala). Not as well established as the incumbent, but still very welcome by the community, and an all-round excellent PBT library.

For my little reimplementation project, I decided to go with Hedgehog!

The reasoning? Twofold:

I just wanted to play with the "other" tool, the runner-up, full of promise.
Unlike FsCheck that lacks it, Hedgehog boasts built-in shrinking!

Honey, I shrunk the test

I'm sure the second bullet point made perfect sense, especially those who only learned of property-based testing just now, so we can move on.

Just kidding.

To understand what shrinking is, let's take a hand-waving detour of how property-based testing works.

How the property sausage is made

At its core a PBT library generates random value according to the types of the inputs to the function-under-test, which it then "feeds" into said function and assert a certain invariant, the property, is held for all those values.

(How those values are generated is a topic unto itself, you can read about here.)

We, however, want to discuss what happens when the library generates a value that disproves the property.

True, the library could just return the offending value and call it a day, but, due to the input values being generated in a pseudo-random fashion, that value might be non-informative.

As a silly, but illustrative example, think of a function that, due to a faulty implementation, expects all its inputs, which are strings, to contain the character 'a'.

Most PBTs generate strings by appending a random draw of ASCII, or even UTF-8, characters to each other for a given length. It's not uncommon for a generated string to look like "tIg87%^K🔥FHkjがf".

Now suppose our library found this string is invalidating our property and returned it.

What useful information did we get? Why is that string invalid? Is it because of the emoji? The Kanji? Too long? Too short? Because it has two consecutive numbers (did you catch that?)

There are too many possibilities, and even when inspecting the (faulty) function's implementation, we might miss the issue because we'd be trying to spot an issue that matches our assumptions, that I wrote before, not looking for "must contain an 'a' character" flaw!

Could the library do something to show us a failing input that just by looking at it we'd get that it's wrong and have an idea of how to fix it? For example, for our silly example function, the empty string, ""?

It would certainly help!

The act of producing ever simpler examples until finding the most trivial example to invalidate the invariant is called "shrinking".

I like small values and I can not lie

For simple types, e.g., primitive types, most PBT libraries know how to shrink towards a trivial example on their own: strings get iteratively shrunk into the empty string, numbers are shrunk from large ones to zero, lists are shrunk to the empty list, and so forth.

But... what happens when the library is faced with a complex type? How does shrinking happen then?

Without knowledge on how to shrink, some PBT libraries would be forced to return the first offending value they find, not the most trivial one.

The following example is taken from Hedgehog's documentation

(I feel it's not explained well, and the code snippets, for both FsCheck and Hedgehog are incompatible with their respective current APIs.)

Assume we have a type: type MyVersion = MyVersion of maj: int * min: int * patch: int denoting a SemVer-comptiable version number. (Not using Version as the type's name since there is a System.Version already.)

We now have this, again silly, notion all SemVer-compatible numbers are reversible (not necessarily palindrome, e.g., "1.2.1", but also "240.35.240") so we define the function, let revVer Ver(x, y, z) = Ver(z, y, x) (Yes, I called it revVer on purpose, see if you get why?)

Now, let's look at how FsCheck will return on this obviously wrong property:

// Assuming FsCheck library is in context, of course
open FsCheck
open FsCheck.FSharp // New in v3.x of FsCheck

type MyVersion = MyVersion of maj: int * min: int * patch: int

let verRev (MyVersion (ma, mi, pa)) = MyVersion(pa, mi, ma)

let version =
    Gen.choose (0, 255) // Arb.Generator<'T> is not compatible with FsCheck v3.x, so we get creative. Choosing `byte` was purely to restrict the possible values to some reasonable size!
    |> Gen.three
    |> Gen.map (fun (ma, mi, pa) -> MyVersion(ma, mi, pa))
    |> Arb.fromGen

Prop.forAll version (fun ver -> ver = verRev ver)

Here's the output I got:

Falsifiable, after 1 test (0 shrinks) (7912673337469139209,2146181641386198071)
Last step was invoked with size of 2 and seed of (16035987728726137193,1406933410677738447):
Original:
MyVersion (63, 87, 87)
with exception:
System.Exception: Expected true, got false.

There are two takeaways from this very informative error message:

The counter-example: MyVersion (63, 87, 87).
No shrinking was done, because FsCheck doesn't know how to shrink the custom type MyVersion: "Falsifiable, after 1 test (0 shrinks)".

Now, before we discuss this any further, let's see how Hedgehog deals with the same property:

// Assuming Hedgehog is in context
open Hedgehog

type MyVersion = MyVersion of maj: int * min: int * patch: int

let revVer (MyVersion (ma, mi, pa)) = MyVersion (pa, mi, ma)

let version =
    Range.constantBounded ()
    |> Gen.byte
    |> Gen.map int
    |> Gen.tuple3
    |> Gen.map (fun (ma, mi, pa) -> MyVersion (ma, mi, pa))

property {
    let! vers = Gen.list (Range.linear 0 100) version
    return (List.forall (fun ver -> ver = verRev ver) vers)
}
|> Property.checkBool
|> printfn "%A"

And the error:

Error: System.Exception: *** Failed! Falsifiable (after 1 test and 10 shrinks):
[MyVersion (0, 0, 1)]
This failure can be reproduced by running:
> Property.recheck "0_3673599252239236771_13184715031196647977_1010110110110110110110110110" <property>
at Hedgehog.ReportModule.tryRaise(Report report)
at Hedgehog.Property.checkBool(Property`1 g)
at <StartupCode$FSI_0010>.$FSI_0010.main@()
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

We can already see the difference:

The counter-example is as minimal as can be: `MyVersion (0, 0,1).
Shrinking occurred! Hedgehog knows how to shrink even custom types, provided the types comprising the custom types are either primitive, or otherwise well-defined in our code: "Failed! Falsifiable (after 1 test and 10 shrinks)".

"You're not integral, to the project"

Indeed, for a trivial example as our Version type the difference between Myersion (143, 2, 5) and MyVersion (0, 0, 1) is, well, trivial. But it's not hard to think of properties where getting to the minimal counter-example would be tenfold easier to parse than a non-trivial one (e.g., a record type with 10 fields, each field itself a custom type.)

The thing is, when dealing with custom types, FsCheck, unless provided a shrinking strategy, for which it has a specific API, treats the custom type opaquely and atomically, i.e., as a single unit.

When a custom type fails a property, FsCheck returns the offending non-trivial example, because it's the best it can do.

Hedgehog, on the other hand, and I'd be damned if I know how, that's why I'm only writing about it, not maintaining it, does know how to pierce into a custom type and shrink its constituents - assuming they're primitive types, or otherwise well-defined in the code.

This property, pun not intended but so very fitting, that some other PBT libraries in other programming languages also have, is called integral shrinking, because, unlike FsCheck that requires external shrinking strategies, frameworks with integral shrinking, know about shrinking on their own.

With great shrinking comes great responsibility

Both FsCheck and Hedgehog boast great generators API, the APIs for creating (pseudo-) random inputs.

Actually, they're so great that for the most part you can use those APIs to generate inputs even for custom types without fail or problem.

But sometimes we need more, we need a generator so customized, wrapping over a type so complex, that we need to create our own generator.

Luckily, both libraries allow us that too. With ease!

Check out tests/server/FunParkHedgehog/HedgehogGenerators.fs.

To grok the file, you need to know that Bogus is an F# implementation of the great Ruby Faker gem - a library for creating plausible-sounding values in a variety of domains.

I wanted to use it to create human-sounding names for my Patrons and Rides.

Could I have used Bogus directly in the constructors for these types? Yes, of course.

But that would lose the (integral) shrinking the PBT libraries offer - Bogus dishes out values of an (extensive) internal database. It has no notion of what shrinking is, and is not designed for that purpose.

Great idea in general, not good enough for my tests. I need more!

So, let's create a custom generator wrapping Bogus - a generator that calls a Bogus module, extracting a value from it, while retaining Hedgehog's ability to shrink the values if need be.

First, we define a way to consistently get the same wrapper.

As you may have noted before, in the example code earlier, both libraries, upon failing, note the seed they used to create the random inputs.

Knowing the seed is essential for making sure we can re-run the tests with the same randomized inputs to verify the failing tests now pass.

The implementation is rather straightforward, using Bogus's API for creating a seeded Faker object.

The real "magic" happens in genBogus (and its size-dependent cousin genBogusSized, though I've never used a size-dependent generator in any of my tests, and I'm not sure why they even exist).

In truth, genBogus is not magical at all: it uses Gen module's API to map from the given seed generator, a constraint imposed by Gen.map input expectations, to a generator wrapper around a specific Bogus API.

That really is all there is to it!

Tinker, tailored custom generators, solider, spy

To see how it's used, look at tests/server/FunParkHedgehog/RideTest.fs, specifically at the name generator.

We define fakerName using our genBogus which returns a generator wrapping over Bogus.Faker.Name module, so, basically: Gen<Bogus.Faker.Name>.

If you hover over fakerName though, you'll see its type is Bogus.Faker.Name, unwrapped.

That is because we defined it using let! (i.e., "let-bang"), which bind the unwrapped value.

(This non-magical "magic" is due to how the gen builder, a computation expression, another unique F# feature, is implemented.

I advise on reading Scott Wlaschin's, who else?, series on computation expression to understand these complex, but very rewarding features.)

One more touch I added to my custom generator was custom shrinking!

I didn't have to, as we now know, Hedgehog has integral shrinking, but I wanted the shrinking to also use the Faker.Name module, not resort to string shrinking, after all, name is a string in the end, so, actually, I did have to define a custom shrinker, but due to a business logic constraint, not a shortcoming of the library!

The last nicety I added, strictly for flair and showing-off, I admit, was tagSelector.

Using F#'s reflection capabilities, nothing to do with Hedgehog, it simply makes sure no tag is repeated in the tag list the Ride generator creates.

The worth of a testing library

One question to contemplate is "is this integral shrinking worth it?"

That's not a trivial question! While lacking in that department, at least currently, who knows what FsCheck's maintainers have in store, it does have a slew of other helper functions that make it an extraordinary testing framework: integral logging, custom distribution of inputs generated, and much more.

It may well be that Hedgehog has all those features too, but its documentation is very lacking, and if it does have those features... I don't know of them, or how to invoke them.

(Note that FsCheck's documentation is also lacking, and actually the official docs, on the website, are still those of v2.x, where the library is now v3.x!)

The answer to that question is left to you, dear reader, and your needs, and abilities, per project.

I wanted to try Hedgehog's internal shrinking, and this is, after all, a toy project I do for fun... no one's going to fault me for writing wrong tests, not having a 100% coverage, and so forth.

In real-life, production, projects you need to weigh all constraints you'd be facing and make an informed decision.

Hopefully this post helps with that.

And now, the time has come

This has been an even longer, bumpier, ride, ha-ha, get it, Ride, tough crowd, than the previous one, because the subject of testing, and property-based testing in particular is vast, to say the least.

I hope you did get at least some idea of how we test in F#, and of what PBT are, why they're useful, and a glimpse of how to actually use them.

As with the previous post, I put useful links throughout the text, to folks much more proficient than myself in F# (and the skill of writing succinctly, yet precisely. I know my own faults, yes.)
You'd be wise to follow up on these links, especially the ones to any of Scott Wlaschin's posts!

Adieu

The next two chapters in the original material are about custom equality and comparison.

Elixir doesn't have any built-in facilities to deal with either.

F# on the other hand does. For both, custom equality, and custom comparison.

But it's going to take me a while to read the chapters in Elixir, code them in F#, and write voluminous posts about it. 😁

So, for the time being, this is goodbye.

Hope you enjoyed these two posts, that you learned something, that something clicked for you.

And hey, maybe let's call it "till next time".

It's going to take a while, but I promise you, like Arnie... I'll be back!

Domain modeling, Units-of-Measure, and Property-based testing, oh my

O.F.K. — Tue, 09 Sep 2025 11:14:54 +0000

When I learned about "Advanced Functional Programming with Elixir" by Joseph Koski (PragProg publishing) - detailing building a miniature theme park application (a favorite gaming genre of mine) - I rushed to buy it.

After all, Elixir is a wonderful FP language I enjoyed coding in the past.

But there's a twist - I'm reimplementing the system in F#, using everything I know about F# to make the domain safer and correct!

For all my love for Elixir, F# is much better at leading the developer into the "pit of success."

As with all coding posts, I suggest you checkout the repo and take a look at the code while reading.

Grokking our domain (covering original book's chapter 1)

As is customary, and wise, we start the journey with the domain entities: Ride, FreePass, and Patrons (which are the park guests, as per the ubiquitous language for our domain).

The book starts with Rides.

The author immediately shows good software design by declaring it as a structure, an Elixir construct that takes specific shape, but only allowing instantiation via a constructor.

I was surprised that though Elixir does feature private functions, the author made the constructor public, defeating the purpose of only allowing instansiation via it.

In the F# implementation, I made the constructors private - no ad-hoc entity creation anywhere in the project by "rogue" code, no surprises!

But, with great control comes great compromises and technical challenges as we shall see momentairly.

Right off the bat, as I was modelling Ride in F#, some key differences between Elixir and F# stood out:

Elixir has succinct null-string verification but requires pattern-matching for empty/all-whitespace checks. F# actually doesn't have even that functionality built-in, but it's easy to implement by hand.
No built-in UUID generation in Elixir, forcing integer IDs. F# wins this one with robust GUID/UUID generation tools right in the standard library.
Erlang, on top of which Elixir is running, has symbols for strictly positive integers (which in math are called Naturals). F# doesn't ,but, again, it's easy to implement.
Elixir supports passing default values to functions while F# doesn't.

As an aside, I favor F#'s approach: call functions with all required arguments, or let it fail.

I did however implement defaults, for the challenge.

(Keep in mind, default values grant type-, and runtime safety, allowing an object to be instasiated despite missing arguments, but might not make business sense!

Programming is, as is well known, an exercise in compromise.)

To make constructors private in F#, there are two approaches: FP-leaning and OO-leaning: see the series on constrained types by (the great) Scott Wlaschin.

For the Ride type, I chose the FP-leaning approach purely for stylistic reasons.

Programming is also an exercise in style. 😜

To start an FP-leaning private type/constructor combo we first need to define the private type. The logic is impeccable, right?

// All preceding code elided
type Ride =
    private { Id: Guid
              Name: string
              MinAge: int<yr>
              MinHeight: int<cm>
              WaitTime: int<s>
              Online: RideStatus
              Tags: RideTags list}

Can't compare apples to Lamborghinis

We can already see a feature of F#, not available out-of-the-box in any other programming language I'm aware of: Units-of-Measure (in short: UoM).

Notice those <yr>, <cm>, and <s>? Those are tags, units, that qualify the numerical, integer, quantity they're attached to.

.Net has a few of them, the SI units, predefined, e.g., <s> which is the SI unit second. The others I had to qualify myself (look in Shared.fs file in the Shared folder to see how).

Thing is, much like a disciminated union, also known as tagged union, since each case acts as a tag, marking its corresponding data, UoM are light-weight tags too: an int<yr> is type incompatible with int<s>: if I were to do 5<yr> = 5<s>, the compiler would throw a type error!

Can we have some privacy, please

Now, this code only defines the private type, but not the constructor I talked about.

The point to understand is that by qualifying the type as private, the compiler will now allow only code in the type's enclosing module and/or namespace to access the type.

The way to create a constructor for the private type, which is public, is to create a sub-module, F# supports nesting modules as deep as you like, in the "main" module that will have a function that creates an instance, in the OO meaning of the word, F# types get compiled down to classes, of that type.

It's convention to name the sub-module after the type it creats, so I now declared module Ride.

Now came the time for another contemplatation: how to pass the arguments, six of them (Name, MinAge, MinHeight, WaitTime, Online, Tags) to the constructor: either passing them as one tupled argument, or six curried ones, meant all of them would be positional: their place in the order of passed arguments will dictate what argument they are: the first is Name, last is Tags... for an arbitrary function that has that exact parameter list!

That would work, obviously, but given there are six such parameters, this risks mixing them up causing errors.

True, in this specific case, most of the arguments being tagged by UoM, any such mixups would be caught by the compiler as errors, but I'm lazy... re-typing a six argument list by hand over does not sound appealing!

I figured there must be a better way to pass the parameters to the function - and there is!

Luckily for me, the ID properity of each of the entities is generated via the Systenm.Guid.NewGuid() method.

With that in mind I created a new type to provide the constructor function its arguments in a named fashion.

While I first hoped to pass an annonymous record to the constructor, e.g. {|Name = "myName"; MinAge = 8<yr>...|}, functions in F# do not allow annonymous recrods as parameters, so a full-fledged type was in order.

What I came up was:

    module Ride =
        type RideConstructor =
            { Name: ContentfulString option
              MinAge: Natural<yr> option
              MinHeight: Natural<cm> option
              WaitTime: Natural<s> option
              Online: RideStatus option
              Tags: RideTags list }

I'm gonna have my own types with private constructors and validations

I guess I now have some 'xplaining to do with regards to what are ConteftfulString and Natural which surely aren't built-in F# types.

I want my Rides to have meaningful names, e.g. not the empty string, nor an all whitespace name, and they definitely must not be null.

Same for the numerical value denoting age, heigt and wait time: neither of them can be a negative value, and actually, neither can be zero either! (Well, WaitTime can, in theory, denoting an offline ride, as we shall see in an upcoming post about testing the domain!)

Both these types are also constrained types: private with constructor and extractor functions and some logic to constrain the type instances' creation, to only allow values that are valid for the domain.

And yet, each of these types is also slightly different the Ride too.

For ContentfulString I used the OO-leaning construction of constrained types, simply because the OO-leaning way allows to attach the extractor to the type as a member, later allowing value extraction via the syntax aContentfulString.Value:

    type ContentfulString private (str) =
        static member Create str =
            if String.IsNullOrWhiteSpace str then
                None
            else
                Some(ContentfulString str)

        member _.Value = str

For Natural, since it would be denoting a tagged UoM quantity, its definition needs to support that:

    type Natural<[<Measure>] 'u> = private Natural of int<'u>

    module Natural =
        let create x =
            if x > 0<_> then Some(Natural x) else None

        let value (Natural x) = x

Failure is not an option (but in this case, it is)

Going back to the constructor type, you may be wondering, "but why are all the inputs to this record optional"?

The answer has to do with the Natural and ContenfulString constructors.

If you look at the constructors of these two types you'll notice both output an optional: Some<'T>.

The reason is that when constructing those types the input might be invalid, e.g., a negative number for the Natural constructor.

In that case, what should the constructor do? One way to go would be to raise an exception, but that's a very dramatic option, and also not very testable (the test would throw on any negative-path test, polluting the entire test suite's results!)

The better way, the F# idiomatic way, is to use the Option type: when an invalid input is given return None, otherwise, as noted earlier, return Some<'T>.

"Sure", I hear you say, "that makes sense for the name and the numerical quantities that use your custom, constrained, types. But what about Online and Tags? Those are custom types, but they don't have constrained constructors, so, what's the deal?!"

Do, or do not, there is no default

The answer to that question is that by now I was sure I had the Ride type figured out and it was time to create the constructor function.

As mentioned earlier, though I object, personally, to the notion of default values, I decided to implement them in this domain for the sheer challenge of it.

I also mentioned I created the RideConstructor type to be able to pass named arguments to the function.

What this amounts to is:

// Within the `Ride` module
let create
    ({ Name = name
       MinAge = minAge
       MinHeight = minHeight
       WaitTime = waitTime
       Online = online
       Tags = tags }: RideConstructor)
    =
    { Id = Guid.NewGuid()
      Name = defaultArg (Option.map (fun (n: ContentfulString) -> n.Value) name) "Generic ride!"
      MinAge = defaultArg (Option.map Natural.value minAge) 8<yr>
      MinHeight = defaultArg (Option.map Natural.value minHeight) 100<cm>
      WaitTime =
        if online = Some Offline then
            0<s>
        else
            defaultArg (Option.map Natural.value waitTime) 60<s>
      Online = defaultArg online Online
      Tags = List.distinct tags }

Aside: I didn't have to supply the input's type, RideConstructor, F#'s type inference engine would have infered it by its own, but I decided to add it as a hint for future readers (i.e., me).

Now it should be apparent why I made all the inputs to the constructor optional... as I said before, F# doesn't support default value to function's arguments at the function's call site.

What F# does have is the defaultArg method, as part of its core library.

The type signature for this method is option<'T> -> 'T -> 'T.

Let's deconstruct that: the first argument is a generic optional value, i.e., it can be of any inner type.

The second argument is a concrete value of the same type.

The outcome is a concrete value of the same type, too.

What that means is that, in essence, defaultArg takes an optional, and a concrete value: if the optional exist, i.e., its a Some<'T>, we get back the inner value of the Some. If, however, we pass a None, the method's output is the concrete value we passed as its second argument: the default value!

I didn't say it's hard creating default values in F#, just that it's not possible at function's call site. 😉

Since I wanted consistency in my parameters, and allowing default values to all parameters, like in the original book, I set Online and Tags as optional as well, and used defaultArg on them, too.

BTW, as I mentioned earlier, default values provide type safety, not business logic safety!

Consider the default name I assign: "Generic ride!". In the unfortunate event our ride constructor function (not yet implemented) is failing we'd have quite a lot of "Generic ride!"s.

Does it make sense? Nope! But that's what you get when you opt-out of failing fast!

It's the little touches that count

Maybe you also noticed that I employ List.distinct on the tags list, or the algorithm for creating the waiting time?

Neither of these is in the original book, but I like it.

The first ensures there are no duplicate tags in the tag list provided to the constructor, no sense in that after all, and the second makes sure an offline ride has a 0 wait time... no one is waiting on an unoperational ride!

The private constructor conundrum

At this point I was sure I'm done with the Ride type and can move on to the others. I used F#'s REPL (AKA fsi) to create a few Rides and things seemed to work fine.

Or did they?

Everything was fine... until I needed to access an instance's fields in tests, at which point all hell broke loose!

It's not so much a mistake, as a limitation imposed by the fact that for a private type, only the module holding its defintion can access its fields!

Even an extractor function wouldn't work: its return type would be Ride -> Ride, but Ride is private!

Twins - like in the Schwarzenegger/De-Vito movie

This may surprise you, as in the examples from Scott Wlaschin's blog posted earlier, the extractor works fine.

The difference stems from Scott's example constrained types being "boxes" for inner values like String50 str - when extracting, we want the str content, not the String50 wrapper.

Our domain types, on the other hand, are the entirety of what the constructor produces. Extracting a Ride simply returns another private Ride which is what we need back!

The solution turned out to be intuitive but, admittedly, cumbersome: creating a public clone type, RideView, and setting its fields to the original instance's values.

Programming is, it turns out, an exercise in creative workarounds. 🤯

The closer - Like Brenda Leigh Johnson

It's now time to bring the Ride type to conclusion.

With the RideView type being public, I could now write an extractor function that returns a type whose members I could access on demand, which is the final part missing before I can test my implementation for correctness.

In my Rides.fs file I made a design decision to put RideView after the Ride type.

This has significance as F#'s compiler infers types that have the same shape in order from top to bottom, so when referring to types of the shape of Ride/RideView, unless explicitly annotated, inference will always infer RideView, which is not what we want!

For instace, our create function now has to be annotated on its return type:

        let create
            ({ Name = name
               MinAge = minAge
               MinHeight = minHeight
               WaitTime = waitTime
               Online = online
               Tags = tags }: RideConstructor)
            // Notice the return type annotation
            : Ride = ...

The reason is when creating I do want a Ride, not RideView, but without annotation as discussed, the type would have been infered incorrectly.

Lastly, we finally are ready to create the extractor function.

        let value (ride: Ride) : RideView =
            { Id = ride.Id
              Name = ride.Name
              MinAge = ride.MinAge
              MinHeight = ride.MinHeight
              WaitTime = ride.WaitTime
              Online = ride.Online
              Tags = ride.Tags }

This time I didn't have to annotate the output, inference would have worked just fine. I did, however, have to annotate the input to let the compiler now I'm only willing to accept Rides to the extractor function... there's no sense in extracting a RideView.

The body of the function is pretty self-explantory: create a record of the public RideView type, a public clone of Ride, and assign each of its members the corresponding value from the private Ride... a 1-to-1 clone of the input, but public, with accessible members that would be testable.

All good things come to an end

With this, the Rides module is complete: we have a private constructor to only allow Rides to be constructed by a trusted function, and a public extractor to allow testing.

It tooks some compromises and some work-arounds, but it is now done.
Mission - accomplished!

The FreePass and Patrons types follow the exact same logic, with the same constrained types (actually FreePass takes valid Rides and .Net's native DateTime... the constructor logic is straight-forward once you followed this post).

And so we finished our initial domain modelling according to what we know about the domain thus far.

Now remains the "little" matter of testing to make sure my implementations actually got the job right.

But that's for another post... 😝

Thanks for reading all this scroll of a post, hope you enjoyed, maybe even learned something new, and, of course, comments are welcome, especially if they're nice. 🤣

DEV Community: O.F.K.

The death of a QA profession

2000 just called, it can't believe you're STILL using L33tC0d3!

The path to hell is paved in good intentions

My way

It's a cultural thang

From CAP to GAP?

Humble beginnings

Artificial intelligence is no match for human stupidity

Fundamentally speaking

Tasty, low calories, cheap - pick only two

The future's calling

Are we there yet?

The function not dispatched

You had one task

Two methods diverged in a code

Are you kidding me?

Slow and steady wins the race?

Fast and loose

They STILL look like the same picture

Why don't they build the entire airplane from the materials of the black box?

Fin

Say what you mean

Use your words

What's the point?

A trusted gatekeeper

So, the same as the English definition?

My hovercraft is full of Rubies

Ruby, the Python we deserved

Yeah, well, you know, that's just like YOUR opinion, man

Objects all the way down, consistently

"Come up and see me, make me smile"

I see what you mean

A Functional (Programming) language

Eat my dust

The way of the world

Death of a lens(man)

Focusing on the issue

Seeing what the problem is

Eyeing the solution

Seeing with pinpoint accuracy

Rose-tinted glasses to all

Was blind but now can see

One... Two... Testing

Nobody Expecto the Spanish Inquisition

Let me give you an example

FYI

Property of <entity under test>

Standing on the shoulders of giants

The hedgehog can never be buggered at all

Honey, I shrunk the test

How the property sausage is made

I like small values and I can not lie

"You're not integral, to the project"

With great shrinking comes great responsibility

Tinker, tailored custom generators, solider, spy

The worth of a testing library

And now, the time has come

Adieu

Domain modeling, Units-of-Measure, and Property-based testing, oh my

Grokking our domain (covering original book's chapter 1)

Can't compare apples to Lamborghinis

Can we have some privacy, please

I'm gonna have my own types with private constructors and validations

Failure is not an option (but in this case, it is)

Do, or do not, there is no default

It's the little touches that count

The private constructor conundrum

Twins - like in the Schwarzenegger/De-Vito movie

The closer - Like Brenda Leigh Johnson

All good things come to an end

Nobody `Expecto` the Spanish Inquisition