Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #43233 > unrolled thread

objects build up from other objects

Back to article view | Back to comp.lang.forth

Contents

  objects build up from other  objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-04 14:44 +0000
    Re: objects build up from other  objects franck.bensusan@gmail.com - 2015-11-04 09:17 -0800
      Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-05 10:07 -0500
        Re: objects build up from other objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-05 18:34 +0100
          Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-06 00:09 +0000
          Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-05 21:47 -0500
            Re: objects build up from other objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-06 09:37 +0100
              Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-06 04:52 -0500
                Re: objects build up from other objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-06 12:36 +0100
                  Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-06 12:13 +0000
              Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 15:32 -0800
        Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-05 13:15 -0800
          Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-05 15:19 -0800
            Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-05 22:10 -0800
              Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-07 07:50 -0800
                Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-07 13:46 -0800
                  Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-07 14:46 -0800
          Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-06 00:20 +0000
            Re: objects build up from other objects Ron Aaron <rambamist@gmail.com> - 2015-11-06 07:39 +0200
    Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-04 15:33 -0500
    Re: objects build up from other  objects Chris Curl <ccurl609@gmail.com> - 2015-11-06 06:31 -0800
      Re: objects build up from other  objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-06 18:48 +0100
      Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-06 08:15 -1000
      Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-06 13:44 -0500
        Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-06 11:10 -1000
          Re: objects build up from other objects josv@planet.nl - 2015-11-06 15:19 -0800
            Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-06 14:54 -1000
              Re: objects build up from other objects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-07 16:57 +0000
                Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 08:13 -1000
            Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-06 19:31 -0800
              Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 20:03 -0800
              Re: objects build up from other objects josv@planet.nl - 2015-11-07 01:43 -0800
          Re: objects build up from other objects "HAA" <someone@microsoft.com> - 2015-11-07 15:03 +1100
            Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 20:42 -0800
          Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-07 10:12 -0500
            Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-07 10:01 -0800
              Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-08 08:22 -0500
                Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-08 06:37 -0800
              Re: objects build up from other objects "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-08 15:01 -0500
                Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-09 07:27 -0500
            Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 08:20 -1000
              Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-08 23:44 -0800
                Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 21:58 -1000
                  Re: objects build up from other objects Mark Wills <markwills1970@gmail.com> - 2015-11-09 01:57 -0800
                    Re: objects build up from other objects Ron Aaron <rambamist@gmail.com> - 2015-11-09 12:46 +0200
                      Re: objects build up from other objects Mark Wills <markwills1970@gmail.com> - 2015-11-09 03:04 -0800
                        Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-09 23:14 -0800
                    Re: objects build up from other objects - even Forth? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-11-09 12:15 +0000
                      Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-09 12:25 -0800
                        Re: objects build up from other objects - even Forth? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-11-10 10:48 +0000
                          Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-10 04:31 -0800
                            Re: objects build up from other objects - even Forth? hughaguilar96@gmail.com - 2015-11-10 18:06 -0800
                              Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-11 00:49 -0800
                                Re: objects build up from other objects - even Forth? Paul Rubin <no.email@nospam.invalid> - 2015-11-11 01:13 -0800
                                  Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-11 01:52 -0800
                                    Re: objects build up from other objects - even Forth? hughaguilar96@gmail.com - 2015-11-11 15:54 -0800
                                      Re: objects build up from other objects - even Forth? stephen@mpeforth.com (Stephen Pelc) - 2015-11-12 11:01 +0000
                                        Re: objects build up from other objects - even Forth? hughaguilar96@gmail.com - 2015-11-12 11:07 -0800
                                    Re: objects build up from other objects - even Forth? Paul Rubin <no.email@nospam.invalid> - 2015-11-11 15:55 -0800
                                      Re: objects build up from other objects - even Forth? Mark Wills <markwills1970@gmail.com> - 2015-11-12 00:50 -0800
                                        Re: objects build up from other objects - even Forth? Paul Rubin <no.email@nospam.invalid> - 2015-11-12 18:21 -0800
                    Re: objects build up from other objects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-09 12:16 +0000
                      Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-09 07:38 -0500
                  Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-09 04:15 -0800
                  Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 15:29 +0000
                    Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-09 09:09 -1000
                  Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-09 22:41 -0800
        Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-06 19:14 -0800
          Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 19:39 -0800
          Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-07 09:04 -0500
    Re: objects build up from other  objects lehs <skydda.barnen@gmail.com> - 2015-11-06 09:20 -0800
    Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-08 06:12 -0500

