Re: [colorforth] objects and forth

[vaded@xxxxxxxxxxxxxx]

Out of curiosity, given your justified lack of faith in academia, how
would you recommend a young adult in today's world went about learning
to program?  It would be a hard task because the world has adopted
insane paradigms in computing, but most the money is in those insane
paradigms.  Do you learn the new Forths and hope that somehow you will
find employment with that, and thus not "sell out"?

I noticed Jeff Fox made two good points about learning Forth.  1) To be
an expert at something takes 10 years of dedicated work, and 2) To excel
it can greatly help to be trained by a "master" in the art you are
trying to perfect.  

Should people still be learning assembly for the PC and going from
there?  Is that the best starting point?  Should the PC be skipped
altogether?  What books could even be recommended?  

On Mon, 2 Feb 2009 17:05:22 -0500, "David J. Goehrig"
<dave@xxxxxxxxxxxxxx> said:
> 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
> 

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