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

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

A slightly longer mini-oof2.fs example.

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

Contents

  A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-22 19:29 -0700
    Re: A slightly longer mini-oof2.fs example. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-23 11:22 +0000
      Re: A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-23 09:38 -0700
    Re: A slightly longer mini-oof2.fs example. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 12:11 +0000
      Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-23 10:26 -0500
        Re: A slightly longer mini-oof2.fs example. Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-23 19:59 +0200
          Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-24 04:23 -0500
          Re: A slightly longer mini-oof2.fs example. Hans Bezemer <the.beez.speaks@gmail.com> - 2014-05-24 15:47 +0200
            Re: A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-26 12:46 -0700
          Re: A slightly longer mini-oof2.fs example. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-24 15:35 +0000
            Re: A slightly longer mini-oof2.fs example. Alexander Skobelev <al.skobelev@gmail.com> - 2014-05-24 20:45 +0400
            Re: A slightly longer mini-oof2.fs example. Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-24 21:46 +0200
              Re: A slightly longer mini-oof2.fs example. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-25 15:03 +0000
                Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-25 15:16 -0500
                Re: A slightly longer mini-oof2.fs example. Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-26 00:47 +0200
            Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-25 18:55 -0500
              Re: A slightly longer mini-oof2.fs example. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-26 11:44 +0000
                Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-27 05:25 -0500
                  Re: A slightly longer mini-oof2.fs example. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-27 11:56 +0000
              Re: A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-26 12:18 -0700
                Re: A slightly longer mini-oof2.fs example. Paul Rubin <no.email@nospam.invalid> - 2014-05-26 12:46 -0700
                  Re: A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-26 13:43 -0700
                Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-27 05:28 -0500
      Re: A slightly longer mini-oof2.fs example. Julian Fondren <ayrnieu@gmail.com> - 2014-05-23 09:39 -0700
        Re: A slightly longer mini-oof2.fs example. mhx@iae.nl - 2014-05-23 10:29 -0700
        Re: A slightly longer mini-oof2.fs example. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 17:16 +0000
    Re: A slightly longer mini-oof2.fs example. andraszsoter@gmail.com - 2014-05-26 10:23 -0700
      Re: A slightly longer mini-oof2.fs example. Mark Wills <markwills1970@gmail.com> - 2014-05-27 02:09 -0700
        Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-27 06:07 -0500
        Re: A slightly longer mini-oof2.fs example. andraszsoter@gmail.com - 2014-05-28 10:17 -0700
      Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-27 05:39 -0500
        Re: A slightly longer mini-oof2.fs example. Mark Wills <markwills1970@gmail.com> - 2014-05-27 04:02 -0700
          Re: A slightly longer mini-oof2.fs example. Mark Wills <markwills1970@gmail.com> - 2014-05-27 04:04 -0700
          Re: A slightly longer mini-oof2.fs example. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-27 06:19 -0500

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

#30777

Julian Fondren <ayrnieu@gmail.com> writes:
> If you have a current object, then you can write a non-method that grabs the
> current object out of the air:
> : .cons ( -- ) 
>   ." (" car @ .  cdr @ 0 .r ." ) " ;

I don't understand the advantage over
  : .cons ( this -- ) ." (" dup car @ . cdr @ 0 .r ." ) " ;
It also looks to me like that prints the car as an integer, while I'd normally
expect a print function to dispatch on a type tag in the object.

> Java and C++, and certainly the explicit-passing languages, don't
> have this feature at all. 

If they get along without and nobody is missing it, then why is it
important?  I haven't used mini-oof2 so I guess some things are going
past me.

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

#30784

On Monday, May 26, 2014 2:46:04 PM UTC-5, Paul Rubin wrote:
> Julian Fondren <ayrnieu@gmail.com> writes:
> > If you have a current object, then you can write a non-method that grabs the
> > current object out of the air:
> > : .cons ( -- ) 
> >   ." (" car @ .  cdr @ 0 .r ." ) " ;
> 
> I don't understand the advantage over
>
>   : .cons ( this -- ) ." (" dup car @ . cdr @ 0 .r ." ) " ;

You don't have to shepherd the object through .CONS or through its caller to
get it to .CONS

.CONS wouldn't be any differently defined if CAR and CDR were VARIABLEs or
colon definitions.  It's very natural to come back and object-ify code that
wasn't already explicitly passing an address around.

> It also looks to me like that prints the car as an integer, while I'd normally
> expect a print function to dispatch on a type tag in the object.

It's an example, and not an example of heterogeneous lists.

