In Dylan, all values (including numbers, characters, functions, and classes) are first-class objects.

Dylan's main design goal is to be a dynamic language well-suited for developing commercial software.

Two other groups contributed to the design of the language and developed implementations: Harlequin released a commercial IDE for Microsoft Windows and Carnegie Mellon University released an open source compiler for Unix systems called Gwydion Dylan.

Dylan's lexical syntax allows the use of a naming convention where hyphen (minus) signs are used to connect the parts of multiple-word identifiers (sometimes called "lisp-case" or "kebab case").

The slots must be initialized manually: By convention, constant names begin with "$": A factorial function: Here, n!

Often the complete definition for a class does not exist in a single module, but is spread across several that are optionally collected together.

As soon as this occurs, the String class becomes larger, and functions that don't need to use regex still must "pay" for it in increased library size.

Instead of myString.parseWith(myPattern), which would be the natural organization from an OO viewpoint, something like myPattern.parseString(myString) is used, which effectively reverses the ordering.

This is more commonly used in math libraries, where functions tend to be applicable to widely differing object types.

A more practical use of the interface construct is to build public and private versions of a module, something that other languages include as a bolt on feature that invariably causes problems and adds syntax.

Under Java or C++ the visibility of an object is defined in the code, meaning that to support a similar change, a programmer would be forced to rewrite the definitions fully, and could not have two versions at the same time.

Default getter and setter methods are automatically generated based on the slot names.

The optional init-keyword syntax allows the programmer to specify the initial value of the slot when instantiating an object of the class.

In this case the definition above has no explicit instructions, so in both languages access to the slots and methods is considered protected, meaning they can be used only by subclasses.

In Dylan, these sorts of visibility rules are not considered part of the code, but of the module/interface system.

For instance, one interface used during early development could declare everything public, whereas one used in testing and deployment could limit this.

The method need not be known at compile time, the understanding being that the required function may be available, or not, based on a user's preferences.

To use that functionality the programmer is forced to import that class and refer to it explicitly to call the method.

However code may also be located in generic functions, meaning they are not attached to a specific class, and can be called natively by anyone.

For instance, one common function in most languages is the to-string, which returns some human-readable form for the object.

In Dylan these methods could all be collected into a single module called "to-string", thereby removing this code from the definition of the class itself.

When the spell-check module is compiled into your program, all strings (and other objects) will get the added functionality.