Page 4 of 4 — ← Prev page 1 2 3 [4]

#43514 — Re: objects build up from other objects - even Forth?

Mark Wills <markwills1970@gmail.com> writes:
> Just have a separate tag stack. 8 bit cells would suffice. The tag
> stack would be totally invisible ţo the user.

That's reasonable but you'd also have to have a tag area for the heap
since the unboxed values can appear in any object.  I think that is
sometimes done for GC markbits, but for values that are accessed all the
time, it sounds slow.

[toc] | [prev] | [next] | [standalone]

#43425 — Re: objects build up from other objects

Mark Wills <markwills1970@gmail.com> writes:
>One of the best examples of OO being useful in Forth would be
>Forth itself! A pure OO Forth would need only an object stack
>and a return stack. Integers, floats, strings, database connections,
>GUI object references would all go on the same stack regardless
>of type.

Sounds more like Postscript or Factor to me.

>Contrast that with todays situation where floats *may* go on the=20
>data stack, but may not, etc.

The Forth-2012 situation is that floats are on a separate FP stack.

Having to box or tag every integer and FP value as would be necessary
for the language may have it's advantages, but the resulting language
is pretty far from Forth (still close enough to be discussed here, but
not close enough to be called Forth).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#43427 — Re: objects build up from other objects

On 11/9/15 7:16 AM, Anton Ertl wrote:

> Having to box or tag every integer and FP value as would be necessary
> for the language may have it's advantages, but the resulting language
> is pretty far from Forth (still close enough to be discussed here, but
> not close enough to be called Forth).

Agreed on all points.

Discussions focused on honing classic Forth are interesting and
obviously very important. But I also find discussions of new Forth-like
paradigms like Franck Bensusan's Oforth and Ron Aaron's 8th to be
important. Something like what they are doing now could someday become
"mainstream" for Forth especially as hardware capability improves.

-Doug

[toc] | [prev] | [next] | [standalone]

#43424 — Re: objects build up from other objects

Le lundi 9 novembre 2015 08:58:31 UTC+1, Elizabeth D. Rather a écrit :
> 
> A purely procedural application, with essentially 1 each devices and 
> processes. Most simple data acquisition projects.

Well, this does not really answer my point :

Why a purely procedural application, with essentially 1 each devices and
processes will disqualify OO paradigm ? What will be the problem ?
Do you think that OO is unable do a procedural application ?

> 
> Depends on whether you care about code size, performance, and 
> programming effort. If you do, then you want to match the coding 
> paradigm to the problem.

One of OO main objectives is to limit programming effort. 
I don't see how this criteria could possibly disqualify OO.

For performances, I don't see either. But if you have an example 
where performances have disqualified OO paradigm, I'am interested.

For code size, I don't really see why.

The main concern with OO is, imo, memory allocation and desallocation.
If an application needs lots of objects, it can be a criteria to not
use OO paradigm (even if, if you need lots of objects, they must be handled).
This is why this point has to be extremely efficient (and why I think a
Forth OO extention may have difficulties to be really competitive, 
but this just is my opinion).

> 
> Neither are Forth programmers who have written more than one 
> application. As they gain experience, they have back pockets stuffed 
> with strategies, and can modify something from one of them to today's 
> need in tiny moments.

Well, I prefer optimized, proven, well-tested built-in strategies (arrays, ...) 
that don't have to be modified, than everyone making its owns. There is no
gain to modify each time this kind of tool to stick to a particular 
application, thinking it will best fit. Even performance gain is not sure.

And this limits programming effort, of course.

