Those who claim there is "one true way" have a greater burden of proof than those who claim a personal preference to a technique. This is because the scope of the claim of the first is much greater than the second. I created this topic because the issue keeps coming up. Thus, I wish to factor it to one spot. --top ''Absolutism is not about "one true ways", it's about "truth", starting with 'true and false are distinct and not equal to one another'.'' In this context, it is about proving that software principles and related tools and techniques are "objectively better". ''TopMind once again stands proudly upon his white horse and commands all to speak HIS version of the English language. (...) or is it HumptyDumpty on the wall?'' Do you have a specific complaint? Otherwise, stop filling up wiki with vague dangling personal digs like a 7-year-old tagger on crack. ''It would take a blind man not to see the specific complaint listed just three sentences above, and then see TopMind redefining language to his preference one sentence below that. Top will stop receiving personal digs when he stops earning them.'' Other readers may not want to see your spanking sessions scattered all about this wiki. Don't make them suffer for my (alleged) sins. It's rude to them also. You are not mature and patient enough to be the punishment giver anyhow ------ '''Absolutism Challenge''' (''that isn't really about absolutism'') ''I've never seen an objective proof that ''any'' software engineering technique is "better" than another. All past attempts eventually boil down to psychology (AllHolyWarsTiedToPsychology). '''I challenge anybody to point out such proof.''' '' It is undeniable that '''''some'' software designs and languages are objectively worse or no better at ''ALL'' of software properties that one might reasonably deem "good"''' than are certain other software designs and languages. Trivially, one can intentionally design a language that is intended to have poor performance, to make expression of any concept non-trivial to the programmer, to compound and exaggerate errors, to introduce errors ''artificially'' and ''pseudorandomly'' (maybe based on the phase of the moon), to make security or performance or correctness guarantees impossible, et cetera. ''(And that language is called "Java". Sorry, carry on.)'' And some people ''have'' designed such languages and frameworks, often for the fun of it. One can also intentionally solve every single problem in the most bass-ackwards way their imagination can devise - and some people do so on a regular basis - see WorseThanFailure and such constructs as: return (test == true)? ( (test == false)? false : true) : ((test == false) ? false : true); // which can be reduced to 'return test;' It is languages and designs and software snippets such as these that '''prove''' that some software engineering techniques are '''objectively better''' than others, and thus '''disprove any naive insistence or belief to the contrary'''. Sure, it's silly, but it is also '''sufficient'''. One could, of course, come up with a ridiculously twisted set of values such that "security is bad! it means I can't install a backdoor or scam money!" and "readability is awful! it harms job security!". While I admit to finding such statements entertaining, they aren't really serious attacks against the fact that some language/framework/architecture/software designs are objectively, by all reasonable measures, strictly worse or no better than others. ''When I forgot my password when I'm in a critical hurry, security certainly feels "bad" at that moment. Needless to say, every feature or technique has it's trade-offs.'' Actually, I think you need to both 'say' "every feature or technique has its trade-offs", '''and then you need to prove it.''' That was, after all, a very absolute statement you just made - one that must have greater burden of proof. What, pray tell, are the trade-offs of exchanging 'return (test == true)? ((test == false)?false : true) : ((test == false) ? false : true)' technique for the 'return test' technique? Are you going to argue that you're trading-off confusion for clarity? inefficiency for speed? what? ''Lack of trade-offs is not the default if I fail to provide proof of tradeoffs. "Unknown" or "null" is the default.'' ---------------- ''Barne of C++ fame says almost this very statement (regarding readability) that C++ was invented for genius/experts only, and that the entire purpose of C++ was to weed out any programmers (re: jobs etc.) who couldn't understand its syntax, notation, pointers, etc. The exact quote, is.. "insert_here"'' * [Do you have a source for that? The usual Bjarne quote about C++'s intent is "C++ was designed to provide Simula's facilities for program organization together with C's efficiency and flexibility for systems programming." (See http://www.research.att.com/~bs/hopl-almost-final.pdf) I see nothing in there about making C++ to ensure job security. Indeed, Stroustrup has been rather vocal about wanting to make C++ or C++0x more accessible to novices.] * ''And then there is:'' Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity. -- ''http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html'' ** [Which is, of course, a joke. Stroustrup gave no such interview. Nobody would take it seriously, would they??? (I know, I know, they probably would.)] ** {If you actually read the whole page with the hindsight available today... It is, of course, true that Stroustrup said none of those things, but I can't help but look at it with the feeling 'HaHaOnlySerious'.} ** [Has anyone noticed that "C++0x" looks like an AsciiArt drawing of a dead fish?] But there is still no consensus objective way to measure such. A really smart person may get the hang of just about any language anyone could invent and be as productive as the average Java or PHP programmer. We can take a vote, but that only measures subjective preference. {On 'readability', indeed, there is little consensus on a proper way to measure it. Part of the problem is that there is no clean laboratory setting - no matter what language you design, potential users of the language will be influenced by the languages they already know - we'll probably need to develop 'artificial' language-learning agents with scalable but objectively measurable levels of 'intelligence' before there is a fair test that can be applied to any language. That said, I think inventing a language for genius/experts only is a wholly stupid idea. The more people that can effectively, and correctly, do programming, the faster innovation will occur and the more grunt work can be handed off to people who aren't willing to dedicate the effort necessary to be creative (since creativity is, in both my experience and that of Edison, 99% perspiration).} --------------- Some '''objective''' properties that are generally considered good: * Machine Performance (Lag, Computation Rate, Space, Utilization, Efficiency, Scalability) * Performance Guarantees (RealTime guarantees, space guarantees, efficiency guarantees) * Reflection (logging, error messages, runtime hooks, debugging) * Correctness (meeting service contract obligations, proper abandonment of resources, safety - no undefined actions, procedural constraint - no 'wrong' actions or steps (e.g. database consistent between each transaction)) * Correctness Guarantees (automated, enforced guarantees of correctness that are worthy of trust; includes language-implemented StrongTyping) * Expression (Semantic Noise - concept mismatch between programmer and computer due to limited expressive power (e.g. integers wrap around; no direct way to express 'foreach' in C; etc.) * Syntactic Noise - stuff on the page that doesn't match any concept (e.g. semicolons at end of expressions) * Bandwidth (degree to which a large concept-space can be expressed in a small syntactic volume) * Parseability (ChomskyHierarchy; degree to which an advanced machine is required to parse the language) * Portability (ability to move code across different machines and platforms; is often subject to both language and design choices) * Mutability (degree to which a small change in functionality requires an equivalently small change in the source - affected by CouplingAndCohesion) * Security (ability to resist DenialOfService, ability to resist granting service to those not authorized, ability to ensure privacy constraints are met, ability to detect and retaliate to security threats (active security)) * Survivability (robustness (ability to resist excessive damage when an unauthorized capability is achieved, a programmer fault occurs, a user fault occurs) * Resilience (ability to recover from certain forms of damage after a fault or loss) * Graceful Degradation (ability to provide services under compromised conditions) * Delay and Disruption Tolerance (forms of graceful degradation; ability to provide service in partially connected networks and spuriously connected networks)) * Accessibility (degree to which software service is available globally - e.g. limited if you must be sitting at a particular machine, and very wide if service is available on phones, on the net, to the disabled, etc.) * Runtime Extensibility (ability to extend the functionality of the system without stopping it; also 'scriptability') Note that some of those objective properties are easiest to measure in comparison to another implementation as opposed to on some absolute scale. They are no less objective for this. Some '''subjective''' but statistically measurable properties that are considered good: * Readability (ease with which a skilled programmer inexperienced with the code can comprehend and predict its consequences, and possibly its intended consequences) * Fun (inverse of degree to which programming in system is a chore; not well defined, but see BondageAndDisciplineLanguages). --------------- Possible Exceptions and caveats include: * Machine performance: ** Very easy to over-optimize for at the expense of other criteria (security, correctness, expressiveness, fault tolerance, etc.); over-optimizing for performance is a historically common mistake. ** Imperative in some domains (especially embedded systems); probably less valuable than long-term maintainability in most domains. ** Efficiency, utilization, scalability, lag time, response rate, etc. are reasonable metrics to consider. ** Machine performance ''guarantees'', such as hard RealTime or strict finite-space requirements for embedded are sometimes necessary. ** All other things being equal, a design or technique that gives better performance is objectively better. ** All other things being equal, a language or framework that allows one to effectively describe and enforce performance guarantees is objectively better to another that doesn't -- it can be used in a wider range of domains. * LinesOfCode: ** All other things being equal, ''fewer'' lines of code is better: each line is a possibility for another bug. ** LOC is about as accurate and useful as GDP -- it's never more than an approximation. There are more ways to measure code volume, and LOC should not be used on its own. ** Asymptotic code volume: E.g. UnLambdaLanguage requires exponentially more code than LambdaCalculus to express certain identical concepts. * Stated assumptions about human psychology (Ex: "based on psychology assumption X, people will read Y easier...") ** Would '''statistical facts''' about human psychology count (e.g. that people can only recall 5-9 things mentally, that people can't track what is happening in functions much longer than a page, etc.)? And what about the simple observation that people are imperfect and make errors? E.g. statistical analysis of typographical errors? ** ''Interesting question. How about we save those for last. One problem is that no given individual may fit a given statistical profile. A technique that bothers Bill may not bother Lisa, etc.'' * Definitions - this is not about definitions, but practical benefits Even GoTo's have not found objective evidence again them (something that almost nobody supports anymore). The best arguments are still tied to psychology assumptions. If we cannot do it for GoTo's, then how is anybody going to succeed with other HolyWar topics such as typing, OOP, and relational normalization degree? ''See a GoodUseOfGoto'' The "predominant style" is nested blocks these days. Whether a sprinkling of Go To's or Go-To-like idioms are acceptable or not is mostly a side detail. But structured blocks grew in popularity mostly by ArgumentFromVotes, not objective proof. ''Do you have any objective proof that structured blocks grew due to argument from votes? The relational model grew because of ArgumentFromAuthority (Ed Codd was the authority on the subject) which was a good thing. I think structured programming also grew because of authority; people listened to the experts on the subject. It grew because of logical reasoning more so than authority or votes, though.'' ------ Some claim that the evidence is in academic papers or books. If you believe such, then please supply the following: * Source: book/publication title, date, author, etc. * Page numbers where the proof is found * Page numbers where what is being compared is found * Page number(s) where it's clearly stated that item in question is indeed a proof rather than some conceptual "noodling around". ---------------- ''The one true way might not be something we can follow word for word exactly, but having a guideline and point of reference is important. Just as math exists as a good guideline, so that when we add one plus one together.. we get two. It is a guideline, and a good one. If we have other people adding one and one to get five, then our guideline is f**kered and we have to do something about it - create standards, articles, guidelines, education, etc. As something such as normalization is a good guideline to follow - just as one plus one is a good guideline to follow - how can one claim that having a personal preference that one plus one is five is more worthy of respect and proof?'' We can empirically test arithmetic by counting items such as pebbles. Balancing our checkbooks is another such empirical test. ''Not if the person psychologically doesn't enjoy counting pebbles, and if he psychologically thinks 1+1=5, he may have a valid psychiatric problem. If he wants to think that 1+1=5 and that fits his psychology, why not let him? EverythingIsRelative so to him the number 5 could be the number 2.'' You are over-focusing on EverythingIsRelative. I've found it better to '''find a common ground''' between parties and work up from there. There is no use in arguing about whether a chair exists (common exercise in Philosophy 101) if both parties agree it exists for a sake of a common issue between them. Call it "local absolutism" or "working absolutism": these are the givens we both agree on. As far as this wiki, somebody with too many "unpopular" givens (base assumptions) that they cannot reasonably justify as deserving consideration is probably going to be ignored, regardless of whether they are "right". For example, most people these days prefer blocks over goto's and there is little incentive for anyone to "prove" blocks are better. Thus, as a practical issue, it's usually moot. It's only an issue in an academic kind of setting or people studying or interested in evidence presentation techniques. And some WikiZens are indeed interested in such subjects. ''There was incentive decades ago to prove structured programming is better, which is not just blocks but a whole branch of programming technique like the relational model. There was incentive decades ago to prove relational was better too. People listened, and understood the logical superiority - whereas you claim there isn't any logical superiority and it is just a matter of psychology.'' * I've asked you to provide a summary and a link to one of the better such papers somewhere around this wiki. * ''http://dl.acm.org/citation.cfm?doid=362929.362947'' * ''http://delivery.acm.org/10.1145/990000/987370/p54-leavenworth.pdf'' * Sorry, I'm not going to fork over money to ACM. I have kids to put thru college. And it's my understanding that the controversy over the Goto article's objectivity is something that pushed them to focus on hardware and performance metrics and unique specialized algorithms instead of software idea comparisons. ACM realized early that programming is in the head and shifted their focus to avoid the head because they wanted "clean" papers, and psychology is a murky science. Programming is about '''communicating to the human mind''' first, and to computers second. You can't hide from WetWare issues if you want useful software productivity metrics. Accept this and you will be liberated. * [As far as the money goes, I'm sorry but that's not our problem. You asked for a link, and you got two of them. The rest of your response smacks of a ConspiracyTheory. Do you have '''any''' evidence for any of that?] * If you give me money, I'll give you the source. My fee is coincidentally the same as ACM's. * [Since I can go to their website and find multiple journals devoted to topics you claim they avoid, I think that money would be better spent elsewhere.] * {''You say that programming is about communicating to the human mind, and computers are second. This is hilarious because that's exactly why GoTo isn't good - GoTo is perfect for computers to understand - a software program compiles into basically a bunch of GoTo's. It's for the computer. For a human to logically reason about a program he needs something higher level than a GoTo. There is a reason that math didn't use GoTo and instead used lists of equations going down the blackboard one by one in order. Introduce GoTo statements into a math class and your math problem becomes much harder to prove than if you had avoided GoTo.''} * So the "goto's are bad" argument model ''does'' assume something about the human thought process? Math indeed was designed to communicate with humans (both the author and other human beings). In other words, WetWare influenced its design. However, although I may informally agree with most premises about human thought processes, it still should be empirically tested to claim it's The Truth in the absolute sense. My head may not match your head, etc. Some of the goto experts seemed to use pattern recognition also, not just up-and-down logic. And aliens from Zolob may have a very different brain from humans such that they relate to something completely foreign to us. * [No, it depends on correct reasoning, which is a different thing (than a model of human thought processes) entirely.] * Correct reasoning by ''what''? Please clarify. Humans reading blocks and goto's is the primary issue. Humans do the "reasoning" and/or pattern recognition that "processes" gotos/blocks. That's the "system" to be optimized. (It's not even clear if pattern recognition is "reasoning", at least not in a rigorous sense.) '''Human mental processes are the bottleneck and it's rational to try to optimize the bottlenecks first'''. We are not trying to optimize primarily math, we are not trying to optimize primarily machines, we are trying to optimize the processing in programmers' heads. See GotoBlackBoxThoughtExperiment. If you truly think your reasoning is solid, universal, and correct logic, then please formalize it some more with numbered clauses, etc. so the steps/components and their relationship to each other is clear to all. Goto's are an interesting case study in that almost everyone agrees that "blocks won" (for the most part), yet an objective proof remains elusive. Thus, if we can't do it for the "obvious" winners, then how do we do it for more contentious superiority claims? -t ---- MarchTwelve