Re: any benefit to throwing off lua51 constraints?

  • From: Szabó Antal <szabo.antal.92@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Fri, 12 Apr 2013 23:03:05 +0200

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.
>>> >
>>> >
>>
>>
>

Other related posts: