Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!ix.netcom.com!netcom.com!ddyer
From: ddyer@netcom.com (Dave Dyer)
Subject: Making Dylan Competitive
Message-ID: <ddyerD4xJw6.9L5@netcom.com>
Reply-To: ddyer@netcom.com
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
Date: Sat, 4 Mar 1995 19:09:42 GMT
Lines: 44
Sender: ddyer@netcom8.netcom.com

This thought isn't completely baked yet, but it's more than half baked.

If Dylan is going to find acceptance in the marketplace, it's going to
have to have more going for it than esoteric programmer-level
arguments that it's a better language, a better development
environment, and so on.  Unfortunately, the part of the total Dylan
effort that is publicly known is almost entirely of that kind.

One strong possibility is that Apple will push really hard, using
Macintosh development environments as a lever.  It is likely that
future Apple operating systems will use Dylan internally, and will
make Dylan a really attractive choice for developing macintosh
software by providing tight and elegant integration.  This is a great
idea, except that Macintosh is 10% or less of the market; the universe
at large is much more likely to influence Apple than the other way
around.  Remember Dylan's lisp syntax?

One way to make Dylan attractive is to cast it as *the* premier cross-platform
development language.  Everybody who develops applications fantasizes about
running the same code on many platforms.  Core algorithms, expressed in C,
are pretty portable (A big improvement from the bad-old days when everything
was written in assembler!) but the big problem, the big money sink, is 
maintaining cross platform GUIs.

Dylan provides the technology to solve the cross-platform problem, if the various
dylan development efforts focus on it.  I hope they do, but the costs of doing
so are up-front, while the benefits are downstream.

There should be a well supported

	Dylan Database
	Dylan File System Interface
	Dylan Windowing Environment

There should *NOT* *NOT* *NOT* be:

	Dylan X window interface
	Dylan Macintosh Operating System Interface
	Dylan Interface to DOS filesystem.

It isn't adequate to implement custom interfaces (say, to X windows)
and assert that it will be "easy" or even "possible" to use the power
of Dylan's object orientation to add bindings to make those "other"
windowing environments look like X windows.
