Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!fnnews.fnal.gov!gw1.att.com!gw2.att.com!nntpa!ssbunews!ssbunews.ih.att.com!hyatt
From: hyatt@fred.flw.att.com (Wayne Hyatt)
Subject: Re: Yes, but how much will it cost?
In-Reply-To: sfeldman@red.seas.upenn.edu's message of 5 Apr 1995 18:42:22 GMT
Message-ID: <HYATT.95Apr6175611@fred.flw.att.com>
Sender: news@ssbunews.ih.att.com (Netnews Administration)
Nntp-Posting-Host: fred.flw.att.com
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
References: <gwynne-2403951245370001@tchm04a14.rmt.utk.edu>
	<DAVIS.95Mar31190729@passy.ilog.fr>
	<patrick_d_logan.234.000D62D3@ccm.jf.intel.com>
	<DAVIS.95Apr3101918@passy.ilog.fr> <3lsr46$qr9@News1.mcs.com>
	<Pine.A32.3.91.950405102238.17021H-100000@swim5.eng.sematech.org>
	<3luoae$r8g@netnews.upenn.edu>
Date: Thu, 6 Apr 1995 22:56:11 GMT
Lines: 149

In article <3luoae$r8g@netnews.upenn.edu> nagelc1@sb.com (Chris) writes:

   As I asked in another post, what can you do with Dylan that you *cannot*
   do in C++, ObjectPascal (which seems to be trying to make a comeback
   in Delphi), or Objective-C or (smalltalk?)??

Due to the fact that I haven't come across any articles that touch on
what I consider to be a significant advantage of dynamic languages
such as Dylan, I'll try to provide an example that illustrates this
advantage and see what I can learn from the responses ....

With a language that is dynamic and introspective (e.g. it can
determine at run time an object's type and the names, types, and
values of that object's slots), one can fairly easily develop a
reusable, extensible "platform" which would be prohibitively
expensive to implement with a language which only offers compile-time
(i.e. static) typing.

In short, this is because in a dynamic language the platform can be
written without compile-time knowledge of application-defined data or
behavior.  All information that the platform needs can be obtained at
run time.  With a static language, a platform cannot (by definition)
know about application-defined data or behavior.  (I recognize that
this limitation is not strict or universal, but I think it holds true
as a generalization and exceptions are often based on the dynamic
aspects of a language.)

When a dynamic language also allows one to provide new defining forms
(e.g. with macros), much of the knowledge a platform needs in order to
deal with application-defined data or behavior can be generated at
compile-time.  An important motivation for this might be to allow for
much greater efficiency.  (I would note, though, that this seems to be
as much a function of syntactic complexity and its effect on macro
processing as it is a function of dynamic vs. static languages.)

The example outlined below puts this into more concrete terms and is
based my experience developing platform software over the last eight
years or so.  After years of developing platform software in Common
Lisp, I have been working on developing platform software in C++ for
the last several months and I believe the example below illustrates
the difference between what is possible (in a practical sense) with an
essentially static language like C++ on the one hand and a dynamic
language like Common Lisp or Dylan on the other.

Based on the little information I've gathered on Dylan, I am confident
that Dylan provides enough of the necessary facilities available in
Common Lisp to allow one to accomplish roughly the same degree of
reusability and extensibility.  On the other hand, I'm no expert in
C++ (although my C++ experience does pre-date my recent assignment)
and I welcome comments on how any static language can be used to
accomplish the same things that can be done in Common Lisp.  However,
I don't think my limited experience with C++ leads me to misunderstand
the practical limitations that arise from its essentially static
nature.

As for the other languages mentioned, I'm not in a position to
evaluate how they would compare, except to say that I've not heard of
any facilities in Smalltalk that allow the level of introspection or
extensibility that Dylan or Common Lisp do.  I invite those of you
more familiar with Smalltalk to outline ways to accomplish similar
things in Smalltalk.

---------------------------------------------------------------------

The best example I can think of to illustrate the power of dynamic,
introspective, extensible languages is a platform designed to capture
the essence of a homogeneous class of applications.  One could think
of such a platform as an independently executable and verifiable
"engine" to which individual applications need only add data
definitions and application-specific behavior.

In the interest of brevity, I will outline how one could implement one
"slice" of such a platform using a language like Common Lisp or Dylan.
(When I say "could," I am thinking of straight-forward applications of
proven, working techniques, not hypothetical implementations or
speculations.)

In many applications, application-specific data needs to be audited in
application-specific ways.  One could use Common Lisp in a very
"natural" way to develop a platform that:

  1) provides defining forms that simultaneously define the application's
     data and the specifics of how that data will be audited - e.g. for
     the default case verifying that the run-time data value satisfies
     the declared type or invoking an application-supplied function
     that will verify the run-time data value in a more sophisticated
     way.

  2) an audit "engine" that schedules, runs, and reports on audits
     according to a framework of manually vs. automatically scheduled audits,
     low- vs. high-priority audits, critical vs. non-critical audits,
     stand-alone audits vs audits involving multiple objects, etc - all
     without knowing the specifics of how an application's data is to be
     audited.

  3) mechanisms to allow individual applications to tailor the behavior
     of the audit "engine" to suit particular application needs where
     these needs require something different than the default behavior
     provided by the platform - e.g. introducing a new, application-
     specific kind of audit into the audit framework outlined in (2)
     above.

  4) automatic mechanisms to a) display GUI forms to the end user of the
     application to allow the end user correct faulty data, and b)
     verify the corrected data before applying the changes.

With such a platform in place, the development of any particular
application requires only the definition of its data and the
implementation of its unique behavior.  Virtually no development
effort is required to produce a polished, product-quality framework
for auditing or otherwise administering the application data.

While I don't pretend to know how such a platform could best be
implemented using C++ (with which I'm familiar) or any other
statically typed language you mention, I'm confident that the effort
required to produce and maintain such a platform with a statically
typed language would be far greater than producing and maintaining it
with Common Lisp or Dylan.  I'm sure it could be done in any language,
but I would claim that it would take a lot more work and probably take
more language expertise to make it fit "naturally" with the language
when compared to Common Lisp or Dylan.

Furthermore, any attempts to implement such a platform in a static
language would inevitably lead to dealing with the same problems and
issues that have already been solved in a general way by the
implementors of Common Lisp and Dylan, but in a proprietary and less
general way.  I'm thinking specifically of things like the increased
burden of memory management that is incurred by such a dynamic
platform and the necessary capabilities for introspection.

I would note that the particular problem domain of auditing
application-specific data does not represent a significant portion of
software development effort in any one project, but I believe it does
serve as an example of how Common Lisp and Dylan can be used well to
accomplish easily something that would be considered a practical
impossibility by many programmers familiar with the other languages
you mention (except perhaps Smalltalk).

The important question would be how often your business is in a
position to gain economic leverage from such a "platform" approach by
applying it to other "slices" beyond auditing data and covering all
the generic, administrative aspects of installing, maintaining, and
running a class of applications.  I believe that when you consider
that this approach is well suited to supporting customized
applications for individual customers, the answer is "more often than
many software architects think."

Wayne Hyatt
(Speaking for myself only)
