Re: any benefit to throwing off lua51 constraints?
- From: Andrew Starks <andrew.starks@xxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 12 Apr 2013 10:53:53 -0500
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:
