Chris Double on 12 Jan 2000

The things I like most about Dylan would probably be:

I do miss the listener style  approach you get in Lisp, where you see the results of what you do straight away - similar type of functionality in Smalltalk too. HD 1.2 provides this from the IDE though and HD 2.0 beta makes it even easier so it's not such a loss.

Overall it is a language that seems to suit the style of programming that I do. The use of multiple dispatch simplifies many designs I've had to do and the macro faciltiy helps to simplify things even further. The ability to pass methods, functions, and classes around as first class objects also has made things easier for the types of things I do.

Many of the above things can be done in other languages in a varity of different ways. But for me Dylan has provided a good trade off between ease of use, powerfull language features, and easy application delivery.

I've used HD 1.2 professional for most of my recent personal programming projects, one commercial program and a couple of small freeware programs available for download from the internet.

That's my reasons for using Dylan. I'm sure an enthusiast of any language could come up with similar reasons though. Pick a language and I hope you have fun using it.

Chris.

--

Chris
Double

Dylan has provided a good trade off between ease of use, powerfull language features, and easy application delivery.

I quote from the description of <stretchy-vector> in the DRM:

"Because <stretchy-vector> is abstract and instantiable but has no specified subclasses, every implementation must provide one or more concrete subclass to instantiate. These concrete subclasses have no specified names, and their names are not exported by the Dylan module."

A similar paragraph occurs in several other places in the section on the built-in collection classes. Saying it's legal to call make on a particular abstract class but leaving undefined what you get when you call make seems kind of weird. One way of dealing with this is to have the standard library define suitable classes for these operations. I was hoping that's part of what's going on if someone's working on a standard library.

Andrew Shalit

This design is intentional. There's no reason for programmers to know how any particular implementation implements stretchy vectors.

Okay, okay, it feels like about thirty-seven people have all told me that there's no reason why I should know what I'm really getting back when I make a <stretchy-vector>. You're right! Uncle, already!

Remember again that I'm a C++ programmer who's never written a line of code in a dynamic language. My confusion here stemmed from the fact that you can't instantiate an abstract class in C++. I know you can do that in Dylan, but because of my background, I'm conditioned to wanting to know what I'm getting. It'd make a difference in C++.

    Chris Double

I like the way in the HD versions of Dylan that all libraries are packaged as DLL's. For me it has encouraged reuse of common libraries.

The HD c-ffi is good - it is easy to access Windows API and other external API's. I would like to be able to use this in the listener though but that is currently not possible unfortunately. I've never had an external API I couldn't call via Dylan yet.

I was a bit dubious that people would download the HD runtime, given its size, just to run a small freeware thing but I was surprised that this proved not to be an obstacle. And once I wrote a few more add on programs there was no need for users to download the large file again. I guess the HD runtime isn't that much bigger than all the MFC DLL's or the VB runtime stuff. Over the last two months there were about 2,000 downloads of the HD runtime and associated utilities from my web site so it seems that end users didn't mind running Dylan stuff.