
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 6 Sep 2011, at 10:24, Joe Armstrong wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Programming *is* the art of understanding a problem - once you have<br>complete understood the problem<br>the program is in a sense "written" (at least in your head) - it<br>remains to type it into the machine.<br>Thus when the problem is not solved you will often not know what to do.</span></blockquote><br></div><div>I completely agree. This also leads into the domain of "accidental complexity", where the answer to why you don't know what to do in a particular spot in your code, may well be that you shouldn't ever get there in the first place. The solution then could be to choose a simpler (or more adequate) overall approach.</div><div><br></div><div>This is very easy to fall into in concurrency programming, and I have given some examples, e.g. in my EUC 2005 talk [1], and later in the Death by Accidental Complexity talk [2]. This comment is an example similar to Joe's, but where the authors eventually figured out what to do - even if it was a "false answer":</div><div><br></div><div>%% Getting a ReleasePath when pending a Notify Released event is a bit<br>%% complicated. We need to check for which path the ReleasePath is for and<br>%% for which path the notify is for. If they are for different paths we are<br>%% in a dilemma since we only can be in pending for one of them. As a simple<br>%% way out we just treat this as an abnormal release for now.</div><div><… code …></div><div><br></div><div>The "can only be in pending for one of them" was, AFAIK, an consequence of the implementation, and not of the problem itself. The code in question was later rewritten and _much_ simplified - to the point where it could even be understood by more than one person...</div><div><br></div><div>[1] <a href="http://www.erlang.org/euc/05/1500Wiger.ppt">http://www.erlang.org/euc/05/1500Wiger.ppt</a></div><div>[2] <a href="http://www.infoq.com/presentations/Death-by-Accidental-Complexity">http://www.infoq.com/presentations/Death-by-Accidental-Complexity</a></div><div><br></div><div>BR,</div><div>Ulf W</div><br><div>

<div>Ulf Wiger, CTO, Erlang Solutions, Ltd.</div><div><a href="http://erlang-solutions.com">http://erlang-solutions.com</a></div><div><br></div><br class="Apple-interchange-newline">

</div>

<br></body></html>