7 ms·
Open Dylan's Call for Help
- gghh 13y agoah, 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/ http://icfpc.plt-scheme.org/. Here the blog post describing their entry: http://www.hoult.org/bruce/icfp2005/ http://www.hoult.org/bruce/icfp2005/
- yetfeo 13y agoDylan did well in multiple ICFP contests IIRC.
- thomasz 13y agoThe team is infinitely more important than the language, and the Dylan Hackers team was top notch.
- gohrt 13y agoIndeed, 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-2001-contest-results 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.
- gcv 13y agoIt'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.
- BruceM 13y agoGood 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!
- gress 13y agoIt seems as though Objective-C is slowly morphing into something more Dylan-like over time.
- protomyth 13y agoObjective-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.
- eonil 13y agoDeterministic 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.
- bjourne 13y agoWhen 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.
- sspiff 13y agoI 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.
- kaoD 13y agoBut 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?
- sspiff 13y agoI'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.)
- 13y ago
- sspiff 13y agoFor 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.
- CmonDev 13y agoDeveloping the language is more interesting then developing tooling I guess. F# has same issues.
- kozhevnikov 13y agoI'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 http://channel9.msdn.com/blogs/pdc2008/tl16 @ 1h1m
- michael_h 13y agoC# REPL like this http://www.mono-project.com/CsharpRepl http://www.mono-project.com/CsharpRepl ?
- BruceM 13y agoWell, 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/ 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.
- peterhull90 13y agoIn 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.
- yetfeo 13y agoMindy 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.
- BruceM 13y agoThanks 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.
- 13y ago
- informatimago 13y agoA 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).
- nickik 13y agoSince Dylan people are probably reading this. - What GC will the LLVM backend use? - Is there any data an the performance of the MPS?
- BruceM 13y agoHi 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.)
- nickik 13y agoHi 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.
- TempleOSV2 13y agoFor the sake of argument, mine could suck-ass, but with God's endorsement, home run. We will see. I don't know. Nothing else matters. God says... smart lust test_pilot oh_come_on make_my_day I'm_the_boss rockstar in_theory What daunting Catastrophic_Success yep furious you_don't_like_it furious could_it_be___Satan baffling energy you_know_a_better_God thats_right you're_wonderful air_head vengeful when_hell_freezes_over thank_you_very_much BRB place you_think_you_could_do_better smack_some_sense_into_you It's_nice_being_God Hasta hit