Something I never quite understood about languages was why they are restricted to one or another domain. For example the author writes: Algebraic types? Dependent types? You'll never see them. They're too ... research-y Why can't those features be baked into C++ or Java?
Dylan: the harsh realities of the market
11–20 of 120 posts
Re: Dylan: the harsh realities of the market
#12For 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.
Re: Dylan: the harsh realities of the market
#13The article hits rather close to home, as someone who, for better or worse, is committed to improving Common Lisp's ecosystem. I often feel this existential dread of "Is it worth it? Whose lives will it change? Will I spend years labouring in obscurity for nothing?". And while the answer to all those questions is probably not what I'd like to hear, I still do it. This is why ecosystems are, for most people, more valu…
Re: Dylan: the harsh realities of the market
#14Something I never quite understood about languages was why they are restricted to one or another domain. For example the author writes: Algebraic types? Dependent types? You'll never see them. They're too ... research-y Why can't those features be baked into C++ or Java?
Re: Dylan: the harsh realities of the market
#15Dylan was my favorite language back in college. I remember following PG's essays to Lisp, and then Lisp to all the newer dialects like Dylan or Goo. Dylan had it all: a metaobject protocol, generic functions, optional static typing, infix macros . I even got started working on an Eclipse plugin for it, which I ended up shelving after like 3 weeks when I lost interest. Unfortunately, there are large network effects to…
I think it's performance.
"Scripting languages" tear compiled languages apart when it comes to iterating. Write a "hello world" web app page in Python and Scala, then see which one takes 30 seconds and about a gig of RAM to actually display in the browser.
On the other hand, if you needed performance scaled across millions of users, you needed C or C++.
The big languages are C and C++ and Fortran (if you need performance), a long laundry list of "scripting" languages, and Java. Java is the only one that actually gets a spot because of its tooling, most other languages only got tooling because people loved the languages.
There's a lot of compiled languages coming out (or re-emerging) these days (Scala, Haskell, Swift, Julia) with funky features that require compilation that don't get you closer to the metal. I suspect that's largely because computers now have the RAM and CPU power to actually make them fun to use.
Re: Dylan: the harsh realities of the market
#16> Algebraic types? Dependent types? You'll never see them. They're too ... research-y. They stink of academe, which is: they stink of uselessness-to-industry. One may think that because closures are finally entering the mainstream (after what, 5 decades?), we have hope for those things to come as well. But then I saw Swift. Built-in support for an Option type, so one can avoid null pointer exceptions. At the same tim…
enum Optional {
case None
case Some(T)
}Re: Dylan: the harsh realities of the market
#17A Conversation with Alan Kay, ACM Queue, 2004, https://queue.acm.org/detail.cfm?id=1039523
Re: Dylan: the harsh realities of the market
#18Re: Dylan: the harsh realities of the market
#19> Algebraic types? Dependent types? You'll never see them. They're too ... research-y. They stink of academe, which is: they stink of uselessness-to-industry. One may think that because closures are finally entering the mainstream (after what, 5 decades?), we have hope for those things to come as well. But then I saw Swift. Built-in support for an Option type, so one can avoid null pointer exceptions. At the same tim…
8 decades, to be precise. They predate electronic computing - Church published his original paper in 1932.
It still amazes me that it's only in the past few years that widely-used languages have begun adopting them.
Re: Dylan: the harsh realities of the market
#20Something I never quite understood about languages was why they are restricted to one or another domain. For example the author writes: Algebraic types? Dependent types? You'll never see them. They're too ... research-y Why can't those features be baked into C++ or Java?