Every idiot claims that what he said was a joke when he gets caught.

  In any case: acquire some _taste_, you anti-social retard.

  Please note: if you think the above is offensive, it is of course a joke
  and you did not get it.  If you do not find it offensive, it is of course
  not a joke, and you did not get it.  This is not a joke.  Get it?

I self-deprecatingly called myself a "fool" in order to save you the
bother of pointing it out YET again, and everyone else of reading it.  
Not that that stopped you.

I don't get you.

It should be clear by now that there are few axioms in programming.
Like nil/null/false. Like when is something a pattern or a tools based
on observed patterns? One discovers these things through experience.

On Fri, 30 Nov 2001 20:38:33 +1300, Bruce Hoult <br...@hoult.org>
wrote:

Would you feel better if Erik (and others) consistently said "you act
foolishly, you say foolish things and you keep doing it regardless of
our responses"? Why do you perceive that "fool" and "idiot" are such
absolute damning terms that you must keep "defending" yourself at any
cost?

A few other posters to c.l.l arrive at this stage: endless clashes
with Erik. The reason is usually that they do not read him carefully
enough. Review the postings _carefully_ and if possible with neutral
eyes. You may see things in a new light ...

--
Janis Dzerins

As soon as one brings in an argument that's contradicting Eriks, he
starts calling people names, assuming that the only explanation is
that the guy on the other side is too stupid to understand *his*
argument.  Even if this were true, his behaviour would be
unacceptable, much worse is that he doesn't even try to explain where
the contradiction is, let alone considering that it is *him* who might
be wrong, or that it may be his fault that the other person didn't
understand his argument, because he failed to communicate it properly.

If somebody behaved like that in my team, I would fire him without
thinking twice about his intelligence.  The possible damage to the
team is a bigger threat than having to find a replacement.

I will do as several people suggested to me in personal communication:
I'll just stop taking Erik seriously.

Andreas

Regs, Pierre.

Early versions of the software of the Apollo Guidance Computer used on
Apollo spacecrafts, i.e. both the Command Module and the Lunar Module,
included lots of checks for preventing astronauts from performing
potentially dangerous manoeuvres.

The main contribution from astronauts--i.e. pilots--to the design was to
ask that all those checks be removed. As someone recently said in an
Apollo-related mailing list, think of what might have happened if the
Apollo 13 LM computer detected an "unusual" engine firing.

ja...@unlambda.com (James A. Crippen) writes:

Cheers

On approach the pilots decided to abort and began a climb, but the
computer compensated and managed to complete the landing, tho the runway
was then a few miles back. :(

I wonder whether method combination could be introduced in Dylan
without a performance penalty.  Lots of the Dylan design tradeoffs
revolve around insisting to have objects all the way down, while still
being able to generate fast code.

Andreas

One thing I've learned in my time as a "language diplomat" (or whatever
inflated term I can get away with calling the one who gets elected to go
into voting situations with other members of the CL community :-), is this:

