Re: [dylan] The Future of Dylan: What do we use it for?
Andrew Glynn <[email protected]> Mon, 8 Sep 2014 12:03:05 -0700
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CANmAu+aoJXPcE6SHdQsYc_fCNHz5rdC9jUXcRftT0siwGOfnQw@mail.gmail.com> |
--===============1129185878== Content-Type: multipart/alternative; boundary=bcaec52d571909e13d0502927811 --bcaec52d571909e13d0502927811 Content-Type: text/plain; charset=UTF-8 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 > > --bcaec52d571909e13d0502927811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">A while ago I did a bit of work on a Dylan game engine, bu= t 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.<div><br></div><div>First, Bruce (= and others?) already put in a lot of work on improving melange, and those i= mprovements certainly made my life quite a bit easier. But it's still n= ot as painless as one might hope. Would the LLVM back-end help for auto-gen= erating FFI stuff? For example, integrating libclang somehow? Being able to= integrate with C++ (in addition to C) would be even better, considering al= l the libraries it would make available, but I don't know how complicat= ed that would be.</div><div><br></div><div>Second: value types. I'm not= trying to create fancy AAA blockbuster games, but even for a little toy ph= ysics engine I've had to replace my <vec2> class and its useful l= ibrary of vector math functions with a bunch of raw <single-float>s i= n 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 un= boxed, stack allocated value types (and vectors of them allocated contiguou= sly) would be helpful.</div><div><br></div><div>-Andrew<br></div><div><br><= /div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed= , Sep 3, 2014 at 7:59 AM, Bruce Mitchener <span dir=3D"ltr"><<a href=3D"= mailto:[email protected]" target=3D"_blank">[email protected]= om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in: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't yet, but her= e's the next thread!<div><br></div><div>What do we all use or want to u= se Dylan for?</div><div><br></div><div>The idea here is to see what sort of= thing we might focus on, based on how we intend to use Dylan. Also, perhap= s enough of us are using it for similar things that we can get some sort of= cooperation going.</div> <div><br></div><div>We recognize that Dylan is a general purpose language a= nd don't plan to change that. But it might be well suited for certain t= ypes of applications, especially if we're able to improve the library c= overage some!</div> <div><br></div><div>Looking forward to hearing your thoughts!</div><span cl= ass=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>=C2=A0- Bruce</d= iv><div><br></div></font></span></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> --bcaec52d571909e13d0502927811-- --===============1129185878== 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 --===============1129185878==--