On Wed, Jun 19, 2013 at 7:36 PM, Marvin Humphrey <[email protected]> wrote: > On Wed, Jun 19, 2013 at 2:02 PM, Nick Wellnhofer <[email protected]> wrote: > Part of what's driving this line of development is that I've personally spent > a good part of the last year studying language implementation and other > low-level computer science topics and I'm circling back to see if any > of the new techniques I've learned suggest any improvements.
This is a great reason. > My take so far is that the original "inside-out vtable" concept turns out to > have been fundamentally sound, and that among Nick's vast contributions over > the last year have been fixes for what were the most glaring flaws in this > specific corner of the codebase (more optimal symbol export, linking > portability, etc.). Agree on all. > I think it's going to be hard to improve much more without a life-changing > architectural shift such as implementing a JIT. In the meantime, it's not a > huge amount of work to explore the short menu of options available to us given > our current constraints. (And it's super fun!) If we are treating this as blue sky, there are probably lots of ways to improve. Among others, the 'hash-table' approach that was brought up in the last discussion sounds plausible to me. Agree on the fun. >> I don't think that the uptake of Lucy has anything to do with complexity, >> actual or perceived. The critical factor, in my opinion, is that we only >> support Perl. I think it's both. The Perl folk are put off that everything is in C, and the C folk are scared by the Perl. And while I think it's a solid architecture, it has a strong 'accent' that can make it hard to understand at a glance. >> The good thing is that our architecture has been >> designed to support multiple host languages via Clownfish. Supporting other >> languages like Python or Ruby still means a lot of work, but I think we have >> made some considerable progress in that area. Agree. Getting the C interface working is a great step. >> My current focus is about making Clownfish a stand-alone and great product. >> And for Clownfish, solving the fragile ABI problem would be an incredibly >> important feature. You're right that there's not much direct benefit to >> Lucy. I agree with that mindset. As a standalone, it's a good problem to tackle, although I'd probably put detection of version incompatibility above it. I'm thinking particularly of a change of parameter type or order in a published method. >> The C library might spark some interest and I'd love to >> see a stand-alone Clownfish release on CPAN. Both true. I have some plans that might tie well to a late summer release. I'll describe in a followup. > However, I'd also say that having a small team working on Clownfish during > these early stages helps to keep focus. I'll be happy if more devs join > later, > but I'm happy now! Great! As long as it's being viewed as an enjoyable long-term process rather than a quick fix for Lucy. --nate
