IF-less programming

Ok, with that I can agree.

Or maybe better: how can ifs be replaced (sometimes) using OO principles

My take on why ifs are "bad" is that they are statements, just like for, while, switch and others. Being statements they can't be composed as you would do with expressions.

I know that this isn't probably the case you speak of when you say "If your code reads like math, I expect that its probably done right.", but I have a huge tendency to minimize code size by converting everything to "math". I converted a few hundred lines of C# code full of if statements made by a junior dev into this (more or less):

  var minutesToAddToAlert = (timeToAddInMinutes) + (900 * ((timeToAddInMinutes + 
                            (currentTimeOfDayInMinutes - 510)) / 540)) +
                            (2880*(((currentTimeOfDayInMinutes + (1440*dayOfTheWeek)) + 
                            ((timeToAddInMinutes) + (900 * ((timeToAddInMinutes + 
                            (currentTimeOfDayInMinutes - 510)) / 540))) ) / 7200));

  var nextAlertDate = currentDate.AddMinutes(minutesToAddToAlert);

There is definitely a lot more to it than just this, but I don't like blocks of code that don't fit on my vertical 24 inch screens. So I always end up converting "logic" (if's and else's) to math. It's a pet peeve of mine (as is overusing ternary operators as my own personal way of doing haiku), and while I certainly decrease the vertical size of the code itself, it makes it a hell of a lot harder to understand for everyone else. I then have to write comments explaining what stuff like this does, and those comments can get rather obtuse depending on the time of day.

Everyone winces when they see my commits with this message: "Math. Converted X and Y to M-A-T-H. Math. :D"

In what languages is if a function?

Oh yes we all live in the land of the ideal where everything is functional and has no side effects of course and we're blessed with parenthesis.

There is a huge difference between an if and a function. Consider SICP where lazy evaluation is introduced (read it if you haven't). An if statement encompasses the lazy evaluation as a native concept whereas a function's arguments are always evaluated (assumption for now - please carry on reading).

So consider an if statement as a control flow structure which automatically supports lazy evaluation and leaves the return semantics up to the user. This abstraction is clean from the highest level, right down to the CPU which uses conditional branching to perform the if operation. There is a 1:1 match all the way down.

The function on the other hand does not natively support lazy evaluation and enforces the return semantics. You then have to apply a lazy evaluation mechanism over the top (another layer of abstraction!). This layer of abstraction conveniently ends up using conditional branching to perform the if operation when it gets to CPU level. There is not a 1:1 match all the way down.

Big hint there: your functional if at the end of the day is just a compiler abstraction over a state machine which uses ifs.

As for OO, the industry I think has decided who won that battle.

But alas, no religious war is required. Use what tools work for you.

It's irrelevant if you're using ifs or different objects, the number of conditions/tests needed for what you are testing is the same.

Now, you could make depObj1 of type Obj1 and Obj2 to replace the if, which may simplify testing because the method is "simpler" in Obj1/Obj2/ObjBase but in the end it isn't!

Why? Because your test of Obj1/2 has to take care of their dependency to ObjBase. It's usually a dependency hell, needing lots of workarounds to test properly.

As long as there is a mechanical transformation from one style to another, this is not abstracting, is merely shifting the syntax.

You do introduce more named test points, but you risk of creating too many tests at a too small granularity, that will only slow you down for no good reason. Consider using a code coverage tool to help you navigate all the branches, without explicitly naming them.

Keep in mind readability. Jumping around source files is costly on the reader, don't break the flow if you don't have to.

Welcome to HN where all subjects are obsessed over obsessively..

That said I do think all things in moderation. At some point if you abstract the logic so far out humans have a hard time reading it or computers have a hard time optimally running it then you've lost the gains. I can think of several times when I was coding something using a class and noticed I had to write a lot of logic to really use the class the way I wanted. I wish in those situations the class was better designed to avoid spaghetti code to use it.

That said many times the use of an object is nothing like what the original author thought it would be. It is hard to think in advance about every potential use case, shoot for the most common cases and make it all readable. Hopefully later someone else will come along and make it more useful to the real world use cases.. :-)

Function-extensibility using the visitor pattern in OO sucks compared to functional pattern matching. It is almost unusable except for the most trivial tree traversals.

Frequently you want to be able to pass arguments down and return values up the tree traversal. Using visitors, you need a whole separate class for each unique function arity, or you have to use tedious little data carrier instances. Sometimes you want to switch between them half-way through the traversal, e.g. use your constant-folding visitor during an optimization visit, and the visual overhead of constructing visitors and keeping track of them, making sure they're all linked together properly, is really ugly. Don't even think about matching the visitor method on more than one parameter type, like you might do with e.g. overload resolution of binary operators. I've been there working on a commercial compiler, and I don't want to go back there again.

Haskell can implement the OO style using existential types (forall), a bit like Go's interfaces, except once you put a value into an existential type variable, you can't typecast it back out again.

"We need to think about the effect our choices have on the next person who touches the code."

