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.
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.
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)
> 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.
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).
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.)
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.
For me it is very hard to see what Dylan brings to the table. It's nieche is already filled by more popular languages.