
The Two Things about Computer Programming - avk
http://fishbowl.pastiche.org/2007/04/15/the_two_things_about_computer_programming/
======
petercooper
_The computer will always do exactly what you tell it to._

With the obligatory footnote: "Unless you get into multithreading - then all
bets are off." ;-)

~~~
j_baker
Even if you multithread, it will still do exactly what you tell it to. It's
just that it becomes even easier to tell it the wrong thing. ;-)

~~~
KeithMajhor
Multithreading sacrifices determinism. So, regardless of what you tell it you
can't make any claims of exactness about what it's doing.

~~~
extension
The computer is still deterministic, but somebody lower in the technology
stack doesn't want to completely define its behavior.

~~~
KeithMajhor
You're right.

However, from the perspective of the programmer it is non-deterministic. It
only becomes deterministic when it is coupled with a particular scheduler and
dispatcher. Most programmers strive to write cross platform code.

~~~
nikster
If it's non-deterministic, you're not doing it right.

~~~
KeithMajhor
That's false. If you're doing it "right" then it will produce the same
functional output for all of the possible execution paths. That doesn't make
it deterministic.

------
meese_
"There are only two hard problems in Computer Science: cache invalidation and
naming things." - Phil Karlton

~~~
michael_dorfman
"There are only two hard problems in Computer Science: cache invalidation,
naming things, and off-by-one errors."

------
mathgladiator
Computer Science =

    
    
      1. How to represent data
    
      2. How to transform representations

~~~
Groxx

      3. ...
      
      4. PROFIT!

------
extension
1\. Nobody really knows how to do it

2\. If you think you have a reliable system for doing it, you're probably
doing the computer's job

------
philwelch
This is fortuitous, because just this week I started realizing there are Two
Things about AI:

1\. Graph search

2\. Representing problems as graph search

~~~
klochner
For (2) I'd try to work in:

    
    
      - multi-agent systems
      - knowledge representation/reasoning
      - machine learning
      - CSPs
    

"Learning" probably captures the bulk of it.

~~~
philwelch
Knowledge representation--depends on which kind. The kind that involves logic
and resolution turns out to be just another problem that you have to represent
as graph search.

~~~
_delirium
On the low, algorithmic level that's often true, but a lot of the difficulty
imo is at higher levels of the stack. We're very good at writing SAT-solvers,
for example, but directly writing problems as SAT is not a particularly good
knowledge representation, especially if you want to build systems that are
flexible and can interact with humans.

So a lot of the interesting work (imo) is on non-graph knowledge
representations, like answer-set programming, situation calculus, etc. They
often ground out in some variety of graph search to do the inference, but
that's just the solver algorithm, not where the research that interests me is
at. It's like saying that graph search grounds out in x86 asm twiddling bits
in a computer, so all AI is just bits in a computer, which is also true but
misses the point.

Though it does remind me that there was a comment from someone in the 60s or
70s amounting to, "all AI boils down to heuristic search".

------
ericflo
> Make it work, then make it elegant, then make it fast.

I usually find that making it fast makes it inelegant.

~~~
pquerna
Making it 'raw fast' is what compilers/JITs are for.

You still need to pick the right algorithms, but I've personally been really
focusing on elegancy. Maintenance and Operation of code is the major costs of
software, not writing new stuff -- so when you write new stuff, I believe that
decreasing those other costs should be the first priority.

~~~
j_baker
I think you mean "elegance". ;-)

That said, I agree with you. Most of the time, the elegant solution is fast or
can be made fast.

~~~
davvid
I agree completely. A common mistake is thinking that performance can be
tacked-on later. Thinking about performance up-front can inform elegant
designs.

'git' is a good example of this.

~~~
InclinedPlane
Targeted performance improvements tend to make specific operations more
efficient. Elegant architectures tend to completely eliminate huge swaths of
duplicate and unnecessary operations, and so typically have the opportunity
for much greater performance improvements.

------
limist
Closely related to the first Thing of problem reductionism: "All problems in
computer science can be solved by another level of indirection... Except for
the problem of too many layers of indirection." — David Wheeler

------
vb6
1: You love it, 2: You hate it.

------
biotech
The two things about software engineering:

1\. You have to figure out what you need to build.

