Re: [dylan] The Future of Dylan: Why are we here?
Bruce Mitchener <[email protected]> Tue, 2 Sep 2014 09:48:56 +0700
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CA+esKjP=szd_YXywcAdC0F2x6XMq=UQ9s=xG+7mm406XjE3m0Q@mail.gmail.com> |
--===============1527743415== Content-Type: multipart/alternative; boundary=047d7bacb0a6271c8305020c29e5 --047d7bacb0a6271c8305020c29e5 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 1, 2014 at 2:22 PM, Bruce Mitchener <[email protected]> wrote: > What makes Dylan special? What makes it great? What makes some of us want > to keep working on it, well past any hope of entering the mainstream? > > Some like the macros. Some like the condition system. Others appreciate > the sliding scale between static and dynamic behaviors. Some appreciate > that it can generate efficient, native executables and shared libraries. > Still others find the syntax to be nice while, admittedly, others hate the > syntax. Yet others appreciate the coherent and consistent design behind > Dylan, where a set of core features mesh well to provide a clean and clear > language. Perhaps some value that we have an actual language specification > via the DRM. > > What brings you here? > > To move on and think further about the future of Dylan, we must understand > why we've chosen to be here in the first place. > > What are the core values of Dylan? What must, above all else, be preserved? > I remember seeing Dylan in MacTech and other media in the 1990s and how exciting things seemed then. Compared to some of the tools that I was using at the time, it seemed like an impossible vision from the future. (If only I'd known about Smaltalk, Lisp Machines and so on at the time!) I looked at Dylan a couple of times between 2000 and 2010, but didn't end up diving in due to being too busy and various issues with trying to use Dylan. For me, the key moment came after a couple of years of using Scala. I have many complaints about Scala, but chief among them is that it doesn't feel like a coherent and consistent language design. We can talk about whether or not a build tool should consume 3+ gigs of memory, or whether or not it is okay for accessing an element in a map to require an allocation, but at the core of it, I was really missing a sense of elegance. To me, one of the most important core values of Dylan is that it is pretty consistent and clear and the pieces fit together very nicely. That's something that I would not want to lose when looking to add or change features in the core Dylan language. As for other elements of the design, I can argue either side of the case for macros. There are times and places where I really appreciate them, but also situations where I really dislike them and the extra difficulty that they bring. I suspect that some of the issues are a matter of having bugs or deficiencies in the implementation, but given that no one has really made the dive into that code in over a decade, it is a bit intimidating. I used to really appreciate the dynamic nature and being able to make things progressively more static. Lately, I've been enjoying having added static guarantees and think that the slider can be reset to have a bit less of a dynamic and increasingly more static nature. I think that reality has changed significantly since the 1980s and 1990s in terms of what compilers can do and how fast they can do it. I can do entire builds of some things now than I could do an incremental build in the past. It would be interesting to see where the productivity cut offs change these days, especially once we get a working JIT & debugger again in Open Dylan with the advent of the LLVM backend. I like conditions, but I'm less sure about their future as I think it'll be interesting to see how they fit into a more static view of the world. The syntax really just isn't that important to me. When I left Scala, I took a look around. What did I want to be working with? What type of language did I want to be using? How much work did I want to put into things? I figured that I had a couple of choices. I could use an existing language, I could seek to mold an existing language to be better, or I could start from scratch. I didn't want to start from scratch as it is really hard to build everything from the ground up. It is easier now than it was 20 years ago, but a significant amount of labor is still involved, especially if you want it to be usable in production. I didn't really want to use an existing language exactly. I didn't see one that gave me everything that I wanted. That left the option of molding an existing language to be more to my liking. In the end, I thought that Dylan was pretty close and had solid implementations and was well suited for being improved upon. We covered the design side of why I like Dylan above. I'll talk about what I didn't like in the design another time (after other emails in this process). That leaves the implementation. Some things that I really like about the Open Dylan implementation: - It produces native executables and shared libraries. I have a proposal for improving upon this some, but this is a key thing in my mind. You can see other languages striving to do this for years and not approaching the ease with which this is possible in Dylan. - It works and it works pretty well. We've got some rough patches admittedly. There are still some interesting 64 bit issues. We have done some ports that haven't been shipped (ARM Linux and 64 bit FreeBSD). We've improved upon the GC integration significantly, including working with Ravenbrook to fix a number of issues with MPS and Open Dylan. The implementations also bring some pain with them, but this is true of all implementations of anything. There are things that can be done to improve the situation, but overall, things are pretty decent. To me, these are core values as well and things that I don't want to give up (entirely). I'm willing to take limited short term sacrifices, but I don't want to give up the fact that Open Dylan works and that it produces native executables. An example of a limited short term sacrifice is that I'm willing, for example, to temporarily abandon Windows so that we can get rid of the HARP compiler back-end. I wouldn't be willing to start over entirely from scratch. Finally, I also appreciate that we have a specification, despite some of the flaws in it. I think that it can be improved upon in places and I hope that we can work things out to where we can treat it as a living specification (but not freely editable in a willy-nilly fashion). I still hope to hear from many of you that haven't responded yet. (Carl, Chris Page, Housel, Dustin Voss, Scott McKay, Hannes, Benjamin Pollack, Ingo, Sean, Seyi, Bastian, aglynn, Glenn to name a few.) - Bruce --047d7bacb0a6271c8305020c29e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M= on, Sep 1, 2014 at 2:22 PM, Bruce Mitchener <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]" target=3D"_blank">bruce.mitchener@gma= il.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>What makes Dylan speci= al? What makes it great? What makes some of us want to keep working on it, = well past any hope of entering the mainstream?<br> </div><div> <div><br></div><div>Some like the macros. Some like the condition system. O= thers appreciate the sliding scale between static and dynamic behaviors. So= me appreciate that it can generate efficient, native executables and shared= libraries. Still others find the syntax to be nice while, admittedly, othe= rs hate the syntax. Yet others appreciate the coherent and consistent desig= n behind Dylan, where a set of core features mesh well to provide a clean a= nd clear language. Perhaps some value that we have an actual language speci= fication via the DRM.</div> <div><br></div><div>What brings you here?<br></div><div><br></div><div>To m= ove on and think further about the future of Dylan, we must understand why = we've chosen to be here in the first place.</div><div><br></div><div> What are the core values of Dylan? What must, above all else, be preserved?= </div></div></div></blockquote><div><br></div><div>I remember seeing Dylan = in MacTech and other media in the 1990s and how exciting things seemed then= . Compared to some of the tools that I was using at the time, it seemed lik= e an impossible vision from the future. (If only I'd known about Smalta= lk, Lisp Machines and so on at the time!)</div> <div><br></div><div>I looked at Dylan a couple of times between 2000 and 20= 10, but didn't end up diving in due to being too busy and various issue= s with trying to use Dylan.</div><div><br></div><div>For me, the key moment= came after a couple of years of using Scala. I have many complaints about = Scala, but chief among them is that it doesn't feel like a coherent and= consistent language design. We can talk about whether or not a build tool = should consume 3+ gigs of memory, or whether or not it is okay for accessin= g an element in a map to require an allocation, but at the core of it, I wa= s really missing a sense of elegance.</div> <div><br></div><div>To me, one of the most important core values of Dylan i= s that it is pretty consistent and clear and the pieces fit together very n= icely. That's something that I would not want to lose when looking to a= dd or change features in the core Dylan language.</div> <div><br></div><div>As for other elements of the design, I can argue either= side of the case for macros. There are times and places where I really app= reciate them, but also situations where I really dislike them and the extra= difficulty that they bring. I suspect that some of the issues are a matter= of having bugs or deficiencies in the implementation, but given that no on= e has really made the dive into that code in over a decade, it is a bit int= imidating.</div> <div><br></div><div>I used to really appreciate the dynamic nature and bein= g able to make things progressively more static. Lately, I've been enjo= ying having added static guarantees and think that the slider can be reset = to have a bit less of a dynamic and increasingly more static nature. I thin= k that reality has changed significantly since the 1980s and 1990s in terms= of what compilers can do and how fast they can do it. I can do entire buil= ds of some things now than I could do an incremental build in the past. It = would be interesting to see where the productivity cut offs change these da= ys, especially once we get a working JIT & debugger again in Open Dylan= with the advent of the LLVM backend.</div> <div><br></div><div>I like conditions, but I'm less sure about their fu= ture as I think it'll be interesting to see how they fit into a more st= atic view of the world.</div><div><br></div><div>The syntax really just isn= 't that important to me.</div> <div><br></div><div>When I left Scala, I took a look around. What did I wan= t to be working with? What type of language did I want to be using? How muc= h work did I want to put into things? I figured that I had a couple of choi= ces. I could use an existing language, I could seek to mold an existing lan= guage to be better, or I could start from scratch.</div> <div><br></div><div>I didn't want to start from scratch as it is really= hard to build everything from the ground up. It is easier now than it was = 20 years ago, but a significant amount of labor is still involved, especial= ly if you want it to be usable in production. I didn't really want to u= se an existing language exactly. I didn't see one that gave me everythi= ng that I wanted.</div> <div><br></div><div>That left the option of molding an existing language to= be more to my liking. In the end, I thought that Dylan was pretty close an= d had solid implementations and was well suited for being improved upon.</d= iv> <div><br></div><div>We covered the design side of why I like Dylan above. I= 'll talk about what I didn't like in the design another time (after= other emails in this process). =C2=A0That leaves the implementation. =C2= =A0Some things that I really like about the Open Dylan implementation:</div= > <div><br></div><div><ul><li>It produces native executables and shared libra= ries. I have a proposal for improving upon this some, but this is a key thi= ng in my mind. You can see other languages striving to do this for years an= d not approaching the ease with which this is possible in Dylan.<br> </li><li>It works and it works pretty well. We've got some rough patche= s admittedly. There are still some interesting 64 bit issues. We have done = some ports that haven't been shipped (ARM Linux and 64 bit FreeBSD). We= 've improved upon the GC integration significantly, including working w= ith Ravenbrook to fix a number of issues with MPS and Open Dylan.</li> </ul></div><div>The implementations also bring some pain with them, but thi= s is true of all implementations of anything. There are things that can be = done to improve the situation, but overall, things are pretty decent.</div> <div><br></div><div>To me, these are core values as well and things that I = don't want to give up (entirely). =C2=A0I'm willing to take limited= short term sacrifices, but I don't want to give up the fact that Open = Dylan works and that it produces native executables. =C2=A0An example of a = limited short term sacrifice is that I'm willing, for example, to tempo= rarily abandon Windows so that we can get rid of the HARP compiler back-end= . =C2=A0I wouldn't be willing to start over entirely from scratch.</div= > <div><br></div><div>Finally, I also appreciate that we have a specification= , despite some of the flaws in it. I think that it can be improved upon in = places and I hope that we can work things out to where we can treat it as a= living specification (but not freely editable in a willy-nilly fashion).</= div> <div><br></div><div>I still hope to hear from many of you that haven't = responded yet. (Carl, Chris Page, Housel, Dustin Voss, Scott McKay, Hannes,= Benjamin Pollack, Ingo, Sean, Seyi, Bastian, aglynn, Glenn to name a few.)= </div> <div><br></div><div>=C2=A0- Bruce</div><div><br></div></div></div></div> --047d7bacb0a6271c8305020c29e5-- --===============1527743415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ hackers mailing list [email protected] https://lists.opendylan.org/mailman/listinfo/hackers --===============1527743415==--