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

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

Opinions on googl's go language?

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

Contents

  Opinions on googl's go language? the_gavino_himself <visphatesjava@gmail.com> - 2012-12-26 02:13 -0800
    Re: Opinions on googl's go language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-27 16:53 -0800
      Re: Opinions on googl's go language? The Beez <the.beez.speaks@gmail.com> - 2012-12-28 02:49 -0800
        Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-28 07:59 -0600
          Re: Opinions on googl's go language? "A. K." <akk@nospam.org> - 2012-12-28 16:26 +0100
            Re: Opinions on googl's go language? Richard Owlett <rowlett@pcnetinc.com> - 2012-12-28 11:21 -0600
              Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-12-28 17:23 +0000
                Re: Opinions on googl's go language? Richard Owlett <rowlett@pcnetinc.com> - 2012-12-28 16:20 -0600
                  Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-08 17:55 +0000
                Re: Opinions on googl's go language? mhx@iae.nl (Marcel Hendrix) - 2012-12-28 23:48 +0200
                Re: Opinions on googl's go language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-28 23:56 +0100
                  Re: Opinions on googl's go language? gavino_himself <visploveslisp@gmail.com> - 2013-01-06 03:53 -0800
                  Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-08 16:22 +0000
                    Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-08 12:34 -0600
                      Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-23 16:40 +0000
                        Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 11:36 -0600
                          Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-24 12:46 +0000
                            Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-24 09:17 -0600
                              Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-24 17:23 +0000
                                Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-24 13:16 -0600
                                  Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-05 17:59 +0000
                                    Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 12:38 -0600
              Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-30 03:24 -0600
                Re: Opinions on googl's go language? Richard Owlett <rowlett@pcnetinc.com> - 2012-12-30 12:14 -0600
                  Re: Opinions on googl's go language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-30 22:17 +0100
            Re: Opinions on googl's go language? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-30 03:22 -0600
              Re: Opinions on googl's go language? Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-30 14:25 +0100
          Re: Opinions on googl's go language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-28 20:55 -0800
            Re: Opinions on googl's go language? The Beez <the.beez.speaks@gmail.com> - 2012-12-29 03:35 -0800
              Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2012-12-29 11:49 -0500
                Re: Opinions on googl's go language? The Beez <the.beez.speaks@gmail.com> - 2012-12-30 01:57 -0800
                  Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2012-12-30 07:01 -0500
                    Re: Opinions on googl's go language? The Beez <the.beez.speaks@gmail.com> - 2012-12-31 00:29 -0800
                  Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2013-01-02 09:18 -0500
                    Re: Opinions on googl's go language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-02 20:32 -0800
                      Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2013-01-03 06:56 -0500
                    Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-08 15:50 +0000
                      Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2013-01-08 21:41 -0500
                        Re: Opinions on googl's go language? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-23 16:55 +0000
                          Re: Opinions on googl's go language? Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-23 20:23 +0100
                          Re: Opinions on googl's go language? Doug Hoffman <glidedog@gmail.com> - 2013-01-24 09:46 -0500
            Re: Opinions on googl's go language? Alex McDonald <blog@rivadpm.com> - 2012-12-29 07:41 -0800
        Re: Opinions on googl's go language? gavino_himself <visploveslisp@gmail.com> - 2012-12-29 19:29 -0800
    Re: Opinions on googl's go language? tcholoka@gmail.com - 2013-01-03 09:36 -0800
      Re: Opinions on googl's go language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-06 00:32 -0800
        Re: Opinions on googl's go language? Mark Wills <forthfreak@gmail.com> - 2013-01-06 01:26 -0800
        Re: Opinions on googl's go language? gavino_himself <visploveslisp@gmail.com> - 2013-01-06 03:57 -0800
        Re: Opinions on googl's go language? tcholoka@gmail.com - 2013-01-06 06:02 -0800
          Re: Opinions on googl's go language? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-07 23:41 -0800
            Re: Opinions on googl's go language? tcholoka@gmail.com - 2013-01-08 00:15 -0800
      Re: Opinions on googl's go language? gavino_himself <visploveslisp@gmail.com> - 2013-01-06 03:56 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#19477

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>Perhaps, but to do so you'd have to convert each C expression into a
>>>>>sequence of instructions.  It's easier to see what is going on in
>>>>>assembly.
>>>> 
>>>> For algorithms?
>>>
>>>No, for exact timing.
>> 
>> There's no exact timing with assembly language on modern CPUs, either,
>> and even if Knuth defines one for MMIX, it does not transfer any
>> better to real machines than a performance model based on C (or what C
>> used to be).
>
>But when discussing algorithms you need something better than big-O
>notation when talking about efficiency, so you need to be able to talk
>about the the time taken by specific operations, and to do that you
>need to be able to talk about instructions.

