

The Only Sure Thing In Computer Science - mrbbk
http://michaelrbernste.in/2013/11/13/the-only-sure-thing-in-computer-science.html

======
protonfish
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'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...

To suggest "everything is a tradeoff" is a sort of moral relativism. It
implies that all code has value and is a shield for criticism to even the
poorest work.

~~~
Double_Cast
I don't think the intention was to imply "everything is equal". I think the
intention was closer to "everything has a cost" or "you can't simultaneously
optimize for everything". AKA the Project Management Triangle.

~~~
protonfish
I realize what they were trying to say and I agree with it; they just stated
it poorly. Is it that hard to not use the word "everything?" I suppose it does
not make as good of a headline. If you are going to give advice, you need to
consider how your advice can be misused. There exists techniques and
technologies that are measurably superior to others. Knowing how to recognize
them is a critical skill for a competent developer.

------
pflats
I'm being completely twitchy and pedantic and missing the point entirely but
I'm still compelled to say, as a Mathematics and Computer Science teacher:

Computer Science is a branch of mathematics. It consists of axiomatic systems.
There are many, many, many sure things in computer science.

~~~
JonnieCache
It might have been better phrased as "the only sure thing in software
engineering" but that doesn't sound as good.

~~~
pflats
Oh, I understand. I just have a personal quixotic crusade about the
distinction between the two. Computer programming and computer science are
parallel fields that complement each other. Too many students who want to
learn to program major in computer science, because nobody tells them what CS
actually is. IS or IT with a CS minor might suit them a lot more.

------
vesinisa
I don't understand this. Not everything is always a trade-off. Take array
sorting, a classical example. There are many stupid solutions that have _both_
unnecessary memory/time requirement and unnecessarily large code size and
method complexity. Such code can be always traded for a more efficient
solution "for free", at least before deployment.

