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

Responses to Bravo DYLAN



Fellas,

It was interesting to see all the responses I got to my last message.
But, the comments were not very diverse.  I fear there aren't enough
C++ folks in the audience.  I didn't even get called on my "one and
tied behind their backs" crack (which I expected).

I'm not happy with yet another obscure research dialect.  It is not
too much of a generalization to say that only research hackers even
consider using ML.  There are lots of interesting new software
technology research type languages coming out of DARPA (see DARPA
Software Technology Conference '92) but these aren't REAL options.  

Languages require lots of people, time, and money to be an alternative
to Common Lisp, ADA, Smalltalk, let alone C++.  C++ has a special
place because it proliferated like the gold rush.  The reason it did
was because there were people with money willing to support good
developers to build great compilers and improved support features like
development environments and OODBs (best example: Lucid/SUN/Object
Design).

My greatest elation about DYLAN was that it was being done by Apple.
With these guys teamed with IBM, they may have the clout to get DYLAN
accepted by the C++ advocates who lord over software popular opinion
(ie. those who came from C and mainstream comercial programming).  If
they can get OODL to be considered as valuable to those guys as OOP --
then we can get somewhere in convincing management.  

I expect Lisp people to take to DYLAN like fish to water.  I hope that
eventually the C++ advocates will see that their syntax is overly
complex.  If they can be convinced that building abstractions with
macros is useful and necessary then maybe they will understand the
need to go with the uniformly simpler paren-based style.  In the mean
time, I hope Apple doesn't cripple the language by becoming C syntax
oriented just to appease the unknowing.

Now to respond directly to some questions/comments:

----------------------------------------------------------------------
Sorry, Charlie, as of September, TI Hillcreast is no more.  I know
because I had worked there for the last four years.  Yes it is true
that our group has more Macs than most.  But don't be misled.  Macs
are mostly used by managers and secretaries.  Engineers have either
Apollos or Suns.  In fact, the latest corporate mandate is that we
will not by any more Macs.  Instead we will purchase PCs for the
managers (the equivalent hardware issue again).

It is my strongest hope that the new Apple/IBM RISCs will compete with
SUNs speed so I can get one.

------------------------------------------------------------------
To everyone. Thank you, yes I know about THOMAS.  I have it.  But I
have been burned before by using prototype software.  I think the
three week effort they made is useful and promising.  However, I am
not going to get into a deadline jam because I have an unsupported
language bug.  I will continue to experiment with THOMAS.  It is a
great way to grow knowledge of the language -- which is what it was
intended for.

------------------------------------------------------------------
Dak.  Scheme contains obsolete forms which are maintained for backward
compatability.  Also, Scheme implementations contain Flavor-type
object systems.  Flavors is an obsolete (thank goodness)
object-oriented methodology.

------------------------------------------------------------------
Several people asked about SmallTalk.  It is true that TI has had some
interest in this language of late.  However, convincing management to
use it was painful.  Doug Johnson wrote and interesting report
comparing SmallTalk to Lisp to C++ and finally won the war.  The
report entitiled "On Holy Wars and a Plea for Peace: MMST Lanugage
Selection."  The bottom line was that the project would require ten
times the developers ten times as long to complete the work.

For myself, I have used SmallTalk.  I find it great that they are so
primally object-oriented.  However, they don't support the building of
language abstractions (like macros).  This results in a lot of typing
and less readability. Both of which equate directly to code
maintainability.  Plus, sometimes their brand of OOP doesn't suit the
problem.  I prefer a more flexable methodology. SELF looks
interesting, but I have never tried it.

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


I hope I get mail from C++ folks this time.



Rob Farrow
Integrated Systems Laboratory
Texas Instruments
P.O. Box 655474, MS 446
Dallas, TX  75265

EMAIL: farrow@hc.ti.com
FACS: (214) 995-6194