Or one might just talk about operations: x additions, y loads, z
stores, w branches, v cache misses, u branch mispredictions etc.

And if you want instructions and accurate timing, show the assembly
code (on some real architecture) and present timings from an
implementation of that architecture, or maybe several; and performance
counter results for various operations.

>And of course, this won't correspond exactly to any particular
>modern CPU, but some people's mental machinery needs something
>concrete.

What I suggest would be just as concrete and corresponds to at least
one modern CPU.

>>>>>> However, that is contrary to my mental model of C performance, which
>>>>>> says that function calls have a much higher cost than a memory access
>>>>>> through a pointer.
>>>>>
>>>>>Your mental model of C performance is wrong.
>>>> 
>>>> It is?  You mean, that every version of every C compiler with any
>>>> optimization options will compile this memcpy() to a simple unaligned
>>>> memory-to-register load?
>>>
>>>No, I mean that on some processors unaligned loads are hard, and on
>>>some they're not.
>> 
>> I knew beforehand that on some architectures unaligned loads take a
>> few instructions (three on Alpha IIRC).  I expected beforehand that
>> my code would cause an exception on such machines (I even documented
>> that dependency), so I did not expect that code to perform on such
>> machines at all.  Why did you say that my mental model of C
>> performance is wrong?
>
>Because that model does not correspond with reality.  What other test
>of a model is there?

Is there any performance model that always corresponds to reality?
No.  So if you wanted to state a truism, you succeeded.  I just
thought that there was something more substantial to your statement.

>> In a real low-level language (like the GNU C compiled by gcc 2.x) the
>> mapping is not 1:1, but it's relatively simple.  The kind of
>> unpredictable performance that you get with stuff like the memcpy()
>> trick is removing this important feature of C, which leads me to the
>> "intersection" assessment above.
>
>I guess the difference here is our expectations.  I've never really
>thought of C as being like that.  One programmer's bug is another
>programmer's feature.

You consider unpredictable performance a feature?  In a low-level
language?

>>>> No, it's only fast with memcpy() if the compiler can perform this
>>>> optimization in general and if if succeeds in performing this
>>>> optimization in this particular case.  If it does not, not only will
>>>> the call to memcpy() be slow, but other accesses to this local will be
>>>> slow, too, because the local is forced into memory.
>>>
>>>Well, yes, but that's true of everything a compiler does.
>> 
>> No, that's not true of proper language features.  Show me a compiler
>> for, say, AMD64 that compiles a function call for *p, where p points
>> to an unsigned long.
>
>Ah, OK.  :-)  Of course, you can argue reductio ad absurdum if you
>want.

How does "reductio ad absurdum" come into play here?

>  But this is an entirely circular argument, defining a "proper
>language feature" to suit yourself.

What is circular here?  And of course I use suitable terms, and if I
had to define them, I would define them in a suitable way.  Would you
prefer if I used unsuitable terms in an argument?

>>>I think you're making this up as you go along.  memcpy() to a local is
>>>a language feature.
>> 
>> K&R (2nd Ed.) never mentioned it, and I also never saw it in any other
>> books about C.
>
>It's there, though.

