Dylan Implementations 
Author Message
 Dylan Implementations

Howdy,
        OK - so there's been a fairly interesting, non-trivial
mature discussion going on regarding Lisp implementations, Lisp
vs. C, what Lisp _could_ be vs. current implementations, etc.
        What is actually going on with Dylan?  Are we going to
see: Inexpensive, Commercial implementations for Popular Desktop
operating systems -- Windows,Chicago,Mac,OS/2 ? In other words,
the kind of thing we can "learn at home" and/or "evaluate at
work".  Are there multiple vendors working on the thing, so that
companies don't view the language as "proprietary". Are there
folks out there writing books on Dylan for relatively popular
consumption. Does anyone have a book contract? (e.g., "Tricks
of the Dylan Masters" or "Dylan for Dummies").
        I'm _not_ being "skeptical" or asking "rhetorical
questions". I want to understand more about the "political
economy" of dynamic languages. If the answer is "Yes" to the
above questions, I'd like to here how this is possible with
Dylan even though these possibilities never actualized with
say Scheme or Common Lisp.  If the answer is "No", I'd like
to hear about why not. Why is Dylan (and/or other dynamic
languages) not a good base language definition for the next
Visual Basic or Turbo Pascal or Zortech C++ type of language??
(implementation, that is).

=============================================
Scott McLoughlin
Conscious Computing
=============================================



Sun, 09 Mar 1997 09:41:32 GMT  
 Dylan Implementations
Quote:

>....
>.... Are there
>folks out there writing books on Dylan for relatively popular
>consumption. Does anyone have a book contract? (e.g., "Tricks
>of the Dylan Masters" or "Dylan for Dummies")....

****************************************************************

I have a friend who's writing a book on Dylan.  He's done really good
stuff in the past, so I'm hopeful.  (It's probably not appropriate to
bandy his name about -- that's up to him.)

Hope that helps us keep the faith.

   Bob Futrelle
_______________________________________________________________
Prof. Robert P. Futrelle  |  Biological Knowledge Laboratory
                          |  College of Computer Science  161CN
Office: (617)-373-2076    |  Northeastern University
Fax:    (617)-373-5121    |  360 Huntington Ave.

__________________________|____________________________________

--
Prof. Robert P. Futrelle | Biological Knowledge Lab, College of CS
Office: (617)-373-2076   | Northeastern University, 161CN
Fax:    (617)-373-5121   | 360 Huntington Ave.



Sun, 09 Mar 1997 18:29:28 GMT  
 Dylan Implementations

There are several forms of 'success' that can be discussed.  For instance,
Visual Basic is certainly a success from the stand point of sales.  But
it has not, and probably will not, succeed in terms of being available
across many types of OS platforms.  Scheme and Lisp have 'succeeded' in
the sense that they are taught in many classrooms - but failed in the sense
that there are not hoards of programmers on any platform developing
in these languages.

I suspect most folks think of the language as being a success if it is
being used for many programs.  Unfortunately for me, that means the language
runs on a Windows or Chicago platform first, then perhaps a Mac platform,
and maybe some day runs on a Unix platform where I am working.
--
:s Great net resources sought...

:s <URL:http://www.mps.ohio-state.edu/cgi-bin/hpp?lvirden_sig.html>
The task of an educator should be to irrigate the desert not clear the forest.



Mon, 10 Mar 1997 23:57:41 GMT  
 Dylan Implementations
[Mark Richer]

|   In conclusion, the one thing I hear over and over again when talking to
|   a commercial app developer: "Has anyone shipped a shrink-wrap package
|   I've heard of using this tool?"

thank god there are still innovative thinkers and product developers who
don't fall prey to this, or we would be and will be standing still.
trouble is, the more you look at the PC applications market, the more you
realize that you're going backwards.  things that were normal in 1970 are
only now beginning to make sense to "developers".  when will what was
normal in 1960 begin to make sense?  before the turn of the century?
probably not.  Microsoft is a time machine, folks.

just _use_ dylan, and see what you can do with it.  it _may_ be something
you didn't know you'd missed all these years.  (C++ sure wasn't.)  for me,
it has been fun playing with it, and that has been the start of everything
I've done, including things that didn't succeed at once.

if you don't want to be the first, that's perfectly OK, but don't use the
fact that you are a coward against those who are brave and daring enough to
go forward with something new.  even Microsoft, the producer of the most
mediocre software the world has ever known, sometimes does brave things,
such as Windows.  to paraphrase you: "has anyone shipped a shrink-wrap
package I've heard of for Windows?"  "If you can't answer yes to this
question, then I think success for Windows will be elusive."

Dylan, good luck.  Apple, thanks for still having the guts to be innovative.

#<Erik>
--
Microsoft is not the answer.  Microsoft is the question.  NO is the answer.



Tue, 11 Mar 1997 07:46:10 GMT  
 Dylan Implementations
Yes, there are very different criteria. Success can be defined in terms
of the number of people that use something, the amount of money that is
made, and/or how useful something is. Therefore, something can be
useful and used and therefore, a success in that sense (e.g., PERL),
but not used on a volume platform or by a lot of people. Or something
can be widely used (e.g, Visual Basic) on the {*filter*} platform or
widely used on many platforms (e.g., C/C++). Depending on the kind of
work you do, you would have different criteria. My understanding is
that Dylan was designed to meet the requirements of commercial software
development. There are at least two categories:

shrink-wrap software products
custom apps

Visual Basic has been very successful for supporting custom apps, but
I'm not sure how many shrink-wrap products have been written with it.
And of course it is quite limited. Smalltalk, except for the footprint
required, seems to be able to support both relatively well in terms of
what the language supports, but it seems to require too much resources
for most shrink-wrap products. I would consider Dylan successful for my
purposes if it can be used for commercial shrink-wrap app development.
I don't see how it can be successful in terms of Apple's needs either
unless this goal is met. Otherwise, it's not clear to me why it's
needed, but then again someone else might have a very different
perspective.

In conclusion, the one thing I hear over and over again when talking to
a commercial app developer: "Has anyone shipped a shrink-wrap package
I've heard of using this tool?" MacApp made it over this hurdle with
Photoshop and lots of other products. I think it's important that Dylan
does as well. Will Claris develop a product with Dylan? Will Apple?
Will the Newton development environment be rewritten using Dylan? Will
a hit product be written with Dylan? If you can't answer yes to some
questions of this sort, then I think success for Dylan will be elusive.

-------------------------------------------------------------
Mark Richer         Island Graphics, San Rafael, CA, USA



Tue, 11 Mar 1997 03:35:55 GMT  
 Dylan Implementations

Quote:

> Dylan, good luck.  Apple, thanks for still having the guts to be innovative.

> #<Erik>
> --
> Microsoft is not the answer.  Microsoft is the question.  NO is the answer.

Howdy,
        Yes. Innovation is a GOOD THING. I read somewhere that we are
now simply in an age of "conservatism" with regard to software
technology and that this is cyclical -- sounded about accurate to
me.
        OTOH - some of us look at the tree of LISP derived languages
and we see that the root there is dated around 1955 and we begin
to wonder "Hey, what's going on here? Why haven't _any_ of the
leaves of this tree seen widespread commercial use." My origianl
posting asked _both_ a practical and theoretical question. The
theoretical question regards the intersection of this tree of
tools (or lack of intersection) and the history of commercially
successful (better term than "popular"?) development tools.
        I don't want to risk misquote, but over in comp.lang.lisp
Thomas Breuel made a comment to the effect that once we have
extra space/cpu resources, we often just want to solve even
bigger problems -- so the "extra overhead" traditionally
associated with LISP like languages on stock hardware might
_always_ be a problem.
        There are (as usual) two responses: (1) There are other
classes of apps being built where this problem doesn't apply -
say the oodles of small to medium financial models and other
custom apps now built using Pascal, C, Basic, etc. (2) Implementations
might theoretically eliminate much of this overhead "as the science
matures."
        I was asking more about the (1) possibility rather than
the (2) possibility, or at least limiting (2) to what is now
feasible rather than just "possible".
        Anyway - YES, grow the tree. It's just nice to eat fruit
sometimes as well.

=============================================
Scott McLoughlin
Conscious Computing
=============================================



Tue, 11 Mar 1997 11:37:08 GMT  
 Dylan Implementations


Quote:
> [Mark Richer]

> |   In conclusion, the one thing I hear over and over again when talking to
> |   a commercial app developer: "Has anyone shipped a shrink-wrap package
> |   I've heard of using this tool?"

> thank god there are still innovative thinkers and product developers who
> don't fall prey to this, or we would be and will be standing still.
> trouble is, the more you look at the PC applications market, the more you
> realize that you're going backwards.  things that were normal in 1970 are
> only now beginning to make sense to "developers".  when will what was
> normal in 1960 begin to make sense?  before the turn of the century?

   There's a lot that could be said about the reinvention of older, big
machine, technology in the personal computer arena.  Sadly, these
reinventions are often better known by their mistakes -- IBM wrestled with
their mistake of using the 'spare' 8 bits their 32-bit/24-bit addressing
scheme in the S/360 series for years, their mistake realised BEFORE Apple
followed the same path with the same chaotic, though finally sucessful,
result -- virtual memory technology has been around for over 30 years
(even before IBM claimed to have invented it) but small computer
implementations didn't take advantage of what was learned and started the
same evolutionary progress to getting it right all the way from scratch.

   What's this got to do with Dylan?  At least a couple of things - one is
that language design and implementation can be pretty machine indenpendent
and we've tended to not reinvent the big machine wheel on small machines.
At least in the Mac environment we've seen some very innovative language
work, both pushing the limits of known languages (MetroWerks efforts with
C and Pascal for example) and in the invention of new (Prograph, for
example).  Dylan, even if it only pushed the state of the art and was
never adopted, would be a worthwhile contribution.

   Secondly, ten years ago I was lucky enough to be involved in mainframe
systems programing when a new language became available -- Plus is its
name, you'll never have heard of it probably.  Derived, in part, from
BCPL, Sue and others it was a 'perfect' combination of clear syntax,
strict typing and all the language stuff you could want, along with a very
capable compiler with decent optimization, optional source reformatting to
a 'pretty' form etc etc ... At the time, we used mainly 370 Assembler for
production code and fortran, SNOBOL etc for those grungy little program
utilities we all need.  I moved to Plus for both the 'glp' work and my
production system code and after a nominal learning curve my productivity
rose by an order of magnitude (the expected improvement in stepping from
assembly to a high level language was mitigated to some extent by the use
of a collection of assembly macros and coding conventions that provided a
lot of high level benefit in the assembly world).

   When I moved to Mac programming was my first exposure to C.  Again,
there was the usual learning curve, longer this time, but, worse, my
productivity dropped.  Language wars are futile and I don't play those
games -- all I can say is I personally found (and still find) C (and C++)
hard to program in.  In the light of this I started to port the Plus
compiler to an MPW tool, but the writing was on the wall and I would never
have the resources to maintain it so I stopped.

   I have high hopes that Dylan will replace Plus as my language of
choice.  It has the clear language syntax and highly favorable development
environment to do it.  If I can get back even a quarter of my time (and
the Dylan guys claim I'll do a lot better than that), it'll be a winner
for me.

   I've read the book and the Interim; I've played with Marlais -- I'm ready!!



Tue, 11 Mar 1997 21:07:29 GMT  
 Dylan Implementations

Quote:

>         Yes. Innovation is a GOOD THING. I read somewhere that we are
> now simply in an age of "conservatism" with regard to software
> technology and that this is cyclical -- sounded about accurate to
> me.
>         OTOH - some of us look at the tree of LISP derived languages
> and we see that the root there is dated around 1955 and we begin
> to wonder "Hey, what's going on here? Why haven't _any_ of the
> leaves of this tree seen widespread commercial use."

They have.  AutoCAD, InterLeaf, EMACS, and others...


Tue, 11 Mar 1997 22:00:36 GMT  
 Dylan Implementations

Quote:



> [...]
> > I think the reason that Scheme & Common Lisp never became popular w/
> > companies is that they were difficult to interface w/ C and Pascal.

> Scheme and I'm pretty sure CL aren't at all difficult to interface to
> C and Pascal....

You are correct.  Symbolics had nice, fairly easy-to-use interfaces between
Lisp and Fortran, Pascal and C.  I personally used the Fortran and Pascal
ones, and had good experiences with them.  You're also right that there
is no "standard" way to do it, but is there in any language?

Lucid (and probably other Lisp vendors) also provided C and Pascal FFIs.



Wed, 12 Mar 1997 03:08:32 GMT  
 Dylan Implementations


[...]

Quote:
> I think the reason that Scheme & Common Lisp never became popular w/
> companies is that they were difficult to interface w/ C and Pascal.

Scheme and I'm pretty sure CL aren't at all difficult to interface to
C and Pascal.  Chez Scheme supports dynamically linking in "C" style
foreign procedurs and we use it to dynamically create and manipulate
C++ class instances directly.  In Elk Scheme you can add your own
atomic Scheme types by writing in C.  (`Elk' stands for Extension
Language Kit, and it is not at all difficult to use.)  MacScheme
provides everything you need to convert between Pascal data structures
and its own.  It even provides you with a ready-made interface to the
Macintosh toolbox.  And these are only the Schemes that I've had
direct experience with.  There are many more.

The only complaint one could make about interfacing Scheme to C or
Pascal is that there is no *standard* way to do it.

The reason Scheme and Common Lisp aren't more popular in the business
community is that they have a mostly undeserved reputation for being
slow, academic, and inappropriate for real-world problem solving.

For us, the only advantage that Dylan may have over Scheme is the
potential ability to compile more efficiently.  So I am still rooting
for its success.

thant



Wed, 12 Mar 1997 01:22:18 GMT  
 Dylan Implementations

Quote:
>Symbolics had nice, fairly easy-to-use interfaces between
>Lisp and Fortran, Pascal and C.

Hey, the coolest thing about interfacing to these languages on a Symbolics
system is that Fortran, Pascal, and C are essentially implemented in Lisp
rather than the other way around!

The best C development system ever, IMHO, was called Zeta-C (?) and ran on
(at least) TI Explorers. It puts Saber to shame! (I can't remember what Saber
is called now: CodeCenter?)

There is an article in a recent Dr. Dobbs magazine about a C interpreter
developed in some Lisp, for anyone interested.


Intel ProShare Teleconferencing
(503) 696-9309 FAX: (503) 696-4210



Wed, 12 Mar 1997 00:13:18 GMT  
 Dylan Implementations

Quote:

> >         Yes. Innovation is a GOOD THING. I read somewhere that we are
> > now simply in an age of "conservatism" with regard to software
> > technology and that this is cyclical -- sounded about accurate to
> > me.
> >         OTOH - some of us look at the tree of LISP derived languages
> > and we see that the root there is dated around 1955 and we begin
> > to wonder "Hey, what's going on here? Why haven't _any_ of the
> > leaves of this tree seen widespread commercial use."

> They have.  AutoCAD, InterLeaf, EMACS, and others...

Howdy,
        Good examples -- all embedded Lisps. That's why Conscious
Computing is developing a Windows .DLL Common Lisp subset bytecode
compiler/runtime environment.  One of our internal mottos is
"Render unto Lisp what Lisp is due. Render unto C what C is due".
C calls Lisp and Lisp calls C (via linking .DLL's). Hacking
Windows single data segment .DLL's for safe reentrancy is _NO_
_FUN_ -- but that's what people are buying. It works real well
and we're making it better.  Stay tuned....

=============================================
Scott McLoughlin
Conscious Computing
=============================================



Wed, 12 Mar 1997 07:28:35 GMT  
 Dylan Implementations


Quote:
> I think the reason that Scheme & Common Lisp never became popular w/
> companies is that they were difficult to interface w/ C and Pascal. Also,

That's an implementation problem, not a language problem. I don't know
of any language for Windows, for example, that has a problem interfacing
with C and Pascal Code. That could because of the dynamic linking, which
means that the C code doesn't need to be in the same binary as the high
level language that calls it.

Martin Rodgers
--
Future generations are relying on us
It's a world we've made - Incubus      
We're living on a knife edge, looking for the ground -- Hawkwind



Tue, 11 Mar 1997 17:47:53 GMT  
 
 [ 35 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Dylan implementation question

2. another Dylan implementation?

3. Free Dylan implementations?

4. Dylan implementation tips

5. Status of Dylan implementations

6. Status of Dylan implementations

7. Which public domain Dylan implementation ?

8. Dylan Implementations

9. Where is dylan implementation?

10. Dylan-implementation in CL?

11. Implementations of Dylan

12. Implementation of Dylan on PC?

 

 
Powered by phpBB® Forum Software