[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ARC



At 05:58 PM 11/28/01, Paul Graham wrote:
>Dylan has some good qualities, and I'm sure Arc will end
>up doing many things the same way (ditto for CL and Scheme).
>
>My main gripe with Dylan is the pervasive object-orientedness.
>I would rather have simpler ideas at the core of the language,
>and let people build fancy OO systems as libraries.

I take issue with the notion of treating OO as "fancy".  As soon as
you introduce a "struct" and any sort of overloaded operators -- such
as + or * on numbers -- you are well down the road to OO.

Building OO in from the bottom makes this simpler, not more difficult.
It allows you to reason about all of the "stuff" in your program using
the same mental tools.  It's like achieving closure in arithmetic.  Having
only natural numbers doesn't, in the long run, make things simpler.
You have add the concept of zero, then negatives, than rationals, then
extend that to reals, and then (gasp) imaginaries.  Then, mirabile dictu,
instead of arithmetic getting *harder*, it gets *easier* because you have
achieved closure.  You stop having to make special rules like "you can't
subtract 4 from 3" or "you can't just add a 'color' value to that 'point'
structure".

When you slap OO on as a library, achieving this level of closure is
much more difficult than if you build it in from the start.

I think that a more productive use of your time would be to think about
how to build objects in from the bottom up, but hide the implications of
this so the introductory layers feel very natural, and then figure out how
to scale smoothly into objects.  In my opinion, Dylan comes very close
to achieving this, and better expository writing about it could well be
worth more than any language design you might do.

I would also be interested in hearing:
  - what your definition of OO actually is, and
  - what is so wrong with it that you dismiss it out of hand

>As for syntax, we do plan to have it as an option in Arc,
>but as a way to abbreviate s-expressions, not to appeal
>to the programmers of the world.  (There are enough
>languages designed for them already.)
>
>I agree with you about development enviroments.  My personal
>favorite is vi + load.

OK, now I'll bait you ;-)

I think that we as a professional should be collectively embarrassed that
anybody can make this claim without being stripped of all honors and rank.
And please, everyone, spare me all false analogies to fine home-building
using only hand tools, unless your hand tools consists solely of flint axes
and stone hammers.  (And yeah, there are plenty of fancy-but-awful devel
environments out there, but that doesn't mean they all suck.)

>There will be lots of libraries of course, esp.for things
>useful to Web-based apps.