[dylan] Announcing Project Mindy
Bruce Mitchener <[email protected]> Tue, 6 Oct 2015 08:51:15 +0700
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <CA+esKjNF_8_kERzw2ikFUf-SQasUeqGhV+UCsPN+d9Kave9R6Q@mail.gmail.com> |
--===============0509816916== Content-Type: multipart/alternative; boundary=047d7bdca2f88baf29052165ddd6 --047d7bdca2f88baf29052165ddd6 Content-Type: text/plain; charset=UTF-8 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 --047d7bdca2f88baf29052165ddd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><blockquote style=3D"margin:0px 0px 0px 40px;border:n= one;padding:0px"><div>Mindy: Modern. Beautiful. Fun.</div><div>An implement= ation of a language bearing a striking resemblance=C2=A0to Dylan.</div></bl= ockquote><br></div>I've had some conversations with people off and on o= ver the last couple of years about Dylan, complexity, ease of entry and man= y other topics.<div><br></div><div>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 projec= t going with Open Dylan isn't terribly easy either. There's overhea= d 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 bootstrappi= ng requirements).</div><div><br></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 definitely doesn't come with a low barrier to= entry.</div><div><br></div><div>Last year, during the fogs of depression, = I had a talk with Krishna about Mindy, the original bytecode compiler and i= nterpreter from CMU. I apparently went on to mostly forget about this conve= rsation.</div><div><br></div><div>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:</div><div><br></div><di= v><ul><li><a href=3D"https://news.ycombinator.com/item?id=3D5219533">https:= //news.ycombinator.com/item?id=3D5219533</a><br></li><li><a href=3D"https:/= /news.ycombinator.com/item?id=3D3340419">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" style=3D= "margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2= 04,204);border-left-style:solid;padding-left:1ex">These were all done with = "mindy", the CMU dylan interpreter. It was a byte code compiled i= nterpreter, but its compiler was so fast you never noticed the "make&q= uot;. Very fast startup time on the executables as well. You would need a s= topwatch with milliseconds to tell the workflow from a "edit-run-repea= t" scripting language. Mindy was later abandoned because it didn't= have macros and it was deemed too much work to add it.</blockquote><div><b= r></div><div>and:</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg= b(204,204,204);border-left-style:solid;padding-left:1ex">Ah yes, you say, b= ut 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 t= he mid '90s. 32MB RAM in a 66MHz i386. What we lost in CPU efficiency w= e 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 s= ites to see if there was a new "init" to compile for your Linux m= achine since distributions weren't really invented yet), g++ had a 1 in= the first version digit. If C++ had templates, they were so ludicrously bl= oated that you couldn't afford the RAM to use them. egcs hadn't for= ked then eventually killed the abomination that gcc 1 had become. With Mind= y our builds were instantaneous and it ran pretty well too. Even the "= stop the world and copy everything" garbage collector worked well in o= ur GUI programs once we figured out to detect and force impending collectio= ns at times when the user wouldn't notice, like right after they select= ed a menu item, rather than letting the GC trigger automatically in the mid= dle of a button draw.</blockquote><div><br></div><div>This sounds like the = sort of system that might be an interesting alternative view of things.</di= v><div><br></div><div>In the past, I was against the idea of trying to supp= ort and maintain both Gwydion Dylan's d2c and Open Dylan. Both are larg= e, complex systems that are trying to do the same thing: produce efficient = code that is fully optimized.</div><div><br></div><div>What I didn't th= ink 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.</d= iv><div><br></div><div>Mindy provides:</div><div><br></div><div><ul><li>A f= ull system written in C and libraries in Dylan.<br></li><li>That system com= piles in a matter of seconds, from scratch, on a machine without an existin= g Dylan compiler. There is no complicated bootstrap.</li><li>Compilation of= Dylan code is fast.</li><li>User-space green threads.</li><li>Built-in sou= rce level debugger that just works.</li><li>Very simple to use and integrat= e with other build systems. (We're building it with cmake and ninja, a = make replacement.)</li><li>Embeddable. The C library is fairly small and no= rmal 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 perfec= t. 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 checking.<= br></li><li>The libraries are out of date with respect to what's includ= ed in Open Dylan.<br></li></ul></div><div>At any rate, I feel like experime= nting with Mindy and possibly building further with it is a noble, interest= ing endeavor.=C2=A0 I figured that since we're experimenting with somet= hing new here, we could experiment in other ways as well.</div><div><br></d= iv><div><ul><li>Using Travis CI for builds and running tests. This isn'= t ideal (test result reporting is poor), but it is very quick. I'll pro= bably still set up Jenkins builds though.<br></li><li>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.<br></li></ul></div><div><br></div><div>I've also established a = new GitHub organization and repository for Mindy: <a href=3D"https://github= .com/project-mindy/mindy/">https://github.com/project-mindy/mindy/</a>.=C2= =A0 I'd like to give Mindy some space to move around, grow and breathe.= </div><div><br></div><div>I'll write another post another day about wha= t I see as some possible future directions for Project 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 implementation of a lang= uage bearing a striking resemblance=C2=A0to Dylan.</div></blockquote><div><= br>=C2=A0- Bruce</div><div><br></div></div> --047d7bdca2f88baf29052165ddd6-- --===============0509816916== 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 --===============0509816916==--