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&#39;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&#39;t written complex Dylan projects yet, and I&#39;=
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&#39;m not sure this is an inherent problem with t=
he macro system&#39;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==--