Where is it?

- 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 2013: http://www.euroforth.org/ef13/

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

#19479

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>Perhaps, but to do so you'd have to convert each C expression into a
>>>>>>sequence of instructions.  It's easier to see what is going on in
>>>>>>assembly.
>>>>> 
>>>>> For algorithms?
>>>>
>>>>No, for exact timing.
>>> 
>>> There's no exact timing with assembly language on modern CPUs, either,
>>> and even if Knuth defines one for MMIX, it does not transfer any
>>> better to real machines than a performance model based on C (or what C
>>> used to be).
>>
>>But when discussing algorithms you need something better than big-O
>>notation when talking about efficiency, so you need to be able to talk
>>about the the time taken by specific operations, and to do that you
>>need to be able to talk about instructions.
> 
> Or one might just talk about operations: x additions, y loads, z
> stores, w branches, v cache misses, u branch mispredictions etc.

Indeed.  And the assembly language is a list of operations.

> And if you want instructions and accurate timing, show the assembly
> code (on some real architecture) and present timings from an
> implementation of that architecture, or maybe several; and performance
> counter results for various operations.

So you have to use assembly language, one way or another.  QED.

>>And of course, this won't correspond exactly to any particular
>>modern CPU, but some people's mental machinery needs something
>>concrete.
> 
> What I suggest would be just as concrete and corresponds to at least
> one modern CPU.

OK.  I personally don't see any significant difference.  It shouldn't
be too tied to any particular architecture.  But all this is a matter
of taste.

>>> In a real low-level language (like the GNU C compiled by gcc 2.x) the
>>> mapping is not 1:1, but it's relatively simple.  The kind of
>>> unpredictable performance that you get with stuff like the memcpy()
>>> trick is removing this important feature of C, which leads me to the
>>> "intersection" assessment above.
>>
>>I guess the difference here is our expectations.  I've never really
>>thought of C as being like that.  One programmer's bug is another
>>programmer's feature.
> 
> You consider unpredictable performance a feature?  In a low-level
> language?

C is not really a low-level language.  Not so low-level that you can
just translate it 1-to-1 into machine instructions, anyway.

>>>>I think you're making this up as you go along.  memcpy() to a local is
>>>>a language feature.
>>> 
>>> K&R (2nd Ed.) never mentioned it, and I also never saw it in any other
>>> books about C.
>>
>>It's there, though.
> 
> Where is it?

Every time you use it, it's there.  Obviously.  And I have already
demonstrated that this feature works, with an example.  You can hardly
deny that it works; and if it works, it exists.  QED.

Andrew.

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

#18336

Richard Owlett <rowlett@pcnetinc.com> wrote:

> Reading Andrew's post got me thinking. As both a teaching tool and
> attention grabber might an appropriately visual Turing Machine
> simulator be useful as a primary/secondary school tool?

A Turing Machine is a terrible computer; it's only really interesting
in a historical context.  It's easier to understand something like
pure LISP.

Andrew.

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

#18341

Andrew Haley wrote:
> Richard Owlett <rowlett@pcnetinc.com> wrote:
>
>> Reading Andrew's post got me thinking. As both a teaching tool and
>> attention grabber might an appropriately visual Turing Machine
>> simulator be useful as a primary/secondary school tool?
>
> A Turing Machine is a terrible computer;

In the context of "instructional aids", that matters how?
Which would be a better teaching aid - a detailed exploded 
view of:
    one of Goddard's rockets?
    a V2?

> it's only really interesting in a historical context.

Open to debate.

> It's easier to understand something like pure LISP.

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

#18348

Richard Owlett wrote:

> Andrew Haley wrote:
>> A Turing Machine is a terrible computer;
> 
> In the context of "instructional aids", that matters how?