~~~
jere
You're right in a way, but I was surprised by how even the worst algorithms
you learn in school have some properties that are better than the ones
considered the best (e.g. bubble vs quicksort, quicksort isn't stable). This
website makes it pretty clear: [http://www.sorting-
algorithms.com/](http://www.sorting-algorithms.com/)

To the larger point: everything is a tradeoff once we refuse to consider the
"stupid solutions." Yea, bogosort is absolutely stupid, but we don't really
think about it when seriously designing software. Instead, we're left with the
smart solutions, none of which can be considered optimal for all applications.

 _Everything is a tradeoff_ is a tautology. Because if one algorithm _was_
proven to completely dominate another algorithm, we would no longer seriously
consider the weak algorithm.

~~~
lucian1900
It's pretty easy to make quicksort stable. The more interesting comparison is
with insertion sort, which is often used for small arrays.

------
mathattack
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.

EDIT: Made microeconomics more explicit.

~~~
arethuza
"Should"? I'm slightly surprised that CS courses don't have at least an
introduction to hardware/low-level level design as a compulsory component.

Then again, I'm probably showing my age...

~~~
kandrea
I certainly would support both microeconomics and some form of introductory
systems course (low-level programming/architecture) for any CS program.

Unfortunately, the other end of this CS guarantee is that there are not enough
credit hours to provide a foundation that everyone would agree with.
University restrictions prevent 'high-unit' majors from exceeding the credit
hour requirement for a degree.

We just went through a long process that ultimately resulted in adding a
requirement for CS students to take a course which involves concurrent
programming. Unfortunately, this came at the cost of removing a requirement
for numerical analysis. Even with this update, you can still graduate without
ever hearing the term 'OSI Model' or ever being exposed to anything dealing
with the interwebs.

There are, however, amazingly good opportunities to expand the horizon outside
of the department that also nicely tie into general education requirements, if
students are made aware of them. In addition to economics, philosophy is
another rather nice area to take courses in. Our philosophy department has a
rather nice course in symbolic logic.

It's all about the tradeoffs though.

~~~
eloff
I did all kinds of crap related to physics, chemistry, calculus, and the arts.
I'd much rather have done those kinds of courses than the (almost completely)
useless things. There is definitely credit room, just a wrong focus. Also
being able to skip early level courses for more advanced ones would have been
nice (I challenged a few anyway, but they were expensive and still consumed
some time.) Then maybe I would have enjoyed CS and not dropped out.

~~~
kandrea
This is another one of those interesting areas to explore in CS education that
comes up a lot in conversation. Of course, there is no one path for everyone
and there are many people who would thrive and reach greater levels of
proficiency and success outside of this sort of environment.

For my bit, I received a 2-year degree in a programming-centric degree program
(systems programming) and my 4-year degree in a CS-focused degree program,
which placed a much heavier emphasis on theory and models. Coming from my
first college, I was upset over having to 'repeat' a lot of subject areas,
only to find out that under a different focus these courses offered a better
perspective over areas I was missing understanding in.

Looking at the two years I worked as a TA and the time I have spent assisting
in an applied programming student organization, I've come across many students
who have complained about not being able to skip ahead to the more advanced
materials. Several complain vociferously about having to take the theory and
logic courses. Others complain about the course in low-level programming (C --
which is not even low-level) or systems programming. Most of the time that
I've seen, this is a result of simply not understanding the concepts as result
of a lack of foundational knowledge. Mathematics is an area continually
complained about amongst the newer students as a requirement for
'programming'.

I've worked with students who wanted to push straight to the senior-level
courses while having no real understanding of basic data structures,
fundamental algorithms, core programming structure concepts (ie. have never
learned/used recursion), or even had any exposure to taking the time to
structure their thoughts before diving into the code.

I've always been more of the 'renaissance man' when it comes to education, but
I've learned to appreciate and I do support the balancing that universities
engage in, in order to provide a core CS framework for their degree programs.
University degrees should not be able gaining the information needed to go out
and program, but should be focused more on these topics involving theory and
the mathematical underpinnings of the field. This should involve some levels
of useless, pedantic academia.

While we do not offer the ability to challenge courses in this department, one
area I do highly push students to get involved in is laboratory research with
professors. We had two undergrads with no prior systems education build and
write the drivers for custom robots recently, after they came in looking to
get involved in such a project. Many professors, in my limited experience, are
eager to see students who are looking for additional challenges in their
studies and are only too happy to provide additional experience in desired
areas for them.

------
16s
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.

Really, a CS education is just preparing you to pick the right solution for
the problem/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.

~~~
aegiso
A self-reminder I use to stay humble: If X really is so perfect, I better
start looking for a new job because I'm no longer required.

We need look no further than the existence of the programming profession to
see that there ain't no such thing as a free lunch.

------
kunwoo
The quote actually does not appear in Concepts, Techniques, and Models of
Computer Programming but is Bernstein'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/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.

CTMCP is the bible for Oz. But it'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.

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'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.

(CTMCP actually goes further and classifies the programming paradigms into an
elaborate branching hierarchy, as can be seen here
[http://www.info.ucl.ac.be/~pvr/paradigmsDIAGRAMeng108.pdf](http://www.info.ucl.ac.be/~pvr/paradigmsDIAGRAMeng108.pdf))

------
sgarlatm
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't involve any tradeoffs.

~~~
RogerL
length of name vs completeness capturing scope vs ignoring it (foo.foo_thing
vs foo.thing) capturing type vs ignoring it (studentList vs students)

and so on. I often struggle with competing desires in naming. _Code Complete_
dedicates an entire chapter to variable naming.

~~~
crpatino
In the same vein, length of name vs abundance of other candidate tokens of the
same length. By example, in C language, there are only 52 possible one-
character names (26 if you stick to the convention of using only lower case
characters), 52 _63 two-character names, 52_ 63^2 three-character names, etc,
etc.

It follows that shorter names should be reserved for more restricted scopes
where additional context is available. i.e. the use of "i" and "j" as a
conventional names for counters, "x" and "y" for arithmetic operands, and "N"
for the number of elements in a collection is a good thing. On the other hand,
the use of terse names like "atoi" in standard library is terrible, because
its scope is in all existing programs (or at least in all C modules that
directly or indirectly include stdlib.h

------
absplyt
And here I thought that the only sure thing in computer science was that all
problems can be solved by another level of indirection:
[http://en.wikipedia.org/wiki/Fundamental_theorem_of_software...](http://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering)

~~~
john_b
Except throughput of course.

------
Derbasti
However, keep in mind that it is only a tradeoff if you tried _at least_ two
things. Otherwise it's just random choice.

~~~
marcosdumay
You don't need to try things to make a choice. That's why we have theory.

------
tlarkworthy
Its easy to think of programs as existing in the unbounded abstract, but as
soon as you run them, you'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.

finite resources implies tradeoffs

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

------
endophage
I disagree that there is only one sure thing, it is also certain that:

A or not A

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

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

------
lindowe
Economics got there first.

