<font face="courier new,monospace"><br></font><br><div class="gmail_quote">On Mon, Jun 4, 2012 at 10:48 AM, <span dir="ltr"><<a href="mailto:arocker@vex.net" target="_blank">arocker@vex.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
At the last TPM meeting, I raised the question of complexity in<br>
programming, and how to classify it.<br></blockquote><div><br>... snip ...<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The question is, what is a reasonable hierarchy of complexity in computer<br>
programming? (I hope the concept of "complexity" is fairly obvious in the<br>
context; if not, we'll have to define that first.<br></blockquote><div><br>To me complexity of streams and structured and unstructured data<br>really don't change the thought process; they are all basically the<br>
low-level, process, type of thinking.<br><br>In other words, most algorithms (once understood) are SMOP<br>('Simple Matter Of Programming')<br><br>To me, the next level up is dealing with concurrency, parallelism,<br>
and time-synchronism.<br>Things like handling the same 'kind' of requests at the same time,<br>considering that some requests might be quick and others slow<br>so you don't want the slow ones delaying the quick ones.<br>
... and the associated handling of the logical interlocks and<br>'synchronous' access to any data (structures) that the application<br>may have to maintain internally (... given your programming language).<br><br>
After that you get into the domain-specific functions/algorithms<br>which is a separate issue that may or may not have 'complexity'.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Am I shouting into the void, or has anyone else any views on these points,<br>
"what is complexity and what language features become relevant, where?"<br></blockquote></div><br>With respect to those issues above, my problems these days revolve around:<br>"I know what I need to accomplish... but,<br>
how do I accomplish it in 'this' language?<br><br>--------<br><br>Another issue is 'handling errors'.<br><br>I'm not talking about 'catching exceptions' or listening to return values<br>or errno; but what stupid things can your user's do (in either input or<br>
'sequencing') that can cause your app to miss states, or wander<br>through informational states that you never thought of in advance<br>(ie. _ALL_ of the boundary conditions). You know...<br>"I've fixed all the 'known' bugs"... but what about the 'unknown' bugs'?<br>
or<br>"I've made it idiot-proof"... but the world invents a bigger idiot!<br><br>Fulko<br><br>