Yes, it matters.  As a student, you can't do anything useful with a 
Turing machine, despite you learn a proof that it is indeed useful.  
Even those things you try, it does not offer any usable insight into how 
you would write that on a computer of today's design.  The Turing 
machine is from 1936.  The Zuse Z1 is from 1937.  The Zuse Z1 is a 
small, but useful machine where you can do simple calculations with 
little effort; it has about the same programming paradigm as modern 
machines (register transfer language), but it is severely limited.  The 
Turing machine is universal, but it has a programming model that didn't 
catch on.  The Turing machine represents a dead end, the Zuse Z1 
doesn't; in essence, it's a Harward architecture, because the program 
was on punched tape.

> Which would be a better teaching aid - a detailed exploded
> view of:
>     one of Goddard's rockets?
>     a V2?

Goddard's rockets are fun, but I doubt what teaching value they have, 
apart from history.  Goddard tried to create liquid fuel rockets, a type 
of rocket that is much more complicated than the standard solid fuel 
rocket, but he didn't solve all the problems.  The exploded view of a 
solid fuel rocket is very simple: It is a tube, filled with something 
that's damn'd near an explosive, and some way to ignite it.  It works, 
it is extremely simple to explain, and it has obvious shortcomings, like 
that you have no dynamic control of the thrust - it just burns the fuel 
as it is, and will only stop when all fuel has been exhausted.

The V2 has the advantage of being the ancestor of most, if not all, 
liquid fuel rockets of today, and showing that a liquid fuel rocket is a 
really complicated thing if you think about all of the problems you have 
to solve there.

>> it's only really interesting in a historical context.
> 
> Open to debate.

Probably similar to the Goddard rocket - interesting in a historical 
context, not useful to explain people how a modern rocket works by using 
a simpler version of a modern rocket engine (which the V2 still is).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#18335

A. K. <akk@nospam.org> wrote:
> On 28.12.2012 14:59, Andrew Haley wrote:
>>
>> Of course, knowledge of machine language isn't sufficient to
>> understand everything, but it's a huge help.  Many students aren't
>> taught such things today and they're at a huge disadvantage when
>> compared with my generation.
> 
> Really?

Yes.

> It seems that it has become cheaper to throw more hardware into
> systems than optimizing and tuning software.

But, oddly, firms making smartphone processors have roomfuls of people
doing just that.

> Eg Samsung's S4 smartphone S4 is driven by a quad core CPU (just a
> few years ago that was the ultimate high performance server
> CPU). But does it help students to understand the system by
> memorizing its machine instructions?

I'm not at all sure about the need to memorize all the instructions.
However, unless you understand machine language it's much harder to
understand how to solve performance problems or, indeed, to create
efficient programs in the first place.  And besides that, it's very
easy to forget that all those interpreters, virtual machines, and
compilers don't write themselves.

Andrew.

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

#18339

Andrew Haley wrote:
>> Eg Samsung's S4 smartphone S4 is driven by a quad core CPU (just a
>> few years ago that was the ultimate high performance server
>> CPU). But does it help students to understand the system by
>> memorizing its machine instructions?
> 
> I'm not at all sure about the need to memorize all the instructions.

You two seem to have a communication problem.  The thing you need to 
know is the *concepts* a machine uses, not the mnemonics.

> However, unless you understand machine language it's much harder to
> understand how to solve performance problems or, indeed, to create
> efficient programs in the first place.

It also often helps for efficient programs to look at the compiler 
output.  If you say WTF? too often, the compiler has troubles compiling 
your program.  You need to fix either the program or the compiler.

> And besides that, it's very
> easy to forget that all those interpreters, virtual machines, and
> compilers don't write themselves.

Ah, they are all written by the olt farts with grey beards, who are of 
no good use, because they frown at the language of the year ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#18329

