Open Dylan's Call for Help(opendylan.org)
opendylan.org
Open Dylan's Call for Help
http://opendylan.org/news/2014/01/28/call-for-help.html
9 comments
It's a crying shame that Dylan did not become the systems language of Apple's new era — it's really quite lovely. Much nicer than Objective C, though undoubtedly trickier to compile efficiently.
Good thing we already have a compiler that does a pretty good job. :) (But yes, it is a pretty complicated beast in places.)
But at the time, the Apple Dylan IDE was pretty slow and buggy. It is amazing what a few years make much more feasible!
But at the time, the Apple Dylan IDE was pretty slow and buggy. It is amazing what a few years make much more feasible!
Objective-C had the advantage that it worked while Dylan struggled to get an implementation that was acceptable. It would have been interesting if it had made it onto the Newton or got a compiler that could do PowerPC acceptably.
Deterministic realtime attribute was required condition on Apple product, and any GC based language was not acceptable at the time. But sometimes I think they could solve the issue if they could research longer.
A lot of open source projects are quite human resource constrained. I see two solutions to this problem:
- universal citizen revenue, so that programmers who want to work on free software or open source may do it more easily.
- let's reduce the ecosystem diversity. I'd move to drop all those useless fancy languages, and let's all concentrate on Common Lisp, developping tools and libraries, perfecting the implementations, etc.
(No need to argue, I know the former will occur sooner).
- universal citizen revenue, so that programmers who want to work on free software or open source may do it more easily.
- let's reduce the ecosystem diversity. I'd move to drop all those useless fancy languages, and let's all concentrate on Common Lisp, developping tools and libraries, perfecting the implementations, etc.
(No need to argue, I know the former will occur sooner).
In the mid-90s I did some playing round with something called MINDY from Carnegie Mellon. It was (IIRC) a Dylan interpreter (the acronym was 'MINDY Is Not Dylan Yet') and was very interesting both to experiment with Dylan and also to see how MINDY itself was implemented.
As I remember, a cool thing about the Dylan concept was that it had a sliding scale of dynamic-ness - in other words you could start off being quite relaxed about types but, where needed, you could narrow down the types, seal generic methods etc. and the compiler would then be able to optimise better, for example by avoiding dynamic dispatch if it could prove it knew the specific method at compile time.
Mindy was used to bootstrap Gwydion Dylan, a Dylan compiler implementation. This was the main open source Dylan implementation for quite some time until Functional Objects (which obtained the code and rights from Harlequin when they went out of the language business) open sourced their implementation which is now 'Open Dylan'.
Functional Developer (What was Harelequin Dylan) was nice. The editor would syntax highlight the code based on the optimization level. In this way you could look at a method call and see if it was inlined or not and decide whether to seal functions or classes to improve performance.
Another interesting feature was the editor was written in Dylan (using a framework called Deuce). This was emacs-like and had features like virtual sections in a buffer that could each be mapped to a different file on disk. This allowed viewing in a single editor pane the implementations of all methods of a generic function even if they crossed multiple files. This could also be edited as if it was a single file.
Functional Developer (What was Harelequin Dylan) was nice. The editor would syntax highlight the code based on the optimization level. In this way you could look at a method call and see if it was inlined or not and decide whether to seal functions or classes to improve performance.
Another interesting feature was the editor was written in Dylan (using a framework called Deuce). This was emacs-like and had features like virtual sections in a buffer that could each be mapped to a different file on disk. This allowed viewing in a single editor pane the implementations of all methods of a generic function even if they crossed multiple files. This could also be edited as if it was a single file.
Optimisation colouring was one of the Harlequin Dylan features I was most proud of having a hand in back in the day. Did anything like it ever get implemented in a more mainstream IDE?
We only implemented it for static optimisations I think (i.e. you could see at a glance how well the compiler had inferred types, resolved method calls, inlined functions, etc), but we had a lot of ideas at the time around its future application to profiling results, as well as layered, more interactive presentation.
It'd be a great addition to Light Table...
We only implemented it for static optimisations I think (i.e. you could see at a glance how well the compiler had inferred types, resolved method calls, inlined functions, etc), but we had a lot of ideas at the time around its future application to profiling results, as well as layered, more interactive presentation.
It'd be a great addition to Light Table...
I don't know of other IDE's that use the idea. It's a pity as I used this feature a lot when using HD/FD.
Thanks for your great summary. :)
Functional Developer and now Open Dylan also support debugging on Windows, have a REPL (on Windows) and many other features.
With the upcoming LLVM backend, we'll be able to bring those features to other platforms, but we'll need DUIM backends to support the user interface. That's a big part of why this call for help mentions several GUI related things.
With some luck and a lot of hard work, this will be a great year for Dylan.
Functional Developer and now Open Dylan also support debugging on Windows, have a REPL (on Windows) and many other features.
With the upcoming LLVM backend, we'll be able to bring those features to other platforms, but we'll need DUIM backends to support the user interface. That's a big part of why this call for help mentions several GUI related things.
With some luck and a lot of hard work, this will be a great year for Dylan.
ah, Dylan! I remember from far 2005 a team called "Dylan Hackers" who earned both the judges' prize and the second prize at the ICFP Contest (cop & robbers), http://icfpc.plt-scheme.org/.
Here the blog post describing their entry: http://www.hoult.org/bruce/icfp2005/
Here the blog post describing their entry: http://www.hoult.org/bruce/icfp2005/
Indeed, ICFP 2001 was the only time I ever heard of someone using Dylan, and 2005 was the next and last time.
In 2001, the Dlyan Hackers placed #2, but the #1 team had a team member named Dylan (Thurston)
http://developers.slashdot.org/story/01/09/07/0131231/icfp-2...
and IIRC, in that 2005 cops-and-robbers game, the game rules invited complex strategies, but the game wasn't balanced, so degenerate strategies dominated, and the competitiveness was over details of implementation.
In 2001, the Dlyan Hackers placed #2, but the #1 team had a team member named Dylan (Thurston)
http://developers.slashdot.org/story/01/09/07/0131231/icfp-2...
and IIRC, in that 2005 cops-and-robbers game, the game rules invited complex strategies, but the game wasn't balanced, so degenerate strategies dominated, and the competitiveness was over details of implementation.
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.
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 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!
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.
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.
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?":
I think the custom is to use "!" in functions with side-effects.
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
I think the custom is to use "!" in functions with side-effects.
More precisely, "functions that modify their arguments". For example,
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-...)
append(list,value)
append!(list,value)
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.
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.
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
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
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.
Different people like different things, and while I love Ruby, static typing does catch a lot of problems earlier on.
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
[1] https://github.com/wycats/rust-activesupport
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.)
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.
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.
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.
For those interested in using Dylan or helping out, I've found the community very welcoming to beginners and they're eager to help you get started.
Since Dylan people are probably reading this.
- What GC will the LLVM backend use?
- Is there any data an the performance of the MPS?
- What GC will the LLVM backend use?
- Is there any data an the performance of the MPS?
Hi Nick,
I have a branch that will soon allow using either Boehm or MPS on the various backends. That'll probably be the case for the LLVM backend as well.
Part of the reason that I'm doing that is to help gather some performance data on the MPS. (I'm actually doing that Dylan runtime work under contract.)
I have a branch that will soon allow using either Boehm or MPS on the various backends. That'll probably be the case for the LLVM backend as well.
Part of the reason that I'm doing that is to help gather some performance data on the MPS. (I'm actually doing that Dylan runtime work under contract.)
Hi Bruce.
I actually met prom yesterday and he showed me that there are much more information on MPS know. I already read threw most of the documentation and I'm very interested to maybe use it.
I don't yet fully understand the license and what it means, I will probably join IRC in the next days and dig for some more info on MPS.
Great that you get payed to work on this.
I actually met prom yesterday and he showed me that there are much more information on MPS know. I already read threw most of the documentation and I'm very interested to maybe use it.
I don't yet fully understand the license and what it means, I will probably join IRC in the next days and dig for some more info on MPS.
Great that you get payed to work on this.
Developing the language is more interesting then developing tooling I guess. F# has same issues.
Well, none of the things listed in our current call for help are issues with modifying the language. In fact, we spend a lot of time on improving things like the tools, libraries and documentation.
Lately, we've made our test framework integrate well with Jenkins (using Surefire output) and have been getting more and more of our libraries and tests building via Jenkins.
We've also been pulling out some chunks of code and turning them into useful and usable libraries. Our binary data library is an example of this (http://opendylan.org/documentation/binary-data/).
And one of our hackers has spent a large amount of time this week cleaning up and re-working a tool that he had for visualizing the compiler's optimizer. This will let us better perform bugfixes, ensure that the transforms are operating correctly.
We do have areas where we intend to improve the language. There are some extensions to the type system that we're looking at, improving Unicode support, and improving our numerics. But these aren't our main or daily areas of focus.
We want to bring our IDE to non-Windows platforms, we're improving our compiler backends, improving the GC integration, working on editor integration with CodeMirror, vim, emacs, and IntelliJ.
Lately, we've made our test framework integrate well with Jenkins (using Surefire output) and have been getting more and more of our libraries and tests building via Jenkins.
We've also been pulling out some chunks of code and turning them into useful and usable libraries. Our binary data library is an example of this (http://opendylan.org/documentation/binary-data/).
And one of our hackers has spent a large amount of time this week cleaning up and re-working a tool that he had for visualizing the compiler's optimizer. This will let us better perform bugfixes, ensure that the transforms are operating correctly.
We do have areas where we intend to improve the language. There are some extensions to the type system that we're looking at, improving Unicode support, and improving our numerics. But these aren't our main or daily areas of focus.
We want to bring our IDE to non-Windows platforms, we're improving our compiler backends, improving the GC integration, working on editor integration with CodeMirror, vim, emacs, and IntelliJ.
I'm still waiting on a C# REPL since the 2008 demo [1] or Roslyn release beyond CTP, not M# whatever that is.
[1] http://channel9.msdn.com/blogs/pdc2008/tl16 @ 1h1m
[1] http://channel9.msdn.com/blogs/pdc2008/tl16 @ 1h1m
C# REPL like this http://www.mono-project.com/CsharpRepl ?