> > Java and C++, and certainly the explicit-passing languages, don't
> > have this feature at all. 
> 
> If they get along without and nobody is missing it, then why is it
> important?  I haven't used mini-oof2 so I guess some things are going
> past me.

You say this as if Java and C++ have N features, and mini-oof2 has N+1
features, and since they get by pretty well with N, the +1 must be pretty
superfluous.  But a current object is just an alternative to other ways of
getting your objects and your methods &c together.  It's N features in both
cases -- one of the features is different.  And it's therefore no surprise that
Java and C++ manage to get along without an alternative to something they already
offer.  One just points out that they get along differently.

I would say, >o o o> are so easy to deal with (in spite of return-stack
weirdness) that alternatives to them are that much more of a hassle.  Meanwhile
the response (in that other thread, mainly) seems to be that people merely
anticipate that they would be more of a hassle than alternatives.  FOO >O BAR
O> certainly looks like more work than FOO BAR  .  But has anyone tried
mini-oof2.fs for a length of time and *then* complained about having to manage
the current object?


-- Julian

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

#30827

Julian Fondren <ayrnieu@gmail.com> wrote:
> On Sunday, May 25, 2014 6:55:12 PM UTC-5, Andrew Haley wrote:
>> I don't think that Java and C++ really have a current object: "this"
>> is really just the name given to the first argument that was passed to
>> a (virtual or non-static) method.
> 
> You've said this a few times, but always tentatively like this, or
> with reference to a language where the passed object is explicitly
> an argument of the method, like Python [or Perl or CL].
> 
> If you have a current object, then you can write a non-method that
> grabs the current object out of the air:
> 
> : .cons ( -- ) 
>  ." (" car @ .  cdr @ 0 .r ." ) " ;
> 
> : debug ( -- ) 
>  cr ." DEBUG: <other debugging information>.  Current class: " o .class ;
> 
> And invoke it in the middle of a method or an >o .... o> sequence without
> taking any effort to pass anything to it.

Right, but how is that a good thing?  If you want to debug THIS, why
not say THIS DEBUG ?

> If you don't have a current object, then you can't do that.  There's
> nothing to grab.  So Java and C++, and certainly the
> explicit-passing languages, don't have this feature at all.

That's exactly what I'm saying, yes.

Andrew.

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

#30616

On Friday, May 23, 2014 7:11:34 AM UTC-5, Anton Ertl wrote:
> IIRC the only one sceptical was Andrew Haley.  Most people working on
> this have a current object (THIS, SELF or O).  The main discussion was
> about how the current object should be set.  Bernd Paysan sets and
> restores it explicitly with >O O>, or WITH END-WITH or somesuch,
> whereas most others set it implicitly on method call.  As a
> consequence, the others put the object that is to become the current
> object on the data stack on a method call, while Bernd Paysan makes it
> the current object explictly at some earlier point, and then just uses
> that for the dynamic dispatch.
> 
> 
> This results in the following syntactic differences:
> 
> Calling a method FOO for the current object (THIS):
> 
> Bernd Paysan: foo
> Anton Ertl:   this foo
> 
> Callingt a method FOO for a different object BAR
> 
> Bernd Paysan:  bar >o foo o>
> Anton Ertl:    bar foo   

Hm.  I thought that :EACH would show off some other syntatic differences, but
it doesn't really:

\ [: car @ . ;]
[: { xt } o >o begin nil? 0= while xt execute cdr @ o> >o repeat o> ;] nil-class to :each

vs.

\ [: ( obj ) car @ . ;]
m: { xt } this begin { o } o nil? 0= while o xt execute  o cdr @ repeat ;m overrides :each

\ [: this car @ . ;]
m: { xt } this begin to-this  this nil? 0= while xt execute  this cdr @ repeat ;m overrides :each

These definitions are also pretty similar:

: chop ( -- )  a-list >o :shift . :shift . :shift . o to a-list o> ;
: chop ( -- )  a-list :shift . :shift . :shift . to a-list ;

> Bernd Paysan's argument was that he usually calls the method with the
> current object and that he changes the current object much less
> frequently.  Given your experiment, what do you think?  There are 9
> >O, 9 O>, and 5 O in your example, in 8 definitions.

Your comparison of syntatic differences is pretty stark, but I never minded
using >O O O> .  Working backwards from these facts, I might also guess that
the reason I don't mind them is that I don't change the current object much.
But after rewriting this example in object.fs, I'd rather argue that that >O O
O> are mentally light-weight, maybe lighter than managing an object on the data
stack.