On Dec 28, 6:59 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> The Beez <the.beez.spe...@gmail.com> wrote:
> > I learned that in 1986 (about, for arguments sake) when I spent
> > weeks reading a host of C manuals and ended up with a 12 hour
> > session making a page-long C program. BTW, one of the best books on
> > C is "Advanced C" by the Andersons and the always helpful -S option
> > of the C compiler.
>
> > BTW, I learned Forth by decompiling the whole darn thing (to Z80
> > assembly) and the Appendix of "Advanced Abersoft Forth". Books were
> > of very little use.
>
> I think that if you know machine language you have a huge advantage
> over those who don't.  All programming languages, no matter how
> complex, are ultimately reducible to those machine instructions.
> Knowledge of them gives you a key that helps you to understand
> everything that a computer does.
>
> Of course, knowledge of machine language isn't sufficient to
> understand everything, but it's a huge help.  Many students aren't
> taught such things today and they're at a huge disadvantage when
> compared with my generation.
>
> Andrew.

I agree with this.

I remember when I first tried to learn OOP in the early 1990s, that I
was totally baffled. The problem was that all of the terms, such as
inheritance and polymorphism and so forth, were not defined in what I
read. Instead of definitions, I mostly got analogies, such as to the
platypus, and a lot of examples.  I had no idea what OOP was. My
impression was that nobody else did either, because otherwise they
would have defined the terms rather than just provide examples. I was
about to give up on learning OOP altogether, when I decided to read
about how OOP compiles were written. Considering that I had never
written an OOP program and had no idea what OOP was, it seemed like a
pretty big leap to go straight into compiler-writing. I supposed
though, that the compiler writers must have something more to go on
than hand-waving discussions about the platypus in order to succeed in
writing a compiler. They did! Suddenly, everything made sense. OOP is
actually quite simple. It is just structs with new fields tacked onto
them --- the old functions that work on that struct still work on the
new struct because the old fields are still in the same place, but we
also have new functions that only work on the new struct because they
access the new fields --- that is inheritance. When I saw assembly
code implementing all of this, it was clear to me. My first efforts in
Forth were similar to Oberon which does not have a VMT, but rather
just implements virtual functions as fields containing pointers to
functions. Then I figured out how the VMT works, and how this
simplifies the constructor significantly and also saves a lot of
memory in the struct. After I figured out inheritance and the VMT, the
concept of polymorphism became obvious, although I never implemented
that as I didn't think it was Forth-like (and I still don't).

I think there is a tendency for some programmers to spout a lot of
abstract high-brow terminology, and not have the slightest idea how
any of this is implemented under the hood. They succeed mostly a
script kiddies, pasting together code written by other people, but
they can't write a program themselves.

In order to understand a concept, you really have to understand it at
the assembly-language level. If you don't, then you are just faking
it. If you can't write a compiler for a language, then you don't know
the language.

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

#18331

On Dec 29, 5:55 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> OOP is
> actually quite simple. It is just structs with new fields tacked onto
> them --- the old functions that work on that struct still work on the
> new struct because the old fields are still in the same place, but we
> also have new functions that only work on the new struct because they
> access the new fields --- that is inheritance. When I saw assembly
> code implementing all of this, it was clear to me.
Agreed again! Although I'm hardly a OOP proponent it's actually quite
simple to implement once you discard this mumbo-jumbo jargon of the
OOP crowd and get back to the basics. I wrote an article on that in my
4tH manual (where OOP is implemented as part of the preprocessor) and
published it online as well. Note it has been amended since. Your
statement could be a literal quote from that ;-)

http://code.google.com/p/4th/wiki/ObjectOrientation

Hans Bezemer

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

#18333

On 12/29/12 6:35 AM, The Beez wrote:

>Although I'm hardly a OOP proponent it's actually quite
> simple to implement once you discard this mumbo-jumbo jargon of the
> OOP crowd and get back to the basics.

Using a word or two to represent an idea or concept is pretty common. 
What terms do you consider to be mumbo-jumbo and what terminology would 
you use instead?  I've read your wiki and don't find a concise 
replacement terminology.