There is a BIG difference between a "team" (a company that can ruthlessly
demand its own way and fire anyone who doesn't agree) and a "community"
(especially a global community with multiple sovereigns, as occurs with the
national standards bodies, though it's really remarkably similiar, and
probably not accidentally so, at the intercorporate level within a nation,
at least within the US, where we allow companies to indulge pretty close to
the sense of absolute autonomy without government intervention in the name
of any greater good).  That chief difference is that the people you don't
like and whose support you need in order to consider you have a team do not
work for you and cannot be fired.  You are stuck with them.  And they are
your tactical equal.  So unless you learn to work with them, on those terms,
pleasant or not, you don't move ahead.

Incidentally, as an aside, this is the reason a charter document (such as
 http://world.std.com/~pitman/CL/x3j13-86-020.html
is so important.  It doesn't directly give power, but indirectly it does
because once someone has agreed to a premise (and everyone on the committee
had to buy into that one), cognitive dissonance becomes a powerful ally.
Being able to say "You promised you'd do x" is about the closest you can get
in a world where you can't fire anyone to saying "You must do x".  But beyond
that, and common sense reasoning, no one in such a setting has power over
another.

As a further aside, this is the thing Perot never understood about US
politics.  He always wanted to envision the US Government as a badly
run company, needing an executive to pull things together and
centralize orders.  He really does not appear to grasp the notion of
separation of powers in the US government, and that there is a purpose
to having the US Congress not "answer to" the US president.  The requirement
for consensus is what keeps dictatorships from forming.  

  It is never about disagreement.  You were not called anything at all as
  long as you _disagreed_.  But this is quite typical.  Those who actually
  _are_ retarded think it is about disagreement, and they always resort to
  this idiotic "argument".

  A person who is a pathological liar does not just _disagree_ with others.
  A thief who breaks into a person's house, does not merely _disagree_ with
  him on the concept of property rights.  Someone who drives under the
  influence of drugs or alcohol does not just _disagree_ with the limits
  and traffic rules.  Yes, they probably _also_ disagree, but the criminal
  mind is indeed marked by the failure to understand that disagreement is
  not a reason for anybody to react harshly.  Breaking rules and acting on
  false premises, however, is.  However, since you have a criminal mind,
  and go on to prove it beyond reasonable doubt, you think that you are
  being attacked for _disagreeing_ with the prevailing rules, as if it were
  a free speech issue or you should have been respected for your "opinion".

  Some people are so amazingly smart (by your standards) that they wonder
  what happened when something unexpected occurs.  You are not that smart.
  That means that you react with an urge to defend yourself when you think
  you see something hurtful to yourself.  Only insecure _and_ stupid people
  do that.  Only people with _inflated_ egos respond violently when others
  challenge their inflated egos with _facts_.  Only people with _inflated_
  egos respond violently when people _disagree_ with them, and therefore
  think that others react to disagreement.  Spread of disinformation is not
  disagreement.  Osama bin Laden does not "disagree" with George W. Bush on
  the policies of the United States in the Middle East.  Yet you can bet
  that if he were half a smart as he is rumored to be, he will argue that
  he "only expressed his disagreement" when defending himself and cannot
  understand why he caused Afghanistan to be bombed.

| As soon as one brings in an argument that's contradicting Eriks, he
| starts calling people names, assuming that the only explanation is that
| the guy on the other side is too stupid to understand *his* argument.

  This is again the typical defense made by retarded people.  That it is in
  fact false, that there is lots of available counter-evidence and that it
  is so stupid a thing to say that it is more self-incriminating than
  anything they have previously said or done, does not bother them.  This
  is about _making_up_ things to attack other people for, and then getting
  more insistent when their victim objects to it.

  Exaggeration is the favorite tool of the dysfunctional mind.  And you who
  made such a stink about _logic_.  That I demonstrated that you are devoid
  of logical thinking skills, has caused you to take this personally, but
  at least you have stopped bragging about logic.  That is good, and
  probably goes to show that I was indeed right: You have never been
  challenged on your thinking skills, but had a hugely inflated ego that
  has been cut down to size.   This is good for you, provided that you do
  not develop a cancerous growth of arrogant ignorance, but you are on the
  way there.

| I did.  His intelligence seems to be above average, so some of the things
| he writes actually make sense.  It is unfortunate that this makes him so
| arrogant that it is impossible to have a discussion with him.

  You only observe it from this point of view because you are too stupid to
  recognize your own arrogancae from _ignorance_.

| If somebody behaved like that in my team, I would fire him without
| thinking twice about his intelligence.  The possible damage to the team
| is a bigger threat than having to find a replacement.

  If you behaved the way you have in any professional setting, you would be
  fired for incompetence before I had time to react.

| I will do as several people suggested to me in personal communication:
| I'll just stop taking Erik seriously.

  This only reflects very badly on yourself.  Like a few other prize morons
  here, you may never understand what happened.

  If you have a working brain, use it to go back over and re-read your
  _own_ contributions, and accept the blame for your own behavior.  This is
  what morons are unable to do, and intelligent people figure out quickly.

  I have _never_ met a person of reasonable intelligence who failed to see
  how he could make every piece of criticism go away.  Indeed, I have come
  to make it a test for reasonable intelligence that they do, and it works
  amazingly well.  You failed.  Lots of people have realized this already.
  _They_ would not mail you and tell you that you are a moron, however.

  A normally intelligent person would have taken my comments to _you_ as
  being precisely "you are fired!  get the hell out of here!"  You did not
  understand this, did you?  It was because of the "possible damage to the
  team" that existed here before you arrived that you are being chastised
  for your behavioral and attitude problems.  You did not understand this,
  did you?  But since you _are_ such a moron and feel so righteous about
  continuing to post so much insanity, you do not even _recognize_ this as
  you write your stupid drivel about firing me.  You are the epitome of
  arrogance.  You have the introspective skills of a mad dog.  Insight into
  one's own behavior and impact on others is not something that comes until
  one is fairly well above average.  You are not.  I find some enjoyment in
  "proving" that people like you, who come only to make a disturbance in a
  community, are indeed far too unintelligent to _understand_ what they do.

  Incidentally, I do not go to work for morons, so you would never _get_ a
  chance to fire me.  Neither do I hire morons, so you would not be in
  danger of being fired by me, either.  Amazingly, so many so much smarter
  people than you exist that working relationships with people who _think_
  do not look like USENET discussions with arrogant morons.  That you do
  not even recognize this is somewhat alarming.  It might indicate that you
  are _actually_ at the best of your professional performance when you act
  the way you do in this newsgroup.  It would be inconcveiable for _me_ to
  think of even the most egregiously rabid idiot as if he was trying to
  sell himself to a prospective employer, but you apparently think your
  actions here have been a sales pitch to _your_ future employers, not to
  mention people who would have to take your instructions.  I am actually
  very happy that I have prevented a large number of people from ever doing
  _business_ with you as you proclaim that you would behave the same way
  towards people who pay you as people who do not.  I have never made that
  mistake.  I do not bite the hand that feeds me.  I do, however, kill the
  dogs who bite mine when I feed them in a voluntary medium like USENET.
  You, the mad dog of Dylan, would not understand the difference or your
  own role in this interplay.

  You _are_ a retard, Andreas Bogk.  Adjust accordingly.  If I had to deal
  with you professionally, I would have told you to hold the onions and
  give me large fries.

(1) One could also consider an approach where constructors are
    supplied for the appropriate classes (MAKE-FOO, MAKE-BAR, etc.,
    or MAKE-THING, which accepts only an appropriate class to
    instantiate, if that class needs to be determined at run time),
    and the programmers are asked not to call MAKE-INSTANCE at all,
    at least for classes in the provided hierarchy.  (Or are the
    users so random that they cannot be asked even that?)  This
    approach is analogous to just calling slot accessors and
    refraining from calling SLOT-VALUE, and makes it harder to
    instantiate the wrong class by accident.  There could also be a
    MAKE-THE-ABSTRACT-CLASS constructor which provides some
    suitable notification to the programmer.

(2) If one decides to put some restraints on instantiating the
    `abstract' class, perhaps a `gentler' approach would be more
    productive, like issuing only a warning (or just logging a
    message somewhere), rather than signalling an error.

(3) I don't know how often this would occur in practice, but at
    least in theory I can think of a need to instantiate the
    `abstract' class.  Consider a scenario where the program needs
    to create the object early (perhaps to store a reference to it
    somewhere), when it doesn't know yet which specific class it
    needs.  Then an instance of the `abstract' class might be
    created, to be subjected to CHANGE-CLASS later as necessary.

- Call the current Dylan method combination, simple-method-combination
  and make it the default.  No performance impact should result.
- Add what is called standard-method-combination in CL as
  advanced-method-combination.  Come up with useful definitions of the
  various GF and method declarations.  A certain amount of performance
  impact is going to be necessary.
- Repeat for other M-Cs you can think of.

Adding user-programmable method combinations to the mix seems more
problematic, because it probably presupposes programmability at
compile-time, and it might be difficult to reconcile with the
declaration business.

That said, while doing it this way might be in the Dylan spirit, I
personally find the "static is the default" of Dylan to be rather
contrary to the whole point of a lot of things, including that of
standard-method-combination.  The static-by-default approach can, IMHO
only work, if the original programmer knows best.  The problem in my
eyes is that in a statistically significant proportion of the cases he
doesn't, but rather goes with the default, without thinking things
through (which is also rather difficult, without having a way to see
into the future).  The default in CL might result in slower than
necessary code.  The default in Dylan will result in the inability to
correct a problem, even if you can prove to your own satisfaction that
overriding the original programmers decision is safe (the no-way-out
problem).

Standard-Method-Combination is at its most powerful, when it allows me
to add code to and override code in a GF in places that the original
programmer didn't anticipate.  If he did, he could just as easily have
made the :before, :after, and :around segments into their own GFs.
Not as elegant as s-m-c, but not fatally so.

So defaulting to simple-m-c would IMHO not realize most of the
advantages of standard-m-c.  Defaulting to standard-m-c will cost you,
especially since sealed domain declarations on such a GF shouldn't
prohibit adding non-primary methods on superclasses.

But then again, my preferences run counter to the whole
"static-by-default" business in Dylan, so feel free to discount them.

Regs, Pierre.

If I can't hear you anymore, will you still exist?

*plonk*

Andreas

http://www.xanalys.com/software_tools/reference/lwl41/deluser/D_166.H...

ciao,
Jochen

I think there are similiar tradeoffs in CL, I have seen the
recommendation to use a struct instead of a class when performance
matters.

Andreas

  No, people smarter than you would not have gotten into this mess to begin
  with.  Again, you demonstrate that you cannot think clearly when under
  pressure.  I did not come out of nowhere to attack you -- you did get a
  number of warnings and you decided to pick a fight.  Now you lose, and
  you are trying to salvage your pride.  It is _truly_ pathetic to watch.

  It is typical of people of very, very low self-esteem to play the stupid
  mirror game when they are given advice, trying to reflect everything back
  at whoever told them something.  This demonstrates that it is much more
  important to them to take revenge and defend themselves than to think,
  which is actually one of the things I want to demonstrate about you guys.

  So act smarter!  THINK!  You have received this advice dozens of times,
  yet the only thing you do is act more and more stupid.  This is why it is
  becoming increasingly obvious that you _are_ retarded.

| If I can't hear you anymore, will you still exist?

  Yes, and you will still read my articles to see what I say about your
  pathetic behavior.  The reason is the same as that which prompted you to
  attack me in the first place.  (Of course, you will think of it as self-
  defense, but _you_ were in fact never under attack.  This you will never
  understand.)

 (unless *inside-make-thing*
   (error "You muse use ~S to create this object." 'make-thing))

I don't think that solution is totally general to the full class of situations
being expressed here, but you're right to point it out as a sometimes option.

It also reminds me of another option, though, which is that sometimes
the class name can be internal to a package, and does not have to be
exported.   Sometimes one wants to export an abstract class, and then the
problem  under discussion still exists, but when it's just a class you made
for internal purposes, you can rely on people programming your own package
to use it according to specialized constraints known to your design team,
and the package system can tell other people "hands off".

I think it's a design mistake that CL doesn't simply have a :abstract-class
option.  Flavors had it (can't remember what it was called, but probably
:abstract-flavor), and I'm not sure why it was omitted for CLOS.  Perhaps
it was just accidental.  The design of CLOS was a process that was very
insular and I don't know much about; Richard Gabriel, who's been posting
here recently about patterns, was a key part of it and might know if there
was a discussion of this. (hint, hint, rpg, that's your cue)  

#define protected public
#define private public
#include <your_precious_abstraction.h>

A lot of compiler implementors forget to use only variables in
compiler namespace as arguments to their macros in compiler specific
include files. [1]

[0] note to C++ standard gurus: yes this violates the ODR and causes
undefined behaviour. It has a reasonable change of working on some
implementations though.

[1] They may have caught up now. It's been more than four years I've
had to look at C++.

I'm all for having sealing declarations and similar optional (from the
point of view of the user, but often also from the implementation's
point of view) permissions to the compiler that allow generation of
extremely fast code at the cost of flexibility in those few spots in a
program where it matters.

- Single inheritance, so a simple class inheritance tree, not a DAG
- No class redefinition, hence no changes in the inheritance tree
- No change-class of instances, hence no need for storage indirection

This enables the usual trick of hard-coded constant slot offsets
(similar to the primary class declarations in Dylan), and eliminates
some other overhead.

That said, modern CLOS implementations will also do a great amount of
optimization for common cases (even CMUCL/PCL does lots of that,
details of which I post from time to time, and it isn't one of the
fastest CLOS implementations around).

The important thing IMHO is that the language doesn't default you to
use one or the other...

Regs, Pierre.