Why Functional Programmers Avoid Exceptions

If you’re in a hurry, here is the 60 second version:

My previous article caused a variety of consternation, imperative patriotism, and lots of nuanced follow up. It reminded me of when Richard Feynman was asked to define how magnets work and he refused. The perturbed interviewer postulated it was a reasonable question in hopes to understand why Mr. Feynman wouldn’t answer it. Richard Feynman covered a variety of reasons, 2 of which were:

  1. you have to know the deeper reasons first before I can explain it
  2. I can’t cheat by using analogies that they themselves require deeper meanings to explain how _they_ work.

In the case of avoiding async/await keywords in JavaScript, this makes a huge assumption you know about Functional Programming, Imperative, exception handling, how various languages approach it or don’t, the challenges between dynamic and strongly typed languages, and on and on.

Continue reading “Why Functional Programmers Avoid Exceptions”

Why I Don’t Use Async Await

A lot of JavaScript developers speak in exceptions. However, JavaScript does not have any defined practices on “good exception handling”. What does good mean? All using try/catch, .catch for Promises, and window.onerror in the browser or process.on for Node.js? Just http/file reading/writing calls? 3rd party/vendor systems? Code with known technical debt? None “because fast, dynamic language”?

In my view, good exception handling is no exceptions. This means both writing code to not throw Exceptions, nor cause them, and ensuring all exceptions are handled.

Continue reading “Why I Don’t Use Async Await”

Test Driven Development in Both OOP and FP

Skip Intro, Show me the Vids

I’ve been watching a lot of Dave Farley’s YouTube channel lately, and it’s spawned a lot of gears in my head. One in particular is “translating OOP people”. Specifically, our software industry will say things, and many times the speaker will assume they’re talking to an Object Oriented Programming audience. They’re drop words like “abstraction”, “coupling”, or “Bounded Context” as if that’s the way things are done, supposed to be, and everyone just needs context.

Continue reading “Test Driven Development in Both OOP and FP”