-Doug

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

#18337

On Dec 29, 5:49 pm, Doug Hoffman <glide...@gmail.com> wrote:
> Using a word or two to represent an idea or concept is pretty common.
> What terms do you consider to be mumbo-jumbo and what terminology would
> you use instead?  I've read your wiki and don't find a concise
> replacement terminology.
I don't need to replace it, its already there:
- class = structure (with function pointers)
- selector = function pointer field
- method = execution token
- property = field
- object = allocated space (of structure)
- sending a message = invocation by name
- invoking a method = invocation by reference
- virtual method = overwritable function pointer
- early binding = at compile time
- late binding = at runtime
- subtyping = extending a structure
- encapsulation = combining data and functions (in a structure)
- inheritence = cascaded initialization

Enough?

Hans Bezemer

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

#18338

On 12/30/12 4:57 AM, The Beez wrote:
> On Dec 29, 5:49 pm, Doug Hoffman <glide...@gmail.com> wrote:
>> Using a word or two to represent an idea or concept is pretty common.
>> What terms do you consider to be mumbo-jumbo and what terminology would
>> you use instead?  I've read your wiki and don't find a concise
>> replacement terminology.
> I don't need to replace it, its already there:
> - class = structure (with function pointers)
> - selector = function pointer field
> - method = execution token
> - property = field
> - object = allocated space (of structure)
> - sending a message = invocation by name
> - invoking a method = invocation by reference
> - virtual method = overwritable function pointer
> - early binding = at compile time
> - late binding = at runtime
> - subtyping = extending a structure
> - encapsulation = combining data and functions (in a structure)
> - inheritence = cascaded initialization
>
> Enough?
>
> Hans Bezemer

You confused me with your statement:

"Although I'm hardly a OOP proponent it's actually quite
simple to implement once you discard this mumbo-jumbo jargon of the
OOP crowd"

What you show above looks pretty much like the common terms with 
commonly accepted meaning.

-Doug

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

#18357

On Dec 30, 1:01 pm, Doug Hoffman <glide...@gmail.com> wrote:
> "Although I'm hardly a OOP proponent it's actually quite
> simple to implement once you discard this mumbo-jumbo jargon of the
> OOP crowd"
>
> What you show above looks pretty much like the common terms with
> commonly accepted meaning.
There you go: to you it is the meaning, to me it is the term.

Hans Bezemer

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

#18395

On 12/30/12 4:57 AM, The Beez wrote:
> On Dec 29, 5:49 pm, Doug Hoffman <glide...@gmail.com> wrote:
>> Using a word or two to represent an idea or concept is pretty common.
>> What terms do you consider to be mumbo-jumbo and what terminology would
>> you use instead?  I've read your wiki and don't find a concise
>> replacement terminology.
> I don't need to replace it, its already there:
> - class = structure (with function pointers)
> - selector = function pointer field
> - method = execution token
> - property = field
> - object = allocated space (of structure)
> - sending a message = invocation by name
> - invoking a method = invocation by reference
> - virtual method = overwritable function pointer
> - early binding = at compile time
> - late binding = at runtime
> - subtyping = extending a structure
> - encapsulation = combining data and functions (in a structure)
> - inheritence = cascaded initialization
>
> Enough?

Actually, on further reflection I would add the following:

- polymorphism
- method over riding (perhaps what you call overwriting a function pointer?)
- information hiding
- instance variable (probably what you call a property or field)

We are apparently just talking about class-based OOP in this thread, 
which is OK as long as we acknowledge that.

Some define polymorphism as "the ability of sub-type objects to respond 
to the same messages in different ways".  But this would be the more 
confining definition/implementation.  The more Forth-like way, IMO, 
would be to use duck typing where any message can be sent to any object 
without concern for class hierarchy.  So I guess I would add another term:

- duck typing

