Re: [dylan] The Future of Dylan: Why are we here?

--===============1890861870==
Content-Type: multipart/alternative; boundary=089e013c6eca478c200501fcd83d

--089e013c6eca478c200501fcd83d
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 1, 2014 at 7:22 PM, Bruce Mitchener <[email protected]>
wrote:

> 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?
>

Yes, all of that.

The #1 meta thing is that the features in Dylan are simple, powerful and
ORTHOGONAL and combine the way you'd expect, without a bunch of exceptions
and restrictions.

I like to be able to program in a high level way, but be able to make those
small parts of the program that determine the overall speed run at the
speed of the metal (within a very small epsilon of C/C++ .. 20%, not 2x).

I like my programming language to be portable, my myself in a few days, to
any conceivable OS or CPU I might be using. Gwydion is fabulous for that.
which is probably the prime reason I still use it today and have never
learned how to use Open Dylan. LLVM support for Open Dylan could change
that. Heck, it might already be changed if the C backend and Boehm are now
fully first class citizens in the Open Dylan world.

If the Open Dylan IDE and debugger ran on machines I owned (Mac and *nix)
then I'd probably have switched years ago. I'd hate to see that not part of
the system in future. I presume that needs LLVM to be portable (for JIT and
debugging).

I love the syntax and macro system. I love that most of the built in syntax
is macros from a library, and malleable by importing a different library.
It has its warts. I'd like to see compile-time code execution, but I'm not
willing to go to S-exprs to get that. Code generation and multi-step
makefiles get you 90% of the benefits.

Note that the macros would not work *nearly* as well without the other
features: the ability to in a single macro expansion define new types,
global init code, inject new methods into existing GFs...


The ugly stuff and what is missing:

- a type system for function values. Glad to see it's being worked on.

- namespace clashes between local bindings and slot accessors i.e. "let foo
= x.foo;" and now you can't access the slot. This hits beginners ALL the
time, and me too. But I think full multiple namespaces ala Common Lisp is
overkill. Suggestion: x.foo means foo-getter(x).

- better support for functional classes. Functional programming and OO are
(contrary to popular opinion with C++/Java programmers) NOT mutually
exclusive. Inheritance and polymorphic dispatch are just as useful in a
functional program. But you need ways to say "make a new object, just like
those one except for these changes..."

- modern string and array processing.

--089e013c6eca478c200501fcd83d
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 7:22 PM, Bruce Mitchener <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">bruce.mitchener@gma=
il.com</a>&gt;</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><div>Some like the mac=
ros. Some like the condition system. Others appreciate the sliding scale be=
tween static and dynamic behaviors. Some appreciate that it can generate ef=
ficient, native executables and shared libraries. Still others find the syn=
tax to be nice while, admittedly, others hate the syntax. Yet others apprec=
iate the coherent and consistent design behind Dylan, where a set of core f=
eatures mesh well to provide a clean and clear language. Perhaps some value=
 that we have an actual language specification via the DRM.</div>

<div><br></div><div>What brings you here?</div></div></div></blockquote><di=
v><br></div><div>Yes, all of that.</div><div><br></div><div>The #1 meta thi=
ng is that the features in Dylan are simple, powerful and ORTHOGONAL and co=
mbine the way you&#39;d expect, without a bunch of exceptions and restricti=
ons.</div>
<div><br></div><div>I like to be able to program in a high level way, but b=
e able to make those small parts of the program that determine the overall =
speed run at the speed of the metal (within a very small epsilon of C/C++ .=
. 20%, not 2x).</div>
<div><br></div><div>I like my programming language to be portable, my mysel=
f in a few days, to any conceivable OS or CPU I might be using. Gwydion is =
fabulous for that. which is probably the prime reason I still use it today =
and have never learned how to use Open Dylan. LLVM support for Open Dylan c=
ould change that. Heck, it might already be changed if the C backend and Bo=
ehm are now fully first class citizens in the Open Dylan world.</div>
<div><br></div><div>If the Open Dylan IDE and debugger ran on machines I ow=
ned (Mac and *nix) then I&#39;d probably have switched years ago. I&#39;d h=
ate to see that not part of the system in future. I presume that needs LLVM=
 to be portable (for JIT and debugging).</div>
<div><br></div><div>I love the syntax and macro system. I love that most of=
 the built in syntax is macros from a library, and malleable by importing a=
 different library. It has its warts. I&#39;d like to see compile-time code=
 execution, but I&#39;m not willing to go to S-exprs to get that. Code gene=
ration and multi-step makefiles get you 90% of the benefits.</div>
<div><br></div><div>Note that the macros would not work *nearly* as well wi=
thout the other features: the ability to in a single macro expansion define=
 new types, global init code, inject new methods into existing GFs...</div>
<div><br></div><div><br></div><div>The ugly stuff and what is missing:</div=
><div><br></div><div>- a type system for function values. Glad to see it&#3=
9;s being worked on.</div><div><br></div><div>- namespace clashes between l=
ocal bindings and slot accessors i.e. &quot;let foo =3D x.foo;&quot; and no=
w you can&#39;t access the slot. This hits beginners ALL the time, and me t=
oo. But I think full multiple namespaces ala Common Lisp is overkill. Sugge=
stion: x.foo means foo-getter(x).</div>
<div><br></div><div>- better support for functional classes. Functional pro=
gramming and OO are (contrary to popular opinion with C++/Java programmers)=
 NOT mutually exclusive. Inheritance and polymorphic dispatch are just as u=
seful in a functional program. But you need ways to say &quot;make a new ob=
ject, just like those one except for these changes...&quot;</div>
<div><br></div><div>- modern string and array processing.</div><div><br></d=
iv></div></div></div>

--089e013c6eca478c200501fcd83d--

--===============1890861870==
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

--===============1890861870==--