The Only Sure Thing In Computer Science

Maybe this is true in the ivory pillars of academia, but in the real world a large amount of technology is simply worthless - the world would be a better place if it didn&#x27;t exist: Dead code that was never cleaned up, encapsulations of encapsulations of encapsulations, code that solves nothing but to express the astronaut architecture of a dogmatic developer, code based on poorly communicated specifications, code that has so many bugs as to consider it worthless...<p>To suggest &quot;everything is a tradeoff&quot; is a sort of moral relativism. It implies that all code has value and is a shield for criticism to even the poorest work.

I&#x27;m being completely twitchy and pedantic and missing the point entirely but I&#x27;m still compelled to say, as a Mathematics and Computer Science teacher:<p>Computer Science is a branch of mathematics. It consists of axiomatic systems. There are many, many, many sure things in computer science.

I don&#x27;t understand this. Not everything is always a trade-off. Take array sorting, a classical example. There are many stupid solutions that have <i>both</i> unnecessary memory&#x2F;time requirement and unnecessarily large code size and method complexity. Such code can be always traded for a more efficient solution &quot;for free&quot;, at least before deployment.

The grad assistant in my computer structures (programming hardware in assembler) class suggested that every CS student should take a semester of microeconomics to understand trade-offs. He was right.<p>EDIT: Made microeconomics more explicit.

Very well said. There is no one perfect programming language, no one perfect algorithm and no one perfect data structure for all problems and constraints you will face as a CS practitioner.<p>Really, a CS education is just preparing you to pick the right solution for the problem&#x2F;constraints at hand. For example, you can loop through a list. That approach works fine. However, when you begin to scale, you may find that look-ups against a tree-based data structure or perhaps a hash table are much more time efficient at the cost of more complexity, more space and more educated programmers.

The quote actually does not appear in Concepts, Techniques, and Models of Computer Programming but is Bernstein&#x27;s summary of the work. Although it is an appropriate summary, it can easily be taken out of context. Van Roy and Haridi, authors of CTMCP, were mainly concerned with the trade-offs of programming paradigms. They observed that functional languages, like Haskell, and object-oriented&#x2F;shared-state-concurrency languages, like Java, sit at opposite ends of a continuum. The functional paradigm is very easy to formally reason with, but can be very kludgy when expressing certain real world concepts, like state. The OO paradigm and the shared-state concurrency paradigm, on the other hand, are very powerful and expressive, but can be quite a pain to reason over. Van Roy and Haridi believed that programmers, rather than having to make a boolean decision between the two, should be allowed to work anywhere on the continuum, and they designed the Oz programming language to make that easy to do.<p>CTMCP is the bible for Oz. But it&#x27;s more than just a language reference book. It is an exploration of this trade-off between language expressiveness and ease of comprehension. CTMCP outlines how programming concepts can be layered to form gradual steps between functional and OO languages by controlling the use of mutable state. The Oz language like Haskell, starts in a functional paradigm and makes the use of state explicit, but unlike Haskell it also tries to make the use of state easy and intuitive, rather than overly verbose. CTMCP advocates an avoidance of using a single paradigm to solve all problems.<p>Oz also has concurrency built in natively, and one of the overarching themes of CTMCP is that the use of concurrency greatly benefits from an understanding of this trade-off between expressiveness and ease of comprehension. Concurrency doesn&#x27;t have to be difficult, and in the case of functional languages (think dataflow concurrency, as seen in Unix pipes) can be quite easy to use and comprehend. CTMCP posits that as one moves from functional to OO, concurrency analogously becomes both more expressive and more difficult to formally reason over. The use of concurrency therefore can become more tractable when programmers are made more aware of these trade-offs.<p>(CTMCP actually goes further and classifies the programming paradigms into an elaborate branching hierarchy, as can be seen here <a href="http://www.info.ucl.ac.be/~pvr/paradigmsDIAGRAMeng108.pdf" rel="nofollow">http:&#x2F;&#x2F;www.info.ucl.ac.be&#x2F;~pvr&#x2F;paradigmsDIAGRAMeng108.pdf</a>)

As usual, silly little phrases like this are just silly. Lots of things are tradeoffs, but not everything. For example, picking good variable names doesn&#x27;t involve any tradeoffs.

And here I thought that the only sure thing in computer science was that all problems can be solved by another level of indirection: <a href="http://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Fundamental_theorem_of_software...</a>

However, keep in mind that it is only a tradeoff if you tried <i>at least</i> two things. Otherwise it&#x27;s just random choice.

Its easy to think of programs as existing in the unbounded abstract, but as soon as you run them, you&#x27;ll find the logic fragments are competing for physical representational resources (bits in RAM, CPU cycles etc.). So having feature X does cost feature Y for a fixed CPU and RAM budget.<p>finite resources implies tradeoffs

The Only Sure Thing In Software Development: Never Underestimate the Incompetence of the End User

I disagree that there is only one sure thing, it is also certain that:<p>A or not A

As an econ nerd turned programmer, this is why I feel right at home.

true for all branches of engineering. pretty much holds for all of life.

Economics got there first.