Re: [dylan] The Future of Dylan: What do we use it for?

Erik Charlebois <[email protected]> Tue, 9 Sep 2014 12:09:16 -0400
Newsgroups gmane.comp.lang.dylan.gwydion.devel
Message-ID <CAC+abJZgSy_-406Pb7BM8KF6qR=JWQks_s=5G-uoqMPN2E6hxA@mail.gmail.com>
--===============1270999780==
Content-Type: multipart/alternative; boundary=e89a8f92410e3d6c820502a42862

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

This is something .NET has really done well with value types, layout
attributes, out/ref parameters, unsafe blocks where you can manipulate
interior pointers, and the new SIMD support.

http://msdn.microsoft.com/en-us/library/y31yhkeb.aspx
http://blogs.msdn.com/b/dotnet/archive/2014/04/07/the-jit-finally-proposed-jit-and-simd-are-getting-married.aspx


On Mon, Sep 8, 2014 at 3:03 PM, Andrew Glynn <[email protected]>
wrote:

> A while ago I did a bit of work on a Dylan game engine, but I ended up
> getting kind of bogged down in various details, many of which were
> unrelated to Dylan. Although I might be getting ahead of things here, I'll
> briefly mention a couple of issues that could make the Dylan side of game
> development easier in the future.
>
> First, Bruce (and others?) already put in a lot of work on improving
> melange, and those improvements certainly made my life quite a bit easier.
> But it's still not as painless as one might hope. Would the LLVM back-end
> help for auto-generating FFI stuff? For example, integrating libclang
> somehow? Being able to integrate with C++ (in addition to C) would be even
> better, considering all the libraries it would make available, but I don't
> know how complicated that would be.
>
> Second: value types. I'm not trying to create fancy AAA blockbuster games,
> but even for a little toy physics engine I've had to replace my <vec2>
> class and its useful library of vector math functions with a bunch of raw
> <single-float>s in order to get acceptable performance. To be fair, I
> didn't profile to see why the class-based version was so much slower, but I
> imagine having unboxed, stack allocated value types (and vectors of them
> allocated contiguously) would be helpful.
>
> -Andrew
>
>
> On Wed, Sep 3, 2014 at 7:59 AM, Bruce Mitchener <[email protected]
> > wrote:
>
>> Feel free to respond to the earlier thread if you haven't yet, but here's
>> the next thread!
>>
>> What do we all use or want to use Dylan for?
>>
>> The idea here is to see what sort of thing we might focus on, based on
>> how we intend to use Dylan. Also, perhaps enough of us are using it for
>> similar things that we can get some sort of cooperation going.
>>
>> We recognize that Dylan is a general purpose language and don't plan to
>> change that. But it might be well suited for certain types of applications,
>> especially if we're able to improve the library coverage some!
>>
>> Looking forward to hearing your thoughts!
>>
>>  - Bruce
>>
>>
>> _______________________________________________
>> hackers mailing list
>> [email protected]
>> https://lists.opendylan.org/mailman/listinfo/hackers
>>
>>
>
> _______________________________________________
> hackers mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/hackers
>
>

--e89a8f92410e3d6c820502a42862
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This is something .NET has really done well with valu=
e types, layout attributes, out/ref parameters, unsafe blocks where you can=
 manipulate interior pointers, and the new SIMD support.</div><div><div><br=
></div><div><a href=3D"http://msdn.microsoft.com/en-us/library/y31yhkeb.asp=
x">http://msdn.microsoft.com/en-us/library/y31yhkeb.aspx</a><br></div><div>=
<a href=3D"http://blogs.msdn.com/b/dotnet/archive/2014/04/07/the-jit-finall=
y-proposed-jit-and-simd-are-getting-married.aspx">http://blogs.msdn.com/b/d=
otnet/archive/2014/04/07/the-jit-finally-proposed-jit-and-simd-are-getting-=
married.aspx</a></div></div><div><br></div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Mon, Sep 8, 2014 at 3:03 PM, Andrew Glyn=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">A while ago I did a bit of work on a Dyl=
an game engine, but I ended up getting kind of bogged down in various detai=
ls, many of which were unrelated to Dylan. Although I might be getting ahea=
d of things here, I&#39;ll briefly mention a couple of issues that could ma=
ke the Dylan side of game development easier in the future.<div><br></div><=
div>First, Bruce (and others?) already put in a lot of work on improving me=
lange, and those improvements certainly made my life quite a bit easier. Bu=
t it&#39;s still not as painless as one might hope. Would the LLVM back-end=
 help for auto-generating FFI stuff? For example, integrating libclang some=
how? Being able to integrate with C++ (in addition to C) would be even bett=
er, considering all the libraries it would make available, but I don&#39;t =
know how complicated that would be.</div><div><br></div><div>Second: value =
types. I&#39;m not trying to create fancy AAA blockbuster games, but even f=
or a little toy physics engine I&#39;ve had to replace my &lt;vec2&gt; clas=
s and its useful library of vector math functions with a bunch of raw &lt;s=
ingle-float&gt;s in order to get acceptable performance. To be fair, I didn=
&#39;t profile to see why the class-based version was so much slower, but I=
 imagine having unboxed, stack allocated value types (and vectors of them a=
llocated contiguously) would be helpful.</div><div><br></div><div>-Andrew<b=
r></div><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Wed, Sep 3, 2014 at 7:59 AM, Bruce Mitchener <span dir=3D"lt=
r">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">bruce=
[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">Feel free to respond to the earlier thread if you haven&=
#39;t yet, but here&#39;s the next thread!<div><br></div><div>What do we al=
l use or want to use Dylan for?</div><div><br></div><div>The idea here is t=
o see what sort of thing we might focus on, based on how we intend to use D=
ylan. Also, perhaps enough of us are using it for similar things that we ca=
n get some sort of cooperation going.</div>
<div><br></div><div>We recognize that Dylan is a general purpose language a=
nd don&#39;t plan to change that. But it might be well suited for certain t=
ypes of applications, especially if we&#39;re able to improve the library c=
overage some!</div>
<div><br></div><div>Looking forward to hearing your thoughts!</div><span><f=
ont 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>
<br>_______________________________________________<br>
hackers mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]<=
/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>

--e89a8f92410e3d6c820502a42862--

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

--===============1270999780==--