Re: [colorforth] objects and forth

["David J. Goehrig" <dave@xxxxxxxxxxxxxx>]

On Sat, Jan 31, 2009 at 12:21:58AM -0800, Panthera Altaica wrote:
> 
> The main goal of OOD is ignorance(they call "encapsulation")
> OOD doesn't like 'inheritance', the problem is stated as follows: "Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'". 
> 

Oh I agree with this to an extent.  This is true of the Java crowd for sure.  Not all OO-ers fully believe in this nonsense though.

> It is the whole hide it in a black box and it will just magicaly work idea.

Well, most Smalltalkers tend to avoid this black box idea.  They are generally more than willing to go in and modify a low level class like Object just to make their idiom work correctly.  For example it is standard practice to add a method like:

	isMyClass
		^ false

to the root level Object class, and then in your own class implement the corresponding method

	isMyClass
		^ true

Just so you can test if an object is a member of your class or not, without triggering the debugger at runtime.  So the general concept isn't so much mandatory ignorance, but rather results in a culture of willful ignorance, because one doesn't need to think about what they're doing.  It doesn't actually have to be that way.

That said, when you jump through hoops just to make your idiom work, your idiom is probably broken.  But hey, that's why the Gang of Four wrote the Patterns book, to describe all the different hoops they typically encounter.

> And you are surprized that they all idiots teaching others how to be idiots?

Actually, judging by one of my friend's experiences as an associate professor at one of the best Comp Sci Universities in the country (a top 20 school for sure), he's got PhD students who don't know how to open files off a CD.  So I'd avoid saying we've got idiots teaching idiots, just that we have CompSci people who know nothing about real world computers.   Theoretical computers they understand, real computers we should probably keep them far away from.  And you know this is getting bad, when even professors are complaining they can't find any students competent enough to program their research projects!

In my opinion, the structure of academia is to blame for decline in programming.  We have a culture that engenders a whole range of behaviors and thought processes that are contrary to developing a fundamental understanding of actual reality.  Academia simply over values theoretical generality and experiments in an idealized world.  When combined with the pressure to publish specialized research, it produces programmers who over focus on narrow aspects of problems, (in order to get published), and then attempt to produce the most generalized solution (to qualify as academic).

When we train PhDs to narrowly focus on a small aspect of the problem, and they carry that behavior into the real world.  As a result, you see people generate huge XML documents to transfer data to client apps, (consisting of largely redundant and irrelevant data), and then add a layer of complexity to solve that problem by compressing the feed.  Eventually, all of the processing necessary is too much, so they implement a ASN.1-like solution, and spend a lot of time trying to compress that data say by using variable bytewise integers.  Eventually, this too grows too large, so they add compression layers on top of that too.  At no point does anyone ask, "Why do we really need all this data?"  Because none of them have been trained to look at the whole picture.  Rather they all live in little boes.

http://www.youtube.com/watch?v=ONEYGU_7EqU

My experiences contracting for a certain large company, that is known for hiring PhDs, has been a painful exercise in fighting that culture war.  At one point I was handed a portablilty layer of 16k LOC for a library they wanted ported to a new hardware platform.  I turned around and instead reverse engineered their undocumented proprietary protocol and provided them an implementation in 300 LOC, tooled specifically for the platform.  Had I attempted to port their code, I estimated I would have had to write 2600 LOC just to port the underlying classes.  Removing the abstraction layers, resulted in less work, less testing, and less cost.  But that's not what the PhDs ever thought of doing.

Dave

PS. full disclosure, I too have a post-graduate degree, but in Useless Studies :)



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com