[Prev][Next][Index][Thread]
Some thoughts on using Dylan
Some thoughts on using Dylan
Background:
For the past year, I've been participating in a technical lab project looking
at some B2B and A2A connectivity issues. In the course of the lab, we've
had to create some "software manufacturing" tools - a macro processor and a
product configuration tool. I had the opportunity to choose any language I
thought proper to create any tools needed to support the lab efforts. While
the "end product" was developed in Java, the supporting "manufacturing" tools
were created in Dylan. I would like to share with the Dylan community some
initial impressions on using Dylan in this effort.
My Background:
I've been a software engineer for over 25 years. From a programming language
perspective, I've migrated over my career from the
punch-card/assembler/Fortran era, through PL1/C/Pascal, to
Lisp/CLOS/SmallTalk/Objective-C/C++, arriving now at Java/Dylan. I imagine
this to be very typical of any "grey beard".
Around 1995, I became involved with Dylan when a project I was working on
involved creating a survey of O-O models/techniques. I stumbled upon the
CMU/Gwydion effort and have been using Dylan in one form or another ever
since.
Why Dylan?
Choosing the languages to create the various components of the lab effort was
fairly straight forward. Our B2B connectivity framework would be created in
Java to support the wide range of runtime enviroments we were faced with.
The "tools" software that we would be developing only needed to run on a
lap-top. Dylan was choosen for the tools for the primary (not very
scientific) reason of I wanted to explore the idea that Dylan was more
efficient (less lines of code - straight forward design) in creating tools
like these. Supporting this notion was some tests that I had run (during the
O-O survey) indicating that there was some significant leverage when coding
with Dylan compared to C++.
Dylan vs. Java
Our lab efforts were split between myself and a co-worker. I was the primary
application architect, creating the top-level designs, from which my
co-worker then created the final designs and realized them in Java. I
additionally designed and built the "manufacturing" tools (in Dylan). During
the development cycle, we used some very similar design/architecture elements
in both the application and the tools. This gave me a chance to create
designs that had to be realized in both Java and Dylan.
Here are some of the observations made during this effort:
* the Abstract Factory Pattern
This pattern was used heavily in both the application and the tools. In Java,
this was a very formal pattern involving the creation of special classes to
support any Abstract Factory(s). In Dylan, this could be approached much
more casually. A <string-table> containing the name of the "part" to create
and a function (either an anonomous method or a curried' function) was all
that it took to realize this pattern.
Additionally, patterns like the "Visitor" are implemented in Dylan easily
enough that you really don't think about this as a formal "pattern". They
become more of an "idiom" of the language.
* Functions as 1st Class Objects
Functions as 1st class objects is probably one of the strongest
differentiators for Dylan. In a "dispatch" problem, the Java solution was to
create many classes and polymorphically dispatch one method over any given
class. In the Dylan solution, I had one class with many methods. The
appropriate method was retrieved and "applied" to the object. This approach
felt more natural. Additionally, this approach didn't create a flurry of
class files.
* code complexity
In both Java and Dylan applications, we created a lisp-like execution
environment. This environment gave us a back-plane upon which we could add
any number of functions. If you only counted "lines of code" for each of
these functions, the Dylan and Java versions were very similar. But if you
looked any of the lines of code, the Java lines were much more complicated -
mostly due to multiple casting to clue the compiler into which method from
which class to invoke. Additionally, control structures like "map", "apply",
"reduce", and such allowed a more concise statement to be created.
* different approaches to Threads
Dylan and Java have (what appears to me) a very different approach to the
creation and management of threads. I find the Dylan approach to be very
familiar (locks, spin-locks, semaphores, etc.) and easy to use - could be my
"old school" up-bringing. Java's approach I've found to be elegant, but
sometimes downright frustrating to work with. Sometimes, I just want to
create a function (either curry'd or ananomous) and start a thread on it.
Java requires me to be formal to the point of missing the point of what I'm
trying to do.
* exceptions
Both Java and Dylan have a robust and very handy exception systems. Dylan's
dynamism allows the coder to be more "relaxed" in handling the exceptions.
With Java, you have to declare all possible exceptions. In the Dylan model,
you probably don't know all of the possible exceptions that may be thrown -
no big deal - create handlers for the ones that you're aware of. While this
approach might seem to "loose", in application, I've not had any trouble with
it.
* Dylan's module system
For the most part, newbies can ignore it or use it very casually. But when
you need it (i.e. name collisions), darn it's handy.
* stumbling blocks
- lack of examples
Java wins hands down for having an abundance of examples to draw from. There
have been very few issues that we've been faced with that we were not able to
solve by going across the street to the bookstore (it's way too handy) and
buying a book.
Both Fun-O and individuals (like Chris Double, the Gwydion contributors, and
such) have made some very valuable contributions to the body of Dylan code
available. When I needed to perform some XML-RPC calls from my Dylan
program, Chris's DylanLibs came to the rescue.
This can only be solved with time and acceptance of Dylan. In my mind, this
is not a crippling issue, just a challenging one.
- Dylan's multi-dispatch system
When I first started with Dylan, I had been using SmallTalk and Objective-C
alot. Dylan's seperation of data-structure and dispatch took a little
getting used to. Once I "got it", it now feels much more natural and
expressive. Add a clean approach to multiple inheritance and things get very
powerfull and expressive.
Bottom Line(s)
* The more that I use Dylan, the more I like it - and I like it a LOT !!!
* Functions as 1st class objects - ask for it by name!
* Curry - love it on food, even more as a function (don't forget rcurry -
great for creating factories)
* Dynamism - keeps expressions simple and clean.
Well, that's my rant about Dylan. I'm hoping that this doesn't turn into
flame-bait on Dylan vs. Java - it's just a set of impressions while working
on a project.
Cheers to everyone,
Ron Franke-Polz
ron.franke-polz@psd.invensys.com
----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net
Follow-Ups: