Article for your reading (and flaming) pleasure:

http://www.turn.co.za/david/gcch.html

Regards
David Turner

"David Turner" <david@firepro.co.za> wrote:
> Article for your reading (and flaming) pleasure:
> http://www.turn.co.za/david/gcch.html

"gcch" hmm? I wonder what the original title of this document was.
(I'll have more comments when others have chipped in.)

Bill, considered harmful.

> "gcch" hmm? I wonder what the original title of this document was.
> (I'll have more comments when others have chipped in.)
>
> Bill, considered harmful.

That was quick, Bill!  Actually the article title is exactly as I first
wrote it, the temptation only arose when it came to saving the file.  But
well spotted, and I hope nobody minds.

Note: Courtesy copy of this followup sent to author via email.

On Thu, 5 Feb 2004 12:21:51 +0200, "David Turner" <david@firepro.co.za>
wrote:

>Article for your reading (and flaming) pleasure:
>
>http://www.turn.co.za/david/gcch.html
>
>Regards
>David Turner

Whenever I hear the term "Garbage Collection", it takes me back over 20
years to the early days of DOS and Micro$oft's Basic interpreter.  To
clean up its string storage space, it had a garbage collection routine
that would be triggered at the most inconvenient times.  The more
strings you had, the longer the routine took.  During garbage
collection, the computer was frozen and gave no indication of life.  You
could not even control-break out of the program!

Anyway, back to the present day...

The idea of having an object clean itself up when it goes out of scope,
as in your C++ example is VERY powerful and I use that philosophy
whenever possible.  Still, there are numerous ways to create memory
leaks in ANY language.

In addition, Windows also allows you to create resource leaks; such as
when you create a handle to a system object and then fail to close the
handle when you are done with it.

No matter WHAT programming language you use, you need to use a
disciplined approach to preventing leaks.  No programming language is
going to do your work for you!

Good debugging tools are a MUST!  "Bounds Checker" (and other products)
are excellent tools.  Unfortunately, they have limited usefulness in my
type of programming.  I work on a mammoth program with critical real
time performance requirements.  I can not afford the slowdown caused by
running the program under Bounds Checker.

Gary

-- 
Gary Edstrom <gedstrom@pacbell.net>
Visit my Midway Island home page at http://gbe.dynip.com/Midway
I couldn't repair your brakes, so I made your horn louder.
The above tagline is number 215 in a series of 547.  Collect them all!

Hi

> The idea of having an object clean itself up when it goes out of scope,
> as in your C++ example is VERY powerful and I use that philosophy
> whenever possible.  Still, there are numerous ways to create memory
> leaks in ANY language.

The language doesn't create the leaks; the underlying API does.  A good
language allows you to wrap the API in such a way as to minimize the
possibility of resource leaks.


> In addition, Windows also allows you to create resource leaks; such as
> when you create a handle to a system object and then fail to close the
> handle when you are done with it.

That's precisely the kind of thing I'm pointing out.  However, there is no
reason why one cannot arrange a framework in which it is (nearly) impossible
to leak resources.

This type of thing requires the cooperation of multiple language features,
however at a very minimum one needs scope destructors.  Templates are also
helpful, as is the const modifier.


> No matter WHAT programming language you use, you need to use a
> disciplined approach to preventing leaks.  No programming language is
> going to do your work for you!

Surprisingly enough, Visual Basic is a pretty good language when it comes to
managing resources.

Just to reiterate my main point: the framework should be such that the path
of least resistance is the correct one.  In other words, the solution that
uses the minimum amount of code should work properly in the context of the
framework.  The language itself doesn't provide the framework; this is what
library designers do.  The language merely facilitates.

Regards
David Turner

David Turner wrote:

> Article for your reading (and flaming) pleasure:
> 
> http://www.turn.co.za/david/gcch.html
> 
> Regards
> David Turner
> 
> 

One of the basic premises of the web page appears to be that this code...

static void Main(string[] args)
         {
   		//...
             OleDbDataReader rdr = cmd.ExecuteReader();
		// ...
         }

Leaks rdr.

Seems bizarre that rdr being a locally scoped object wouldnt have its 
destructor called as soon it goes out of scope rather than at some 
random point when the GC kicks in. Is that really the case?

I didnt look into it too far but it seems other garbage collected 
languages like Lisp work normally.

In article <1075977989.319807@tanzanite.firepro.co.za>,
David Turner <david@firepro.co.za> wrote:
>Article for your reading (and flaming) pleasure:
>
>http://www.turn.co.za/david/gcch.html

It took me a few minutes to think how I wanted to respond to your 
article:

I'm going to use the term "dispose" to indicate the act of freeing an 
object's resources. In C++, this is done in the destructor, in C#, this is 
done in the IDispose interface.


If you're arguing that C# and Java should have had better support for
enforded RAII, then that's something I can agree with. If you're arguing
against garbage collection, then I strenuously disagree: It's too useful
to throw away.

To me, the fundamental difference between C# and C++ (wrt RAII) is that
C++ supports RAII by default: automatic variables, the easiest kind to
create, are always disposed of at the end of a scope.  C#, in contrast,
will only automatically dispose of objects in the event that the
library's client uses "using(...) ...".

That said, the only reason this is related to garbage collection is that
C++ happens to dispose of objects as they are deallocated. The fact that
garbage collected languages decouple deallocation and disposal shouldn't
indict garbage collection itself. All it means is that garbage collected
languages need to provide ways to enforce object disposal at the end of a 
scope, and that _this should be as automatic as possible for the client 
programmer_.

Languages like Lisp do this with macros and unwind-protect. unwind-protect 
is a mechanism for ensuring that code is executed as the stack is unwound, 
even though the stack might be unwound as a result of an exception. Macros 
can be used to safely wrap up these guts into something easy for the 
client programmer to use. That is, the client programmer would have to go 
out of her way to defeat this protection mechanism. 

Here's a small example.

   (defmacro (with-window-draw-surface w s . forms)
      `(let ((,s (get-window-draw-surface ,w)))
          (unwind-protect
             (lambda ()  
                (draw-surface-open! ,s)
                ,@forms)
             (lambda ()
                (draw-surface-close! ,s)))))

Basically, what this does is ensure that a drawing surface that is opened 
is closed, even in the event of an exception. It's used like this:

  (with-window-draw-surface *window* surf
     (draw-rectangle surf 0 0 100 100)
     (draw-rectangle surf 100 100 200 200))

Even if draw-rectangle fails, draw-surface-close! will be called. The 
client programmer can be blissfully unware that the surface has to be 
gotten, opened, and closed at all. (Of course, if you do need more control 
over the object's life cycle, then the functions can be called explicitly, 
but that's a PITA, as it should be.)

Keep in mind that this is in a garbage collected language...

-Mike
-- 
http://www.mschaef.com

In article <TZqUb.9492$%i5.7762@news-binary.blueyonder.co.uk>,
xbunny  <xbunny@eidosnet.co.uk> wrote:
   ...
>One of the basic premises of the web page appears to be that this code...
>
>static void Main(string[] args)
>         {
>   		//...
>             OleDbDataReader rdr = cmd.ExecuteReader();
>		// ...
>         }
>
>Leaks rdr.
>
>Seems bizarre that rdr being a locally scoped object wouldnt have its 
>destructor called as soon it goes out of scope rather than at some 
>random point when the GC kicks in. Is that really the case?

rdr is not the object, it's a reference to the object. The reference goes 
out of scope, and assuming it's the last reference to the object, leaves 
it unreachable. The next time the GC runs, it notices this and deletes it.

The only way I can think of easily adding "enforced" automatic disposal to
C# is a class attribute that would cause the compiler to throw an error if
an object reference variable was created outside of a using(...). With
that, you'd also have to have a way of "blessing" modules that can't abide
by this restriction for whatever reason. I think it'd be quite convoluted 
in the end...

-Mike

-- 
http://www.mschaef.com

MSCHAEF.COM wrote:
> In article <TZqUb.9492$%i5.7762@news-binary.blueyonder.co.uk>,
> xbunny  <xbunny@eidosnet.co.uk> wrote:
>    ...
> 
>>One of the basic premises of the web page appears to be that this code...
>>
>>static void Main(string[] args)
>>        {
>>  		//...
>>            OleDbDataReader rdr = cmd.ExecuteReader();
>>		// ...
>>        }
>>
>>Leaks rdr.
>>
>>Seems bizarre that rdr being a locally scoped object wouldnt have its 
>>destructor called as soon it goes out of scope rather than at some 
>>random point when the GC kicks in. Is that really the case?
> 
> 
> rdr is not the object, it's a reference to the object. The reference goes 
> out of scope, and assuming it's the last reference to the object, leaves 
> it unreachable. The next time the GC runs, it notices this and deletes it.

So your saying the language framework doesnt notice that rdr has the 
last reference which gets lost when it goes out of scope and then it 
doesnt realize that the object is garbage there and then? Seems to me 
that that would be easier to put in the language than having the garbage 
collector hunt out unreachable objects all the time.
I say this cos I wrote a garbage collected language which did just that, 
noone ever had a problem with it. I think thats how programmers expect 
scope to work...
Or perhaps that breaks something else in garbage collection in general?

Interesting

Bunny

(of course my garbage collector should have collected itself really lol 
- you gotta feel sorry for language writers its such a minefield)

Hi

> That said, the only reason this is related to garbage collection is that
> C++ happens to dispose of objects as they are deallocated. The fact that
> garbage collected languages decouple deallocation and disposal shouldn't
> indict garbage collection itself. All it means is that garbage collected
> languages need to provide ways to enforce object disposal at the end of a
> scope, and that _this should be as automatic as possible for the client
> programmer_.

If an object is to be disposed of, then we must be sure that there are no
references to it.  That is the fundamental dangling reference problem.  The
only way to do this effectively in a gc language is to check if there are
any outstanding references when the object goes out of scope.  Since we are
performing that check anyway, we may as well just free the memory at that
point.

In this case, the only advantage garbage collection has over smart pointers
is that it can understand cyclical references.  I have no objection to
building that sort of support into a language.


> Languages like Lisp do this with macros and unwind-protect. unwind-protect
[snip]
> Basically, what this does is ensure that a drawing surface that is opened
> is closed, even in the event of an exception. It's used like this:
>
>   (with-window-draw-surface *window* surf
>      (draw-rectangle surf 0 0 100 100)
>      (draw-rectangle surf 100 100 200 200))
>

Heh.  Reminds me of 'The rise of "worse is better"' ;-).  At any rate, this
is the other side of the story: adding sentry objects to an otherwise gc
language.  I have no objection to that, either, but I don't see an obvious
way to incorporate it into Java or C#.  Not safely, anyway.

What is required is a way of enforcing pre- and post-conditions without
making the client programmer write more code.  More on this later.

Regards
David Turner

>>>static void Main(string[] args)
>>>        {
>>>  		//...
>>>            OleDbDataReader rdr = cmd.ExecuteReader();
>>>		// ...
>>>        }


In article <DvtUb.10404$%i5.8176@news-binary.blueyonder.co.uk>,
xbunny  <xbunny@eidosnet.co.uk> wrote:
>So your saying the language framework doesnt notice that rdr has the 
>last reference which gets lost when it goes out of scope and then it 
>doesnt realize that the object is garbage there and then? 

Nope... after all, we don't know that cmd.ExecuteReader hasn't created
other references to OleDbDataReader that are still extant after rdr goes
out of scope. You could count the references, which is a common strategy,
but that has some problems too:

- It doesn't handle circular references (A->B->back to A)
- You spend a lot of time incrementing and decrementing reference counts
- reference counts take space, per object. 
- reference counts need to be explicitly managed somehow

>Seems to me 
>that that would be easier to put in the language than having the garbage 
>collector hunt out unreachable objects all the time.

Well, not all the time. There are some optimizations you can do. The GC
routine can wait until the system is relatively free before running. It
can also use object lifetime properties to avoid collecting the entire
heap every time. Since the longer an object exists, the less likely it is
to need to be garbage collected, you can traverse longer-lived objects
less frequently. GC also can arrange objects to maximize locality of
reference, which can have performance benefits on modern
VM/cache-intensive hardware. (Of course, if your garbage collector touches 
every page, you can create awful problems too...)

-Mike
-- 
http://www.mschaef.com

In article <1075997309.844132@tanzanite.firepro.co.za>,
David Turner <david@firepro.co.za> wrote:
   ...
>If an object is to be disposed of, then we must be sure that there are no
>references to it.

I think this breaks down in the case of something like a semaphore.  You
obviously need to retain references to the semaphore, despite the fact
that you want to enforce the release of the semaphore at the end of a
"scope" in which it was acquired. (I guess in RAII you end up creating an
object that models an acquisition of a semaphore.)

This goes straight to your comment about the need for a way to enforce 
post-conditions. "Worse is better" aside, I think that unwind-protect and 
Lisp-style macros do an excellent job of providing a way to create useful 
abstractions that do this. I'd be interested in hearing of ways to do this 
in other languages too.

-Mike
-- 
http://www.mschaef.com

"MSCHAEF.COM" wrote:

> If you're arguing that C# and Java should have had better support
> for enforded RAII, then that's something I can agree with. If you're
> arguing against garbage collection, then I strenuously disagree:
> It's too useful to throw away.

I second everything you wrote!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"David Turner" <david@firepro.co.za> wrote in message <news:1075984939.369650@tanzanite.firepro.co.za>...

> > No matter WHAT programming language you use, you need to use a
> > disciplined approach to preventing leaks.  No programming language is
> > going to do your work for you!
>
> Surprisingly enough, Visual Basic is a pretty good language when it comes to
> managing resources.

Not anymore, it isn't.  The macro preprocessor for C# that Micro$haft
speciously calls "Visual Basic 7.0" and up is even worse than C# when
it comes to resource management.  Of course, it's still better than
Java, which no longer even calls finalizers upon normal program exit!

--
Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

On Thu, 5 Feb 2004 12:21:51 +0200, "David Turner" <david@firepro.co.za> wrote:

>Article for your reading (and flaming) pleasure:
>
>http://www.turn.co.za/david/gcch.html

To be fair your C# examples should be using 'using'.

And to sum up, to possibly avoid knee-jerk reactions here, the
main problem with your article is that it assumes that C#/Java
(garbage collection) is in direct competition with e.g. C++ (RAII),
which as far as I know, after decades of programming, is not true.

But I agree that garbage collection in Java and C# is a problem:

  1) Garbage collection is inefficient in actual systems.
     It can be _very efficient_ in isolation, but in practice it
     soaks up virtual memory from a very willing provider, namely
     the operating system.  And as is the case when one mindlessly
     accepts freebies from very willing providers, without proper
     protection, the cost may be a sickness.  May God destroy all
     Java Swing-based applications.

  2) Garbage collection gives a false sense of security.
     Again, the Java Swing library is an example.  The garbage
     collector cannot collect objects that still have references
     to them, although these references are long forgotten by the
     program.  Probably installed in call-back 'manager' objects.

  3) Garbage collection requires meta invariants for classes.
     Meta-invariants are precisely what constructors are meant to
     get rid of: once you have successfully constructed an object,
     you have a working object that fulfills the direct invariant
     of its class.  But to ensure that as the object is used, its
     logical destruction must be coupled to its deallocation.  In
     C++, for example, that is the case; with GC as in Java and C#
     it is not the case, so you can easily encounter objects that
     have been cleaned up, logically destroyed, but still exist.

Having said that, though, these problems seem to a large extent to
be _acceptable_ given the simplification GC brings to the language
that is designed with GC in mind.  And regarding point (1) it is
simply a Quality Of Implementation problem.  The fact that it still
is a problem may indicate that it's simply not problematic enough...

For example, C++, which I love and hate, is not a language well
suited for the less experienced programmers who constitute the main
work force on almost any real-world project, and much of the reason
for that complexity is that C++ is not designed with GC in mind.

On the other hand, C++ and similar languages are needed for the things
that can only reasonably be implemented using such languages, so it's
not "use C#/Java always or else C++ always", it's "use C#/Java for
whatever these languages are well-suited for, use C++ for whatever C++
is well-suited for, and if more than one language can cut it, then
use other factors to decide, on a case-by-case basis".

"Alf P. Steinbach" <alfps@start.no> wrote in message <news:4022f5a6.70082093@News.CIS.DFN.DE>...

> On Thu, 5 Feb 2004 12:21:51 +0200, "David Turner" <david@firepro.co.za> wrote:
>
> >Article for your reading (and flaming) pleasure:
> >
> >http://www.turn.co.za/david/gcch.html
>
> To be fair your C# examples should be using 'using'.
>
> And to sum up, to possibly avoid knee-jerk reactions here, the
> main problem with your article is that it assumes that C#/Java
> (garbage collection) is in direct competition with e.g. C++ (RAII),
> which as far as I know, after decades of programming, is not true.
>
> But I agree that garbage collection in Java and C# is a problem:
>
>   1) Garbage collection is inefficient in actual systems.
>      It can be _very efficient_ in isolation, but in practice it
>      soaks up virtual memory from a very willing provider, namely
>      the operating system.  And as is the case when one mindlessly
>      accepts freebies from very willing providers, without proper
>      protection, the cost may be a sickness.  May God destroy all
>      Java Swing-based applications.

C++ seems to be one of the few languages that allow first-class objects
to live on the stack, facilitating RAII.  Perhaps a simpler yet almost
as powerful language could use RAII for stack-based objects and garbage
collection for heap-based objects.  Don't ask me how to accomplish this
transparently, though!  =)

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Gary Edstrom <gedstrom@pacbell.net> writes:

> Whenever I hear the term "Garbage Collection", it takes me back over 20
> years to the early days of DOS and Micro$oft's Basic interpreter.  To
> clean up its string storage space, it had a garbage collection routine
> that would be triggered at the most inconvenient times.  The more
> strings you had, the longer the routine took.  During garbage
> collection, the computer was frozen and gave no indication of life.  You
> could not even control-break out of the program!

Luckily, we have made a lot of progress the last 20 years.  We now
have real-time garbage collectors that are as efficient as malloc/free
and equivalent.  Some of them are faster because they are able to
compact memory and improve locality.  

> Anyway, back to the present day...
> 
> The idea of having an object clean itself up when it goes out of scope,
> as in your C++ example is VERY powerful and I use that philosophy
> whenever possible.  

The problem is that it is usually very hard to know when an object
goes out of scope, especially if there are several references to it in
different data structures of the program.

What usually happens is that in order to know exactly when an object
goes out of scope, programmers either create copies, which slows down
the code (and which have dubious semantics), or resort to things like
reference counters (which are again slow because a simple assignment
needs to invoke a function, and which cannot handle cycles), or smart
pointers (which are again much slower than the assignment of a
reference). 

> No matter WHAT programming language you use, you need to use a
> disciplined approach to preventing leaks.  No programming language is
> going to do your work for you!

But the task is somewhat easier in languages with automatic memory
management.  These languages remove the need for the programmer to
know when the last reference to an object was lost (a global, non
modular property), and he can concentrate on avoiding leaks by not
hanging on to references that are no longer needed (a local, modular
property). 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

"David Turner" <david@firepro.co.za> writes:

> If an object is to be disposed of, then we must be sure that there are no
> references to it.  That is the fundamental dangling reference problem.  The
> only way to do this effectively in a gc language is to check if there are
> any outstanding references when the object goes out of scope.  Since we are
> performing that check anyway, we may as well just free the memory at that
> point.
> 
> In this case, the only advantage garbage collection has over smart pointers
> is that it can understand cyclical references.

Actually, that is not true in general.  Freeing memory can be costly.
You must check whether the block can be fused with other blocks
already freed.  Some garbage collectors do not even touch unreferenced
memory.  They can therefore be faster than manual approaches. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Hi

> The problem is that it is usually very hard to know when an object
> goes out of scope, especially if there are several references to it in
> different data structures of the program.

I think you may be a little confused about the meaning of scope?  Tracking
the scope of an identifier is usually very easy.  True, some languages allow
you to have more than one identifier bound to a variable, so it can be hard
to tell when a variable becomes unreferenced.  However, is the sort of thing
that framework writers should deal with.  A one-size-fits-all garbage
collection approach is too inflexible.  C++ scoping rules are fairly
intuitive.


> What usually happens is that in order to know exactly when an object
> goes out of scope, programmers either create copies, which slows down
> the code (and which have dubious semantics), or resort to things like
> reference counters (which are again slow because a simple assignment
> needs to invoke a function, and which cannot handle cycles), or smart
> pointers (which are again much slower than the assignment of a
> reference).

I don't think one can argue that reference counted code is slower than
garbage collected code ;-).  Remember that the garbage collector also has to
keep track of references.  And to say that smart pointers are "slow" is
ludicrous.  Any compiler worth its salt will reduce the overhead of accesses
through a smart pointer to zero.  Smart pointers have disadvantages, but
speed is not one of them.


> But the task is somewhat easier in languages with automatic memory
> management.  These languages remove the need for the programmer to
> know when the last reference to an object was lost (a global, non
> modular property), and he can concentrate on avoiding leaks by not
> hanging on to references that are no longer needed (a local, modular
> property).

That's a false argument.  And anyway, it doesn't address the actual problem.
Did you read the OP article?

Regards
David Turner

> >
> > In this case, the only advantage garbage collection has over smart
pointers
> > is that it can understand cyclical references.
>
> Actually, that is not true in general.  Freeing memory can be costly.
> You must check whether the block can be fused with other blocks
> already freed.  Some garbage collectors do not even touch unreferenced
> memory.  They can therefore be faster than manual approaches.
>

That's not really relevant.  How the heap is managed is secondary to the
main thesis of this discussion.  I'm not particularly concerned about when
the actual memory is freed, but rather when the destructor (or finalizer)
for an object is called.

Regards
David Turner

"Alf P. Steinbach" <alfps@start.no> wrote in message
news:4022f5a6.70082093@News.CIS.DFN.DE...
> On Thu, 5 Feb 2004 12:21:51 +0200, "David Turner" <david@firepro.co.za>
wrote:
>
> >Article for your reading (and flaming) pleasure:
> >
> >http://www.turn.co.za/david/gcch.html
>
> To be fair your C# examples should be using 'using'.

I did mention that towards the end of the article, although I still consider
it to be a dangerous construct.  At the very least the compiler should warn
you when you don't apply a using() block to an IDispose'able object.  Of
course, the compiler has no way of knowing which block of code "owns" the
object in the case of multiple references, so that approach could result in
a lot of unavoidable warnings :-).  Draw your own conclusions...


> And to sum up, to possibly avoid knee-jerk reactions here, the
> main problem with your article is that it assumes that C#/Java
> (garbage collection) is in direct competition with e.g. C++ (RAII),
> which as far as I know, after decades of programming, is not true.

I agree that C# and Java have their place, and that they are not actually in
direct competition with C++.  I'm merely pointing out that the current
fixation on garbage collection (as a silver bullet) might be setting a
dangerous precedent.  In 1980, Lisp had it right, but it was beaten by C.
Do we want *another* 20 years of struggling to figure out why our code is
buggy?


>   1) Garbage collection is inefficient in actual systems.

Efficiency doesn't really concern me, and I don't see why any programmer
should be overly concerned with it, provided the asymptotic behaviour is
right.


>   2) Garbage collection gives a false sense of security.

That's the core of the issue.  Because of the PR campaigns conducted by Sun
and Microsoft, evangelizing their garbage-collected platforms, there is an
attitude out there that "because it's gc, I don't need to manage my
resources".  This is false, and the situation is made worse by the fact that
Java and C# actually provide poor tools for resource management.


>      of its class.  But to ensure that as the object is used, its
>      logical destruction must be coupled to its deallocation.  In
>      C++, for example, that is the case; with GC as in Java and C#
>      it is not the case, so you can easily encounter objects that
>      have been cleaned up, logically destroyed, but still exist.

This is a hard problem, and C++ isn't immune to it.  A question for another
day :-).


> For example, C++, which I love and hate, is not a language well
> suited for the less experienced programmers who constitute the main
> work force on almost any real-world project, and much of the reason
> for that complexity is that C++ is not designed with GC in mind.

Actually, I would argue that C++ is an excellent language for those
programmers... provided that they are working within a framework constructed
by more experienced programmers!  What I mean is that it's possible in C++
to construct your framework in such a way as to make it very difficult to
misuse the underlying API.

Grunt programmers don't have to understand how this works, they just have to
recite the Holy Incantations.

As I said, Java and C# don't provide nearly as many or as good tools to
achieve this end.


Regards
David Turner

> >If an object is to be disposed of, then we must be sure that there are no
> >references to it.
>
> I think this breaks down in the case of something like a semaphore.  You
> obviously need to retain references to the semaphore, despite the fact
> that you want to enforce the release of the semaphore at the end of a
> "scope" in which it was acquired. (I guess in RAII you end up creating an
> object that models an acquisition of a semaphore.)

Precisely so.  Here's an example of something similar from the C++ boost
library:

void addUser(const char* name)
{
    boost::mutex::scoped_lock lock(user_list_mutex);
    user_list.insert(name);
}

Of course, I would rarely provide direct access to the user_list object like
that.  Instead, I would guarantee safety by ensuring that the mutex is
acquired before the user_list can be accessed:

void addUser(const char* name)
{
    user_list::write_access writer(user_list);
    writer->insert(name);
}

Perhaps that makes my assertions about C++ allowing you to construct an
"idiot-proof" framework a little clearer :-).


> This goes straight to your comment about the need for a way to enforce
> post-conditions. "Worse is better" aside, I think that unwind-protect and
> Lisp-style macros do an excellent job of providing a way to create useful
> abstractions that do this. I'd be interested in hearing of ways to do this
> in other languages too.

I spent last night thinking of a way to add sentry objects to Java.  The
problem is ultimately that you would have to add too much language support.
As I see it, the following features are necessary:

 * a new keyword to introduce a sentry (non-gc) object;
 * (constructor and) destructor syntax for the sentry type;
 * the ability to overload operator ".".

Here's an example of what I had in mind:

class JavaProgram
{
    sentry DBConnection
    {
        IDatabaseConnection db;
        precondition(string connectionStr)
        {
            db = new DatabaseConnection(connectionStr);
        }

        postcondition
        {
            db.close();
        }

        accessor(IDatabaseConnection)
        {
            return db;
        }
    }

    static void Main(string[] args)
    {
        DBConnection db("database=test;user=admin;pwd=password");
        db.query("select * from users;");
        // etc...
    }
}

This might even be possible without changing the bytecode.

Regards
David Turner

On Fri, 6 Feb 2004 08:49:44 +0200, "David Turner" <david@firepro.co.za> wrote:
>"Alf P. Steinbach" <alfps@start.no> wrote in message
>news:4022f5a6.70082093@News.CIS.DFN.DE...
>> On Thu, 5 Feb 2004 12:21:51 +0200, "David Turner" <david@firepro.co.za>
>wrote:
>>
>> >Article for your reading (and flaming) pleasure:

I now think you're simply trolling.


>> >http://www.turn.co.za/david/gcch.html
>>
>> To be fair your C# examples should be using 'using'.
>
>I did mention that towards the end of the article, although I still consider
>it to be a dangerous construct.  At the very least the compiler should warn
>you when you don't apply a using() block to an IDispose'able object.  Of
>course, the compiler has no way of knowing which block of code "owns" the
>object in the case of multiple references, so that approach could result in
>a lot of unavoidable warnings :-).  Draw your own conclusions...

The main observation is simply that you gave two different examples and
claimed they were the same example expressed in different languages.

And the conclusion from that?

Well, draw it yourself...



>> And to sum up, to possibly avoid knee-jerk reactions here, the
>> main problem with your article is that it assumes that C#/Java
>> (garbage collection) is in direct competition with e.g. C++ (RAII),
>> which as far as I know, after decades of programming, is not true.
>
>I agree that C# and Java have their place, and that they are not actually in
>direct competition with C++.  I'm merely pointing out that the current
>fixation on garbage collection (as a silver bullet) might be setting a
>dangerous precedent.

Do you have any references to the claim that there is a fixation
on garbage collection?



>In 1980, Lisp had it right,

Do you have any references or arguments in support of that?


> but it was beaten by C.

Screwdrivers were beaten by oscilloscopes, yes.  Are you sure?  And
for that matter, from where does the year 1980 enter the picture?



>Do we want *another* 20 years of struggling to figure out why our code is
>buggy?

?

Do you mean that Lisp has made your code buggy for 20 years?

Do you mean that C has made your code buggy for 20 years?



>>   1) Garbage collection is inefficient in actual systems.
>
>Efficiency doesn't really concern me, and I don't see why any programmer
>should be overly concerned with it, provided the asymptotic behaviour is
>right.

Troll #1.



>>   2) Garbage collection gives a false sense of security.
>
>That's the core of the issue.

OK, that's what you want us to discuss.


>Because of the PR campaigns conducted by Sun
>and Microsoft, evangelizing their garbage-collected platforms, there is an
>attitude out there that "because it's gc, I don't need to manage my
>resources".  This is false,

Right, the 'because' is definitely incorrect.  Also, the statement
that there have been "don't need to manage my resources" evangelizing
PR-campaigns by Sun and Microsoft needs some facts to back it up.  Do
you have any references?


> and the situation is made worse by the fact that
>Java and C# actually provide poor tools for resource management.

You would have to provide arguments for that opinion.  Otherwise
it's just an unfounded opinion.




>>      of its class.  But to ensure that as the object is used, its
>>      logical destruction must be coupled to its deallocation.  In
>>      C++, for example, that is the case; with GC as in Java and C#
>>      it is not the case, so you can easily encounter objects that
>>      have been cleaned up, logically destroyed, but still exist.
>
>This is a hard problem, and C++ isn't immune to it.

That's right on both counts, but the implication that it's not a
problem specific to languages like C# and Java is incorrect.  In C# and
Java meta-invariants are forced on the programmer.  Not so in C++.  As
mentioned earlier that doesn't make any of the languages better in any
general sense.  What it does mean is that this is a problem with GC.



[About non-experienced programmers.]
>Actually, I would argue that C++ is an excellent language for those
>programmers...

Feel free to do so.


>provided that they are working within a framework constructed
>by more experienced programmers!  What I mean is that it's possible in C++
>to construct your framework in such a way as to make it very difficult to
>misuse the underlying API.

If it's possible, please present such a framework.


>Grunt programmers don't have to understand how this works, they just have to
>recite the Holy Incantations.

Troll #2.



>As I said, Java and C# don't provide nearly as many or as good tools to
>achieve this end.

Troll #3.

> >I did mention that towards the end of the article, although I still
consider
> >it to be a dangerous construct.  At the very least the compiler should
warn
> >you when you don't apply a using() block to an IDispose'able object.  Of
> >course, the compiler has no way of knowing which block of code "owns" the
> >object in the case of multiple references, so that approach could result
in
> >a lot of unavoidable warnings :-).  Draw your own conclusions...
>
> The main observation is simply that you gave two different examples and
> claimed they were the same example expressed in different languages.
>
> And the conclusion from that?
>
> Well, draw it yourself...

I think you've missed the boat...


> Do you have any references to the claim that there is a fixation
> on garbage collection?

Yes.
http://www.google.com/search?sourceid=mozclient&ie=utf-8&oe=utf-8&q=C%23+Java+programming+jobs.


> >provided that they are working within a framework constructed
> >by more experienced programmers!  What I mean is that it's possible in
C++
> >to construct your framework in such a way as to make it very difficult to
> >misuse the underlying API.
>
> If it's possible, please present such a framework.

Try http://www.boost.org/libs/thread/doc/index.html.


I'm trying to create a serious discussion.  You have responded very rudely
and without making much sense.

Regards
David Turner

"David Turner" <david@firepro.co.za> wrote in message news:<1075977989.319807@tanzanite.firepro.co.za>...
> Article for your reading (and flaming) pleasure:
> 
> http://www.turn.co.za/david/gcch.html

I quite agree.  I find the C# Dispose() syntax particularly silly when
compared with the simplicity of a C++ destructor.

The situation is even worse with C# and .NET, because in some cases
the .NET runtime library disposes objects with live references,
leaving dangling references, and in other cases the .NET runtime
library holds internal references to objects that are inaccessible to
the application, leading to memory leaks.

On Thu, 5 Feb 2004 20:05:03 -0800, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:

>"Alf P. Steinbach" <alfps@start.no> wrote in message <news:4022f5a6.70082093@News.CIS.DFN.DE>...
>
>> On Thu, 5 Feb 2004 12:21:51 +0200, "David Turner" <david@firepro.co.za> wrote:
>>
>> >Article for your reading (and flaming) pleasure:
>> >
>> >http://www.turn.co.za/david/gcch.html
>>
>> To be fair your C# examples should be using 'using'.
>>
>> And to sum up, to possibly avoid knee-jerk reactions here, the
>> main problem with your article is that it assumes that C#/Java
>> (garbage collection) is in direct competition with e.g. C++ (RAII),
>> which as far as I know, after decades of programming, is not true.
>>
>> But I agree that garbage collection in Java and C# is a problem:
>>
>>   1) Garbage collection is inefficient in actual systems.
>>      It can be _very efficient_ in isolation, but in practice it
>>      soaks up virtual memory from a very willing provider, namely
>>      the operating system.  And as is the case when one mindlessly
>>      accepts freebies from very willing providers, without proper
>>      protection, the cost may be a sickness.  May God destroy all
>>      Java Swing-based applications.
>
>C++ seems to be one of the few languages that allow first-class objects
>to live on the stack, facilitating RAII.  Perhaps a simpler yet almost
>as powerful language could use RAII for stack-based objects and garbage
>collection for heap-based objects.  Don't ask me how to accomplish this
>transparently, though!  =)

One possibility could be a language that like Eiffel distinguishes between
expanded and non-expanded (reference) instances.  A stack based local
variable is the primary example of an expanded instance.  You can not
obtain a copyable reference to an expanded instance.

With that as basis add reference counting to normal garbage collection, and
specify that a destructor call will occur immediately for any expanded object
when it goes out of scope or its container object is destroyed, and for
reference objects,


  * when the ref-object's ref-count goes to zero, or

  * when the ref-object is garbage collected,


whichever happens first.  An object with non-zero ref-count can be garbage
collected if (and I think only if) it is part of a circular data structure.

Add a rule that any exception that propagates out of a destructor causes
immediate program termination with some specific exit status.

Hm, I wonder whether this is in any way similar to D?

Too lazy to check...

"David Turner" <david@firepro.co.za> wrote in message
news:1075977989.319807@tanzanite.firepro.co.za...
> Article for your reading (and flaming) pleasure:
>
> http://www.turn.co.za/david/gcch.html

The D Programming Language also uses garbage collection as its primary
memory management technique. However, it also supports RAII programming
idioms for managing non-memory resources. www.digitalmars.com/d/memory.html


-Walter
www.digitalmars.com/d/ The D Programming Language

David Turner wrote:
> If an object is to be disposed of, then we must be sure that there are
> no references to it.  That is the fundamental dangling reference
> problem.

In C++ you can dispose an object which is still referenced. Even if you
use some smart technique like the one you presented, you can still leave
a reference to the proxy object living on the stack.

> The only way to do this effectively in a gc language is to check if
> there are any outstanding references when the object goes out of
> scope. Since we are performing that check anyway, we may as well just
> free the memory at that point.

Be careful, there are GC languages other than Java. Some of them can
even perform this kind of checking at compile time.

> In this case, the only advantage garbage collection has over smart pointers
> is that it can understand cyclical references.  I have no objection to
> building that sort of support into a language.

Perhaps GC doesn't give such a big advantage in Java and C#, but have
you used any language which conveniently supports higher order functions
and closures?

>> Languages like Lisp do this with macros and unwind-protect. unwind-protect
> [snip]
>> Basically, what this does is ensure that a drawing surface that is opened
>> is closed, even in the event of an exception. It's used like this:
>>
>>   (with-window-draw-surface *window* surf
>>      (draw-rectangle surf 0 0 100 100)
>>      (draw-rectangle surf 100 100 200 200))
>>
> 
> Heh.  Reminds me of 'The rise of "worse is better"' ;-).  At any rate, this
> is the other side of the story: adding sentry objects to an otherwise gc
> language.  I have no objection to that, either, but I don't see an obvious
> way to incorporate it into Java or C#.  Not safely, anyway.

I agree that Java and C# got many things wrong. But please, don't try to
extend your bad experience with them to all GCed language
implementations.

> Regards
> David Turner

Best regards,
Tomasz

-- 
..signature: Too many levels of symbolic links

MSCHAEF.COM wrote:
> This goes straight to your comment about the need for a way to enforce 
> post-conditions. "Worse is better" aside, I think that unwind-protect and 
> Lisp-style macros do an excellent job of providing a way to create useful 
> abstractions that do this. I'd be interested in hearing of ways to do this 
> in other languages too.

In Haskell you could use a higher-order function to do this. For
example, there is a function 'bracket' (or rather a parametrized IO
action 'bracket'):

    http://tinyurl.com/2rfcs
    http://www.zvon.org/other/haskell/Outputio/bracket_f.html

One can argue that this still has the 'dangling references' problem,
because you can return the resource from the function, store it in some
data structure or send it to other thread.

There are techniques to statically catch some of these errors, but I
haven't yet figured how to completely eliminate errors without
significantly impairing usability.

For example, I could use 'rank-2 explicit universal quantification' and
come up with such module:

  module U
      ( ScopedFile
      , sfGetChar
      , withScopedFile
      ) where

  import IO

  newtype ScopedFile s = ScopedFile Handle

  sfGetChar :: ScopedFile s -> IO Char
  sfGetChar (ScopedFile h) = hGetChar h

  withScopedFile :: FilePath -> (forall s. ScopedFile s -> IO a) -> IO a
  withScopedFile path action = do
      h <- openFile path ReadMode
      x <- action (ScopedFile h)
      hPutStrLn stderr ("closing file " ++ path)
      hClose h
      return x

I defined an abstract data type ScopedFile which is parametrized by type
variable 's'.

The second argument of withScopedFile is a function that takes a
'ScopedFile s' argument and returns an IO action. The type of this
function parameter contains explicit universal quantification on 's', so
the function has to be polymorphic on 's'.

This means that 's' type variable from type 'ScopedFile s' can't be
constrained in any way, for example by (indirect) unification with type
variable 'a', which would be the case if I tried to return the
ScopedFile from an IO action. It also prevents storing ScopedFile in a
mutable reference of type IORef (ScopedFile s), or sending it to another
thread through an MVar (ScopedFile s) or Chan (ScopedFile s).

Using this module I can do:

  foo = do
      withScopedFile "/etc/passwd" (\sf1 -> do
      withScopedFile "/etc/termcap" (\sf2 -> do
      c1 <- sfGetChar sf1
      c2 <- sfGetChar sf2
      return (c1, c2)))

but the following code would be rejected:

      ...
      return (c1, c2, sf1))) -- can't return sf1 from here

and so would this:

  foo = do
      ref <- newIORef undefined

      withScopedFile "/etc/passwd" (\sf1 -> do
      withScopedFile "/etc/termcap" (\sf2 -> do
      c1 <- sfGetChar sf1
      c2 <- sfGetChar sf2
      writeIORef ref sf1 -- can't store sf1 in an external 
			 -- mutable reference
      return (c1, c2)))

Unfortunately, I can still partially apply sfGetChar to sf1 and return
it from the function like this:

      ...
      return (sfGetChar sf1)))

So this doesn't guard against all errors, but neither does the presented
C++ solution.


The Concurrent Clean (GCed) language can guarantee that certain objects
have only one reference to them with help of Uniqueness Typing. UT is a
very interesting idea, for example it allows to perform compile time
garbage collection of unique nodes. It's major role in Clean is to
introduce imperative mechanisms like IO or mutable arrays into a purely
functional language. UT can be also use to enforce a simple protocol,
like the one presented by David Turner.

> -Mike

Best regards,
Tom

-- 
..signature: Too many levels of symbolic links

"Walter" <walternospamm@digitalmars.nospaam.com> wrote in message news:<ifbVb.246214$na.408827@attbi_s04>...
> "David Turner" <david@firepro.co.za> wrote in message
> news:1075977989.319807@tanzanite.firepro.co.za...
> > Article for your reading (and flaming) pleasure:
> >
> > http://www.turn.co.za/david/gcch.html
> 
> The D Programming Language also uses garbage collection as its primary
> memory management technique. However, it also supports RAII programming
> idioms for managing non-memory resources. www.digitalmars.com/d/memory.html
> 

As does Lisp.  I like some of the ideas in D (though it's a bit too
"everything and the kitchen sink" for me).

What I *don't* like is the attitude that "our programs will be
safe/secure/crash-proof/supercowpowered because we wrote them on the
Java/.NET/foo platform".

Regards
David Turner

"David Turner" <david@firepro.co.za> wrote in message
news:592f3326.0402080644.590c5b67@posting.google.com...
> "Walter" <walternospamm@digitalmars.nospaam.com> wrote in message
news:<ifbVb.246214$na.408827@attbi_s04>...
> > "David Turner" <david@firepro.co.za> wrote in message
> > news:1075977989.319807@tanzanite.firepro.co.za...
> > > Article for your reading (and flaming) pleasure:
> > >
> > > http://www.turn.co.za/david/gcch.html
> >
> > The D Programming Language also uses garbage collection as its primary
> > memory management technique. However, it also supports RAII programming
> > idioms for managing non-memory resources.
www.digitalmars.com/d/memory.html
> >
>
> As does Lisp.  I like some of the ideas in D (though it's a bit too
> "everything and the kitchen sink" for me).

D appears to have more features than C++ because more can be done with it,
but it actually has far less. This is because it is not loaded with subtle
cases each requiring a special rule.

> What I *don't* like is the attitude that "our programs will be
> safe/secure/crash-proof/supercowpowered because we wrote them on the
> Java/.NET/foo platform".

You're right. There's no getting away from having to use one's brain in
writing code. But it is nice if the language helps you to write good code,
rather than hinders. What bothers me about the VM sandbox approach is this:
modern CPU's have 4 privilege modes implemented in hardware. The lowest
privilege mode is meant to be a sandbox. Why not use that instead?

Hi Tomasz Zielonka

I'm going to quote you in reverse order, because I want to agree with
you before I disagree with you :-).

Tomasz Zielonka <t.zielonka@zodiac.mimuw.edu.pl> wrote in message news:<slrnc2c131.b3a.t.zielonka@zodiac.mimuw.edu.pl>...
> Be careful, there are GC languages other than Java. Some of them can
> even perform this kind of checking at compile time.
[snip]
> Perhaps GC doesn't give such a big advantage in Java and C#, but have
> you used any language which conveniently supports higher order functions
> and closures?
[snip]
> I agree that Java and C# got many things wrong. But please, don't try to
> extend your bad experience with them to all GCed language
> implementations.

You are perfectly correct, and I must apologize: garbage collection is
a Good Thing (applied in moderation), and I didn't intend to set
myself up in a position quite so opposed to it.  Garbage collection is
not what I'm attacking; what I *am* attacking is the distraction from
the real problem that the inclusion of garbage collection in Java has
ultimately caused.

So for all the bad things I said or implied about garbage collection,
I'm sorry.  I have no similar criticisms to apply to Lisp, Haskell,
Scheme, or any number of other gc languages.



> David Turner wrote:
> > If an object is to be disposed of, then we must be sure that there are
> > no references to it.  That is the fundamental dangling reference
> > problem.
> 
> In C++ you can dispose an object which is still referenced. Even if you
> use some smart technique like the one you presented, you can still leave
> a reference to the proxy object living on the stack.

I'm not 100% sure I know what you mean.  Referenced how?  Yes, it's
possible to return a *pointer* to an object in a local scope, and this
causes many people who are new to C++ endless headaches.  Objects
returned by *reference*, however, are required to have their lifetimes
extended.  As to the proxy object technique I described, as far as I'm
concerned it's perfectly safe - provided nobody tries to create a
proxy on the heap.

By the way, I'm not advocating C++ as a language that is somehow
"perfect"; I'm simply using it as an example of how things could be
better in Java and C#.  An excellent example of why C++ is not perfect
has just arisen in the previous paragraph: I would like to be able to
prevent the use of the "new" keyword in certain contexts, and C++
doesn't make this possible.

Regards
David Turner

On Sun, 08 Feb 2004 11:52:35 -0800, David Turner wrote:

> Yes, it's
> possible to return a *pointer* to an object in a local scope, and this
> causes many people who are new to C++ endless headaches.  Objects
> returned by *reference*, however, are required to have their lifetimes
> extended.

I'm afraid not.

  int& dangling_reference() {
    int x;
    return x;
    }

If you try to use the lvalue result of calling dangling_reference(), you
will invoke undefined behavior.

Josh

"Walter" <walternospamm@digitalmars.nospaam.com> wrote in message news:PqwVb.6275$QA2.14439@attbi_s52...
> 
> "David Turner" <david@firepro.co.za> wrote in message
> news:592f3326.0402080644.590c5b67@posting.google.com...
> > "Walter" <walternospamm@digitalmars.nospaam.com> wrote in message
> news:<ifbVb.246214$na.408827@attbi_s04>...
> > > "David Turner" <david@firepro.co.za> wrote in message
> > > news:1075977989.319807@tanzanite.firepro.co.za...
> > > > Article for your reading (and flaming) pleasure:
> > > >
> > > > http://www.turn.co.za/david/gcch.html
> > >
> > > The D Programming Language also uses garbage collection as its primary
> > > memory management technique. However, it also supports RAII programming
> > > idioms for managing non-memory resources.
> www.digitalmars.com/d/memory.html
> > >
> >
> > As does Lisp.  I like some of the ideas in D (though it's a bit too
> > "everything and the kitchen sink" for me).
> 
> D appears to have more features than C++ because more can be done with it,
> but it actually has far less. This is because it is not loaded with subtle
> cases each requiring a special rule.

While I do sincerely sympathise with your, can I say, courageous attempt
to bring your D language under the attention of a wider audience, I must
object against the "more can be done with it" part. But then again,
mathematicians are terrible folks to have an argument with, while having
a drink with them in a pub somewhere ...

kind regards,

Jos

>
> If an object is to be disposed of, then we must be sure that there are no
> references to it.  That is the fundamental dangling reference problem.

No, we must make sure that the object is in an "unreachable" state, not to
be confused with "not having any more references to it."
http://java.sun.com/developer/Books/performance/performance2/appendixa.pdf

> Since we are
> performing that check anyway, we may as well just free the memory at that
> point.

Huh ? Since Java does not provide direct access to objects, how are you
proposing that "we perform some check" on an object about what references
are referring to it ?

-- 
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

"Walter" <walternospamm@digitalmars.nospaam.com> wrote in message <news:PqwVb.6275$QA2.14439@attbi_s52>...

> D appears to have more features than C++ because more can be done with it,
> but it actually has far less. This is because it is not loaded with subtle
> cases each requiring a special rule.

What do you mean by "more can be done with it"?  Can you provide an
example showing how this D can be used to solve the Halting Problem?
Or are you talking about Date and Darwen's Tutorial-D language?  >=)

Anyway, I'm unconvinced that programming with line noise is optimal.
This goes for C, C++, Objective C, Java, Perl, C#, J#, etc., as well.

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Jos A. Horsmeier" <j.a.horsmeier@wanadoo.nl> wrote in message
news:4026a839$0$62673$cd19a363@news.wanadoo.nl...
> "Walter" <walternospamm@digitalmars.nospaam.com> wrote in message
news:PqwVb.6275$QA2.14439@attbi_s52...
> > D appears to have more features than C++ because more can be done with
it,
> > but it actually has far less. This is because it is not loaded with
subtle
> > cases each requiring a special rule.
> While I do sincerely sympathise with your, can I say, courageous attempt
> to bring your D language under the attention of a wider audience, I must
> object against the "more can be done with it" part. But then again,
> mathematicians are terrible folks to have an argument with, while having
> a drink with them in a pub somewhere ...

If you mean that any program can be expressed in any programming language,
you're right. But if you're talking about things like nested functions for
example, D can do them, and C++ cannot.

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:1076288251.854731@news-1.nethere.net...
> "Walter" <walternospamm@digitalmars.nospaam.com> wrote in message
<news:PqwVb.6275$QA2.14439@attbi_s52>...
>
> > D appears to have more features than C++ because more can be done with
it,
> > but it actually has far less. This is because it is not loaded with
subtle
> > cases each requiring a special rule.
>
> What do you mean by "more can be done with it"?

The current (March 2004) issue of DDJ has an article detailing such with
examples. There are also many examples on www.digitalmars.com/d/cpptod.html


-Walter

> > Yes, it's
> > possible to return a *pointer* to an object in a local scope, and this
> > causes many people who are new to C++ endless headaches.  Objects
> > returned by *reference*, however, are required to have their lifetimes
> > extended.
>
> I'm afraid not.
>
>   int& dangling_reference() {
>     int x;
>     return x;
>     }
>
> If you try to use the lvalue result of calling dangling_reference(), you
> will invoke undefined behavior.

You're quite right.  I was thinking of 12.2-5.

Regards
David Turner

Hi

"Tony Morris" <dibblego@optusnet.com.au> wrote in message
news:c06nkn$irk$1@news.btv.ibm.com...
> >
> > If an object is to be disposed of, then we must be sure that there are
no
> > references to it.  That is the fundamental dangling reference problem.
>
> No, we must make sure that the object is in an "unreachable" state, not to
> be confused with "not having any more references to it."
> http://java.sun.com/developer/Books/performance/performance2/appendixa.pdf
>
> > Since we are
> > performing that check anyway, we may as well just free the memory at
that
> > point.
>
> Huh ? Since Java does not provide direct access to objects, how are you
> proposing that "we perform some check" on an object about what references
> are referring to it ?

We as in the language.  Perform a targeted garbage collection sweep at the
end of the object's scope so that it can be effectively finalized.

Regards
David Turner

"Alf P. Steinbach" <alfps@start.no> wrote in message
news:40233c83.88223421@News.CIS.DFN.DE...
> On Fri, 6 Feb 2004 08:49:44 +0200, "David Turner" <david@firepro.co.za>
wrote:
> >"Alf P. Steinbach" <alfps@start.no> wrote in message
> >

> >Efficiency doesn't really concern me, and I don't see why any programmer
> >should be overly concerned with it, provided the asymptotic behaviour is
> >right.
>
> Troll #1.
>

That is most certainly not a troll (as long as constant factors are
relatively small).  As computers get faster, and grid and distributed
computing become more ubiquitous, I think this will become (if it already
hasn't) the mainstream opinion on efficiency.  ie: In most cases,
_including_ most embedded and real-time systems, efficiency will not be all
that high on the list of desired qualities when one chooses an
implementation language.  When cheap off the shelf chips routinely execute
instructions on the order of nanoseconds.... and they're only going to get
faster.



l8r, Mike N. Christoff

"David Turner" <david@firepro.co.za> wrote in message
news:1076313007.89348@tanzanite.firepro.co.za...
> Hi
>
> "Tony Morris" <dibblego@optusnet.com.au> wrote in message
> news:c06nkn$irk$1@news.btv.ibm.com...
> > >
> > > If an object is to be disposed of, then we must be sure that there are
> no
> > > references to it.  That is the fundamental dangling reference problem.
> >
> > No, we must make sure that the object is in an "unreachable" state, not
to
> > be confused with "not having any more references to it."
> >
http://java.sun.com/developer/Books/performance/performance2/appendixa.pdf
> >
> > > Since we are
> > > performing that check anyway, we may as well just free the memory at
> that
> > > point.
> >
> > Huh ? Since Java does not provide direct access to objects, how are you
> > proposing that "we perform some check" on an object about what
references
> > are referring to it ?
>
> We as in the language.  Perform a targeted garbage collection sweep at the
> end of the object's scope so that it can be effectively finalized.
>
> Regards
> David Turner
>
>

That is infeasible.
a) an object doesn't have scope, an object reference does.
b) an object reference going out of scope does not necessarily imply
eligibility for garbage collection of the object that it was referring to.
c) even if the last object reference that was referring to an object goes
out of scope, still doesn't imply eligibility for garbage collection of the
object that it was referring to.

I suggest you read
http://java.sun.com/developer/Books/performance/performance2/appendixa.pdf

-- 
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

On Mon, 9 Feb 2004 15:04:40 -0500, "Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote:

>
>"Alf P. Steinbach" <alfps@start.no> wrote in message
>news:40233c83.88223421@News.CIS.DFN.DE...
>> On Fri, 6 Feb 2004 08:49:44 +0200, "David Turner" <david@firepro.co.za>
>wrote:
>> >"Alf P. Steinbach" <alfps@start.no> wrote in message
>> >
>
>> >Efficiency doesn't really concern me, and I don't see why any programmer
>> >should be overly concerned with it, provided the asymptotic behaviour is
>> >right.
>>
>> Troll #1.
>>
>
>That is most certainly not a troll (as long as constant factors are
>relatively small).  As computers get faster, and grid and distributed
>computing become more ubiquitous, I think this will become (if it already
>hasn't) the mainstream opinion on efficiency.

People have thought that since cirka 1970 when Moore formulated his law
of exponentially doubling capacity.

There should be a name for the law of exponentially doubling size and
inefficiency for software programs (of the same end user utility).

Alf's law?  ;-)

On Mon, 09 Feb 2004 00:58:44 +0000, Walter wrote:

> But if you're talking about things like nested functions for
> example, D can do them, and C++ cannot.

  void foo {
    struct nested {
      static void bar() {
      }
    };
    nested::bar();
  }

Josh

"Michael N. Christoff" wrote:
> 
.... snip ...
> 
> That is most certainly not a troll (as long as constant factors
> are relatively small).  As computers get faster, and grid and
> distributed computing become more ubiquitous, I think this will
> become (if it already hasn't) the mainstream opinion on efficiency. 
> ie: In most cases, _including_ most embedded and real-time systems,
> efficiency will not be all that high on the list of desired
> qualities when one chooses an implementation language.  When cheap
> off the shelf chips routinely execute instructions on the order of
> nanoseconds.... and they're only going to get faster.

Pick yourself an O(Ncube) algorithm.  Implement it in some
portable language.  

Execute that on, say, a 2 MHz 8080 or z80 system.  Find the value
of N for which you feel execution time is becoming a nuisance. 
Record N and Time (N0 and T)

Repeat the above steps on a 2 GHz system, or whatever.  Record the
new N (N1), since T should be roughly the same.  Let us know the
values of N0, N1, and T.  Extrapolate (or even calculate) the
expected result after another 1000x improvement in hardware speed.

(you can trade off hardware speed for efficiency, if you like)

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in
news:BLRVb.2354$y07.187294@news20.bellglobal.com: 

> 
> "Alf P. Steinbach" <alfps@start.no> wrote in message
> news:40233c83.88223421@News.CIS.DFN.DE...
>> On Fri, 6 Feb 2004 08:49:44 +0200, "David Turner"
>> <david@firepro.co.za> 
> wrote:
>> >"Alf P. Steinbach" <alfps@start.no> wrote in message
>> >
> 
>> >Efficiency doesn't really concern me, and I don't see why any
>> >programmer should be overly concerned with it, provided the
>> >asymptotic behaviour is right.
>>
>> Troll #1.
>>
> 
> That is most certainly not a troll (as long as constant factors are
> relatively small).  As computers get faster, and grid and distributed
> computing become more ubiquitous, I think this will become (if it
> already hasn't) the mainstream opinion on efficiency.  ie: In most
> cases, _including_ most embedded and real-time systems, efficiency
> will not be all that high on the list of desired qualities when one
> chooses an implementation language.  When cheap off the shelf chips
> routinely execute instructions on the order of nanoseconds.... and
> they're only going to get faster.
> 
> l8r, Mike N. Christoff

The problem in embedded circles is the definition of 'cheap'. If it's a 
relatively bespoke piece of kit, each unit can have a relatively high-cost 
to manufacture and hence a high-cost to the purchaser. Usually, that's 
reasonable. A trade off between using a more expensive but more powerful 
hardware platform which reduces the complexity and development time of the 
software is a Good Idea.

The problem is that such a choice simply doesn't scale IME. The more units 
you're producing the greater the benefit of using a cheaper hardware but 
more expensive software development costs. Knocking off �2 from the 
manufacturing cost of the hardware for the sake of doubling the �100,000 
software development cost becomes a really Good Idea for mass-market 
electronics.

It's for this reason that I believe that there is always going to be a 
demand for 'low level' languages and the people who have the skills to 
write robust, efficient code in them. As long as there exists a 
price/performance trade off, there will always be a need for efficient 
code.

Ian Woods

-- 
"I'm a paranoid schizophrenic sado-masochist.
My other half's out to get me and I can't wait."
Richard Heathfield

Hi

> The problem in embedded circles is the definition of 'cheap'. If it's a
> relatively bespoke piece of kit, each unit can have a relatively high-cost
> to manufacture and hence a high-cost to the purchaser. Usually, that's
> reasonable. A trade off between using a more expensive but more powerful
> hardware platform which reduces the complexity and development time of the
> software is a Good Idea.
[etc..]

I agree that the embedded space, particularly, needs efficient solutions.
However, remember Knuth:

    "Premature optimization is the root of all evil".

....and the little-known rider:

    "The value of evil can be measured in dollars".

Regards
David Turner

"Josh Sebastian" <curien@cox.net> wrote in message
news:pan.2004.02.10.02.06.48.655156@cox.net...
> On Mon, 09 Feb 2004 00:58:44 +0000, Walter wrote:
>
> > But if you're talking about things like nested functions for
> > example, D can do them, and C++ cannot.
>
>   void foo {
>     struct nested {
>       static void bar() {
>       }
>     };
>     nested::bar();
>   }

Only as a member of a nested class, and with a crippling shortcoming -
nested::bar() cannot access any of foo's local non-static variables. It's
explicitly disallowed by the C++ standard 9.8-1 "Declarations in a local
class can use only type names, static variables, extern variables and
functions, and enumerators from the enclosing scope." For example:

int foo(int x)
{
    int bar(int c) { return x + c; }    // legal D, illegal C++

    return bar(6);
}

-Walter
www.digitalmars.com free C/C++/D compilers

"Ian Woods" <newspub2@wuggyNOCAPS.org> wrote in message
news:Xns948B1E6D36495newspubwuggyorg@217.32.252.50...
> "Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in
> news:BLRVb.2354$y07.187294@news20.bellglobal.com:
>
> >
> > "Alf P. Steinbach" <alfps@start.no> wrote in message
> > news:40233c83.88223421@News.CIS.DFN.DE...
> >> On Fri, 6 Feb 2004 08:49:44 +0200, "David Turner"
> >> <david@firepro.co.za>
> > wrote:
> >> >"Alf P. Steinbach" <alfps@start.no> wrote in message
> >> >
> >
> >> >Efficiency doesn't really concern me, and I don't see why any
> >> >programmer should be overly concerned with it, provided the
> >> >asymptotic behaviour is right.
> >>
> >> Troll #1.
> >>
> >
> > That is most certainly not a troll (as long as constant factors are
> > relatively small).  As computers get faster, and grid and distributed
> > computing become more ubiquitous, I think this will become (if it
> > already hasn't) the mainstream opinion on efficiency.  ie: In most
> > cases, _including_ most embedded and real-time systems, efficiency
> > will not be all that high on the list of desired qualities when one
> > chooses an implementation language.  When cheap off the shelf chips
> > routinely execute instructions on the order of nanoseconds.... and
> > they're only going to get faster.
> >
> > l8r, Mike N. Christoff
>
> The problem in embedded circles is the definition of 'cheap'. If it's a
> relatively bespoke piece of kit, each unit can have a relatively high-cost
> to manufacture and hence a high-cost to the purchaser. Usually, that's
> reasonable. A trade off between using a more expensive but more powerful
> hardware platform which reduces the complexity and development time of the
> software is a Good Idea.
>
> The problem is that such a choice simply doesn't scale IME. The more units
> you're producing the greater the benefit of using a cheaper hardware but
> more expensive software development costs. Knocking off �2 from the
> manufacturing cost of the hardware for the sake of doubling the �100,000
> software development cost becomes a really Good Idea for mass-market
> electronics.
>

I don't buy that.  If that were true we'd have never seen things like Java
vms on cell phones and smart cards.  One could knock off a lot more than $2
from cell phones by not having to need enough processing power to run a vm,
for example.  However I agree there will always be a need for efficient
code.



l8r, Mike N. Christoff

David Turner <david@firepro.co.za>
wrote on 8 Feb 2004 06:44:47 -0800:
> What I *don't* like is the attitude that "our programs will be
> safe/secure/crash-proof/supercowpowered because we wrote them on the
> Java/.NET/foo platform".

  There are programmers with bad attitudes and arrogance programming in
every language.  You are certainly not the person to start pointing
fingers on that subject.

  If you want to ensure that you close streams (or otherwise manage
resources) when you're done with them in Java, you use the standard
idiom:

Connection conn = null;
try {
    conn = new Connection();
    conn.doStuff();
} finally {
    if( conn != null ) {
        conn.close();
        conn = null;
    }
}

  There are higher-level techniques possible using weak references and
object pools, which are useful in large-scale applications.

  Cleaning up resources is covered in excruciating detail in basically
every tutorial and text on Java, which makes me...  dubious...  of your
authority on the subject.

  If you don't bother to learn the local idiom, you just come off
looking idiotic.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

"Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message <news:slrnc2lh23.elu.kamikaze@kuoi.asui.uidaho.edu>...

> David Turner <david@firepro.co.za>
> wrote on 8 Feb 2004 06:44:47 -0800:
> > What I *don't* like is the attitude that "our programs will be
> > safe/secure/crash-proof/supercowpowered because we wrote them on the
> > Java/.NET/foo platform".
>
>   There are programmers with bad attitudes and arrogance programming in
> every language.  You are certainly not the person to start pointing
> fingers on that subject.
>
>   If you want to ensure that you close streams (or otherwise manage
> resources) when you're done with them in Java, you use the standard
> idiom:
>
> Connection conn = null;
> try {
>     conn = new Connection();
>     conn.doStuff();
> } finally {
>     if( conn != null ) {
>         conn.close();
>         conn = null;
>     }
> }
>
>   There are higher-level techniques possible using weak references and
> object pools, which are useful in large-scale applications.

However, these are typically at the tender mercies of the garbage collector.

>   Cleaning up resources is covered in excruciating detail in basically
> every tutorial and text on Java, which makes me...  dubious...  of your
> authority on the subject.
>
>   If you don't bother to learn the local idiom, you just come off
> looking idiotic.

WI the "local idiom" itself sucks dead ebola monkey nuts through a syringe?

--
Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Hello

>   There are programmers with bad attitudes and arrogance programming in
> every language.  You are certainly not the person to start pointing
> fingers on that subject.

Really?


>   If you want to ensure that you close streams (or otherwise manage
> resources) when you're done with them in Java, you use the standard
> idiom:
[snipped]

You're missing my point completely.  There is no way in Java to *enforce*
design policies.  Which is exactly why:

>   Cleaning up resources is covered in excruciating detail in basically
> every tutorial and text on Java, which makes me...  dubious...  of your
> authority on the subject.

The fact that cleaning up resources is covered in such "excruciating" detail
is symptomatic of the problem.

>   If you don't bother to learn the local idiom, you just come off
> looking idiotic.

Indeed.  The same principle applies to debate.

Regards
David Turner

David Turner <david@firepro.co.za>
wrote on Thu, 12 Feb 2004 09:25:12 +0200:
> Hello
>>   There are programmers with bad attitudes and arrogance programming in
>> every language.  You are certainly not the person to start pointing
>> fingers on that subject.
> Really?
>>   If you want to ensure that you close streams (or otherwise manage
>> resources) when you're done with them in Java, you use the standard
>> idiom:
>[snipped]
> You're missing my point completely.  There is no way in Java to *enforce*
> design policies.  Which is exactly why:

  There's no way to enforce good behavior in any language.  A determined
asshat can produce bad code regardless of the language's "defenses".
But your point was that Java is incapable of managing resources, and to
"prove" that point you used broken examples in .NET and Java that would
get you fired from any professional programming job.  Sadly, you were
wrong.  This would be a good point for you to realize this and get over
it.

>>   Cleaning up resources is covered in excruciating detail in basically
>> every tutorial and text on Java, which makes me...  dubious...  of your
>> authority on the subject.
> The fact that cleaning up resources is covered in such "excruciating" detail
> is symptomatic of the problem.

  The technique works reliably, is well documented, and makes the flow
of control obvious.  It's not a problem, except to people with an agenda
and a weak grasp of the facts.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:1076547199.358882@news-1.nethere.net...
> "Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message
<news:slrnc2lh23.elu.kamikaze@kuoi.asui.uidaho.edu>...
>
> > David Turner <david@firepro.co.za>
> > wrote on 8 Feb 2004 06:44:47 -0800:
> > > What I *don't* like is the attitude that "our programs will be
> > > safe/secure/crash-proof/supercowpowered because we wrote them on the
> > > Java/.NET/foo platform".
> >
> >   There are programmers with bad attitudes and arrogance programming in
> > every language.  You are certainly not the person to start pointing
> > fingers on that subject.
> >
> >   If you want to ensure that you close streams (or otherwise manage
> > resources) when you're done with them in Java, you use the standard
> > idiom:
> >
> > Connection conn = null;
> > try {
> >     conn = new Connection();
> >     conn.doStuff();
> > } finally {
> >     if( conn != null ) {
> >         conn.close();
> >         conn = null;
> >     }
> > }
> >
> >   There are higher-level techniques possible using weak references and
> > object pools, which are useful in large-scale applications.
>
> However, these are typically at the tender mercies of the garbage
collector.
>

Uh, the method conn.close() releases the resource immediately.  The object
simply _connects_ to the real resource whic is the database.  That this, now
useless, connector object is not itself collected immediately is irrelevent
to this discussion.



l8r, Mike N. Christoff

"Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message
news:slrnc2n6d0.12nd.kamikaze@kuoi.asui.uidaho.edu...
> David Turner <david@firepro.co.za>
> wrote on Thu, 12 Feb 2004 09:25:12 +0200:
> > Hello
> >>   There are programmers with bad attitudes and arrogance programming in
> >> every language.  You are certainly not the person to start pointing
> >> fingers on that subject.
> > Really?
> >>   If you want to ensure that you close streams (or otherwise manage
> >> resources) when you're done with them in Java, you use the standard
> >> idiom:
> >[snipped]
> > You're missing my point completely.  There is no way in Java to
*enforce*
> > design policies.  Which is exactly why:
>
>   There's no way to enforce good behavior in any language.  A determined
> asshat can produce bad code regardless of the language's "defenses".
> But your point was that Java is incapable of managing resources, and to
> "prove" that point you used broken examples in .NET and Java that would
> get you fired from any professional programming job.  Sadly, you were
> wrong.  This would be a good point for you to realize this and get over
> it.
>
> >>   Cleaning up resources is covered in excruciating detail in basically
> >> every tutorial and text on Java, which makes me...  dubious...  of your
> >> authority on the subject.
> > The fact that cleaning up resources is covered in such "excruciating"
detail
> > is symptomatic of the problem.
>
>   The technique works reliably, is well documented, and makes the flow
> of control obvious.  It's not a problem, except to people with an agenda
> and a weak grasp of the facts.
>

The bottom line is that any employment-worthy Java/C# developer should have
no problem releasing resources properly.  Is it easier to do this with a
language with direct support for RAII?  Probably.  Is it impossible or even
difficult to release resources properly in Java/C#.  Absolutely not.



l8r, Mike N. Christoff

"Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in message <news:f5QWb.8530$lK.602740@news20.bellglobal.com>...

> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> news:1076547199.358882@news-1.nethere.net...
> > "Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message
> <news:slrnc2lh23.elu.kamikaze@kuoi.asui.uidaho.edu>...
> >
> > > David Turner <david@firepro.co.za>
> > > wrote on 8 Feb 2004 06:44:47 -0800:
> > > > What I *don't* like is the attitude that "our programs will be
> > > > safe/secure/crash-proof/supercowpowered because we wrote them on the
> > > > Java/.NET/foo platform".
> > >
> > >   There are programmers with bad attitudes and arrogance programming in
> > > every language.  You are certainly not the person to start pointing
> > > fingers on that subject.
> > >
> > >   If you want to ensure that you close streams (or otherwise manage
> > > resources) when you're done with them in Java, you use the standard
> > > idiom:
> > >
> > > Connection conn = null;
> > > try {
> > >     conn = new Connection();
> > >     conn.doStuff();
> > > } finally {
> > >     if( conn != null ) {
> > >         conn.close();
> > >         conn = null;
> > >     }
> > > }
> > >
> > >   There are higher-level techniques possible using weak references and
> > > object pools, which are useful in large-scale applications.
> >
> > However, these are typically at the tender mercies of the garbage
> collector.
> >
>
> Uh, the method conn.close() releases the resource immediately.  The object
> simply _connects_ to the real resource whic is the database.  That this, now
> useless, connector object is not itself collected immediately is irrelevent
> to this discussion.

Duuh, I seem to be under the delusion that we're talking about
non-memory resource management, not silly schemes to recycle
"about to be GC'd objects" which will only bloat the precious
working set, if the usual Cheerleaders.NET are to be believed.

--
Joe Foster <mailto:jlfoster%40znet.com>   L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in message <news:v8QWb.8534$lK.602971@news20.bellglobal.com>...

> "Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message
> news:slrnc2n6d0.12nd.kamikaze@kuoi.asui.uidaho.edu...

> >   The technique works reliably, is well documented, and makes the flow
> > of control obvious.  It's not a problem, except to people with an agenda
> > and a weak grasp of the facts.
> >
>
> The bottom line is that any employment-worthy Java/C# developer should have
> no problem releasing resources properly.  Is it easier to do this with a
> language with direct support for RAII?  Probably.  Is it impossible or even
> difficult to release resources properly in Java/C#.  Absolutely not.

Similarly, while GC-addicted languages such as Java and C# may or
may not make it easier to manage memory, if not other important
resources, any employment-worthy programmer should have no problem
releasing memory properly using good old free(), and any program
with absolutely any memory leaks whatsoever should be a firing
offense, right?  After all, is it impossible or even difficult to
release memory or other resources properly in C?  Absolutely not.
It's not a problem, except to people with an agenda and a weak
grasp of the facts.

--
Joe Foster <mailto:jlfoster%40znet.com>   L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:1076615354.645371@news-1.nethere.net...
> "Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in
message <news:f5QWb.8530$lK.602740@news20.bellglobal.com>...
>
> > "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> > news:1076547199.358882@news-1.nethere.net...
> > > "Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in
message
> > <news:slrnc2lh23.elu.kamikaze@kuoi.asui.uidaho.edu>...
> > >
> > > > David Turner <david@firepro.co.za>
> > > > wrote on 8 Feb 2004 06:44:47 -0800:
> > > > > What I *don't* like is the attitude that "our programs will be
> > > > > safe/secure/crash-proof/supercowpowered because we wrote them on
the
> > > > > Java/.NET/foo platform".
> > > >
> > > >   There are programmers with bad attitudes and arrogance programming
in
> > > > every language.  You are certainly not the person to start pointing
> > > > fingers on that subject.
> > > >
> > > >   If you want to ensure that you close streams (or otherwise manage
> > > > resources) when you're done with them in Java, you use the standard
> > > > idiom:
> > > >
> > > > Connection conn = null;
> > > > try {
> > > >     conn = new Connection();
> > > >     conn.doStuff();
> > > > } finally {
> > > >     if( conn != null ) {
> > > >         conn.close();
> > > >         conn = null;
> > > >     }
> > > > }
> > > >
> > > >   There are higher-level techniques possible using weak references
and
> > > > object pools, which are useful in large-scale applications.
> > >
> > > However, these are typically at the tender mercies of the garbage
> > collector.
> > >
> >
> > Uh, the method conn.close() releases the resource immediately.  The
object
> > simply _connects_ to the real resource whic is the database.  That this,
now
> > useless, connector object is not itself collected immediately is
irrelevent
> > to this discussion.
>
> Duuh, I seem to be under the delusion that we're talking about
> non-memory resource management,

Yes.  Do you categorize a database connection a memory resource or a
non-memory resource?



l8r, Mike N. Christoff

In article <1076617371.657394@news-1.nethere.net>,
Joe \"Nuke Me Xemu\" Foster <jlf%40znet%2ecom> wrote:
   ...
>Similarly, while GC-addicted languages such as Java and C# may or
>may not make it easier to manage memory, if not other important
>resources, any employment-worthy programmer should have no problem
>releasing memory properly using good old free(), and any program
>with absolutely any memory leaks whatsoever should be a firing
>offense, right?  After all, is it impossible or even difficult to
>release memory or other resources properly in C?  Absolutely not.

It depends on what the language lets you do with dynamic memory. Java and
C# arn't the best example of this, but taken to the extreme, _everything_
can be allocated on a GC heap: stack frames, continuations, variable 
bindings, whatever.  This gives all these structures a degree of 
flexibility and expressive power that C can't match, and it's made almost 
entirely feasable by the fact that the programmer doesn't have to 
explicitly free everything allocated on the heap.

The best example of this is something called a lexical closure, basically
a function bound to its run-time lexical environment.  Let me illustrate:

(define (make-adder k)
  (lambda (x) (+ k x)))

This function, written in Scheme, returns a closure. The second line of 
the function is itself a definition of a function that is returned by 
make-adder. You'll notice that the embedded function refers to a variable 
k, that is defined in the parameter list of the outer function. In a 
stack-based allocation method like that espoused by propoents of RAII, the 
storage for the value of k would be freed when make-adder returned. 
However, allocate the variable binding on the garbage collected heap, and 
the GC algorithm will notice that there are two references to k: one by 
make-adder and one by the inner function. As a consequence it'll retain 
the binding to k as long as the inner function sticks around.

As much a fan of C as I am, this flexibility can be awfully nice...

-Mike
-- 
http://www.mschaef.com

"Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in message <news:_hRWb.8561$lK.608067@news20.bellglobal.com>...

> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> news:1076615354.645371@news-1.nethere.net...
> > "Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in
> message <news:f5QWb.8530$lK.602740@news20.bellglobal.com>...
> >
> > > "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> > > news:1076547199.358882@news-1.nethere.net...
> > > > "Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message
> > > <news:slrnc2lh23.elu.kamikaze@kuoi.asui.uidaho.edu>...
> > > >
> > > > > David Turner <david@firepro.co.za>
> > > > > wrote on 8 Feb 2004 06:44:47 -0800:
> > > > > > What I *don't* like is the attitude that "our programs will be
> > > > > > safe/secure/crash-proof/supercowpowered because we wrote them on the
> > > > > > Java/.NET/foo platform".
> > > > >
> > > > >   There are programmers with bad attitudes and arrogance programming in
> > > > > every language.  You are certainly not the person to start pointing
> > > > > fingers on that subject.
> > > > >
> > > > >   If you want to ensure that you close streams (or otherwise manage
> > > > > resources) when you're done with them in Java, you use the standard
> > > > > idiom:
> > > > >
> > > > > Connection conn = null;
> > > > > try {
> > > > >     conn = new Connection();
> > > > >     conn.doStuff();
> > > > > } finally {
> > > > >     if( conn != null ) {
> > > > >         conn.close();
> > > > >         conn = null;
> > > > >     }
> > > > > }
> > > > >
> > > > >   There are higher-level techniques possible using weak references and
> > > > > object pools, which are useful in large-scale applications.
> > > >
> > > > However, these are typically at the tender mercies of the garbage
> > > collector.
> > > >
> > >
> > > Uh, the method conn.close() releases the resource immediately.  The object
> > > simply _connects_ to the real resource whic is the database.  That this, now
> > > useless, connector object is not itself collected immediately is irrelevent
> > > to this discussion.
> >
> > Duuh, I seem to be under the delusion that we're talking about
> > non-memory resource management,
>
> Yes.  Do you categorize a database connection a memory resource or a
> non-memory resource?

Yes.  I suppose it's all 'only' memory, if you go far enough below the
surface. However, an open database connection could soak up a TCP/IP
socket or a database server license from a comparatively limited pool.
What exactly is your point?  Are we going to go for a little swim in
the Turing tar-pit or what?

--
Joe Foster <mailto:jlfoster%40znet.com>     On the cans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:1076619385.273084@news-1.nethere.net...
> "Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in
message <news:_hRWb.8561$lK.608067@news20.bellglobal.com>...
>
> > "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> > news:1076615354.645371@news-1.nethere.net...
> > > "Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in
> > message <news:f5QWb.8530$lK.602740@news20.bellglobal.com>...
> > >
> > > > "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> > > > news:1076547199.358882@news-1.nethere.net...
> > > > > "Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in
message
> > > > <news:slrnc2lh23.elu.kamikaze@kuoi.asui.uidaho.edu>...
> > > > >
> > > > > > David Turner <david@firepro.co.za>
> > > > > > wrote on 8 Feb 2004 06:44:47 -0800:
> > > > > > > What I *don't* like is the attitude that "our programs will be
> > > > > > > safe/secure/crash-proof/supercowpowered because we wrote them
on the
> > > > > > > Java/.NET/foo platform".
> > > > > >
> > > > > >   There are programmers with bad attitudes and arrogance
programming in
> > > > > > every language.  You are certainly not the person to start
pointing
> > > > > > fingers on that subject.
> > > > > >
> > > > > >   If you want to ensure that you close streams (or otherwise
manage
> > > > > > resources) when you're done with them in Java, you use the
standard
> > > > > > idiom:
> > > > > >
> > > > > > Connection conn = null;
> > > > > > try {
> > > > > >     conn = new Connection();
> > > > > >     conn.doStuff();
> > > > > > } finally {
> > > > > >     if( conn != null ) {
> > > > > >         conn.close();
> > > > > >         conn = null;
> > > > > >     }
> > > > > > }
> > > > > >
> > > > > >   There are higher-level techniques possible using weak
references and
> > > > > > object pools, which are useful in large-scale applications.
> > > > >
> > > > > However, these are typically at the tender mercies of the garbage
> > > > collector.
> > > > >
> > > >
> > > > Uh, the method conn.close() releases the resource immediately.  The
object
> > > > simply _connects_ to the real resource whic is the database.  That
this, now
> > > > useless, connector object is not itself collected immediately is
irrelevent
> > > > to this discussion.
> > >
> > > Duuh, I seem to be under the delusion that we're talking about
> > > non-memory resource management,
> >
> > Yes.  Do you categorize a database connection a memory resource or a
> > non-memory resource?
>
> Yes.  I suppose it's all 'only' memory, if you go far enough below the
> surface. However, an open database connection could soak up a TCP/IP
> socket or a database server license from a comparatively limited pool.
> What exactly is your point?  Are we going to go for a little swim in
> the Turing tar-pit or what?
>

Actually, my point was that, for all practical purposes a db should be
considered a non-memory resource.  You made a point that the program was
under mercy of the gc.  My point was that, in terms of the resource (ie: the
db), the gc was irrelevent since the db connection was freed as soon as
conn.close was called which may be long before the gc gets involved.

I think we are talking past each other. :)



l8r, Mike N. Christoff

kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote in message news:<slrnc2lh23.elu.kamikaze@kuoi.asui.uidaho.edu>...
> David Turner <david@firepro.co.za>
> wrote on 8 Feb 2004 06:44:47 -0800:
> > What I *don't* like is the attitude that "our programs will be
> > safe/secure/crash-proof/supercowpowered because we wrote them on the
> > Java/.NET/foo platform".
> 
>   There are programmers with bad attitudes and arrogance programming in
> every language.  You are certainly not the person to start pointing
> fingers on that subject.
> 
>   If you want to ensure that you close streams (or otherwise manage
> resources) when you're done with them in Java, you use the standard
> idiom:
> 
> Connection conn = null;
> try {
>     conn = new Connection();
>     conn.doStuff();
> } finally {
>     if( conn != null ) {
>         conn.close();
>         conn = null;
>     }
> }

The problem is that this idiom is seven lines of boilerplate code that
have to be repeated every time a connection is used.  It's all too
easy to screw up and forget to do it once, and all too difficult to
find the screw-up when your program fails due to a shortage of
connections.  The only option is to search the entire program text for
code that opens a connection but fails to close it.  We have a lot of
experience hunting memory leaks in C programs, and it's no fun.  It's
no more fun to hunt resource leaks in Java and C# programs.

I prefer languages that let me solve a problem once and forget about
it.  In C++ I would write a destructor for the connection class, and
then just say:

  Connection conn(...);
  conn.doStuff();

No worries as long as the connection class was implemented properly. 
And if there's a bug, I know exactly where to look.

In C# I would write:

  using (Connection conn = new Connection(...)) {
    conn.doStuff();
  }

This is better than the Java idiom, but it's still possible to screw
up and write:

  conn = new Connection();
  conn.doStuff();

The problem with Java and C# is that code that appears correct may
leak resources, and there's no way to know without examining the code
for all the objects created.

I prefer languages where simple code can be correct code.  I don't
like languages that require me to repeatedly perform complex rituals
to keep the demons away.

"MSCHAEF.COM" <mschaef@io.com> wrote in message
news:Faydnc9JIt4terbdRVn-jQ@io.com...
> In article <1076617371.657394@news-1.nethere.net>,
> Joe \"Nuke Me Xemu\" Foster <jlf%40znet%2ecom> wrote:
>    ...
> >Similarly, while GC-addicted languages such as Java and C# may or
> >may not make it easier to manage memory, if not other important
> >resources, any employment-worthy programmer should have no problem
> >releasing memory properly using good old free(), and any program
> >with absolutely any memory leaks whatsoever should be a firing
> >offense, right?  After all, is it impossible or even difficult to
> >release memory or other resources properly in C?  Absolutely not.
>
> It depends on what the language lets you do with dynamic memory. Java and
> C# arn't the best example of this, but taken to the extreme, _everything_
> can be allocated on a GC heap: stack frames, continuations, variable
> bindings, whatever.  This gives all these structures a degree of
> flexibility and expressive power that C can't match, and it's made almost
> entirely feasable by the fact that the programmer doesn't have to
> explicitly free everything allocated on the heap.
>
> The best example of this is something called a lexical closure, basically
> a function bound to its run-time lexical environment.  Let me illustrate:
>
> (define (make-adder k)
>   (lambda (x) (+ k x)))
>
> This function, written in Scheme, returns a closure. The second line of
> the function is itself a definition of a function that is returned by
> make-adder. You'll notice that the embedded function refers to a variable
> k, that is defined in the parameter list of the outer function. In a
> stack-based allocation method like that espoused by propoents of RAII, the
> storage for the value of k would be freed when make-adder returned.
> However, allocate the variable binding on the garbage collected heap, and
> the GC algorithm will notice that there are two references to k: one by
> make-adder and one by the inner function. As a consequence it'll retain
> the binding to k as long as the inner function sticks around.
>
> As much a fan of C as I am, this flexibility can be awfully nice...
>

What is the practical benefit of closures?

class PsuedoClosure()
{
    private int k = 0;
    public PsudeoClosure(int k) {this.k = k;}
    public int add(int x) {return x + k;}
}

PsuedoClosure makeAddr(int k)
{
    return new PsudeoClosure(k);
}



l8r, Mike N. Christoff

"Kevin Cline" <kcline17@hotmail.com> wrote in message <news:ba162549.0402121308.3a5ade0b@posting.google.com>...

> The problem with Java and C# is that code that appears correct may
> leak resources, and there's no way to know without examining the code
> for all the objects created.
>
> I prefer languages where simple code can be correct code.  I don't
> like languages that require me to repeatedly perform complex rituals
> to keep the demons away.

The current 'best practice' seems to be to throw an exception in
the finalizer in order to crash the program with an unfriendly
diagnostic message.  Of course, since Java is no longer guaranteed
to even call pending finalizers on normal program exit, this is
even farther from a 'panacea' than it first appears.  And the Java
bigots wonder why Visual Basic was one of the most popular languages
before Micro$haft killed it in favor of their buggered Java clones!

--
Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Michael N. Christoff" wrote:

>> [...closure...]
> 
> What is the practical benefit of closures?
> 
> class PsuedoClosure() { /*...*/ };

[BWG] Perhaps--not unlike class syntax--it makes the source a bit
more clear, and you don't have to "roll your own".

Now do it in C.  :->

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in message <news:qVRWb.8577$lK.611013@news20.bellglobal.com>...

> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> news:1076619385.273084@news-1.nethere.net...
> > "Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in
> message <news:_hRWb.8561$lK.608067@news20.bellglobal.com>...

> > > Yes.  Do you categorize a database connection a memory resource or a
> > > non-memory resource?
> >
> > Yes.  I suppose it's all 'only' memory, if you go far enough below the
> > surface. However, an open database connection could soak up a TCP/IP
> > socket or a database server license from a comparatively limited pool.
> > What exactly is your point?  Are we going to go for a little swim in
> > the Turing tar-pit or what?
> >
>
> Actually, my point was that, for all practical purposes a db should be
> considered a non-memory resource.  You made a point that the program was
> under mercy of the gc.  My point was that, in terms of the resource (ie: the
> db), the gc was irrelevent since the db connection was freed as soon as
> conn.close was called which may be long before the gc gets involved.
>
> I think we are talking past each other. :)

Then we're in (possibly violent) agreement.  However, I'd still like
to know what 'Kamikaze' was gabbling about with his "higher-level
techniques possible using weak references and object pools", which I
fear are the usual crapola depending on the GC doing a complete mark
and sweep at least once per second and damn the system responsiveness.

Anyway, if always having to remember to call .close() or .Dispose() is
a reasonable burden to place upon programmers, why not free() as well?
After all, memory is merely yet another resource to manage, is it not?

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Kevin Cline <kcline17@hotmail.com>
wrote on 12 Feb 2004 13:08:49 -0800:
> kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote in message news:<slrnc2lh23.elu.kamikaze@kuoi.asui.uidaho.edu>...
>>   If you want to ensure that you close streams (or otherwise manage
>> resources) when you're done with them in Java, you use the standard
>> idiom:
>> Connection conn = null;
>> try {
>>     conn = new Connection();
>>     conn.doStuff();
>> } finally {
>>     if( conn != null ) {
>>         conn.close();
>>         conn = null;
>>     }
>> }
> The problem is that this idiom is seven lines of boilerplate code that
> have to be repeated every time a connection is used.  It's all too
> easy to screw up and forget to do it once,

  That's a pretty trivial bit of code, though.  Hard to get it wrong,
and forgetting it isn't an option to anyone who bothered to learn the
language in the first place; making a connection means that you write
the try...finally block.  Period.  Since that code will have checked
exceptions, the compiler will tell you if you've forgotten.

  You shouldn't be repeating the same code in a dozen places anyway, so
it's not a problem even if you are completely absent-minded and have
poor exception handling.  You should do it right, once, and then your
code just invokes that method and works with the returned results.

  Oh, and this is obvious, but perhaps not to everyone:  If you aren't
catching exceptions in that code, you can simplify it to almost nothing:
Connection conn = new Connection();
try {
    conn.doStuff();
} finally {
    conn.close();
}

  However, real code will rarely do this, because you'll want to handle
exceptions, and "new Connection()" probably throws something.  The null
testing saves lines and produces clearer program flow in production
code.

> it.  In C++ I would write a destructor for the connection class, and

  But then you have to manage the memory yourself anyway, so you've
gained nothing in efficiency and lost everything in safety.  I'll take
the try...finally code and GC of Java over the manual memory management
and memory corruption of C++ every single day.

> I prefer languages where simple code can be correct code.  I don't
> like languages that require me to repeatedly perform complex rituals
> to keep the demons away.

  <shrug>  I should care about your tastes?  You don't like languages
like that, don't use 'em.  Nobody's forcing you to use Java; if your
workplace converts to it and you feel that strongly about it, you can
still go get a job elsewhere.  I just object to "Garbage Collection
Considered Harmful" rants which don't get the facts right.

  I wouldn't describe Java as beautiful or simple.  It's an ugly
language full of nasty surprises for naive kiddies who don't take the
time to learn it right.  For many tasks, I prefer Python, or various
domain scripting languages I've written in Java.  But Java's efficient,
powerful, and rigorously correct in its behavior, if you know what
you're doing.  If you don't, go use a simpler language.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

"Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message <news:slrnc2o09n.2jnr.kamikaze@kuoi.asui.uidaho.edu>...

> Kevin Cline <kcline17@hotmail.com>
> wrote on 12 Feb 2004 13:08:49 -0800:

> > it.  In C++ I would write a destructor for the connection class, and
>
>   But then you have to manage the memory yourself anyway, so you've
> gained nothing in efficiency and lost everything in safety.  I'll take
> the try...finally code and GC of Java over the manual memory management
> and memory corruption of C++ every single day.

Uhh, have you actually used C++ in the past ten years or so?

 http://hackcraft.net/raii/

 http://www.research.att.com/~bs/bs_faq2.html#finally considered harmful

--
Joe Foster <mailto:jlfoster%40znet.com>   L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Joe \"Nuke Me Xemu\" Foster <joe@bftsi0.UUCP>
wrote on Thu, 12 Feb 2004 13:34:30 -0800:
> The current 'best practice' seems to be to throw an exception in
> the finalizer in order to crash the program with an unfriendly
> diagnostic message.  Of course, since Java is no longer guaranteed
> to even call pending finalizers on normal program exit, this is
> even farther from a 'panacea' than it first appears.

  Finalizers never worked reliably in Java, and anyone who relied on
them was writing bad code in defiance of the documentation and all
accepted practice.  It would be nice if they had been functional, at
least at program close, but that's not the case.  But what is it that
you'd prefer a language to do when an exception occurs in a finalizer?
Trap and display it, and continue on to the next 10000 identical objects
which will also fail?  That sounds like a cunning and very
developer-friendly solution.  Please demonstrate this technique in your
language so we can all observe how useful it is.

>  And the Java
> bigots wonder why Visual Basic was one of the most popular languages
> before Micro$haft killed it in favor of their buggered Java clones!

  I'm fairly described as a Java bigot[0], and I don't wonder that about
VB at all.  VB was a brain-damaged[1] language designed to allow
non-programmers to attach 10k of broken code to a GUI button, or to
create the exciting new field of email viruses.  It filled the niche
that Hypercard did on the Mac, but with Microsoft's usual standard of
ease of use and quality instead of Apple's.  Its popularity among
Windoze users is completely unsurprising.

[0] Really, more of a "good languages bigot".  I'm perfectly happy with
Python, PHP, OCaml, and several other languages.  With time and some
practical examples of its use, D may well join that list.
[1] "It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers they
are mentally mutilated beyond hope of regeneration."
-Prof. Dr. Edsger W. Dijkstra
I don't fully agree with the good professor.  I do believe it's possible
to recover from bad programming languages.  I certainly hope so, since I
was raised on BASIC, before learning better.
-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

"Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message <news:slrnc2o772.2jnr.kamikaze@kuoi.asui.uidaho.edu>...

> Joe \"Nuke Me Xemu\" Foster <joe@bftsi0.UUCP>
> wrote on Thu, 12 Feb 2004 13:34:30 -0800:
> > The current 'best practice' seems to be to throw an exception in
> > the finalizer in order to crash the program with an unfriendly
> > diagnostic message.  Of course, since Java is no longer guaranteed
> > to even call pending finalizers on normal program exit, this is
> > even farther from a 'panacea' than it first appears.
>
>   Finalizers never worked reliably in Java, and anyone who relied on
> them was writing bad code in defiance of the documentation and all
> accepted practice.  It would be nice if they had been functional, at
> least at program close, but that's not the case.  But what is it that
> you'd prefer a language to do when an exception occurs in a finalizer?
> Trap and display it, and continue on to the next 10000 identical objects
> which will also fail?  That sounds like a cunning and very
> developer-friendly solution.  Please demonstrate this technique in your
> language so we can all observe how useful it is.

I've posted pointers to the RAII idiom in a reply to a different
post.  Real languages have real object destructors.  Even VB has
Class_Terminate, as opposed to Java's totally broken finalizers.

> >  And the Java
> > bigots wonder why Visual Basic was one of the most popular languages
> > before Micro$haft killed it in favor of their buggered Java clones!
>
>   I'm fairly described as a Java bigot[0], and I don't wonder that about
> VB at all.  VB was a brain-damaged[1] language designed to allow
> non-programmers to attach 10k of broken code to a GUI button, or to
> create the exciting new field of email viruses.

Any sufficiently powerful macro language, such as VBA or VBScript,
can be used to create viruses.  It was possible in Lotus 1-2-3's
macro language as well.

>  It filled the niche
> that Hypercard did on the Mac, but with Microsoft's usual standard of
> ease of use and quality instead of Apple's.  Its popularity among
> Windoze users is completely unsurprising.
>
> [0] Really, more of a "good languages bigot".  I'm perfectly happy with
> Python, PHP, OCaml, and several other languages.  With time and some
> practical examples of its use, D may well join that list.
> [1] "It is practically impossible to teach good programming to students
> that have had a prior exposure to BASIC: as potential programmers they
> are mentally mutilated beyond hope of regeneration."
> -Prof. Dr. Edsger W. Dijkstra
> I don't fully agree with the good professor.  I do believe it's possible
> to recover from bad programming languages.  I certainly hope so, since I
> was raised on BASIC, before learning better.

Do you actually know anything about VB at all, or do you really
believe Basic as a language hasn't progressed in absolutely any
way whatsoever since 1974, when Dijkstra said that?  Do you also
agree with Dijkstra about object orientation?

"Object-oriented programming is an exceptionally bad idea that
could only have been invented in California."
http://quote.wikipedia.org/wiki/Edsger_Dijkstra

--
Joe Foster <mailto:jlfoster%40znet.com>   L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Hi

[snip]
> The best example of this is something called a lexical closure, basically
> a function bound to its run-time lexical environment.  Let me illustrate:
>
> (define (make-adder k)
>   (lambda (x) (+ k x)))
[snip]

Just a point of interest - have you seen the boost lambda library?

Regards
David Turner

Hi

>   There's no way to enforce good behavior in any language.  A determined
> asshat can produce bad code regardless of the language's "defenses".

I agree that it is possible, in principle, to violate any constraint place
upon you by a language/system.  However, the more difficult this is, the
less likely it is to occur.  I humbly suggest that it's far more difficult
to leak a resource that can only be accessed through a scoped sentry object
(which guarantees cleanup), than it is to forget a "finally {
resource.release(); }" block.


> But your point was that Java is incapable of managing resources, and to
> "prove" that point you used broken examples in .NET and Java that would

Careful.  I never said it was "incapable" of managing resources.  I said it
provided fewer tools to do so than C++.  This is a statement of fact, not an
opinion.


>   The technique works reliably, is well documented, and makes the flow
> of control obvious.  It's not a problem, except to people with an agenda
> and a weak grasp of the facts.

Au contraire.  It IS a problem, and a very serious one.  I myself have taken
financial damage from resource leaks in the Java-based internet banking site
that I use.  Perhaps that means I have an agenda - fair enough.  But I think
the accusation that I have a weak grasp of the facts is unfounded.

Regards
David Turner

Hello

> > it.  In C++ I would write a destructor for the connection class, and
>
>   But then you have to manage the memory yourself anyway, so you've
> gained nothing in efficiency and lost everything in safety.  I'll take
> the try...finally code and GC of Java over the manual memory management
> and memory corruption of C++ every single day.

I'm sorry, but... balls.  You clearly haven't grasped the significance of
the sample code that has now been posted several times.  The following is
*completely correct* C++ code:

typedef std::auto_ptr<Foo> SafeFoo;  // usually done in a header file
somewhere
void some_function_might_throw()
{
    SafeFoo my_foo = new Foo();
    my_foo->do_some_stuff_that_might_throw_exceptions();
}

The Foo object is *guaranteed* to be cleaned up, regardless of what happens.
I seriously recommend you follow this link, kindly provided by Joe Foster:

http://www.research.att.com/~bs/bs_faq2.html#finally


Regards
David Turner

In article <1076656599.165542@tanzanite.firepro.co.za>,
David Turner <david@firepro.co.za> wrote:
>Hi
>
>[snip]
>> The best example of this is something called a lexical closure, basically
>> a function bound to its run-time lexical environment.  Let me illustrate:
>>
>> (define (make-adder k)
>>   (lambda (x) (+ k x)))
>[snip]
>
>Just a point of interest - have you seen the boost lambda library?

I've seen it, along with some other parts of boost, but I haven't used it 
myself. From what I can tell, it's a truly remarkable piece of work, given
that the underlying language doesn't really offer any native support for 
anonymous functions. 

It's also worth pointing out that boost lambdas enforce some pretty severe
constraints on programers. Referring to parameters by an ordinal number is
more than a little crude, as is the fact that (from what I can tell, this
might be fixable with inlining)  boost lambdas can't be compiled as
efficiently as a "normal" function.

Until about a year ago, I had pretty much disconnected myself from the C++ 
community since 1996-7 (when I was using it regularly in school). There 
are a lot of amazing things going on with C++ these days.

-Mike

-- 
http://www.mschaef.com

In article <p5SWb.8593$lK.613813@news20.bellglobal.com>,
Michael N. Christoff <mchristoff@sympatico.caREMOVETHIS> wrote:
  ...
>What is the practical benefit of closures?
>
>class PsuedoClosure()
>{
>    private int k = 0;
>    public PsudeoClosure(int k) {this.k = k;}
>    public int add(int x) {return x + k;}
>}
>
>PsuedoClosure makeAddr(int k)
>{
>    return new PsudeoClosure(k);
>}

I'll revert to stuff like that quite often when writing in languages like 
C and C++. The benefit to closures is that, like most other HLL features, 
they make expressing something easier and more convenient, not to mention 
safer. 

As I'm sure you know, something that's a common idiom in C, when using
callbacks, is a user-pointer that's passed in when the callback is
registered and passed to the callback function when it's called. Closured
make these obsolete.  Rather than passing in a callback function and a
pointer, you pass in a closure, which brings with it its lexical
environment. What most likely in C is code that:

* defines a callback function (somewhere)
* defines a structure
* dynamically allocates it 
* explicitly initializes it
* passes it along with a named function into a callback
  registration function
* casts it back to a structure pointer, 
* and eventually frees the structure

becomes code that just declares an anonymous function exactly in line
with the code that uses it.

Here's another example, along these lines:

   (define (remove pred lis)
      (filter (lambda (x) (not (pred x))) lis))  
   
   (define (delete x lis) 
      (filter (lambda (y) (not (equal? x y))) lis))

These functions pass anonymous functions into the function filter to
filter list elements based on predicates. Both of the lambda functions
depend on variables bound at the invocation time of the outer function.

That's in 2 lines of code each...

Let's see about C++ (any mistakes are unintentional, I'm just typing this out):

   class IObjectPredicate
   {
   public:
      virtual bool satisfies(object &A) = 0;
   };

   list filter(IObjectPredicate *pred, list);

   class ObjectPredicateInverter
   {
   private:
      IObjectPredicate *_basePredicate;

   public:
      ObjectPredicateInverter(IObjectPredicate *basePredicate) 
      {
         _basePredicate = basePredicate;
      }

      virtual bool satisfies(object &A)
      {
         return !(_basePredicate->satisfies(A));
      }
   };

   list remove(IObjectPredicate *pred, list l)
   {
      // RAII sure is saving me a lot... ;-)
      ObjectPredicateInverter invertedPred(pred);
     
      return filter(&pred, l)
   } 
   
That's 15 lines of (non {/}) code, and that's assuming that filter
knows how to appropriately manage the storage of objects and lists.
To me this code is far more complicated (and RSI inducing) than the
simple little task it performs warrants.

-Mike
-- 
http://www.mschaef.com

Joe \"Nuke Me Xemu\" Foster <joe@bftsi0.UUCP>
wrote on Thu, 12 Feb 2004 17:20:54 -0800:
> "Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message <news:slrnc2o772.2jnr.kamikaze@kuoi.asui.uidaho.edu>...
>> Joe \"Nuke Me Xemu\" Foster <joe@bftsi0.UUCP>
>> wrote on Thu, 12 Feb 2004 13:34:30 -0800:
> I've posted pointers to the RAII idiom in a reply to a different
> post.

  I looked.  Not particularly valuable theory-wanking, it looks to me.

>  Real languages have real object destructors.  Even VB has
> Class_Terminate, as opposed to Java's totally broken finalizers.

  Java is a real language, and does not.  Lisp is a real language, and
(without major hackery of the runtime) does not.  I can find many more.
Your assertion is false.

  It's a wart, but not a deal-breaking one.  I suggest you get over it
and accept that not everyone is as obsessed on the subject as you are.

  If you seriously think that VB monkeys chose VB because it has
finalizers, you need to check the color of the sky in your world.

>> >  And the Java
>> > bigots wonder why Visual Basic was one of the most popular languages
>> > before Micro$haft killed it in favor of their buggered Java clones!
>>   I'm fairly described as a Java bigot[0], and I don't wonder that about
>> VB at all.  VB was a brain-damaged[1] language designed to allow
>> non-programmers to attach 10k of broken code to a GUI button, or to
>> create the exciting new field of email viruses.
> Any sufficiently powerful macro language, such as VBA or VBScript,
> can be used to create viruses.  It was possible in Lotus 1-2-3's
> macro language as well.

  Most macro/scripting languages do not provide unrestricted access to
the local filesystem, network, and all loaded libraries.  You can make a
very powerful scripting language that's still safe to run.

  JavaScript, for instance, has had occasional security vulnerabilities
which are rapidly patched, but overall it was designed the right way.
You can at worst annoy the user; you can't make a self-replicating gray
goo virus with it.

>>  It filled the niche
>> that Hypercard did on the Mac, but with Microsoft's usual standard of
>> ease of use and quality instead of Apple's.  Its popularity among
>> Windoze users is completely unsurprising.
>> [0] Really, more of a "good languages bigot".  I'm perfectly happy with
>> Python, PHP, OCaml, and several other languages.  With time and some
>> practical examples of its use, D may well join that list.
>> [1] "It is practically impossible to teach good programming to students
>> that have had a prior exposure to BASIC: as potential programmers they
>> are mentally mutilated beyond hope of regeneration."
>> -Prof. Dr. Edsger W. Dijkstra
>> I don't fully agree with the good professor.  I do believe it's possible
>> to recover from bad programming languages.  I certainly hope so, since I
>> was raised on BASIC, before learning better.
> Do you actually know anything about VB at all, or do you really
> believe Basic as a language hasn't progressed in absolutely any
> way whatsoever since 1974, when Dijkstra said that?

  It has certainly changed, but I would not say it has improved
significantly.  As an instructional tool for how computers work and a
lead-in to real languages, it's actually become worse, and that took
effort.  As a tool for casually producing bad or destructive code, it's
much more efficient.  Not an accomplishment I'd be proud of.

>  Do you also
> agree with Dijkstra about object orientation?
> "Object-oriented programming is an exceptionally bad idea that
> could only have been invented in California."
> http://quote.wikipedia.org/wiki/Edsger_Dijkstra

  Given the early OOP systems he saw, certainly.  Older OOP languages
sucked, and were more liability than help.  Things have improved a bit
since then, so OOP is now a useful technology.  EWD often expressed his
opinions as extremes based on the worst-case examples (GOTO being the
canonical example), but he was rarely (never?) wrong about them.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

David Turner <david@firepro.co.za>
wrote on Fri, 13 Feb 2004 09:21:27 +0200:
> Hello
>> > it.  In C++ I would write a destructor for the connection class, and
>>   But then you have to manage the memory yourself anyway, so you've
>> gained nothing in efficiency and lost everything in safety.  I'll take
>> the try...finally code and GC of Java over the manual memory management
>> and memory corruption of C++ every single day.
> I'm sorry, but... balls.  You clearly haven't grasped the significance of
> the sample code that has now been posted several times.

  I've grasped it, I just consider it inferior to having a real
try...catch...finally block.  You don't seem to be capable of
understanding that someone might grasp your argument and still find it
unconvincing.  Welcome to reality, David.

> The Foo object is *guaranteed* to be cleaned up, regardless of what happens.

  Sure.  This is not true if you allocate it on the heap, which is much
more likely to be done in useful code.

  The Java version is also *GUARANTEED* to be cleaned up, regardless of
what happens.

  What you're obsessing over is equivalent to being upset that Java uses
.. instead of -> as the method/field operator.

> I seriously recommend you follow this link, kindly provided by Joe Foster:
> http://www.research.att.com/~bs/bs_faq2.html#finally

  I did.  It's a difference of theory at best, and disingenuous at
worst.  This is hardly surprising, since I find most of Bjarne's
arguments about good language design...  less than convincing.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

"David Turner" <david@firepro.co.za> wrote in message <news:1076658416.917252@tanzanite.firepro.co.za>...

> The Foo object is *guaranteed* to be cleaned up, regardless of what happens.
> I seriously recommend you follow this link, kindly provided by Joe Foster:
>
> http://www.research.att.com/~bs/bs_faq2.html#finally

Unfortunately, Mark 'Kamikaze' Hughes was apparently talking about
himself when he mentioned using a weak grasp of the facts in order
to flog a particular agenda.  He's just another raving Java bigot.

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message <news:slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>...

> Joe \"Nuke Me Xemu\" Foster <joe@bftsi0.UUCP>
> wrote on Thu, 12 Feb 2004 17:20:54 -0800:
> > "Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message
<news:slrnc2o772.2jnr.kamikaze@kuoi.asui.uidaho.edu>...

> >> [1] "It is practically impossible to teach good programming to students
> >> that have had a prior exposure to BASIC: as potential programmers they
> >> are mentally mutilated beyond hope of regeneration."
> >> -Prof. Dr. Edsger W. Dijkstra
> >> I don't fully agree with the good professor.  I do believe it's possible
> >> to recover from bad programming languages.  I certainly hope so, since I
> >> was raised on BASIC, before learning better.
> > Do you actually know anything about VB at all, or do you really
> > believe Basic as a language hasn't progressed in absolutely any
> > way whatsoever since 1974, when Dijkstra said that?
>
>   It has certainly changed, but I would not say it has improved
> significantly.  As an instructional tool for how computers work and a
> lead-in to real languages, it's actually become worse, and that took
> effort.  As a tool for casually producing bad or destructive code, it's
> much more efficient.  Not an accomplishment I'd be proud of.

Aha!  You're one of those wing-nuts who believes that because it's
possible for a complete ass-hat to write bad code in Visual Basic,
Visual Basic must therefore be suitable only for ass-hats to write
crap code.  I'd also guess that if you've ever deigned to actually
try using VB, it was only for at most fifteen minutes back in '96
or thereabouts.  When VB4 failed to reach out and give you a hand-
job, you fled screaming in terror back to Java, the �ber-language,
am I right?  Perhaps you and EGN should go get a room somewhere.

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

> > I'm sorry, but... balls.  You clearly haven't grasped the significance of
> > the sample code that has now been posted several times.
> 
>   I've grasped it, I just consider it inferior to having a real
> try...catch...finally block.  You don't seem to be capable of
> understanding that someone might grasp your argument and still find it
> unconvincing.  Welcome to reality, David.
> 
> > The Foo object is *guaranteed* to be cleaned up, regardless of what happens.
> 
>   Sure.  This is not true if you allocate it on the heap, which is much
> more likely to be done in useful code.

It IS on the heap.  I told you you didn't get it.  We have two objects
here: the Foo object on the heap, and the auto_ptr<Foo> object that
manages its lifetime.  Want an object on the heap with shared
ownership semantics?  No problem: manage it with a boost::shared_ptr. 
Want a weak reference?  boost::weak_ptr.

The beauty of this is that the compiler can eliminate virtually all of
the overhead.  The net result is just about as efficient as if you had
done the memory management yourself, in C.  Except that you didn't
have to do it.

What's more, your vaunted try/catch/finally block has been made
virtually redundant.  The only instance where it's necessary to use it
is where you actually want to catch an exception (rather than pass it
on).  "Finally" does not exist in C++.



>   What you're obsessing over is equivalent to being upset that Java uses
> . instead of -> as the method/field operator.

And you had the gall to accuse me of having a shaky understanding?


Regards
David Turner

mschaef@io.com (MSCHAEF.COM) wrote in message news:<oaydnbvWtcXBY7Hd4p2dnA@io.com>...
> In article <1076656599.165542@tanzanite.firepro.co.za>,
> David Turner <david@firepro.co.za> wrote:
> >Hi
> >
> >[snip]
> >> The best example of this is something called a lexical closure, basically
> >> a function bound to its run-time lexical environment.  Let me illustrate:
> >>
> >> (define (make-adder k)
> >>   (lambda (x) (+ k x)))
> >[snip]
> >
> >Just a point of interest - have you seen the boost lambda library?
> 
> I've seen it, along with some other parts of boost, but I haven't used it 
> myself. From what I can tell, it's a truly remarkable piece of work, given
> that the underlying language doesn't really offer any native support for 
> anonymous functions. 
> 
> It's also worth pointing out that boost lambdas enforce some pretty severe
> constraints on programers. Referring to parameters by an ordinal number is
> more than a little crude, as is the fact that (from what I can tell, this
> might be fixable with inlining)  boost lambdas can't be compiled as
> efficiently as a "normal" function.

Yeah, I agree that C++ "lambdas" don't have a patch on Lisp lambdas,
but I thought it was pretty neat :-).  As for efficiency, from what I
can tell it's not too bad.  That's one of the strengths of C++
compilers.  Lots of objects get optimized away.


> Until about a year ago, I had pretty much disconnected myself from the C++ 
> community since 1996-7 (when I was using it regularly in school). There 
> are a lot of amazing things going on with C++ these days.

Well, I think that the C++ community is actually starting to explore
the boundaries of software design, which is a Very Good Thing.  As
some have noted, not much has changed since the 70's.  But I think the
RAII idiom is the beginning of a truly remarkable idea.  I haven't
quite elucidated it in my own mind, but basically it should be
possible to build requirements and constraints into the framework.  In
other words, create a domain-specific sublanguage such that the
requirements can't be violated.

Lisp, of course, has been able to do this sort of thing for a while,
but I don't know if it's ever been investigated in a formal manner? 
What I *do* know is that since becoming aware of these ideas, my own
error rate (in C++) has gone virtually to zero.  No bugs in three
months - everything has just worked, first time I compiled it.

Regards
David Turner

Joe \"Nuke Me Xemu\" Foster <joe@bftsi0.UUCP>
wrote on Fri, 13 Feb 2004 16:18:03 -0800:
> "Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message <news:slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>...
>>   It has certainly changed, but I would not say it has improved
>> significantly.  As an instructional tool for how computers work and a
>> lead-in to real languages, it's actually become worse, and that took
>> effort.  As a tool for casually producing bad or destructive code, it's
>> much more efficient.  Not an accomplishment I'd be proud of.
> Aha!  You're one of those wing-nuts who believes that because it's
> possible for a complete ass-hat to write bad code in Visual Basic,
> Visual Basic must therefore be suitable only for ass-hats to write
> crap code.  I'd also guess that if you've ever deigned to actually
> try using VB, it was only for at most fifteen minutes back in '96
> or thereabouts.  When VB4 failed to reach out and give you a hand-
> job, you fled screaming in terror back to Java, the �ber-language,
> am I right?  Perhaps you and EGN should go get a room somewhere.

  I regularly use many languages, and constantly try new ones.
Currently I work with Java, PHP, Perl, and Python, and occasionally use
OCaml for fun.  In the past, I've written professional code with
FORTRAN, C, Objective C, C++ (very unhappily), Pascal, Lisp, and
Smalltalk, at least; I'm probably forgetting some.  Java's hardly an
uber-language, but it's the most reliable and powerful language
currently available for large software engineering projects.  That's why
it's used for the majority of enterprise development now.

  OTOH, Visual Basic is completely inadequate for real programming.
It's a toy for making clicky forms and scripting Office apps, that's all
it's ever been good for, and all it will ever be good for.  I've never
understood why people even bother, though, since MS breaks the language
in incompatible ways every year or two.

  I know you resent the fact that your favorite toy language has not
conquered the world, while a language you weren't capable of learning to
use correctly did, but taking it out on me is stupid.  You have only
yourself to blame.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

In article <slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
>
>>  Do you also
>> agree with Dijkstra about object orientation?
>> "Object-oriented programming is an exceptionally bad idea that
>> could only have been invented in California."
>> http://quote.wikipedia.org/wiki/Edsger_Dijkstra
>
>  Given the early OOP systems he saw, certainly.  Older OOP languages
>sucked, and were more liability than help.  Things have improved a bit
>since then, so OOP is now a useful technology.  EWD often expressed his
>opinions as extremes based on the worst-case examples (GOTO being the
>canonical example), but he was rarely (never?) wrong about them.

Dijkstra seems incredibly overrated.  As far as I can see he is famous 
for (a) a trivial pathfinding algorithm that must have been re-invented 
hundreds of times, and (b) a bunch of stupidly aggressive and 
wrong-headed comments, such as the above about OO, and the stupidity 
about Basic (which I interpret as meaning he was a crap teacher too).

No doubt he did useful stuff I haven't heard of, but his record as 
typically referred to on usenet is quite pitiful.

- Gerry Quinn

"Gerry Quinn" <gerryq@indigo.ie> wrote in message news:m8oXb.2759$rb.57985@news.indigo.ie...
> In article <slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
> >
> >>  Do you also
> >> agree with Dijkstra about object orientation?
> >> "Object-oriented programming is an exceptionally bad idea that
> >> could only have been invented in California."
> >> http://quote.wikipedia.org/wiki/Edsger_Dijkstra
> >
> >  Given the early OOP systems he saw, certainly.  Older OOP languages
> >sucked, and were more liability than help.  Things have improved a bit
> >since then, so OOP is now a useful technology.  EWD often expressed his
> >opinions as extremes based on the worst-case examples (GOTO being the
> >canonical example), but he was rarely (never?) wrong about them.
> 
> Dijkstra seems incredibly overrated.  As far as I can see he is famous 
> for (a) a trivial pathfinding algorithm that must have been re-invented 
> hundreds of times, and (b) a bunch of stupidly aggressive and 
> wrong-headed comments, such as the above about OO, and the stupidity 
> about Basic (which I interpret as meaning he was a crap teacher too).
> 
> No doubt he did useful stuff I haven't heard of, but his record as 
> typically referred to on usenet is quite pitiful.

When I was a youngster I've met Dijkstra on several occasions when
he lectured. He was, should I say, quite a 'personality' besides 
being a very intelligent mathematician. Here's a short list of some
of his publications -- http://www.cbi.umn.edu/collections/inv/burros/ewddocs.htm
Some of those subjects and titles are hilarious, but always interesting stuff,
the reflections of his 'personality' and intelligence.

BTW, you should try to get your hands on all his EWD-notes; entertaining,
interesting and very passionate stuff indeed.

kind regards,

Jos

mschaef@io.com (MSCHAEF.COM) wrote in message news:<lPOdndgdi4zhm7Dd4p2dnA@io.com>...
[snip]
> As I'm sure you know, something that's a common idiom in C, when using
> callbacks, is a user-pointer that's passed in when the callback is
> registered and passed to the callback function when it's called. Closured
> make these obsolete.  Rather than passing in a callback function and a
> pointer, you pass in a closure, which brings with it its lexical
> environment. What most likely in C is code that:

....etc.  In support of your argument, I thought I'd provide this
further illustration of the usefulness of function objects.  It's from
Python:

#-------------------------------------------------
def binder(obj, fn):
    return lambda *args: fn(obj, *args)
    
def bindMethods(object):
    result = { }
    for x, y in object.__class__.__dict__.items():
        if(inspect.isfunction(y)):
            result[x] = binder(object, y)
    return result

class MyGui:
    def __init__(self):
        self.wtree = gtk.glade.XML('MyGui.glade')
        self.wtree.signal_autoconnect(bindMethods(self))
#-------------------------------------------------

I've found this little construct quite useful, as it essentially means
I can just write functions into my Gui class that match the names of
the GTK signals I declare in Glade, and not have to worry about
binding things up.  Makes writing GUI applications a breeze.  Almost
as easy as Visual Basic ;-).



> Here's another example, along these lines:
> 
>    (define (remove pred lis)
>       (filter (lambda (x) (not (pred x))) lis))  
>    
>    (define (delete x lis) 
>       (filter (lambda (y) (not (equal? x y))) lis))
> 
> These functions pass anonymous functions into the function filter to
> filter list elements based on predicates. Both of the lambda functions
> depend on variables bound at the invocation time of the outer function.
> 
> That's in 2 lines of code each...
> 
> Let's see about C++ (any mistakes are unintentional, I'm just typing this out):
[about 20 lines snipped]

Dear me and tsk tsk.  What was wrong with the following?

remove_if(list.begin(), list.end(),
  not1(
    bind1st(
      mem_fun(&IObjectPredicate::satisfies),
      predicateObject
    )
  )
);

If anything, I think the C++ version is easier to comprehend than the
Lisp version ;-).  To be fair, though, there is a larger body of
knowledge to master.

An explanation for anyone who's puzzled:  mem_fun is a template
function that converts a member function pointer into a function
object that takes an explicit "this" parameter.  The bind1st function
binds the predicateObject variable to that function object's first
parameter, leaving us with a unary function object.  The not1 function
wraps that in something like lambda x: not x.

Regards
David Turner

In article <592f3326.0402140838.24d4863c@posting.google.com>,
David Turner <david@firepro.co.za> wrote:
   ...
>>    (define (remove pred lis)
>>       (filter (lambda (x) (not (pred x))) lis))  
>
>Dear me and tsk tsk.  What was wrong with the following?

I was kind of hoping that someone would post a nice example with 
templates. I'm behind the curve enough on C++ that it doesn't suprise
me at all that STL has better support that what I posted. (I think it's
worth pointing out that I think that my C++ code is closer to a "state
of the art" idiom for languages like C# and Java, at least until C# gets 
its own anonymous function support.)

>remove_if(list.begin(), list.end(),
>  not1(
>    bind1st(
>      mem_fun(&IObjectPredicate::satisfies),
>      predicateObject
>    )
>  )
>);

>If anything, I think the C++ version is easier to comprehend than the
>Lisp version ;-). 

I think that's a matter of perspective. Coming from more Lispy background, 
I'd make the opposite statement. Without direct experience with the idiom
you've posted, there are several issues that more specificaly concern me:

* With not1 and bind1st, you're limited to referencing arguments, by 
  ordinal, aren't you? I'd consider that a disadvantage compared to the
  by name references available in Lisp/Scheme.

* You still have this explicit "IObjectPredicate" concept, which seems
  very heavyweight compared to an anonymous function and its lexical 
  bindings.  Even if you can pass in a non-member function and bypass the 
  whole idea of a predicate object, you're still reduced to defining your 
  predicate functions out of line compared to where they're used. I guess 
  you can use boost lambdas, but again you're limited to referring to 
  parameters by ordinal, which has never, as far as I can remember, been 
  considered best (or even good) practice in higher level language 
  design.

* A lot of this logic is done using templates and I question how easy 
  templates are to debug. At least in Visual C++ 7, the diagnostics
  offered by the compiler on a template error seem fairly limited.
  (This is also a problem I have with template metaprogramming. I've
  seen some pretty amazing things done with templates, but compared
  to Lisp languages where you get to use the whole native language 
  while metaprogramming, C++ limits you to a radically limited language
  with limited support for debugging.)

>To be fair, though, there is a larger body of knowledge to master.

I agree that C++ has a larger body of knowledge. Maybe the way I'd phrase 
it is, "C++ has more fundamental rules to learn than Lisp". I just don't 
think that the added complexity has much of a payoff in terms of power
or safety. 

The other thing that's worth pointing out is that my style has always 
tended towards skipping straight from C to higher level language like 
Scheme and Lisp (and long ago, Tcl). I've never fully bought into C++'s 
value propositon, and it's always biased my opinions on these issues in 
"non-mainstream" ways.

-Mike
-- 
http://www.mschaef.com

In article <592f3326.0402140005.62660b33@posting.google.com>,
David Turner <david@firepro.co.za> wrote:
  ...
>Yeah, I agree that C++ "lambdas" don't have a patch on Lisp lambdas,
>but I thought it was pretty neat :-). 

Me too. I don't remember if I mentioned it in my other post, but I also 
really like the ideas behind the boost parser library.  I think that 
Stroustrup, Stepanov and Lee, (sp? on the first two names) and the 
ANSI C++ standards body have done an excellent job of keeping the spirit 
of C and yet providing good tools for creating new abstractions.

The thing I've never fully gotten about C++ is the rationale for its
scope. By this I mean that I see a lot of benefit in having a language
that can support these more powerful abstractions in a first-class manner
and then having a solid escape route to a language like C. This seems more
managable than expanding C to try to encompass all these features while
retaining the low-level capabilities of the original.

Keep in mind that this is coming from the perspective of someone who has
never done something like large-scale (>1MLOC, let's say) system level
programming.  It's pretty easy for me to admit that I might not ever have
been in the target audience the full language.

>What I *do* know is that since becoming aware of these ideas, my
>own error rate (in C++) has gone virtually to zero.  No bugs in three
>months - everything has just worked, first time I compiled it. 

I can't claim that entirely bug-free level of success, but I've had a lot 
of success with a hybrid Scheme/C (and a little C++) approach. I've built 
a system around a highly modified version of George Carette's SIOD 
interpreter. The vast majority of my work in C is developing new types of 
objects to manipulate in Scheme code.  When these objects are freed by the 
garbage collector, they know to explicitly free their malloc allocated 
storage. This, combined with some smart macros on the Scheme side, has 
made memory management trivially easy. Thanks to the type-bits on each 
scheme object pointer, there's also a lot of internal consistancy 
checking that catches errors too.

I think you're absolutely right about the key being having tools that can 
help enforce constraints automatically.

-Mike
-- 
http://www.mschaef.com

In article <slrnc2rsn0.l07.kamikaze@kuoi.asui.uidaho.edu>,
Mark 'Kamikaze' Hughes <kamikaze@kuoi.asui.uidaho.edu> wrote:
  ...
>In the past, I've written professional code with ... Objective C

Was this on NeXTStep/Cocoa?

I'd be curious to hear your thoughts on the language. From my (very 
limited) experience with Objective C on Cocoa, I was impressed by
the flexibility of the object model.

-Mike
-- 
http://www.mschaef.com

In article <402e192c$0$93698$cd19a363@news.wanadoo.nl>,
Jos A. Horsmeier <j.a.horsmeier@wanadoo.nl> wrote:
  ...
>BTW, you should try to get your hands on all his EWD-notes; entertaining,
>interesting and very passionate stuff indeed.

That's easier than you might think:

http://www.cs.utexas.edu/users/EWD/

UT (my alma mater, and where Dijkstra closed out his career) has set up a 
nice archive of a lot of his work. It's very interesting reading, Some of 
his comments about IBM (IIRC) in the 60's are very reminiscent of comments 
made about Microsoft today.

-Mike
-- 
http://www.mschaef.com

"Mark 'Kamikaze' Hughes" <kamikaze@kuoi.asui.uidaho.edu> wrote in message <news:slrnc2rsn0.l07.kamikaze@kuoi.asui.uidaho.edu>...

> Smalltalk, at least; I'm probably forgetting some.  Java's hardly an
> uber-language, but it's the most reliable and powerful language
> currently available for large software engineering projects.  That's why
> it's used for the majority of enterprise development now.

Sure, now that Micro$haft has broken Visual Basic completely and
the Gnome Basic folks have guzzled the grape Koolaid.NET.  >=(

>   OTOH, Visual Basic is completely inadequate for real programming.
> It's a toy for making clicky forms and scripting Office apps, that's all
> it's ever been good for, and all it will ever be good for.

Do you have *specific* objections to VB, or are you just ranting
and raving out of obvious ignorance?  Perhaps you claim it isn't
Turing-complete or that any language relying on RAII instead of
on the "finally" �ber-construct like Java the �ber-language does
thus must needs therefore be totally, irredeemably broken due to
its inadequate B&D straitjacket?  Perhaps it's the awful way VB
allows developers to /avoid/ breaking encapsulation because the
overuse of inclusion polymorphism and methods aren't shoved down
their throats?  Perhaps having object destructors that actually
*work* is Evil, Bad, and Wrong?  Perhaps COM support is the big
bad boogeyman hiding in the closet.  Or is it the IDE?  Do tell!

>  I've never
> understood why people even bother, though, since MS breaks the language
> in incompatible ways every year or two.

In what ways, *specifically*, has VB been broken every year or two
since the debut of VB 5.0 in 1997?

--
Joe Foster <mailto:jlfoster%40znet.com>   L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"MSCHAEF.COM" <mschaef@io.com> wrote in message <news:Faydnc9JIt4terbdRVn-jQ@io.com>...

> The best example of this is something called a lexical closure, basically
> a function bound to its run-time lexical environment.  Let me illustrate:
>
> (define (make-adder k)
>   (lambda (x) (+ k x)))
>
> This function, written in Scheme, returns a closure. The second line of
> the function is itself a definition of a function that is returned by
> make-adder. You'll notice that the embedded function refers to a variable
> k, that is defined in the parameter list of the outer function. In a
> stack-based allocation method like that espoused by propoents of RAII, the
> storage for the value of k would be freed when make-adder returned.
> However, allocate the variable binding on the garbage collected heap, and
> the GC algorithm will notice that there are two references to k: one by
> make-adder and one by the inner function. As a consequence it'll retain
> the binding to k as long as the inner function sticks around.
>
> As much a fan of C as I am, this flexibility can be awfully nice...

VB (just to stick it to 'Kamikaze') can simulate lexical closures
and anonymous functions using its reference-counted objects, but
unfortunately not in just two lines:

----Class Adder----
Private K As Double

Friend Sub Init(ByVal NewK As Double)
  K = NewK
End Sub

' The "Attribute" makes Evaluate the "default" for this class
Public Function Evaluate(ByVal X As Double) As Double
Attribute Evaluate.VB_UserMemId = 0
  Evaluate = X + K
End Function
----

Public Function MakeAdder(ByVal K As Double) As Adder
  Set MakeAdder = New Adder
  MakeAdder.Init K
End Function

Sub TestAdder()
  Dim Temp As Adder
  Set Temp = MakeAdder(12)
  Debug.Print Temp(9) ' equivalent to Temp.Evaluate(9)
End Sub

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Joe "Nuke Me Xemu" Foster wrote:

> Do you have *specific* objections to VB, or are you just ranting
> and raving out of obvious ignorance?

No bit shifting operators.
Non short-circuting logical operators (and, or).
The IDE has always pissed me off also.

-- 
"I'm a war president.  I make decisions here in the Oval Office
  in foreign policy matters with war on my mind." - Bush

"Noah Roberts" <nroberts@dontemailme.com> wrote in message <news:afudnbd_YochDLPdRVn-vg@scnresearch.com>...

> Joe "Nuke Me Xemu" Foster wrote:
>
> > Do you have *specific* objections to VB, or are you just ranting
> > and raving out of obvious ignorance?
>
> No bit shifting operators.
> Non short-circuting logical operators (and, or).
> The IDE has always pissed me off also.

However, are these truly the difference between 'real' and 'toy' languages?
Bit shifting is easy enough to simulate using multiplication and division,
short circuiting is easy enough to simulate using If/ElseIf, and the IDE
can be tweaked using add-ins or even bypassed altogether, since VB's source
code files are plain text, with embedded images and the like quarantined in
separate *.??X files.  To me, the most persuasive argument that VB is a toy
language can be made by Micro$haft's support commitment or lack thereof...

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Joe "Nuke Me Xemu" Foster wrote:
> "Noah Roberts" <nroberts@dontemailme.com> wrote in message <news:afudnbd_YochDLPdRVn-vg@scnresearch.com>...
> 
> 
>>Joe "Nuke Me Xemu" Foster wrote:
>>
>>
>>>Do you have *specific* objections to VB, or are you just ranting
>>>and raving out of obvious ignorance?
>>
>>No bit shifting operators.
>>Non short-circuting logical operators (and, or).
>>The IDE has always pissed me off also.
> 
> 
> However, are these truly the difference between 'real' and 'toy' languages?

I would say they are important.  The thing that gets me about BASIC is 
that it was never meant to be used the way it is now.  It was originally 
a language to teach programming, it was never supposed to be used to 
build complex systems.  Therefor there are several important things 
missing from the language that in my opinion, and others, makes it a toy 
language.

> Bit shifting is easy enough to simulate using multiplication and division,

expensive.

> short circuiting is easy enough to simulate using If/ElseIf,

Well it isn't always as straight forward in the end.  Consider this code:

while (x < max && arr[x] != someval)
....
wend.

This has to be changed into something like the following:

bool keepLooping = true;
while (keepLooping)
  if (x >= max) keepLooping = false;
  else if (arr[x] == someval) keepLooping=false;
  else
    ...
  fi
wend.

or
while (x < max)
   if (arr[x] == someval) break;
  ...
wend.

Obviously it is a personal preference, but I prefer the first option.
  and the IDE
> can be tweaked using add-ins or even bypassed altogether, since VB's source
> code files are plain text, with embedded images and the like quarantined in
> separate *.??X files.

Yes, you can loose the IDE but I have never seen one that has and I 
wouldn't know how to compile the result without it.  But I suppose that 
is my issue.

-- 
"I'm a war president.  I make decisions here in the Oval Office
  in foreign policy matters with war on my mind." - Bush

"Noah Roberts" <nroberts@dontemailme.com> wrote in message <news:456dnTnfmqLpBLPdRVn-uQ@scnresearch.com>...

> Joe "Nuke Me Xemu" Foster wrote:
> > "Noah Roberts" <nroberts@dontemailme.com> wrote in message <news:afudnbd_YochDLPdRVn-vg@scnresearch.com>...
> >
> >
> >>Joe "Nuke Me Xemu" Foster wrote:
> >>
> >>
> >>>Do you have *specific* objections to VB, or are you just ranting
> >>>and raving out of obvious ignorance?
> >>
> >>No bit shifting operators.
> >>Non short-circuting logical operators (and, or).
> >>The IDE has always pissed me off also.
> >
> >
> > However, are these truly the difference between 'real' and 'toy' languages?
>
> I would say they are important.  The thing that gets me about BASIC is
> that it was never meant to be used the way it is now.  It was originally
> a language to teach programming, it was never supposed to be used to
> build complex systems.  Therefor there are several important things
> missing from the language that in my opinion, and others, makes it a toy
> language.

Languages can evolve over time.  Look at how C started as a "portable
assembler", yet C and C-derived languages are now used for just about
everything.  Pascal also started out as a teaching language, and look
at how that mutated over time into Turbo Pascal, Delphi, and Kylix.

> > Bit shifting is easy enough to simulate using multiplication and division,
>
> expensive.

Depends on the compiler and the CPU architecture.  Nothing prevents a
peephole optimizer from converting multiplication and division by a
power of two to bit-shifting.  Similarly, nothing prevents Intel from
leaving out the barrel-shifter, making bit shifting horribly slow, the
bastards...

> > short circuiting is easy enough to simulate using If/ElseIf,
>
> Well it isn't always as straight forward in the end.  Consider this code:
>
> while (x < max && arr[x] != someval)
> ...
> wend.
>
> This has to be changed into something like the following:
>
> bool keepLooping = true;
> while (keepLooping)
>   if (x >= max) keepLooping = false;
>   else if (arr[x] == someval) keepLooping=false;
>   else
>     ...
>   fi
> wend.
>
> or
> while (x < max)
>    if (arr[x] == someval) break;
>   ...
> wend.

VB can also leave *all* tests inside the loop:

do
  if x >= max then exit do
  if arr(x) = someval then exit do
  ...
loop

Actually, some versions of Microslop Basic did have short-circuiting.
Even using the usual bitwise semantics, if the LHS of an And is False,
you don't need to evaluate the RHS at all.  Granted, the extra tests
and branches in the compiled code would play merry hell with modern
pipelined CPUs...

> Obviously it is a personal preference, but I prefer the first option.
>   and the IDE
> > can be tweaked using add-ins or even bypassed altogether, since VB's source
> > code files are plain text, with embedded images and the like quarantined in
> > separate *.??X files.
>
> Yes, you can loose the IDE but I have never seen one that has and I
> wouldn't know how to compile the result without it.  But I suppose that
> is my issue.

I have edited VB source code with a plain old text editor at times.
The VB compiler/IDE also recognizes a number of command-line switches,
some of which may be used to compile a project without starting the
IDE, just what the doctor ordered for doing automated builds.

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

MSCHAEF.COM <mschaef@io.com>
wrote on Sat, 14 Feb 2004 13:17:59 -0600:
> In article <slrnc2rsn0.l07.kamikaze@kuoi.asui.uidaho.edu>,
> Mark 'Kamikaze' Hughes <kamikaze@kuoi.asui.uidaho.edu> wrote:
>   ...
>>In the past, I've written professional code with ... Objective C
> Was this on NeXTStep/Cocoa?
> I'd be curious to hear your thoughts on the language. From my (very 
> limited) experience with Objective C on Cocoa, I was impressed by
> the flexibility of the object model.

  I did ObjC on OS/2.  I was a poor college student when NeXT was hot,
and I haven't had a chance to work on MacOS X yet.  I do plan to get a
MacOS X laptop next month or so, but I'll almost certainly keep
programming in Java, possibly playing with the native enhancements.

  ObjC was a very powerful and pleasant OOP language for its time, but
it has some annoyances.  The syntax is nightmarish; you have the usual
ugly C syntax and the incredibly ugly Smalltalk syntax, mixed together
into an ugly soup.  My eyes bleed when I read the stuff.  The semantics
are fine, it's just the look of the language that's hideous.  Managing
memory and other resources in it is easier than C, but less convenient
than Smalltalk (let alone Java, Python, etc.).

  It's not very fast, especially if you put most of your code in the
Smalltalk layer, but that's a lot less important now than it was 10
years ago.  It's vastly better than C and C++ for developing reliable
and powerful applications, though.  If you're doing Mac-only apps, it's
the way to go.  If you want cross-platform, Apple supports Java very
well, and Java apps can look and feel completely native now.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

Gerry Quinn <gerryq@indigo.ie>
wrote on Sat, 14 Feb 2004 12:08:01 GMT:
> In article <slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
>>EWD often expressed his
>>opinions as extremes based on the worst-case examples (GOTO being the
>>canonical example), but he was rarely (never?) wrong about them.
> Dijkstra seems incredibly overrated.  As far as I can see he is famous 
> for (a) a trivial pathfinding algorithm that must have been re-invented 
> hundreds of times, and (b) a bunch of stupidly aggressive and 
> wrong-headed comments, such as the above about OO, and the stupidity 
> about Basic (which I interpret as meaning he was a crap teacher too).
> No doubt he did useful stuff I haven't heard of, but his record as 
> typically referred to on usenet is quite pitiful.

  Some people have a problem with EWD because he would tell the truth in
a way that was guaranteed to piss people off, and he apparently enjoyed
that.  But if you can come up with something he said that's actually
*wrong*, rather than just extreme and uncomfortably close to your home,
please share it with the rest of us.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

"Gerry Quinn" <gerryq@indigo.ie> wrote in message <news:m8oXb.2759$rb.57985@news.indigo.ie>...

> Dijkstra seems incredibly overrated.  As far as I can see he is famous
> for (a) a trivial pathfinding algorithm that must have been re-invented
> hundreds of times, and (b) a bunch of stupidly aggressive and
> wrong-headed comments, such as the above about OO, and the stupidity
> about Basic (which I interpret as meaning he was a crap teacher too).

Actually, he was talking about old-school unstructured line-numbered
BASIC.  Modern Basic, despite 'Kamikaze's laughably ignorant ranting,
is a far cry from the language Dijkstra was denouncing in the 1970's.

> No doubt he did useful stuff I haven't heard of, but his record as
> typically referred to on usenet is quite pitiful.

Being quoted out of context by cretins can make anybody look pitiful.

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"MSCHAEF.COM" <mschaef@io.com> wrote in message news:Re-dnV5QD-686LPdRVn-ig@io.com...
> In article <402e192c$0$93698$cd19a363@news.wanadoo.nl>,
> Jos A. Horsmeier <j.a.horsmeier@wanadoo.nl> wrote:
>   ...
> >BTW, you should try to get your hands on all his EWD-notes; entertaining,
> >interesting and very passionate stuff indeed.
> 
> That's easier than you might think:
> 
> http://www.cs.utexas.edu/users/EWD/
> 
> UT (my alma mater, and where Dijkstra closed out his career) has set up a 
> nice archive of a lot of his work. It's very interesting reading, Some of 
> his comments about IBM (IIRC) in the 60's are very reminiscent of comments 
> made about Microsoft today.

That link is a very worthy tribute indeed.

kind regards,

Jos

In article <slrnc2tajk.l07.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
>Gerry Quinn <gerryq@indigo.ie>
>wrote on Sat, 14 Feb 2004 12:08:01 GMT:
>> In article <slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>,
> kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
>>>EWD often expressed his
>>>opinions as extremes based on the worst-case examples (GOTO being the
>>>canonical example), but he was rarely (never?) wrong about them.
>> Dijkstra seems incredibly overrated.  As far as I can see he is famous 
>> for (a) a trivial pathfinding algorithm that must have been re-invented 
>> hundreds of times, and (b) a bunch of stupidly aggressive and 
>> wrong-headed comments, such as the above about OO, and the stupidity 
>> about Basic (which I interpret as meaning he was a crap teacher too).
>> No doubt he did useful stuff I haven't heard of, but his record as 
>> typically referred to on usenet is quite pitiful.
>
>  Some people have a problem with EWD because he would tell the truth in
>a way that was guaranteed to piss people off, and he apparently enjoyed
>that.  But if you can come up with something he said that's actually
>*wrong*, rather than just extreme and uncomfortably close to your home,
>please share it with the rest of us.

The notions that learning Basic renders students unteachable, or that 
object orientation is a stupid idea, have already been profferred as 
examples of things he said that are wrong.  So wrong, indeed, as to 
merit not just two asterisks, but perhaps as many as six. 

I note he even went so far as to write an article (substantially content 
free) about how he tells truths that are calculated to piss people off.  
In such ways does he show symptoms of intoxication due to the attentions 
of sycophants.  

- Gerry Quinn

mschaef@io.com (MSCHAEF.COM) wrote in message news:<p_-dnQ8W5Pnk8rPdRVn-jw@io.com>...
> I'd make the opposite statement. Without direct experience with the idiom
> you've posted, there are several issues that more specificaly concern me:
> 
> * With not1 and bind1st, you're limited to referencing arguments, by 
>   ordinal, aren't you? I'd consider that a disadvantage compared to the
>   by name references available in Lisp/Scheme.

Yes.  It's a disadvantage.

> 
> * You still have this explicit "IObjectPredicate" concept, which seems
>   very heavyweight compared to an anonymous function and its lexical 
>   bindings.  Even if you can pass in a non-member function and bypass the 
>   whole idea of a predicate object, you're still reduced to defining your 
>   predicate functions out of line compared to where they're used. I guess 
>   you can use boost lambdas, but again you're limited to referring to 
>   parameters by ordinal, which has never, as far as I can remember, been 
>   considered best (or even good) practice in higher level language 
>   design.

I think this is less of a problem in practice than it might appear to
be.  The reason is that most of the "trivial" predicates that I would
be inclined to write as anonymous functions can be constructed out of
various standard templates like not1 (possibly augmented with a
personal library of useful transforms).  Less-than-trivial predicates
or operations deserve to be maintained separately (much in the same
way as non-trivial functions deserve to be written out-of-line).  In
this way the flow logic isn't obscured by detail, so that I end up
writing things like:

vector< vector<Cell> > columns;
vector<int> widths, heights;
for_each(columns.begin(), columns.end(), calculateGridSizes(widths,
heights));

where calculateGridSizes is actually a function object that
recursively applies itself to each individual column.  So the lexical
context (in this case, widths and heights) are actually stored
explicitly as [reference] members.  This has its advantages and
disadvantages.


> * A lot of this logic is done using templates and I question how easy 
>   templates are to debug. At least in Visual C++ 7, the diagnostics
>   offered by the compiler on a template error seem fairly limited.
>   (This is also a problem I have with template metaprogramming. I've
>   seen some pretty amazing things done with templates, but compared
>   to Lisp languages where you get to use the whole native language 
>   while metaprogramming, C++ limits you to a radically limited language
>   with limited support for debugging.)

Yes, the compiler diagnostics where templates are involved fall far
short of most people's expectations.  I think this is the most serious
problem with the state of the C++ art.  Usually I don't actually read
the error message, just trace back through the instantiation stack
looking for potential problems :-/.

> 
> >To be fair, though, there is a larger body of knowledge to master.
> 
> I agree that C++ has a larger body of knowledge. Maybe the way I'd phrase 
> it is, "C++ has more fundamental rules to learn than Lisp". I just don't 
> think that the added complexity has much of a payoff in terms of power
> or safety. 

Not so much fundamental rules as idioms and a library of pre-written
algorithms and containers.  Yes, the complexity is a problem.  I'd say
in terms of expressive power and safety, C++ and Lisp are on a par. 
In terms of complexity (and just plain verbosity), C++ has the worse
of it.  In terms of the efficiency of the resulting machine code, Lisp
has the worse of it.

Choose your poison :-).


Regards
David Turner

david@firepro.co.za (David Turner) writes:

> In terms of the efficiency of the resulting machine code, Lisp
> has the worse of it.

Do you have any references to support such a broad claim? 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Robert STRANDH <strandh@labri.fr> wrote in message news:<6wk72ooaqk.fsf@serveur5.labri.fr>...
> david@firepro.co.za (David Turner) writes:
> 
> > In terms of the efficiency of the resulting machine code, Lisp
> > has the worse of it.
> 
> Do you have any references to support such a broad claim?

Don't be an ass.  I said it was an opinion, and it's certainly not an unpopular one.

Regards
David Turner

"Gerry Quinn" <gerryq@indigo.ie> wrote in message <news:QxAXb.2818$rb.58353@news.indigo.ie>...

> In article <slrnc2tajk.l07.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:

> >  Some people have a problem with EWD because he would tell the truth in
> >a way that was guaranteed to piss people off, and he apparently enjoyed
> >that.  But if you can come up with something he said that's actually
> >*wrong*, rather than just extreme and uncomfortably close to your home,
> >please share it with the rest of us.
>
> The notions that learning Basic renders students unteachable, or that
> object orientation is a stupid idea, have already been profferred as
> examples of things he said that are wrong.  So wrong, indeed, as to
> merit not just two asterisks, but perhaps as many as six.
>
> I note he even went so far as to write an article (substantially content
> free) about how he tells truths that are calculated to piss people off.
> In such ways does he show symptoms of intoxication due to the attentions
> of sycophants.

I'm perfectly willing to grant that EWD's pithier 'truths' were quite
true at the time he wrote them.  What 'Kamikaze' can't quite grasp is
that some 'truths' have an expiration date, but he should be forgiven
this lapse, since his fount of 'knowledge' is his ~100KB quotes file.
Even his list of "good languages" comes directly from a Usenet quote:

 URL:http://kuoi.asui.uidaho.edu/~kamikaze/Quotes/#cplusplus

All his 'knowledge' about VB apparently came from this moronic quote:

 URL:http://kuoi.asui.uidaho.edu/~kamikaze/Quotes/#visual_basic

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"MSCHAEF.COM" <mschaef@io.com> wrote in message
news:lPOdndgdi4zhm7Dd4p2dnA@io.com...
> In article <p5SWb.8593$lK.613813@news20.bellglobal.com>,
> Michael N. Christoff <mchristoff@sympatico.caREMOVETHIS> wrote:
>   ...
> >What is the practical benefit of closures?
> >

By the way, have you checked out the Java based language BeanShell?  An
example of what they call a method closure is below:

---
// define a function foo
foo() {
    int a = 42;
    bar() {
        print("The bar is open!");
    }
    bar();
    return this;
}

// Construct the foo object
fooObj = foo(); // prints "the bar is open!"

// Print a variable of the foo object
print ( fooObj.a ) // 42

// Invoke a method on the foo object
fooObj.bar(); // prints "the bar is open!"
---

http://www.beanshell.org/home.html



l8r, Mike N. Christoff

In article <6wk72ooaqk.fsf@serveur5.labri.fr>, strandh@labri.fr says...
> david@firepro.co.za (David Turner) writes:
> 
> > In terms of the efficiency of the resulting machine code, Lisp
> > has the worse of it.
> 
> Do you have any references to support such a broad claim? 

Do you suppose the existence of dedicated "lisp machines" to 
support the language have any impact on this, particularly 
those with special hardware support for some of the common 
Lisp operations such as GC and CONS?

-- 
Randy Howard                
2reply remove FOOBAR 
      

gerryq@indigo.ie (Gerry Quinn) wrote in message news:<m8oXb.2759$rb.57985@news.indigo.ie>...
> In article <slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
> >
> Dijkstra seems incredibly overrated.  As far as I can see he is famous 
> for (a) a trivial pathfinding algorithm that must have been re-invented 
> hundreds of times, and (b) a bunch of stupidly aggressive and 
> wrong-headed comments, such as the above about OO, and the stupidity 
> about Basic (which I interpret as meaning he was a crap teacher too).
> 
> No doubt he did useful stuff I haven't heard of, but his record as 
> typically referred to on usenet is quite pitiful.

He did a large amount of the seminal work on synchronization.  He was
also contributed hugely to understanding the software crisis of the
60s.  Things that perhaps seem trivial now, but were path-breaking
steps.

Regards
David Turner

Joe \"Nuke Me Xemu\" Foster <joe@bftsi0.UUCP>
wrote on Sun, 15 Feb 2004 09:34:04 -0800:
> "Gerry Quinn" <gerryq@indigo.ie> wrote in message <news:QxAXb.2818$rb.58353@news.indigo.ie>...
>> In article <slrnc2tajk.l07.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
>> >  Some people have a problem with EWD because he would tell the truth in
>> >a way that was guaranteed to piss people off, and he apparently enjoyed
>> >that.  But if you can come up with something he said that's actually
>> >*wrong*, rather than just extreme and uncomfortably close to your home,
>> >please share it with the rest of us.
>> The notions that learning Basic renders students unteachable, or that
>> object orientation is a stupid idea, have already been profferred as
>> examples of things he said that are wrong.  So wrong, indeed, as to
>> merit not just two asterisks, but perhaps as many as six.
>> I note he even went so far as to write an article (substantially content
>> free) about how he tells truths that are calculated to piss people off.
>> In such ways does he show symptoms of intoxication due to the attentions
>> of sycophants.
> I'm perfectly willing to grant that EWD's pithier 'truths' were quite
> true at the time he wrote them.  What 'Kamikaze' can't quite grasp is
> that some 'truths' have an expiration date,

  \"Xemu\", you need to learn to read for comprehension.

  When I quoted EWD's BASIC complaint, I said that he was exaggerating,
because I recovered from knowing BASIC.  When Gerry brought up the OOP
quote, I pointed out that the OOP systems of his time sucked.  When I
mentioned the "extreme case" that he used for his examples, normal
people who can read understand what that means.

  Alas, this is you.  Maybe you can get someone to help you with the big
words.

> but he should be forgiven
> this lapse, since his fount of 'knowledge' is his ~100KB quotes file.

  That happens when you add a new quote every few days for over 10
years.

> Even his list of "good languages" comes directly from a Usenet quote:
>  URL:http://kuoi.asui.uidaho.edu/~kamikaze/Quotes/#cplusplus

  As would be obvious to any rational person, I quoted that because
Eric's rant matched my opinions.  And why not?  He was right.  Well,
except about Ruby.  Bah.

> All his 'knowledge' about VB apparently came from this moronic quote:
>  URL:http://kuoi.asui.uidaho.edu/~kamikaze/Quotes/#visual_basic

  Have you learned to use your opposable thumbs yet, chimp?

  I'm glad you think I'm so important that you have to study every last
one of my web pages for clues as to my opinions, but you only had to
ask.  I'm afraid I don't consider you that important; I haven't wasted
time looking for your site, if you even have one.  Nothing you've said
to date suggests that you'd have anything of value to anyone there.

  Of course, this is the one that best describes you:
<http://kuoi.asui.uidaho.edu/~kamikaze/Quotes/#anoheliocentric>

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

"David Turner" <david@firepro.co.za> wrote in message <news:592f3326.0402151201.3edd8d72@posting.google.com>...

> gerryq@indigo.ie (Gerry Quinn) wrote in message news:<m8oXb.2759$rb.57985@news.indigo.ie>...

> > Dijkstra seems incredibly overrated.  As far as I can see he is famous
> > for (a) a trivial pathfinding algorithm that must have been re-invented
> > hundreds of times, and (b) a bunch of stupidly aggressive and
> > wrong-headed comments, such as the above about OO, and the stupidity
> > about Basic (which I interpret as meaning he was a crap teacher too).
> >
> > No doubt he did useful stuff I haven't heard of, but his record as
> > typically referred to on usenet is quite pitiful.
>
> He did a large amount of the seminal work on synchronization.  He was
> also contributed hugely to understanding the software crisis of the
> 60s.  Things that perhaps seem trivial now, but were path-breaking
> steps.

FWIW, EWD may have softened his stance on OOP over time, if one
can accept the concept of 'praising with faint damnation'.  =)
Scroll down to section 21, but the rest is also interesting:

 URL:http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html

--
Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

In article <592f3326.0402150919.5950d7c0@posting.google.com>,
David Turner <david@firepro.co.za> wrote:
>Robert STRANDH <strandh@labri.fr> wrote in message
>news:<6wk72ooaqk.fsf@serveur5.labri.fr>...
>> david@firepro.co.za (David Turner) writes:
>> 
>> > In terms of the efficiency of the resulting machine code, Lisp
>> > has the worse of it.
>> 
>> Do you have any references to support such a broad claim?
>
>Don't be an ass.  I said it was an opinion, and it's certainly not an
>unpopular one.

That seems like an awfully quantitative statement to call an opinion.  
There are plenty of examples of Lisp machine code matching the quality and
runtime performance of C and C++ code (at least on a per-function level).  
I've posted an example on this group a week or two ago of the kind of x86 
assembler Xanalys LispWorks generates for a trivial little increment 
operation. You might be suprised...

-Mike
-- 
http://www.mschaef.com

In article <MPG.1a9970fbe4e80ccb9896f1@news.verizon.net>,
Randy Howard  <randyhoward@FOOverizonBAR.net> wrote:
>In article <6wk72ooaqk.fsf@serveur5.labri.fr>, strandh@labri.fr says...
>> david@firepro.co.za (David Turner) writes:
>> 
>> > In terms of the efficiency of the resulting machine code, Lisp
>> > has the worse of it.
>> 
>> Do you have any references to support such a broad claim? 
>
>Do you suppose the existence of dedicated "lisp machines" to 
>support the language have any impact on this, particularly 
>those with special hardware support for some of the common 
>Lisp operations such as GC and CONS?

As I understand it, Lisp machines when the way of so many other
processors with language specific features: outperformed by
more general purpose hardware able to support more R&D investment.
 
IIRC, Sparc offered a couple instructions for dealing with tagged-integer 
math (integers with a couple bits reserved for type information). However,
even this limited support apparantly went away in the switch to 64-bit. I 
don't know the significance of this in terms of performance, but my hunch 
is that safety suffers more than performance in the absence of 
tagged-integer support in hardware. 

-Mike
-- 
http://www.mschaef.com

In article <0M-dnTAExLLMpa3dRVn-jA@io.com>, mschaef@io.com says...
> In article <MPG.1a9970fbe4e80ccb9896f1@news.verizon.net>,
> Randy Howard  <randyhoward@FOOverizonBAR.net> wrote:
> >In article <6wk72ooaqk.fsf@serveur5.labri.fr>, strandh@labri.fr says...
> >> david@firepro.co.za (David Turner) writes:
> >> 
> >> > In terms of the efficiency of the resulting machine code, Lisp
> >> > has the worse of it.
> >> 
> >> Do you have any references to support such a broad claim? 
> >
> >Do you suppose the existence of dedicated "lisp machines" to 
> >support the language have any impact on this, particularly 
> >those with special hardware support for some of the common 
> >Lisp operations such as GC and CONS?
> 
> As I understand it, Lisp machines when the way of so many other
> processors with language specific features: outperformed by
> more general purpose hardware able to support more R&D investment.

True, but the original point was whether or not Lisp was the worst
in terms of efficiency on hardware.  I can't think of any other
language that had special hardware built JUST to support it, at
least not in the last 30 years, IIRC.  

It's true that Lisp machines have died out, once LispM got ported
to the Dec Alpha and the emulator turned out to be faster than
a dedicated Symbolics machine, I think the party was officially
over in that regard.

-- 
Randy Howard                
2reply remove FOOBAR 
      

david@firepro.co.za (David Turner) writes:

> Robert STRANDH <strandh@labri.fr> wrote :
> > david@firepro.co.za (David Turner) writes:
> > 
> > > In terms of the efficiency of the resulting machine code, Lisp
> > > has the worse of it.
> > 
> > Do you have any references to support such a broad claim?
> 
> Don't be an ass.  I said it was an opinion, and it's certainly not
> an unpopular one. 

I sure did not come across as an opinion.  Also, just because it is a
popular opinion does not make it a correct statement.  

As others have pointed out, there are some excellent implementations
of Lisp out there that produce code that is comparable in performance
to similar C++ and C code.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Randy Howard <randyhoward@FOOverizonBAR.net> writes:

> In article <6wk72ooaqk.fsf@serveur5.labri.fr>, strandh@labri.fr says...
> > david@firepro.co.za (David Turner) writes:
> > 
> > > In terms of the efficiency of the resulting machine code, Lisp
> > > has the worse of it.
> > 
> > Do you have any references to support such a broad claim? 
> 
> Do you suppose the existence of dedicated "lisp machines" to 
> support the language have any impact on this, particularly 
> those with special hardware support for some of the common 
> Lisp operations such as GC and CONS?

I do not suppose that, but that may in effect have an impact on
someone making such a claim.  But that still does not make it a true
statement.  Compiler technology has come a long way in the past 30
years.  Now, we are able to compile Common Lisp to very efficient
machine code on stock hardware. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

mschaef@io.com (MSCHAEF.COM) writes:

> IIRC, Sparc offered a couple instructions for dealing with tagged-integer 
> math (integers with a couple bits reserved for type information). However,
> even this limited support apparantly went away in the switch to 64-bit. I 
> don't know the significance of this in terms of performance, but my hunch 
> is that safety suffers more than performance in the absence of 
> tagged-integer support in hardware. 

I think you are probably right.  If you supply as many declarations
(optional in Common Lisp) to a good Common Lisp compiler as you are
forced to do to the C++ or C compiler, you get roughly the same
performance of the resulting machine code.  But then, you get all the
same inconveniences that you get with C++ and C (modulo arithmetic,
overflow not detected, etc).

The tagged-integer instructions on the SPARC, and indeed the entire
idea of the Lisp machine, existed to provide a platform that could
give the safety and performance simultaneously. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

"Randy Howard" <randyhoward@FOOverizonBAR.net> wrote in message <news:MPG.1a9a118158dedd599896f7@news.verizon.net>...

> In article <0M-dnTAExLLMpa3dRVn-jA@io.com>, mschaef@io.com says...

> > As I understand it, Lisp machines when the way of so many other
> > processors with language specific features: outperformed by
> > more general purpose hardware able to support more R&D investment.
>
> True, but the original point was whether or not Lisp was the worst
> in terms of efficiency on hardware.  I can't think of any other
> language that had special hardware built JUST to support it, at
> least not in the last 30 years, IIRC.

Wasn't there a FORTH chip?  There might also be a CPU which runs
Java bytecode in microcode.

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Randy Howard <randyhoward@FOOverizonBAR.net> writes:

> True, but the original point was whether or not Lisp was the worst
> in terms of efficiency on hardware.  I can't think of any other
> language that had special hardware built JUST to support it, at
> least not in the last 30 years, IIRC.  

Dedicated hardware turned out to be a bad idea, mainly because it was
impossible to keep up with performance improvements of stock
hardware, but that was not clear at the time. 

However, the Lisp machine was not built JUST as a way to get decent
performance out of Lisp.  In fact, at the time, there were good
implementations of Maclisp around for ordinary (at the time)
machines. 

In fact, mainly thanks to the power of Lisp, Symbolics Lisp machines
ran what is probably still one of the most advanced operating systems
ever written, called Genera.  I do not know whether such a system
could have been written for stock hardware at the time, given the
state of art of compiler technology, but it would certainly be more
than feasible now. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

david@firepro.co.za (David Turner) writes:

> I'd say
> in terms of expressive power and safety, C++ and Lisp are on a par. 

I know this is just an opinion of yours, but I am interested in
understanding the basis for it.  Like, can you give us some (possibly
informal) definition of "expressive power" (I am assuming you are not
talking about Turing completeness) and "safety" that would make C++
and Lisp comparable here?

I haven't programmed in C++ for a long time, so many features have
been added since then, but last time I looked, C++ did not have
things like multiple dispatch, the possibility to redefine functions,
classes, etc at run time, closures, macros having the full language at
their disposal, code-data equivalence, keyword arguments, a built-in
parser having the full language at its disposal, and many more things
that I think of as part of the expressive power of Lisp.  No doubt
many of these features have been added to C++ since, but all of them?
Or are you saying these features are worthless in terms of expressive
power? 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Hello

> That seems like an awfully quantitative statement to call an opinion.
> There are plenty of examples of Lisp machine code matching the quality and
> runtime performance of C and C++ code (at least on a per-function level).
> I've posted an example on this group a week or two ago of the kind of x86
> assembler Xanalys LispWorks generates for a trivial little increment
> operation. You might be suprised...


I notice that nobody complained when I opined that C++ was more verbose ;-).
Also, this is very much peripheral to the argument.  But it should be
obvious that the fact that there are plenty of examples of Lisp code
matching C++ code in terms of speed says nothing about the "average"
performance of Lisp programs compared to the "average" performance of C++
programs.  What's more, I wouldn't call the "average" performance of a Lisp
program something that could be quantified:  it depends heavily on the type
of task, the type of hardware (a Lisp machine is likely to do much better
than an x86), and the type of programmer.

Hence: it's an opinion.  To be precise: in the type of work I'm involved in,
it is my subjective experience that Lisp solutions I write run slower than
C++ I write.  Insert as many disclaimers as you like.

Regards
David Turner

"David Turner" <david@firepro.co.za> writes:

> To be precise: in the type of work I'm involved in,

What kind of work are you involved in?

> it is my subjective experience that Lisp solutions I write run slower than
> C++ I write.

Could you post some of your Lisp code?  It would be interesting to see
why it would be slower than the comparable C++ code.  Perhaps your
opinion that Lisp is slow is based on some code that is not
representative for Lisp code in general.  

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

In article <1076892760.497303@news-1.nethere.net>, "Joe \"Nuke Me Xemu\" Foster" <jlf%40znet%2ecom> wrote:
>
>FWIW, EWD may have softened his stance on OOP over time, if one
>can accept the concept of 'praising with faint damnation'.  =)
>Scroll down to section 21, but the rest is also interesting:
>
> URL:http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html

<BEGIN QUOTE>
>After more than 45 years in the field, I am still convinced that in computing, 
>elegance is not a dispensable luxury but a quality that decides between 
>success and failure; in this connection I gratefully quote from The Concise 
>Oxford Dictionary a definition of "elegant", viz. "ingeniously simple and 
>effective". Amen. (For those who have wondered: I don't think 
>object-oriented programming is a structuring paradigm that meets my 
>standards of elegance.)
<END QUOTE>

Well, he sounds like somebody who knows he is wrong, but won't admit it.

- Gerry Quinn

In article <1076912576.167044@news-1.nethere.net>,
Joe \"Nuke Me Xemu\" Foster <jlf%40znet%2ecom> wrote:
>"Randy Howard" <randyhoward@FOOverizonBAR.net> wrote in message
  ...
>Wasn't there a FORTH chip?  

Yes, the Novix NC4016 is the one that immediately came to mind. In
the Google search for the part number, I ran across this:

http://www.ultratechnology.com/chips.htm

>There might also be a CPU which runs
>Java bytecode in microcode.

There's the picoJava core, and I believe there was a CPU chip based on
similar technology.

http://www.sun.com/microelectronics/picoJava/


IIRC, around the time of Java's release, when Sun was emphasizing the 
cross-platform nature of the platform, they were also ironically enough
developing a native Java hardware and OS platform.

-Mike
-- 
http://www.mschaef.com

On Mon, 16 Feb 2004 07:17:07 -0600, mschaef@fnord.io.com (MSCHAEF.COM) wrote:
>
>There's the picoJava core, and I believe there was a CPU chip based on
>similar technology.
>
>http://www.sun.com/microelectronics/picoJava/

Heh, it would be nice if Microsoft, perhaps with Intel, took that picoJava
thing and changed it just a little bit and voil�!, "picoNet!".  :-)

In article <1076916296.785839@tanzanite.firepro.co.za>,
David Turner <david@firepro.co.za> wrote:
  ...
>I notice that nobody complained when I opined that C++ was more verbose ;-).

I think that in the general case, C++ _is_ more verbose. The mechanisms it 
provides for defining abstractions are focused enough that you need more 
of them to do most designs. Lisp does tend towards wordy naming 
(destructuring-bind, etc.), but the longer names tend to do a lot. 
(destructuring-bind will, at compile time, analyze a template of a given 
list structure and generate primitive code to extract out the specified 
elements.)

>Also, this is very much peripheral to the argument.  But it should be
>obvious that the fact that there are plenty of examples of Lisp code
>matching C++ code in terms of speed says nothing about the "average"
>performance of Lisp programs compared to the "average" performance of C++
>programs. 

I've found that the "average" performance of my software is pretty much
irrelevant. There are usually just a couple routines that make up the vast
majority of the time spent processing. As a result, I'd rather work in a
language that gives me the flexibility to work quickly on the stuff
outside the critical path and then spend my time optimizing the core of
the software to a high degree. Part of the problem I have with C++ is that 
it forces you to spend all your time in "static typed, highly optimized" 
land, even on the trivial things for which it shouldn't matter. It's 
almost like optimizing an entire program prematurely.

>I wouldn't call the "average" performance of a Lisp ... [it depends 
>on] ... the type of hardware (a Lisp machine is likely to do much better
>than an x86), 

Lisp hardware hasn't had a good performance-related value proposition for
more than 20 years.. If your C++ knowledge was limited to the same
timeframe as this statement, you'd pretty much be limited to talking about
Stroustrup's original "C with Classes" and the way it was compiled into
pre-ANSI C. ;-)

I've said it before, and I'll say it again: The biggest battle Lisp has 
had to fight has been regarding what people think it is, rather than what 
it actually is. There are just so many stereotypes:

- Lisp is slow and produces inefficient machine code
- Lisp requires special hardware to run fast
- Lisp is an AI language only
- Lisp can only work with lists
- Lisp can't be compiled
- Garbage collection is amazingly inefficient

None of these statements is even close to being true, and yet I see them
_all the time_, and from what are generally talented and open minded
developers.

-MIke
-- 
http://www.mschaef.com

In article <MPG.1a9a118158dedd599896f7@news.verizon.net>,
Randy Howard  <randyhoward@FOOverizonBAR.net> wrote:
 ...
>True, but the original point was whether or not Lisp was the worst
>in terms of efficiency on hardware.  I can't think of any other
>language that had special hardware built JUST to support it, at
>least not in the last 30 years, IIRC.  

There are a bunch of oddball special purpose processors extant. I've 
mentioned the Novix Forth chip elsewhere in this thread, as well as 
the picoJava core. Linn, a Scottish company known for High-fidelity stereo 
equipment, sponsored work 10-15 years ago on the Rekursiv, a processor 
optimized for doing OOP work. It had a writable instruction set, so it 
could be customized for multiple languages, but it very much targeted a 
given idiom. The same thing can be said for the architecture of most DSP 
chips: they are highly targeted towards a given programming style.

Lisp is far from unique in that it has custom hardware designed for it.

-Mike
-- 
http://www.mschaef.com

On Mon, 16 Feb 2004 07:58:17 -0600, mschaef@fnord.io.com (MSCHAEF.COM) wrote:

>I've said it before, and I'll say it again: The biggest battle Lisp has 
>had to fight has been regarding what people think it is, rather than what 
>it actually is. There are just so many stereotypes:
>
>- Lisp is slow and produces inefficient machine code
>- Lisp requires special hardware to run fast
>- Lisp is an AI language only
>- Lisp can only work with lists
>- Lisp can't be compiled
>- Garbage collection is amazingly inefficient
>
>None of these statements is even close to being true, and yet I see them
>_all the time_, and from what are generally talented and open minded
>developers.

They're idiots, just reciting arguments from folks like Patrick H. Winston.

No, the main reason no sane person should be using Lisp is its parenthesis-
based syntax.

Get rid of that, and something else and more readable in place, and Lisp
could be the new JavaScript (sort of like RatFor!)  --  or something!

Hi

> it forces you to spend all your time in "static typed, highly optimized"
> land, even on the trivial things for which it shouldn't matter. It's
> almost like optimizing an entire program prematurely.

Fair enough.  C++ isn't the right tool for every job.


> Lisp hardware hasn't had a good performance-related value proposition for
> more than 20 years.. If your C++ knowledge was limited to the same
> timeframe as this statement, you'd pretty much be limited to talking about
> Stroustrup's original "C with Classes" and the way it was compiled into
> pre-ANSI C. ;-)

Ha ha, yes.  I give up ;-).


> I've said it before, and I'll say it again: The biggest battle Lisp has
> had to fight has been regarding what people think it is, rather than what
> it actually is. There are just so many stereotypes:
[snip]
> None of these statements is even close to being true, and yet I see them
> _all the time_, and from what are generally talented and open minded
> developers.

Valid point.  Evangelize!

Regards
David Turner

In article <4030cdb0.449203515@news.individual.net>,
Alf P. Steinbach <alfps@start.no> wrote:
  ...
>No, the main reason no sane person should be using Lisp is its parenthesis-
>based syntax.

How could I have forgotten: "Lisp has a too complicated syntax!". :-)

>Get rid of that, and something else and more readable in place, and Lisp
>could be the new JavaScript (sort of like RatFor!)  --  or something!

I think that Dylan was an attempt at an infix Lisp.

(On a much more trivial scale, I'm working on an infix->Lisp parser 
myself, so that I can avoid forcing users to code formulas in prefix.)

-Mike
-- 
http://www.mschaef.com

alfps@start.no (Alf P. Steinbach) writes:

> No, the main reason no sane person should be using Lisp is its parenthesis-
> based syntax.

On the contrary, that is one of the absolute main features of the
language.  Anyone who does not realize that is going to miss out on
perhaps the main feature of Lisp, namely its absolutely fantastic
macro facility.  Fully parenthesized expressions let the Lisp
programmer think of the program in terms of how the code is
represented internally as Lisp lists.  Macros transform these internal
representations into other internal representations, thereby making it
easy for Lisp programs to inspect, transform, and generate other Lisp
programs.

This is the main reason Lisp has been called "a programmable
programming language".

Anyone interested in programming techniques based on Common Lisp
macros should have a look at the excellent book "On Lisp" by Paul
Graham.  This is one of the best books on programming that I have ever
read.  I believe it is still available in full on line as a PDF file. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

"Gerry Quinn" <gerryq@indigo.ie> wrote in message <news:1i2Yb.2955$rb.58571@news.indigo.ie>...

> In article <1076892760.497303@news-1.nethere.net>, "Joe \"Nuke Me Xemu\" Foster" <jlf%40znet%2ecom> wrote:
> >
> >FWIW, EWD may have softened his stance on OOP over time, if one
> >can accept the concept of 'praising with faint damnation'.  =)
> >Scroll down to section 21, but the rest is also interesting:
> >
> > URL:http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html
>
> <BEGIN QUOTE>
> >After more than 45 years in the field, I am still convinced that in computing,
> >elegance is not a dispensable luxury but a quality that decides between
> >success and failure; in this connection I gratefully quote from The Concise
> >Oxford Dictionary a definition of "elegant", viz. "ingeniously simple and
> >effective". Amen. (For those who have wondered: I don't think
> >object-oriented programming is a structuring paradigm that meets my
> >standards of elegance.)
> <END QUOTE>
>
> Well, he sounds like somebody who knows he is wrong, but won't admit it.

You have to admit that OOP turned out to hardly be the panacea its
evangelists still claim it to be, what with the "fragile base class"
problem and the way both inheritance and methods break encapsulation:

 URL:http://citeseer.nj.nec.com/context/73033/513482

 URL:http://cuj.com/documents/s=8042/cuj0002meyers/

 URL:http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1024.html

<quote>
If, then, the campus is insufficiently shielded from those
pressures and the market forces are given too free a reign,
you can draw your conclusion: a flourishing snakeoil business,
be it in "programming by example", "object-oriented programming",
"natural language programming", "automatic program generation",
"expert systems", "specification animation", or "computer-supported
co-operative work".
</quote>

At least I can't find slams against BASIC after versions deprecating
the line numbers and supporting structured programming became popular.
EWD continued to pimp-slap OOP ten years after his last BASIC bitching!

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Alf P. Steinbach" <alfps@start.no> wrote in message <news:4030c5d2.447188796@news.individual.net>...

> On Mon, 16 Feb 2004 07:17:07 -0600, mschaef@fnord.io.com (MSCHAEF.COM) wrote:
> >
> >There's the picoJava core, and I believe there was a CPU chip based on
> >similar technology.
> >
> >http://www.sun.com/microelectronics/picoJava/
>
> Heh, it would be nice if Microsoft, perhaps with Intel, took that picoJava
> thing and changed it just a little bit and voil�!, "picoNet!".  :-)

They're trying the 'next best thing', DRM in the BIOS so only
Micro$haft Longhorn and above will be able to boot up at all.

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Mark 'Kamikaze' Hughes wrote:

> Visual Basic is completely inadequate for real programming.

Oops!  Didn't realize I'd been making toy programs for my customers!!

> It's a toy for making clicky forms and scripting Office apps,...

And writing interactive, graphical manufacturing process control
applications.  And writing interactive, graphical software for
running testing equipment and displaying realtime results.  And
writing powerful user interface systems.  And writing data conversion
layers in SQL server.  And generating complicated Word and Excel
documents in software.  And....  [1]

(-:


[1] to name just a few of the "toys" I've *personally* written...

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Noah Roberts wrote:

>> ...objections to VB,...
> 
> No bit shifting operators.
> Non short-circuting logical operators (and, or).
> The IDE has always pissed me off also.

#3 is personal opinion, although I can understand your feelings.
I do do a fair amount of VB editing in gvim.

#2 is more a language choice, I think, than an indicator of the
"maturity" or "professionalism" of a language.  There is nothing
to my mind intrinsically "correct" about short-circuiting logical
ops.

#1 is a fair shot.  VB sucks at bit-level manipulation and lacks
an unsigned integer type (one of *my* biggest gripes).  I solved
that by writting a C DLL that provides a library of low-level
stuff (and some string routines) for my VB programs.  Works great,
and I get the best of both worlds.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Programmer Dude" <Chris@Sonnack.com> wrote in message <news:4030ECEF.F066617C@Sonnack.com>...

> #1 is a fair shot.  VB sucks at bit-level manipulation and lacks
> an unsigned integer type (one of *my* biggest gripes).  I solved
> that by writting a C DLL that provides a library of low-level
> stuff (and some string routines) for my VB programs.  Works great,
> and I get the best of both worlds.

I usually manage to cobble up pure-VB workarounds, like using
a sequence of And, division, and another And to simulate an
unsigned right-shift.  The result, used for calculating file
CRCs, was competitive with a command-line utility written in C:

http://groups.google.com/groups?selm=%23bXyVM5uDHA.1680%40TK2MSFTNGP12.phx.gbl

--
Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Programmer Dude" <Chris@Sonnack.com> wrote in message <news:4030EB9D.D6CAA057@Sonnack.com>...

> Mark 'Kamikaze' Hughes wrote:
>
> > Visual Basic is completely inadequate for real programming.
>
> Oops!  Didn't realize I'd been making toy programs for my customers!!

It's all because he discovered a VB programmer had a higher salary:

 URL:http://groups.google.com/groups?selm=slrna9kdkq.67e.kamikaze%40kuoi.asui.uidaho.edu

--
Joe Foster <mailto:jlfoster%40znet.com>     On the cans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Joe \"Nuke Me Xemu\" Foster <joe@bftsi0.UUCP>
wrote on Mon, 16 Feb 2004 09:23:43 -0800:
> "Programmer Dude" <Chris@Sonnack.com> wrote in message <news:4030EB9D.D6CAA057@Sonnack.com>...
>> Mark 'Kamikaze' Hughes wrote:
>> > Visual Basic is completely inadequate for real programming.
>> Oops!  Didn't realize I'd been making toy programs for my customers!!
> It's all because he discovered a VB programmer had a higher salary:
>  URL:http://groups.google.com/groups?selm=slrna9kdkq.67e.kamikaze%40kuoi.asui.uidaho.edu

  How nice, you've graduated from kook to Internet Stalker.

 <http://kuoi.asui.uidaho.edu/~kamikaze/doc/plonk.html>

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

"Michael N. Christoff" wrote:

> // Construct the foo object
> fooObj = foo(); // prints "the bar is open!"

Looks like a function, accesses like a struct???

How bizarre!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

MSCHAEF.COM <mschaef@fnord.io.com>
wrote on Mon, 16 Feb 2004 08:12:32 -0600:
> In article <4030cdb0.449203515@news.individual.net>,
> Alf P. Steinbach <alfps@start.no> wrote:
>>No, the main reason no sane person should be using Lisp is its parenthesis-
>>based syntax.
> How could I have forgotten: "Lisp has a too complicated syntax!". :-)

  It's a very simple syntax, but it's also very ugly, especially when
deeply nested.  For procedural code with little nesting, sexps are fine.
Naturally, most Lisp code is written as functionally as possible (Lisp
programmers seem to like playing the game "how few variables or named
functions can I use?"), and is therefore unreadable.

  When used in a different style of language, the syntax works okay; the
scripting language I'm working on uses sexps, but it's more procedural
than Lisp.

>>Get rid of that, and something else and more readable in place, and Lisp
>>could be the new JavaScript (sort of like RatFor!)  --  or something!
> I think that Dylan was an attempt at an infix Lisp.
> (On a much more trivial scale, I'm working on an infix->Lisp parser 
> myself, so that I can avoid forcing users to code formulas in prefix.)

  LOGO is just a dialect of Lisp, where the parens [brackets, actually]
are omitted from around lines.  The only minor exception is for TO.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

"Programmer Dude" <Chris@Sonnack.com> wrote in message <news:40310E92.CFE54335@Sonnack.com>...

> "Michael N. Christoff" wrote:
>
> > // Construct the foo object
> > fooObj = foo(); // prints "the bar is open!"
>
> Looks like a function, accesses like a struct???
>
> How bizarre!

Everything is an object, including functions?

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

In article <4030EB9D.D6CAA057@Sonnack.com>,
Programmer Dude  <Chris@Sonnack.com> wrote:
   ...
>And generating complicated Word and Excel documents in [VisualBASIC]
>software. 

That sounds like an exercise in applied misery in almost any language. :-)

Is this typically done starting with a template, or is everything driven into 
Word using the object model?

-Mike
-- 
http://www.mschaef.com

Joe \"Nuke Me Xemu\" Foster wrote:

>>> // Construct the foo object
>>> fooObj = foo(); // prints "the bar is open!"
>>
>> Looks like a function, accesses like a struct???
>>
>> How bizarre!
> 
> Everything is an object, including functions?

That *is* true in some languages.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"MSCHAEF.COM" wrote:

>> And generating complicated Word and Excel documents in
>> [VisualBASIC] software.
> 
> That sounds like an exercise in applied misery in almost any
> language. :-)

Using ADO as a yardstick, I think I'd hate to do it in VC++, but
it's not bad in VB.

> Is this typically done starting with a template, or is
> everything driven into Word using the object model?

The latter.  I usually start with a blank page or spreadsheet.

The Word and Excel object models are actually kind of neat....

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

In article <slrnc3240n.r32.kamikaze@kuoi.asui.uidaho.edu>,
Mark 'Kamikaze' Hughes <kamikaze@kuoi.asui.uidaho.edu> wrote:
  ...
>  It's a very simple syntax, but it's also very ugly, especially when
>deeply nested.  

That's a matter of taste. I've found that a good editor with syntax
highlighting/indenting, and paren matching can work wonders for
code. Not to mention paying attention to code factoring. Like
virtually every other language *cough*C*cough* the possibility of
ugly code does not preclude writing readable and maintainable code.

>Naturally, most Lisp code is written as functionally as possible (Lisp
>programmers seem to like playing the game "how few variables or named
>functions can I use?"), and is therefore unreadable.

This is another one of those biases I was talking about, except
this one is sometimes supported in the academic Lisp community. The
lower-divison course I took to introduce myself to Lisp placed lots
of emphasis on a functional style and lots of non-desctuctive
operators. It was only when I started using it in more advanced
courses that the curricula started placing more emphasis on
efficienty concerns. And, while you're right that Lisp _can_ be
used in a highly functional style, it also can support the
procedural/OO, lots of variables, destructive assignment (with a
goto on top) model that most programmers are used to these days.

Again, it's a matter of the choice and style of the programmer.

>  When used in a different style of language, the syntax works okay; the
>scripting language I'm working on uses sexps, but it's more procedural
>than Lisp.

Can you post some examples of what code looks like in this language?

-Mike
-- 
http://www.mschaef.com

In article <4031199E.B12F3B5@Sonnack.com>,
Programmer Dude  <Chris@Sonnack.com> wrote:
  ...
>The Word and Excel object models are actually kind of neat....

Maybe it's worth looking into...

-Mike
-- 
http://www.mschaef.com

In article <1076944899.255108@news-1.nethere.net>, "Joe \"Nuke Me Xemu\" Foster" <jlf%40znet%2ecom> wrote:
>"Gerry Quinn" <gerryq@indigo.ie> wrote in message
> <news:1i2Yb.2955$rb.58571@news.indigo.ie>...
>>
>> [Dijkstra] sounds like somebody who knows he is wrong, but won't admit it.
>
>You have to admit that OOP turned out to hardly be the panacea its
>evangelists still claim it to be, what with the "fragile base class"
>problem and the way both inheritance and methods break encapsulation:
>
> URL:http://cuj.com/documents/s=8042/cuj0002meyers/

Meyers understands neither object orientation nor encapsulation.  I 
refer you to the thread from August 2002:
http//groupsgooglecom/groupsas_q=Meyer%20encapsulation
&safe=images&ie=ISO-8859-1&as_uauthors=gerryq@indigo.ie
&lr=&hl=en
..in which I comprehensively demolish the nonsensical concepts he 
presents.

As for "the panacea its evangelists still claim it to be" it is well 
known that there is no silver bullet in software, so that argument is a 
straw horse.

- Gerry Quinn
  

MSCHAEF.COM <mschaef@io.com>
wrote on Mon, 16 Feb 2004 13:34:04 -0600:
> In article <slrnc3240n.r32.kamikaze@kuoi.asui.uidaho.edu>,
> Mark 'Kamikaze' Hughes <kamikaze@kuoi.asui.uidaho.edu> wrote:
>>  It's a very simple syntax, but it's also very ugly, especially when
>>deeply nested.  
> That's a matter of taste. I've found that a good editor with syntax
> highlighting/indenting, and paren matching can work wonders for
> code. Not to mention paying attention to code factoring. Like
> virtually every other language *cough*C*cough* the possibility of
> ugly code does not preclude writing readable and maintainable code.

  The trouble with paren matching is that it only happens when you
actively move the cursor to one paren.  Reading it without moving the
cursor around is a much harder problem.  Drawing lines to represent the
structure just clutters the display.  Using newlines in all
more-than-minimally complex structures is ugly, too:
(foo (+ a b)
)

  I don't think a good solution to this is possible.  You can put a bag
over Lisp's head, but it's still not gonna get a date on its looks.

>>Naturally, most Lisp code is written as functionally as possible (Lisp
>>programmers seem to like playing the game "how few variables or named
>>functions can I use?"), and is therefore unreadable.
> This is another one of those biases I was talking about, except
> this one is sometimes supported in the academic Lisp community. The
> lower-divison course I took to introduce myself to Lisp placed lots
> of emphasis on a functional style and lots of non-desctuctive
> operators. It was only when I started using it in more advanced
> courses that the curricula started placing more emphasis on
> efficienty concerns. And, while you're right that Lisp _can_ be
> used in a highly functional style, it also can support the
> procedural/OO, lots of variables, destructive assignment (with a
> goto on top) model that most programmers are used to these days.
> Again, it's a matter of the choice and style of the programmer.

  Most of the academics will claim that massively recursive, functional
code is more efficient than procedural; this is even true to some
extent, since Lisp compilers are optimized for tail-recursion rather
than looping structures or variable access.

  If you're trying to modify code written by someone else, it will
almost always be written in a pure functional style.  If you try to
write Lisp code some other way, the pure-functional Lisp programmers
will get upset and throw 10-pound Lisp books at you.  Basically it's not
worth even trying in a professional environment.

>>  When used in a different style of language, the syntax works okay; the
>>scripting language I'm working on uses sexps, but it's more procedural
>>than Lisp.
> Can you post some examples of what code looks like in this language?

  Not right now, I'm still waffling on some of the syntax.  The current
version works and runs my regression tests, but it's not at a
public-consumption point yet.  But in brief: I use the LOGO approach of
implicit parens around lines and function declarations (quoted code run
with eval uses explicit parens).  It has a richer set of more
traditional looping structures.  The list type is mutable and has
efficient random-access--this is vital in procedural code that might
iterate over or select from a list, but is irrelevant in functional
code.  Lisp treats arrays/vectors as second-class citizens even in
implementations which support them at all.  There are other differences,
mainly emerging from it being intended as a small-footprint tool for
scripting Java apps, rather than a general-purpose app dev language.  If
I want that, I've got Java or Python.

-- 
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"God, I think. God. He doesn't answer, and I'd be justifiably scared--but not
 in a panic!--if he did, since I would know it really was Resuna, or a tiny
 brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes

In article <slrnc32k72.r32.kamikaze@kuoi.asui.uidaho.edu>,
Mark 'Kamikaze' Hughes <kamikaze@kuoi.asui.uidaho.edu> wrote:
  ...
>  The trouble with paren matching is that it only happens when you
>actively move the cursor to one paren.  Reading it without moving the
>cursor around is a much harder problem.

For code structure, this is a problem soluble via indention rules, like
virtually every other free-form language. IMO, where it gets a little ugly
is in mathematical expressions:

  (define (tvm pv fv i pmt n begin?)
    (+ pv
       (* pmt 
          (+ 1 (* i (if begin? 1 0)))
          (/ (- 1 (expt (+ 1 i) (- n)))
             i))
        (* fv
           (expt (+ 1 i) (- n)))))

I'm not willing to say much of anything positive about that, except to 
point out that Lisp makes it pretty easy to add custom lexical and syntax 
analysis to the native language. That's a marginal solution, at best.

>Using newlines in all
>more-than-minimally complex structures is ugly, too:
>(foo (+ a b)
>)

That's not the way that'd be indented:

(foo (+ a b)
     )

I think the readability of control structures in Lisp is pretty much a 
matter of what you've gotten used to. I don't find well-indented code to 
be much of a problem in either Lisp or languages like C. Misleading 
formatting in either is much worse to me than the differences between the 
two.

>  Most of the academics will claim that massively recursive, functional
>code is more efficient than procedural; this is even true to some
>extent, since Lisp compilers are optimized for tail-recursion rather
>than looping structures or variable access.

I don't think you'll find anybody that will claim that an efficiently 
compiled tail recursive solution is more efficient than the same code 
implemented with a looping construct. Regarding looping structures or 
variable access, have you actually looked at the code emitted by a good 
Lisp compiler?  With safety turned down and optimization turned up, it can 
look remarkably like the output from a good C compiler.

But we were talking about academic attitudes towards Lisp. I can't claim
to have more than four or five Lisp courses under my belt, but in the more
advanced coursework I took, the professors took a more pragmatic approach
than what you seem to be claiming.

>  If you're trying to modify code written by someone else, it will
>almost always be written in a pure functional style.  If you try to
>write Lisp code some other way, the pure-functional Lisp programmers
>will get upset and throw 10-pound Lisp books at you.

Even the language itself speaks against that statement.  Lisp has 
incredibly powerful looping and assigment operators built into the 
specificaton. Not to mention the CLOS object system, which is almost
by definition more imperative than functional. 

>The list type is mutable and has efficient random-access--

Can you speak to how this is implemented?

> Lisp treats arrays/vectors as second-class citizens even in
>implementations which support them at all. 

O(1) by index containers (arrays/vectors) have first-class representation 
in both the Common Lisp and Scheme specificatons. In Common Lisp, the full 
set of sequence operations work on both lists and vectors, not to mention 
desctucturing-bind. There are implementations of both specificatons that 
support type declarations for high degrees of efficiency (machine vision 
work in Lisp apparantly provided a great deal of impetus). 

Personally, I think you'd have a hard time finding an implementation of 
either language that did _not_ support arrays or vectors. Even SIOD, known 
for it's simplicity (it's about 10kloc), supports several different kinds 
of vectors.

-Mike
-- 
http://www.mschaef.com

"Gerry Quinn" <gerryq@indigo.ie> wrote in message <news:p6cYb.3029$rb.58285@news.indigo.ie>...

> In article <1076944899.255108@news-1.nethere.net>, "Joe \"Nuke Me Xemu\" Foster" <jlf%40znet%2ecom> wrote:

> >You have to admit that OOP turned out to hardly be the panacea its
> >evangelists still claim it to be, what with the "fragile base class"
> >problem and the way both inheritance and methods break encapsulation:
> >
> > URL:http://cuj.com/documents/s=8042/cuj0002meyers/
>
> Meyers understands neither object orientation nor encapsulation.  I
> refer you to the thread from August 2002:
> http//groupsgooglecom/groupsas_q=Meyer%20encapsulation
> &safe=images&ie=ISO-8859-1&as_uauthors=gerryq@indigo.ie
> &lr=&hl=en
> .in which I comprehensively demolish the nonsensical concepts he
> presents.

Provide a Sleep( Wombat& , double ) which calls wombat.Sleep( double ).
End of inconsistency, but the illusion of data and code being 'bound
together' is shattered.  Oh well!  However, the Java/C++ way isn't the
only way.  A language could treat functions and methods as equivalent,
so if the parser encounters wombat.Nap() but wombat has no Nap method,
it looks for an ordinary function like Nap( Wombat& ).  If that fails,
it could look for Nap( Mammal& ), Nap( Vertebrate& ), Nap( Animal& ),
etc. etc. etc. ...

> As for "the panacea its evangelists still claim it to be" it is well
> known that there is no silver bullet in software, so that argument is a
> straw horse.

Not entirely.  Quite a few OO evangelists have gotten carried away.

 URL:http://softpanorama.org/SE/anti_oo.shtml

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"MSCHAEF.COM" <mschaef@io.com> wrote in message <news:LpWdnaDSl9Mfhazd4p2dnA@io.com>...

> In article <4030EB9D.D6CAA057@Sonnack.com>,
> Programmer Dude  <Chris@Sonnack.com> wrote:
>    ...
> >And generating complicated Word and Excel documents in [VisualBASIC]
> >software.
>
> That sounds like an exercise in applied misery in almost any language. :-)

COM is practically VB's native tongue, with the result that it's
so easy Mark 'Kamikaze' Hughes rants and raves about it...  =P

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

In article <1076988021.668617@news-1.nethere.net>,
Joe \"Nuke Me Xemu\" Foster <jlf%40znet%2ecom> wrote:
>"MSCHAEF.COM" <mschaef@io.com> wrote in message
><news:LpWdnaDSl9Mfhazd4p2dnA@io.com>...
>
>> In article <4030EB9D.D6CAA057@Sonnack.com>,
>> Programmer Dude  <Chris@Sonnack.com> wrote:
>>    ...
>> >And generating complicated Word and Excel documents in [VisualBASIC]
>> >software.
>>
>> That sounds like an exercise in applied misery in almost any language. :-)
>
>COM is practically VB's native tongue

Yeah, it was just the idea of using an object model to drive all that 
formatting information into Word.  I'm just envisioning a never ending 
stream of insert_this_text, select_bold, select_underline, 
insert_some_more_text, unselect_bold, make_a_2_by_2_table... and on and 
on.

That seems like a really tedious way to do procedurally the kind of thing
that comes more naturally in markup.  I dunno though, maybe Word's object
model makes it trivial.

 -Mike
-- 
http://www.mschaef.com

On Sat, 14 Feb 2004 12:08:01 GMT, gerryq@indigo.ie (Gerry Quinn)
wrote:

>In article <slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
>>
>>>  Do you also
>>> agree with Dijkstra about object orientation?
>>> "Object-oriented programming is an exceptionally bad idea that
>>> could only have been invented in California."
>>> http://quote.wikipedia.org/wiki/Edsger_Dijkstra
>>
Given that Dijkstra ( along with Hoare and Dahl ) is one of the
authors of one of the first books that describes OO ( I can't think
of another that was earlier ), allthough he did not write that
section.

It may well be that he did not think poorly of OO in general, but
of OO as presented by Smalltalk ( which was probably the defining
language of OO when he made that quote ). Perhaps it was properties
of OO as described by Smalltalk he objected to ( dynamic typing comes
to mind,  but I'm not sure what he felt about typing in general ).

>
>Dijkstra seems incredibly overrated.  As far as I can see he is famous 
>for (a) a trivial pathfinding algorithm that must have been re-invented 
>hundreds of times, and (b) a bunch of stupidly aggressive and 
>wrong-headed comments, such as the above about OO, and the stupidity 
>about Basic (which I interpret as meaning he was a crap teacher too).
>

He has three main claims to fame:
1) He basically invented a large structured programming ( goto
considered...).
2) He invented semaphores.
3) He brought a mathematical rigor to programming.
The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.

"TLOlczyk" <olczyk2002@yahoo.com> wrote in message <news:gn4330lqibqeqakv0loqahjf0ntjp7bs6d@4ax.com>...

> On Sat, 14 Feb 2004 12:08:01 GMT, gerryq@indigo.ie (Gerry Quinn)
> wrote:
>
> >In article <slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
> >>
> >>>  Do you also
> >>> agree with Dijkstra about object orientation?
> >>> "Object-oriented programming is an exceptionally bad idea that
> >>> could only have been invented in California."
> >>> http://quote.wikipedia.org/wiki/Edsger_Dijkstra
> >>
> Given that Dijkstra ( along with Hoare and Dahl ) is one of the
> authors of one of the first books that describes OO ( I can't think
> of another that was earlier ), allthough he did not write that
> section.
>
> It may well be that he did not think poorly of OO in general, but
> of OO as presented by Smalltalk ( which was probably the defining
> language of OO when he made that quote ). Perhaps it was properties
> of OO as described by Smalltalk he objected to ( dynamic typing comes
> to mind,  but I'm not sure what he felt about typing in general ).

I can't find anything in EWD's transcribed notes about Smalltalk,
only some juicy quotes denouncing object-oriented programming as
"snakeoil" and an insufficiently elegant structuring paradigm:

<< After more than 45 years in the field, I am still convinced that
in computing, elegance is not a dispensable luxury but a quality that
decides between success and failure; in this connection I gratefully
quote from The Concise Oxford Dictionary a definition of "elegant",
viz. "ingeniously simple and effective". Amen. (For those who have
wondered: I don't think object-oriented programming is a structuring
paradigm that meets my standards of elegance.) >>
-- URL:http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html

<< If, then, the campus is insufficiently shielded from those
pressures and the market forces are given too free a reign,
you can draw your conclusion: a flourishing snakeoil business,
be it in "programming by example", "object-oriented programming",
"natural language programming", "automatic program generation",
"expert systems", "specification animation", or "computer-supported
co-operative work". >>
-- URL:http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1024.html

I'm not sure about the provenance of this one:

"Object-oriented programming is a style of programming designed
to teach students about stacks."
-- URL:http://groups.google.com/groups?selm=85oboh%24bac%241%40nntp9.atl.mindspring.net

Anyone else want to have a swing?

 URL:http://www.cs.utexas.edu/users/EWD/advancedSearch.html

--
Joe Foster <mailto:jlfoster%40znet.com>     On the cans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Gerry Quinn wrote:
> 
> In article <1076892760.497303@news-1.nethere.net>, "Joe \"Nuke Me Xemu\" Foster" <jlf%40znet%2ecom> wrote:
> >
> >FWIW, EWD may have softened his stance on OOP over time, if one
> >can accept the concept of 'praising with faint damnation'.  =)
> >Scroll down to section 21, but the rest is also interesting:
> >
> > URL:http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html
> 
> <BEGIN QUOTE>
> >After more than 45 years in the field, I am still convinced that in computing,
> >elegance is not a dispensable luxury but a quality that decides between
> >success and failure; in this connection I gratefully quote from The Concise
> >Oxford Dictionary a definition of "elegant", viz. "ingeniously simple and
> >effective". Amen. (For those who have wondered: I don't think
> >object-oriented programming is a structuring paradigm that meets my
> >standards of elegance.)
> <END QUOTE>
> 
> Well, he sounds like somebody who knows he is wrong, but won't admit it.
> 
> - Gerry Quinn

Both Djikstra and Knuth principally object to OOP because they were of a
generation which had not apandoned the concept of proof of correctness.

They could not see how OOP provides anything which closes the gap 
with POC. 

Knuth in his Byte interview states this, and it's inferred from various
of Djikstra's writings. 

One forgets that in history, there are both prophets and generals. 
Djikstra was more the former. 

--
Les Cargill

In article <1076986667.82663@news-1.nethere.net>, "Joe \"Nuke Me Xemu\" Foster" <jlf%40znet%2ecom> wrote:
>"Gerry Quinn" <gerryq@indigo.ie> wrote in message

>> > URL:http://cuj.com/documents/s=8042/cuj0002meyers/
>>
>> Meyers understands neither object orientation nor encapsulation.  I
>> refer you to the thread from August 2002:
>> http//groupsgooglecom/groupsas_q=Meyer%20encapsulation
>> &safe=images&ie=ISO-8859-1&as_uauthors=gerryq@indigo.ie
>> &lr=&hl=en
>> .in which I comprehensively demolish the nonsensical concepts he
>> presents.
>
>Provide a Sleep( Wombat& , double ) which calls wombat.Sleep( double ).
>End of inconsistency, but the illusion of data and code being 'bound
>together' is shattered.  Oh well!  However, the Java/C++ way isn't the
>only way.  A language could treat functions and methods as equivalent,
>so if the parser encounters wombat.Nap() but wombat has no Nap method,
>it looks for an ordinary function like Nap( Wombat& ).  If that fails,
>it could look for Nap( Mammal& ), Nap( Vertebrate& ), Nap( Animal& ),
>etc. etc. etc. ...

Somebody came up with that idea on the thread.  I think it being a bad 
idea was the only thing all participants eventually agreed on!

>> As for "the panacea its evangelists still claim it to be" it is well
>> known that there is no silver bullet in software, so that argument is a
>> straw horse.
>
>Not entirely.  Quite a few OO evangelists have gotten carried away.
>
> URL:http://softpanorama.org/SE/anti_oo.shtml

Oh, the evangelists exist!  The silver bulet doesn't, though...

- Gerry Quinn

In article <4031CF4D.BA964485@worldnet.att.net>, Les Cargill <lcargill@worldnet.att.net> wrote:
>
>Both Djikstra and Knuth principally object to OOP because they were of a
>generation which had not apandoned the concept of proof of correctness.
>
>They could not see how OOP provides anything which closes the gap 
>with POC. 
>
>Knuth in his Byte interview states this, and it's inferred from various
>of Djikstra's writings. 

That seems plausible.

- Gerry Quinn

In article <gn4330lqibqeqakv0loqahjf0ntjp7bs6d@4ax.com>, olczyk2002@yahoo.com wrote:
>On Sat, 14 Feb 2004 12:08:01 GMT, gerryq@indigo.ie (Gerry Quinn)
>wrote:
>
>>Dijkstra seems incredibly overrated.  As far as I can see he is famous 
>>for (a) a trivial pathfinding algorithm that must have been re-invented 
>>hundreds of times, and (b) a bunch of stupidly aggressive and 
>>wrong-headed comments, such as the above about OO, and the stupidity 
>>about Basic (which I interpret as meaning he was a crap teacher too).
>>
>He has three main claims to fame:
>1) He basically invented a large structured programming ( goto
>considered...).
>2) He invented semaphores.
>3) He brought a mathematical rigor to programming.

There was something about Algol too - I did in fact look up his 
biography.  It's his usenet 'eidolon' that has become pernicious, I 
think...

- Gerry Quinn 

Joe \"Nuke Me Xemu\" Foster wrote:

> Not entirely.  Quite a few OO evangelists have gotten carried away.
> 
>  URL:http://softpanorama.org/SE/anti_oo.shtml

Worth reading....

	"OOP is more of a program organizational philosophy rather
	 than a set of new external solutions or operations."

'Swhat I've been saying for years!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

> > >>>  Do you also
> > >>> agree with Dijkstra about object orientation?
> > >>> "Object-oriented programming is an exceptionally bad idea that
> > >>> could only have been invented in California."
> > >>> http://quote.wikipedia.org/wiki/Edsger_Dijkstra

While I like Dijkstra for his eventual realization and then emphasis on
abstraction as central to software engineering, this quote shows an obvious
lack in his knowledge.

Dijkstra is clearly unaware that OO began with Dahl & Nygaard in Norway and
Dijkstra is unaware of the history leading up to that Norwegian start of OO.
Perhaps if Dijkstra knew of the factors that motivated Dahl & Nygaard and
what OO essentially meant to them, perhaps Dijkstra would not have been so
"down" on OO.

Given that Dijkstra came to understand the centrality of skillful domain and
requirements entity decomposition leading to effective abstractions in
programming, Dijkstra may have been more positive toward OO if he knew that
better modelling using collaborating object abstractions to reduce
complexity was the key motivation for Dahl & Nygaard.

Elliott
--
Enumerative (quantitative; metric) reasoning is only an
adequate mental tool under the severe boundary condition
that we only use it very moderately. We should appreciate
abstraction (qualitative thinking) as our main mental technique
to reduce the demands made upon enumerative reasoning."
~ EW Dijkstra

Joe \"Nuke Me Xemu\" Foster wrote:

> ----Class Adder----
> Private K As Double
> 
> Friend Sub Init(ByVal NewK As Double)
>   K = NewK
> End Sub

Curiosity: why the Friend declaration for Init()?

And you might want to submit your code to Paul Graham's site
for the "Accumulator Generator" page (although there is a VBScript
example that's pretty similar).

	http://www.paulgraham.com/accgen.html

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Universe" <universe@tAkEcovadOuT.net> wrote in message <news:435c4$4032690f$97cff003$28425@msgid.meganewsservers.com>...

> > > >>>  Do you also
> > > >>> agree with Dijkstra about object orientation?
> > > >>> "Object-oriented programming is an exceptionally bad idea that
> > > >>> could only have been invented in California."
> > > >>> http://quote.wikipedia.org/wiki/Edsger_Dijkstra
>
> While I like Dijkstra for his eventual realization and then emphasis on
> abstraction as central to software engineering, this quote shows an obvious
> lack in his knowledge.
>
> Dijkstra is clearly unaware that OO began with Dahl & Nygaard in Norway and
> Dijkstra is unaware of the history leading up to that Norwegian start of OO.

Did OO really start with SIMULA?  URL:http://ootips.org/history.html

> Perhaps if Dijkstra knew of the factors that motivated Dahl & Nygaard and
> what OO essentially meant to them, perhaps Dijkstra would not have been so
> "down" on OO.

Didn't Alan Kay, a Californian, coin the term "object-oriented programming"?

 URL:http://www.hp.com/hpinfo/newsroom/feature_stories/2002/alankaybio.html

 URL:http://userpage.fu-berlin.de/~ram/pub/pub_frscm4/doc_kay_oop_en

> Given that Dijkstra came to understand the centrality of skillful domain and
> requirements entity decomposition leading to effective abstractions in
> programming, Dijkstra may have been more positive toward OO if he knew that
> better modelling using collaborating object abstractions to reduce
> complexity was the key motivation for Dahl & Nygaard.

And thirty years wasn't enough time for Edsger Dijkstra to learn this?
His last jab at OOP that I found was written in 1999.

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:1077046925.835514@news-1.nethere.net...
> "Universe" <universe@tAkEcovadOuT.net> wrote in message
<news:435c4$4032690f$97cff003$28425@msgid.meganewsservers.com>...
>
> > > > >>>  Do you also
> > > > >>> agree with Dijkstra about object orientation?
> > > > >>> "Object-oriented programming is an exceptionally bad idea that
> > > > >>> could only have been invented in California."
> > > > >>> http://quote.wikipedia.org/wiki/Edsger_Dijkstra
> >
> > While I like Dijkstra for his eventual realization and then emphasis on
> > abstraction as central to software engineering, this quote shows an
obvious
> > lack in his knowledge.
> >
> > Dijkstra is clearly unaware that OO began with Dahl & Nygaard in Norway
and
> > Dijkstra is unaware of the history leading up to that Norwegian start of
OO.
>
> Did OO really start with SIMULA?  URL:http://ootips.org/history.html

Patrick Logan, the first one listed in the listing of comp.object.moderated
discussion your url refers to, is a hardcore XP type.  And it is well known
that the "pragmatism" of the XP, downplays and with RCM denies any
relationship between modelling collaborating domain entities as
collaborating object/class abstractions and OO in software engineering.

Yet, it was that kind of logical simulationist object modelling that Dahl
and Nygaard used to reduce complexity with Simula in '67.

Elliott
--
Madsen helped to create Beta the successor the 1st OOPL Simula
with Nygaard.  Madsen continues to write the simulationist, centered
truth about OO.  He continues to draw the line in the sand for
genuine, domain modelling oriented, OO software science and
engineering against the establishment, maximum ROI oriented,
anti-simulationist, pragmatism philosophy based, faux OO, as
represented by XP/Alliance.  His site:
http://www.daimi.au.dk/~olm/

"Programmer Dude" <Chris@Sonnack.com> wrote in message <news:40326E66.C80CF11E@Sonnack.com>...

> Joe \"Nuke Me Xemu\" Foster wrote:
>
> > ----Class Adder----
> > Private K As Double
> >
> > Friend Sub Init(ByVal NewK As Double)
> >   K = NewK
> > End Sub
>
> Curiosity: why the Friend declaration for Init()?

I'll do that with methods that aren't for client use, even if the
class isn't marked Public inside an ActiveX component.  It's just
something that bites me worse when I forget to do it when I should
than if I do it anyway even when it shouldn't matter.

> And you might want to submit your code to Paul Graham's site
> for the "Accumulator Generator" page (although there is a VBScript
> example that's pretty similar).
>
> http://www.paulgraham.com/accgen.html

Once I make the changes needed to solve the stated problem, it'll
be even /more/ similar to the VBScript example.  Are the esolang
folks aware of that page, though?  >=)

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Universe" <universe@tAkEcovadOuT.net> wrote in message <news:c5f3$40327460$97cff003$29183@msgid.meganewsservers.com>...

> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
> news:1077046925.835514@news-1.nethere.net...

> > Did OO really start with SIMULA?  URL:http://ootips.org/history.html
>
> Patrick Logan, the first one listed in the listing of comp.object.moderated
> discussion your url refers to, is a hardcore XP type.  And it is well known
> that the "pragmatism" of the XP, downplays and with RCM denies any
> relationship between modelling collaborating domain entities as
> collaborating object/class abstractions and OO in software engineering.
>
> Yet, it was that kind of logical simulationist object modelling that Dahl
> and Nygaard used to reduce complexity with Simula in '67.

However, Alan Kay talks about Sketchpad and a Burroughs OS as
proto-OO systems that predate SIMULA.  Is Alan Kay one of the
demonic horde of evil hardcore XP 'pragmatists' as well?

 URL:http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html#4

--
Joe Foster <mailto:jlfoster%40znet.com>  KrazyKookKultz! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote in message news:<1076944899.255108@news-1.nethere.net>...
> > Well, he sounds like somebody who knows he is wrong, but won't admit it.
> 
> You have to admit that OOP turned out to hardly be the panacea its
> evangelists still claim it to be,

It is true that OOP is not a panacea, but its inventors never claimed
it was.  OO languages (especially Smalltalk) do contribute some useful
ideas to the world of programming.  OTOH I think we have lingered too
long on the plains of OO.  It's a 30 year old idea, and hardly
deserves to be considered cutting edge anymore.  We need a few new
words to think with.

> what with the "fragile base class"
> problem and the way both inheritance and methods break encapsulation:

An OO language can be designed to prevent direct access to variables,
and it would still be an OO language.  Also, if developers would
simply use a little discipline and always use accessor methods instead
of writing code that directly accessed variables, this would be a much
less troublesome thing.  I've worked with people who shrug it off when
I mention that directly accessing variables is a bad practice.  Oh
well.

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

"Programmer Dude" <Chris@Sonnack.com> wrote in message
news:40323787.7A2A3426@Sonnack.com...
> Joe \"Nuke Me Xemu\" Foster wrote:
>
> > Not entirely.  Quite a few OO evangelists have gotten carried away.
> >
> >  URL:http://softpanorama.org/SE/anti_oo.shtml
>
> Worth reading....
>
> "OOP is more of a program organizational philosophy rather
> than a set of new external solutions or operations."
>

One can also think of OOP as, among things, a paradigm with support for the
development of asynchronous message passing distributed systems.  I
personally believe that as the internet becomes even more ubiquitous, this
model will also become increasingly important as it fits so perfectly with
the realities of distributed network based computing.

> 'Swhat I've been saying for years!
>

"OOP in itself does NOT allow programs to do things that they could not do
before."

Well this is obvious.  Are you saying there were people arguing OO programs
were super-Turing?  If so, I agree those authors don't know what they're
talking about.

---

"One of these ideals was central control and planning of the economy.
Duplication and coordination of production would eliminate wasteful,
redundant procedures; thus increasing the overall wealth.
A watchful, central eye would also keep people in line so that they would
produce only what was deemed useful and fair."

What is this 'central' eye?  This implies the existence of entity that has
access to the internal state of the entire system.  In fact, stuctured
languages seem to fit the analogy better than OOPLs (if I'm inteerpreting
this right).  To say mainstream OOA/D does not suggest that one write
programs with entities like this is an understatement.

---

"OOP has a similar appeal. Data and operations (methods) are tightly
integrated and controlled within the watchful eye of the OO paradigm."

What does he mean by 'under the eye of the paradigm'?  That sounds pretty
vague.  Also, I think if you consider, in partcular, design patterns, one
can see that often the most popular OO designs are taken from the
successfull solutions of common problems found in actual implementations in
a variety of settings.  Also, every language contains infrastructure that
supports the paradigm, if thats what this means.  But I would hazard to say
that there is no such thing as a paradigmless language.

---

"It simply has it's rules and regulations and follows them like a good
little bureaucratic soldier."

They are called method signatures, if I'm understanding the analogy.  An
object method, or C function etc..., has a list of required input(s).  In
the case that, for example, the particlar choice of the first two arguments
in a three argument function makes the third argument unneccesary, the
calling object must still provide that argument (given that having the
caller determinine whether that situation was true before calling, would not
be practical).  Perhaps I've misunderstood the intent, but if I'm correct,
is there a proposed solution the author has in mind?

---

Without going over every point, I think that they are trying to debunk the
OO-fanatics, not the more 'sane' proponents of OO.

<gush mode = "on">
By the way, if you haven't already, you might want to check out AOP as a
possible solution to some of the problems with OO mentioned.  As a
technology, its "still in the lab", but at first glance it seems like a
logical next step in language infrastructure.  It makes it possible to write
generic services (like security, validation, performance analysis,...) that
classes of possibilily unrelated class hierarchies can all transparently
make use of - ie: without the need to explicitly add service-supporting API
calls, like calls to a security API for example.  It supports the
development of domain-specific run-time containers in which domain objects
need only contain business logic since they are (if things go right)
obsolved of any system level concerns.  It makes the development of truly
service oriented architectures much easier to implement.
<gush mode = "off">

(However, I'm interested in hearing anyone with practical experience
implementing a non-trivial AOP based solution (good or bad).  At this point
this is probably a small group though.)



l8r, Mike N. Christoff

"Michael N. Christoff" wrote:

>> "OOP is more of a program organizational philosophy rather
>> than a set of new external solutions or operations."
> 
> One can also think of OOP as, among things, a paradigm with support
> for the development of asynchronous message passing distributed
> systems.  I personally believe that as the internet becomes even
> more ubiquitous, this model will also become increasingly important
> as it fits so perfectly with the realities of distributed network
> based computing.

I'd agree the model is important, but I'm not sure I'd apply the
*program* *design* method, named OOP, to such a high level.  I
see what you're saying, but I think I'd never choose to use that
terminology in that area.

>> 'Swhat I've been saying for years!
> 
> "OOP in itself does NOT allow programs to do things that they
> could not do before."
> 
> Well this is obvious.

[grin] Well, sometimes the obvious does need stating.  Sometimes
just to make sure we're all on the same wavelength, sometimes
because--saddly--it really needs to be.  :-\

> Are you saying there were people arguing OO programs were
> super-Turing?

(Why ask me?! Not my website!!  :-)  Well, I can guess he means
how some folks thought OOP would greatly simply program construction
or make the world wonderful through code reuse or reduce errors or
whatevertheclaim.

> "One of these ideals was central control and planning of the economy.
> [...]  A watchful, central eye would also keep people in line so
> that they would produce only what was deemed useful and fair."
> 
> What is this 'central' eye?  This implies the existence of entity
> that has access to the internal state of the entire system.  In
> fact, stuctured languages seem to fit the analogy better than OOPLs
> (if I'm inteerpreting this right).

You're not.  The author is speaking of Communism at that point.
As the next paragraph goes on to say (EMPH mine):

> "OOP has a *SIMILAR* appeal. Data and operations (methods) are
> tightly integrated and controlled within the watchful eye of
> the OO paradigm."
>
> What does he mean by 'under the eye of the paradigm'?  That sounds
> pretty vague.

Or even BS-ish.  Yeah, I though so, too.  I think it's a fancy way
of saying OOP (tightly) integrates data and code.

> Also, every language contains infrastructure that supports the
> paradigm, if thats what this means.  But I would hazard to say
> that there is no such thing as a paradigmless language.

Agreed.  But some languages are more flexible in supporting different
styles of programming.  C, for example, can be used in an OOP-ish
way or a Functional way or a procedural way.  Then consider something
like Java.  I recall my amusement at learning Main had to be a class.

> "It simply has it's rules and regulations and follows them like a
> good little bureaucratic soldier."
> 
> They are called method signatures, if I'm understanding the analogy.

The author *might* be referring to entire class designs (interfaces)
rather than individual methods.  (But who knows!)

> Perhaps I've misunderstood the intent, but if I'm correct,
> is there a proposed solution the author has in mind?

Seems to be just recognizing that OOP isn't the Alpha And Omega,
I guess.  The whole thing seems a reactionary testiment to the
hype of OOP.  You seem to get the same sense:

> Without going over every point, I think that they are trying to
> debunk the OO-fanatics, not the more 'sane' proponents of OO.


> <gush mode = "on">
> By the way, if you haven't already, you might want to check out AOP
> as a possible solution to some of the problems with OO mentioned.
> As a technology, its "still in the lab",...

I'm aware of it and have read (skimmed, actually) a couple articles
about it.  The Luddite in me is content to wait until it gets out
of the lab and can be had cheap at Best Buy...  (-:

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"MSCHAEF.COM" wrote:

> Yeah, it was just the idea of using an object model to drive all
> that formatting information into Word.  I'm just envisioning a
> never ending stream of insert_this_text, select_bold,
> select_underline, insert_some_more_text, unselect_bold,
> make_a_2_by_2_table... and on and on.
> 
> That seems like a really tedious way to do procedurally the kind
> of thing that comes more naturally in markup.

I'm not sure markup alone could do all the things that Word can do
(and which you can do programmatically via COM).  Given a situation
where you create the document from scratch,... well, it's just a lot
of "never ending" stuff anyway!  (-:

> I dunno though, maybe Word's object model makes it trivial.

You tell me.  Here's a complete package from a package old enough
that I can share it publically.  (Would be much shorter if all the
error-handling stuff were removed.)

It creates a (if I do say so myself) VERY nicely formatted letter
complete with ruled lines and other "professional look" features.
There's a test routine at the very bottom demonstrating the usage.

Um,... maybe you should stand back a bit.  This is kinda long....

'*********************************************************************
'*********************************************************************
Public Type LetterInfo
    Contact As String
    Manager As String
    DateNotified As Date
    NUContact As String
    IncidentDetail As String
    Investigator As String
    RootCauseDetail As String
    CorrActionDetail As String
    ManagerPhone As String
End Type

'*********************************************************************
' MS WORD LETTER
'*********************************************************************
Public Sub MS_Word_Letter(ltr As LetterInfo)
Dim wordApp As Word.Application
Dim myDoc As Word.Document
Dim pp As Word.Paragraph
Dim s As String
Dim k1 As Long, k2 As Long
    
    ' START MS-WORD...
    On Error GoTo ERR_APP
    Set wordApp = CreateObject("Word.Application")
    ' CREATE NEW DOCUMENT....
    On Error GoTo ERR_DOC
    Set myDoc = wordApp.Documents.Add
    '
    ' GENERATE DOCUMENT CONTENTS...
    On Error GoTo ERR_WRITE
    With myDoc.Paragraphs
        .Alignment = wdAlignParagraphLeft
        .LeftIndent = 0
        .RightIndent = 0
        Call .Space15
        Call .TabStops.ClearAll
    End With
    
    ' Heading...
    s = vbTab & "To: " & vbTab & ltr.Contact & vbCrLf _
      & vbTab & "From: " & vbTab & ltr.Manager & vbCrLf _
      & vbTab & "Subject: " & vbTab & "Customer Satisfaction Opportunity" & vbCrLf _
      & vbTab & "Date: " & vbTab & Format$(Now(), "mmmm d, yyyy")
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = s & vbCrLf
        .Font.Name = "Arial"
        .Font.Size = 10
        .Font.Underline = wdUnderlineNone
        .Paragraphs.Space1
        .Paragraphs.TabStops.Add InchesToPoints(0.5), wdAlignTabRight
        .Paragraphs.TabStops.Add InchesToPoints(0.6), wdAlignTabLeft
    End With
    ' "3M"
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = "3" & vbCrLf
        .Font.Name = "Logo3Mv3tt"
        .Font.Size = 36
        .Paragraphs.Alignment = wdAlignParagraphRight
        .Paragraphs.Space1
        .Paragraphs.TabStops.Add InchesToPoints(6#), wdAlignTabRight
    End With
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = "_" & vbTab & "_" & vbCrLf
        .Font.Name = "Arial"
        .Font.Size = 12
        .Font.Bold = True
        .Font.Underline = wdUnderlineThick
        .Paragraphs.Alignment = wdAlignParagraphJustify
        .Paragraphs.Space1
        .Paragraphs.TabStops.Add InchesToPoints(6#), wdAlignTabLeft
    End With
    
    ' "On [NotifyDate] [NUContact] alerted us that..."
    s = "On " & Format$(ltr.DateNotified, "mm/dd/yy") & " " _
      & ltr.NUContact & " alerted us that there was the following concern:"
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = s & vbCrLf
        .Font.Name = "Times New Roman"
        .Font.Size = 12
        .Paragraphs.SpaceBefore = 12
        .Paragraphs.SpaceAfter = 6
    End With
    ' Incident Detail...
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = ltr.IncidentDetail & vbCrLf
        .Font.Name = "Arial"
        .Font.Size = 12
        .Paragraphs.LeftIndent = 16
        .Paragraphs.RightIndent = 16
        .Paragraphs.Space1
        .Paragraphs.SpaceAfter = 12
    End With
    
    ' "[Investigator] investigated this concern and..."
    s = ltr.Investigator & " investigated this concern and has" _
      & " identified the following cause:"
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = s & vbCrLf
        .Font.Name = "Times New Roman"
        .Font.Size = 12
        .Paragraphs.SpaceBefore = 12
        .Paragraphs.SpaceAfter = 6
    End With
    ' Root Cause Detail...
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = ltr.RootCauseDetail & vbCrLf
        .Font.Name = "Arial"
        .Font.Size = 12
        .Paragraphs.LeftIndent = 16
        .Paragraphs.RightIndent = 16
        .Paragraphs.Space1
        .Paragraphs.SpaceAfter = 12
    End With
    
    ' "To resolve this problem we will..."
    s = "To resolve this problem we will be implementing the following" _
      & " corrective action:"
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = s & vbCrLf
        .Font.Name = "Times New Roman"
        .Font.Size = 12
        .Paragraphs.SpaceBefore = 12
        .Paragraphs.SpaceAfter = 6
    End With
    ' Corrective Action Detail...
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = ltr.CorrActionDetail & vbCrLf
        .Font.Name = "Arial"
        .Font.Size = 12
        .Font.Bold = False
        .Paragraphs.LeftIndent = 16
        .Paragraphs.RightIndent = 16
        .Paragraphs.Space1
        .Paragraphs.SpaceAfter = 12
    End With
    
    ' "We are committed..."
    s = "We are committed to removing the root cause of this problem." _
      & " If the corrective action listed above does not solve the problem," _
      & " we will continue our investigation until the real cause is" _
      & " identified and removed." & vbCrLf _
      & "Thank you for bringing this improvement opportunity to our attention." _
      & " If you have any questions, please call me on " & ltr.ManagerPhone
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = s & vbCrLf
        .Font.Name = "Times New Roman"
        .Font.Size = 12
        .Paragraphs.SpaceBefore = 12
    End With
    
    ' "Sincerely,..."
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = "Sincerely," & vbCrLf
        .Font.Name = "Times New Roman"
        .Font.Size = 12
        .Font.Italic = True
        .Paragraphs.SpaceBefore = 36
    End With
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = ltr.Manager & vbCrLf
        .Font.Name = "Times New Roman"
        .Font.Size = 12
        .Paragraphs.SpaceBefore = 24
        .Paragraphs.SpaceAfter = 12
    End With
    
    ' "dc:"
    s = vbTab & "dc:" & vbTab & ltr.NUContact & vbCrLf _
      & vbTab & vbTab & ltr.Investigator & vbCrLf _
      & vbTab & vbTab & "Steve Spilman"
    Set pp = myDoc.Paragraphs.Add
    With pp.Range
        .Text = s & vbCrLf
        .Font.Name = "Arial"
        .Font.Size = 8
        .Font.Bold = False
        .Font.Underline = wdUnderlineNone
        .Paragraphs.Space1
        .Paragraphs.TabStops.Add InchesToPoints(0.2), wdAlignTabRight
        .Paragraphs.TabStops.Add InchesToPoints(0.3), wdAlignTabLeft
    End With
    
    ' SAVE DOCUMENT...
    On Error GoTo ERR_SAVE
    Call myDoc.SaveAs(filename:="C:\......\LookyHere.doc", AddToRecentFiles:=True)
    Print "paragraphs="; CStr(myDoc.Paragraphs.Count)
    wordApp.Visible = True
    MsgBox "[OK] to continue... (closes Word)"
ERROR_EXIT:
    ' CLOSE DOCUMENT...
    On Error Resume Next
    Call myDoc.Close(wdDoNotSaveChanges, wdWordDocument)
EXIT_DOC:
    ' QUIT MS-WORD...
    On Error Resume Next
    Call wordApp.Quit(wdDoNotSaveChanges, wdWordDocument)
EXIT_APP:
    'CLEAN UP & EXIT...
    On Error Resume Next
    Set myDoc = Nothing
    Set wordApp = Nothing
    Exit Sub
'''''''''''''''''' ERROR HANDLERS ''''''''''''''''''''''''''''''''''
ERR_SAVE:
    Call MsgBox(Err.Description, vbCritical)
    Resume ERROR_EXIT
ERR_WRITE:
    Call MsgBox(Err.Description, vbCritical)
    If MsgBox("Save unfinished document?", vbQuestion + vbYesNo) = vbYes Then
        Call myDoc.Close(wdSaveChanges, wdWordDocument)
    End If
    Resume EXIT_DOC
ERR_DOC:
    Call MsgBox(Err.Description, vbCritical)
    Resume EXIT_DOC
ERR_APP:
    Call MsgBox(Err.Description, vbCritical)
    Resume EXIT_APP
End Sub
'*******************************************************************
Public Sub MS_Word_Letter_Test()
    With yourLetter
        .Contact = "Vicky Jensen"
        .Manager = "Norm Smythe"
        .DateNotified = CDate("05/28/97")
        .NUContact = "Peggy Gohr"
        .IncidentDetail = "Bad fiber convertor PCB.  S/N 1946"
        .Investigator = "Ken Rolloff"
        .RootCauseDetail = "Board was not returned for evaluation.  Suspect shipping damage."
        .CorrActionDetail = "None at this time."
        .ManagerPhone = "xxx-xxxx"
    End With
    Call MS_Word_Letter(yourLetter)
End Sub


-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

In article <40328EB2.2CC4B5D6@Sonnack.com>,
Programmer Dude  <Chris@Sonnack.com> wrote:
>"MSCHAEF.COM" wrote:
   ...
>> That seems like a really tedious way to do procedurally the kind
>> of thing that comes more naturally in markup.
>
>I'm not sure markup alone could do all the things that Word can do
>(and which you can do programmatically via COM).

Don't get me wrong, I'm not claiming that markup is the solution, just 
that it covers part of the problem easier than calls into an object model.
As you point out, the reverse is true also.

I'm actually somewhat a fan of ASP's model of integrating code and markup 
together. I think it does a pretty good job of saying "this source file 
produces a document that looks like this" while making it easy to bring in 
dynamic content sourced from behind the scenes code.

>You tell me.  Here's a complete package from a package old enough
>that I can share it publically.

Grazie.

>    ' Heading...
>    s = vbTab & "To: " & vbTab & ltr.Contact & vbCrLf _
>      & vbTab & "From: " & vbTab & ltr.Manager & vbCrLf _
>      & vbTab & "Subject: " & vbTab & "Customer Satisfaction
>Opportunity" & vbCrLf _
>      & vbTab & "Date: " & vbTab & Format$(Now(), "mmmm d, yyyy")
>    Set pp = myDoc.Paragraphs.Add
>    With pp.Range
>        .Text = s & vbCrLf
>        .Font.Name = "Arial"
>        .Font.Size = 10
>        .Font.Underline = wdUnderlineNone
>        .Paragraphs.Space1
>        .Paragraphs.TabStops.Add InchesToPoints(0.5), wdAlignTabRight
>        .Paragraphs.TabStops.Add InchesToPoints(0.6), wdAlignTabLeft
>    End With

This is the kind of thing I was talking about. It really reminds me of the 
Perl-CGI code I've written that spends a lot of time in output statements. 
While it works, it embedds the document text in a bunch of code and the 
formatting behind a bunch of assignment statements in an object model. 

Just out of curiosity: how easy is it for you to modify such a auto 
generated document? What kind of prototyping process can you use? Some 
type of macro that would take a document and generate VB object model code 
to recreate that document (perhaps with tags for where the code needs to
bring in variables) seems like it might be pretty useful.

-Mike


-- 
http://www.mschaef.com

"Programmer Dude" <Chris@Sonnack.com> wrote in message
news:40328A0A.71A990CB@Sonnack.com...
> "Michael N. Christoff" wrote:
>
> >> "OOP is more of a program organizational philosophy rather
> >> than a set of new external solutions or operations."
> >
> > One can also think of OOP as, among things, a paradigm with support
> > for the development of asynchronous message passing distributed
> > systems.  I personally believe that as the internet becomes even
> > more ubiquitous, this model will also become increasingly important
> > as it fits so perfectly with the realities of distributed network
> > based computing.
>
> I'd agree the model is important, but I'm not sure I'd apply the
> *program* *design* method, named OOP, to such a high level.  I
> see what you're saying, but I think I'd never choose to use that
> terminology in that area.
>

I assume by "OOP program design method" you mean OOA/D (object oriented
analysis and design).  I've always understood OOA/D as the process of
developing systems in which computation is achieved through the
collaboration of autonomous processes with encasulated internal state.
Anyways, I think saying that OOP (most prominently the class\object concept,
encapsulation and interfaces) is well suited to implementing distributed
systems is different from saying OOA/D = distributed computing.  However, I
must admit, I find the similarities both stricking and numerous.

> >> 'Swhat I've been saying for years!
> >
> > "OOP in itself does NOT allow programs to do things that they
> > could not do before."
> >
> > Well this is obvious.
>
> [grin] Well, sometimes the obvious does need stating.  Sometimes
> just to make sure we're all on the same wavelength, sometimes
> because--saddly--it really needs to be.  :-\
>
> > Are you saying there were people arguing OO programs were
> > super-Turing?
>
> (Why ask me?! Not my website!!  :-)  Well, I can guess he means
> how some folks thought OOP would greatly simply program construction
> or make the world wonderful through code reuse or reduce errors or
> whatevertheclaim.
>

Sorry.  I thought you implied you agreed with what this guy was saying.

> > "One of these ideals was central control and planning of the economy.
> > [...]  A watchful, central eye would also keep people in line so
> > that they would produce only what was deemed useful and fair."
> >
> > What is this 'central' eye?  This implies the existence of entity
> > that has access to the internal state of the entire system.  In
> > fact, stuctured languages seem to fit the analogy better than OOPLs
> > (if I'm inteerpreting this right).
>
> You're not.  The author is speaking of Communism at that point.
> As the next paragraph goes on to say (EMPH mine):
>
> > "OOP has a *SIMILAR* appeal. Data and operations (methods) are
> > tightly integrated and controlled within the watchful eye of
> > the OO paradigm."
> >
> > What does he mean by 'under the eye of the paradigm'?  That sounds
> > pretty vague.
>
> Or even BS-ish.  Yeah, I though so, too.  I think it's a fancy way
> of saying OOP (tightly) integrates data and code.
>
> > Also, every language contains infrastructure that supports the
> > paradigm, if thats what this means.  But I would hazard to say
> > that there is no such thing as a paradigmless language.
>
> Agreed.  But some languages are more flexible in supporting different
> styles of programming.  C, for example, can be used in an OOP-ish
> way or a Functional way or a procedural way.  Then consider something
> like Java.  I recall my amusement at learning Main had to be a class.
>

True.  There are 'multi-paradigm' languages like C++.  However it is
notoriously difficult to design multi-paradigm languages that don't have
'language infrastructure overload'.  I'm not naming names. :)

> > "It simply has it's rules and regulations and follows them like a
> > good little bureaucratic soldier."
> >
> > They are called method signatures, if I'm understanding the analogy.
>
> The author *might* be referring to entire class designs (interfaces)
> rather than individual methods.  (But who knows!)
>
> > Perhaps I've misunderstood the intent, but if I'm correct,
> > is there a proposed solution the author has in mind?
>
> Seems to be just recognizing that OOP isn't the Alpha And Omega,
> I guess.  The whole thing seems a reactionary testiment to the
> hype of OOP.  You seem to get the same sense:
>
> > Without going over every point, I think that they are trying to
> > debunk the OO-fanatics, not the more 'sane' proponents of OO.
>
>
> > <gush mode = "on">
> > By the way, if you haven't already, you might want to check out AOP
> > as a possible solution to some of the problems with OO mentioned.
> > As a technology, its "still in the lab",...
>
> I'm aware of it and have read (skimmed, actually) a couple articles
> about it.  The Luddite in me is content to wait until it gets out
> of the lab and can be had cheap at Best Buy...  (-:
>

Although I'll be personally investing time in learning AOP, the above makes
a lot of practical sense.



l8r, Mike N. Christoff

"MSCHAEF.COM" wrote:

> I'm actually somewhat a fan of ASP's model of integrating code and
> markup together. I think it does a pretty good job of saying "this
> source file produces a document that looks like this" while making
> it easy to bring in dynamic content sourced from behind the scenes
> code.

I'm not familiar with it in this context.  Care to share an e.g.?

> Grazie.

Da nada.  (-:

>> [snip]
> 
> This is the kind of thing I was talking about. [...] While it works,
> it embedds the document text in a bunch of code and the  formatting
> behind a bunch of assignment statements in an object model.

A fair point.  If I needed to create a series of documents, I might
use an approach that tries to automate much of that (e.g. I do have
an Excel "creator" that takes any ADO Recordset as input and makes
a spreadsheet--including column headers and some formatting--from
the data).

But, at some point, you need to say, 'this bit here has these
attributes (and there can be a lot of attributes in highly formatted
text--fontname, fontsize, fontstyle, forecolor, backcolor, line
spacing, indenting,...blah, blah, blah).  If not with a bunch of
assignments, then how?

> Just out of curiosity: how easy is it for you to modify such a
> auto generated document?

Define "modify"!  Make small changes, very.  Medium changes, depends
on the nature of the change--some are easy if they keep the basic
structure.  Big changes to the structure--better to start fresh.

> What kind of prototyping process can you use?

I create the document in Word until it looks "perfect".  Then it's
just a matter of making all those assignments for each piece.  If
you have a good understanding of how Word represents text, it's
actually pretty easy.

> Some type of macro that would take a document and generate VB
> object model code to recreate that document...

Ish.  I'm **far** too anal to allow software to generate my code!

(But it would actually be sort of a fun project.  Something I've
had on the back burner for years is a VB app to do a "listing" of
a Word (or Excel or Powerpoint) document.  Given the design of the
Word object model, it wouldn't be that hard.)

> (perhaps with tags for where the code needs to
> bring in variables) seems like it might be pretty useful.

So now you want an IDE to design Word documents?..  (-:

I think it took me less than a day to design and implement four
(rather complex) Word documents from scratch, so I don't think I
consider it a task that needs massive improvements.

Another tactic would be to use templates with fields and do a
sort of "mail merge" to insert the necessary data.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

In article <40329954.2F1EEEE1@Sonnack.com>,
Programmer Dude  <Chris@Sonnack.com> wrote:
>"MSCHAEF.COM" wrote:
  ...
>I'm not familiar with it [ASP] in this context.  Care to share an e.g.?

I'm pretty sure ASP can't be used, as is, for generating Word documents. 
I just like the model it uses for document production in general.

Now that Word has an XML schema for its documents, I guess it's 
increasingly possible to use more markup oriented tools to produce
these kinds of documents. 
 
>But, at some point, you need to say, 'this bit here has these
>attributes (and there can be a lot of attributes in highly formatted
>text--fontname, fontsize, fontstyle, forecolor, backcolor, line
>spacing, indenting,...blah, blah, blah).  If not with a bunch of 
>assignments, then how?

Maybe stylesheets? I guess the Word object model has decent support for 
defining and using stylesheets? In general, I think you're right: you 
can't avoid the use of assignments into the object model to format text. 
All you can do is make those assignments have more meaning. (As a style 
assignment would represent a bunch of individual attributes in one 
assignment statement, etc.)

>Ish.  I'm **far** too anal to allow software to generate my code!

In the general case, so am I. That said, for boilerplate coding (data 
translation layers, etc.), I find that I'm too anal to do it by hand. :-)

>(But it would actually be sort of a fun project.  Something I've
>had on the back burner for years is a VB app to do a "listing" of
>a Word (or Excel or Powerpoint) document.  Given the design of the

That would be fun. Have you seen the "Reveal Formatting" options in new 
versions of Word? For solving complicated formatting problems, it's about 
the best piece of MS UI work I've seen in some time...


>> (perhaps with tags for where the code needs to
>> bring in variables) seems like it might be pretty useful.
>
>So now you want an IDE to design Word documents?..  (-:

Nah, just a way to decorate Word documents with instructions to 
more easily programmatically fill them with data. Something like 
this:

>Another tactic would be to use templates with fields and do a
>sort of "mail merge" to insert the necessary data.


>I think it took me less than a day to design and implement four
>(rather complex) Word documents from scratch, so I don't think I
>consider it a task that needs massive improvements.

Yeah, my worst professional flaw is that I tend to overengineer things
if I'm not careful. :-)

-Mike
-- 
http://www.mschaef.com

kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) writes:

>   It's a very simple syntax, but it's also very ugly, especially when
> deeply nested.  For procedural code with little nesting, sexps are fine.
> Naturally, most Lisp code is written as functionally as possible (Lisp
> programmers seem to like playing the game "how few variables or named
> functions can I use?"), and is therefore unreadable.

I am not sure where you get this information from, but I am sure
almost everyone on comp.lang.lisp would disagree.  

First, as Mike has pointed out, Lisp programmers read and understand
code not by counting parentheses, but by indentation.  Even fairly
deep nesting is therefore quite readable.  

Second, good Lisp programmers do not nest very deeply, simply because
they tend to write many small functions as opposed to few large ones.  

>   When used in a different style of language, the syntax works okay; the
> scripting language I'm working on uses sexps, but it's more procedural
> than Lisp.

I am not sure what makes you think that Lisp is less procedural than
your language, because I haven't seen your language.  However, Lisp is
perfectly well suited for procedural programming.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) writes:

>   The trouble with paren matching is that it only happens when you
> actively move the cursor to one paren.  

And that is pretty much the only time you need it.  If you try to read
a Lisp program by matching parentheses, you are using a method that is
not shared by any Lisp programmer I know.  Instead they use
indentation to understand the code. 

> Reading it without moving the
> cursor around is a much harder problem.  Drawing lines to represent the
> structure just clutters the display.  Using newlines in all
> more-than-minimally complex structures is ugly, too:
> (foo (+ a b)
> )

One of the first rules of indenting Lisp code is "never put a
parenthesis by itself on a line".

>   I don't think a good solution to this is possible.  You can put a bag
> over Lisp's head, but it's still not gonna get a date on its looks.

Well, looks are a matter of taste.  My personal opinion is that
anyone who is willing to stay away from a very productive and very
efficient language like Common Lisp because of some initial opinion
about superficial looks, despite the fact that all experienced users
testify that these looks are both necessary and, in fact, beautiful
(once you understand why they exist), deserves to remain forever less
productive in his software development. 

>   Most of the academics will claim that massively recursive, functional
> code is more efficient than procedural; this is even true to some
> extent, since Lisp compilers are optimized for tail-recursion rather
> than looping structures or variable access.

Where *do* you get this information from?  Common Lisp compilers are
not even required to eliminate tail recursion.  Have you actually
looked at a real Common Lisp compiler such as the one distributed with
CMUCL or SBCL?  I can assure you that it generates excellent code for
loops and variable access, in addition to being good at optimizing
away tail recursion (and tail calls in general). 

>   If you're trying to modify code written by someone else, it will
> almost always be written in a pure functional style.  

Really?  How about having a look at, say, McCLIM, the free version of
the Common Lisp Interface Manager, or some application, let's say the
Gsharp score editor.  These are prime examples of current Common Lisp
style, which turns out to be highly object-oriented rather than
functional.  In fact, I have yet to see any useful Common Lisp program
that is written in a pure functional style.  What is your source of
such code?  

> If you try to
> write Lisp code some other way, the pure-functional Lisp programmers
> will get upset and throw 10-pound Lisp books at you.  Basically it's not
> worth even trying in a professional environment.

You seem to live on a different planet from the one I am living on.  

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) writes:

> Lisp treats arrays/vectors as second-class citizens even in
> implementations which support them at all.

Now I am *convinced* we live on different planets.  The Common Lisp
standard *requires* arrays and vectors, and they are first-class
objects, just like lists, numbers, functions, classes, and pretty much
everything else in Common Lisp.  A vector is a subtype of sequence and
array, so all the sequence operations and array operations work on
vectors. 

I find it very sad that such misinformation continues to be spread
about Lisp.  People who actually believe such statements without
checking for themselves will miss out on an excellent general-purpose
programming language.  

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

Robert STRANDH wrote:
> 
.... snip ...
> 
> First, as Mike has pointed out, Lisp programmers read and understand
> code not by counting parentheses, but by indentation.  Even fairly
> deep nesting is therefore quite readable.
> 
> Second, good Lisp programmers do not nest very deeply, simply because
> they tend to write many small functions as opposed to few large ones.

Why do you limit this to Lisp programmers?  It applies equally to
C, Pascal, Ada, ....

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

CBFalconer <cbfalconer@yahoo.com> writes:

> Robert STRANDH wrote:
> > 
> ... snip ...
> > 
> > First, as Mike has pointed out, Lisp programmers read and understand
> > code not by counting parentheses, but by indentation.  Even fairly
> > deep nesting is therefore quite readable.
> > 
> > Second, good Lisp programmers do not nest very deeply, simply because
> > they tend to write many small functions as opposed to few large ones.
> 
> Why do you limit this to Lisp programmers?  It applies equally to
> C, Pascal, Ada, ....

I did not mean to say that it was limited to Lisp programmers.  Sorry
if it came across like that.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

"MSCHAEF.COM" wrote:

>> I'm not familiar with it [ASP] in this context.  Care to share
>> an e.g.?
> 
> I'm pretty sure ASP can't be used, as is, for generating Word
> documents.  I just like the model it uses for document production
> in general.

That's what I was hoping for an e.g. of!  (-:

> Now that Word has an XML schema for its documents, I guess it's
> increasingly possible to use more markup oriented tools to produce
> these kinds of documents.

It'd be interesting to look into that and see how well it translates
really complex Word docs.  I have a "book" I've been working on for
years--the spec for my language, BOOL--and the doc is no simple letter!

>> But, at some point, you need to say, 'this bit here has these
>> attributes [...].  If not with a bunch of assignments, then how?
> 
> Maybe stylesheets? I guess the Word object model has decent support
> for defining and using stylesheets?

If you mean CSS, Word doesn't have that, but it has paragraph and
character "Styles".  It also has "Themes" which bundle a bunch of
styles.

If I were going to produce larger documents, I would very likely
define some styles first and then be able to simply apply them in
one operation (although with larger documents, I'd also be thinking
about templates).

> (As a style assignment would represent a bunch of individual
> attributes in one assignment statement, etc.)

Exactly.  And they offer a single point of change if you want to
use a different font or whatever.

>> I'm **far** too anal to allow software to generate my code!
> 
> In the general case, so am I. That said, for boilerplate coding
> (data translation layers, etc.), I find that I'm too anal to do
> it by hand. :-)

Agreed!


>> (But it would actually be sort of a fun project.  Something I've
>> had on the back burner for years is a VB app to do a "listing" of
>> a Word (or Excel or Powerpoint) document.  Given the design of the
> 
> That would be fun.

May still do it OOTD (One Of These Days).

> Have you seen the "Reveal Formatting" options in new versions of
> Word? For solving complicated formatting problems, it's about
> the best piece of MS UI work I've seen in some time...

I don't find it on the menus as that name.  Do you mean the "Show
All" toggle that makes spaces, tabs and such visible?


> Nah, just a way to decorate Word documents with instructions to
> more easily programmatically fill them with data. Something like
> this:
> 
>> Another tactic would be to use templates with fields and do a
>> sort of "mail merge" to insert the necessary data.

Word certainly does provide a mechanism of "fields".

>> I think it took me less than a day to design and implement four
>> (rather complex) Word documents from scratch, so I don't think I
>> consider it a task that needs massive improvements.
> 
> Yeah, my worst professional flaw is that I tend to overengineer
> things if I'm not careful. :-)

Heh!  Been there, done that, own several of the videos....

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Michael N. Christoff" wrote:

>>> ...distributed network based computing.
>>
>> I'd agree the model is important, but I'm not sure I'd apply the
>> *program* *design* method, named OOP, to such a high level.  I
>> see what you're saying, but I think I'd never choose to use that
>> terminology in that area.
> 
> I assume by "OOP program design method" you mean OOA/D (object
> oriented analysis and design).

That, but also the physical coding mechanisms that support it
("classes", "member functions", etc.).

> I've always understood OOA/D as the process of developing systems
> in which computation is achieved through the collaboration of
> autonomous processes with encasulated internal state.

That's a good technique, which I think predates OOP.  Programmers
encapsulated state and developed autonomous "objects" before OOP.

I've taken (and this may be particular to me) OO[ADP] to also
define a coding technique that uses things like "classes" as a
native language construct, inheritance and object polymorphism.

What prevents me, I think, from seeing network computing as "OOP"
is the (to my eye) lack of inheritance and polymorphism.  Clearly
the encapsulation aspect is present, though!

> Anyways, I think saying that OOP (most prominently the class\object
> concept, encapsulation and interfaces) is well suited to
> implementing distributed systems is different from saying OOA/D =
> distributed computing.  However, I must admit, I find the
> similarities both stricking and numerous.

I agree!  And there may come a time--if distributed computer really
takes off--when creating such "objects" WILL be very much like
creating objects in an OOPL.


>>>> 'Swhat I've been saying for years!
>> 
>> [..Sir SnipAlot was here...]
>>
>> (Why ask me?! Not my website!!  :-)
> 
> Sorry.  I thought you implied you agreed with what this guy was
> saying.

Just that bit I first quoted about OOP being just an organizational
technique.  (Got into a longish debate here a while back when I
wrote that I saw Procedural Programming as "verb oriented" and OOP
as "noun oriented".  Despite that, I still do think of it that way.
The words are the same (i.e. you write the same code), but they are
organized differently.)


>> [Some] languages are more flexible in supporting different styles
>> of programming.
> 
> True.  There are 'multi-paradigm' languages like C++.  However it
> is notoriously difficult to design multi-paradigm languages that
> don't have 'language infrastructure overload'.  I'm not naming
> names. :)

[BWG]


>> I'm aware of [AOP] and have read (skimmed, actually) a couple
>> articles about it.  The Luddite in me is content to wait until
>> it gets out of the lab and can be had cheap at Best Buy...  (-:
> 
> Although I'll be personally investing time in learning AOP, the
> above makes a lot of practical sense.

Well, you're talking with someone who bought his first DVD player
just a couple months ago....  (-:

Drop by and tell us about AOP sometime, though.  I am interested.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Robert STRANDH <strandh@labri.fr> writes:

> CBFalconer <cbfalconer@yahoo.com> writes:
>
>> Robert STRANDH wrote:
>> > 
>> ... snip ...
>> > 
>> > First, as Mike has pointed out, Lisp programmers read and understand
>> > code not by counting parentheses, but by indentation.  Even fairly
>> > deep nesting is therefore quite readable.
>> > 
>> > Second, good Lisp programmers do not nest very deeply, simply because
>> > they tend to write many small functions as opposed to few large ones.
>> 
>> Why do you limit this to Lisp programmers?  It applies equally to
>> C, Pascal, Ada, ....
>
> I did not mean to say that it was limited to Lisp programmers.  Sorry
> if it came across like that.
>
> -- 

FWIW I simply had the impression that you were correcting
misstatements about Lisp that the person you were replying to made,
so I didn't take your statement to imply anything about any other
language in any way. :-)

-- 
Howard Ding
<hading@hading.dnsalias.com>

In article <40338EB0.71DEA668@Sonnack.com>,
Programmer Dude  <Chris@Sonnack.com> wrote:
  ...
>It'd be interesting to look into that and see how well it translates
>really complex Word docs.  

I think it's just an XMLization of the Word document format...

>> Maybe stylesheets? I guess the Word object model has decent support
>> for defining and using stylesheets?
>
>If you mean CSS, Word doesn't have that, but it has paragraph and
>character "Styles".  It also has "Themes" which bundle a bunch of
>styles.

No, I meant the Word Character and Paragraph styles.

>> Have you seen the "Reveal Formatting" options in new versions of
>> Word? For solving complicated formatting problems, it's about
>> the best piece of MS UI work I've seen in some time...
>
>I don't find it on the menus as that name.  Do you mean the "Show
>All" toggle that makes spaces, tabs and such visible?

Under Word XP, it's Format >> Reveal Formatting...

That will display a subwindow that has an outline describing all the 
current formatting settings for the text at the caret.

-Mike
-- 
http://www.mschaef.com

"MSCHAEF.COM" wrote:

>> Do you mean the "Show All" toggle that makes spaces, tabs and
>> such visible?
> 
> Under Word XP, it's Format >> Reveal Formatting...
> 
> That will display a subwindow that has an outline describing all
> the current formatting settings for the text at the caret.

Ah.  Word2000 no gots dat.  :-(

One can certainly get all that information by opening the dialogs
that apply (font dialog, paragraph dialog, style dialog), and you
can get icons in the toolbar to indicate some of the basic text
attributes....

But a one-stop shop would be neat!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude <Chris@Sonnack.com> wrote in news:4033937B.E0860628
@Sonnack.com:

> "Michael N. Christoff" wrote:
> 
>> I've always understood OOA/D as the process of developing systems
>> in which computation is achieved through the collaboration of
>> autonomous processes with encasulated internal state.
> 
> That's a good technique, which I think predates OOP.  Programmers
> encapsulated state and developed autonomous "objects" before OOP.
> 
> I've taken (and this may be particular to me) OO[ADP] to also
> define a coding technique that uses things like "classes" as a
> native language construct, inheritance and object polymorphism.
> 
> What prevents me, I think, from seeing network computing as "OOP"
> is the (to my eye) lack of inheritance and polymorphism.  Clearly
> the encapsulation aspect is present, though!

Surprisingly, polymorphism and inheritence are rather trivial to show... 
but not in the same way that many, supposed, OO languages support them. 
Part of this is odd, and ask that "what actually /is/ *" kinds of 
questions.

An objects interface defines a license - no more, and no less. It's a 
license for the kinds of data an object will accept and the kinds of data 
an object will produce. In 'active object', 'asynchronous object' land, 
that means the data accepted or produced could (potentially) be at any 
time. In most OO circles, the data produced is merely in reponse to some 
data accepted.

So, polymorphism:

I have two programs running on (optionally) seperate computers. Both 
programs use the same protocol (i.e. interface) but do different 
operations. The protocol is published and available.

So, inheritence:

I have two programs running on (optionally) seperate computers. Program A 
uses some protocol. Program B uses an optionally a restricted or expanded 
protocol compatible with that from program A.

TBH I find the idea of seperate processes which have defined interfaces, 
and optionally relationships between their interfaces, to be more 'in the 
spirit' of OO than the capabilities of most so-called OO languages.

>> Anyways, I think saying that OOP (most prominently the class\object
>> concept, encapsulation and interfaces) is well suited to
>> implementing distributed systems is different from saying OOA/D =
>> distributed computing.  However, I must admit, I find the
>> similarities both stricking and numerous.
> 
> I agree!  And there may come a time--if distributed computer really
> takes off--when creating such "objects" WILL be very much like
> creating objects in an OOPL.

I do, in fact, have a language with such properties already defined... 
noting of course that even current OO languages have (some) support for 
remote access of objects using things like SOAP. The one thing they 
appear to lack is the idea of these 'objects' being asynchronous.
 
>>>>> 'Swhat I've been saying for years!
>>> 
>>> [..Sir SnipAlot was here...]
>>>
>>> (Why ask me?! Not my website!!  :-)
>> 
>> Sorry.  I thought you implied you agreed with what this guy was
>> saying.
> 
> Just that bit I first quoted about OOP being just an organizational
> technique.  (Got into a longish debate here a while back when I
> wrote that I saw Procedural Programming as "verb oriented" and OOP
> as "noun oriented".  Despite that, I still do think of it that way.
> The words are the same (i.e. you write the same code), but they are
> organized differently.)

To anyone sufficiently skilled in the art of programming, it's clear that 
OO is 'merely' a reorganisation. Widespread OO languages take what is 
good about structured programming wholesale, even though the benefits of 
SP and OO are (at least in my eyes) orthogonal. OO, (IMO) defines many 
aspects of the interface(s) of an 'entity' (thing holding datat) without 
specifying anything about how the functionallity of the entity is 
actually performed (which is where the SP comes in to play). In practice, 
what's good in OO is /also/ good in SP... and in many cases could easilly 
be described as being 'just' good SP practice. To me, then, OO (at least 
while it's still synchronous) is merely a reorganisation of SP which has 
'promoted' aspects of good SP practice which are /not/ explicitely coded 
into SP. Similarly, SP is 'merely' a reorganisation of earlier 'good' 
programming practices.

If anyone has any ideas of what happens at the end of all this 'good 
practice'... I'd like to hear your thoughts on language design. :)

Ian Woods 

-- 
"I'm a paranoid schizophrenic sado-masochist.
My other half's out to get me and I can't wait."
Richard Heathfield

Ian Woods wrote:

>> What prevents me, I think, from seeing network computing as "OOP"
>> is the (to my eye) lack of inheritance and polymorphism.  Clearly
>> the encapsulation aspect is present, though!
> 
> An objects interface defines a license - no more, and no less.

Interesting term!  Reminds me of the "contract" term sometimes used
to describe an interface.

> ...data accepted or produced could (potentially) be at any time.

Good point!

> In most OO circles, the data produced is merely in reponse to some
> data accepted.

Synchronous.  But not always!


> So, polymorphism:
> 
> I have two programs running on (optionally) seperate computers.
> Both programs use the same protocol (i.e. interface) but do
> different operations. The protocol is published and available.

I can see your point,.... but I'm not sure I'm entirely onboard.
How often does the *same* protocol sequence/command to two different
"objects" cause different behavior.  I mean, how often does that
actually happen in DC (distrib. comp.)?

For instance, using the archetypal Animal class example, if you
"send" the same "speak message" to different derived Animals, you
get different behaviors (barking, meowing, mooing, etc.).

I have this vague, un-well-defined sense that identical protocol
isn't quite the same thing, nor are its effects quite the same.
But let's talk about it more--I could be off-base here.

And to monkey wrench my own sense, how about a webserver getting
a request for "GET /".  Same client, same command, different results.

So, hmmm,.... yeah,... maybe so!  (-:

(Pssst: old schoolboy trick...there's "a rat" in "separate".)

> So, inheritence:
> 
> I have two programs running on (optionally) seperate computers.
> Program A uses some protocol. Program B uses an optionally a
> restricted or expanded protocol compatible with that from program
> A.

Nah,... now this one I ain't buyin' at all.  (-:  That's not
inheritance... Not quite sure WHAT to call it, but tain't inheriting
(except maybe in the most virtual sense).

> TBH I find the idea of seperate processes which have defined
> interfaces, and optionally relationships between their interfaces,
> to be more 'in the spirit' of OO than the capabilities of most
> so-called OO languages.

I can see why.  Are you familiar with Smalltalk?  If not, you might
enjoy checking into it.


>> I agree!  And there may come a time--if distributed computer really
>> takes off--when creating such "objects" WILL be very much like
>> creating objects in an OOPL.
> 
> I do, in fact, have a language with such properties already defined...

You talked about it here recently, yes?

> noting of course that even current OO languages have (some) support
> for remote access of objects using things like SOAP. The one thing
> they appear to lack is the idea of these 'objects' being asynchronous.

Why do I now expect Jim Rogars to speak up about Ada....  (-:


>> ...about OOP being just an organizational technique.
> 
> OO, (IMO) defines many aspects of the interface(s) of an 'entity'
> (thing holding datat) without specifying anything about how the
> functionallity of the entity is actually performed (which is where
> the SP comes in to play).

Yes... I agree that's mostly true.  C++, for example, does have some
recommendations about how you go about certain things, but I very
much agree that once you're writing a method, it's very much the
same art as writing a (non-method) function.

> To me, then, OO (at least while it's still synchronous) is merely
> a reorganisation of SP which has 'promoted' aspects of good SP
> practice which are /not/ explicitely coded into SP. Similarly, SP
> is 'merely' a reorganisation of earlier 'good' programming practices.

I'd agree.  This is demonstrated by how you CAN do OOP in C if you
do it "by hand".


-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Ian Woods" <newspub2@wuggyNOCAPS.org> wrote in message
news:Xns9494160E4C6A2newspubwuggyorg@217.32.252.50...
> Programmer Dude <Chris@Sonnack.com> wrote in news:4033937B.E0860628

> >
> > What prevents me, I think, from seeing network computing as "OOP"
> > is the (to my eye) lack of inheritance and polymorphism.  Clearly
> > the encapsulation aspect is present, though!

To ProgrammerDude:
But that means OOP has a superset of the requirements for network computing
(given most modern OOPLs have proprietary remote object frameworks).  Note,
I try and define two types of distributed computing below: applied, and
academic.

>
> Surprisingly, polymorphism and inheritence are rather trivial to show...
> but not in the same way that many, supposed, OO languages support them.
> Part of this is odd, and ask that "what actually /is/ *" kinds of
> questions.
>
> An objects interface defines a license - no more, and no less. It's a
> license for the kinds of data an object will accept and the kinds of data
> an object will produce. In 'active object', 'asynchronous object' land,
> that means the data accepted or produced could (potentially) be at any
> time. In most OO circles, the data produced is merely in reponse to some
> data accepted.
>

To Ian Woods:

Yes.  In particular, in a synchronous call, the caller blocks until the
callee finishes processing.  In an asynchronous call, the caller invokes the
callee and then continues processing without waiting for a response.  The
response is read at a later time.  It is typically used to query multiple
network resources simultaneously in business applications.

I agree that most OOPLs do not have built in facilities for things like
asynchronous interaction, but to say its not considered in 'OO circles' is
simply not true.  Modern business applications are quickly becoming more
distributed.  Web and database server fault-tolerant clusters are common
among even small business nowadays, due to almost universal support for
clustering in most business platforms, and cheap computers/server-software.
In J2EE, each web server's state is replicated at each cluster node, and
distributed as serialized objects.  Java Messaging Service (JMS) and/or
MessageDrivenBeans facilitate asynchronous communication.  JNDI provides an
interface to a network directory service, where for instance, executable
objects can be cached, and possibly consumed by other nodes.  .NET has its
ActiveDirectory with similar support for distributed objects.  It may be
both simple and applied distributed computing, but it is distributed
computing.

Now of course one can define many 'types' or 'levels' of distributed
computing.  Jumping to highest level is the complex systems notion.  In this
notion, computation is a macro-property of the system as a whole called an
emergent property.  This type of system is composed of a network of nodes
whose knowledge of the system state is limited to their own state, and the
state of their immediate neigbours.  Typically all nodes are coded
identically with a minimum of logic.  Cellular automata are an example of a
similar distributed model.  So are neural nets.

> So, polymorphism:
>
> I have two programs running on (optionally) seperate computers. Both
> programs use the same protocol (i.e. interface) but do different
> operations. The protocol is published and available.
>
> So, inheritence:
>
> I have two programs running on (optionally) seperate computers. Program A
> uses some protocol. Program B uses an optionally a restricted or expanded
> protocol compatible with that from program A.
>
> TBH I find the idea of seperate processes which have defined interfaces,
> and optionally relationships between their interfaces, to be more 'in the
> spirit' of OO than the capabilities of most so-called OO languages.
>
> >> Anyways, I think saying that OOP (most prominently the class\object
> >> concept, encapsulation and interfaces) is well suited to
> >> implementing distributed systems is different from saying OOA/D =
> >> distributed computing.  However, I must admit, I find the
> >> similarities both stricking and numerous.
> >
> > I agree!  And there may come a time--if distributed computer really
> > takes off--when creating such "objects" WILL be very much like
> > creating objects in an OOPL.
>
> I do, in fact, have a language with such properties already defined...
> noting of course that even current OO languages have (some) support for
> remote access of objects using things like SOAP. The one thing they
> appear to lack is the idea of these 'objects' being asynchronous.
>

See above (and I'm pretty sure .NET has similar services).

> >>>>> 'Swhat I've been saying for years!
> >>>
> >>> [..Sir SnipAlot was here...]
> >>>
> >>> (Why ask me?! Not my website!!  :-)
> >>
> >> Sorry.  I thought you implied you agreed with what this guy was
> >> saying.
> >
> > Just that bit I first quoted about OOP being just an organizational
> > technique.  (Got into a longish debate here a while back when I
> > wrote that I saw Procedural Programming as "verb oriented" and OOP
> > as "noun oriented".  Despite that, I still do think of it that way.
> > The words are the same (i.e. you write the same code), but they are
> > organized differently.)
>
> To anyone sufficiently skilled in the art of programming, it's clear that
> OO is 'merely' a reorganisation. Widespread OO languages take what is
> good about structured programming wholesale, even though the benefits of
> SP and OO are (at least in my eyes) orthogonal. OO, (IMO) defines many
> aspects of the interface(s) of an 'entity' (thing holding datat) without
> specifying anything about how the functionallity of the entity is
> actually performed (which is where the SP comes in to play).

But thats the point.  You separate the specification of 'what it does' from
the spec for 'how it does it'.  Its a way to promote loosely coupled
systems.  If client objects are dependent on exactly how the functionality
of a server object is performed, we can't replace the server polymorphically
with new code or we risk breaking the client's expectation of the server's
internal functionality.  That's strong coupling.  The idea is to never make
interface contracts that refer to any implementation details.

> In practice,
> what's good in OO is /also/ good in SP... and in many cases could easilly
> be described as being 'just' good SP practice. To me, then, OO (at least
> while it's still synchronous) is merely a reorganisation of SP which has
> 'promoted' aspects of good SP practice which are /not/ explicitely coded
> into SP.

> Similarly, SP is 'merely' a reorganisation of earlier 'good'
> programming practices.
>

So you believe that, for instance, the move from unstructured to structured
languages, can be thought of simply in terms of organization (noun-centered
from verb-centered)?  Perhaps, but I would argue thats only true at a very
low, yet obviously fundamental, level.  Its like an original axiom of OO,
but there have been many theorems proven since then.  It takes more to being
good at OOP than simply understanding a broad general principle.  Same goes
for structured.

> If anyone has any ideas of what happens at the end of all this 'good
> practice'... I'd like to hear your thoughts on language design. :)
>

Heard of AOP?  Its like a language-enhancing technology.  ie: you can add it
to a large variety of languages, even purely functional ones.



l8r, Mike N. Christoff

Hmm, I seem to not getting some of your objections: if I understand
correctly, there are some easy examples.

Programmer Dude schrieb:
> > I have two programs running on (optionally) seperate computers.
> > Both programs use the same protocol (i.e. interface) but do
> > different operations. The protocol is published and available.
> 
> I can see your point,.... but I'm not sure I'm entirely onboard.
> How often does the *same* protocol sequence/command to two different
> "objects" cause different behavior.  I mean, how often does that
> actually happen in DC (distrib. comp.)?

If you have two printers on the network, one can print color PS, the
other prints it B/W ... or two B/W printers, but one has white paper,
the other yellow paper in it.

Browsers: if differnet browsers get the same HTML data via the same http
protocol, the display generated can look quite different based on the
browser used.

> > I have two programs running on (optionally) seperate computers.
> > Program A uses some protocol. Program B uses an optionally a
> > restricted or expanded protocol compatible with that from program
> > A.
> 
> Nah,... now this one I ain't buyin' at all.  (-:  That's not
> inheritance... Not quite sure WHAT to call it, but tain't inheriting
> (except maybe in the most virtual sense).

Browser A displays HTML without CSS.
Browser B displays the same HTML using the Screen stylesheet.
Browser C prints the same HTML using the print stylesheet (in theory).

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

"Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in message
news:yL7Zb.6790$w65.622987@news20.bellglobal.com...
>
> "Ian Woods" <newspub2@wuggyNOCAPS.org> wrote in message
> OO, (IMO) defines many
> > aspects of the interface(s) of an 'entity' (thing holding datat) without
> > specifying anything about how the functionallity of the entity is
> > actually performed (which is where the SP comes in to play).
>
> But thats the point.  You separate the specification of 'what it does'
from
> the spec for 'how it does it'.  Its a way to promote loosely coupled
> systems.  If client objects are dependent on exactly how the functionality
> of a server object is performed, we can't replace the server
polymorphically
> with new code or we risk breaking the client's expectation of the server's
> internal functionality.  That's strong coupling.  The idea is to never
make
> interface contracts that refer to any implementation details.
>

Sorry.  I retract this.  I misread your intent I believe.  I agree good OO
separates implementation from interface.



l8r, Mike N. Christoff

"Programmer Dude" <Chris@Sonnack.com> wrote in message <news:403502A2.B7F13434@Sonnack.com>...

> Ian Woods wrote:

> > noting of course that even current OO languages have (some) support
> > for remote access of objects using things like SOAP. The one thing
> > they appear to lack is the idea of these 'objects' being asynchronous.
>
> Why do I now expect Jim Rogars to speak up about Ada....  (-:

....and Visual Basic versions 5.0 and 6.0 can define events within
ordinary classes, in addition to GUI controls.  Some trickery is
needed for truly asynchronous processing, but it can be done within
"pure" VB.

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Michael Mendelsohn wrote:

>> How often does the *same* protocol sequence/command to two different
>> "objects" cause different behavior.  I mean, how often does that
>> actually happen in DC (distrib. comp.)?
> 
> If you have two printers on the network, one can print color PS, the
> other prints it B/W ... or two B/W printers, but one has white paper,
> the other yellow paper in it.
> 
> Browsers: if differnet browsers get the same HTML data via the same
> http protocol, the display generated can look quite different based
> on the browser used.

Right.  This is why I went on to write:

} And to monkey wrench my own sense, how about a webserver getting
} a request for "GET /".  Same client, same command, different results.

So we're seeing the same phenomena... I'm still questioning slightly
whether it's really object polymorphism or--in reality--just different
instances of the same "meta-class".

I'm going to play Devil's Advocate here and say that network printers
(regardless of paper color or number of inks or paper size) are really
"instances" of the same "class": the meta-class "CNetworkPrinter".

Likewise, a web server--regardless of content served--is just an
"instance" of the "CWebServer" meta-class.  These instances have
different "state data" (paper, ink, web pages, etc.).

So I'm still not *convinced* this is (object) polymorphism as the
term is usually defined in OOP.  (Although there are some pretty
fuzzy lines here, yeah?)

>>> Program A uses some protocol. Program B uses an optionally a
>>> restricted or expanded protocol compatible with that from
>>> program A.
>>
>> Nah,... now this one I ain't buyin' at all.  (-:  That's not
>> inheritance... Not quite sure WHAT to call it, but tain't
>> inheriting (except maybe in the most virtual sense).
> 
> Browser A displays HTML without CSS.
> Browser B displays the same HTML using the Screen stylesheet.
> Browser C prints the same HTML using the print stylesheet (in theory).

Again, I see instances of the same meta-class, and these instances
use state data to define their actual behavior.  The more I think
about this, the more I'm leaning towards this model rather than the
OO one.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Michael N. Christoff" <mchristoff@sympatico.caREMOVETHIS> wrote in message <news:Eb8Zb.6822$w65.625222@news20.bellglobal.com>...

> Sorry.  I retract this.  I misread your intent I believe.  I agree good OO
> separates implementation from interface.

Oh, dear.  That could lead directly to the Visual Basic
"interface inheritance" heresy, now, couldn't it... >=)

--
Joe Foster <mailto:jlfoster%40znet.com>  KrazyKookKultz! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Programmer Dude" <Chris@Sonnack.com> wrote in message
news:40351410.3CFED03E@Sonnack.com...
> Michael Mendelsohn wrote:
>
> >> How often does the *same* protocol sequence/command to two different
> >> "objects" cause different behavior.  I mean, how often does that
> >> actually happen in DC (distrib. comp.)?
> >
> > If you have two printers on the network, one can print color PS, the
> > other prints it B/W ... or two B/W printers, but one has white paper,
> > the other yellow paper in it.
> >
> > Browsers: if differnet browsers get the same HTML data via the same
> > http protocol, the display generated can look quite different based
> > on the browser used.
>
> Right.  This is why I went on to write:
>
> } And to monkey wrench my own sense, how about a webserver getting
> } a request for "GET /".  Same client, same command, different results.
>
> So we're seeing the same phenomena... I'm still questioning slightly
> whether it's really object polymorphism or--in reality--just different
> instances of the same "meta-class".
>

Polymorphism can be thought of as a way to support the idea of substitutable
objects.  Take a class C that inherits from B which inherits from A.  Class
A has the type 'A'.  B has the types 'A' and 'B', and C has the types 'A',
'B' and 'C'.  So C can be passed to any method designed to accept objects of
type A, B, or C, even if they were written long before class C was even a
twinkle in a programmer's eye. heh heh :)  Interface inheritance (or
extension in Java) works the same way.  An object that implements interfaces
D1 -> D4 is simulataneously considered an object of each type D1-D4, and can
therefore be passed to any method requiring any of the types D1-D4.  This is
how I think of 'practical' polymorphism.

So in the case of the printer, both a B/W ink-jet printer and the
colour-laser can both implement the PostScript interface.  The client only
cares that it has access to any object of type PostScript.  It doesn't need
to know that one object will implement the interface by printing in B/W and
use dithering, while the other will print in full colour.

ie:

public interface PostScript
{
    public void print(SpecialPSFileFormatDoc p);
}

public class PrintHandler
{
    private PostScript ps = null;
    public PrintHandler(PostScript ps) {this.ps = ps;}
    public void recievePrintRequest(SpecialPSFileFormat p)
    {
        ps.print(p);
    }
}

The above will compile without me needing to write a concrete class that
implements PostScript.  Another class may be:

public class PrintDispatcher()
{
    PrintHandler ph = null;
    public void run()
    {
            double i = MathLib.someRandomNumber();
            if(i < 0.5)
                ph = new PrintHandler(new BWPrinter());
            else
                ph = new PrintHandler(new LaserPrinter());
            ....
    }
}

public class BWPrinter
    implements PostScript
{
    public void print(SpecialPSFileFormatDoc p) {// print in black and
white}
}

public class LaserPrinter
    implements PostScript
{
    public void print(SpecialPSFileFormatDoc p) {// print in colour}
}

Its simple, but hopefully clear.



l8r, Mike N. Christoff

Programmer Dude schrieb:> 
> Michael Mendelsohn wrote:
> >> How often does the *same* protocol sequence/command to two different
> >> "objects" cause different behavior.  I mean, how often does that
> >> actually happen in DC (distrib. comp.)?
> >
> > If you have two printers on the network, one can print color PS, the
> > other prints it B/W ... or two B/W printers, but one has white paper,
> > the other yellow paper in it.
> >
> > Browsers: if differnet browsers get the same HTML data via the same
> > http protocol, the display generated can look quite different based
> > on the browser used.
> 
> Right.  This is why I went on to write:
> 
> } And to monkey wrench my own sense, how about a webserver getting
> } a request for "GET /".  Same client, same command, different results.

No, that's not the same - different webservers hold different data.
Although, depending on what modules are enabled... an Apache's pretty
polymorphic if it wants to be.

> So we're seeing the same phenomena... I'm still questioning slightly
> whether it's really object polymorphism or--in reality--just different
> instances of the same "meta-class".
> 
> I'm going to play Devil's Advocate here and say that network printers
> (regardless of paper color or number of inks or paper size) are really
> "instances" of the same "class": the meta-class "CNetworkPrinter".

Well, the paper example of mine was BS: you can take the white paper
printer, exchange the paper and get a yellow paper printer without the
object=printer having changed.

However, a B/W laser printer and a color inkjet differ in
implementation; and that you can find a meta-class to lump them under
(and code to) is a prerequisite for polymorphism.
For classes to be polymorphous, they have to have a common ancestor or
interface; but the ancestor is not the class as implemented.

> Likewise, a web server--regardless of content served--is just an
> "instance" of the "CWebServer" meta-class.  These instances have
> different "state data" (paper, ink, web pages, etc.).

So a MS Server and an Apache are instances of the same class?
Don't think so. 

> >>> Program A uses some protocol. Program B uses an optionally a
> >>> restricted or expanded protocol compatible with that from
> >>> program A.
> >>
> >> Nah,... now this one I ain't buyin' at all.  (-:  That's not
> >> inheritance... Not quite sure WHAT to call it, but tain't
> >> inheriting (except maybe in the most virtual sense).
> >
> > Browser A displays HTML without CSS.
> > Browser B displays the same HTML using the Screen stylesheet.
> > Browser C prints the same HTML using the print stylesheet (in theory).
> 
> Again, I see instances of the same meta-class, and these instances
> use state data to define their actual behavior.  The more I think
> about this, the more I'm leaning towards this model rather than the
> OO one.

You argument only holds if Browser A is actually able to do what B and C
do; but the code may just not be in place!

You can throw OO out the window by saying: "New functionality? I'll just
extend the old class to have some extra states and some extra
functions!", but in reality the old software and devices live on
unextended, and new ones come to join them, which by dint of being
"compatible" contain and extend the old interface.

A better inheritance example would be to have a machine with an add-on,
for example a continuous-feed printer extended with a single sheet
feeder: the new combination can do more than the printer alone, yet
relies on teh old implementation to do everything except feeding paper
the new way.

You could also thin of an Apache web server that has a new module linked
to it; this new software conglomerate inherits most of the behaiour of
the basic server, with additional behaviour added.
You're going to argue the new module is just new data, aren't you? Well,
every program is data...

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

"Michael N. Christoff" wrote:

> In particular, in a synchronous call, the caller blocks until the
> callee finishes processing.  In an asynchronous call, the caller
> invokes the callee and then continues processing without waiting
> for a response.  The response is read at a later time.

Just to mitigate some possible confusion, also called (respectively)
blocking and non-blocking.  And synchronous and asynch sometimes
refer more to the receiver than sender.  That is, asynch often means
things can happen to something at any time.

But you probably knew all that.  (-:


> So you believe that, for instance, the move from unstructured
> to structured languages, can be thought of simply in terms of
> organization...

Yes, I believe that the difference between unstructured code and
structured code is organization (of the code).

> ...(noun-centered from verb-centered)?

But THAT is my (and I have heard it from others) term for the
difference between the organization of OOP and PP.


-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Michael N. Christoff" wrote:

>> So we're seeing the same phenomena... I'm still questioning
>> slightly whether it's really object polymorphism or--in reality--
>> just different instances of the same "meta-class".
> 
> Polymorphism can be thought of as a way to support the idea of
> substitutable objects.

Hmmmm....

> [C inherits B inherits A]  So C can be passed to any method
> designed to accept objects of type A, B, or C,...

I'd tend to call that inheritance rather than polymorphism, but
that's just me.  To be polymorphism (by me), you'd need B1 and B2
(which both inherit A).  Now you can write code which takes an 'A',
send it B1 and B2, and let them work it out.

(And, in fact, your later point about printers more closely matches
this situation.)

> Interface inheritance (or extension in Java) works the same way.

Which is part of what makes me lean away from calling this polymorph.
It's inheritance.  Polymorphism must be something else/more/different.

(FWIW, I distinguish between object polymorphism and function
polymorphism (also called function overloading).  We're obviously
talking about object polymorph.)

> So in the case of the printer, both a B/W ink-jet printer and the
> colour-laser can both implement the PostScript interface.  The
> client only cares that it has access to any object of type
> PostScript.  It doesn't need to know that one object will
> implement the interface by printing in B/W and use dithering,
> while the other will print in full colour.

I'm going to have to think about this to come up with an explanation
that makes sense, but my gut is against calling this polymorphism.
I just can't tell you exactly *why* right now!  (-:

> Its simple, but hopefully clear.

Oh, it's *absolutely* clear why you think what you think, and as I
said, I understand your point.  I'm just finding I'm not going along
with it.  Let me ponder it for a while.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Michael Mendelsohn wrote:

>>> And to monkey wrench my own sense, how about a webserver getting
>>> a request for "GET /".  Same client, same command, different
>> results.
> 
> No, that's not the same - different webservers hold different data.

Yeah, that's the part about "different results".

> However, a B/W laser printer and a color inkjet differ in
> implementation; and that you can find a meta-class to lump
> them under (and code to) is a prerequisite for polymorphism.

True enough.

But, here's something to consider.  Actually talking to those two
printers uses a different language--there would be different drivers
speaking to those printers.  Even at the application level, when
you select a different printer, the dialog changes to indicate the
properties of that printer.

That's not very polymorphous to me.

>> Likewise, a web server--regardless of content served--is just an
>> "instance" of the "CWebServer" meta-class.  These instances have
>> different "state data" (paper, ink, web pages, etc.).
> 
> So a MS Server and an Apache are instances of the same class?
> Don't think so.

Externally they are pretty close.  They both use http as a mechanism
for speaking with them.  But given that they both offer very different
capabilities, I don't think "instance" or "polymorphism" is really
an appropriate model.


> You're going to argue the new module is just new data, aren't you?
> Well, every program is data...

[grin]  Like I said to the other Michael, let me ponder this a bit.
It does seem a great deal depends on "how you look at it".

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude wrote:

> What prevents me, I think, from seeing network computing as
> "OOP" is the (to my eye) lack of inheritance and polymorphism. 

Since inheritance is defined mainly in terms of interfaces, might one 
not see an "inheritance" language construct as mere syntactic sugar 
for a certain kind of composition? It relieves the programmer from 
the tedium of explicitly publicizing the base interface and 
delegating (part of) its implementation to a subobject. And on that 
level, the subobject might as well live on a different computer 
although a language's inheritance construct may not directly 
facilitate that. No?


Martin

-- 
   Please help refine my English usage!
    -= Send your critique by email. =-

Quidquid latine dictum sit, altum viditur.

Programmer Dude <Chris@Sonnack.com> wrote in news:403502A2.B7F13434
@Sonnack.com:

> Ian Woods wrote:
> 
>>> What prevents me, I think, from seeing network computing as "OOP"
>>> is the (to my eye) lack of inheritance and polymorphism.  Clearly
>>> the encapsulation aspect is present, though!
>> 
>> An objects interface defines a license - no more, and no less.
> 
> Interesting term!  Reminds me of the "contract" term sometimes used
> to describe an interface.
> 
>> ...data accepted or produced could (potentially) be at any time.
> 
> Good point!
> 
>> In most OO circles, the data produced is merely in reponse to some
>> data accepted.
> 
> Synchronous.  But not always!
> 
> 
>> So, polymorphism:
>> 
>> I have two programs running on (optionally) seperate computers.
>> Both programs use the same protocol (i.e. interface) but do
>> different operations. The protocol is published and available.
> 
> I can see your point,.... but I'm not sure I'm entirely onboard.
> How often does the *same* protocol sequence/command to two different
> "objects" cause different behavior.  I mean, how often does that
> actually happen in DC (distrib. comp.)?

In tradition DC, I've no idea - I've not done any serious distributed 
work yet. But, you've already struck upon the obvious example...

<snip animal example >

> I have this vague, un-well-defined sense that identical protocol
> isn't quite the same thing, nor are its effects quite the same.
> But let's talk about it more--I could be off-base here.
> 
> And to monkey wrench my own sense, how about a webserver getting
> a request for "GET /".  Same client, same command, different results.

And, just as importantly, different underlying behaviour. Some requests 
to some servers might involve merely fetching a file, or running a 
CGI/ASP/PHP/<insert TLA here> script.
 
> So, hmmm,.... yeah,... maybe so!  (-:
> 
> (Pssst: old schoolboy trick...there's "a rat" in "separate".)

I've been doing too much maths and not enough language... I've started to 
forget all sorts of speelings and things. I think I'm going to have to do 
some serious writing before I lose the ability to write altogether!
 
>> So, inheritence:
>> 
>> I have two programs running on (optionally) seperate computers.
>> Program A uses some protocol. Program B uses an optionally a
>> restricted or expanded protocol compatible with that from program
>> A.
> 
> Nah,... now this one I ain't buyin' at all.  (-:  That's not
> inheritance... Not quite sure WHAT to call it, but tain't inheriting
> (except maybe in the most virtual sense).

I think we might be back on a similar track to an earlier discussion 
we've had, to do with the difference between inheriting the underlying 
implementation of something as opposed to the interface of something. :)

My take on this from the view that OO is 'all about' the interface rather 
than the implementation. If I take a class A and derive a class B from 
it, I can specify which methods from A are applicable in B and provide 
additional methods of B's very own. (And, mixed with polymorphism, 
potentially different behaviours for some the methods derived from A). 
From here, other than the quirk that the inherited methods in B's 
interface happen to be duplicates of the behaviour of the same method in 
A (unless told otherwise), all that has been specified is how the 
interface of B relates to the interface of A.

>> TBH I find the idea of seperate processes which have defined
>> interfaces, and optionally relationships between their interfaces,
>> to be more 'in the spirit' of OO than the capabilities of most
>> so-called OO languages.
> 
> I can see why.  Are you familiar with Smalltalk?  If not, you might
> enjoy checking into it.

I played around with Squeak for a week or so... uhm... too many years ago 
now. I didn't spend enough time to learn it properly, and have forgotten 
almost all what I learned during that week. What I did keep was the new 
and strange ways I was thinking about OO... as might be apparent. :)

<snip>

Ian Woods

-- 
"I'm a paranoid schizophrenic sado-masochist.
My other half's out to get me and I can't wait."
Richard Heathfield

Programmer Dude schrieb:
> Michael Mendelsohn wrote:
> > However, a B/W laser printer and a color inkjet differ in
> > implementation; and that you can find a meta-class to lump
> > them under (and code to) is a prerequisite for polymorphism.
> 
> True enough.
> 
> But, here's something to consider.  Actually talking to those two
> printers uses a different language--there would be different drivers
> speaking to those printers. 

Not necessarily.
Remember "Epson-compatible" printers?
Also, I was living under the uninformed assumption that postscript
printers with an ethernet interface had a universal way of being spoken
to.

> Even at the application level, when
> you select a different printer, the dialog changes to indicate the
> properties of that printer.
> 
> That's not very polymorphous to me.

You're thinking local Windows printer.

> >> Likewise, a web server--regardless of content served--is just an
> >> "instance" of the "CWebServer" meta-class.  These instances have
> >> different "state data" (paper, ink, web pages, etc.).
> >
> > So a MS Server and an Apache are instances of the same class?
> > Don't think so.
> 
> Externally they are pretty close.  They both use http as a mechanism
> for speaking with them.  But given that they both offer very different
> capabilities, I don't think "instance" or "polymorphism" is really
> an appropriate model.

There is no way of convincing you.
You either say "They're so much the same, they're instances of the same
object" or you say "they're so different, the things they have in common
don't count".

Polymorphism is an appropriate model, because the morph they have in
common is that of a web server that take html data and delivers it to
clients using http; and the client need not know which server software
is running, nor does the HTML author. Of course this "base class"
functionality has been extended in different ways in both kinds of
software, which is why this serves as an example of polymorphism.
One server can deliver HTML from .asp, the other from .shtml.

> > You're going to argue the new module is just new data, aren't you?
> > Well, every program is data...
> 
> [grin]  Like I said to the other Michael, let me ponder this a bit.
> It does seem a great deal depends on "how you look at it".

Well, that's all OO is - a way to look at things, and a formalism to let
you write down the things you see. In the issue at hand, it would let
you write down how different network device/software interfaces are
similar, and how they are different.

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

"Robert STRANDH" <strandh@labri.fr> wrote in message
news:6woerzimv3.fsf@serveur5.labri.fr...
> > > david@firepro.co.za (David Turner) writes:
> > >
> > > > In terms of the efficiency of the resulting machine code, Lisp
> > > > has the worse of it.
> > >
> > > Do you have any references to support such a broad claim?
> >
> > Don't be an ass.  I said it was an opinion, and it's certainly not
> > an unpopular one.
>
> I sure did not come across as an opinion.  Also, just because it is a
> popular opinion does not make it a correct statement.
>
> As others have pointed out, there are some excellent implementations
> of Lisp out there that produce code that is comparable in performance
> to similar C++ and C code.

And as I pointed out, I have nothing against Lisp.  My opinion of it was
formed several years ago, and may very well be wrong.  As a matter of fact,
since so many people have pointed out to me that current Lisp
implementations are so good, I've downloaded some free ones to see what they
can do for me.  This has absolutely no bearing on the point I was originally
trying to make, which has now been lost in a flood of controversy over a
simple lapse in rigour, viz. the phrase in the conclusion of my OP along the
lines of, "...and other garbage collected languages...".

Ironically, the OP was motivated partly by the same sentiment that now
inspires you: a desire to correct a popular misconception.  That
misconception is that Java (or C#) relieves the programmer of the burden of
resource management.  It does not, and in fact its use of garbage collection
is dangerous, because it prevents the use of more elegant patterns that _do_
help to solve the problem.  Simultaneously, it lulls the programmer into a
false sense of security.  In many ways, the programming community seems to
be going *backwards* in its efforts to produce better tools.

The key idea that seems to be emerging from "The New C++" is that it's
possible to construct an API that enforces constraints.  A very simple form
of constraint that has been implemented very successfully is the "acqusition
=> de-acquisition" pattern, which can be seen in the likes of std::auto_ptr,
std::fstream, boost::shared_ptr, boost::mutex::scoped_guard, etc.  Other
types of constraints, such as "mutating iterator => no non-mutating
iterators" can also be implemented, with varying levels of success.

My point is that the programmer using the API should not be relied upon not
to forget anything.  Forcing him to free a resource allocated implicitly by
an API function is a Bad Thing.  The C++ solution is to make that function
private, and model the acquisition and release with an object.  This cannot
be done effectively in Java.  It *can* be done effectively in Lisp, which is
why I have nothing against Lisp.

Regards
David Turner

Martin Eisenberg wrote:

>> What prevents me, I think, from seeing network computing as
>> "OOP" is the (to my eye) lack of inheritance and polymorphism.
> 
> Since inheritance is defined mainly in terms of interfaces, might
> one not see an "inheritance" language construct as mere syntactic
> sugar for a certain kind of composition?

I don't agree inheritance *is* defined mainly in terms of interfaces.
To me, the thing about inheritance is inheriting *functionality*.

One of the promises of OOP was "code re-use", which I always though
broke down into (at least) two kinds.  First, there's re-use of
code from project A in project B.  I always thought programmers have
done *that* since card decks.  The second type, which I think OOP
does provide nicely, is re-use of code *within* a project, and this
is often done via inheritance.

As an example, if I have a string class, I can derive a "numbered
line" class, which is a string with a line number.  I inherit (and
don't have to re-write) all the function of strings, plus a bit
more I add to specialize the new class.

And there, ya see?  Two paragraphs describing inheritance and no
reference at all to interfaces.  (Which is not to say either view
is wrong or right, BTW.  There's room in the world for looking at
things in different ways, don'tcha think?)

> It relieves the programmer from the tedium of explicitly
> publicizing the base interface and delegating (part of) its
> implementation to a subobject.

I believe the really significant part of the above is that last
bit: "to a subobject".  That's a huge part of the picture--that
something else provides important functionality.

As an aside, I believe "delegation" usually has a formal meaning
in OOP, and that meaning is actually *opposed* to "inheritance".
Using the "numbered line" class idea above, it could be done
via inheritance:

	class NumberedLine: public myString
	{
	    unsigned long  line_number;
	public:
	    // ...implementation...
	};

Or via delegation:

	class NumberedLine
	{
	    unsigned long  line_number;
	    myString       a_string;
	public:
	    // ...implementation...
	};

The inherited example "looks like" a myString object, because
inheritance can also support polymorphism.  The delegated
example can never "look like" a myString, and all methods of
myString we might want to expose in NumberedLine need to be
replicated, and need to then delegate to the myString methods.


> And on that level, the subobject might as well live on a
> different computer although a language's inheritance construct
> may not directly facilitate that. No?

I suppose it *could*.  Maybe there's a virtual print engine that
users couldn't actually print to, but which actual printers might
use do some of the processing.

Seems weird, but certainly not impossible.  And things like .NET,
CORBA and DCOM ("ActiveX") certainly provide a mechanism that would
support it.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Ian Woods wrote:

>> And to monkey wrench my own sense, how about a webserver getting
>> a request for "GET /".  Same client, same command, different
>> results.
> 
> And, just as importantly, different underlying behaviour.  Some
> requests to some servers might involve merely fetching a file,
> or running a CGI/ASP/PHP/<insert TLA here> script.

Yep.  But,.... [grin] been thinking about this, and I've decided
(in part to continue as Devil's Advocate, but also in because I
just don't see the OOP sense of polymorphism here) I just don't
see the OOP sense of polymorphism here.

(I'll go into why in detail in my response to Michael.)


>>> So, inheritence:
>>
>> Nah,... now this one I ain't buyin' at all.
> 
> I think we might be back on a similar track to an earlier
> discussion we've had, to do with the difference between
> inheriting the underlying implementation of something as
> opposed to the interface of something. :)

Very possibly.  I'd like to make clear that, first, in a GENERAL
sense of "polymorphic" (many shapes) and "inherited", I quite
agree with you guys' perceptions.  It's the OOP-ish sense of
those concepts I don't feel quite applies.  My goal here isn't
to convince anyone of the "truth" of my view--I just think it
might be fun to expose and dicuss the opposing viewpoints.  And
hopefully, no one has any emotional attachments here!  (-:

Anyway....

> My take on this from the view that OO is 'all about' the interface
> rather than the implementation.

This *is* going to get interesting, because a big part of my reply
to Michael involves the difference between interface ("shape") and
implementation!

> If I take a class A and derive a class B from it, I can specify
> which methods from A are applicable in B and provide additional
> methods of B's very own.

"Specialization".  You're making a "more specialized" A.

> From here, other than the quirk that the inherited methods in B's
> interface happen to be duplicates of the behaviour of the same
> method in A (unless told otherwise), all that has been specified
> is how the interface of B relates to the interface of A.

But... without the implementation, all you have is a design, so I'm
not sure we can entirely discount it in defining "inheritance".

I'd quibble over calling the duplication a quirk--it's the whole
point.  You can pass a B to something expecting an A, and that
something will "see" it as an A.  And it will be, in fact, an A.

After all, inheritance is sometimes named "is-a".  I might casually
say I "inherited" a behavior from a friend, but I wouldn't mean it
in the OOP-ish sense, because there's no "is-a" relationship.  There
is more a "using", "supports" or "has-a" relationship.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Michael Mendelsohn wrote:

>> But, here's something to consider.  Actually talking to those two
>> printers uses a different language--there would be different
>> drivers speaking to those printers.
> 
> Not necessarily.
> Remember "Epson-compatible" printers?

That's just placing the specific driver in a different place.

> Also, I was living under the uninformed assumption that postscript
> printers with an ethernet interface had a universal way of being
> spoken to.

It may well be the case that, if you just send a PS document to a
printer as a data stream it will figure it out, but....

>> Even at the application level, when you select a different
>> printer, the dialog changes to indicate the properties of that
>> printer.
>>
>> That's not very polymorphous to me.
> 
> You're thinking local Windows printer.

....if you work in a world where, when you select a printer you can't
interact with things like paper trays or sizes or orientations, I'd
say you're missing something.  (Because the printers certainly are
capable of talking to you about those things.)

Now, to be fair, the PS example is quite a good argument in favor
of polymorphism (as I define it within OOP), because when you print
a PS document you are dealing with an abstract sub-set of something:
a (virtual) PostScript printer.

And, to me, a big part of the definition of (OOP-ish) polymorphism
does involve the idea of an abstract sub-set.

>>> So a MS Server and an Apache are instances of the same class?
>>
>> Externally they are pretty close.  [...]  But given that they both
>> offer very different capabilities, I don't think "instance" or
>> "polymorphism" is really an appropriate model.
> 
> There is no way of convincing you.

That may well be the case, because I may simply see things differently
and define my terms differently.  That doesn't mean either of us is
wrong or right.  We just have different ways of seeing it.  The fun
is in exploring those views.  Seeing yours enriches mine.  Hopefully
that works both ways.

This is probably a good point to elucidate my sense of polymorphism
AS IT APPLIES TO OOP.  (In the general sense, I hope I've made it
clear I fully appreciate you guys' point!)

First, two definitions.

Function Polymorphism.  Also called Function Overloading.  The ability
to have multiple functions with the same name, which are distinguished
by their "signatures"--that is, by their interface.

Object Polymorphism.  The ability to treat a set of different objects
(specifically, objects instanced from different classes) on the basis
of a common (often abstract) subset.  The important characteristic
here is that you treat the object per its subset and which method is
called is distinguished by the object's actual type (it may be the
"system" that figures this out, or it may be the object--particularly
in message-passing paradigms).

Now, a *defining* characteristic to me is the element of *dispatch*
(calling functions) based on data type--either at compile or run.

Keeping the above in mind, you may see--as we continue--why I have a
different view.

> Polymorphism is an appropriate model,...

(To you! [wink])

> ...because the morph they have in common is that of a web server
> that take html data and delivers it to clients using http; and the
> client need not know which server software is running, nor does
> the HTML author.

Yes, and the fact is, you could plug-n-chug servers and clients,
and the user wouldn't know the difference.

In contrast, consider that old Animal class example.  If you switch
Pigs for Dogs, you're going to get quite different results if you
send a "Speak" message!

> Of course this "base class" functionality has been extended in
> different ways in both kinds of software, which is why this
> serves as an example of polymorphism.

Maybe we can all be happy if we call this a *third* form of pm?
One in which the paradigm is "replacable" objects.

Although, to be honest, I still resist calling this pm, because I
see the "dispatch" aspect of it as central.

To illustrate what I'd think of as pm in the arena we're discussing,
it'd be like having a virtual "Printer" object to which I'd send all
"to be" printed data--B&W, Color, Circuit Diagrams, CAD plots, etc.

The Printer "object" would figure out--based on the type of the
document--which actual printer was appropriate.  Then, to me, your
virtual Printer would be polymorphic.

Ah, and maybe I've just stumbled on a simplified way to explain the
difference I see: in polymorphism, a *single* thing (e.g. variable
in a function) TAKES ON different shapes at different times.

'Sall in how you look at it.  (-:

Peas Out!!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Programmer Dude" <Chris@Sonnack.com> wrote in message <news:40363EBC.99CB9532@Sonnack.com>...

> Ian Woods wrote:
>
> >> And to monkey wrench my own sense, how about a webserver getting
> >> a request for "GET /".  Same client, same command, different
> >> results.
> >
> > And, just as importantly, different underlying behaviour.  Some
> > requests to some servers might involve merely fetching a file,
> > or running a CGI/ASP/PHP/<insert TLA here> script.
>
> Yep.  But,.... [grin] been thinking about this, and I've decided
> (in part to continue as Devil's Advocate, but also in because I
> just don't see the OOP sense of polymorphism here) I just don't
> see the OOP sense of polymorphism here.
>
> (I'll go into why in detail in my response to Michael.)

You can have polymorphism without explicit support from an OOP language.
The old UNIX character and block device driver interfaces are excellent
examples of this, as was the early 60's Sketchpad.  Maybe the confusion
comes from the multiple "flavors" of polymorphism.  "Static" polmorphism
is what you get with C++-style templates, "dynamic" polymorphism is what
"VB Classic" supports, and "inclusion" or "inclusive" polymorphism is
what most coOOol people think of as "*real* inheritance".

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Programmer Dude" <Chris@Sonnack.com> wrote in message <news:403639E3.1178EE0E@Sonnack.com>...

> Martin Eisenberg wrote:
>
> >> What prevents me, I think, from seeing network computing as
> >> "OOP" is the (to my eye) lack of inheritance and polymorphism.
> >
> > Since inheritance is defined mainly in terms of interfaces, might
> > one not see an "inheritance" language construct as mere syntactic
> > sugar for a certain kind of composition?
>
> I don't agree inheritance *is* defined mainly in terms of interfaces.
> To me, the thing about inheritance is inheriting *functionality*.
>
> One of the promises of OOP was "code re-use", which I always though
> broke down into (at least) two kinds.  First, there's re-use of
> code from project A in project B.  I always thought programmers have
> done *that* since card decks.  The second type, which I think OOP
> does provide nicely, is re-use of code *within* a project, and this
> is often done via inheritance.

You can also do it using static or dynamic polymorphism.
While you can do it via 'real' inheritance, just as often
you only get a mess:

 URL:http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

 URL:http://groups.google.com/groups?selm=GrE7F4.1s0x%40beaver.cs.washington.edu

 URL:http://www.eros-os.org/pipermail/e-lang/1998-October/002049.html

 URL:http://home.planet.nl/~faase009/AoP_OOCH.html

 URL:http://groups.google.com/groups?selm=3C9965ED.7060502%40psychogenic.com

I do not claim these links are definitive.  The links to the
DDJ "Java's new Considered Harmful" article are all borken
frex.

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Joe \"Nuke Me Xemu\" Foster wrote:

> You can have polymorphism without explicit support from an OOP
> language.

Indeed.

> Maybe the confusion comes from the multiple "flavors" of
> polymorphism.

I think so, too.  The term, polymorphism, is used in the biology
sciences, and in the sense they usually use it seems to apply more
(again, just to me) to this "network object polymorphism" thing.

(E.g. one form of "caste polymorphism" is male insects of the same
species differentiated into disparate roles (soldier or gatherer).
Similar--to my eye--are network printers, Color or B&W, which have
different roles but are still all "printers".)

> "Static" polmorphism is what you get with C++-style templates,
> "dynamic" polymorphism is what "VB Classic" supports,...

I'd consider static and dynamic as flavors of another way of
breaking them down (function or object).  (I'm assuming, by
static and dynamic, you mean "compile time" and "run time".)

> ...and "inclusion" or "inclusive" polymorphism is
> what most coOOol people think of as "*real* inheritance".

Many sources define them as synonymous.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Programmer Dude" <Chris@Sonnack.com> wrote in message <news:40365DB1.66A53297@Sonnack.com>...

> Joe \"Nuke Me Xemu\" Foster wrote:
>
> > You can have polymorphism without explicit support from an OOP
> > language.
>
> Indeed.
>
> > Maybe the confusion comes from the multiple "flavors" of
> > polymorphism.
>
> I think so, too.  The term, polymorphism, is used in the biology
> sciences, and in the sense they usually use it seems to apply more
> (again, just to me) to this "network object polymorphism" thing.
>
> (E.g. one form of "caste polymorphism" is male insects of the same
> species differentiated into disparate roles (soldier or gatherer).
> Similar--to my eye--are network printers, Color or B&W, which have
> different roles but are still all "printers".)

Watch out for the "platypus effect", where you might have a
mutant worker bee which can lay viable eggs, or a printer
designed to churn out color separations, which is neither
quite B&W fish nor quite Color fowl:

 URL:http://advogato.org/article/83.html

> > "Static" polmorphism is what you get with C++-style templates,
> > "dynamic" polymorphism is what "VB Classic" supports,...
>
> I'd consider static and dynamic as flavors of another way of
> breaking them down (function or object).  (I'm assuming, by
> static and dynamic, you mean "compile time" and "run time".)

I think so.  However, C++ templates may be more like "parametric
polymorphism" than "static polymorphism":

 URL:http://pmg.lcs.mit.edu/papers/thetaref/node8.html

> > ...and "inclusion" or "inclusive" polymorphism is
> > what most coOOol people think of as "*real* inheritance".
>
> Many sources define them as synonymous.

Many sources appear to equate "polymorphism" with "implementation
inheritance".  The definitions of the terms isn't very consistent
amongst various sources.  =(

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

"Programmer Dude" <Chris@Sonnack.com> wrote in message news:4030ECEF.F066617C@Sonnack.com...
> Noah Roberts wrote:
>
> >> ...objections to VB,...
> >
> > No bit shifting operators.
> > Non short-circuting logical operators (and, or).
> > The IDE has always pissed me off also.
>
> #3 is personal opinion, although I can understand your feelings.
> I do do a fair amount of VB editing in gvim.

Bit shift operators can be done with simple multiplies and divides
by constant, ie., a*16 is shift left 4, a/16 is shift right by 4.
In fact, in a half decent compiler, the two operators are performed
by the exact same code, since the compiler recognizes the constant
multiply or divide and performs the same output for it.

>
> #2 is more a language choice, I think, than an indicator of the
> "maturity" or "professionalism" of a language.  There is nothing
> to my mind intrinsically "correct" about short-circuiting logical
> ops.

In the "AMD x86 optimization guide" they detail the ways in which
C's short circuit evaluation actually HURTS optimal code generation.
Basically, it requires lots of jumps be inserted into the code, and
jumps are bad in superscalar processors, and it makes it impossible
for the compiler to reorder associative operators for best code
generation.

>
> #1 is a fair shot.  VB sucks at bit-level manipulation and lacks
> an unsigned integer type (one of *my* biggest gripes).  I solved
> that by writting a C DLL that provides a library of low-level
> stuff (and some string routines) for my VB programs.  Works great,
> and I get the best of both worlds.

VB is still interpreted, right ? Not the worlds most efficient
Basic implementation, so you get what you pay for. However, the
"faults" listed above were really "why isn't VB more like C".
Being like C is not all that great. How many C to .net or JVM
implementations do you see ? None. However, VB compiles to .net
because it has basic type protection.

VB is apples, C is oranges. The world does not need an amalgamation
of Basic and C.

>
> -- 
> |_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
> |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
> |_____________________________________________|_______________________|

Scott Moore schrieb:
> "Programmer Dude" <Chris@Sonnack.com> wrote in message news:4030ECEF.F066617C@Sonnack.com...
> > Noah Roberts wrote:
> > >> ...objections to VB,...
> > >
> > > No bit shifting operators.
> 
> Bit shift operators can be done with simple multiplies and divides
> by constant, ie., a*16 is shift left 4, a/16 is shift right by 4.
> In fact, in a half decent compiler, the two operators are performed
> by the exact same code, since the compiler recognizes the constant
> multiply or divide and performs the same output for it.


Well, does VB?

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

Programmer Dude schrieb:
> Michael Mendelsohn wrote:
> >> But, here's something to consider.  Actually talking to those two
> >> printers uses a different language--there would be different
> >> drivers speaking to those printers.
> >
> > Not necessarily.
> > Remember "Epson-compatible" printers?
> 
> That's just placing the specific driver in a different place.

Huh?
How can a driver be specific for a printer that didn't even exist when
the driver was written?
There is a level at which the differences are hidden, and that is the
level at which the objects are polymorphous.

> >>> So a MS Server and an Apache are instances of the same class?
> >>
> >> Externally they are pretty close.  [...]  But given that they both
> >> offer very different capabilities, I don't think "instance" or
> >> "polymorphism" is really an appropriate model.
> >
> > There is no way of convincing you.
> 
> That may well be the case, because I may simply see things differently
> and define my terms differently.  That doesn't mean either of us is
> wrong or right.  We just have different ways of seeing it.  The fun
> is in exploring those views.  Seeing yours enriches mine.  Hopefully
> that works both ways.

That is part of it, but I think you're also employing "no-win"
definitions with semi-circular logic. I may be wrong, though.

> This is probably a good point to elucidate my sense of polymorphism
> AS IT APPLIES TO OOP.  (In the general sense, I hope I've made it
> clear I fully appreciate you guys' point!)
> 
> First, two definitions.
> 
> Function Polymorphism.  Also called Function Overloading.  The ability
> to have multiple functions with the same name, which are distinguished
> by their "signatures"--that is, by their interface.

I think I have not provided examples for this. There have been
distributed systems ("Linda"?) that placed jobs in a central pool, and
free agents could pull tasks from the pool they'd be able to handle.
With a setup like this, a match could be made on function name AND data
type.

> Object Polymorphism.  The ability to treat a set of different objects
> (specifically, objects instanced from different classes) on the basis
> of a common (often abstract) subset.  The important characteristic
> here is that you treat the object per its subset and which method is
> called is distinguished by the object's actual type (it may be the
> "system" that figures this out, or it may be the object--particularly
> in message-passing paradigms).

That's what I thought I had found examples for.
 
> Now, a *defining* characteristic to me is the element of *dispatch*
> (calling functions) based on data type--either at compile or run.

Who is doing the dispatching? In a monolithic program, the issue is
moot, but in a distributed environment, there are different possible
answers.

> Keeping the above in mind, you may see--as we continue--why I have a
> different view.
> 
> > Polymorphism is an appropriate model,...
> 
> (To you! [wink])
> 
> > ...because the morph they have in common is that of a web server
> > that take html data and delivers it to clients using http; and the
> > client need not know which server software is running, nor does
> > the HTML author.
> 
> Yes, and the fact is, you could plug-n-chug servers and clients,
> and the user wouldn't know the difference.
> 
> In contrast, consider that old Animal class example.  If you switch
> Pigs for Dogs, you're going to get quite different results if you
> send a "Speak" message!

White and Yellow paper.
The animal just sends back different sound data; you could use a general
animal class with the sound being internal data. :) At least that's the
way your objection went earlier...

Oh, and tell a webserver to "speak" its version... ;)

> > Of course this "base class" functionality has been extended in
> > different ways in both kinds of software, which is why this
> > serves as an example of polymorphism.
> 
> Maybe we can all be happy if we call this a *third* form of pm?
> One in which the paradigm is "replacable" objects.
> 
> Although, to be honest, I still resist calling this pm, because I
> see the "dispatch" aspect of it as central.

I think some would lump all of my examples under inheritance, and we
seem to at least agree that inheritance is a useful concept to analyse
network computing.

> To illustrate what I'd think of as pm in the arena we're discussing,
> it'd be like having a virtual "Printer" object to which I'd send all
> "to be" printed data--B&W, Color, Circuit Diagrams, CAD plots, etc.
> 
> The Printer "object" would figure out--based on the type of the
> document--which actual printer was appropriate.  Then, to me, your
> virtual Printer would be polymorphic.

Have a program use a proxy to fetch a document by URI - the proxy could
be a nntp, http, gopher or ftp client to fulfil that request; some proxy
could be that and more, others would be less.

Where's your virtual printer "object" that is doing the dispatch?

> Ah, and maybe I've just stumbled on a simplified way to explain the
> difference I see: in polymorphism, a *single* thing (e.g. variable
> in a function) TAKES ON different shapes at different times.

The superset of all these shapes is another single shape that can be
used by you to refute yourself. :)
It all depends on where you locate the dispatch logic.

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

"Carl Gundel" <carlg@libertybasic.com> wrote in message <news:8203e17b.0402171259.44b74089@posting.google.com>...

> "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote in message news:<1076944899.255108@news-1.nethere.net>...

[stuff I agree with snipped]

> > what with the "fragile base class"
> > problem and the way both inheritance and methods break encapsulation:
>
> An OO language can be designed to prevent direct access to variables,
> and it would still be an OO language.  Also, if developers would
> simply use a little discipline and always use accessor methods instead
> of writing code that directly accessed variables, this would be a much
> less troublesome thing.  I've worked with people who shrug it off when
> I mention that directly accessing variables is a bad practice.  Oh
> well.

Apparently, even the accessor methods are Evil, Bad, and Wrong:

 URL:http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

--
Joe Foster <mailto:jlfoster%40znet.com>  Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Joe \"Nuke Me Xemu\" Foster schrieb:
> "Carl Gundel" <carlg@libertybasic.com> wrote in message 
> > An OO language can be designed to prevent direct access to variables,
> > and it would still be an OO language.  Also, if developers would
> > simply use a little discipline and always use accessor methods instead
> > of writing code that directly accessed variables, this would be a much
> > less troublesome thing.  I've worked with people who shrug it off when
> > I mention that directly accessing variables is a bad practice.  Oh
> > well.
> 
> Apparently, even the accessor methods are Evil, Bad, and Wrong:
> 
>  URL:http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

"Getter and setter methods (also known as accessors) are dangerous for
the same reason that public fields are dangerous: They provide external
access to implementation details. What if you need to change the
accessed field's type?"

Ok, in Delphi I can publish a field, and later retract that and rewrite
it to use accessors without changing outside code: the accessor will be
called implicitly when the "field" is accessed.

So if I need to change the type, I may provide a new interface to take
adavantage of that; and not to break old code, I write accessors for the
old field that can convert, flagging conversion errors if necessary.

Providing a public field is an interface abstraction; it makes certain
kinds of functions easier to use; and it doesn't constrain the
implentation in any way taht I can see.

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote in message news:<1077468049.846451@news-1.nethere.net>...
> "Carl Gundel" <carlg@libertybasic.com> wrote in message <news:8203e17b.0402171259.44b74089@posting.google.com>...
> > "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote in message news:<1076944899.255108@news-1.nethere.net>...
> > An OO language can be designed to prevent direct access to variables,
> > and it would still be an OO language.  Also, if developers would
> > simply use a little discipline and always use accessor methods instead
> > of writing code that directly accessed variables, this would be a much
> > less troublesome thing.  I've worked with people who shrug it off when
> > I mention that directly accessing variables is a bad practice.  Oh
> > well.
> 
> Apparently, even the accessor methods are Evil, Bad, and Wrong:
> 
>  URL:http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

Thanks for the link.  It actually goes out of its way to say that no
language feature is inherently evil.  Of course, accessors can be
abused.  In general, an object's public interface should present
behavior in an abstract way, as the article explains.  No argument
there.  However, one should never say never.  Accessor methods are
more abstract than the variables they service.  Software developers
are constantly required to make decisions.  Sometimes this means
choosing one evil over another, and sometimes there's no evil
involved.

My original point was that accessors are preferable to direct variable
access.  This is hard to argue against.   As for one object directly
modifying the instance variables of another (with or without
accessors).  How often should this be done?  As little as possible,
but doubtless there will be times when it will hard to avoid doing.

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

carlg@libertybasic.com (Carl Gundel) wrote in
news:8203e17b.0402221842.52257152@posting.google.com: 

> "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote in message
> news:<1077468049.846451@news-1.nethere.net>... 
>> "Carl Gundel" <carlg@libertybasic.com> wrote in message
>> <news:8203e17b.0402171259.44b74089@posting.google.com>... 
>> > "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote in message
>> > news:<1076944899.255108@news-1.nethere.net>... An OO language can
>> > be designed to prevent direct access to variables, and it would
>> > still be an OO language.  Also, if developers would simply use a
>> > little discipline and always use accessor methods instead of
>> > writing code that directly accessed variables, this would be a much 
>> > less troublesome thing.  I've worked with people who shrug it off
>> > when I mention that directly accessing variables is a bad practice.
>> >  Oh well.
>> 
>> Apparently, even the accessor methods are Evil, Bad, and Wrong:
>> 
>>  URL:http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.htm
>>  l 
> 
> Thanks for the link.  It actually goes out of its way to say that no
> language feature is inherently evil.  Of course, accessors can be
> abused.  In general, an object's public interface should present
> behavior in an abstract way, as the article explains.  No argument
> there.  However, one should never say never.  Accessor methods are
> more abstract than the variables they service.  Software developers
> are constantly required to make decisions.  Sometimes this means
> choosing one evil over another, and sometimes there's no evil
> involved.
>
> My original point was that accessors are preferable to direct variable
> access.  This is hard to argue against.   As for one object directly
> modifying the instance variables of another (with or without
> accessors).  How often should this be done?  As little as possible,
> but doubtless there will be times when it will hard to avoid doing.
> 
> -Carl Gundel, author of Liberty BASIC
> http://www.libertybasic.com

I actually agree with the article - quickly realising that it's not 
really about accessors at all! It's about 'solid' types being passed 
backwards and forwards through an object's interface. It isn't only 
'accessors' which run into this problem, though they are the most obvious 
case.

The biggest problem is that providing 'soft' types for passing the 
information to or from an object can be a hell of a lot of work in C++ 
and Java, though with the right reusable odds-n-sods and some suitably 
cautious operator overloading it should be simple enough to do in C++. 
(My experience of other OO languages isn't vast enough to comment more 
widely with surety... so I won't!). 

By a 'soft' type, I mean a type which could be altered (internally)
without automatically requiring changes in all the using code. 
Essentially, they would all simply be classes with only the abilities 
that are required for passing the information from the caller to the 
callee (or vice versa). So, instead of returning a width for a graphical 
object as an 'unsigned int', say... you'd have a dedicated type. 
Obviously, if you're defining piles new types all of which are restricted 
forms of 'unsigned int'... unless it can be done painlessly you'll spend 
a lot of time writing code for them instead of the interesting stuff 
you're actually paid for.

Having these sorts of types, in the right framework, would be terribly 
useful. Not only is 'how they work' hidden but they can check their own 
values for correctness and, potentially, allow 'dimensional' checking of 
expressions using them.

Ian Woods

-- 
"I'm a paranoid schizophrenic sado-masochist.
My other half's out to get me and I can't wait."
Richard Heathfield

In article <Xns94983DCF9DF7Dnewspubwuggyorg@217.32.252.50>, Ian Woods <newspub2@wuggyNOCAPS.org> wrote:
>By a 'soft' type, I mean a type which could be altered (internally)
>without automatically requiring changes in all the using code. 
>Essentially, they would all simply be classes with only the abilities 
>that are required for passing the information from the caller to the 
>callee (or vice versa). So, instead of returning a width for a graphical 
>object as an 'unsigned int', say... you'd have a dedicated type. 
>Obviously, if you're defining piles new types all of which are restricted 
>forms of 'unsigned int'... unless it can be done painlessly you'll spend 
>a lot of time writing code for them instead of the interesting stuff 
>you're actually paid for.
>
>Having these sorts of types, in the right framework, would be terribly 
>useful. Not only is 'how they work' hidden but they can check their own 
>values for correctness and, potentially, allow 'dimensional' checking of 
>expressions using them.

I'm not sure how bad this tends to be in practice - a lot of types can 
be modelled for all foreseeable purpose as ints under 2000000000 [I tend 
to start with signed ints by default even when it will probably be an 
unsigned value, because that is a realistic change that may happen.  
Insisting that ints be unsigned if appropriate seems a little finicky to 
me - I can see the point, but I can also see it bringing grief.]

If only the values are changing, and they aren't going to exceed the 
maximum int, you can have an informational function
int GetMaximumPictureWidth()

..to go with
SetPictureWidth( int )
int GetPictureWidth()

That way moderate changes to the class can be conveyed without changing 
output types.  Most of the time, it may be enough. 

Gerry Quinn                                   
-- 
http://bindweed.com 
Screensavers, Games, Kaleidoscopes
Download free trial versions

"Michael Mendelsohn" <keine.Werbung.1300@michael.mendelsohn.de> wrote in message news:403817C2.AE82E17E@michael.mendelsohn.de...
> Scott Moore schrieb:
> > "Programmer Dude" <Chris@Sonnack.com> wrote in message news:4030ECEF.F066617C@Sonnack.com...
> > > Noah Roberts wrote:
> > > >> ...objections to VB,...
> > > >
> > > > No bit shifting operators.
> >
> > Bit shift operators can be done with simple multiplies and divides
> > by constant, ie., a*16 is shift left 4, a/16 is shift right by 4.
> > In fact, in a half decent compiler, the two operators are performed
> > by the exact same code, since the compiler recognizes the constant
> > multiply or divide and performs the same output for it.
>
>
> Well, does VB?
>

Yes, VB has multiply and divide, and yes, those produce the same effect
as shifts. I think you mean "does it do that optimally", VB does nothing
optimally. Its an interpreter. That has nothing to do with its ability
to shift bits.

> mendel
> -- 
> Feel the stare of my burning hamster and stop smoking!

"Scott Moore" <samiam@moorecad.com> wrote in message <news:lTC_b.111989$jk2.501951@attbi_s53>...

> "Michael Mendelsohn" <keine.Werbung.1300@michael.mendelsohn.de> wrote in message news:403817C2.AE82E17E@michael.mendelsohn.de...
> > Scott Moore schrieb:
> > > "Programmer Dude" <Chris@Sonnack.com> wrote in message news:4030ECEF.F066617C@Sonnack.com...
> > > > Noah Roberts wrote:
> > > > >> ...objections to VB,...
> > > > >
> > > > > No bit shifting operators.
> > >
> > > Bit shift operators can be done with simple multiplies and divides
> > > by constant, ie., a*16 is shift left 4, a/16 is shift right by 4.
> > > In fact, in a half decent compiler, the two operators are performed
> > > by the exact same code, since the compiler recognizes the constant
> > > multiply or divide and performs the same output for it.
> >
> >
> > Well, does VB?

> Yes, VB has multiply and divide, and yes, those produce the same effect
> as shifts. I think you mean "does it do that optimally", VB does nothing
> optimally. Its an interpreter. That has nothing to do with its ability
> to shift bits.

VB5 and 6 use the same code generator and optimizer that Visual C++
uses.  Anyway, since Intel removed the barrel shifters from their
newer CPU cores, it probably doesn't matter much what multiplications
and divisions by powers of two in VB get compiled to.

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Joe "Nuke Me Xemu" Foster wrote:

> 
> 
> VB5 and 6 use the same code generator and optimizer that Visual C++
> uses.  Anyway, since Intel removed the barrel shifters from their
> newer CPU cores, it probably doesn't matter much what multiplications
> and divisions by powers of two in VB get compiled to.

Except that Intel isn't the only CPU manufacturer nor are they 
guaranteed to continue with this design.  Pluss this is the newer models 
you speak of, what about the others?

-- 
"I'm a war president.  I make decisions here in the Oval Office
  in foreign policy matters with war on my mind." - Bush

"Noah Roberts" <nroberts@dontemailme.com> wrote in message <news:Dvedner05O0yl6bdRVn-jg@scnresearch.com>...

> Joe "Nuke Me Xemu" Foster wrote:

> > VB5 and 6 use the same code generator and optimizer that Visual C++
> > uses.  Anyway, since Intel removed the barrel shifters from their
> > newer CPU cores, it probably doesn't matter much what multiplications
> > and divisions by powers of two in VB get compiled to.
>
> Except that Intel isn't the only CPU manufacturer nor are they
> guaranteed to continue with this design.  Pluss this is the newer models
> you speak of, what about the others?

True.  After compiling some test code with all the optimizations
selected, here's what I got in a disassembly listing in VC++:

135:    i = i * 16
004066A9   shl         edi,4
136:    Print i;
004066AC   push        edi
004066AD   push        esi
004066AE   push        offset ___vba@00195354(0x00403424)
004066B3   call        dword ptr [__imp____vbaPrintObj(0x0040c348)]
004066B9   add         esp,0Ch
137:    i = i * 32
004066BC   shl         edi,5
138:    Print i;
004066BF   push        edi
004066C0   push        esi
004066C1   push        offset ___vba@00195354(0x00403424)
004066C6   call        dword ptr [__imp____vbaPrintObj(0x0040c348)]
139:    i = i \ 64
140:    Print i
004066CC   mov         eax,edi
004066CE   add         esp,0Ch
004066D1   cdq
004066D2   and         edx,3Fh
004066D5   add         eax,edx
004066D7   sar         eax,6
004066DA   push        eax
004066DB   push        esi
004066DC   push        offset ___vba@00195388(0x0040344c)
004066E1   call        dword ptr [__imp____vbaPrintObj(0x0040c348)]

Looks like VB can store variables in registers, convert integer
multiplication and division to bit-shifts, and run with scissors
when it comes to integer arithmetic in general.  When I turned
integer overflow checking back on and recompiled, the SHL opcodes
turned back into IMUL followed by JO. (Jump if Overflow?)

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Scott Moore wrote:

> VB is still interpreted, right ?

No, it's compiled.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Michael Mendelsohn wrote:

> "Getter and setter methods (also known as accessors) are dangerous
> for the same reason that public fields are dangerous: They provide
> external access to implementation details. What if you need to
> change the accessed field's type?"
> 
> Ok, in Delphi I can publish a field, and later retract that and
> rewrite it to use accessors without changing outside code: the
> accessor will be called implicitly when the "field" is accessed.

You're saying Delphi supports something like (imaginary syntax):

	my_foo: foo        -- instance a "foo" object
	my_foo.a = 42      -- set public field

After redefining:

	my_foo: foo
	my_foo.a = 42      -- set via "setter" function

That is, the syntax is the same for the client?  (This would be
like VB's Property class methods--looks syntactically like a field,
works like a function.)


> Providing a public field is an interface abstraction;

Class "field" is one of those "how do YOU define it words" to me.
Do you mean static "variables" or *any* access (such as a property
or method)?  To me--and I may be ignorant here--"field" is a very
generic term that could mean almost anything.

I have to admit, I sometimes find myself wondering about making
(what I prefer to call) instance variables public when I find myself
writing matching get/set methods that do little more than their name
implies.  (And I do know that many experts suggest that this means
you need to rethink your entire design.)

If I have, for example, a read-only "field", it's nice to be able
to write a get, but not a set.

Or, if "fields" need to be validated--say a "current index" field
of some list type--then also great.

But--and maybe the article will answer this, haven't had a chance
to finish it yet--it seems to me that objects have "fields" and
those fields have types.  I don't see how you can get/set data to
any object without knowing the type of that data.

So, to me (so far), the whole "Getter/Setter Is Evil" has a point,
but..... [shrug]

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude wrote:

<snip>

> But--and maybe the article will answer this, haven't had a chance
> to finish it yet--it seems to me that objects have "fields" and
> those fields have types.  I don't see how you can get/set data to
> any object without knowing the type of that data.

Well, one way (and I'm /not/ saying it's the best way) is to pass in a 
string.

For example, let's say you have an Employee class, and your program needs to 
set an employee's working hours for the week gone by. The relevant 
information might be stored like this:

int hours;

Or like this:

double hours;

Or like this:

int hours;
int minutes;

Or like this:

int quarterHours;

or in some other way. Note that at least one of these implementations is 
split across two different member variables.

The caller need not know any of this. It could simply pass in a string, such 
as: "43:28". (The interface documentation would of course specify the 
required format -- here, clearly, it's hours and minutes.)

The "hours:minutes" format is sufficiently "real world" that it makes some 
kind of sense in the calling code, no matter what the underlying 
implementation is.

The class itself has responsibility for parsing the string appropriately. In 
the event that a better underlying implementation is chosen, it would of 
course be the class maintainer's job to ensure that the parser is changed 
accordingly. The calling code need not change.

Does that help, or have I completely missed what you were getting at?

> So, to me (so far), the whole "Getter/Setter Is Evil" has a point,
> but..... [shrug]

Sorry to have to agree with you, but I think you're right. At least, I think 
that a true setter (and of course a true getter) shouldn't have the 
slightest idea what the underlying implementation is. It should couch its 
interface in terms of what makes sense to the caller, not what makes sense 
to the implementation.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Programmer Dude schrieb:
> Michael Mendelsohn wrote:
> > "Getter and setter methods (also known as accessors) are dangerous
> > for the same reason that public fields are dangerous: They provide
> > external access to implementation details. What if you need to
> > change the accessed field's type?"
> >
> > Ok, in Delphi I can publish a field, and later retract that and
> > rewrite it to use accessors without changing outside code: the
> > accessor will be called implicitly when the "field" is accessed.
> 
> You're saying Delphi supports something like (imaginary syntax):


type 
   foo = class ()
      public 
         a : Integer;
   end;

>         my_foo: foo        -- instance a "foo" object
>         my_foo.a := 42      -- set public field

 
> After redefining:


type 
   foo = class ()
      private
         Fa : String;
	 function Geta: Integer;       // converts Fa to Int
	 procedure Seta(a : Integer);  // converts a to string -> Fa
      public 
         property a : Integer read Geta write Seta;
   end;

>         my_foo: foo
>         my_foo.a := 42      -- set via "setter" function

Right, this now calls Seta.

> That is, the syntax is the same for the client?  (This would be
> like VB's Property class methods--looks syntactically like a field,
> works like a function.)

Yes.
I didn't know VB has properties as well.

> > Providing a public field is an interface abstraction;
> 
> Class "field" is one of those "how do YOU define it words" to me.
> Do you mean static "variables" or *any* access (such as a property
> or method)?  To me--and I may be ignorant here--"field" is a very
> generic term that could mean almost anything.

I tried to not be language specific; just wanted to distingish a
variable-type access from a function call-type access; variable-type
meaning using the assignment operator := for access, and function-type
using a (parameter list).

> If I have, for example, a read-only "field", it's nice to be able
> to write a get, but not a set.

In Delphi, simply don't declare the "write" method.

	property a : Integer read Geta;

If you don't need code to access it, you could also do
         
   private
      Fa : Integer;
   public
      property a: Integer read Fa;

This makes a read-only, and a read accesses Fa without calling code.

You can also do the reverse to get write-only properties, or you could
declare a property that accesses the value directly when reading (get)
and calls a function (to validate) when writing (set).

> But--and maybe the article will answer this, haven't had a chance
> to finish it yet--it seems to me that objects have "fields" and
> those fields have types.  I don't see how you can get/set data to
> any object without knowing the type of that data.

You don't need to know the type that's used internally.
You need to know which type the interface expects you to use.
In the example above, you couldn't care less that I used a Stringtype to
hold the data - what you need to know is that you can access a as you
would an Integer type field.

(The motivation to do it that way might be that foo also offers a
GetAasString method, which is called more often than a is set or read,
so we've changed foo to store a as string for performance reasons.
Implementation independent of interface!)

> So, to me (so far), the whole "Getter/Setter Is Evil" has a point,
> but..... [shrug]

Imagine you've made a random generator class.
You want the user to be able to set a seed, and you also want the
current state to be accessible so the user can duplicate runs. 
I think the conceptually easiest way is to offer a "Seed : unsigned
Long" property, and have the implied setter do whatever needs to be done
to adjust internal data structures.
Any other way to achieve the same would be more kludgy to use, IMHO.

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

Michael Mendelsohn wrote:

> [snip Delphi example]

Interesting!  Wasn't familiar at all with Delphi's OO syntax.  Thanks!!


> I didn't know VB has properties as well.

Yep.  I have mixed feelings about them sometimes.  They're nice
syntactically, but it's also nice having it obvious when you're
using a method verses a variable.


>> Class "field" is one of those "how do YOU define it words" to me.
>> Do you mean static "variables" or *any* access (such as a property
>> or method)?  To me--and I may be ignorant here--"field" is a very
>> generic term that could mean almost anything.
> 
> I tried to not be language specific; just wanted to distingish a
> variable-type access from a function call-type access; variable-type
> meaning using the assignment operator := for access, and function-
> type using a (parameter list).

Just to make sure I understand, "field" would apply to the variable-
type access, yes?


>> If I have, for example, a read-only "field", it's nice to be able
>> to write a get, but not a set.
> 
> In Delphi, simply don't declare the "write" method.
> 
>         property a : Integer read Geta;

Right.

Now,... I wonder if a syntactic mechanism like this is the very sort
of thing that Allen Holub (author of that JavaWorld "no get/sets"
article) has in mind.  What I mean is that the mechanism makes it
very easy to create those "plain brown" getter/setter methods, which
seem to be his main complaint....

But it may be that the real complaint is more about a class *design*
that *requires* (or strongly suggests) access to the member data from
outside the class.

A trivial example:

	class point_2d {                 // BAD DESIGN
	    double  m_x, m_y;
	public:
	    void  x(double new_x) { m_x=x; }
	    void  y(double new_y) { m_y=y; }
	    void  xy(double new_x, double new_y) { m_x=x; m_y=y; }

	    point_2d ():m_x(0), m_y(0) {}
	};

	class point_2d {                 // BETTER DESIGN
	    double  m_x, m_y;
	public:
	    void  move(double new_x, double new_y) { m_x=x; m_y=y; }

	    point_2d ():m_x(0), m_y(0) {}
	};

All that's really changed is the *semantics* of the design.  The
first design pretty much "lifts its skirts".  The second design
presents a more sensible interface--implementation could be quite
different.


>> But--and maybe the article will answer this, haven't had a chance
>> to finish it yet--it seems to me that objects have "fields" and
>> those fields have types.  I don't see how you can get/set data to
>> any object without knowing the type of that data.
> 
> You don't need to know the type that's used internally.
> You need to know which type the interface expects you to use.
> In the example above, you couldn't care less that I used a
> Stringtype to hold the data - what you need to know is that
> you can access a as you would an Integer type field.

Very Much Agreed.  Which I think brings me back to what bothered me
about that article.  Getter/Setter methods--unless one is validating
data or preventing read or write--seem pretty silly to me.

But *Data Access Methods*  (which are *decoupled* from the internal
representation) seem like a good idea to me.

>> So, to me (so far), the whole "Getter/Setter Is Evil" has a point,
>> but..... [shrug]
> 
> Imagine you've made a random generator class.
> You want the user to be able to set a seed, and you also want the
> current state to be accessible so the user can duplicate runs.
> I think the conceptually easiest way is to offer a "Seed : unsigned
> Long" property, and have the implied setter do whatever needs to be
> done to adjust internal data structures.
> Any other way to achieve the same would be more kludgy to use, IMHO.

To quote Big (John!) in the Last Episode, "Abso-[elided]-lutely!"

I think you and I are on the same page.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Richard Heathfield wrote:

>> I don't see how you can get/set data to any object without knowing
>> the type of that data.
> 
> Well, one way (and I'm /not/ saying it's the best way) is to pass
> in a string.
> 
> [masso-snip]
> 
> Does that help, or have I completely missed what you were getting at?

You're definitely in the right area.  Generic data.  Hmmmm.

You're right to suggest it may not be ideal, and even string data has
some potential to be a "type"-type problem.  For example, when you
switch to Unicode or some other language.  Plus I can see issues with
highly structured data...


>> So, to me (so far), the whole "Getter/Setter Is Evil" has a point,
>> but..... [shrug]
> 
> Sorry to have to agree with you, but I think you're right.

[grin] I'll try to be more frustrating in the future!

> At least, I think that a true setter (and of course a true getter)
> shouldn't have the slightest idea what the underlying implementation
> is. It should couch its interface in terms of what makes sense to
> the caller, not what makes sense to the implementation.

*Exactly*


-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Michael Mendelsohn wrote:

>>>> ...there would be different drivers speaking to those printers.
>>>
>>> Not necessarily.
>>> Remember "Epson-compatible" printers?
>>
>> That's just placing the specific driver in a different place.
> 
> Huh?

I said, "THAT'S JUST PLACING THE SPECIFIC DRIVER IN A DIFFERENT PLACE!"

> How can a driver be specific for a printer that didn't even exist
> when the driver was written?

The driver is specific to an Epson printer or a printer that looks
like an Epson printer.

> There is a level at which the differences are hidden, and that is
> the level at which the objects are polymorphous.

[shrug] As I've said, I understand your point, I just don't see it
quite that way.  I don't call a printer pretending to be some other
printer polymorphism (for reasons I've detailed in earlier posts,
but in summary, *to* *me* OOP polymorphism is mostly about dynamic
dispatch).


>> We just have different ways of seeing it.  The fun is in exploring
>> those views.  Seeing yours enriches mine.  Hopefully that works
>> both ways.
> 
> That is part of it, but I think you're also employing "no-win"
> definitions with semi-circular logic. I may be wrong, though.

I hope so, because that's not on my menu!  (-:

>> Function Polymorphism.  Also called Function Overloading....
> 
> I think I have not provided examples for this. There have been
> distributed systems ("Linda"?) that placed jobs in a central pool,
> and free agents could pull tasks from the pool they'd be able to
> handle.  With a setup like this, a match could be made on function
> name AND data type.

Sounds like a Collection with multi-variable lookup to me.

>> Object Polymorphism.  [...] The important characteristic
>> here is that you treat the object per its subset and which
>> method is called is distinguished by the object's actual type...
> 
> That's what I thought I had found examples for.

[shrug] All I can say is they don't say "polymorphism" to me.  (-:
Because...

>> Now, a *defining* characteristic to me is the element of *dispatch*
>> (calling functions) based on data type--either at compile or run.
> 
> Who is doing the dispatching? In a monolithic program, the issue is
> moot, but in a distributed environment, there are different possible
> answers.

But once you're talking to a specific network device, you're talking
to that device.  No dispatching.  An example that sprung to my mind
that would be hard to deny as polymorphic would be a virtual printer
that dispatched print jobs to various real printers depending on the
nature of the print job.


>> In contrast, consider that old Animal class example.  If you switch
>> Pigs for Dogs, you're going to get quite different results if you
>> send a "Speak" message!
> 
> White and Yellow paper.
> The animal just sends back different sound data; you could use a
> general animal class with the sound being internal data. :)

But notice an important difference.  If a printer can support both
colors of paper, there's no polymorphism, just different "instance
data values".

Compare that to the dog and pig classes.  Dogs ne'er go "Oink", nor
pigs "Woof!"  (Well, normally! :-)


> Oh, and tell a webserver to "speak" its version... ;)

Instance data values!  (-:


>> Although, to be honest, I still resist calling this pm, because I
>> see the "dispatch" aspect of it as central.
> 
> I think some would lump all of my examples under inheritance, and we
> seem to at least agree that inheritance is a useful concept to
> analyse network computing.

Absolutely!


>> The Printer "object" would figure out--based on the type of the
>> document--which actual printer was appropriate.  Then, to me, your
>> virtual Printer would be polymorphic.
> 
> Have a program use a proxy to fetch a document by URI - the proxy
> could be a nntp, http, gopher or ftp client to fulfil that request;
> some proxy could be that and more, others would be less.

Not sure I follow your example.  Sounds like the program would need
to select a proxy from a set of available ones depending on the URI?

> Where's your virtual printer "object" that is doing the dispatch?

I *definitely* don't follow the question!  (Sorry, I'm sure the error
is mine.)

>> Ah, and maybe I've just stumbled on a simplified way to explain the
>> difference I see: in polymorphism, a *single* thing (e.g. variable
>> in a function) TAKES ON different shapes at different times.
> 
> The superset of all these shapes is another single shape that can
> be used by you to refute yourself. :)
> It all depends on where you locate the dispatch logic.

Nope, you've definitely lost me in the last few paragraphs.  :-(

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Michael Mendelsohn" <keine.Werbung.1300@michael.mendelsohn.de> wrote in message <news:40390B36.8DDFD6CD@michael.mendelsohn.de>...

> Joe \"Nuke Me Xemu\" Foster schrieb:

> > Apparently, even the accessor methods are Evil, Bad, and Wrong:
> >
> >  URL:http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
>
> "Getter and setter methods (also known as accessors) are dangerous for
> the same reason that public fields are dangerous: They provide external
> access to implementation details. What if you need to change the
> accessed field's type?"
>
> Ok, in Delphi I can publish a field, and later retract that and rewrite
> it to use accessors without changing outside code: the accessor will be
> called implicitly when the "field" is accessed.
>
> So if I need to change the type, I may provide a new interface to take
> adavantage of that; and not to break old code, I write accessors for the
> old field that can convert, flagging conversion errors if necessary.
>
> Providing a public field is an interface abstraction; it makes certain
> kinds of functions easier to use; and it doesn't constrain the
> implentation in any way taht I can see.

Sure, like the following in VB:

----Class Polar----
Implements Cartesian

Private Type Stash
  R As Double
  Theta As Double
End Type

Private This As Stash

Public Property Get R() As Double
  R = This.R
End Property

Public Property Let R(ByVal NewR As Double)
  If NewR < 0 Then Error EInvalid
  This.R = NewR
End Property

Public Property Get Theta() As Double
  If Theta < 0 Or Theta > 2 * Pi Then Error EInvalid
  Theta = This.Theta
End Property

Public Property Let Theta(ByVal NewTheta As Double)
  This.Theta = NewTheta
End Property

Private Property Get Cartesian_X() As Double
  Cartesian_X = This.R * Cos(This.Theta)
End Property

Private Property Get Cartesian_Y() As Double
  Cartesian_Y = This.R * Sin(This.Theta)
End Property
----

--
Joe Foster <mailto:jlfoster%40znet.com>  Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Programmer Dude schrieb:
> Michael Mendelsohn wrote:
> > I didn't know VB has properties as well.
> 
> Yep.  I have mixed feelings about them sometimes.  They're nice
> syntactically, but it's also nice having it obvious when you're
> using a method verses a variable.

Why?
To be more aware of side effects?
If I had an "address" class, and setting the zip code changes the city,
and setting the city changes the zip code, one _would_ want to be aware
of this. ;)

> >> Class "field" is one of those "how do YOU define it words" to me.
> >> Do you mean static "variables" or *any* access (such as a property
> >> or method)?  To me--and I may be ignorant here--"field" is a very
> >> generic term that could mean almost anything.
> >
> > I tried to not be language specific; just wanted to distingish a
> > variable-type access from a function call-type access; variable-type
> > meaning using the assignment operator := for access, and function-
> > type using a (parameter list).
> 
> Just to make sure I understand, "field" would apply to the variable-
> type access, yes?

Yes, meaning variables and properties and whatnot.
In another context, I'd probably use the word differently.

> Now,... I wonder if a syntactic mechanism like this is the very sort
> of thing that Allen Holub (author of that JavaWorld "no get/sets"
> article) has in mind.  What I mean is that the mechanism makes it
> very easy to create those "plain brown" getter/setter methods, which
> seem to be his main complaint....

This mechanism makes it unnecessary to create them in the first place if
they have no function other than to pass a value; you don't lose
flexibility if you don't.
 
> But it may be that the real complaint is more about a class *design*
> that *requires* (or strongly suggests) access to the member data from
> outside the class.

I took the complaint to be about a class design that says "we don't know
how this class will be used, so we'll just make everything wide open and
let the other guys figure it out." This means that you can code
functionality outside the class that really should be inside it.

The Delphi designers like to make a fairly "closed" class, and for those
who like to twiddle the insides derive a descendant class that exposes
some of the protected properties of the base class.

[example using 2D point with coord fields exposed / unexposed]

> All that's really changed is the *semantics* of the design.  The
> first design pretty much "lifts its skirts".  The second design
> presents a more sensible interface--implementation could be quite
> different.

Which one of these is more sensible stands to reason - it depends on how
they're going to be used! (Your single coord setters can move the object
horizontally or vertically and do that more cheaply than the generic
move). I got that from the Simula/Smalltalk article: that an object's
member define its goals. If you limit these appropriately, you can
communicate better what this object would be effective at.

Holub is with me on this: hide the implementation details and make the
interface fit the way you want to use the class; let the class do as
much work on its own data as it can.

The offshoot is that any usenet discussion of this is going to be fairly
academic; to judge a design style, you have to see a complete design,
which is slightly out of my posting scope. ;)

> > You don't need to know the type that's used internally.
> > You need to know which type the interface expects you to use.
> > In the example above, you couldn't care less that I used a
> > Stringtype to hold the data - what you need to know is that
> > you can access a as you would an Integer type field.
> 
> Very Much Agreed.  Which I think brings me back to what bothered me
> about that article.  Getter/Setter methods--unless one is validating
> data or preventing read or write--seem pretty silly to me.

Yes!

> But *Data Access Methods*  (which are *decoupled* from the internal
> representation) seem like a good idea to me.

Yes!

> I think you and I are on the same page.

In the same class? ;)

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

"Programmer Dude" <Chris@Sonnack.com> wrote in message <news:403BD07C.8A4E68AC@Sonnack.com>...

> Michael Mendelsohn wrote:

> > I didn't know VB has properties as well.
>
> Yep.  I have mixed feelings about them sometimes.  They're nice
> syntactically, but it's also nice having it obvious when you're
> using a method verses a variable.

Only VB4 had "real" Public class member variables. VB5 and 6
treat them as syntactic sugar for an (unnamed) Private variable
plus a set of Public Property Get/Let/Set procedures.  This may
have broken some code which depended on passing a property's
value to a subroutine by reference, changing the value, and
expecting the new value to "stick" after the subroutine exits.

> > You don't need to know the type that's used internally.
> > You need to know which type the interface expects you to use.
> > In the example above, you couldn't care less that I used a
> > Stringtype to hold the data - what you need to know is that
> > you can access a as you would an Integer type field.
>
> Very Much Agreed.  Which I think brings me back to what bothered me
> about that article.  Getter/Setter methods--unless one is validating
> data or preventing read or write--seem pretty silly to me.
>
> But *Data Access Methods*  (which are *decoupled* from the internal
> representation) seem like a good idea to me.

Holub appears to want to go further, in that objects should even
be responsible for their own UI, if any.  This can be problematic
with objects from third-party libraries, unless you're using the
Officially Approved B&D GUI such as Java's Swing. =)

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Joe \"Nuke Me Xemu\" Foster schrieb:
> Sure, like the following in VB:

Nice, we get a VB example as well! :)

> ----Class Polar----
> Implements Cartesian
> 
> Private Type Stash
>   R As Double
>   Theta As Double
> End Type
> 
> Private This As Stash
> 
> Public Property Get R() As Double
>   R = This.R
> End Property
> 
> Public Property Let R(ByVal NewR As Double)
>   If NewR < 0 Then Error EInvalid
>   This.R = NewR
> End Property
> 
> Public Property Get Theta() As Double
>   If Theta < 0 Or Theta > 2 * Pi Then Error EInvalid
>   Theta = This.Theta
> End Property

Shouldn't the IF line be in "Let Theta"?
 
> Public Property Let Theta(ByVal NewTheta As Double)
>   This.Theta = NewTheta
> End Property
> 
> Private Property Get Cartesian_X() As Double
>   Cartesian_X = This.R * Cos(This.Theta)
> End Property
> 
> Private Property Get Cartesian_Y() As Double
>   Cartesian_Y = This.R * Sin(This.Theta)
> End Property
> ----

I'm never going to learn VB! This looks way too ugly...

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

"Michael Mendelsohn" <keine.Werbung.1300@michael.mendelsohn.de> wrote in message <news:403BED9D.C8631AE8@michael.mendelsohn.de>...

> Joe \"Nuke Me Xemu\" Foster schrieb:
> > Sure, like the following in VB:
>
> Nice, we get a VB example as well! :)
>
> > ----Class Polar----
> > Implements Cartesian
> >
> > Private Type Stash
> >   R As Double
> >   Theta As Double
> > End Type
> >
> > Private This As Stash
> >
> > Public Property Get R() As Double
> >   R = This.R
> > End Property
> >
> > Public Property Let R(ByVal NewR As Double)
> >   If NewR < 0 Then Error EInvalid
> >   This.R = NewR
> > End Property
> >
> > Public Property Get Theta() As Double
> >   If Theta < 0 Or Theta > 2 * Pi Then Error EInvalid
> >   Theta = This.Theta
> > End Property
>
> Shouldn't the IF line be in "Let Theta"?

D'oh!

> > Public Property Let Theta(ByVal NewTheta As Double)
> >   This.Theta = NewTheta
> > End Property
> >
> > Private Property Get Cartesian_X() As Double
> >   Cartesian_X = This.R * Cos(This.Theta)
> > End Property
> >
> > Private Property Get Cartesian_Y() As Double
> >   Cartesian_Y = This.R * Sin(This.Theta)
> > End Property
> > ----
>
> I'm never going to learn VB! This looks way too ugly...

The IDE does some of the work for you, like creating the stubs.
Much of the "ugliness" traces back to how form and control event
handlers worked in VB 1.0 and attempts to maintain uniform syntax.
My tomfoolery with "Stash" and "This" isn't strictly necessary
but does seem to make a number of things easier in the long run.

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Joe \"Nuke Me Xemu\" Foster wrote:

>> I have mixed feelings about [properties] sometimes.  They're nice
>> syntactically, but it's also nice having it obvious when you're
>> using a method verses a variable.
> 
> Only VB4 had "real" Public class member variables. VB5 and 6
> treat them as syntactic sugar for an (unnamed) Private variable
> plus a set of Public Property Get/Let/Set procedures.

Which illustrates the point beautifully.  I had no idea that was
the case (although it does make sense when you consider how VB
works).

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Joe \"Nuke Me Xemu\" Foster wrote:

> My tomfoolery with "Stash" and "This" isn't strictly necessary
> but does seem to make a number of things easier in the long run.

I was wondering what the utility of the Private Type was.  The only
other person I've seen do that is our own EN.

Don't you get the same effect (as with "This") using "Me"?

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Michael Mendelsohn wrote:

>> I have mixed feelings about [properties] sometimes.  They're nice
>> syntactically, but it's also nice having it obvious when you're
>> using a method verses a variable.
> 
> Why?  To be more aware of side effects?

Yep.

> If I had an "address" class, and setting the zip code changes the
> city, and setting the city changes the zip code, one _would_ want
> to be aware of this. ;)

Exactly!


>> What I mean is that the mechanism makes it very easy to create
>> those "plain brown" getter/setter methods, which seem to be his
>> main complaint....
> 
> This mechanism makes it unnecessary to create them in the first
> place if they have no function other than to pass a value; you
> don't lose flexibility if you don't.

Well right, but what I'm saying is that the language gives you a
mechanism that makes it very easy to expose the implementation (in
the hands of a less knowledgeable programmer, I mean).

One question.  Would this work:

	private
	    Fa : Integer;
	public
	    property a: String read Fa;

That is, would there be a type conversion without writing any more
code?  That would at least decouple the property type from the
underlying representation.


>> But it may be that the real complaint is more about a class *design*
>> that *requires* (or strongly suggests) access to the member data
>> from outside the class.
> 
> I took the complaint to be about a class design that says "we don't
> know how this class will be used, so we'll just make everything wide
> open and let the other guys figure it out."

[grin] I think we're saying the same thing.  You seem to be addressing
the "why"; I only touched on the "what".


> The Delphi designers like to make a fairly "closed" class, and for
> those who like to twiddle the insides derive a descendant class
> that exposes some of the protected properties of the base class.

Heh.  That Allen Holub mentions in one of those articles that
"protected" attributes are an abomination.  I've heard the attitude
before--some feel they break encapsulation.


>> All that's really changed is the *semantics* of the design.  The
>> first design pretty much "lifts its skirts".  The second design
>> presents a more sensible interface--implementation could be quite
>> different.
> 
> Which one of these is more sensible stands to reason - it depends
> on how they're going to be used! (Your single coord setters can
> move the object horizontally or vertically and do that more cheaply
> than the generic move).

Not all THAT much more cheaply, but point well taken. Particularly
the part about, "It Depends."  Obviously (well, I hope obviously),
if my coordinate class needed to very cheaply move in X or Y only,
I'd provide a mechanism.

But it would very probably NOT be X or Y props, but a MoveHorizontal
or MoveVertical method.  The method would be *identical* to a setter
method, but the semantic of the interface is decoupled from what's
under the hood.  (The canonical example being that if I changed the
representation from cartesian to polar, X and Y setters would be bad.)

> Holub is with me on this: hide the implementation details and make
> the interface fit the way you want to use the class; let the class
> do as much work on its own data as it can.

Absolutely!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Programmer Dude" <Chris@Sonnack.com> wrote in message <news:403CC6D6.8270D7EB@Sonnack.com>...

> Joe \"Nuke Me Xemu\" Foster wrote:
>
> > My tomfoolery with "Stash" and "This" isn't strictly necessary
> > but does seem to make a number of things easier in the long run.
>
> I was wondering what the utility of the Private Type was.  The only
> other person I've seen do that is our own EN.
>
> Don't you get the same effect (as with "This") using "Me"?

"Me." only allows access to Friend or Public members.  Using the
private type, "This." gives me a nice IntelliSense list of the
private variables.  There is no additional run-time overhead in
native code, at least according to disassembler listings.

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Programmer Dude schrieb:
> Michael Mendelsohn wrote:
> >> What I mean is that the mechanism makes it very easy to create
> >> those "plain brown" getter/setter methods, which seem to be his
> >> main complaint....
> >
> > This mechanism makes it unnecessary to create them in the first
> > place if they have no function other than to pass a value; you
> > don't lose flexibility if you don't.
> 
> Well right, but what I'm saying is that the language gives you a
> mechanism that makes it very easy to expose the implementation (in
> the hands of a less knowledgeable programmer, I mean).

Well, except that the "property" mechanism doesn't really expose the
implementation. The easier mechanism is to declare the implementation
details public directly. :)
The property mechanism is almost as easy as that, AND it hides
implementation.

I agree that this mechanism supports lazy design.
However, it also supports thought-out design, so there! :)

> One question.  Would this work:
> 
>         private
>             Fa : Integer;
>         public
>             property a: String read Fa;
> 
> That is, would there be a type conversion without writing any more
> code?  That would at least decouple the property type from the
> underlying representation.

No; it doesn't even work when a ist Integer and Fa is double because of
the strict type checking. You have to write the type conversion code in
the Getter.

> >> But it may be that the real complaint is more about a class *design*
> >> that *requires* (or strongly suggests) access to the member data
> >> from outside the class.
> >
> > I took the complaint to be about a class design that says "we don't
> > know how this class will be used, so we'll just make everything wide
> > open and let the other guys figure it out."
> 
> [grin] I think we're saying the same thing.  You seem to be addressing
> the "why"; I only touched on the "what".

Ah, but I think the "what" is only bad if the "why" is wrong. ;)

> > The Delphi designers like to make a fairly "closed" class, and for
> > those who like to twiddle the insides derive a descendant class
> > that exposes some of the protected properties of the base class.
> 
> Heh.  That Allen Holub mentions in one of those articles that
> "protected" attributes are an abomination.  I've heard the attitude
> before--some feel they break encapsulation.

Hmmm.

> > Which one of these is more sensible stands to reason - it depends
> > on how they're going to be used! (Your single coord setters can
> > move the object horizontally or vertically and do that more cheaply
> > than the generic move).

> But it would very probably NOT be X or Y props, but a MoveHorizontal
> or MoveVertical method. 

Yeah, I'd thought of that, too.

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

Joe \"Nuke Me Xemu\" Foster schrieb:
> "Programmer Dude" <Chris@Sonnack.com> wrote in message <news:403BD07C.8A4E68AC@Sonnack.com>...
> > Michael Mendelsohn wrote:
> > > I didn't know VB has properties as well.
> >
> > Yep.  I have mixed feelings about them sometimes.  They're nice
> > syntactically, but it's also nice having it obvious when you're
> > using a method verses a variable.
> 
> Only VB4 had "real" Public class member variables. VB5 and 6
> treat them as syntactic sugar for an (unnamed) Private variable
> plus a set of Public Property Get/Let/Set procedures.  This may
> have broken some code which depended on passing a property's
> value to a subroutine by reference, changing the value, and
> expecting the new value to "stick" after the subroutine exits.

Two observations:

1) I'm glad I haven't seen a langugae change like this with Delphi
(properties still work the same as they did in 1.0). Maybe I'm just too
inexpereinced, though.

2) Your point about changing variables to properties is well taken; I
didn't think of that, and it counters my original argument that you can
start with a variable and make it a property later. Properties can't be
passed by reference in Delphi, either; the compiler flags this when it
occurs.

> > But *Data Access Methods*  (which are *decoupled* from the internal
> > representation) seem like a good idea to me.
> 
> Holub appears to want to go further, in that objects should even
> be responsible for their own UI, if any.  This can be problematic
> with objects from third-party libraries, unless you're using the
> Officially Approved B&D GUI such as Java's Swing. =)

A good design seems to me to have a UI object that uses a non-UI data
object to hold its data - i.e. a Listbox  object would contain a
TStrings object to hold the choices.

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

Programmer Dude schrieb:
> Michael Mendelsohn wrote:
> >>>> ...there would be different drivers speaking to those printers.
> >>>
> >>> Not necessarily.
> >>> Remember "Epson-compatible" printers?
> >>
> >> That's just placing the specific driver in a different place.
> >
> > How can a driver be specific for a printer that didn't even exist
> > when the driver was written?
> 
> The driver is specific to an Epson printer or a printer that looks
> like an Epson printer.

Still, it's late binding - you don't have to know about the exact
printer implementation when writing your printing code.

> > There is a level at which the differences are hidden, and that is
> > the level at which the objects are polymorphous.
> 
> [shrug] As I've said, I understand your point, I just don't see it
> quite that way.  I don't call a printer pretending to be some other
> printer polymorphism (for reasons I've detailed in earlier posts,
> but in summary, *to* *me* OOP polymorphism is mostly about dynamic
> dispatch).

I've looked it up.

I feel I want to go with 
en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming
which states:
"Why is polymorphism important? Because it allows client programs to be
written based only on the abstract interfaces of the objects which will
be manipulated (this is also called interface inheritance)."

So if you have a network device written to conform to an abstract spec
(such as a RFC), it'll fulfill this polymorphism definition.

The same source requires late binding for polymorphism, and you usually
have that because usually you don't know at this end of teh network
connection the internal setup of the device at the other end. ;)


> >> Object Polymorphism.  [...] The important characteristic
> >> here is that you treat the object per its subset and which
> >> method is called is distinguished by the object's actual type...
> >
> > That's what I thought I had found examples for.
> 
> [shrug] All I can say is they don't say "polymorphism" to me.  (-:
> Because...
> 
> >> Now, a *defining* characteristic to me is the element of *dispatch*
> >> (calling functions) based on data type--either at compile or run.
> >
> > Who is doing the dispatching? In a monolithic program, the issue is
> > moot, but in a distributed environment, there are different possible
> > answers.
> 
> But once you're talking to a specific network device, you're talking
> to that device.  No dispatching.  An example that sprung to my mind
> that would be hard to deny as polymorphic would be a virtual printer
> that dispatched print jobs to various real printers depending on the
> nature of the print job.

A "virtual printer" as in "virtual class" does not exist - it's not
implemented; you talk to the _real_ printer as if it was the virtual
printer, and you don't need to know how the real printer is implemented
as long as it behaves to virtual printer rules.

> >> Although, to be honest, I still resist calling this pm, because I
> >> see the "dispatch" aspect of it as central.
> >
> > I think some would lump all of my examples under inheritance, and we
> > seem to at least agree that inheritance is a useful concept to
> > analyse network computing.
> 
> Absolutely!

If, as above, polymorphism = interface inheritance, they can't be
separated when talking about network computing.

> >> Ah, and maybe I've just stumbled on a simplified way to explain the
> >> difference I see: in polymorphism, a *single* thing (e.g. variable
> >> in a function) TAKES ON different shapes at different times.
> >
> > The superset of all these shapes is another single shape that can
> > be used by you to refute yourself. :)
> > It all depends on where you locate the dispatch logic.
> 
> Nope, you've definitely lost me in the last few paragraphs.  :-(

Well, the "variable" is this device's idea of the kind of device that
sits at the other end. You have polymorphism when you can code this
device without exactly knowing what device is at the other end (e.g.
because you're coding to spec), and have it work with any device that
follows the spec.

In your argument, you wait for me to give you an example "other end"
device, then point to it saying that it's only got one shape, so it
can't be polymorphous; and if I then substitute another device for it,
that doesn't count because they're similar. :)

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

"Michael Mendelsohn" <keine.Werbung.1300@michael.mendelsohn.de> wrote in message <news:403D2F20.A7348A8F@michael.mendelsohn.de>...

> Joe \"Nuke Me Xemu\" Foster schrieb:

> > Only VB4 had "real" Public class member variables. VB5 and 6
> > treat them as syntactic sugar for an (unnamed) Private variable
> > plus a set of Public Property Get/Let/Set procedures.  This may
> > have broken some code which depended on passing a property's
> > value to a subroutine by reference, changing the value, and
> > expecting the new value to "stick" after the subroutine exits.
>
> Two observations:
>
> 1) I'm glad I haven't seen a langugae change like this with Delphi
> (properties still work the same as they did in 1.0). Maybe I'm just too
> inexpereinced, though.

As far as I know, VB4's behavior introduced some inconsistencies
with previous versions, which were fixed in VB5 about a year later.

> 2) Your point about changing variables to properties is well taken; I
> didn't think of that, and it counters my original argument that you can
> start with a variable and make it a property later. Properties can't be
> passed by reference in Delphi, either; the compiler flags this when it
> occurs.

VB5 can sometimes catch such things, but potentially long strings
and Variants are often passed ByRef for performance reasons, not
because the subroutine might modify its arguments.  VB6 might have
some global data flow analysis features, or it might not.

> > Holub appears to want to go further, in that objects should even
> > be responsible for their own UI, if any.  This can be problematic
> > with objects from third-party libraries, unless you're using the
> > Officially Approved B&D GUI such as Java's Swing. =)
>
> A good design seems to me to have a UI object that uses a non-UI data
> object to hold its data - i.e. a Listbox  object would contain a
> TStrings object to hold the choices.

But does the TStrings manage the ListBox, or is it the other way
'round?

--
Joe Foster <mailto:jlfoster%40znet.com>  DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Joe \"Nuke Me Xemu\" Foster schrieb:
> > 2) Your point about changing variables to properties is well taken; I
> > didn't think of that, and it counters my original argument that you can
> > start with a variable and make it a property later. Properties can't be
> > passed by reference in Delphi, either; the compiler flags this when it
> > occurs.
> 
> VB5 can sometimes catch such things, but potentially long strings
> and Variants are often passed ByRef for performance reasons, not
> because the subroutine might modify its arguments. 

Haven't tried that yet; I think if you declare the parameter as const,
you can pass a reference without a copy of the data being made.


> > > Holub appears to want to go further, in that objects should even
> > > be responsible for their own UI, if any.  This can be problematic
> > > with objects from third-party libraries, unless you're using the
> > > Officially Approved B&D GUI such as Java's Swing. =)
> >
> > A good design seems to me to have a UI object that uses a non-UI data
> > object to hold its data - i.e. a Listbox  object would contain a
> > TStrings object to hold the choices.
> 
> But does the TStrings manage the ListBox, or is it the other way
> 'round?

Not sure how you mean that.
If I do ListBox.Items.Add('Some new item'), then I've added a new line
to the Items (which is a  TStrings Object), and that will be displayed
by the Listbox. I assume that the Items object is really a descendant of
TStrings that has learned to tell the Listbox to refresh itself.
I'm sorry I can't answer you in more detail. :(

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

Michael Mendelsohn schrieb:
> Joe \"Nuke Me Xemu\" Foster schrieb:
> >>> Holub appears to want to go further, in that objects should even
> >>> be responsible for their own UI, if any.  This can be problematic
> >>> with objects from third-party libraries, unless you're using the
> >>> Officially Approved B&D GUI such as Java's Swing. =)
> >> A good design seems to me to have a UI object that uses a non-UI data
> >> object to hold its data - i.e. a Listbox  object would contain a
> >> TStrings object to hold the choices.
> >
> > But does the TStrings manage the ListBox, or is it the other way
> > 'round?
> 
> Not sure how you mean that.
> If I do ListBox.Items.Add('Some new item'), then I've added a new line
> to the Items (which is a  TStrings Object), and that will be displayed
> by the Listbox. I assume that the Items object is really a descendant of
> TStrings that has learned to tell the Listbox to refresh itself.
> I'm sorry I can't answer you in more detail. :(

I've looked it up in the source, and found that I assumed correctly,
except that the example is bad because the data is not kept within
Items, since the Listbox class wraps the Windows Listbox control which
holds the data; Items is just a convenient way to access it. 
"Items" is indeed a TStrings descendant (TListBoxStrings) that knows
which Listbox it is in, and it will update the Listbox whenever it
changes (the methods that would change TStrings have been overridden).

So if you want a GUI for an existing data type, make a GUI class that
lets you control its attributes, and derive a descendant of that data
type that hooks it up to the GUI class.
This fulfills the demand that the object be responsible for its own GUI
by taking irresponsible objects and adding the responsibility
separately; one could this way match several GUI styles, or even several
ways to display that GUI-less core data object.

I learn something new every day. :)

Michael
-- 
Feel the stare of my burning hamster and stop smoking!

gerryq@indigo.ie (Gerry Quinn) wrote in message news:<m8oXb.2759$rb.57985@news.indigo.ie>...
> In article <slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
> >
> >>  Do you also
> >> agree with Dijkstra about object orientation?
> >> "Object-oriented programming is an exceptionally bad idea that
> >> could only have been invented in California."

If he said this, and I believe he did, it was a massive error on his
part. OO was invented in Scandinavia by his colleague Ole Johan Dahl
who modified early Fortran and Algol into Simula. Barney Stroustrup
knew of the work and as a result developed C++ after emigrating from
Denmark.

[Richard Heathfield, I'd be obliged to you if you run off like a good
chap and get all the cites we need. There's a good fellow.]

Nonetheless I am a great admirer of the D-man because unlike so many
computer scientists he was a truly independent thinker, to the extent
that he was not always careful to engage his truly massive brain
before opening his mouth. As such he is a fellow spirit because I am
not always careful to engage my brain before speaking either, and I
believe that human beings have this right.

Dijkstra was computing's only "public intellectual" in the sense of
Jean Paul Sartre, who believed he could speak independently of market
pressures. For this reason I admire him greatly.

Hi!

spinoza1111@yahoo.com (Edward G. Nilges) writes:

>If he said this, and I believe he did, it was a massive error on his
>part. OO was invented in Scandinavia by his colleague Ole Johan Dahl
>who modified early Fortran and Algol into Simula. Barney Stroustrup
>knew of the work and as a result developed C++ after emigrating from
>Denmark.

Barney Stroustrup???? Perhaps you should vist 
http://www.research.att.com/~bs/homepage.html .

Bye,
Chris Dams

gerryq@indigo.ie (Gerry Quinn) wrote in message news:<m8oXb.2759$rb.57985@news.indigo.ie>...
> In article <slrnc2q9j4.2jnr.kamikaze@kuoi.asui.uidaho.edu>, kamikaze@kuoi.asui.uidaho.edu (Mark 'Kamikaze' Hughes) wrote:
> >
> >>  Do you also
> >> agree with Dijkstra about object orientation?
> >> "Object-oriented programming is an exceptionally bad idea that
> >> could only have been invented in California."
> >> http://quote.wikipedia.org/wiki/Edsger_Dijkstra
> >
> >  Given the early OOP systems he saw, certainly.  Older OOP languages
> >sucked, and were more liability than help.  Things have improved a bit
> >since then, so OOP is now a useful technology.  EWD often expressed his
> >opinions as extremes based on the worst-case examples (GOTO being the
> >canonical example), but he was rarely (never?) wrong about them.
> 
> Dijkstra seems incredibly overrated.  As far as I can see he is famous 
> for (a) a trivial pathfinding algorithm that must have been re-invented 

If you mean the minimum spanning hull algorithm you are just wrong. In
fact, solutions to the problem were probably "re-inventged" "hundreds
of times"...the wrong way by coders who after Dijkstra published the
algorithm had no excuse not to follow it.

Dijkstra's major accomplishments were semaphores and structured
programming and their signal feature is that they are useful to real
programmers, because as a sort of instinctive Kantian Dijkstra refused
the mental separation between "theory" and "practice".

> hundreds of times, and (b) a bunch of stupidly aggressive and 
> wrong-headed comments, such as the above about OO, and the stupidity 
> about Basic (which I interpret as meaning he was a crap teacher too).
>
This is interesting. You flame Dijkstra for "stupidly aggressive and
wrong-headed comments", and then use the phrase "crap teacher" which
AT A MINIMUM is stupidly aggressive.

For I have long noticed that within the corporate world, there is a
genuine, and usually well-meaning, tendency, not to be "stupidly
aggressive" or, as Dijkstra was, even intelligently aggressive.
Caution and moderation help advancement.

But I have also noticed that the anger this repression creates finds a
convenient target in the form of the teacher and I find that for many
programmers, ALL of their teachers at university were "crap".

Their anger at the university system is hypostatized and focused on a
convenient target, that of the teacher who today the student feels
fully qualified to judge as prima facie inadequate, not only as an
imparter of information but at a deeply personal level...which is
paradoxical for it assumes foreknowledge, on the part of the student,
of the material the teacher is supposed to teach: as if the student
comes to school somehow blessed with a vision of truth which the
teacher actually obscures.

This form of everyday Fascism has a genesis as seen in films like Der
Blaue Engel in which a generation brutalized by WWI returned to find
its teachers objects of scorn because those teachers were exposed,
whether in Weimar or in cafes, as ordinary and fallible men.

In computer science, the machine often enough makes a monkey out of
the teacher, who has to depend, increasingly in the increasingly
brutalized climate of universities subordinate to corporations and
corporate goals, on elaborate and ill-understood "educational software
packages" which at best represent the theft of professorial
intellectual property and at worst are replications of bad teaching.

I recently interviewed Peter Neumann of comp.risks about Dijkstra for
Neumann knew Dijkstra personally, and I hope to be able after my tech
books are complete to perhaps write a sort of Beautiful Mind story of
EWD. Neumann confirmed something I've read elsewhere and this was that
there was a complete split between the acerbic Dijkstra of his written
communications, some of which are wrong as I've said, and the person
known in Austin. While he did not suffer fools gladly, it appears, he
was a good teacher of motivated students and personally courteous and
polite even to damned fools.

The problem is that unlike most computer scientists, who are rather
aliterate, Dijsktra was educated in the European Continental tradition
of respect for the written word, and "telling truths that might hurt".

In the humanities, public intellectuals like Jean Paul Sartre were
expected to be offensive and "speak truth to power" but in the
sciences this isn't so, and therefore Dijsktra's writings are wrongly
supposed to be those of a loose cannon.

If computer science had less respect for big money and more respect
for humanity, Dijkstra would be I think better respected.

I think that had humanity not fallen off a moral cliff during my
generation, Dijkstra would have been honored, and this is because in
the 1960s and in place of genuine change, we sort of decided that the
very idea of a tradition was necessarily something that could not
adapt to a novelty...by which people are dazzled, in the case of
technology and in an image of the technocritic Jerry Mander, like a
deer in headlights.

Dijkstra however saw that the technology while being a radical novelty
did not change the ground rules of committment to truth, linked with
moral seriousness. And I think he saw how a lack of committment to
truth brings whole systems and societies crashing down. This ng, and
its collective inability to ever get to programming apart from
obfuscated C and Nilges bashing, is an almost laboratory example.

 
> No doubt he did useful stuff I haven't heard of, but his record as 
> typically referred to on usenet is quite pitiful.

Yeah, he did a whole shitpile of work about which you know jack. In
particular and unlike 99% of cs teachers he was able to design and
explain new algorithms with that form of clarity which shouldn't be
confused with that form of "simplicity" constituted in avoidance of
hard issues.
> 
> - Gerry Quinn

"David Turner" <david@firepro.co.za> wrote in message
news:1076050521.462960@tanzanite.firepro.co.za...
> I don't think one can argue that reference counted code is slower than
> garbage collected code ;-).  Remember that the garbage collector also
> has to keep track of references.

Pardon my ignorance, but are all garbage collectors required to know all
references to all objects, at any time? This would seem very inefficient to
me. I thought collectors could work with the knowledge of just the "global"
objects or environment, and deduce all object references from those (they
would also need to know how objects are defined, then, in order to traverse
the object tree (or graph)).

> And to say that smart pointers are "slow" is ludicrous.  Any compiler
> worth its salt will reduce the overhead of accesses through a smart
> pointer to zero.

That makes sense, but don't smart pointers still bring a performance
overhead by being regular instance classes, thus needing to be allocated and
freed as such?

Thanks,


--
Matthieu Villeneuve

In article <403dfaad$0$22411$626a14ce@news.free.fr>,
Matthieu Villeneuve <matthieu@nospam.matthieu-villeneuve.net> wrote:
 ...
>I thought collectors could work with the knowledge of just the "global"
>objects or environment, and deduce all object references from those (they
>would also need to know how objects are defined, then, in order to traverse
>the object tree (or graph)).

This is correct, although some garbage collectors are what's called 
'conservative'. That is, they don't purport to do a complete job. Rather, 
they can traverse regions of memory looking for numbers that look like 
pointers to objects, and then traversing the graphs to which they point.  
These systems need much less information about object/stack layout, but at 
an obvious cost if the heap contains integers that look like pointers, but 
are not.

If you know where all the roots are, and you know the layout of all
objects on the heap, then you can guarantee that you only traverse those
objects that are reachable. This is a little tricky to implement, but it
avoids the spurious memory leaks that you can get in a conservative
system. Where you can run into problems (with either of these approaches ,
actually) is in the graph traversal itself.  If you're traversing the
entire heap, not only can that be a considerable number of objects, it
also entails touching every page containing allocated heap objects. This
can cause problems on machines with virtual memory paging.

Some more sophisticated GC algoorithms use what's called generational or 
ephemeral collection.  These all operate on the philosophy that the more 
recently an object has been allocated, the more likely it is to be
deleted. This makes sense, if you think about the number of short lived 
temporary allocations and long lived allocations of tables, etc. in many 
programs.

A simple generational system might have two heaps: one for young objects 
and one for old objects. When new objects are allocated, they are 
allocated on the young objects heap. Most garbage collection 
traversals operate only on the young objects heap, and only free storage 
therein. If an object survives the first GC pass it is moved into the 
other heap. A nice way to implement the object move is to move the object 
and replace it with a 'forwarding pointer'. That way, as the object is 
encountered during subsequent parts of the graph traversal it will be able 
to be found and other pointers updated. Of course, since pointers are now 
being altered by the collector, it must know for certain what's a pointer 
and what's not. The bright side is that since objects are being moved 
around the heap, it's possible for the collector to take some care about 
how it lays out the objects in memory to optimize the paging 
characteristics of the heap.

The downside to all this is actually somewhat subtle: the "roots" of the
young heap can actually change with assignments to the old heap. That is,
if an old heap object is modified to point to a new heap object, then
steps must be taken to keep the new heap object from being garbage
collected. This entails the use of a 'write barrier'. That is, writes to
the old heap are checked for this condition.

Other refinements include things like special heaps for large objects, and
more than two generations of objects. I believe that modern runtimes like
..Net use pretty much all of these optimizations and then some.

-Mike
-- 
http://www.mschaef.com

"Matthieu Villeneuve" <matthieu@nospam.matthieu-villeneuve.net> wrote in message <news:403dfaad$0$22411$626a14ce@news.free.fr>...

> "David Turner" <david@firepro.co.za> wrote in message
> news:1076050521.462960@tanzanite.firepro.co.za...

> > And to say that smart pointers are "slow" is ludicrous.  Any compiler
> > worth its salt will reduce the overhead of accesses through a smart
> > pointer to zero.
>
> That makes sense, but don't smart pointers still bring a performance
> overhead by being regular instance classes, thus needing to be allocated and
> freed as such?

Smart pointers are "value types" and can live on the stack or be
directly embedded in other types and thus do not need a separate
dynamic heap allocation.  Reference counts could be kept in a
special arena and not incur the overhead of a typical allocation.

--
Joe Foster <mailto:jlfoster%40znet.com>  "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Michael Mendelsohn wrote:

> So if you want a GUI for an existing data type, make a GUI class
> that lets you control its attributes, and derive a descendant of
> that data type that hooks it up to the GUI class.

Makes sense.

Why am I thinking, "I wonder if AOP might be interesting here?"

AOP is about cross-cutting concerns, and maybe GUI display is a
concern that cuts across the concerns of different data types....

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Michael Mendelsohn wrote:

> Well, except that the "property" mechanism doesn't really expose
> the implementation.

Yet, it seems that it does:

}} That is, would there be a type conversion without writing any more
}} code?  That would at least decouple the property type from the
}} underlying representation.
} 
} No; it doesn't even work when a ist Integer and Fa is double because
} of the strict type checking. You have to write the type conversion
} code in the Getter.

Which is what I was "Getter-ing" at.  (-:  If a programmer just
provides the properties, it seems they expose the underlying type.
(Or have I misunderstood?)

> The easier mechanism is to declare the implementation details
> public directly. :)

True enough.  (Unless, maybe you wanted R/O or W/O?)

> The property mechanism is almost as easy as that, AND it hides
> implementation.

But.... doesn't it *need* to be the same type as the variable?

(We're spiraling in on minutia here, and I just want to mention
I'm not intending to knock OO Pascal.  I think the whole props
thing is cool!)

> I agree that this mechanism supports lazy design.
> However, it also supports thought-out design, so there! :)

Hey!  I'm a huge believer in potentially dangerous tools that need
intelligence to use!!  (-:


>> You seem to be addressing the "why"; I only touched on the "what".
> 
> Ah, but I think the "what" is only bad if the "why" is wrong. ;)

Agreed!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

There's an opportunity here to join two on-going threads....

Michael Mendelsohn wrote:

>> The driver is specific to an Epson printer or a printer that looks
>> like an Epson printer.
> 
> Still, it's late binding - you don't have to know about the exact
> printer implementation when writing your printing code.

In a sense.  You're talking to a specific object--a driver--in a
defined way (Epson talk), and that specific object talks to another
specific object (XYZ Brand printer).  I just don't see that as
polymorphism--I'll try to explain precisely why below.

But here's an interesting observation related to the thread about
making models from perceived reality (or imagination).  We see the
same "realties": network objects and the concept of OO polymorphism
and have developed different models of that reality based on exactly
how we define various component concepts.

I suspect we'll never "agree" on a gut level with each other's model,
because we define our terms slightly differently.  My contention, and
I hope you're on board with this, is that both models are probably
equally valid representations of the perceived reality.

The most interesting aspect to me--with regard to the philosophy
thread and model construction--is that there need not be a "most
correct" model in a given situation.  It would be like suggesting
there is a "most correct" language for a given problem.  I would
claim there are usually several "equally correct" languages or
models.

Anyway....

> I feel I want to go with
> en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming
> which states:
> "Why is polymorphism important? Because it allows client programs
> to be written based only on the abstract interfaces of the objects
> which will be manipulated (this is also called interface
> inheritance)."

That's a fine definition.

> So if you have a network device written to conform to an abstract
> spec (such as a RFC), it'll fulfill this polymorphism definition.
> 
> The same source requires late binding for polymorphism, and you
> usually have that because usually you don't know at this end of
> teh network connection the internal setup of the device at the
> other end. ;)

Fair enough, and--as I've said before--I fully understand why you'd
see it as you do.  Here's my definition--refined as a direct result
of this discussion into something fairly concise and specific--and
I think (hope) it illustrates why my model differs.

We agree on the elements of an abstract interface and late binding.
A further element for me is that a polymorphic object is a *single*
thing in a *single* location that *becomes*, at different times and
depending on circumstances, *distinctly* different objects.

For example:

    void Increment_It (IncrementableObject& obj)
    {
        obj.Incr();
    }

You can pass any object that looks like an IncrementableObject
to the above, and it invokes "Incr" on it.  The actual object
could be a numeric value or a list with a "cursor".

The thing that strikes me here is that "obj" is a single thing in
a single place that "becomes" different--sometimes very different
(numeric object vs: list object)--objects under different
circumstances (different call instances).

The me, the model of a bunch of different objects "out there" that
share a similar interface is NOT a polymorphic model.  It just isn't.

To me, they are instances of some class--perhaps a very abstract
and complicated one, but instances all the same.

To me, the MS webserver and apache *are* just instances of the class
WebServer, which defines a specific interface (http).  The class is
a complex one with a LOT of "instance variables"--the "how" of a
particular module, for instance.

Likewise printers.  A trivial example, the vendor name and model
and serial number are easily seen (at least I think so) as instance
data that varies from instance to instance.  I also see the deeper
details of the implementation as a sort of instance variable.

So, to try to summarize, it's the idea of a *single* thing dealt with
in a *single* place--but which becomes different things--that is
vital to my model of polymorphism.


>> An example that sprung to my mind that would be hard to deny as
>> polymorphic would be a virtual printer that dispatched print jobs
>> to various real printers depending on the nature of the print job.
> 
> A "virtual printer" as in "virtual class" does not exist - it's not
> implemented; you talk to the _real_ printer as if it was the virtual
> printer, and you don't need to know how the real printer is
> implemented as long as it behaves to virtual printer rules.

I can't tell if my example was understood, and that may be due to
using the term "virtual printer".  What I mean is a *single* thing,
called a "Printer"--either on my desktop or on the network--to which
I can send any printable object (document).  That "Printer" then
dispatches the job to an actual printer appropriate for the job.

Similar to sending a "speak" message to an Animal object and having
that dispatch to the "became" object--a Dog or Cow, e.g.


> If, as above, polymorphism = interface inheritance, they can't be
> separated when talking about network computing.

Agreed, but I do not agree with the "equals" above (as I hope I have
been able to make clear now).


> In your argument, you wait for me to give you an example "other end"
> device, then point to it saying that it's only got one shape, so it
> can't be polymorphous; and if I then substitute another device for
> it, that doesn't count because they're similar. :)

The disconnect is occuring, because (in my eyes) the dispatch is
deliberate and intentional on your part.  YOU surf from webserver
to webserver.  YOU select a network device.  That they share a
common interface does not fully satisfy *my* polymorphism definition.
Compare those examples to the "virtual Printer" example above.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

In article <f5dda427.0402260527.5eb0332b@posting.google.com>, spinoza1111@yahoo.com (Edward G. Nilges) wrote:
>gerryq@indigo.ie (Gerry Quinn) wrote in message

>> Dijkstra seems incredibly overrated.  As far as I can see he is famous 
>> for (a) a trivial pathfinding algorithm that must have been re-invented 
>
>If you mean the minimum spanning hull algorithm you are just wrong. In
>fact, solutions to the problem were probably "re-inventged" "hundreds
>of times"...the wrong way by coders who after Dijkstra published the
>algorithm had no excuse not to follow it.

How could I mean it when I said a "pathfinding algorithm"?  As for the 
"minimal spanning hull" I must that while I am familiar with "spanning 
trees" and "convex hulls", a "spanning hull" is a new one on me.  A 
Google search shows the term is occasionally used by physicists in 
certain theories of percolation, but not in computer science.

>> hundreds of times, and (b) a bunch of stupidly aggressive and 
>> wrong-headed comments, such as the above about OO, and the stupidity 
>> about Basic (which I interpret as meaning he was a crap teacher too).
>>
>This is interesting. You flame Dijkstra for "stupidly aggressive and
>wrong-headed comments", and then use the phrase "crap teacher" which
>AT A MINIMUM is stupidly aggressive.

Even if it were, it would not absolve Dijkstra of the charge.  But as I 
see it, a teacher who blames his students for learning things 'the wrong 
way' when he can't teach them is indeed a crap teacher.

[Irrelevancies and standard accusations of Fascism deleted]

>> No doubt he did useful stuff I haven't heard of, but his record as 
>> typically referred to on usenet is quite pitiful.
>
>Yeah, he did a whole shitpile of work about which you know jack. In
>particular and unlike 99% of cs teachers he was able to design and
>explain new algorithms with that form of clarity which shouldn't be
>confused with that form of "simplicity" constituted in avoidance of
>hard issues.

Actually I did look it up since I posted that.  It doesn't alter the 
fact that the famous algorithm bearing his name (or sometimes called 
'wavefront') is trivial and must often have been re-invented.  I did 
re-invent it at one time, and recently invented and posted a modified 
version giving the second and third sets of shortest paths etc. in 
response to a usenet query.

- Gerry Quinn

Programmer Dude schrieb:
> Michael Mendelsohn wrote:
> > Well, except that the "property" mechanism doesn't really expose
> > the implementation.
> 
> Yet, it seems that it does:
> 
> }} That is, would there be a type conversion without writing any more
> }} code?  That would at least decouple the property type from the
> }} underlying representation.
> }
> } No; it doesn't even work when a ist Integer and Fa is double because
> } of the strict type checking. You have to write the type conversion
> } code in the Getter.
> 
> Which is what I was "Getter-ing" at.  (-:  If a programmer just
> provides the properties, it seems they expose the underlying type.
> (Or have I misunderstood?)

Weeellll, if you think of an old-style maternity ward, with a big
window, behind which daddy can see rows of cots, one of which holds his
new little darling, then I guess you could say the window exposes that
infant. Daddy's a long way from getting his grubby hands on the little
sprog, though! ;)

If you offer a SetXY(float, float) for your 2Dpoint, it is safe to guess
your initial design provided for these coords to be stored as float.
Does your design feel exposed now?

I can't see a difference to properties, because the implementation is
still independent of the interface; the exposure is make-believe.

> > The easier mechanism is to declare the implementation details
> > public directly. :)
> 
> True enough.  (Unless, maybe you wanted R/O or W/O?)

Well, a lazy programmer implements R/W and says in the docs "should be
treated as R/O". :)

> > The property mechanism is almost as easy as that, AND it hides
> > implementation.
> 
> But.... doesn't it *need* to be the same type as the variable?

No. In my first example (the my_foo.a := 42 one), an Integer property
was used to access a value stored in a string. This requires for the
getter/setter to have conevrsion code, but it does not require whoever
uses the class to worry about it - he can treat the class as if the
property was stored as an Integer.

> (We're spiraling in on minutia here, and I just want to mention
> I'm not intending to knock OO Pascal.  I think the whole props
> thing is cool!)

Knock OO Pascal all you want if you do it intelligently! ;)

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

Michael Mendelsohn wrote:

>> [Properties...] it seems they expose the underlying type.
> 
> Weeellll, if you think of an old-style maternity ward,...

Good point.  My sense of "exposed" was too lenient or something
(thinking, apparently, "exposed" == "reveal knowledge of").

Nevermind.  (-:

> If you offer a SetXY(float, float) for your 2Dpoint, it is safe
> to guess your initial design provided for these coords to be
> stored as float. Does your design feel exposed now?

Actually, yes.  That's why I'd use the Move() method.  It's less
revealing.


>> But.... doesn't it *need* to be the same type as the variable?
> 
> No. In my first example (the my_foo.a := 42 one), an Integer
> property was used to access a value stored in a string.

Understood.  I meant sans-conversion code.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude schrieb:
> Michael Mendelsohn wrote:
> > If you offer a SetXY(float, float) for your 2Dpoint, it is safe
> > to guess your initial design provided for these coords to be
> > stored as float. Does your design feel exposed now?
> 
> Actually, yes.  That's why I'd use the Move() method.  It's less
> revealing.

Well, I can think of some pretty revealing moves...
.... but that's offtopic here. :)

> >> But.... doesn't it *need* to be the same type as the variable?
> >
> > No. In my first example (the my_foo.a := 42 one), an Integer
> > property was used to access a value stored in a string.
> 
> Understood.  I meant sans-conversion code.

Yeah, it'd be nice if the Assign operator (properly overloaded, of
course) was used implicitly for this one, if possible.

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

Gerry Quinn schrieb:
> Even if it were, it would not absolve Dijkstra of the charge.  But as I
> see it, a teacher who blames his students for learning things 'the wrong
> way' when he can't teach them is indeed a crap teacher.

You seem to overestimate the powers of even the best teachers.

I've just read ""On the Cruelty of really Teaching Computer Science"
http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF .

I think Dijkstra shows a good understanding of the teaching process;
he's focused on what the teacher makes the students think; centered on
transmitting a mode of thinking.

From the appearences, I'd hesitate to label him a "crap teacher".

This same paper makes a good refutation of TDD, btw. :)

I am not sure I entirely understand what he means by "operational
thinking" about computer programs, esp. as that relates to Objects.

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

gerryq@indigo.ie (Gerry Quinn) wrote in message news:<4Jr%b.4749$rb.62483@news.indigo.ie>...
> In article <f5dda427.0402260527.5eb0332b@posting.google.com>, spinoza1111@yahoo.com (Edward G. Nilges) wrote:
> >gerryq@indigo.ie (Gerry Quinn) wrote in message
>  
> >> Dijkstra seems incredibly overrated.  As far as I can see he is famous 
> >> for (a) a trivial pathfinding algorithm that must have been re-invented 
> >
> >If you mean the minimum spanning hull algorithm you are just wrong. In
> >fact, solutions to the problem were probably "re-inventged" "hundreds
> >of times"...the wrong way by coders who after Dijkstra published the
> >algorithm had no excuse not to follow it.
> 
> How could I mean it when I said a "pathfinding algorithm"?  As for the 
> "minimal spanning hull" I must that while I am familiar with "spanning 
> trees" and "convex hulls", a "spanning hull" is a new one on me.  A 
> Google search shows the term is occasionally used by physicists in 
> certain theories of percolation, but not in computer science.

I think you need to read more and understand more. Cf.
http://www.cse.unsw.edu.au/~lambert/java/3d/hull.html. I said
"spanning" hull because this is what a convex hull actually does, it
spans the outlier points.
> 
> >> hundreds of times, and (b) a bunch of stupidly aggressive and 
> >> wrong-headed comments, such as the above about OO, and the stupidity 
> >> about Basic (which I interpret as meaning he was a crap teacher too).
> >>
> >This is interesting. You flame Dijkstra for "stupidly aggressive and
> >wrong-headed comments", and then use the phrase "crap teacher" which
> >AT A MINIMUM is stupidly aggressive.
> 
> Even if it were, it would not absolve Dijkstra of the charge.  But as I 
> see it, a teacher who blames his students for learning things 'the wrong 
> way' when he can't teach them is indeed a crap teacher.

Not in a society which produces students unwilling to learn,
unprepared to learn, and blind to their own limitations.

Dijsktra focused his teaching on that approximately 20% of computer
science who weren't majoring in "pre-wealth studies" and did not have
the vulgar idea that a college education is about getting rich.

> 
> [Irrelevancies and standard accusations of Fascism deleted]
> 
> >> No doubt he did useful stuff I haven't heard of, but his record as 
> >> typically referred to on usenet is quite pitiful.
> >
> >Yeah, he did a whole shitpile of work about which you know jack. In
> >particular and unlike 99% of cs teachers he was able to design and
> >explain new algorithms with that form of clarity which shouldn't be
> >confused with that form of "simplicity" constituted in avoidance of
> >hard issues.
> 
> Actually I did look it up since I posted that.  It doesn't alter the 
> fact that the famous algorithm bearing his name (or sometimes called 
> 'wavefront') is trivial and must often have been re-invented.  I did 

No, it was not reinvented. 

> re-invent it at one time, and recently invented and posted a modified 
> version giving the second and third sets of shortest paths etc. in 
> response to a usenet query.

You did so after Dijkstra and you probably did it wrong. You are at
best a programmer who should not take any credit for algorithm design
unless you are also capable of publishing a refereed journal article.
> 
> - Gerry Quinn

"Matthieu Villeneuve" <matthieu@nospam.matthieu-villeneuve.net> writes:

> "David Turner" <david@firepro.co.za> wrote in message
> news:1076050521.462960@tanzanite.firepro.co.za...
> > I don't think one can argue that reference counted code is slower than
> > garbage collected code ;-).  Remember that the garbage collector also
> > has to keep track of references.
> 
> Pardon my ignorance, but are all garbage collectors required to know all
> references to all objects, at any time? This would seem very inefficient to
> me. I thought collectors could work with the knowledge of just the "global"
> objects or environment, and deduce all object references from those (they
> would also need to know how objects are defined, then, in order to traverse
> the object tree (or graph)).

This is basically true, as Mike also pointed out.  The extra overhead
from reference counting does not come from keeping track of
references, but from making simple assignments and parameter passing
an order of magnitude more expensive than in a system with a garbage
collector.  At pretty much every assignment, reference counters must
be updated and tested for zero.

If, in addition, reference counting is implemented by replacing a real
pointer by a class instance (whose assignment operation, constructor,
an destructor take care of the reference counting), there might be
additional overhead at each assignment just because a class instance
is usually bigger than an ordinary pointer.  

Reference counting even introduces pauses the way garbage collectors
used to do before we had real-time garbage collectors.  When the
reference count of the root of a large structure (not shared) becomes
zero, the entire structure must be traversed.  The problem can be
somewhat compensated for by a technique by which objects are freed a
little at a time as new ones are allocated.  But then, reference
counters no longer have the advantage of immediately recovering unused
memory.  Copying and fake-copying garbage collectors, on the other
hand, do not even have to traverse unreferenced memory. 

Continuing the list of problems with reference counters, they are
unable to recover circular structure.  There are ways of dealing with
that, of course.  One possibility is to use a real garbage collector,
but which is only called from time to time, hoping that the reference
counters will recover most unused memory.  Another possibility is for
the programmer to explicitly pinpoint some references as "back
pointers" that should not be counted as real references.

Finally, in a multi-threaded system, reference counters will need
locking and synchronization at each assignment, which can be quite
costly, especially in an SMP system.  Generational garbage collectors,
on the other hand, can avoid locking in the youngest generation by
making it per-thread.  Objects will be promoted to an older generation
only when they survive one or more collections.  Locking is needed
only for allocations and not for assignments. 

> > And to say that smart pointers are "slow" is ludicrous.  Any compiler
> > worth its salt will reduce the overhead of accesses through a smart
> > pointer to zero.
> 
> That makes sense, but don't smart pointers still bring a performance
> overhead by being regular instance classes, thus needing to be allocated and
> freed as such?

Yes, I think so.  But again, I do not think that is the source of the
additional overhead.  It is the simple fact that class instances are
usually bigger than a pointer, so that assignment or parameter passing
takes two or three times as long as it would for an ordinary pointer.  

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------

In article <f5dda427.0402260158.61cd80be@posting.google.com>, 
spinoza1111@yahoo.com says...
> [...]
> > >>  Do you also agree with Dijkstra about object orientation?
> > >> "Object-oriented programming is an exceptionally bad idea that
> > >> could only have been invented in California."
> 
> If he said this, and I believe he did, it was a massive error on his
> part. OO was invented in Scandinavia by his colleague Ole Johan Dahl
> who modified early Fortran and Algol into Simula.

It was already pointed out earlier, but it seems it is necessary
to repeat it: considering that Dijkstra co-authored "Structured
Programming" with Dahl (and Hoare) in 1972, it is highly unlikely
Dikjstra was unaware of Dahl's work on Simula, wouldn't you say?

Instead, as was also pointed out earlier in this thread, the
logical conclusion would be that Dijkstra is refering to Alan
Kay, who is the originator of the phrase "object-oriented
programming".

See the links that Joe Foster posted in:

http://groups.google.com/groups?selm=1077046925.835514%40news-
1.nethere.net


> Barney Stroustrup knew of the work and as a result developed
> C++ after emigrating from Denmark.

Barney? That explains why C++ is such a dinosaur of a language!


Christer Ericson
Sony Computer Entertainment, Santa Monica

Programmer Dude schrieb:
> There's an opportunity here to join two on-going threads....
> Michael Mendelsohn wrote:
> 
> >> The driver is specific to an Epson printer or a printer that looks
> >> like an Epson printer.
> >
> > Still, it's late binding - you don't have to know about the exact
> > printer implementation when writing your printing code.
> 
> In a sense.  You're talking to a specific object--a driver--in a
> defined way (Epson talk), and that specific object talks to another
> specific object (XYZ Brand printer).  I just don't see that as
> polymorphism--I'll try to explain precisely why below.

I am NOT talking to a driver - I am talking to an interface in the
original sense. My program (it'd have to be DOS, or it might run on a
non-PC home computer) assumes you hook an EPSON printer up to the
parallel interface. That the EPSON printer might actually be a STAR or
CANON does not matter; the program's written to expect the printer to
support EPSON operations in some way. Granted, the printer contains an
interface that takes the transmitted data and translates it into the
signals needed to drive the printer meachanism.
And yes, the printed letters might actually look different!

> I suspect we'll never "agree" on a gut level with each other's model,
> because we define our terms slightly differently.  My contention, and
> I hope you're on board with this, is that both models are probably
> equally valid representations of the perceived reality.

Thus it's useful to understand both, and to understand when each is
useful.

 
> We agree on the elements of an abstract interface and late binding.
> A further element for me is that a polymorphic object is a *single*
> thing in a *single* location that *becomes*, at different times and
> depending on circumstances, *distinctly* different objects.
> 
> For example:
> 
>     void Increment_It (IncrementableObject& obj)
>     {
>         obj.Incr();
>     }
> 
> You can pass any object that looks like an IncrementableObject
> to the above, and it invokes "Incr" on it.  The actual object
> could be a numeric value or a list with a "cursor".
> 
> The thing that strikes me here is that "obj" is a single thing in
> a single place that "becomes" different--sometimes very different
> (numeric object vs: list object)--objects under different
> circumstances (different call instances).
> 
> The me, the model of a bunch of different objects "out there" that
> share a similar interface is NOT a polymorphic model.  It just isn't.

You have a bunch of IncrementableObjects out there that share the Incr()
Interface, no?

> To me, they are instances of some class--perhaps a very abstract
> and complicated one, but instances all the same.

class IncrementableObject
    public
         procedure Incr(); virtual;

You'd need a declaration like that, and use an object derived from
thisclass, to use your code above, yes?

> To me, the MS webserver and apache *are* just instances of the class
> WebServer, which defines a specific interface (http).  The class is
> a complex one with a LOT of "instance variables"--the "how" of a
> particular module, for instance.

Both servers do not share any code.
Thus, it is not a case of "instance variables", unless you consider the
code to be one. Actually, then I consider the molecules of your animals
to be mere "Instance variables";) turning stone to gold or a gnat into
an elephant are, after all, easy tasks for computer science! ;)

> Likewise printers.  A trivial example, the vendor name and model
> and serial number are easily seen (at least I think so) as instance
> data that varies from instance to instance.  I also see the deeper
> details of the implementation as a sort of instance variable.

You see everything as instance variable. Incr() code of a different
object? Just an instance variable!

> So, to try to summarize, it's the idea of a *single* thing dealt with
> in a *single* place--but which becomes different things--that is
> vital to my model of polymorphism.

Single thing = printer
Single place = program that outputs to printer
different things = different printers with different print mechanisms,
output quality, user configurability, etc.

> >> An example that sprung to my mind that would be hard to deny as
> >> polymorphic would be a virtual printer that dispatched print jobs
> >> to various real printers depending on the nature of the print job.
> >
> > A "virtual printer" as in "virtual class" does not exist - it's not
> > implemented; you talk to the _real_ printer as if it was the virtual
> > printer, and you don't need to know how the real printer is
> > implemented as long as it behaves to virtual printer rules.
> 
> I can't tell if my example was understood, and that may be due to
> using the term "virtual printer".  What I mean is a *single* thing,
> called a "Printer"--either on my desktop or on the network--to which
> I can send any printable object (document).  That "Printer" then
> dispatches the job to an actual printer appropriate for the job.

I do not understand how that could be polymorphic.

It doesn't jibe with your "Incr()" example. In the Incr example, you
have different objects, and you can send each object the same message.
In the printer example, you have a single object (the dispatch printer)
that can receive different messages.
I view it as a collection of printers that offers as interface a
superset of the interfaces teh printer objects offer.

> Similar to sending a "speak" message to an Animal object and having
> that dispatch to the "became" object--a Dog or Cow, e.g.

There is no "animal" object; there are only actual dogs and cows.
And all of them can speak; there's no animal that'd be more appropriate
to speak than another one.

> > In your argument, you wait for me to give you an example "other end"
> > device, then point to it saying that it's only got one shape, so it
> > can't be polymorphous; and if I then substitute another device for
> > it, that doesn't count because they're similar. :)
> 
> The disconnect is occuring, because (in my eyes) the dispatch is
> deliberate and intentional on your part.  YOU surf from webserver
> to webserver.  

How can the dispatch not be deliberate? What use is it if it isn't?
Anyway, the dispatch is not deliberate on the part of my browser; the
browser (and its programmer) have to make do with whatever server I
connect it to.

> YOU select a network device.  That they share a
> common interface does not fully satisfy *my* polymorphism definition.
> Compare those examples to the "virtual Printer" example above.

Could you provide another example that is similar to your "virtual
printer" example?

Michael

-- 
Feel the stare of my burning hamster and stop smoking!

Programmer Dude schrieb:
> Why am I thinking, "I wonder if AOP might be interesting here?"
> 
> AOP is about cross-cutting concerns, and maybe GUI display is a
> concern that cuts across the concerns of different data types....

Never heard of it - reading up on it now - thanks for the tip!

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

Christer Ericson schrieb:
> It was already pointed out earlier, but it seems it is necessary
> to repeat it: considering that Dijkstra co-authored "Structured
> Programming" with Dahl (and Hoare) in 1972, it is highly unlikely
> Dikjstra was unaware of Dahl's work on Simula, wouldn't you say?
> 
> Instead, as was also pointed out earlier in this thread, the
> logical conclusion would be that Dijkstra is refering to Alan
> Kay, who is the originator of the phrase "object-oriented
> programming".

From what I read, it is easy to perceive Simula as an implementation of
Abstract Data Types (= "Good"), while Kay introduces the idea of
"messages" being passed between "objects"; this concept seems quite
unmathematical, and I can see how Dijkstra would oppose that.

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

"Edward G. Nilges" schrieb:
> Not in a society which produces students unwilling to learn,
> unprepared to learn, and blind to their own limitations.

This is, in fact, the stance of a crap teacher. :)

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

chrisd@gamow.sci.kun.nl (Chris Dams) wrote in message news:<c1kjmk$uqa$1@gamow.sci.kun.nl>...
> Hi!
> 
> spinoza1111@yahoo.com (Edward G. Nilges) writes:
> 
> >If he said this, and I believe he did, it was a massive error on his
> >part. OO was invented in Scandinavia by his colleague Ole Johan Dahl
> >who modified early Fortran and Algol into Simula. Barney Stroustrup
> >knew of the work and as a result developed C++ after emigrating from
> >Denmark.
> 
> Barney Stroustrup???? Perhaps you should vist 

Of course his real first name is Bjarne, which I americanize to Barney
for the hell of it
> http://www.research.att.com/~bs/homepage.html .
> 
> Bye,
> Chris Dams

In article <f5dda427.0402261703.5861a5a1@posting.google.com>, spinoza1111@yahoo.com (Edward G. Nilges) wrote:
>gerryq@indigo.ie (Gerry Quinn) wrote in message
> news:<4Jr%b.4749$rb.62483@news.indigo.ie>...
>>  
>> >> Dijkstra seems incredibly overrated.  As far as I can see he is famous 
>> >> for (a) a trivial pathfinding algorithm that must have been re-invented 
>> >
>> >If you mean the minimum spanning hull algorithm you are just wrong. In
>> 
>> How could I mean it when I said a "pathfinding algorithm"?  As for the 
>> "minimal spanning hull" I must that while I am familiar with "spanning 
>> trees" and "convex hulls", a "spanning hull" is a new one on me.  A 
>
>I think you need to read more and understand more. Cf.
>http://www.cse.unsw.edu.au/~lambert/java/3d/hull.html. I said
>"spanning" hull because this is what a convex hull actually does, it
>spans the outlier points.

That may be what it does, but it is not what it's called.  And plainly 
it is not what is usually called a pathfinding algorithm.  Dijkstra may 
have invented some convex hull algorithm, but his name does not seem to 
be strongly associated with the field.  What is famous is a trivial 
shortest path algorithm, long since superseded for most applications.
 
>> Even if it were, it would not absolve Dijkstra of the charge.  But as I 
>> see it, a teacher who blames his students for learning things 'the wrong 
>> way' when he can't teach them is indeed a crap teacher.
>
>Not in a society which produces students unwilling to learn,
>unprepared to learn, and blind to their own limitations.

He was attacking precisely those students who *were* prepared to learn, 
and had done so outside the orbit of his prejudices.  

>> Actually I did look it up since I posted that.  It doesn't alter the 
>> fact that the famous algorithm bearing his name (or sometimes called 
>> 'wavefront') is trivial and must often have been re-invented.  I did 
>
>No, it was not reinvented. 

Of course it was re-invented.  I'm pretty sure I re-invented it, and 
it's so trivial I'm sure many others did.

>> re-invent it at one time, and recently invented and posted a modified 
>> version giving the second and third sets of shortest paths etc. in 
>> response to a usenet query.
>
>You did so after Dijkstra and you probably did it wrong. You are at
>best a programmer who should not take any credit for algorithm design
>unless you are also capable of publishing a refereed journal article.

I still don't know how to compress these fully, but here's the link:
http://groups.google.com/groups?selm=
PVXlb.2308%24bD.10590%40news.indigo.ie

It is barely less trivial than Dijkstra's algorithm - of *course* it 
works.  The day of the refereed journal is declining, and in any case 
whether I am capable and desirous of getting such an algorithm into such 
a journal has no import.  I do not share your pathethic desire to 
impress by academic name-dropping of various kinds.  [You would do well 
to lose it yourself, as it sits particularly ill with your general 
incapacity to sustain a rigorous argument, or even post on minor matters 
without numerous errors, handwaving, insults, and irrelevant political 
drivel.]

- Gerry Quinn

Hi!

gerryq@indigo.ie (Gerry Quinn) writes:

>That may be what it does, but it is not what it's called.  And plainly 
>it is not what is usually called a pathfinding algorithm.  Dijkstra may 
>have invented some convex hull algorithm, but his name does not seem to 
>be strongly associated with the field.  What is famous is a trivial 
>shortest path algorithm, long since superseded for most applications.

Now, I am curious. Superseded by what other algorithm?

Bye,
Chris Dams

Michael Mendelsohn wrote:

> I've just read ""On the Cruelty of really Teaching Computer Science"
> http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF .
> 
> I think Dijkstra shows a good understanding of the teaching process;
> he's focused on what the teacher makes the students think; centered on
> transmitting a mode of thinking.
> 
> From the appearences, I'd hesitate to label him a "crap teacher".
> 
> This same paper makes a good refutation of TDD, btw. :)

Does the smiley mean "actually, it says nothing about TDD at all,
and is hardly relevant to it"?

-- 
Chris "serious" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

Chris Dollin schrieb:
> Michael Mendelsohn wrote:
> > I've just read ""On the Cruelty of really Teaching Computer Science"
> > http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF .

> > This same paper makes a good refutation of TDD, btw. :)
> 
> Does the smiley mean "actually, it says nothing about TDD at all,
> and is hardly relevant to it"?

It does not say anything about TDD directly, but in my eyes, it is very
relevant to it.

No, it means that from Phlip's posts in this group, I take TDD to be
analogue in reasoning (there's a supposed continuum between the test
cases) and to be operational in nature (the goal of TD is to make the
code perform in an operationally defined way); both ways of thinking
about programming that Dijkstra speaks out against in this paper. 
TDD treats the program as a device (page 9). 

The smiley comes in where Dijkstra states that �software engineering has
accepted as its charter "How to program if you cannot"�, which seems a
trifle exaggerated :). 

Page 12 makes a case against testing, and he goes on to advocate formal
methods of program verification instead. See also p 26/27.

I am not certain that I want to defend this paper, but it does make one
think.

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

Michael Mendelsohn wrote:

re Epson printer...
>> You're talking to a specific object--a driver--in a defined way
>> (Epson talk), and that specific object talks to another specific
>> object (XYZ Brand printer).
> 
> I am NOT talking to a driver - I am talking to an interface in the
> original sense.

That interface *is* the driver of which I speak.  (-:

> That the EPSON printer might actually be a STAR or CANON does not
> matter; the program's written to expect the printer to support
> EPSON operations in some way. Granted, the printer contains an
> interface that takes the transmitted data and translates it into
> the signals needed to drive the printer meachanism.

Right.  Presumably when set in "Epson Emulation Mode" or whatever.
When not, it responds to STAR or CANON language specifics.

And, yes, placing different printers--all with an Epson interface--
ON THE SAME PARALLEL PORT so your program never knows the difference
would be polymorphic by my definition.  The key element being that
the program always prints to that parallel port.

I'll call this "plug'n'chug" polymorphism in I need to refer to it
again!  (-:


>> The thing that strikes me here is that "obj" is a single thing in
>> a single place that "becomes" different--sometimes very different
>> (numeric object vs: list object)--objects under different
>> circumstances (different call instances).

(Compare with same parallel port, different Epson-speaking printers!)

>> The me, the model of a bunch of different objects "out there"
>> that share a similar interface is NOT a polymorphic model.  It
>> just isn't.
> 
> You have a bunch of IncrementableObjects out there that share
> the Incr() Interface, no?

Yes.  The part I don't seem able to get across effectively is that
those IncrementableObjects COME TO ME via the "obj" variable (in
the code fragment from last post).  Just as different physical Epson-
speaking printers would come to me by being put on the same port.

When you speak of objects "out there" or network devices "out there"
you aren't speaking of them COMING TO YOU via a single object.  What
you're talking about is *addressing* different things, but being able
to talk to them using a common subset.


> class IncrementableObject
>     public
>          procedure Incr(); virtual;
> 
> You'd need a declaration like that, and use an object derived from
> thisclass, to use your code above, yes?

Derived from or--if the language allows--supporting the interface.
Whatever mechanism allows it to be treated *as* *if* it were an
IncrementableObject.


>> To me, the MS webserver and apache *are* just instances of the
>> class WebServer, which defines a specific interface (http).
> 
> Both servers do not share any code.
> Thus, it is not a case of "instance variables", unless you
> consider the code to be one.

I do in this case, yes.  It's not central to my argument, though.

> Actually, then I consider the molecules of your animals to be
> mere "Instance variables";)...

Not an invalid point of view, I'd say.  You could certainly model
all mammals, for example, as instances of the class (CMammals :-)
and m_Species as an instance variable.

That brings us right back to the models and philosophy thing.  It
all depends on how you want to look it at.  An important aspect if
programming is finding a *useful* and *correct* model.

> You see everything as instance variable. Incr() code of a
> different object? Just an instance variable!

Ah, but of what?  What's the template for it?  (-:

The "template" required instance variables for a web server is the
specification for different services and features.  If you think
of each as a "bullet point" on a list, it even almost looks like a
class definition (each bullet point "declaring" a member).


>> So, to try to summarize, it's the idea of a *single* thing dealt
>> with in a *single* place--but which becomes different things--that
>> is vital to my model of polymorphism.
> 
> Single thing = printer
> Single place = program that outputs to printer
> different things = different printers with different print
> mechanisms, output quality, user configurability, etc.

Now all you need to do is bind that single thing dynamically to
the different things such that you never actually deal with the
different things--ONLY the single thing--and you're polymorphic.


>> I can send any printable object (document).  That "Printer" then
>> dispatches the job to an actual printer appropriate for the job.
> 
> I do not understand how that could be polymorphic.

Because from my point of view, there's just this abstract "Printer"
thing that accepts "Print Messages" (which include data).  The
*type* of that data causes dynamic dispatch to a real printer.

IOW, the "Printer" (itself!!) takes on many shapes (from my POV).

> It doesn't jibe with your "Incr()" example. In the Incr example,
> you have different objects, and you can send each object the
> same message.

No, I send the message to the "obj" object.  It just so happens
that "obj" object *becomes* different real objects each time through
the code.

> In the printer example, you have a single object (the dispatch
> printer) that can receive different messages.

Yes, just like the "obj" variable.

> I view it as a collection of printers that offers as interface a
> superset of the interfaces teh printer objects offer.

Your superset being the union of all supported abilities, yes?

That's a fine model, too.


>> Similar to sending a "speak" message to an Animal object and having
>> that dispatch to the "became" object--a Dog or Cow, e.g.
> 
> There is no "animal" object; there are only actual dogs and cows.

There is an "animal" *variable* (object!) in the code that becomes
(is bound to/refers to/points at/whatever) a specific object each
time.  But the calling code has NO idea what that object is.  It
only knows about the "animal" abstraction.


>> The disconnect is occuring, because (in my eyes) the dispatch is
>> deliberate and intentional on your part.  YOU surf from webserver
>> to webserver.
> 
> How can the dispatch not be deliberate? What use is it if it isn't?
> Anyway, the dispatch is not deliberate on the part of my browser; the
> browser (and its programmer) have to make do with whatever server I
> connect it to.

Right.  That YOU CONNECT it to.  That's exactly my point.  YOU do the
CONNECTING.  There's no single abstract object dynamically becoming
different concrete specific objects at different times.

YOU CONNECT to this server and view a few pages. Then YOU CONNECT
to that server and view a few pages.

> Could you provide another example that is similar to your "virtual
> printer" example?

Problem is the Virtual Printer example was a bridge trying to find
a way for me to reconcile our views.  I don't find the network
polymorphism model compelling, so it's hard to think of situations
that apply.

I guess one might say the browser itself is sort of polymorphic in
that it is a single thing that reacts dynamically to the type of
data received (html/gif/audio/etc).  I don't think it's a very good
example.  Polymorphism is (as I see it) a pretty abstract concept
that I don't know that I see applying much in the physical world.

Clearly your MV.  More power to ya!  (-:

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|