No Conditionals Please
At the 2007 OOPSLA Conference in Montreal, a professor from New York City was explaining how he taught his introductory computer science classes. Students would be given a problem and they’d go through a number of steps until the solution failed. He found that most of the failures occurred as students became entangled in ever more elaborate conditional statements.
To resolve this problem, he told them they could not use conditional statements, and the general results were both better solutions and better coding. My first reaction in one of the breakout sessions was “No way!” Back in the day, one of my favorite pastimes was working out sort algorithms, and I find it hard to imagine working out even a simple bubble sort without using conditional statements. Other examples quickly came to mind, and I dug in to defend the use of conditional statements from if to switch (and everything in between).
Then he mentioned three magic words: State Design Pattern. This got my undivided attention because of the work I’d done with them and more generally, State Machines. Each class in a State Design Pattern is made up of a set of functions that launch when a certain state in invoked. No if’s in sight. Triggers launch different states, and the state classes provide the context for the particular state. In other words, the triggers just call the state class desired.
Aside from the State Design Pattern, can a decent program be written without a single conditional statement when more than one condition needs to be considered? I think it can be, and I’m beginning to think that much better programs can be developed if conditionals are kept out. To illustrate a simple decision-making process with no conditional statements, the following program has a decision-making process based on user input.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | package { import flash.display.Sprite; import fl.controls.Button; import flash.events.MouseEvent; public class Unconditional extends Sprite { private var men:String; private var women:String; private var Button1:Button; private var Button2:Button; public function Unconditional () { men="Men"; women="Women"; Button1=new Button(); Button1.label=men; Button1.x=200, Button1.y=150; addChild (Button1); Button1.addEventListener (MouseEvent.CLICK,doMen); Button2=new Button(); Button2.label=women; Button2.x=200, Button2.y=200; addChild (Button2); Button2.addEventListener (MouseEvent.CLICK,doWomen); } private function doMen (e:MouseEvent) { trace ("Whatever is appropriate for men"); } private function doWomen (e:MouseEvent) { trace ("Whatever is appropriate for women"); } } } |
That was a simple program, and it could have been handled with a single method using a conditional statement.
But It Would Have Been Easier….
In thinking about this, you may be thinking of a long list of cases used in a switch statement or even a simple if...else sequence make a program possible. (I mentioned sort algorithms, and I’m sure you can think of others where you just had to have conditionals.) Often, (in fact usually) it’s easier to use conditional statements than to work out a lot of code that does the same thing. However, no one who took up design patterns was looking for an easier way to create code. In my experience, there’s nothing easy about design pattens except when it comes to the all important task of updating and changing a program. So, because it’s easier probably is not the best argument to preserve conditional statements–at least for readers of this blog.
Why Conditionals?
Rather than ask why not conditionals, I think we need to ask why conditionals? Why indeed? If a programmer wants something to happen given an event, ranging from user input to data from a Web service, the event should trigger the actions directly rather than first filter through a conditional statement. It cuts out a step (the conditional scratching its head) and goes right to the solution. So why even use conditionals? Yes, we’re all used to them, but most of us were used to either sequential or procedural programming before tackling OOP or design patterns. If we can get along without conditionals, and keep a direct link between the state to call an action and the action, it would seem to be a better programming structure. Then, when we want to make changes, the events are not tied into a conditional statement, and we don’t have to untangle the conditional webs we weave.
Comments Please
I’d really like to get some feedback on this idea. If you’re thinking, That’s the stupidest thing I’ve ever head, I’ll save you the trouble–that was my initial thought, and it didn’t really help the discussion. Rather, I’m hoping to find some ideas about this — with or without the State Design Pattern. Mainly, I’m interested in this in the context of design patterns in general; specifically how conditionals or lack of them relate to the different kinds of connections between classes. Do they really get in the way of delegation, composition, aggregation and inheritance? Are they simply a shortcut and add little to good structure? Or not?
The Let’s Get Rid of Conditionals! by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Related posts:
Bill Sanders
Interesting post. I think there are a lot of things we use out of habit or laziness. Singletons are one of them. I don’t think it makes sense to totally ban conditionals, but it would a great eye-opening exercise to try to code something without them. Would probably change the way you think about and use them.
If you think about it, one of the tenets of object oriented design and design patterns is encapsulating change. That’s exactly what conditionals don’t do. The state pattern is one good example, but in general, just programming to an interface is a way of avoiding conditionals. Rather than have one class with some methods, each of which have conditionals and different code in them. The methods are designated in the interface and concrete classes implement the different code.
No idea how you’d to a sort without conditionals. That would be a good challenge. :) Of course, the real challenge would be to do a sort without conditionals that was better than one that used them.
Interesting concept Bill. This got me thinking about a post on Slashdot the other day about how “Faster Chips Are Leaving Programmers in Their Dust”:
http://developers.slashdot.org/article.pl?sid=07/12/17/1635200
The basic argument of the cited articles in the post is that the CPU speed wars are over and multi-core computing is the way to increase performance. The downside is that performance gains can only be fully realized by parallel programming — and programmers are quite lacking in their abilities and expertise to write parallel programs.
Of course, I’m no parallelism expert but isn’t branch prediction (due to conditionals) one of the big considerations in pipelined processor design? And aren’t state machines more conducive to parallelism? — just a guess.
It would be nice if eliminating (at least some) conditionals, and implementing state machines brought a significant increase in execution speed. Of course processors and languages would have to be updated to take advantage of the change as well.
Dear Bill,
Of course you know I’m a big fan of state machines, but I wanted to add a caveat by way of a ridiculous example: one could do away with fixed-sized integers as a datatype if you used a state machine to represent the value (i.e., each variable is an instance of our integer state machine, whose active state is the number being represented).
In other words, what may be possible still may not be practical. So common sense has to rule.
That having been said, I think it is essential for programmers to understand how important the idea of maintaining an application state is, not through ad hoc global flags or series of conditionals, but through a formal model (formal meaning that the notion of context is built into the way the application is designed). For anyone who doubts how serious this can be, I’d suggest reading Miro Samek’s book, Practical Statecharts in C/C++ (www.quantum-leaps.com). He cites one real-world example (in particular) in which a radiation-therapy device (Therac 85 I think) killed people because the program, after patches here and there, ended up in an indeterminate state, i.e., the way in which it was programmed left some routines thinking the laser was on, and some parts thinking it was off. He also talks about flaws in programs even as basic as the Microsoft calculator.
I understand that when people think about design patterns, and state machines, they think it’s all conceptual and too much of a hassle to learn, but as you point out Bill, it makes certain aspects of many types of applications much cleaner. Also, as Samek demonstrates, it doesn’t have to be less efficient than what others might consider a pure OOP approach.
In spite of my long-windedness, my basic point is that one has to choose at what level to discretize (to make a context, or state). You can go whole-hog and represent integers as state machines, but you will lose efficiency. In the same vein, I don’t think using conditionals are bad, unless they are being used to manage application state implicitly. For example, if you have two buttons, and in each of the button’s handler, you use a conditional to see which state you’re in, then execute something. In that situation, something one might think is very object-oriented, you open up the potential for later developers to modify one button handler’s perception of state, but not the other. In that situation, it would be better to route all button events through a central routine that determines which state the application is in, then handles all the events for that state. In that way, if a programmer changes the behavior for a state, he or she knows where to find the events that can occur for that state. This may sound less OOP, if you think about the objects as the buttons or interface elements, but in reality, it is very OOP if you think about the objects as states (contexts). So I think a lot of the resistance to state machines from people who try to use OOP as a catch-all comes from an inclination to treat individual interface elements as self-contained objects, whereas they really are actors whose behavior is determined fundamentally by the current state.
-jonathan
Hi Jonathan,
Years ago when the
gotostatement was being condemned as the work of Satan and the cause of spaghetti programming by the (at that time) New Procedural programming style, a very bright programmer showed a group of developers how thegotostatement could be used instead of eithergoSubor loops.(If I remember correctly, some old programmers scoffed at the idea of ever doing away with thegotostatement, which disappeared in name but not necessarily functionality.) The language was FORTH, and so it was pretty low level–some even considered it an assembly language–and so you knew pretty much what was going on with the assembler and compiler. The point being that the procedural programmers were revolutionizing programming just as OOP and Design Patterns (and State Machines!) have done since then, but someone comes along and says, “Hold up! Let’s look at this. Is that really what’s going on?” This was NOT a complaint because procedural programming was new, but rather an examination of the New Truth (which in turn has been replaced by Newer Truths and I hope even newer truths–such as the emerging Parallel Programming that Chandima is tackling.)At some level the title of this blog (Let’s Get Rid of Conditionals) is a fire alarm to get us thinking about what we’re doing in our approach to problem solving. It’s also a way to make us reflect on exactly what we’re doing in our coding. Snorting “Spaghetti Programming”, “OOP” or “Design Patterns” as a battle cry for better programming is not enough unless we understand where and why these structures are put into place and never accept any programming panacea as valid unless we understand it.
In building state machines (using the State Design Pattern), I did pretty much what you said. All of the states were contextually bound, but one class had to be the centralized handling point where I employed conditional statements galore (or just a big
switchstatement) to direct the flow to one state or another.Doing away with integers as a type…hmmm, now there’s an idea….
Bill
(By the way, Dr. Jonathan Kaye is the author of Flash MX for Interactive Simulation and deserves a good part of the blame for my trying to be a better programmer.)
Couple of reactions to this post:
1. In both von Neumann languages (such as ActionScript) and non-von Neumann languages, conditionals are not only explicit like with “switch” and “if,” but are implicit in all loops. Are you saying that we should do without loops, too?
2. It can be proven that languages without conditional statements are weaker than those with conditionals – “weaker” meaning that not all Turing-computable functions can be calculated. So, dropping all conditionals from a language is truly a substantive change.
3. Sure, state machines can be used to mask conditionals, but that’s not the purpose of design patterns, is it? And the sample code provided moves the conditional outside the computer completely, leaving the user to make the decisions – but then why use computers?
4. The decision made by this professor occurs all too frequently in higher education: concept X (be it conditionals, or whatever) is “too hard” for his/her students to grasp, therefore X should be dropped from the curriculum. But it is also a cop-out: maybe this professor is not a good teacher, or maybe the students are unprepared, unmotivated, or suffer from grey-matter deficiency? Many, many people have learned to write conditionals that are free from errors, and the “solution” this professor used postpones the students’ much needed encounter with conditionals, and as such severely compromises their education.
Hi Mike,
I knew a lot of people would be uncomfortable by this suggestion, but we’re not talking about one professor who cannot teach conditionals. Quite the opposite, and your assertion that “this occurs all too frequently in higher education” is baseless if not banal. As you probably know, OOPSLA is made up of both academics and non-academics. (OOPSLA is the conference where Design Patterns were introduced, and Gamma et all are regular conference participants.) In this particular session, we had a rich mix, and like I said, my first reaction was “Now Way!” until I listened to the reasoning.
As for your points citing John Von Neumann, that’s nothing more than a vague reference to an authority who was involved in the early days of computer architecture. When we studied Von Neumann, it was for his contribution to cybernetics, and he is probably the last person on earth who would dismiss an idea because of a tradition. That’s what you seem to have done. If you don’t even listen or think about an alternative to old habits, then I really don’t see how you can ever grow as a developer. Computing is not a religion, and so you need not fear heresy or excommunication for putting forth an idea meant to stir the mind.
You mention that “it can be proven” that languages with conditionals are stronger than those without. Unfortunately, you fail to state how. Please do so.
State machines are NOT used to mask conditionals (do you make this stuff up?). Rather they they are based on moving from state to state with all contextual materials held in the state. If anything masks what’s going on (how outcomes are determined), it would be conditionals and not state machines.
As for “decision making” we all know that computers don’t make decisions. They’re simply a series of gates opening and closing. In the example I provided, the computer did make a “decision” (in your sense) based on the user input; it provided different output depending on the input. In other words, it made the same kind “decision” that a conditional statement would make.
Rather than tossing this idea aside without considering it at all, I thought about it. The people at OOPSLA are far brighter than I am, and so I began experimenting with it. Granted I’ve spent a lot of time with both State Machines and the State Design Pattern where the actual state engine did not use conditionals, and marveled at the minds that conceived the notion.
Remember, this idea flies in the face of conventional wisdom (from which nothing new ever emerged), and I offered it up as such. I have no idea how I would create a Flyweight Factory without using conditional statements, but that has not kept me from thinking about it. My hope is that readers on this list would consider non-conventional ideas–not because they are unconventional, but because they force us to think about what we’re doing.
Bill
I don’t necessarily disagree with this idea, but I do feel that it gets in the way of more important ideas.
In my opinion the art of programming is about clearly communicating your intentions through your code.
The State Design Pattern is possible because of polymorphism, which allows you to define multiple forms of a chunk of functionality.
Languages like Actionscript, where statements are executed sequentially, offer the notion of a flow of control. In these languages if-else statements should define equivalent but alternative flows. By equivalent I mean that the if and else blocks are alternatives to one another. If-else statements can be implemented using polymorphism, but at the cost of a fair amount of conceptual weight. A programmer debugging your code now has another Class to look at. The benefit of using polymorphism should outweigh this cost. If-else statements seem to be a common point of change and it is this change which justifies the conceptual weight.
If statements, on the other hand, present a different problem … they act as exceptions to the flow. An excellent example and use of if statements in an object-oriented language are guard clauses. Consider the static getInstance() method of a singleton:
…
if ( instance == null ) instance = new Instance();
return instance;
…
When you execute getInstance() you expect it to return to you the one and only instance of the class. The if statement here acts as a guard clause in the case that an instance has not yet been created. I chose this example because of how familiar it is, but if the method were not static then the State Design Pattern implementation would require a state for the special case as well as the normal case. The absence of if-statements could possibly endanger the stability of your API or convolute the code which makes it up. Although API design is probably not being taught to introductory students and could be why the idea is seemingly so successful. When designing an API you want to make sure that the developer can avoid exceptional situations. In some situations if you didn’t have if statements, and you didn’t resort to a State Design Pattern implementation, you could throw an Error. However, Errors should be avoided at all costs.
Hi Mik Avila,
The idea of doing away with conditional statements is more a challenge to work out alternatives and delve into program structures than it is to weigh the merits of conventional programming practices. It certainly does not mean that decision-making and branching should not take place.
As for the State design pattern (and to some extent State Machines in general) when a current state is mapped out in a class, all one need do is to wait for a trigger to go to the next state. I agree with you that the State design pattern really brings out polymorphism, but polymorphism is not necessarily related to conditional statements.
Take a look at the new post on the Unconditional Contest to see some examples of alternative structures to conditional statements. See if you can come up with a set of statements that does the same thing as a conditional statement without using a conditional statement.
Bill
You say here … “I’m beginning to think that much better programs can be developed if conditionals are kept out.”, but what makes a program a “better program”? You are advocating the idea in your post and then suggesting it is a challenge in your reply. People who are learning Actionscript from your book come to this site to see the “right way” to code.
I wasn’t suggesting that polymorphism and conditionals are related, but I believe it to be true in one case. I stated my view on polymorphism as being a mechanism for defining multiple forms of a chunk of functionality. When using if-else and switch-case you are providing alternate behavior based on some state. In the case of polymorphism alternate behavior is also based on state. It is the idea of state which is different between the two. Conditionals use expressions which are evaluated to determine state and polymorphism uses objects.
Back to better programs. Given the example here http://www.as3dp.com/2007/12/31/unconditional-contest/ for me to understand this I first have to understand your intermediary language: black is success, red is failure, blue is error, and so on. This is cryptic and requires that I follow the code to see what color shows up where. An issue which can be solved using constants, but seems to defeat the purpose of using an object-oriented language in the first place. I know that this is only one example, but I feel that this will be the recurring theme.
You can find implementations of the various sort algorithms in prolog which doesn’t have conditionals and is also a language with a style reminiscent of what you are suggesting.
Hi Again Michael Avila,
Our book is not meant for learning ActionScript 3.0; so if you’re learning ActionScript for the first time, you’d be better served with a book that starts on a different level. I can recommend Colin Moock’s book Essential ActionScript 3.0 (O’Reilly, 2007).
As for the “right way to code,” I would say that Design Patterns, in general, are the right way to code in an OOP manner. The focus, for me at least, is how relations between classes and objects are rendered in a pattern, and the more you know about these relations and their consequences, the better.
As for doing away with conditionals, that is NOT a feature of design patterns. In fact in the Flyweight design pattern, the class diagram includes a conditional statement in the Flyweight Factory.
Rather, I’m asking readers to consider what is going on when a conditional statement is used. A conditional is a branch statement, sending the program to perform some kind of action depending on information evaluated by the conditional statement. At the most basic level, you have nothing more than a Boolean that either executes a statement or does nothing–a null result. So in fact it is NOT a matter of branching or not–or even making decisions–it is the manner in which it is done.
I’m as attached to conditional statements as much as the next guy, and it takes a lot more gray matter to come up with alternatives that branch without a conditional statement. Further, as you note, it’s probably a lot clearer to someone reading the code if more conventional methods are used. However, the purpose of substituting a non-conditional statements for branches is to streamline both the flow of the code and sustaining encapsulation.
In the most fundamental way, it has nothing to do with the State design pattern or even State machines, other than the fact that in the State DP, you see no conditional statements in moving from one state to another (in the trigger). Also, it is not linked to polymorphism–a concept in OOP that could possibly be linked to branching, but certainly is not a fundamental characteristic of polymorphism. In some respects, “there’s LESS than meets the eye” when it comes to polymorphism and non-conditional branching.
Finally, as for the examples in the Unconditional Contest being “cryptic” — well, I like to think of them as concrete examples for an “abstract” idea– that of branching without using conditional statement. The example using the “non-conditional switch” is a fully working example that provides an alternative to using the conditional switch statement. It simply shows an alternative to conditional statements.
The issue of conditionals came to my attention in a presentation on problem-solving in programming. The language was not ActionScript 3.0 (in fact I’m probably the only person at OOPSLA who had a presentation using AS 3.0), but that is not important. The solutions to the problems were far more resilient than those using conditionals. To me, that was both challenging and important.
Banning conditionals from programs altogether would be extremely difficult, and as Jonathan Kaye pointed out, verging on the absurd in the extreme in some cases. Rather, the exercise is one of seeking alternatives to conditional statements and seeing how creative we can be as programmers.
Bill
Are you even reading Mike’s posts?
Hi JY,
I’m reading them quite closely. What do you have in mind?
Bill
Hi.
First off, love the website! Now that that’s out of the way… :-D
I am all for new ideas and learning and implementing new, better, ways of doing things. I’m not convinced with this pattern though. I am intrigued, don’t get me wrong, but I would be willing to bet that you cannot write a piece of software that actually does something useful, without using a conditional statement. That means no:
* if, if..else statements
* for, for..in, for each..in loops
* while, do..while loops
* switch statements
Your example does work. And I agree with you in that that is the right way to accomplish what you were trying to accomplish with that program, but, let’s get real, that program doesn’t do anything. I’m quite interested in this pattern (and thank you for bringing it to my attention) because n levels of nested conditionals can get pretty nasty, but I’m having trouble picturing and larger large piece of software without using a conditional. I’d be interested to see what else you had in mind for this.
btw keep up the great work! thanks!
Ok, minus the loops :-D brain fart
Hi William,
I admit that broaching the issue turned out to be heuristic, and so naturally I’m glad I did. To do justice to the author of the idea whom I met at OOPSLA, I probably should have set it up more clearly. However, the State Design Pattern is characterized by the lack of conditional statements. Instead, by selecting a context, all of the outcomes are already determined and so you don’t need conditional statement.
After this exercise, though, I’ve got to admit that I’d be hard-pressed not to use conditional statements in most of the other design patterns. Chandima and I hope to continue pushing the envelope in this area, and everyone who’s got an idea or a comment is always welcomed here. In the meantime, I’m trying to find time to get the next design pattern done!
Take care,
Bill
How would you solve this without a switch?
Greetz Erik
Hi Erik,
Each case is a different class. As each class is called, all of the possible and/or correct conditions are put forth. It’s a lot more work, but it takes out the conditional switch statement.
Bill
Hi guys, interesting site, stuff. I’m new to ActionScript, but I once was a Smalltalk programmer, so of course I’ll claim you can do much programming (comfortably) without conditionals.
Smalltalk didn’t have conditionals (syntactically) – the effect was achieved with the behavior of Booleans and Blocks. I don’t think this is feasible in ActionScript because you can’t add the requisite behavior to all the booleans you’re likely to encounter (I don’t think). But ActionScript is so much more dynamically flexible than languages from which it inherited it’s syntax (C, Java), it supports a style of programming much less reliant on conditional syntax.
Which brings me to my favorite pattern, the most overlooked and fundamental pattern of all time: double dispatching. Double dispatching can be used to significantly reduce conditionals, often leads to “better” factored code (IMHO).
…Mike
Hi Mike,
Welcome to the discussion. Now I’ve got to admit that I don’t know jack about double dispatching, but I’m willing to learn. How about a piece of sample code in ActionScript 3.0 or a little app that uses it? Maybe even a little DP that shows what DD can do.
I found a clear description of double-dispatch on page 338 of the GoF’s book, Design Patterns, and right after the Mediator DP that I’m working on now, I’ll have a run at the Visitor pattern that uses double-dispatch. The Visitor patterns allows you to add operations (methods?) to classes without changing them. The executed operation depends on the kind of request and the types of two receivers. It sounds intriguing and as you said, negates the requirement for a conditional.
Naturally, if you’d like to show us how ActionScript 3.0 can be employed in a simple Visitor pattern; we’d be delighted!
Thanks a million,
Bill
Here’s the basic example ported from Dan Ingalls “A Simple Technique for Handling Multiple Polymorphism” paper at OOPSLA 86 (this is the first explanation of DD that I know of – the term “double dispatching” wasn’t in use back then – it’s a nice terse 3 page explanation that seems to be locked up in the
vaults of the ACM):
Likely implementors of IDisplayPort are screen objects, printers, bitmaps, graphic files, etc.
Now if you’re positive you need exactly 2 kinds of display ports and exactly 2 kinds of display objects, putting all the login in a single method with conditionals is easier. But if there are many kinds of display ports and many kinds of display objects, double dispatching makes it much more manageable. It resolves (without conditionals) one kind of display object paired with one kind of display port to a single method (er, function). This same technique can be extended to triple dispatching (and more).
…Mike
Hi Mike,
Are you going to OOPSLA in Nashville later this year? I hope to be able to have a presentation there in the same session I have for the last two years (Killer Apps). It would be great to see someone else using ActionScript there.
Did you do it with Flex or Flash?
Thanks,
Bill
I’m not going OOPSLA, I’ve been out of the programming business for a while now (although I’m getting back into it with Flash).
The code I posted is just pseudo-code (hopefully looks like AS) which was just a translation of Dan Ingall’s Smalltalk code snippets.
Let me just make another point about OOP and conditionals. An OOP program or system is a fundamentally little more than a bunch of conditionals. An object in a true OOP language, I’d argue, has 3 things: identity, instance data, and behavior. The behavior of an object is analogous to a big switch statement mapping method selectors (messsage names or method signatures) to actions. Given this, often a switch statement can be refactored into a message send and vice versa. (There are many factors that influence when this refactoring is a good idea and I’ll leave that to further discussion.)
…Mike
Mike,
Hey, pseudo-code is fine. It gets the idea across, and I really am planning on getting back to the dual dispatch concept written in AS 3.0 as soon as I can get the Mediator wrestled to the ground. I’m trying to work through how one abstract class can hold a reference to another abstract class/interface. If I can quickly get Dan’s code running in AS 3.0, I’ll do it. (Unless someone else would like a shot….)
Take care,
Bill