Hi Randall

>>Nothing personal here either! :).
>
>Kewl. I don't like getting into arguments, but I love a healthy debate,
>especially if someone is open enough to find common ground or maybe
>consider other possibilities they have not previously considered.
>
>>OK, so tell me in exacting detail how the textbox class was coded.
>
>Ah. A loaded question, huh? LOL! Nice try! :^). All kidding aside,
>Mike, this question is doable, even though The textbox class is a
>base class, and I seriously doubt that Microsoft is going to give
>out this information. The only problem with answering this is that
>Microsoft will probably want to sue me for breach of contract if I
>disassemble their code and plaster the answer on the net :^). Off the
>top of my head (pure, logical guess work), though, I can tell you that:
>
>1) it's a base class and built into VFP.
>2) It's most definitely calling the Win32API somewhere along the line and
>3) the original code was probably written in C and translated to C++ long ago,
> most likely coming from the realms of Visual C++ version 1 or something.
>
> It's probably been modified from here to eternity and back again to work in
>.NET and VFP, too.
>
>Oh, and I already know your response: "See. I don't need to know it at that
>level to use it's capabilities, and better yet, I can extended it's capabilities
>in the blink of an eye!" And you know what, I agree with that statement wholeheartedly! :^)
>
>My problem with the situation is this: "I don't need to understand it at that level."

Need <> Want

>Wrong! Do NOT pass go! Do not collect $200.00! A good geek _WILL_ understand it at
>that level, mainly out of insatiable curiosity, love of his or her work, or the
>_need_ to know how the entire system, as a whole, functions. Is it time consuming?
>You bet your butt it is! In most situations, is it practical? NOPE! :^). None the
>less, knowing the underlying workings of a system makes you a guru/wizard in your
>area of interest -- especially in programming and engineering!! -- and going into
>any venture half-baked and half-cocked is, IMHO, simply ludicrous. What I'm saying
>here, Mike is this: there are mindsets out there that not only need to know how
>the textbox class was coded -- they _HAVE_ to know. It's just the way they are.
>They love delving into the techincal details, and this is actually the stuff they
>love and find enjoying while programming, believe it or not. :^)
>
>>Hiding complexity does not mean you make the code impossible to find.
>
>As in something like this: "Here's a dll/class library that does everything you ever
>wanted to do and then some. You don't need to know the details. The methods handle
>all of the details for you. Here's the manual." No problem. Saves time. "This code should
>have been finished yesterday, and this package will save our butts." I totally
>understand this, Mike. This is great, in my book, but, like I've said before,
>it's the overall mentality or way of thinking that OOD and the universities are pushing
>that gets me. "You don't need to understand the details, son. Leave that up to
>people like us. All you need to know is that it has these capabilities, and if
>you want to extend the capabilities with a new subclass, kewlness!" Or how about "We have
>your best interests in mind; we'll hold your hand; we'll make things simple, and all you
>have to do is data entry." And, for all practical purposes, that's exactly what you become.
>A frickin' data-entry programmer.
>
>Basically, I want access to the details. I _want_ to know how things are done in
>VFP or any other language. However, the new OOD paradigm says that we're not
>suppose to even want to know how all the low-level stuff works, and my response
>to that brain-dead mentality is this: AHEM!!! BS! :^) :^).

Want <> Need

>
>>It means you make a chunk of code that does something complex into a unit.
>
>Agreed. Everything is not spread out everywhere, and it's all in one clear,
>logical spot/unit. No problem.
>
>>You build a piece of code that is clear and you name it something clear. It does
>>something complex like a spark plug, but you hide the complexity by calling it a
>>spark plug and there after reusing it. That's how things are supposed to be built.
>
>I agree, but let me ask you this: Let's say you wrote that code, and I said, "Mike.
>That rocks. Way kewl. I need a bunch of these spark plugs. As a matter of fact, I'd
>like to set up a spark plug plant. To do this, though, I'm going to need to see how
>you make these spark plugs, know the complexity, and all details involved. I'll pay you
>for it all, no problem." Most software companies don't want you to know the underlying
>code and details. Most OOD folks don't want others to worry about the base class definitions.

As an inventor of spark plugs, I have an interest in protecting my intellectual property - but hey if you want to resell them, you don't need to know how they work. Just walk in to any auto parts store and go ask the cashier to explain how the electricity from the coil pack actually travels down the wire and into the plug.

They'll have a vague notion at best. They don't have to know how it works to sell it or install it or anything. Wanting to know is not the same as needing to know.

Not only that, but if you "fix" my spark plug and cause your car to explode, that's your problem. :)

>"You don't need to know that." <--- This is the mentality I'm talking about. As programmers,
>all of us should strive to understand as many underlying details as we possibly can, because
>knowing these things will make us all better programmers.

But wouldn't having reliable parts make us even better programmers?

If things are not designed to be so encapsulated and bullet proof and reliable then we have to know their behavior in greater detail.


> For instance, lets say that I did
>understand all the code behind the textbox class. I might know that textbox rendering
>was painfully slow, and that a better solution would be to use a label that looks and acts
>like a textbox in a real-time environment. If I never bothered looking at the base class
>and knowing it to whatever degree, I'd never even consider the solution I came up with.
>"Just think about it as magic. Don't worry how it does things, only that it does the things
>that you want it to do." NAK! (Negative AcKnowledge in RS-232 :^))

That's not really what I mean. Products are supposed to be designed so they serve their purpose, are easy to use and they do not have to be deeply understood.

>
>
>Anywho, Naomi should be applauded for her knowledge of SPT and views. If she feels
>comfortable with "the more complicated" way of doing things, great! She'll get what
>she wants, she knows that she can handle the situation, and she'll probably get a
>finer level of control.
>
>Don't get me wrong here, though, Mike. I understand that she can save herself a lot
>of time and trouble by using CA's. Great! It's only that I don't like seeing her
>(or anyone else) being drawn away from the details, because paying attention to details
>is what inspires innovation, creativity, and it's the fountain of genius. Doubt that?
>Take your favorite program/programmers/geeks. Scrutinize them. What do you see?
>Someone that's been paying attention to details. This is the difference between
>a program and a professional program.

I suppose I can agree with that to a point. Creativity, innovation and "genius" can come from looking at the bigger picture too. Getting lost in the details can be frustrating thereby reducing creativity.

>
>>Where "hiding complexity" is bad is when code obscures the simple into ridiculously complex.
>
>Again, I agree. IMHO, it takes a certain mindset or way of thinking to take the complex
>and transform it into "complex is nothing more than a bunch of simples stacked on top
>of each other." In other words, I try to break down a complex situation into a bunch of
>smaller, more manageable pieces, solving these smaller problems one at a time. As a whole,
>it's complex, but step back and examine each part and it's simple. That's good code.

As long as the parts are simple, I don't have to know how they work. That's the goal of creating any piece of code.

I would like to know, but the thing is I don't need to know. As to unproductive, I just recently saw a contractor spend a week looking at a system and then estimate needing another two weeks to do what was done in 6 hours.

This want to know can be very bad. I don't need to know how the spark plug works to install one - but yes, because I took the time to understand them I know they are supposed to be indexed - positioned in the cylinder so the spark faces the gas.


--|
* | Gas <---- bad


|--
|* Gas <----- good


This is a good discussion - it should be moved to it's own design thread.

See ya!