Re: [dylan] The Future of Dylan: Why are we here?
Carl Gay <[email protected]> Wed, 3 Sep 2014 14:58:00 -0400
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CALekcH1FgNAF0zcK8Zt09PFwH9T8zZQJNJ1AfR9CPfXgwjWtyQ@mail.gmail.com> |
--===============0886890562== Content-Type: multipart/alternative; boundary=14dae94edd6d9eba4a05022dd051 --14dae94edd6d9eba4a05022dd051 Content-Type: text/plain; charset=UTF-8 [back from vacation] I agree with Bruce Hoult, the consistent design and orthogonal features are the key thing. That's about the same as saying it's the whole package; you can't remove any one feature (multi-methods, macros, optional types, conditions, ...) and still call it Dylan. I *do* find the optional typing really important. It allows the code to be much less cluttered and more readable if you specify types on, say, function parameters but not on most local variables, while still being efficient. I *don't* find fully typeless development to be very important. It can make the code harder to read, just as fully statically typed code can.[1] "All things in moderation." The IDE made fully typeless code even less important by having a "loose" development mode that (IIUC) basically ignored all the type specs. As for syntax, I don't personally care much. The main benefit to prefix would be to ease tooling, but switching back would be tons of work, and I still fear that it would be a turn off for a lot of potential users. Go seems to have reasonable tooling support via its http://golang.org/pkg/go/ package. Maybe we could do something similar but I fear macros will thwart us, as usual. Don't know for sure. The main pain points I've had over the years: * Module system is complex. As already pointed out, it can be hard to see where a definition comes from without an IDE. The "create" clause isn't very intuitive. * Being a LISP-1. Having a single namespace for variables and functions greatly increases the need for "poor-man's namespacing", usually by adding a prefix to slot getter names. point-x, point-y, point-z, point.point-x ... ick. * Infix macros are much more difficult to master than prefix macros (and to write tools for, I suspect). -Carl [1] Go somehow seems to have found the worst of both worlds here. It's fully statically typed and the compiler infers a lot. I frequently find myself having to search up the call chain two or three levels to figure out what kind of object I'm dealing with. (Google's style guide makes this even worse by encouraging the "v := ..." binding form over "var v T = ...".) On Mon, Sep 1, 2014 at 3:22 AM, Bruce Mitchener <[email protected]> wrote: > I'm going to break this up over a couple of days as I'd like to see > (hopefully) some discussion of the early points before we move into the > later points. > > I will also try not to answer the questions with my own answers within the > initial posts, but use a follow up to do so so that my opinions are at > least somewhat separate from the questions. > > If you haven't used Dylan in a long time, your answers are welcome as well! > > Even if you just think that you agree with what others have posted or some > of the points below, please respond anyway. The more feedback that we get, > the more we can understand which positions are strongly held and by how > much of the community. > > ------ > > The very least you can do in your life is figure out what you hope for. > And the most you can do is live inside that hope. > Not admire it from a distance but live right in it, under its roof. > > -- Barbara Kingsolver > > It is time for everyone with an interest in Dylan to think about the > future of Dylan. > > But let's take a step backwards. Why are we here? Why are we reading this? > > What Makes Dylan Special? > ------ > > 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? > > Thanks! > > - Bruce > > > _______________________________________________ > hackers mailing list > [email protected] > https://lists.opendylan.org/mailman/listinfo/hackers > > --14dae94edd6d9eba4a05022dd051 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>[back from vacation]</div><div><br></div>I agree with= Bruce Hoult, the consistent design and orthogonal features are the key thi= ng. =C2=A0That's about the same as saying it's the whole package; y= ou can't remove any one feature (multi-methods, macros, optional types,= conditions, ...) and still call it Dylan.<div> <br></div><div>I <b>do</b> find the optional typing really important. =C2= =A0It allows the code to be much less cluttered and more readable if you sp= ecify types on, say, function parameters but not on most local variables, w= hile still being efficient. =C2=A0I <b>don't</b> find fully typeless de= velopment to be very important. =C2=A0It can make the code harder to read, = just as fully statically typed code can.[1] =C2=A0"All things in moder= ation." =C2=A0The IDE made fully typeless code even less important by = having a "loose" development mode that (IIUC) basically ignored a= ll the type specs.</div> <div><br></div><div>As for syntax, I don't personally care much. =C2=A0= The main benefit to prefix would be to ease tooling, but switching back wou= ld be tons of work, and I still fear that it would be a turn off for a lot = of potential users. =C2=A0Go seems to have reasonable tooling support via i= ts=C2=A0<a href=3D"http://golang.org/pkg/go/">http://golang.org/pkg/go/</a>= package. =C2=A0Maybe we could do something similar but I fear macros will = thwart us, as usual. =C2=A0Don't know for sure.</div> <div><br></div><div>The main pain points I've had over the years:</div>= <div><br></div><div>* Module system is complex. =C2=A0As already pointed ou= t, it can be hard to see where a definition comes from without an IDE. =C2= =A0The "create" clause isn't very intuitive.</div> <div><br></div><div>* Being a LISP-1. =C2=A0Having a single namespace for v= ariables and functions greatly increases the need for "poor-man's = namespacing", usually by adding a prefix to slot getter names. =C2=A0p= oint-x, point-y, point-z, point.point-x ... ick.</div> <div><br></div><div>* Infix macros are much more difficult to master than p= refix macros (and to write tools for, I suspect).</div><div><br></div><div>= -Carl</div><div><br></div><div><br></div><div>[1] Go somehow seems to have = found the worst of both worlds here. =C2=A0It's fully statically typed = and the compiler infers a lot. =C2=A0I frequently find myself having to sea= rch up the call chain two or three levels to figure out what kind of object= I'm dealing with. =C2=A0(Google's style guide makes this even wors= e by encouraging the "v :=3D ..." binding form over "var v T= =3D ...".)<br> <div><br></div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"g= mail_quote">On Mon, Sep 1, 2014 at 3:22 AM, Bruce Mitchener <span dir=3D"lt= r"><<a href=3D"mailto:[email protected]" target=3D"_blank">bruce= [email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div dir=3D"ltr">I'm going to break this up over a cou= ple of days as I'd like to see (hopefully) some discussion of the early= points before we move into the later points.<div> <br></div><div>I will also try not to answer the questions with my own answ= ers within the initial posts, but use a follow up to do so so that my opini= ons are at least somewhat separate from the questions.</div> <div><br></div><div><div>If you haven't used Dylan in a long time, your= answers are welcome as well!</div><div><br></div></div><div><div>Even if y= ou just think that you agree with what others have posted or some of the po= ints below, please respond anyway. The more feedback that we get, the more = we can understand which positions are strongly held and by how much of the = community.</div> <div><br></div></div><div>------</div><div><br></div><div><div>=C2=A0 =C2= =A0 The very least you can do in your life is figure out what you hope for.= </div><div>=C2=A0 =C2=A0 And the most you can do is live inside that hope.<= /div><div>=C2=A0 =C2=A0 Not admire it from a distance but live right in it,= under its roof.</div> <div><br></div><div>=C2=A0 =C2=A0 =C2=A0 -- Barbara Kingsolver</div><div><b= r></div><div>It is time for everyone with an interest in Dylan to think abo= ut the future of Dylan.</div><div><br></div><div>But let's take a step = backwards. Why are we here? Why are we reading this?</div> <div><br></div><div>What Makes Dylan Special?</div><div>------</div><div><b= r></div><div>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 mains= tream?</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><br></div></div><div>Thanks!<span><font color=3D"#888888"><br></= font></span></div><span><font color=3D"#888888"><div> <br></div><div>=C2=A0- Bruce</div><div><br></div></font></span></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</a><br> <br></blockquote></div><br></div></div></div></div></div> --14dae94edd6d9eba4a05022dd051-- --===============0886890562== 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 --===============0886890562==--