And that next person might be the newbie on the team that doesn't have the business domain knowledge built up over years of working for This Company. So I'll use the if statement to keep intent clear.

Or maybe it'll be someone whose primary programming language doesn't use the || operator. Or maybe, for some unknown reason, it'll be a PHB. So I'll use the if statement to keep intent clear.

0 evaluates to true in Ruby. Only nil and false evaluate to false in Ruby, so it'd work as intended.

Whether or not the second example represents a syntactic improvement is more of a personal preference. Personally, I find the first example more readable when quickly scanning code.

Couldn't agree more.

I don't advocate a completely if-less style, but I do often grep and count ifs and elses in a code base before digging in, just to get a sense of what sort of developers have been there.

I think the if-less style is great kata material. You learn a lot when you apply it on a toy project rather than a real one. Sometimes you need to overdo things in order to understand what their limitations are.

I guess I don't see the harm in spending a little extra time up front to design things properly rather than just jumping in and writing code, hoping to stumble upon the correct design pattern. I've found it much easier to find and solve problems up front rather than waiting for potential landmines, at least, the time required to fix those problems is less if they're exposed earlier in the process. It's certainly possible to over-engineer a solution if you select a design pattern up front, but maybe you'd be better suited by having a rule against over-engineering.

Fine, but the point is that the guy is only half-way through his reflexion. OO programming is an effective way to organize the business logic. And that logic should be coded in a sequential fashion to be readable and maintainable. Finding the right balance would be a much more interesting subject than to say 'ifs suck'

Similarly, when there are no extension points, extension get hacked in (= "if" everywhere !)

Here is my experience with architected extension points:

1. Generally the first extension point used set the trend, other developers will follow the "pattern" blindly. Hacking to make it fit rather than use another more appropriate extension. That is both bad and common (everyone has had to work with too little time)

2. There is often a sharp refocus close before or after release 1.0. A lot of the extensions disappear at that stage (demo, experimental feature, cross-platform/framework support, performance targets are set, security infrastructure is decided, server setup, integration test env. available instead of simulated, ...). Structural change (like removing extension point) become very difficult to justify after release 1.0.

3. Technical debt is very often called "selling feature" at management level.

But yeah, real world code sucks.

I second the question, pattern matching is cool for destructuring or for completeness checking (not sure those are fundamental properties of pattern matching though), but it does not solve the problem of adding new behaviour without changing existing code any more than an `if` does.

Is pattern matching really that different from switch statements, which are really just fancy of statements?

Mostly, yes. Pattern matching also provides destructuring, allowing you to bind constructor arguments and pattern match against such arguments as well. For instance:

    fun (Just (x:_)) = ...

But some of the downsides are comparable to switch statements, e.g. if you modify:

    data MyType = Foo | Bar

to

    data MyType = Foo | Bar | Baz

You will have to (potentially) update all functions or case expressions to account for Baz. One could use parametric polymorphism, comparably to the linked article, to make more extensible code. In such a case, one would define a type class such as:

    class (Show a) => Printer p where
      printIt :: p -> a -> IO ()

And one could make particular printers of this typeclass. You could even throw in existential quantification so that a function does not specialize to a particular Printer.

Pattern matching is a lot more expressive that switch and if statements, as it combines testing with elimination. For instance, let's say we want to write a new tail function, which returns the tail of a list but returns [] when the list is empty (pseudo-Haskell):

    tail2 xs = case xs of { Nil => []; Cons(x,xs) => xs }

    tail2' xs = if xs == Nil then [] else tail xs

In the second case, tail2', the compiler won't stop us if we switch the two branches. In the first case, tail2, we only get access to the tail of the list if the list is actually non-empty.

In essence, the difference is that if statements throws away any static information about the test result, whereas pattern matching constructs lets that information flow to each branch through variable binding.

It would be just as clear in expressing that the intent is an assignment (and more clear what is being assigned, since it avoids the coalescing-OR) though less concise to leverage the fact that Ruby's "if" is an expression not a statement:

<code> param = if object.property then object.property else default_param end </code>

Though, actually if you want to do what the description says (use the default if the property is unassigned, represented conventionally in Ruby by the accessor returning nil) rather than what either the good or bad code does, you probably want:

<code> param = if not object.property.nil? then object.property else default_param end </code>

(The difference between this and the other versions shows up if the property is assigned, and its value is false.)

I'm actually curious about the internals of how a modern OOP system works internally once it's boiled down to the CPU level. I'd imagine there's still lots of branch prediction issues in complex OOP systems.

There is no programming construct that exists that is not rife for abuse.

The way I see it, a programming language should...

1) correspond to computer architecture (which excuses the distance from human thinking)

2) correspond to human thinking (which excuses the distance from computer architecture)

So what's the excuse for pulling such strange rules out of nowhere? The sort that have no counterpart outside of the language itself? Is it just for the sake of making programming more of a puzzle, or...?

Erlang has mutable variables (the process dictionary), it just makes you do more work to get at them instead of immutable ones and prevents them from being directly shared and causing synchronization problems.