Lastly the following two terms are needed to be a bit more complete:

- single inheritance
- multiple inheritance  (yes, we have this available now in ANS Forth)

-Doug

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

#18410

On Jan 2, 7:18 am, Doug Hoffman <glide...@gmail.com> wrote:
> Some define polymorphism as "the ability of sub-type objects to respond
> to the same messages in different ways".  But this would be the more
> confining definition/implementation.  The more Forth-like way, IMO,
> would be to use duck typing where any message can be sent to any object
> without concern for class hierarchy.  So I guess I would add another term:
>
> - duck typing

Duck-typing is "Forth-like"??? That is Factor-like. I remember you
from the Factor mailing list. Why did you leave?

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

#18416

On 1/2/13 11:32 PM, Hugh Aguilar wrote:
> On Jan 2, 7:18 am, Doug Hoffman <glide...@gmail.com> wrote:
>> Some define polymorphism as "the ability of sub-type objects to respond
>> to the same messages in different ways".  But this would be the more
>> confining definition/implementation.  The more Forth-like way, IMO,
>> would be to use duck typing where any message can be sent to any object
>> without concern for class hierarchy.  So I guess I would add another term:
>>
>> - duck typing
>
> Duck-typing is "Forth-like"???

In the sense that it has no restrictions on "type".  This is just my 
opinion.

> That is Factor-like.

I'll take your word for it as I know very little about Factor.  Good for 
Factor in providing duck typing.

> I remember you
> from the Factor mailing list.

Never been on any such list.  Hoffman is a common name.

-Doug

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

#18567

Doug Hoffman <glidedog@gmail.com> writes:
>On 12/30/12 4:57 AM, The Beez wrote:
>> On Dec 29, 5:49 pm, Doug Hoffman <glide...@gmail.com> wrote:
>>> Using a word or two to represent an idea or concept is pretty common.
>>> What terms do you consider to be mumbo-jumbo and what terminology would
>>> you use instead?  I've read your wiki and don't find a concise
>>> replacement terminology.
>> I don't need to replace it, its already there:
>> - class = structure (with function pointers)
>> - selector = function pointer field
>> - method = execution token
>> - property = field
>> - object = allocated space (of structure)
>> - sending a message = invocation by name
>> - invoking a method = invocation by reference
>> - virtual method = overwritable function pointer
>> - early binding = at compile time
>> - late binding = at runtime
>> - subtyping = extending a structure
>> - encapsulation = combining data and functions (in a structure)
>> - inheritence = cascaded initialization
>>
>> Enough?

That's mostly an implementation-oriented view.  While knowing about
the implementation can help understand the concepts, if you think only
in implementation terms of a single implementation, you probably miss
a lot of aspects of the concepts.

E.g., if an assembly language programmer looks at a simple
implementation of Forth and then says

- stack = memory
- wordlist = linked list
- dictionary = upwards-growing stack

etc., and then thinks he has understood Forth, he will probably miss
quite a lot of things that are important for Forth.

>Some define polymorphism as "the ability of sub-type objects to respond 
>to the same messages in different ways".  But this would be the more 
>confining definition/implementation.  The more Forth-like way, IMO, 
>would be to use duck typing where any message can be sent to any object 
>without concern for class hierarchy.

Yes, no need to mention sub-types in a definition of polymorphism;
and, by contrast, when you talk about duck typing, there is a
(usually) implicit supertype in play: it is the set of all
classes/types for which you can invoke a given set of selectors (or,
in "message" terminology, that which respond to a given set of message
selectors).  This supertype is the "duck" of "duck typing".

- 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 2012: http://www.euroforth.org/ef12/

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

#18594

On 1/8/13 10:50 AM, Anton Ertl wrote:
> Doug Hoffman <glidedog@gmail.com> writes:

