Re: [colorforth] objects and forth
- Subject: Re: [colorforth] objects and forth
- From: vaded@xxxxxxxxxxxxxx
- Date: Mon, 26 Jan 2009 16:06:14 -0700
"However, as a model for factoring code or designing components, it is
horrible."
Could you elaborate on that point a bit?
Thanks
On Mon, 26 Jan 2009 13:00:18 -0500, "David J. Goehrig"
<dave@xxxxxxxxxxxxxx> said:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com