Re: [dylan] Announcing Project Mindy
Bruce Hoult <[email protected]> Tue, 6 Oct 2015 14:09:53 +0300
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CAMU+Ekw-ksOFF22ij7CSH4uHGPbJ--cnpQtS7WmTU-hbsW8k1g@mail.gmail.com> |
--===============2077468630== Content-Type: multipart/alternative; boundary=001a11c262bc5f5ae805216dabf4 --001a11c262bc5f5ae805216dabf4 Content-Type: text/plain; charset=UTF-8 Yes, there's a lot to be said for experimenting in a system like Mindy. I've never used it much (outside of bootstrapping d2c) but I used to do a lot of prototyping of code in Marlais. For real work, lack of macros is a bit of a show-stopper for me. Maybe they could be added on as a source-to-source transformer that happens before Mindy? d2c itself has a lot of the same advantages. Lack of debugging is the only real disadvantage. But then you get C-like speed (STILL better than OpenDylan I think) On Tue, Oct 6, 2015 at 4:51 AM, Bruce Mitchener <[email protected]> wrote: > Mindy: Modern. Beautiful. Fun. > An implementation of a language bearing a striking resemblance to Dylan. > > > I've had some conversations with people off and on over the last couple of > years about Dylan, complexity, ease of entry and many other topics. > > One repeating and obvious theme has been that people find Open Dylan too > intimidating and too large to just jump in and start working on something. > Coupled with that is that getting a project going with Open Dylan isn't > terribly easy either. There's overhead to getting a working and up to date > install of Open Dylan and it isn't something that all package systems want > to accept (due to the bootstrapping requirements). > > There were other issues as well. Even with all of the progress that has > been made on debugging, it isn't an ideal experience and definitely doesn't > come with a low barrier to entry. > > Last year, during the fogs of depression, I had a talk with Krishna about > Mindy, the original bytecode compiler and interpreter from CMU. I > apparently went on to mostly forget about this conversation. > > Thankfully, it came up again this year a couple of weeks ago. During the > course of these discussions, he re-pointed me at some posts by jws (Jim > Studt) on Hacker News: > > > - https://news.ycombinator.com/item?id=5219533 > - https://news.ycombinator.com/item?id=3340419 > > > Some excerpts from those posts: > > These were all done with "mindy", the CMU dylan interpreter. It was a byte >> code compiled interpreter, but its compiler was so fast you never noticed >> the "make". Very fast startup time on the executables as well. You would >> need a stopwatch with milliseconds to tell the workflow from a >> "edit-run-repeat" scripting language. Mindy was later abandoned because it >> didn't have macros and it was deemed too much work to add it. > > > and: > > >> Ah yes, you say, but how do you do eval and all those Lisp macro things >> from a Pascal syntax? We didn't. While many smart people struggled to make >> spectacular Dylan compilers, we happily used Mindy, the tiny byte code >> interpreter. It was the mid '90s. 32MB RAM in a 66MHz i386. What we lost in >> CPU efficiency we picked back up in memory footprint. In those days you did >> something else while building your software, (not surf the web of course, >> maybe poll ftp sites to see if there was a new "init" to compile for your >> Linux machine since distributions weren't really invented yet), g++ had a 1 >> in the first version digit. If C++ had templates, they were so ludicrously >> bloated that you couldn't afford the RAM to use them. egcs hadn't forked >> then eventually killed the abomination that gcc 1 had become. With Mindy >> our builds were instantaneous and it ran pretty well too. Even the "stop >> the world and copy everything" garbage collector worked well in our GUI >> programs once we figured out to detect and force impending collections at >> times when the user wouldn't notice, like right after they selected a menu >> item, rather than letting the GC trigger automatically in the middle of a >> button draw. > > > This sounds like the sort of system that might be an interesting > alternative view of things. > > In the past, I was against the idea of trying to support and maintain both > Gwydion Dylan's d2c and Open Dylan. Both are large, complex systems that > are trying to do the same thing: produce efficient code that is fully > optimized. > > What I didn't think about at that time, I guess, is that there's a role > for a different compiler / runtime with a vastly different focus. I think > Mindy might make a good basis for that. And there's only one way to really > find out. > > Mindy provides: > > > - A full system written in C and libraries in Dylan. > - That system compiles in a matter of seconds, from scratch, on a > machine without an existing Dylan compiler. There is no complicated > bootstrap. > - Compilation of Dylan code is fast. > - User-space green threads. > - Built-in source level debugger that just works. > - Very simple to use and integrate with other build systems. (We're > building it with cmake and ninja, a make replacement.) > - Embeddable. The C library is fairly small and normal C. > - It can run on a Rump Kernel without a traditional OS under it. > > This isn't to say (by any means) that Mindy is perfect. It isn't. > > > - No macros. > - No limited collections. > - Very little compile time checking. > - The libraries are out of date with respect to what's included in > Open Dylan. > > At any rate, I feel like experimenting with Mindy and possibly building > further with it is a noble, interesting endeavor. I figured that since > we're experimenting with something new here, we could experiment in other > ways as well. > > > - Using Travis CI for builds and running tests. This isn't ideal (test > result reporting is poor), but it is very quick. I'll probably still set up > Jenkins builds though. > - Trying out Gitter, a Slack-like chat system. I think it would be > interesting to try out Zulip in this space as well, especially since Zulip > is open source and can be self-hosted. > > > I've also established a new GitHub organization and repository for Mindy: > https://github.com/project-mindy/mindy/. I'd like to give Mindy some > space to move around, grow and breathe. > > I'll write another post another day about what I see as some possible > future directions for Project Mindy. > > Mindy: Modern. Beautiful. Fun. > An implementation of a language bearing a striking resemblance to Dylan. > > > - Bruce > > > _______________________________________________ > hackers mailing list > [email protected] > https://lists.opendylan.org/mailman/listinfo/hackers > > --001a11c262bc5f5ae805216dabf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Yes, there's a lot to be said for experimenting in a s= ystem like Mindy. I've never used it much (outside of bootstrapping d2c= ) but I used to do a lot of prototyping of code in Marlais.<div><br></div><= div>For real work, lack of macros is a bit of a show-stopper for me. Maybe = they could be added on as a source-to-source transformer that happens befor= e Mindy?</div><div><br></div><div>d2c itself has a lot of the same advantag= es. Lack of debugging is the only real disadvantage. But then you get C-lik= e speed (STILL better than OpenDylan I think)</div><div><br></div></div><di= v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Oct 6, 2015 = at 4:51 AM, Bruce Mitchener <span dir=3D"ltr"><<a href=3D"mailto:bruce.m= [email protected]" target=3D"_blank">[email protected]</a>></sp= an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><blockqu= ote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px"><div>Mindy: M= odern. Beautiful. Fun.</div><div>An implementation of a language bearing a = striking resemblance=C2=A0to Dylan.</div></blockquote><br></div>I've ha= d some conversations with people off and on over the last couple of years a= bout Dylan, complexity, ease of entry and many other topics.<div><br></div>= <div>One repeating and obvious theme has been that people find Open Dylan t= oo intimidating and too large to just jump in and start working on somethin= g. Coupled with that is that getting a project going with Open Dylan isn= 9;t terribly easy either. There's overhead to getting a working and up = to date install of Open Dylan and it isn't something that all package s= ystems want to accept (due to the bootstrapping requirements).</div><div><b= r></div><div>There were other issues as well. Even with all of the progress= that has been made on debugging, it isn't an ideal experience and defi= nitely doesn't come with a low barrier to entry.</div><div><br></div><d= iv>Last year, during the fogs of depression, I had a talk with Krishna abou= t Mindy, the original bytecode compiler and interpreter from CMU. I apparen= tly went on to mostly forget about this conversation.</div><div><br></div><= div>Thankfully, it came up again this year a couple of weeks ago. During th= e course of these discussions, he re-pointed me at some posts by jws (Jim S= tudt) on Hacker News:</div><div><br></div><div><ul><li><a href=3D"https://n= ews.ycombinator.com/item?id=3D5219533" target=3D"_blank">https://news.ycomb= inator.com/item?id=3D5219533</a><br></li><li><a href=3D"https://news.ycombi= nator.com/item?id=3D3340419" target=3D"_blank">https://news.ycombinator.com= /item?id=3D3340419</a><br></li></ul></div><div><br></div><div>Some excerpts= from those posts:</div><div><br></div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb= (204,204,204);border-left-style:solid;padding-left:1ex">These were all done= with "mindy", the CMU dylan interpreter. It was a byte code comp= iled interpreter, but its compiler was so fast you never noticed the "= make". Very fast startup time on the executables as well. You would ne= ed a stopwatch with milliseconds to tell the workflow from a "edit-run= -repeat" scripting language. Mindy was later abandoned because it didn= 't have macros and it was deemed too much work to add it.</blockquote><= div><br></div><div>and:</div><div>=C2=A0</div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co= lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Ah yes, you = say, but how do you do eval and all those Lisp macro things from a Pascal s= yntax? We didn't. While many smart people struggled to make spectacular= Dylan compilers, we happily used Mindy, the tiny byte code interpreter. It= was the mid '90s. 32MB RAM in a 66MHz i386. What we lost in CPU effici= ency we picked back up in memory footprint. In those days you did something= else while building your software, (not surf the web of course, maybe poll= ftp sites to see if there was a new "init" to compile for your L= inux machine since distributions weren't really invented yet), g++ had = a 1 in the first version digit. If C++ had templates, they were so ludicrou= sly bloated that you couldn't afford the RAM to use them. egcs hadn'= ;t forked then eventually killed the abomination that gcc 1 had become. Wit= h Mindy our builds were instantaneous and it ran pretty well too. Even the = "stop the world and copy everything" garbage collector worked wel= l in our GUI programs once we figured out to detect and force impending col= lections at times when the user wouldn't notice, like right after they = selected a menu item, rather than letting the GC trigger automatically in t= he middle of a button draw.</blockquote><div><br></div><div>This sounds lik= e the sort of system that might be an interesting alternative view of thing= s.</div><div><br></div><div>In the past, I was against the idea of trying t= o support and maintain both Gwydion Dylan's d2c and Open Dylan. Both ar= e large, complex systems that are trying to do the same thing: produce effi= cient code that is fully optimized.</div><div><br></div><div>What I didn= 9;t think about at that time, I guess, is that there's a role for a dif= ferent compiler / runtime with a vastly different focus. I think Mindy migh= t make a good basis for that. And there's only one way to really find o= ut.</div><div><br></div><div>Mindy provides:</div><div><br></div><div><ul><= li>A full system written in C and libraries in Dylan.<br></li><li>That syst= em compiles in a matter of seconds, from scratch, on a machine without an e= xisting Dylan compiler. There is no complicated bootstrap.</li><li>Compilat= ion of Dylan code is fast.</li><li>User-space green threads.</li><li>Built-= in source level debugger that just works.</li><li>Very simple to use and in= tegrate with other build systems. (We're building it with cmake and nin= ja, a make replacement.)</li><li>Embeddable. The C library is fairly small = and normal C.</li><li>It can run on a Rump Kernel without a traditional OS = under it.</li></ul><div>This isn't to say (by any means) that Mindy is = perfect. It isn't.</div></div><div><br></div><div><ul><li>No macros.<br= ></li><li>No limited collections.<br></li><li>Very little compile time chec= king.<br></li><li>The libraries are out of date with respect to what's = included in Open Dylan.<br></li></ul></div><div>At any rate, I feel like ex= perimenting with Mindy and possibly building further with it is a noble, in= teresting endeavor.=C2=A0 I figured that since we're experimenting with= something new here, we could experiment in other ways as well.</div><div><= br></div><div><ul><li>Using Travis CI for builds and running tests. This is= n't ideal (test result reporting is poor), but it is very quick. I'= ll probably still set up Jenkins builds though.<br></li><li>Trying out Gitt= er, a Slack-like chat system. I think it would be interesting to try out Zu= lip in this space as well, especially since Zulip is open source and can be= self-hosted.<br></li></ul></div><div><br></div><div>I've also establis= hed a new GitHub organization and repository for Mindy: <a href=3D"https://= github.com/project-mindy/mindy/" target=3D"_blank">https://github.com/proje= ct-mindy/mindy/</a>.=C2=A0 I'd like to give Mindy some space to move ar= ound, grow and breathe.</div><div><br></div><div>I'll write another pos= t another day about what I see as some possible future directions for Proje= ct Mindy.</div><div><br></div><blockquote style=3D"margin:0px 0px 0px 40px;= border:none;padding:0px"><div>Mindy: Modern. Beautiful. Fun.</div><div>An i= mplementation of a language bearing a striking resemblance=C2=A0to Dylan.</= div></blockquote><span class=3D"HOEnZb"><font color=3D"#888888"><div><br>= =C2=A0- Bruce</div><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" rel=3D"nor= eferrer" target=3D"_blank">https://lists.opendylan.org/mailman/listinfo/hac= kers</a><br> <br></blockquote></div><br></div> --001a11c262bc5f5ae805216dabf4-- --===============2077468630== 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 --===============2077468630==--