2\. Engineer the solution in such a way that changes in the requirements
result in relatively minor changes to the code.

~~~
mirkules
This reminds me of the tree swing:
[http://blog.thingsdesigner.com/uploads/id/tree_swing_develop...](http://blog.thingsdesigner.com/uploads/id/tree_swing_development_requirements.jpg)

------
bluesmoon
_Every problem can be solved by breaking it up into a series of smaller
problems._

A good ballpark, but not entirely true. At some point you'll end up with a
smaller problem that cannot be broken up further. For the most part these may
be solved problems, like `increment foo`, but at some point you might hit an
unsolved atomic level problem that you either need to spend a lot of time
working on, or forces you to find an alternative path.

~~~
leif
When you hit a problem like that, it's time to start going in the other
direction. _All problems in computer science can be solved by another level of
indirection._

~~~
eru
Please solve the halting problem with indirection. Thanks!

~~~
Dylan16807
Sure! Here's your wrapper that abstracts the concept of processes and never
says 'done'.

~~~
eru
Some computations (and most computations of practical importance) do halt
eventually.

~~~
Dylan16807
Doesn't matter, it's indirected away. All you know is that you were done
asking it for data.

~~~
eru
I don't get it.

~~~
Dylan16807
You have a program. It has input and output, and is either running or done.
With abstraction, you can have a view of the program that is just a
bidirectional data pipe. You give it information, you request information
back. At some point you're done talking to it and drop the reference. The
entire idea of 'halting' is gone.

~~~
eru
No, that doesn't work, because programs in general don't give one output bit
per input bit, and they can also take a very long time to come up with their
answer.

E.g. input stream: stream of description of Turing machines and their input
tape. Output stream: A stream of booleans that are true iff the respective
machine holds.

~~~
Dylan16807
I guess I should have addressed that idea specifically. If you transfer total
control to a subprogram that directly looks for halting, you've just moved the
problem, you haven't really abstracted it.

Apply indirection to anything with unspecified runtime. When you need a
result, put a reasonable waiting time on it, and if it doesn't happen assume
the source has died and handle it as an error code.

------
ColinDabritz
1\. Solving the right problem

2\. Managing Expectations

~~~
KeithMajhor
That's beautiful. However, programming is only one of many fields for which
you could apply those "two things".

~~~
ColinDabritz
Interesting. So perhaps we're talking about the 'two things' that are specific
to software development. Maybe it's worth considering the rest of the
different 'two things' that apply more generally as well?

------
gfodor
1\. You're assuming things that you've not verified.

2\. You've overlooked or ignored things that need to be considered.

Pretty much sums up the source of all pain in day-to-day programming.

------
edw519
1 and 0

~~~
hxa7241
You left out the set-up line: "Fundamentally, there are 10 things about
software:"

------
rarestblog
I'd change second thing about Computer Programming to: "Something ALWAYS goes
wrong and your job is to fix it"

------
flgb
The two things in computer programming are automation and abstraction. That is
all.

------
chrismealy
The two things economists know are hilarious -- square "no free lunch" with
"gains from trade." Do the gains from trade have a price? Who pays that?

As for "incentives matter," what, because incentives incentivize?

~~~
duncanj
I feel like the two things economists need to know are:

1\. You don't know what you're talking about.

2\. You don't know it yet.

------
techbio
1\. Defining problem space.

2\. Input/Output.

~~~
balakk
And some computation.

~~~
techbio
I knew my #2 would be taken more literally than I meant it. At a very
fundamental level, computation consists of moving bits, hence I/O.

------
fotoblur
This reminds me of: "All Our Programming Languages Boil Down to Sequence,
Selection and Iteration"

<http://bit.ly/9lwT8e>

------
signa11
hmm, i was thinking 'All problems can be solved by another level of
indirection' should be somewhere pretty high up...

------
Jupe
1\. Nearly every decision makes the simple stuff more complicated

2\. Accepting thing #1 will make you a better programmer

------
VMG
Interesting idea - but I have never worked out what the two ideas of biology
are.

------
Kilimanjaro
Simplicity and beauty are my two coding principles.

------
hxa7241
1\. Write for the computer

2\. Write for the human

------
hasenj
1\. Abstract thinking

2\. Empathy for users and other programmers