There's anyway not a single instance of a BAR >O FOO O> in the example. 
(Although theres a lot of >O .LIST O> in my gforth-history.)


I started out wanting to use an object system, though.  If I'd started out not
knowing that I'd want that, and had a bunch of code that passed around a
black-box data structure before realizing that, then a system like objects.fs
would be easier to adapt.  If I'd instead developed a bunch of code that
depended on a vocabulary of VARIABLEs and other words before realizing that,
then mini-oof2.fs would let me write >O LEGACY-CODE-THAT-NEVER-REFERS-TO-O O> 

For example:

variable first-name
variable last-name
variable age
: greet ( -- )
  cr ." Hello, " first-name @ count type space  last-name @ count type space ;
: drink ( -- drink )
  age @ 21 >= if wine else grapejuice then ;
: welcome ( -- )  greet  drink order ;

\ wait!  We're going to have more than one guest!

\ delete those variables, replace with:
object class
  field: first-name
  field: last-name
  field: age
end-class guest

\ GREET DRINK and WELCOME did not need any changes
: greet-guests ( -- )
  begin next-guest dup while >o welcome o> repeat drop ;


-- Julian

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

#30618

On Friday, May 23, 2014 6:39:52 PM UTC+2, Julian Fondren wrote:
> On Friday, May 23, 2014 7:11:34 AM UTC-5, Anton Ertl wrote:
[..]
> : greet-guests ( -- )
>   begin next-guest dup while >o welcome o> repeat drop ;

Sorry, but I have grapejuice nor wine. That next-guest
is also not here yet, although one could argue that is
ok as there are no guests at all. 

If you think you have found something interesting, please
go the extra mile and *show* it to the infidels :-)

-marcel

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

#30621

Julian Fondren <ayrnieu@gmail.com> writes:
>Hm.  I thought that :EACH would show off some other syntatic differences, but
>it doesn't really:
>
>\ [: car @ . ;]
>[: { xt } o >o begin nil? 0= while xt execute cdr @ o> >o repeat o> ;] nil-class to :each
>
>vs.
>
>\ [: ( obj ) car @ . ;]
>m: { xt } this begin { o } o nil? 0= while o xt execute  o cdr @ repeat ;m overrides :each

Actually it does.  In objects.fs for inst-vars the access to this is
always implicit, and if you define car and cdr as inst-vars, you
cannot do this in this way; a (tail-)recursive variant would work, or
you would have to define getter methods get-car and get-cdr.  You
could also define car and cdr as fields in objects.fs, but then you
have to provide the object you refer to on every use; the general idea
was that inst-vars would be the usual thing to use.

>\ [: this car @ . ;]
>m: { xt } this begin to-this  this nil? 0= while xt execute  this cdr @ repeat ;m overrides :each

TO-THIS is an internal word and not intended to be used in an
application program.  THIS may become a local, and TO-THIS would
vanish.  However, one might provide some higher-level variant of this
(essentially something like >O O>) for the (presumably) few cases when
doing it through method calls is not good enough.

Well let me have a go at :EACH with CAR and CDR being INST-VARs (untested):

For nil-class:

m: ( xt ) drop ;m overrides :each

For cons-cell:

m: { xt } this xt execute xt cdr @ :each ;m overides each

If we want a loop, it is more cumbersome:

\ accessor words
m: car ;m alias cons-car
m: cdr ;m alias cons-cdr

: :each { xt obj -- }
  obj begin { o }
    o nil? 0= while
      o xt execute
      o cons-cdr @ 
  repeat ;

Yes, pretty much your field-based version, except that I defined a
colon def, because you are not using dynamic dispatch when calling
:EACH.

>I started out wanting to use an object system, though.  If I'd started out not
>knowing that I'd want that, and had a bunch of code that passed around a
>black-box data structure before realizing that, then a system like objects.fs
>would be easier to adapt.  If I'd instead developed a bunch of code that
>depended on a vocabulary of VARIABLEs and other words before realizing that,
>then mini-oof2.fs would let me write >O LEGACY-CODE-THAT-NEVER-REFERS-TO-O O> 

Yes, the latter observation is was the motivation/justification for
Bernd's (big) OOF; it makes this stuff much easier than even mini-oof2
by defining instance bariables with VARIABLE and methods with ":".

- 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 2014: http://www.euroforth.org/ef14/

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

#30753

The problem with us Forthers is that that we never ever agree on anything.

A long long time ago I wrote some articles in Forth Dimensions advocating the concept and efficiency of having a 'current object' (it was not really called that):