> 
> Cheers,
> Elizabeth
> 

Cheers,
Franck

[toc] | [prev] | [next] | [standalone]

#43433 — Re: objects build up from other objects

"Elizabeth D. Rather" <erather@forth.com> writes:

>On 11/8/15 9:44 PM, franck.bensusan@gmail.com wrote:
>> Le samedi 7 novembre 2015 19:20:51 UTC+1, Elizabeth D. Rather a écrit :
>>>
>>> I was addressing motivation. Adding a feature because other languages
>>> have it is a poor reason. As I described in another recent post, OO
>>> techniques have been used in Forth since the 70's. They are appropriate
>>> for some situations, including Windows features (which is the primary
>>> motivation in SwiftForth). Attempting to impose OO techniques on all
>>> programming seems as misguided as implementing a feature just to be a
>>> copycat. The needs of an application should drive the design of the program.
>>>
>>
>> Hello,
>>
>> Can you give one "application need" that will disqualify OO to be used ?
>> Or is it as simplistic as GUI = OO, not GUI = not OO ?

>A purely procedural application, with essentially 1 each devices and
>processes. Most simple data acquisition projects.

Let's see. Suppose we have a data collector, with separate task each
collecting data from a serial line.
The serial line has a memory/port address and all this nasty stuff,
like handshake character, time out, number of stopbits,
baudrate, parity error, overrun error, you name it.
I collect those in a class serial_configuration. Using the
idea of a current object makes this especially handy for different
tasks. I just need to make the pointer to the current object a
USER variable instead of a regular variable. With a task switch
the serial_configuration object is switched automatically.

>GUI is a good example of OO, but so are many other applications of which
>I've given recent examples (image processing, industrial controls, etc.).

>> All mainstream and popular languages that implement OO paradigm
>> refute what your are saying : yes, it is possible to apply OO paradigm
>> to many kind of applications, regardless their need.
>> And this does not seems to be such a bad strategy if we look at those
>> languages popularity.

>Depends on whether you care about code size, performance, and
>programming effort. If you do, then you want to match the coding
>paradigm to the problem.

>> Let me tell you a secret : there are, somewhere, some people that are
>> not beginning from scratch for each application, they are not recreating
>> arrays, list, structure, ... everytime just because "the application
>> needs drives the design" and they use OO as a paradigm, not as an extension
>> dedicated to GUI.

>Neither are Forth programmers who have written more than one
>application. As they gain experience, they have back pockets stuffed
>with strategies, and can modify something from one of them to today's
>need in tiny moments.

We are done by the time the Java programmer discovers he has to
work around a limitation on the third level of abstractions.
However if he manages, it probably works despite those programmers
being less talented than us Forth programmers.

>Cheers,
>Elizabeth


<SNIP>

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#43437 — Re: objects build up from other objects

On 11/9/15 5:29 AM, Albert van der Horst wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>
>> On 11/8/15 9:44 PM, franck.bensusan@gmail.com wrote:
>>> Le samedi 7 novembre 2015 19:20:51 UTC+1, Elizabeth D. Rather a écrit :
>>>>
>>>> I was addressing motivation. Adding a feature because other languages
>>>> have it is a poor reason. As I described in another recent post, OO
>>>> techniques have been used in Forth since the 70's. They are appropriate
>>>> for some situations, including Windows features (which is the primary
>>>> motivation in SwiftForth). Attempting to impose OO techniques on all
>>>> programming seems as misguided as implementing a feature just to be a
>>>> copycat. The needs of an application should drive the design of the program.
>>>>
>>>
>>> Hello,
>>>
>>> Can you give one "application need" that will disqualify OO to be used ?
>>> Or is it as simplistic as GUI = OO, not GUI = not OO ?
>
>> A purely procedural application, with essentially 1 each devices and
>> processes. Most simple data acquisition projects.
>
> Let's see. Suppose we have a data collector, with separate task each
> collecting data from a serial line.
> The serial line has a memory/port address and all this nasty stuff,
> like handshake character, time out, number of stopbits,
> baudrate, parity error, overrun error, you name it.
> I collect those in a class serial_configuration. Using the
> idea of a current object makes this especially handy for different
> tasks. I just need to make the pointer to the current object a
> USER variable instead of a regular variable. With a task switch
> the serial_configuration object is switched automatically.

