OOP theory vs practice

😆

Nice

blasphemy!

 undefined

    
void main(int argc, char ** argv, char ** envp)

  

 undefined

    
public static void main(String[] args)
public static void main(String[] args)
public static void main(String[] args)


  

Am I summoning the flying spaghetti monster?

I believe the lifecycle goes ExceptionLayer, ExceptionIncubator, ExceptionHatcher

It's critical you don't throw your exceptions too early, they need to learn to fly first 🤣

and like a goddamn fiddle!

https://factoryfactoryfactory.net/

Functional Programming Theory: 500 pages of lambda calculus and endofunctors

Functional Programming Practice: Quicksort

You can't spell "functional programming" without "fun".

Functional programming is perfect for all my projects that I don't start!

Been working in Clojure for over a decade now, and would never never go back to using imperative/OOP at this point.

Would you make a game with functional programming? Or anything with a GUI?

I thought those were for only when shit is seriously wrong and execution can't continue in the current state.

That's how it starts. Nice and simple. Everyone understands.

Until

some resource was in a bad state

and you decide you want to recover from that situation, but you don't want to refactor all your code.

Suddenly, catching exceptions and rerunning seems like a good idea. With that normalized, you wonder what else you can recover from.

Then you head down the rabbit hole of recovering from different things at different times with different types of exception.

Then it turns into confusing flow control.

The whole Result<ReturnValue,Error> thing from Rust is a nice alternative.

As a rule, exceptions should indeed be used for behaviors that are outside normal execution flow. For example, you might throw an exception if a file you're trying to access doesn't exist, or a network call fails, etc.

You don't want to use exceptions in normal control flow, because they're extremely slow. Every time you throw an exception, it has to collect a stacktrace, which is hundreds, if not thousands, of calculations, compared to a handful of calculations for returning a boolean or an enum variant.

I suppose it depends on the language? For the most part I think you're right. Exceptions are only used (if at all) in situations where a program diverges unexpectedly from its normal flow. But take a language like Python. They're just everywhere. Even your plain old for loop ends on an exception, and that's just business as usual.

It does, hence why it breaks the paradigm.

The. real question is whether this problem needs to be modelled using classes in the first place. The alternative is to just have a set of composable functions that take a piece of data and return a modified version that can be passed to a different function.

Well, what problems are you trying to solve by having the classes all access each other's data members? Why is that necessary?

My biggest problem with it is that those aren't verbs. You might have LegCount -> Countable and FleaCount -> Countable though.