Hacker News Reader

Comment by bjourne | Hacker News Reader

When reading about Dylan, it seems one of it's main selling points is "everything is an object." But nowadays, that's true in many other dynamic languages like Python, Ruby and Clojure. Macros are everywhere and you can even add them to Python if you want to using third party modules. Though I've never felt the need because Python's syntax is excellent as it is.

For me it is very hard to see what Dylan brings to the table. It's nieche is already filled by more popular languages.

View on HN

A Common Lisp-style condition system is a pretty key thing for me.

It is highly readable. And you can use '!' and '?' in names!

An optimized implementation of multimethods is always nice.

The ability to apply optional static typing is great for putting stuff into production and feeling good about it.

Having multiple return values, keyword arguments and rest arguments is nice (and yes, Python can do much of that).

>It is highly readable. And you can use '!' and '?' in names!

Somehow this feels a little contradictory.

Why do you feel it is contradictory? I think having method names end with "?" whenever they return a boolean value is quite intuitive. They seem to stand out more than having such method names start with "is" or "has". YMMV.

Looking back at some Dylan code again now, I still find its richer, Lisp-derived, hyphenated naming approach more readable-and-expressive than either camelCase or underscore_separated identifiers.

When Dylan switched from Lisp syntax this was something that was fretted over an awful lot, for obvious reasons, but we went with it and it worked fine.

I'd love to see some other algebraic (non Lisp) syntax language get more creative in this direction again one day.

It isn't.

Common Lisp and Scheme can do this as well and I like the look of predicate functions like "list?" or "number?":

    (list? object)
    (number? 1) => returns true
    (number? "abc") => returns false

It isn't really necessary for a language to support this, but it is a nice detail if one preferred such a style.

I think the custom is to use "!" in functions with side-effects.

More precisely, "functions that modify their arguments". For example,

  append(list,value)

returns a new list;

  append!(list,value)

modifies at least one of its arguments, typically, its first argument, but it could be another or multiple ones.

By the way, all of these are conventions. The language doesn't require you to use the punctuation (http://opendylan.org/documentation/intro-dylan/expressions-v...). The conventions grow on you soon, though (I never really wrote anything in lisp or dylan, but still would like to see more flexibility in allowed characters in names)

Functions that have side effects on non-arguments should be very rare, and don't use a naming convention (see for example http://opendylan.org/documentation/library-reference/common-...)

> A Common Lisp-style condition system is a pretty key thing for me.

What does that mean? I absolutely agree with you about using ! and ? (and other special characters too!) in symbol names. That's something I'd like to see more languages adopt.

>> A Common Lisp-style condition system is a pretty key thing for me. >What does that mean?

BruceM is referring to how Common Lisp deals with exceptions - http://www.gigamonkeys.com/book/beyond-exception-handling-co...

I've seen (experimental) Perl & Ruby modules which provide versions of this but having it baked into your language is very nifty indeed.

Perl 6 has baked in some stuff @Larry may have stolen from CL that is intended to enable unified succinct expression of desired sync or async handling in response to errors and callstack events (including exceptions).

Having something like CL Condition System in Perl6 would be very nice!

I've only seen the try/CATCH stuff. Are there any examples of restart/resume/continue handlers ala CL?

BTW: Here's the Perl5 Condition System module I was thinking of (though there maybe others) - https://metacpan.org/pod/ConditionSystem

    CONTROL { print 1; $_.resume }; print 2; warn; print 3 # 213

That's obviously a contrived example but I think it shows the basics.

Some related excerpts from spec doc S04 (blocks and statements):

Warnings are produced in Perl 6 by throwing a resumable control exception to the outermost scope, which by default prints the warning and resumes the exception by extracting a resume continuation from the exception, which must be supplied by the warn() function (or equivalent).

...

Since warnings are processed using the standard control exception mechanism, they may be intercepted and either suppressed or fatalized anywhere within the dynamic scope by supplying a suitable CONTROL block.

...

As with calls to return, the warning control exception is an abstraction that the compiler is free to optimize away (along with the associated continuation) when the compiler or runtime can determine that the semantics would be preserved by merely printing out the error and going on.

...

One additional level of control is the notion of lazy warnings. ... Numeric and string conversions use these lazy warnings to allow (but not require) failsoft semantics.

I understand where your coming from. For me, the selling point of Dylan is that it gives me many of the things I like from dynamic languages, like Ruby, but also gives me static typing (and type inference), relatively high performance and a compiler that catches a lot of problems before I run my code.

Different people like different things, and while I love Ruby, static typing does catch a lot of problems earlier on.

But what does it bring to the table compared to other typed languages with dynamic features (or the other way around, e.g. TypedClojure, TypeScript...) and bigger ecosystems?

I'm not familiar with TypedClojure or TypeScript, so I feel unqualified to answer your question. I'll attempt to answer anyway, because this is the Internet.

At first glance they seem like subsets/dialects of other languages, which would reduce the benefits they get from their "parent" ecosystem? Similar to JRuby and Java, where I always felt a reluctance to interact with the Java side.

That said, Dylan has a pretty neat FFI, and it's simple to wrap C libraries into Dylan-looking interfaces, so at least for me it benefits a lot from the plethora of C libraries out there.

(I realize FFI is available to almost all languages, and doesn't really mean libraries are available to Dylan, but I find it very comfortable to bridge C and Dylan through its FFI.)

Have you seen rust-activesupport? [1] It provides ActiveSupport-ey things like 2.days().from_now() in Rust, which has a very nice type system.

[1] https://github.com/wycats/rust-activesupport

Apple designed it as a replacement for languages like C++, now Objective-C, Java, C#. Stuff like Apple Keynote, Apple Pages, Apple's Xcode, Apple Mail, Contacts, Calendar, and the Apps on mobile devices like the iPhone and iPad would have been written in Dylan. Applications which Apple now writes in Objective-C. Apple already had an Operating System for an ARM-based computer written in an early version of Dylan (with some help of a C++ based kernel). It also tried to develop some Mac-based prototype applications: an interface builder and I think there was a 'Finder' written in Dylan.

Clojure, like Java, has primitives. And I don't understand why you'd include it anyway, as functions are the primary form of abstraction in Clojure.

> For me it is very hard to see what Dylan brings to the table. It's nieche is already filled by more popular languages.

A dynamic language with native code compiler and language features suitable for both application and systems programming.

Plus being a Lisp like language with a more friendly syntax for those scared of parenthesis.

We should get you to help us with the text on our website. :)

Thanks! Feel free to use the comment. :)

Reply on news.ycombinator.com