Re: [dylan] The Future of Dylan: Why are we here?
Andrew Glynn <[email protected]> Tue, 2 Sep 2014 17:59:26 -0700
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CANmAu+Y3mA2c3U8N6aY7yAGTMkUfgYTa7yVU6mmm5MSxGzowCA@mail.gmail.com> |
--===============0471190874== Content-Type: multipart/alternative; boundary=001a113312a65a338b05021ebf26 --001a113312a65a338b05021ebf26 Content-Type: text/plain; charset=UTF-8 When I was in college and really just starting to learn programming (mid/late-90's) I used to wander around the programming languages section of the engineering library and pick up books that caught my eye. On one such occasion I ended up coming home with a copy of the DRM, but soon found I couldn't make heads or tails of it. A few years later, having gained a little bit of knowledge (or at least lost some ignorance), I became interested in multiple dispatch and came across references to that same inscrutable language from before. Looking into it again, I realized Dylan hit some kind of sweet spot for me: multi-methods, objects all the way down, closures, powerful condition system, infix macros (!), garbage collection, native code generation, and a (semi) free IDE to boot! At the time this collection of features seemed incredible, and even today it's better than most languages. I think we need to work hard to keep a small core of cohesive, powerful, and orthogonal features. As others have mentioned, Dylan seems to have a strong sense of design. Look at some other languages: C++ is a kind of awful Frankenstein's monster. Java lacks ambition. Scala never saw a new feature or type system trick it didn't like. Haskell has its strong points, but--heaven help me--I still like objects. All these years later I still wander around used bookstores and libraries looking for books on unusual and obscure programming languages, but of all the oddities I've come across, Dylan is the only one that I actually *use*. Even when working on a project in C++ (or whatever), I sometimes find myself writing up bits in Dylan first, using it as a kind of pseudo-code. And in my all too infrequent side projects I keep coming back to Dylan when possible. Why? It's hard to say precisely, beyond the list of features I (and others) have given. I guess it's just fun. -Andrew On Mon, Sep 1, 2014 at 7:48 PM, Bruce Mitchener <[email protected]> wrote: > 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 > > > _______________________________________________ > hackers mailing list > [email protected] > https://lists.opendylan.org/mailman/listinfo/hackers > > --001a113312a65a338b05021ebf26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">When I was in college and really just starting to learn pr= ogramming (mid/late-90's) I used to wander around the programming langu= ages section of the engineering library and pick up books that caught my ey= e. On one such occasion I ended up coming home with a copy of the DRM, but = soon found I couldn't make heads or tails of it. A few years later, hav= ing gained a little bit of knowledge (or at least lost some ignorance), I b= ecame interested in multiple dispatch and came across references to that sa= me inscrutable language from before. Looking into it again, I realized Dyla= n hit some kind of sweet spot for me: multi-methods, objects all the way do= wn, closures, powerful condition system, infix macros (!), garbage collecti= on, native code generation, and a (semi) free IDE to boot! At the time this= collection of features seemed incredible, and even today it's better t= han most languages.<div> <br></div><div>I think we need to work hard to keep a small core of cohesiv= e, powerful, and orthogonal features. As others have mentioned, Dylan seems= to have a strong sense of design. Look at some other languages: =C2=A0C++ = is a kind of awful Frankenstein's monster. Java lacks ambition. Scala n= ever saw a new feature or type system trick it didn't like. Haskell has= its strong points, but--heaven help me--I still like objects.</div> <div><br></div><div>All these years later I still wander around used bookst= ores and libraries looking for books on unusual and obscure programming lan= guages, but of all the oddities I've come across, Dylan is the only one= that I actually *use*. Even when working on a project in C++ (or whatever)= , I sometimes find myself writing up bits in Dylan first, using it as a kin= d of pseudo-code. And in my all too infrequent side projects I keep coming = back to Dylan when possible. Why? It's hard to say precisely, beyond th= e list of features I (and others) have given. I guess it's just fun.<br= > </div><div><br></div><div>-Andrew</div><div><br></div><div class=3D"gmail_e= xtra"><br><div class=3D"gmail_quote">On Mon, Sep 1, 2014 at 7:48 PM, Bruce = Mitchener <span dir=3D"ltr"><<a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</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 class=3D"gmail_extra">= <div class=3D"gmail_quote"><div>On Mon, Sep 1, 2014 at 2:22 PM, Bruce Mitch= ener <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" tar= get=3D"_blank">[email protected]</a>></span> wrote:<br> </div><div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>What makes = Dylan special? What makes it great? What makes some of us want to keep work= ing 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><div>I remember seeing = Dylan in MacTech and other media in the 1990s and how exciting things seeme= d then. Compared to some of the tools that I was using at the time, it seem= ed like an impossible vision from the future. (If only I'd known about = Smaltalk, 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> <span><font color=3D"#888888"> <div><br></div><div>=C2=A0- Bruce</div><div><br></div></font></span></div><= /div></div> <br>_______________________________________________<br> hackers mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">hackers@li= sts.opendylan.org</a><br> <a href=3D"https://lists.opendylan.org/mailman/listinfo/hackers" target=3D"= _blank">https://lists.opendylan.org/mailman/listinfo/hackers<br clear=3D"al= l"><div><br></div></a></blockquote></div></div></div> --001a113312a65a338b05021ebf26-- --===============0471190874== 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 --===============0471190874==--