>> Some define polymorphism as "the ability of sub-type objects to respond
>> to the same messages in different ways".  But this would be the more
>> confining definition/implementation.  The more Forth-like way, IMO,
>> would be to use duck typing where any message can be sent to any object
>> without concern for class hierarchy.
>
> Yes, no need to mention sub-types in a definition of polymorphism;
> and, by contrast, when you talk about duck typing, there is a
> (usually) implicit supertype in play: it is the set of all
> classes/types for which you can invoke a given set of selectors (or,
> in "message" terminology, that which respond to a given set of message
> selectors).

I tend not to think of selectors(messages) as belonging to a set of 
messages.  Instead, each message is stand alone and used in any class on 
an ad hoc basis.  I find value in re-using message names to the maximum 
extent - of course the message names must make sense for the 
object/method.  Names such as PRINT PUT GET come to mind as usable for 
most any object type and their meaning is clear.  Fewer message names 
means fewer to remember and of course fewer new names to invent.  But I 
suppose this could be overdone.  One thing that I have not been good 
with in practice is assuring that the same messages consume and return 
the same number of stack items for differing object types.  Doing so 
better enables iterating over a collection of dissimilar objects.  I 
think.  Haven't thought this through fully.

-Doug

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

#19052

Doug Hoffman <glidedog@gmail.com> writes:
>On 1/8/13 10:50 AM, Anton Ertl wrote:
>> Doug Hoffman <glidedog@gmail.com> writes:
>> Yes, no need to mention sub-types in a definition of polymorphism;
>> and, by contrast, when you talk about duck typing, there is a
>> (usually) implicit supertype in play: it is the set of all
>> classes/types for which you can invoke a given set of selectors (or,
>> in "message" terminology, that which respond to a given set of message
>> selectors).
>
>I tend not to think of selectors(messages) as belonging to a set of 
>messages.  Instead, each message is stand alone and used in any class on 
>an ad hoc basis.  I find value in re-using message names to the maximum 
>extent - of course the message names must make sense for the 
>object/method.  Names such as PRINT PUT GET come to mind as usable for 
>most any object type and their meaning is clear.

PUT and GET are useful for containers, and for them their meaning may
be clear.  But for a numeric class there is no clear meaning, and I
would not expect it to understand GET and PUT.  So here we have an
example of a set of selectors that makes up an implicit supertype: PUT
and GET make up the implicit supertype "container".

>Fewer message names 
>means fewer to remember and of course fewer new names to invent.  But I 
>suppose this could be overdone.  One thing that I have not been good 
>with in practice is assuring that the same messages consume and return 
>the same number of stack items for differing object types.

Yes, that is essential.  If you don't have that, having the same name
does not help in remembering, on the contrary, it means we have more
to remember: for each combination of class and selector, you have to
remember the stack effect.  With different names for different stack
effects, you just have to remember one stack effect per name, not per
name/class combination.

- 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 2012: http://www.euroforth.org/ef12/

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

#19060

Anton Ertl wrote:
> Yes, that is essential.  If you don't have that, having the same name
> does not help in remembering, on the contrary, it means we have more
> to remember: for each combination of class and selector, you have to
> remember the stack effect.  With different names for different stack
> effects, you just have to remember one stack effect per name, not per
> name/class combination.

As far as I used variable stack effects, I used it only on three 
selectors: the constructor (which is obviously different for different 
classes), and a variant of get/set, which obtains the state of a MINOS 
widget.  Of course, a toggle button will return a flag, a slider a 
number (the position), and a text input widget the text.  That kind of 
stuff is not difficult to remember.  The reason why to use the same 
get/set selector is that many widgets are actually combound widgets 
(i.e. boxes), and you ask the box for the content.  The box then 
delegates this query to an object within, which knows what to return.  
Therefore, the box, the container, needs a single interface for that, 
even though the stack effect is different.

Most other selectors have exactly the same stack effect for polymorphism 
reasons: If you write generic functions with polymorphic methods, the 
stack effect must be identical.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web