Sure, if you have a bunch of them. OO is exactly for the case where you 
have a bunch of things with similar properties. But if there's only one, 
plus a series of things to do with its data, than not so much.

>> GUI is a good example of OO, but so are many other applications of which
>> I've given recent examples (image processing, industrial controls, etc.).
>
>>> All mainstream and popular languages that implement OO paradigm
>>> refute what your are saying : yes, it is possible to apply OO paradigm
>>> to many kind of applications, regardless their need.
>>> And this does not seems to be such a bad strategy if we look at those
>>> languages popularity.
>
>> Depends on whether you care about code size, performance, and
>> programming effort. If you do, then you want to match the coding
>> paradigm to the problem.
>
>>> Let me tell you a secret : there are, somewhere, some people that are
>>> not beginning from scratch for each application, they are not recreating
>>> arrays, list, structure, ... everytime just because "the application
>>> needs drives the design" and they use OO as a paradigm, not as an extension
>>> dedicated to GUI.
>
>> Neither are Forth programmers who have written more than one
>> application. As they gain experience, they have back pockets stuffed
>> with strategies, and can modify something from one of them to today's
>> need in tiny moments.
>
> We are done by the time the Java programmer discovers he has to
> work around a limitation on the third level of abstractions.
> However if he manages, it probably works despite those programmers
> being less talented than us Forth programmers.

Yep.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43440 — Re: objects build up from other objects

On Monday, November 9, 2015 at 12:58:31 AM UTC-7, Elizabeth D. Rather wrote:
> On 11/8/15 9:44 PM, franck.bensusan@gmail.com wrote:
> > Let me tell you a secret : there are, somewhere, some people that are
> > not beginning from scratch for each application, they are not recreating
> > arrays, list, structure, ... everytime just because "the application
> > needs drives the design" and they use OO as a paradigm, not as an extension
> > dedicated to GUI.