http://www.forth.org/literature/andras.html
http://www.forth.org/literature/oopf.html

In the system described classes behaved properly as name spaces.

There is even an implementation in ANS Forth (although a lot less efficient than hand crafted assembly):
ftp://ftp.taygeta.com/pub/Forth/Compilers/native/unix/Linux/oofemu.4th

But that is just my take on doing OOP in Forth.
The problem seems to be that every one of us has a completely different idea what object-oriented Forth should be, so instead of having some common ground everyone has a pet implementation that usually turns out to be unacceptable to everyone else.

OK, I have mostly given up Forth for the real world, so this is just nostalgia...

Andras
http://forth.teleonomix.com/

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

#30824

On Monday, 26 May 2014 18:23:50 UTC+1, andras...@gmail.com  wrote:
> The problem with us Forthers is that that we never ever agree on anything.

True. And I spent a little time recently reflecting on why that was/is. I concluded that it's simply due to the power of the Forth language. The reason people disagree on the implementation of (for example) and OOP system in Forth, is purely down to the fact that you can *actually implement an OOP sytem in Forth yourself* right there at the keyboard, in Forth.

There's no disagreement in the Java world, or the .Net world (for example) because the system(s) are provided for you by the vendor, and you just go and use them, putting up with any idiosyncracities on the way. Nothing you can do about them.

It's not like that in Forth.

In Forth, the only limiting factor seems to be the bit between the keyboard and the chair.

Chuck Moore *so* nailed it in 1970, it's just not funny!

Of course, that Forth is so powerful doesn't make it the best language (or perhaps I should say 'tool'). Obviously, one picks the right tool for the job at hand. Nothing wrong with Java or .Net. I've used both and like both. YOu pick your horse for the course you're running on.

I was particularly intrigued by a comment in your blog about the way people interacted with Chuck Moore:

"There were other aspects of working on a Forth only project that gave me interesting insight. For example working in the same office as the inventor of Forth for years, and watching people interact with him did give me the eery feeling that Forth was not so much a programming language as some sort of cult."

Care to expand on that (without naming names?). I know Jeff Fox was involved in the i21 project, and he was fully behind Chuck Moore. He was also very much a Forth evangelist. He and I disagreed on the use of other languages; as far as he was concerned, Forth was perfect for everything. I disagreed. If you want libraries of code, or you want to tap into the programmer labour market for staff, Forth aint the way.

I enjoyed your blog and your articles on OOP. I hope you continue to update your blog. Please post here on CLF if you do.

Regards

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

#30833

Mark Wills <markwills1970@gmail.com> wrote:
> On Monday, 26 May 2014 18:23:50 UTC+1, andras...@gmail.com  wrote:
>> The problem with us Forthers is that that we never ever agree on anything.
> 
> True. And I spent a little time recently reflecting on why that
> was/is. I concluded that it's simply due to the power of the Forth
> language. The reason people disagree on the implementation of (for
> example) and OOP system in Forth, is purely down to the fact that
> you can *actually implement an OOP sytem in Forth yourself* right
> there at the keyboard, in Forth.
> 
> There's no disagreement in the Java world, or the .Net world (for
> example) because the system(s) are provided for you by the vendor,
> and you just go and use them, putting up with any idiosyncracities
> on the way. Nothing you can do about them.

Not quite: the Java (and I guess .NET) VM is simple enough and
flexible enough that you can implement your own language on it.  And
people do; there are lots of them.

Andrew.

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

#30904

Cult aspects -- company meetings started to look like this:
http://youtu.be/55fqjw2J1vI

Programming, just like science should be based on facts. "Ipse dixit" is not a valid argument.

When a bunch of people who only have ever programmed in Forth spend day in and day out whining about how bad C programs are and how good everything in Forth is and then fail to deliver a product that is just sad.

