Re: [colorforth] objects and forth

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

On Sun, Jan 25, 2009 at 05:40:21PM -0800, tom arnall wrote:
> 
> what's the forth community thinking about objects these days?

Well while I can not speak for the community at large, I can say that there is a growing recognition within the Smalltalk VM developer community that they need to break their bad habits.  A lot of the JIT solutions are focusing on breaking out of the "objects must be represented directly in code" mindset and are starting to think a lot more like forth programmers.

Further more, if you look at what the PEG people have been working on, with their parsing executable grammars, as a forth programmer you'll see how a bunch of object people go about implementing Forth.  It is really quite fun to watch them struggle with concepts that would be easy if they simply adopted a directly manipulable return stack.

At the heart of nearly every ML dialect is a forth implementation screaming for air too!  (SML NJ is a perfect example, its dictionary would make any Forth programmer feel right at home).

So while the views of the forth community may be more or less the same as they were years ago, the other communities, that are actively struggling with simplicity, are starting to think more and more like forth programmers.  At the current rate of "progress", most programmers on the planet will have no concept how their programs work, and the few who do will grok forth.

People who get excited about 'objects' simply don't understand indirect / vectored execution.  Mistaking a conceptual model / metaphor for an implementation strategy / design has never been particularly good idea.  Although those who understand OO only as a matter of faith, will still see this issue only according to their dogma, those who understand forth are free of the messy ideological restrictions.

My personal thoughts on OO is that it is a good model for describing interfaces between pieces of software that reside in separate process spaces.  However, as a model for factoring code or designing components, it is horrible.  As for how we train new programmers in "OO Patterns", without any of the historical perspective, all we are doing is creating a new religion;  a religion in which new programmers take on faith programming techniques as design dogma, rather than understanding them for what they really were.




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