Franck is quite correct that OOP is essential to programming in that it allows for general-purpose data-structures. I disagree with Franck regarding polymorphism which he told me in a private email is absolutely essential, whereas I think that it is a bad thing (it is in blatant conflict with Charles Moore's maxim: "Let the dictionary do the deciding."). This disagreement doesn't mean that I think oForth is a bad language --- just that it is not really my cup of tea. 
 
> Neither are Forth programmers who have written more than one 
> application. As they gain experience, they have back pockets stuffed 
> with strategies, and can modify something from one of them to today's 
> need in tiny moments.
> 
> Cheers,
> Elizabeth

This is not the first time that we have heard Elizabeth Rather describe her ideal Forth programmer: "As they gain experience, they have back pockets stuffed with strategies, and can modify something from one of them to today's need in tiny moments."

I think Elizabeth Rather's quote above really describes in a nutshell why ANS-Forth was a total failure.

Here is a quote from my Stundurd document (http://www.forth.org/Stundurd.txt):
----------------------------------------------------------------------------
Elizabeth Rather:           
Since it's so easy to write common procedures in Forth, they tend to be tightly adapted to the application for which they're developed, which makes them less amenable to sharing.

Anton Ertl question:        
Why do other languages have a thriving culture of sharing reusable code and Forth doesn't? One of the reasons is that the idea of code reuse is despised by a significant part of the Forth community, according to lore starting with Charles Moore.

Elizabeth Rather response:  
That is not entirely true. Chuck carried around with him a large library of things he had written in the past (in the 70's, a notebook full of microfiches and a reader!), and always started with past code when he could. Of course, then he re-wrote it for the application at hand (see my last point above). And everyone I know who is spending a career writing Forth applications has a bulging "back pocket" of reusable code. FORTH, Inc., MPE, and probably most other widely used systems have such libraries.

What Elizabeth Rather is describing --- the bulging "back pocket" --- is not a code library (despite her calling it a "library"); this is an archive of old programs. In the COBOL or CNC culture, if the FNG writes a program from scratch, the boss will reject it because: "that is not the way that we write that kind of program around here." The boss will ask how the FNG can be sure that the program works if it hasn't been previously used dozens of times and didn't come from a reliable source. The boss will accuse the FNG of being a smart-aleck and brashly claiming that he knows more about the job than the old-timers who have been doing the job for years. Essentially, the FNG is required to cut-and-paste old programs and isn't authorized to write original programs, although he will be promised that after a few years when he has proven himself he will gradually be allowed to write programs that aren't cut-and-paste of existing programs. In the meantime, he will cut-and-paste old programs from the archive, and his learning curve will primarily involve familiarizing himself with the archive (the archive never has any documentation, so this familiarization will take years) --- if he is not allowed access to the archive, then he will have to politely ask the FOD to give him copies of appropriate programs from the archive as needed, and he will save them in his own archive so he can gradually replicate the archive. The system is designed so that the transition from FNG to FOD will take several years of brown-nosing.

The FOD/FNG system was prevalent during the Middle Ages when European technology was based on trade-guilds and apprenticeships --- during the Middle Ages it was mostly chemical engineering (the formulas and recipes) that were kept in the journeyman's bulging back-pocket. The science of chemistry didn't exist in the sense that a young person could learn chemistry outside of the context of any particular trade (different trades used different terminology for the same things, and when they had common words such as "acid" they didn't have any means of comparison such as the PH-scale). During the Middle Ages, there was a lot of hostility toward the concept of science. The thinking of the time was that science was totally impractical and that the trades were pragmatic. Science is focused on acquiring general-purpose information and sharing it, whereas the trade guilds were focused on acquiring trade-specific information and hoarding it. The trade guilds were focused on the past, in the sense that information obtained in the past was valuable and would be replicated throughout the future (essentially, cut-and-paste programming). The proto-scientists were focused on the future, in the sense that concepts learned in the past could be the foundation for more learning in the future. The following is a quote from Elizabeth Rather that sounds like something a journeyman representing a 17th-century trade guild might have said, as it perfectly illustrates the tension of the Middle Ages between the trade-guilds and science:

Elizabeth Rather quote #1:  
I have observed that there are programmers who occupy themselves with building shinier and shinier tools, and others who spend their time actually making applications work. The latter have a pragmatic, not theoretical, view of what tools are valuable and what are not, and their toolkit tends to be quite different.

To be fair, there are "programmers" who can't program, so they spend a lot of time on the internet criticizing programmers for their choice of algorithms. Also, if they have a job programming they gravitate toward vague tool-building assignments that don't have deadlines. If they get put in the awkward position of having to write a program on deadline, which they aren't capable of doing, they blame their tools when they fail. Every programming language is plagued with dead weight such as this, and Stundurd Forth won't be immune, but this doesn't matter so long as the Stundurd micro-controller is considered to be competitive with the C-centric micro-controllers at a practical level. The important point, is that in Stundurd Forth we have general-purpose reusable code libraries available. Obviously, people who are capable of programming, rather than the fakers, should be the ones who write these toolkits (mostly just myself initially). But, no matter how capable the programmers are, if the language doesn't have quotations (ANS-Forth, Forth-200x and C do not) then the programmers will be hamstrung in their effort to build a toolkit. Quotations are essential to actually having a toolkit at all.

The "toolkit" that Elizabeth Rather is referring to, that "tends to be quite different," is actually just an archive of past programs that can be cut-and-pasted into future programs. The behavior and implementation is mixed together and largely inseparable, so there is no way to think abstractly about programming as a science. This was really the hallmark of the Middle Ages --- people didn't abstractify very well --- what we now consider to be autism was the zeitgeist of the Middle Ages (see any of Temple Grandin's books for a discussion of abstractification and autism). Rituals were very important during the Middle Ages, because they allowed people to think about abstract concepts in concrete terms. For example, when a man committed to being a vassal to a lord, he would he hold his hand out and give a ritual speech about how he would not move his hand without his lord telling him to do so, and the lord would grasp his wrist implying control --- people needed rituals like this to concretify concepts in their minds. Even today many people rely heavily on rituals to help them get a grip on reality (for example: pointing and clicking in a GUI). Our supposed modern era has not progressed much from the Middle Ages, and since the advent of computers we have gone more backwards than forwards (if we continue back-sliding, the much-anticipated post-modern era will be remarkably similar to the Middle Ages that we supposedly left behind). People weren't doing much abstract thinking in the Middle Ages, and they aren't doing a lot now either. There is very little writing from the Middle Ages that goes beyond purely day-to-day thinking and gives any perspective on the big picture. This was also the paradigm of the trade guilds --- they focused entirely on day-to-day work, which was just a replication of past work, but they didn't give any thought to the future in the sense that they were learning any new concepts that would change anything --- the apprentices were also expected to follow in their masters' footsteps as replicants of their masters.

The good thing about a code library is that only the behavior of a container needs to be understood by the user, but all the complicated implementation details are hidden. Also, the API (Application Programmer Interface) can be documented, but old COBOL or gcode programs have little or no documentation, and there is no good way to separate the behavior from the implementation because the code is all mixed together in the program. So, if Forth is going to ever succeed as a professional programming language, we need to get away from COBOL-style programming (which is really the same as trade-guild thinking) and start building programs based on reusable code libraries (empower the FNGs!). Unfortunately, ANS-Forth is designed entirely around COBOL-style programming. To understand how it became like this, we need to read some quotes from Elizabeth Rather (chair-person of the ANS-Forth committee). ANS-Forth totally embodies Elizabeth Rather's understanding of computer programming, so to understand idiomatic ANS-Forth it is only necessary to understand where Elizabeth Rather is coming from.
----------------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#43281 — Re: objects build up from other objects

On Friday, November 6, 2015 at 1:44:48 PM UTC-5, Doug Hoffman wrote:
> On 11/6/15 9:31 AM, Chris Curl wrote:
> 
> > Forth has its own strengths. It is my opinion that "we don't need no
> > stinking object orientation in Forth".
> 
> Other languages also support the following:
> 
> - structured programming
> - if/then/else program control
> - loops
> - case statements
> - floating point
> - variables
> - local variables (Forth has 2 kinds of locals in the standard)
> - structures
> - a lot more
> 
> Should we shun the above features in Forth just because "other languages
> use them"?  After all, we can't have any part of Forth have anything at
> all in common with other languages now can we?
> 
> -Doug
Don't forget that they all can also add 2 numbers, so we can't
have that in Forth either.

Seriously though, I'm not sure which part of this you missed ...

-> I also get it that a huge strength of Forth is that it can be 
-> used to build one's own world, and that some people want to 
-> build such a world for themselves using Forth. That is great, 
-> and I and I will defend your right to use it for that if you 
-> so choose. 

Am I allowed to voice my OPINION that trying to make Forth like 
C++ seems silly?

[toc] | [prev] | [next] | [standalone]

#43283 — Re: objects build up from other objects

On Friday, November 6, 2015 at 8:14:15 PM UTC-7, Chris Curl wrote:
> Am I allowed to voice my OPINION that trying to make Forth like 
> C++ seems silly?

I mostly agree with Chris on this --- he may be a newbie, but he understands the Forth idea better than most.

Forth is extensible, so a lot of newbies try to extend Forth to look more like some other language that they are familiar with (such as C++ or Pascal or whatever). This is largely missing the point of extensibility --- you want to extend Forth to look more like it was designed specifically for your application --- turn Forth into a DSL (domain-specific-language).

This is not to say that you don't have extensions that are common to a lot of application programs --- in the novice package I provide data-structures such as arrays, lists and associations that are a step toward almost any application program.

The focus should always be on writing application programs --- it is a mistake to think of Forth as a science-fair project, which is what a lot of these OOP package writers are doing --- it is not really harmful, and some of this might be useful, but it is lacking in focus.

[toc] | [prev] | [next] | [standalone]

#43297 — Re: objects build up from other objects

On 11/6/15 10:14 PM, Chris Curl wrote:
> On Friday, November 6, 2015 at 1:44:48 PM UTC-5, Doug Hoffman wrote:
>> On 11/6/15 9:31 AM, Chris Curl wrote:
>>
>>> Forth has its own strengths. It is my opinion that "we don't need no
>>> stinking object orientation in Forth".
>>
>> Other languages also support the following:
>>
>> - structured programming
>> - if/then/else program control
>> - loops
>> - case statements
>> - floating point
>> - variables
>> - local variables (Forth has 2 kinds of locals in the standard)
>> - structures
>> - a lot more
>>
>> Should we shun the above features in Forth just because "other languages
>> use them"?  After all, we can't have any part of Forth have anything at
>> all in common with other languages now can we?
>>
>> -Doug
> Don't forget that they all can also add 2 numbers, so we can't
> have that in Forth either.
>
> Seriously though, I'm not sure which part of this you missed ...
>
> -> I also get it that a huge strength of Forth is that it can be
> -> used to build one's own world, and that some people want to
> -> build such a world for themselves using Forth. That is great,
> -> and I and I will defend your right to use it for that if you
> -> so choose.
>
> Am I allowed to voice my OPINION that trying to make Forth like
> C++ seems silly?

Of course, and proof is that you did. I will always defend the right to
free speech. Including my right to point out the contradiction in your
stated opinion.

-Doug

[toc] | [prev] | [next] | [standalone]

#43272

To me, an object in Forth is some integers on the stack, some arrays and some words that deals with that. Since there is no need for the compilator to regognize "objects" there are no need to formalize it.

[toc] | [prev] | [next] | [standalone]

#43359 — Re: objects build up from other objects

On 11/4/15 9:44 AM, Albert van der Horst wrote:
> I've stood up to the challenge to show how ciforth's mini-OO (with current
> object) can be used to build larger objects.

> class Rectangle
>     M: upper-left-corner ^Point ! M;   BUILD-Point DROP
>     M: lower-right-corner ^Point ! M;   BUILD-Point DROP
> endclass

> \ Store X1 Y1 X2 Y2 into a Rectangle
> : init-Rect lower-right-corner y! x! upper-left-corner y! x! ;

> \ Return the LENGTH of the diagonal of the current Rectangle
> : diagonal   upper-left-corner x y lower-right-corner x y HYP ;

> Rectangle this-mine-self
> this-mine-self    10 10 40 50 init-Rect
> this-mine-self    diagonal .

> It would be interesting to see how composing objects
> works in other OO's.

In response to your request there seems to have been two different
techniques presented for defining a new class using a previously defined
class:

1) Use another class to compose the instance variable fields of a new
class definition.

2) Simply define container instance variables and then store references
to objects in those containers.

If I understand correctly your code above uses technique 1). The FMS
example I presented also used technique 1).

variable ulc
variable lrc

:class rectangle
   point ulc
   point lrc
   :m diagonal ( -- diag )
      ulc get lrc get hyp ;m
   :m put ( x1 y1 x2 y2 -- )
      lrc put ulc put ;m
;class

\ named rectangle in dictionary
rectangle r
10 10 40 50 r put
r diagonal .

Note that the instance variable names do not collide with the global
variable names in FMS ( ulc and lrc ).

heap> rectangle value hr
10 10 40 50 hr put
hr diagonal .
hr <free

Note that instantiating in the heap a composed object using technique 1)
will automatically allocate the embedded objects in the heap as well.


All others used technique 2). I assume that you could have used 2)
because it is the easier technique to implement. FMS could have used 2)
as well but I tried to use the same/similar technique that you presented.

Did I understand correctly? Have you drawn any conclusions from the
responses provided?

-Doug

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.forth

csiph-web