Day 25: TECS Project 2, and Arguing on the Internet

Arguing on the internet is like competing in the Special Olympics:  it doesn't matter who wins, you're still retarded.
 - Internet Wisdom


I was playing an online game last night, when I got into quite the disagreement with another guy in my group.  I casually mentioned that I was teaching myself how to program, and he offered his help as a professional programmer, which was very nice of him to do.  He suggested I dive right into OOP, and asked what I was doing now, and I said I was learning some C++ with the help of a friend (Zach) and going through TECS to learn how computers work from the bottom up.  Then came that fateful moment where someone says something which maybe they don't really mean, but then they stick to their guns and everything blows up in everyone's face.

He said, "No, you should start with a top-down approach.  Top-down is always better than bottom-up."

I added emphasis to "always," because that was the one word that stuck in my craw.  I am a philosopher, and I know from my philosophical training that the word "always" should almost always be preceded by the word "almost."  So I said, "Not necessarily."  To which he responded, "Yes, necessarily.  I do this for a living, I know what I'm talking about."

Oh, boy.

So I offered to cook him up an example of a situation where you'd want a bottom-up approach instead of a top-down one, and he was receptive.  I went on to say that if you wanted to simulate an ecosystem but don't know how it works, you should start at the bottom and tweak the parts until the high-level interactions look acceptably like what you see in reality.  I thought this would be a knock-down argument, since ecosystems do in fact emerge from the bottom up and not from the top down, and designing an ecosystem from the top down requires precisely the sort of understanding which the example stipulates to be lacking.  He replied that no, a better way would be to simply simulate all the high-level interactions without worrying about the bottom-up organization, because the internal structure doesn't matter so long as the output is correct (and fair play to him, that latter clause is true).  Having sprung my trap, I pointed out that this presupposes exactly the understanding which is missing from the example - in other words, if you could design the simulation accurately from the top down, then you've already got what the simulation is for.

It gets better.

Then he says, "Well, that's just one specific example.  In general, the top-down approach is better for achieving professional results."

I replied, "Wait, you just changed the subject!  You said that top-down is always better than bottom-up, which means that 'just one specific example' of bottom-up being better is all that's needed to show that top-down is not always better."

"Fine, but in a professional environment, you've still got to do things from the top down."

"But I'm not doing this in a professional environment!  I'm doing this as a hobby."

"Top-down gets results faster, though.  Working bottom-up usually engages you in a bunch of aimless wandering that doesn't get anything done."

We then discussed the virtues of curiosity-driven exploration and the importance of enjoying one's work, and it was all very edifying.  There was a happy ending, too.  I asked him if he had any hobbies (he does:  writing), and then asked him how many hours a week he spends working with his agent and trying to get published (answer:  zero).  Then I told him that he'll never get a good publishing deal without an agent to help him tweak his book for maximum marketability and so he's never going to make it as a professional writer with his current approach - and said that that's how he sounded to me during the last ten minutes.  Then he understood where I was coming from, and now we're friends again.

Jeez, some people (and in case it wasn't clear from my opening quotation, yes, I know that I am some people, too).

In Other News:  I built the half adder, full adder, 16-bit adder, and incrementer.  Oddly, the incrementer gave me the most trouble of the four, but then I had a flash of inspiration and facepalmed at the obviousness of the solution.  I still can't hack the ALU, though, and apparently that's the centerpiece of the virtual machine I'll eventually be building.  Moreover, it's not like I tried a bunch of different things and just kept failing; I don't even know where to start.  My instinct is that I'm intimidated by it at some level, probably because of all the different pins and the fact that it's just a black box on the inside and I need to specify everything that goes into the box.  But in the greater scheme of things, knowing how to build an ALU is tangential to my long-term goals at best, so I'm skipping it and moving on for now.  I gave it an honest effort (I re-read the chapter, and I'm a little clearer on what it's supposed to do, but no clearer at all on how I need to get it to do that), and maybe I'll come back to it after the next chapter or two and see if I have any epiphanies.  And anyway, I'm repeatedly finding myself thinking, "This would be so much easier if I could just write the function of the chip in C++ instead of the HDL," which A) means that I'm learning to think like a programmer, if nothing else, and B) shows that I still have a ways to go, because I wanted to use software to tell the hardware how to do what it does on its own.  But hey, at least I realized that.

OK, so that's week five down.  Over the weekend, I'll be reading up on OOP and classes and such, and Monday should bring another substantial update to Hula.  Y'all have a good one!