1. 21
  1.  

  2. 12

    I’m just going to copy and paste what I said on HN as I have a lot of work to do today (including some Dylan stuff) …

    I’m the Bruce that he mentioned in the post.

    For better or worse, I’ve been pushing Dylan forward heavily over the last few years and am effectively the primary maintainer.

    Over the last couple of years, we’ve made a lot of progress. We’ve completely revived the documentation from 1990s era FrameMaker files and have it published via a pretty modern system. We’ve converted from SVN to Git and moved to GitHub. We’ve done 4 actual releases. We’ve improved our platform portability. We’ve provided some basic debugging integration with LLDB. We’ve fixed some long standing issues in the compiler and tool chain. We’ve improved the GC integration on all platforms.

    But there’s a lot to do. We need to fix our Unicode support. We need to improve the type system in at least minor ways if not major ways. We need to improve how parse failures are handled as the errors are not always friendly. We need more libraries. Some of this is really easy, some isn’t. But for pretty much everything, there are bite-sized pieces of work that could be done in a couple of hours/week that would lead to significant gains.

    I’ve wanted to just flat out use Dylan for something and have built some small prototypes with it and while they’ve worked out well enough, the actual projects themselves didn’t go anywhere (unrelated to the use of Dylan).

    I think this blog post was triggered by a comment that I’d made publicly yesterday that I’m feeling rather discouraged at this point. There was also a private email that I sent to 19 people who have been involved with Dylan recently, but the author of this post didn’t get that email.

    I view Dylan, not as a language from the past, but as a stepping ladder towards building a better language for the future. We don’t have to get bogged down in a lot of the minutiae involved in creating a new language as a lot of the work has been done. We get to focus on things at a different level and those things are just as important. People bring up Goo often when Dylan comes up. Goo is interesting, but the implementation is nothing close to being industrial enough to survive an encounter with the real world.

    I came to Dylan because I saw the mess that Scala and other languages were. I didn’t like where they were going and following some people on Twitter like https://twitter.com/milessabin and others seems to show that I’m not alone.

    And that’s why I’ll probably keep at it with Dylan. I want a better future and I’m going to keep trying to build it.

    1. 4

      I view Dylan, not as a language from the past, but as a stepping ladder towards building a better language for the future.

      I’d love to hear more about what you like about Dylan, either in comment or blog or the like. I doubt I’m the only one; this would be great material for this site.

      Please keep working on Dylan, and working towards simpler, more conceptually cohesive languages in general. There is something fundamentally wrong with a lot of languages today that many devs just aren’t able to detect. They may have a vague sense of dismay when working on big projects for extended periods of time that something could be better, but I believe they lack the imagination to understand that their tools could help them a lot more. Selling simple languages is very tough!

      I want a better future and I’m going to keep trying to build it.

      Same here. I’d rather fail than have never tried.

      1. 2

        Ha. I could have written that almost word for word about Self. I don’t know if that’s encouraging or scary.

      2. 5

        Separately from what I wrote on HN and copy/pasted here … I had a phone call with him today as well. One of his big points was that Dylan worked just fine for him to build and ship applications in 2002, so there’s no reason it can’t do the same today.

        I’ve only built prototypes to date in Dylan, but if I do decide to go with building a memory / heap profiler, the collection & analysis server for it will probably be written in Dylan. (My prototypes are in Python.) If I end up going with the news application stuff that I’m working on for a challenge, the prototypes are in Python again, but longer term pieces may well be in Dylan. Either way, I’m going to end up creating some fun and useful libraries along the way.

        1. 6

          Good enough for 2002 really doesn’t mean much to me in 2014.

          The world hasn’t frozen in place over the last 12 years.

          1. 4

            People are building and shipping modern applications in C, a language that hasn’t changed significantly since the late 80’s. The same is true of C++.

            There have been minor updates, but most people don’t use these updates in a commercial setting yet. C99 and C++03 are still the standard in most codebases.

            A good language can be a good language even if its design is decades old.

            1. 2

              You build and ship applications using implementations of a language not the language itself.

              There’s a large difference between a language that hasn’t changed significantly in 12 years, 30 years, etc and an implementation that has seen little improvement in that amount of time.

              Implementations can rot. Someone could use an implementation of a language in 2002 to ship software doesn’t mean much to me in 2014.

              1. 1

                People are building and shipping modern applications in C, a language that hasn’t changed significantly since the late 80’s.

                Sure, and C has its place, but if you’re using it for high-level applications today the way you would have in the 80s, you’re going to have someone swoop in and eat your lunch who’s using something more modern, unless you’re off in an unpopulated niche somewhere.