intelligence is a search for satisfaction

In article <2p3vn8Fgpa1nU2.RemoveThis@uni-berlin.de>,
try_vanevery_at_mycompanyname.RemoveThis@yahoo.com says...
> cr88192 wrote:
> >>
> > lets not forget "whip", "paddle", "rope", or any other other items
> > that might be lurking in data files...
> >
> > (oh, but why do classes supposedly represent "real world objects" if
> > we can't use them for real word objects?...).
>
> Because the OO advocates are lying to you. Viewing the world as objects
> with well-defined boundaries within a simple inheritance hierarchy is a lot
> like viewing the world in terms of Newtonian physics. It works a lot of the
> time, but it certainly doesn't take Relativity into account. Actually, OO
> isn't anywhere near as pervasive as Newtonian physics. It's pretty easy to
> run into problems like "is this an ISA relation or a HAS relation? Who HAS
> who?"

Hang on Brandon - I already pointed out the the FP-ers that real-world
objects are only one metaphor for objects. The problem is that a lot of
people who are criticising OO don't seem to understand it very well.

And like Peter says, aggregation is right there in the top drawer of the
toolkit, probably above inheritance. Certainly my instincts would be to
always look at aggregation before multiple inheritance.

In fact, aggregation is in any case a more obvious attribute that one
would expect of 'objects'. Show me some kids blocks, and it's more
obvious that I can put one on top of another, than that I can stretch
one to double its height!

- Gerry Quinn
 >> Stay informed about: intelligence is a search for satisfaction 

In article <m3acwj82lf.fsf DeleteThis @localhost.localdomain>, jknapka DeleteThis @kneuro.net
says...
> [c.l.functional removed due to increasing OT-ness; cc'd to Philippa for politeness' sake]
> Gerry Quinn <gerryq DeleteThis @DELETETHISindigo.ie> writes:

> > I think, though, MI touches on an issue I would call "data contamination
> > of the inheritance hierarchy". I know there's no clear dividing line,
> > but I just don't like when objects get too specific, and MI seems to be
> > an invitation for this. The words "sword" and "mace" should IMO appear
> > only in data files, not in class names.
>
> Probably this bothers you because you have no simple way, in C++, of
> converting the word "sword" in a data file into an instance of an
> appropriate class (say Weapon_sword) at runtime. In eg Python that
> sort of thing is trivial (myWeapon = eval("Weapon_"+weaponName+"()")),
> and in Java it's only a bit of a pain
> (Weapon myWeapon=Class.forName("Weapon_"+weaponName).newInstance()).

No, it's because I don't want to do that sort of thing at all. You
can't perfectly separate data from the inheritance hierarchy, but I
believe you should push as much as possible down into the data.

> In C++ you have to write quite a bit of code to achieve this (either a
> map of weapon_name->class_factory_function, which needs to be
> maintained whenever weapons are added/changed; or else a mechanism
> based on runtime loading of dynamic factories, which is more complex
> at the outset, but more generic and flexible). Which means that having
> a "Weapon" class that accepts a "what kind of weapon am I really"
> parameter is simpler in the short run, though it breaks encapsulation
> something terrible unless you're very disciplined about implementing
> the innards of class Weapon (at which point you may has well have done
> one of the complicated-but-flexible things in the first place,
> especially since you probably have to solve this same issue for
> a number of different kinds of interface).

The point is that there is no simple answer. You can't do it all with
inheritance, and you can't do it all with data. I'm expressing a
preference for favouring data when possible for specifics, and leaving
the classes for abstractions.

There's no hard and fast rule. For example, I referred to the context
of a roguelike game, where there might be lots of weapons without any
graphics. In an FPS there might be more properties that make swords
special, and more case for a Sword class. Either way, you're never
going to be completely happy with the elegance of your solution, but
that is inevitable because the problem domain is not elegant. Perfect
elegance is a chimera.

> Not quite sure what any of this has to do with MI, though...

The example was to do with properties of [simulated physical] objects.
In general, though, MI is an invitation to over-complex inheritance
hierarchies.

- Gerry Quinn
 >> Stay informed about: intelligence is a search for satisfaction 

In article <cghugp$89910$1@hades.rz.uni-saarland.de>, rossberg.TakeThisOut@ps.uni-
sb.de says...
> Gerry Quinn wrote:
> >
> > I mader a comment about a particular language. (Incidentally, I don't
> > see that C++ makes library programming hard. The proper design of
> > libraries IS hard, irrespective of the language.)
>
> The design of a library may or may not be hard per se, depending on the
> kind of library and the degree of genericity you want to achieve.
>
> C++ at least makes it hard to design (and use!) libraries for generic
> data structures and algorithms. The STL is the perfect example. It has
> interesting and non-trivial ideas in it, but much of it is nothing but
> tedious boilerplate forced on it by the language.

STL isn't hard to use.

And sure, there may be languages that make algorithm libraries easier,
no doubt at the expense of making other types of libraries harder.
Algorithms are not a very large part of most significant programming
projects IMO.

> No, I'm just trying to untangle this strange idea of yours of
> attributing everything to "object orientation" just because you use
> classes in the course of it, even when it actually is independent of the
> use of classes.

I made no such argument. Once again you are misrepresenting me.

> If you'd be programming in Smalltalk, would you consider adding numbers
> an object-oriented programming technique, just because numbers are
> objects in Smalltalk?

Non sequitur.

> > If I use OO
> > methodologies to implement something it's not really OO if I could have
> > used something else?
>
> The way you employ it might be OO, but you cannot say that the
> methodoloy itself was "provided" by OO if it is independent of the use
> of OO (which was the case here).

If I use OO methodologies to implement something, the methodology is
obviously not independent of OO. You're not making sense to me.

- Gerry Quinn
 >> Stay informed about: intelligence is a search for satisfaction 

Thant Tessman wrote:
> Peter Ashford wrote:
>
> [...]
>
>> Java succeeded because it was a clean OO extention to C that
>> significantly advanced the language. C++ wasn't - C++ is a
>> 'multiparadigm language' (read "dog's breakfast"). Objective C was a
>> cleaner extension of C than C++, but unlike Java, it stayed failry
>> close to the orignal nature of C, which as many have commented in
>> relation to C++, is in many cases a liabilty.
>
>
> But the choice wasn't between Java and C++ or Objective C. I've already
> mentioned Eiffel and Modula-3,

"a clean OO extention to C"

That applies to neither of those languages.

And being similar to C is not "hype"

>No, there's no getting around it:
> Java succeeded because it was hyped, and adopted by people who knew
> nothing about programming.

So you think my 20 years of programming experience encompassing
procedural, functional, OO and machine code programming makes me a
person who knows nothing about programming?

I'm going to go out on a limb and suggest that you're more than just a
little arrogant.
 >> Stay informed about: intelligence is a search for satisfaction 

Peter Ashford wrote:
> Thant Tessman wrote:

[...]

>> But the choice wasn't between Java and C++ or Objective C. I've
>> already mentioned Eiffel and Modula-3,
>
>
> "a clean OO extention to C"
>
> That applies to neither of those languages.

So Objective-C was too C-like, Eiffel was not C-like enough, but Java
was just right?


> And being similar to C is not "hype"

Nor is it by itself a valid defense of a language's technical
suitability. Of course there are advantages to being C-like when that's
what your engineers are familiar with, but that's a cultural argument,
not a technical one.


>> Java succeeded because it was hyped, and adopted by people who knew
>> nothing about programming.
>
>
> So you think my 20 years of programming experience encompassing
> procedural, functional, OO and machine code programming makes me a
> person who knows nothing about programming?
>
> I'm going to go out on a limb and suggest that you're more than just a
> little arrogant.

Sorry. I was referring to pointy-haired bosses concerned with buzz-word
compliance.

I should also mention that I'm pretty sure Dylan, Ada, and Erlang were
around at the time too. I don't know enough about Ada and Erlang to have
an opinion, but I know Dylan would have made a better langauge than Java
for general application development. Like I said, Java was never even
designed for general application development.


-thant
 >> Stay informed about: intelligence is a search for satisfaction 

Thant Tessman wrote:
....
> I should also mention that I'm pretty sure Dylan, Ada, and Erlang were
> around at the time too. I don't know enough about Ada and Erlang to have
> an opinion, but I know Dylan would have made a better langauge than Java
> for general application development. Like I said, Java was never even
> designed for general application development.

I don't know enough about Dylan and Erlang to form an opinion,
but I think Ada would've been a fine choice for general application
development. It did have two large problems: the validation process
made compiler suites expensive, at least in early days, and it was
something mandated by DoD. It had its share of other problems, too,
but cost and provenance had a lot to do with its lack of acceptance.
(The size of the language and surface similarity to Pascal are also
big candidate causes.)

Java had the big advantages of being free and running most everywhere,
plus it looked a lot like C/C++. It has most of the useful features
of Modula-2 or Ada, and you get to use curly braces and ++. At least,
those were the reasons I started using it. It's convenient.
Considering I avoided C like the plague all through the 80s until
finally forced kicking and screaming to it in 92 or so, "hype" has
not been my primary driver in choosing languages.

--
Carl Burke
cburke.TakeThisOut@mitre.org
 >> Stay informed about: intelligence is a search for satisfaction 

Thant Tessman <thant RemoveThis @acm.org> writes:

> I should also mention that I'm pretty sure Dylan, Ada, and
> Erlang were around at the time too. I don't know enough
> about Ada and Erlang to have an opinion, [...]

Erlang was presented to the world at the end of May 1990.

I think it's fair to say that Erlang as we know it today
was formally announced in 1992, at the XIII International
Switching Symposium in Stokholm, Sweden.

The version presented at the XIV International Switching
Symposium in Yokohama in October 1992 was pretty similar
to the version used today (fluff like records and higher-order
functions came later, but concurrency, exception handling,
lightweight per-process garbage collection and distribution
were all in there.

Java was formally announced by Sun May 23, 1995.
It was at the brainstorming stage in January 1991.
Also during 1995, Netscape, Toshiba, Oracle, Borland,
Lotus, Intuit, MacroMedia, Spyglass, et al announced
plans to develop in Java. Considering that the first
HotJava prototype was demonstrated to Sun executives
in September 1994, one must conclude that Sun moved
very fast once a decision was made. To form such
alliances in less than one year based on prototypes
is very impressive.

Erlang Systems AB was formed in 1993 in order to market
and support Erlang commercially. However, the financial
and strategic backing from Ericsson proved insufficient
to make any real impression on the market. As one of
the first overseas customers at the time, I thought that
a clear long-term commitment from Ericsson was lacking,
making it difficult to guess how long Erlang would be
around. During 1996, Ericsson halted all marketing
activitites in order to focus all Erlang expertise on
internal development.

Erlang wasn't designed for applets, but that was hardly
criticized in 1992 -- NCSA Mosaic 1.0 didn't appear until
April 1993. The most notable difference between Java and
Erlang in this regard is probably the sandbox in Java,
and the lack of such in Erlang. While both languages had
support for concurrency, Erlang's concurrency support was,
and remains, far superior to that of Java, in terms of
expressiveness, robustness and performance. However,
there was no great demand for development tools with those
characteristics in the 90's. I think that demand is slowly
materializing now, as it starts becoming (commercially)
interesting to develop robust and scalable internet services.
However, most people seem convinced that you have to
purchase "real" tools like RoseRT or IBM's WebSphere in
order to build robust internet servers. Compared to WebSphere,
I'd stick my neck out and claim that Erlang is far superior
in terms of core technology, but WebSphere has the edge
in terms of e.g. XML- and SQL-based tool and library support.
Whether this makes it a better platform for e-commerce
development, I dare not say. It's not necessarily so,
but the appearance of superior suitability for the task is
overwhelming on the surface.

The notion of using Java for portable, web-based applications
was certainly exciting, but for many reasons, it remained
largely impractical for many years.

/Uffe

(Source: http://www.ils.unc.edu/blaze/java/javahist.html,
http://www.erlang.se/publications/bjarnelic.ps, and my
own recolletion.)
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes
 >> Stay informed about: intelligence is a search for satisfaction 

> Of course I suppose you could have type safety without GC, *if* you never
> wanted to deallocate anything, or didn't want pointers, or didn't care
> about
> having to do a run-type type-check every time you referenced an object. I
> suppose the designers of Java felt that was too high a price to pay.


IOW you can have type safety without GC.
 >> Stay informed about: intelligence is a search for satisfaction 

Thant Tessman wrote:

> Peter Ashford wrote:
>
>>>
>>> No, Java definitely became popular because of its association in the
>>> minds of managers and developers with the future of the internet.
>>
>>
>>
>> But that *isn't* hype.
>
>
> At the time it most certainly was.

No it wasn't. The idea was (and still is) that VMs allowed Java to run
anywhere a VM was implemented, which means any OS or browser that has a
plug-in. It's quite clear how you get the idea that Java can run on any
device. That's not hype, that a obvious, easy to understand path to
Java running wherever you want it.

(Of course, the same could in theory happen for *any* language, but
since noone was promising to develop all those VMs for other languages,
it's a valid comparison)
 >> Stay informed about: intelligence is a search for satisfaction 

Thant Tessman wrote:

> Peter Ashford wrote:
>
>> Thant Tessman wrote:
>
>
> [...]
>
>>> But the choice wasn't between Java and C++ or Objective C. I've
>>> already mentioned Eiffel and Modula-3,
>>
>>
>>
>> "a clean OO extention to C"
>>
>> That applies to neither of those languages.
>
>
> So Objective-C was too C-like, Eiffel was not C-like enough, but Java
> was just right?

Is that hard for you to understand? Most C programmers hate pascal
syntax and certainly that's what killed Eiffel for me (and my workmates
at the time who all had similar C/C++ backgrounds)

Objective-C doesn't offer any the safety, simplicity and run anywhere
features of Java. In fact, Objective-C always has been strongly related
to Apple which is quite the antithesis of a portable language. And yes,
it is too close to C - all the original C gotchas can bite you just as
hard in Objective-C as they can in C (or C++)


>
>> And being similar to C is not "hype"
>
>
> Nor is it by itself a valid defense of a language's technical
> suitability. Of course there are advantages to being C-like when that's
> what your engineers are familiar with, but that's a cultural argument,
> not a technical one.

I never said it was. But it is a perfectly valid reason to use a
language.

>
>>> Java succeeded because it was hyped, and adopted by people who knew
>>> nothing about programming.
>>
>>
>>
>> So you think my 20 years of programming experience encompassing
>> procedural, functional, OO and machine code programming makes me a
>> person who knows nothing about programming?
>>
>> I'm going to go out on a limb and suggest that you're more than just a
>> little arrogant.
>
> Sorry. I was referring to pointy-haired bosses concerned with buzz-word
> compliance.

I acknowledge that that is a factor in some work places.

> I should also mention that I'm pretty sure Dylan, Ada, and Erlang were
> around at the time too. I don't know enough about Ada and Erlang to have
> an opinion,

Erlang was a little later in terms of getting attention where I worked
at the time. I'm actually revisiting Erlang at the moment - it's a
really great language. Much easier to read than OCaml (IMO) and its
distribution / concurrency tools are second to none.

ADA on the other hand is a great wobbling beast of features with (IMO)
far too many keywords. I think it's significant that despite the fast
resources of the US DOD pushing the language (and I can tell you "hype"
was well and truly attached to ADA) that noone wanted to touch it with a
barge poll. Well, I had to at one point, but only because they made me )

In fact, I think there's the perfect counter example to you "hype made
Java" argument - ADA was pushed HARD by the DOD and they put a lot of
money into the push and forced all their contracts to be done in ADA,
yet despite their massive resources, ADA largely died a lonely death.
Personally I think that's because the language wasn't a good fit for
doing what people needed to do.


but I know Dylan would have made a better langauge than Java
> for general application development. Like I said, Java was never even
> designed for general application development.

Regardless if it was designed to fry dodo eggs, its features are very
well suited to application development. GC provides safety, the API
emphasises simplicity the language is designed to be readable and
checked exceptions are a powerful way to guarantee correctness. The
fact that it looks like C is an added advantage for people coming from
the other mainstream application development languages.

That's all "good fit" not "hype".

I can't comment on Dylan - I know I've cast my eyes over it, but not
well enough to know enough to comment. I bet that I can guess that it
didn't have major corporations on board to ensure that Dylan would run
everywhere?


Peter.
 >> Stay informed about: intelligence is a search for satisfaction 

> Erlang wasn't designed for applets, but that was hardly
> criticized in 1992 -- NCSA Mosaic 1.0 didn't appear until
> April 1993. The most notable difference between Java and
> Erlang in this regard is probably the sandbox in Java,
> and the lack of such in Erlang. While both languages had
> support for concurrency, Erlang's concurrency support was,
> and remains, far superior to that of Java, in terms of
> expressiveness, robustness and performance.

IMO, Erlang blows everything else out of the water on that score.


However,
> there was no great demand for development tools with those
> characteristics in the 90's. I think that demand is slowly
> materializing now, as it starts becoming (commercially)
> interesting to develop robust and scalable internet services.
> However, most people seem convinced that you have to
> purchase "real" tools like RoseRT or IBM's WebSphere in
> order to build robust internet servers. Compared to WebSphere,
> I'd stick my neck out and claim that Erlang is far superior
> in terms of core technology, but WebSphere has the edge
> in terms of e.g. XML- and SQL-based tool and library support.
> Whether this makes it a better platform for e-commerce
> development, I dare not say. It's not necessarily so,
> but the appearance of superior suitability for the task is
> overwhelming on the surface.

You might well be right. My only concern with Erlang's distributed
computing features is just how tweakable they are, and how you tweak
them. Erickson's examples are telephony examples where you can assume
operation over an INAP stack. What if I want to take Erlang and run it
over a network which it's not aware of yet? This kind of thing is not
an issue in lower level languages, but it appears to be a concern for
Erlang, I would think?
 >> Stay informed about: intelligence is a search for satisfaction 

Peter Ashford <me DeleteThis @here.there.com> writes:


> > [...] Compared to WebSphere,
> > I'd stick my neck out and claim that Erlang is far superior
> > in terms of core technology, but WebSphere has the edge
> > in terms of e.g. XML- and SQL-based tool and library support.
> > Whether this makes it a better platform for e-commerce development,
> > I dare not say. It's not necessarily so,
> > but the appearance of superior suitability for the task is
> > overwhelming on the surface.
>
> You might well be right. My only concern with Erlang's
> distributed computing features is just how tweakable they are,
> and how you tweak them. Erickson's examples are telephony
> examples where you can assume operation over an INAP stack.
> What if I want to take Erlang and run it over a network which
> it's not aware of yet? This kind of thing is not an issue in
> lower level languages, but it appears to be a concern for
> Erlang, I would think?

Erlang's distributed computing features currently assume
a closed environment -- that is, the network of "erlang
nodes" must be trusted; an erlang node - once connected to
another node - can literally do anything that can be done
locally from the other erlang VM. In order to run a
network of Erlang nodes across, say, the Internet, one
would need to use SSL or similar.

The distribution protocol is carried on TCP/IP. It _is_
tweakable, and how it is done is even somewhat documented
in a tutorial, but it's fairly advanced stuff
(http://www.erlang.org/doc/r9c/erts-5.3/doc/html/alt_dist.html#3)
The tutorial implements distributed erlang over Unix Domain
Sockets.

Tweaking the OTP INET driver is not something that mere
mortals should attempt to do. Even the OTP experts cringe
at the thought.

Normally, only the control system logic makes use of the
distribution features. In order to serve other traffic,
one opens "ports" to the outside world, using e.g. frameworks
like gen_tcp or gen_udp, or perhaps by writing your own
communication driver.

/Uffe
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes
 >> Stay informed about: intelligence is a search for satisfaction 

<snip>

> Java had the big advantages of being free and running most everywhere,
> plus it looked a lot like C/C++. It has most of the useful features
> of Modula-2 or Ada, and you get to use curly braces and ++. At least,
> those were the reasons I started using it. It's convenient.
> Considering I avoided C like the plague all through the 80s until
> finally forced kicking and screaming to it in 92 or so, "hype" has
> not been my primary driver in choosing languages.

And this is my central point - programmers come to use the tools that
get their jobs done. We all ought to know as much as possible about
other tools so we can know that we're using the best tools for the job,
but it's on the basis of utility that we choose, not what some suit
tells us.
 >> Stay informed about: intelligence is a search for satisfaction