This topic interest me too, and I was wondering what a completely newly designed language + implementation (so it doesn't have any limitations or restrictions of existing languages) created by Mike would be like. I like to think it would be something even more awesome than LuaJIT :) (and probably this is ridiculous, and I just like to dream) 2013/4/12 Dan Eloff <dan.eloff@xxxxxxxxx>: > I agree Andrew, I also think that the confusion hurts adoption and that > lacking 5.2 compatibility will also cost LuaJIT (and maybe Lua as a whole) > some users. > > From what Mike has said in the past, A lot of serious companies use LuaJIT > and they shouldn't have to rewrite their code to adapt to the 5.2 breaking > changes. That makes sense to me. > > There already is a compile option to add more Lua 5.2 features to LuaJIT, > but I think it would be fantastic if it would mean full compatibility with > 5.2 instead of just cherry-picking some features. Even although as Mike has > said many times a lot of it is just window dressing, I think it's important > to maintain compatibility with Lua PUC to continue to grow the LuaJIT > community and also to avoid lockout. > > Some of that stuff is not really hardcore changes, e.g. the window dressing > functions, and people from the community could develop that and submit it as > a patch for Mike, if he agrees that it's the way to go. It seems too much > falls on his shoulders, in my opinion, and he could use some help. > > So as long as anything that breaks compatibility with 5.1 is only enabled > under the 5.2 compatibility compile option, then I'm all for it. > > > On Fri, Apr 12, 2013 at 10:53 AM, Andrew Starks <andrew.starks@xxxxxxxx> > wrote: >> >> On a more substantive note: >> >> >> I understand this conversation as one that says, "if we didn't care about >> backwards compatibility, then how could LuaJIT go forward in ways that it >> otherwise could not?" >> >> I took Mike's response as, "There are broken things in Lua, but these are >> not them." >> >> So, it is hard to understand if the reality is that A) extension isn't >> being hampered very much, or B) some extension is hard, but in ways that >> Mike thinks wise to keep private, at this time. >> >> I would agree that extension, especially when it does not replace existing >> facilities, is... zero calories and awesome and I'd love to see a list. >> >> My perspective is that of someone evangelizing Lua. To someone looking at >> options for the first time, it isn't clear on whether it's best to focus on >> the new 5.2 or go with the fast, 5.1 based LuaJIT. People on this list don't >> think it's much of a choice. But, it's been admitted that "your mileage may >> vary" and it's also hard to know which side of "vary" you're on. It's even >> harder to know if you ever will be on the "wrong" side of it. So, you might, >> "play it safe" and go with Lua. But the lure of speed and the FFI keep >> calling you... >> >> It may be my marketing experience talking here, but I observe that >> confusion is a killer for adoption, even just a little confusion. >> >> The incompatibilities between C-APIs is a huge PITA that will annoy >> developers and lock-in will mean that some libraries only work on LuaJIT. >> Lack of _ENV support, or really anything that's in Lua 5.2 that is not in >> LuaJIT, makes it exponentially difficult to grow Lua and move it forward. >> >> Because I believe these things (or as Homer said, "This things I >> believe...."), I really hold out hope for a reunification, at least on the >> language side of things and a return to the open admiration I enjoyed >> reading from the email archives. >> >> >> >> >> On Thu, Apr 11, 2013 at 11:29 PM, William Adams <william_a_adams@xxxxxxx> >> wrote: >>> >>> I guess it could be misconstrued as rude, harsh, etc. >>> >>> I've created plenty of things in my career that I've happy to see >>> evolve. For example, I was deeply involved in the emergence of >>> XML at Microsoft, and was very happy to see JSON/Rest win the day. >>> >>> And so it goes. >>> >>> I think this discussion has been all positive. No stones thrown, >>> and hopefully no feelings hurt. >>> >>> -- William >>> =============================== >>> - Shaping clay is easier than digging it out of the ground. >>> >>> >>> ________________________________ >>> > From: andrew.starks@xxxxxxxx >>> > Date: Thu, 11 Apr 2013 21:59:54 -0500 >>> > Subject: Re: any benefit to throwing off lua51 constraints? >>> > To: luajit@xxxxxxxxxxxxx >>> > >>> > Cool. I said my piece and I do appreciate that you and William put a >>> > finer point on your posts. >>> > >>> > I read them and can't help but think about how I'd feel, having done >>> > the hard work of making a language and then to have someone call it >>> > behind, obsolete, vanilla, etc. >>> > >>> > I wouldn't want my baby called ugly and now I know that you did not >>> > intend to do that to the PUC/RIO team. Perhaps they, Mike and you are >>> > of a level in this industry where such evaluations are normal and I >>> > should read them differently than how I am and just watch the show. >>> > >>> > Thank you. >>> > >>> > -Andrew >>> > >>> > >>> > On Thu, Apr 11, 2013 at 6:48 PM, Dan Eloff >>> > <dan.eloff@xxxxxxxxx<mailto:dan.eloff@xxxxxxxxx>> wrote: >>> > @Andrew please don't mistake me as saying that we should stop caring >>> > about Lua compatibility, far from it, I think it's essential for LuaJIT >>> > in continuing to gain in popularity. But at the same time I also can >>> > see a likely day when Lua PUC is irrelevant. We're a long way from >>> > there, but it's not inconceivable. Better tools win out over the >>> > long-haul and I think LuaJIT is a better tool. That opinion may not be >>> > representative of developers at large, in which case that future won't >>> > come to pass. I am definitely not saying that Lua has brought nothing >>> > of value to the table, or will not continue to do so (I thought goto in >>> > 5.2 was a rather nice idea.) As you say, without Lua there would be no >>> > LuaJIT. >>> > >>> > However, for example, if Mike felt it was worthwhile to abandon the Lua >>> > debug api for a more LuaJIT friendly one, we're probably at a point >>> > where it would not overly hurt LuaJIT adoption, and it's possible the >>> > gains would be worth it. >>> > >>> > @Josh string operations are slow in LuaJIT right now. Most of the time >>> > it doesn't matter much, because if you really want string performance >>> > you can use the ffi and character arrays and get near native >>> > performance. String operations could be improved, for example, you'll >>> > note string concatenation with .. causes the JIT to punt at the moment, >>> > add the -jv flag when running LuaJIT on your program to see.) But they >>> > can never be as fast as using character buffers. It's the usual >>> > tradeoff of how fast is fast enough and how willing you are to trade >>> > complexity of code for speed of execution. >>> > >>> > Cheers, >>> > Dan >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > On Thu, Apr 11, 2013 at 6:09 PM, William Adams >>> > <william_a_adams@xxxxxxx<mailto:william_a_adams@xxxxxxx>> wrote: >>> > And by the way, in case people believe I am somehow denouncing previous >>> > work, and pushing Mike as the sole genius of the Lua world, nothing >>> > could be further from the truth. >>> > >>> > I believe the original Lua work represents true genius. I love the >>> > simplicity and elegance of the core language, and do not really wish to >>> > add a ton of "features" to it. >>> > >>> > I am just posing the question and challenging the community as I >>> > challenge myself, to think about how Lua/JIT can evolve from this point >>> > forward. >>> > >>> > -- William >>> > =============================== >>> > - Shaping clay is easier than digging it out of the ground. >>> > >>> > >> >> >