Re: [dylan] The Future of Dylan: Why are we here?
Wim Vander Schelden <[email protected]> Mon, 1 Sep 2014 10:41:14 +0200
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CAExEkt-SQUsD3OXuxvdvmM2uChUd21sdHcK11w0Z0trjumNr-g@mail.gmail.com> |
--===============2135878390== Content-Type: multipart/alternative; boundary=001a1134d0c43038540501fcf72b --001a1134d0c43038540501fcf72b Content-Type: text/plain; charset=UTF-8 I orginally came to Dylan because I was looking for a LISP-like that had a more robust (preferably static) typing system. I find it great that I can specify types explicitly, and get compile-time (serious) warnings. I would prefer S-expressions over the current syntax (of which I have mixed feelings), but that's not really a breaking point. As Robert mentioned, being able to produce native binaries is a nice thing, which is also something that has been pretty uncomfortable with LISPs in the past (for instance, generating an image from the SBCL REPL is less than ideal for packaging software in my experience). I haven't written complex Dylan projects yet, and I've used macros only a little, but in my experience the macro system, while powerful, does come with a big drawback: hard to parse error messages and warnings when compiling. I'm not sure this is an inherent problem with the macro system's flexibility, or an implementation issue. --001a1134d0c43038540501fcf72b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>I orginally came to Dylan because I was looking = for a LISP-like that had a more robust (preferably static) typing system. I= find it great that I can specify types explicitly, and get compile-time (s= erious) warnings.<br> <br></div>I would prefer S-expressions over the current syntax (of which I = have mixed feelings), but that's not really a breaking point.<br><br></= div><div>As Robert mentioned, being able to produce native binaries is a ni= ce thing, which is also something that has been pretty uncomfortable with L= ISPs in the past (for instance, generating an image from the SBCL REPL is l= ess than ideal for packaging software in my experience).<br> <br></div><div>I haven't written complex Dylan projects yet, and I'= ve used macros only a little, but in my experience the macro system, while = powerful, does come with a big drawback: hard to parse error messages and w= arnings when compiling. I'm not sure this is an inherent problem with t= he macro system's flexibility, or an implementation issue.<br> </div></div> --001a1134d0c43038540501fcf72b-- --===============2135878390== 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 --===============2135878390==--