On Tuesday, May 27, 2014 5:09:19 AM UTC-4, Mark Wills wrote:
> On Monday, 26 May 2014 18:23:50 UTC+1, andras...@gmail.com  wrote:
> 
> > The problem with us Forthers is that that we never ever agree on anything.
> 
> 
> 
> True. And I spent a little time recently reflecting on why that was/is. I concluded that it's simply due to the power of the Forth language. The reason people disagree on the implementation of (for example) and OOP system in Forth, is purely down to the fact that you can *actually implement an OOP sytem in Forth yourself* right there at the keyboard, in Forth.
> 
> 
> 
> There's no disagreement in the Java world, or the .Net world (for example) because the system(s) are provided for you by the vendor, and you just go and use them, putting up with any idiosyncracities on the way. Nothing you can do about them.
> 
> 
> 
> It's not like that in Forth.
> 
> 
> 
> In Forth, the only limiting factor seems to be the bit between the keyboard and the chair.
> 
> 
> 
> Chuck Moore *so* nailed it in 1970, it's just not funny!
> 
> 
> 
> Of course, that Forth is so powerful doesn't make it the best language (or perhaps I should say 'tool'). Obviously, one picks the right tool for the job at hand. Nothing wrong with Java or .Net. I've used both and like both. YOu pick your horse for the course you're running on.
> 
> 
> 
> I was particularly intrigued by a comment in your blog about the way people interacted with Chuck Moore:
> 
> 
> 
> "There were other aspects of working on a Forth only project that gave me interesting insight. For example working in the same office as the inventor of Forth for years, and watching people interact with him did give me the eery feeling that Forth was not so much a programming language as some sort of cult."
> 
> 
> 
> Care to expand on that (without naming names?). I know Jeff Fox was involved in the i21 project, and he was fully behind Chuck Moore. He was also very much a Forth evangelist. He and I disagreed on the use of other languages; as far as he was concerned, Forth was perfect for everything. I disagreed. If you want libraries of code, or you want to tap into the programmer labour market for staff, Forth aint the way.
> 
> 
> 
> I enjoyed your blog and your articles on OOP. I hope you continue to update your blog. Please post here on CLF if you do.
> 
> 
> 
> Regards

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

#30828

andraszsoter@gmail.com wrote:
> The problem with us Forthers is that that we never ever agree on anything.
> 
> A long long time ago I wrote some articles in Forth Dimensions
> advocating the concept and efficiency of having a 'current object'
> (it was not really called that):
> 
> http://www.forth.org/literature/andras.html
> http://www.forth.org/literature/oopf.html
> 
> In the system described classes behaved properly as name spaces.
> 
> There is even an implementation in ANS Forth (although a lot less efficient than hand crafted assembly):
> ftp://ftp.taygeta.com/pub/Forth/Compilers/native/unix/Linux/oofemu.4th
> 
> But that is just my take on doing OOP in Forth.

> The problem seems to be that every one of us has a completely
> different idea what object-oriented Forth should be, so instead of
> having some common ground everyone has a pet implementation that
> usually turns out to be unacceptable to everyone else.

My take on it: early on, a lot of Forthers saw the surface of OOP but
didn't use any OOP languages or systems for long enough to understand
how object-oriented design could work.  Then they would present a
half-baked Forth OOP system but some fundamental OO design patterns
(eg proxies) didn't work because they author had never heard of them.
This is less true than it used to be because OO design is now better
known.

This doesn't just apply to OO in Forth: Smalltalk got most of this
stuff right, but it was an improvement over most of its successors.

Andrew.

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

#30830

On Tuesday, 27 May 2014 11:39:58 UTC+1, Andrew Haley  wrote:
> This doesn't just apply to OO in Forth: Smalltalk got most of this
> stuff right, but it was an improvement over most of its successors.

Curious: What was Smalltalk a successor to (in OOP terms)? I was under the impression that Smalltalk was the physical manifestation of the invention of OOP, written by the guys that dreamed up the subject. No?

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

#30832

Never mind. As usual, the Internet has the answer. Before Smalltalk was Simula (Norwegian) that is generally considered to be the first object oriented language.

http://en.wikipedia.org/wiki/Simula

Learned something today. Thanks!

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

#30834

Mark Wills <markwills1970@gmail.com> wrote:
> On Tuesday, 27 May 2014 11:39:58 UTC+1, Andrew Haley  wrote:
>> This doesn't just apply to OO in Forth: Smalltalk got most of this
>> stuff right, but it was an improvement over most of its successors.
> 
> Curious: What was Smalltalk a successor to (in OOP terms)? I was
> under the impression that Smalltalk was the physical manifestation
> of the invention of OOP, written by the guys that dreamed up the
> subject. No?

No.  The origin of OO was really Nygaard and Dahl's SIMULA, which also
had a fair bit of inspiration from Hoare.  (Kristen Nygaard spmetimes
began sentences with "When I dicovered object-oriented
programming... :-)  Smalltalk was the first language to apply the
princple consistently.

Andrew.

http://amturing.acm.org/award_winners/nygaard_5916220.cfm

[toc] | [prev] | [standalone]

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

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

csiph-web