TechRepublic article about languages to avoid in 2018

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Pierre-Yves Gérardy
Indeed, for more details look at the luaffi known issues [0]:

Specifically these two points at least diverge from Lua 5.1 semantics
and can't be worked around:

- Comparing a ctype pointer to nil doesn't work the same as luajit.
This is unfixable with the current metamethod semantics. Instead use
ffi.C.NULL
- Not all metamethods work with lua 5.1 (eg char* + number). This is
due to the way metamethods are looked up with mixed types in Lua 5.1.
If you need this upgrade to Lua 5.2 or use boxed numbers (uint64_t and
uintptr_t).

—Pierre-Yves

0. https://github.com/jmckaskill/luaffi#known-issues

On Fri, Mar 9, 2018 at 10:35 AM, Soni "They/Them" L. <[hidden email]> wrote:

>
>
> On 2018-03-09 06:23 AM, Pierre Chapuis wrote:
>>
>> On Thu, Mar 8, 2018, at 22:13, Soni They/Them L. wrote:
>>
>>> You can implement bitops in pure Lua.
>>>
>>> I challenge you to implement FFI in pure Lua.
>>
>> It is a library to interact with the outside world.
>> You can say the same of LuaPosix, LuaSocket, LuaFilesystem...
>>
>
> Hmm...
>
> I mean those were explicitly designed as independent Lua modules, I guess.
>
> The FFI was designed to integrate with the language.
>
>
> --
> Disclaimer: these emails may be made public at any given time, with or
> without reason. If you don't agree with this, DO NOT REPLY.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Roberto Ierusalimschy
In reply to this post by Dibyendu Majumdar
> > luaffi is not a serious option, and cannot be; the whole philosophy of
> > FFI demands a compiler. FFI is what made LuaJIT definitively a fork of
> > Lua.
> >
>
> Did you mean that luaffi is not a serious option for inclusion in Lua
> (because it is not ANSI C etc.)?

By "option" I meant that luaffi is not a real alternative to ffi
in LuaJIT. The use of ffi in LuaJIT makes programs much faster
(when compiled), while the use of luaffi in Lua makes programs much
slower. That is not a fault of luaffi; at most it is a fault of C.


> LuaJIT's ffi is a library and I am not sure why the inclusion of a
> library should cause LuaJIT to be classed as a 'fork' - although
> 'fork' is problematic word in my view anyway.

ffi in LuaJIT is not a library.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Dibyendu Majumdar
On 9 March 2018 at 14:09, Roberto Ierusalimschy <[hidden email]> wrote:

>> > luaffi is not a serious option, and cannot be; the whole philosophy of
>> > FFI demands a compiler. FFI is what made LuaJIT definitively a fork of
>> > Lua.
>> >
>>
>> Did you mean that luaffi is not a serious option for inclusion in Lua
>> (because it is not ANSI C etc.)?
>
> By "option" I meant that luaffi is not a real alternative to ffi
> in LuaJIT. The use of ffi in LuaJIT makes programs much faster
> (when compiled), while the use of luaffi in Lua makes programs much
> slower. That is not a fault of luaffi; at most it is a fault of C.
>

I haven't benchmarked against the standard Lua C api - are you saying
it is slower than that?

LuaJIT's ffi of course has a performance angle to it - but an ffi
interface is also just a convenient way to invoke external code; so
performance is not necessarily the main factor when using luaffi with
Lua which doesn't have a JIT.

>
>> LuaJIT's ffi is a library and I am not sure why the inclusion of a
>> library should cause LuaJIT to be classed as a 'fork' - although
>> 'fork' is problematic word in my view anyway.
>
> ffi in LuaJIT is not a library.
>

It is certainly classed as a Library by LuaJIT, and behaves like one -
i.e. it is not part of the language. Of course it is deeply integrated
to get better performance but that doesn't necessarily take away from
its nature. I believe it is also optional.

Anyone using ffi is writing code that cannot be run in Lua of course,
but that is where luaffi comes in.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Dibyendu Majumdar
In reply to this post by Pierre Chapuis
On 7 March 2018 at 15:23, Pierre Chapuis <[hidden email]> wrote:

> On Tue, Mar 6, 2018, at 04:34, Mason Bogue wrote:
>
>> The trouble is that the Lua ecosystem has become so fragmented after
>> 5.1. The changes in 5.2/5.3 seem to have been very unpopular and split
>> people among three versions.
>
> For the most part they were not unpopular with users, they were
> unpopular with the LuaJIT implementer. At the time of 5.2 I suppose
> the extent to which this would become a problem was not well
> understood.
>

I think the stand taken by Mike Pall to not break ABI compatibility is
a reasonable one. This is the fundamental building block of so much
code in the world; people rely on this day in day out. I fear a
failure to understand how important this is one of the mistakes in
Lua.

> I think it's more likely that it was when LuaJIT was maintained by
> a single person. I don't keep my hopes up though.
>

I think you are mistaken. In fact, Lua is maintained by one man
(Roberto) whereas LuaJIT has regular and sometimes large contributions
from external contributors. Mike Pall also appears to fix any bugs
very quickly. If he is not spending a lot of time enhancing LuaJIT,
that is not necessarily a problem as it is a mature product.

> Here is a scenario I think could happen though: LuaJIT dies for
> lack of proper maintenance and one of its forks (e.g. RaptorJIT)
> rises from its ashes, with a maintainer who cares about this issue.
>

I think this is wishful thinking as LuaJIT is probably not going away
anywhere soon.


Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Dirk Laurie-2
2018-03-09 22:53 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>
> I think you are mistaken. In fact, Lua is maintained by one man
> (Roberto) whereas LuaJIT has regular and sometimes large contributions
> from external contributors.

The nature of collaboration is often such that the tip of the iceberg
looks like one person only.

May I recommend the book "Masterminds of Programming" by Federico
Biancuzzi and Shane Warden (O'Reilly 2009, e-book available) which
inter alia features an interview with Roberto and Luiz, from which
I'll quote one paragraph.

Interviewer: How do you share development responsibilities—in
particular, writing code?

Luiz: The first versions of Lua were coded by Waldemar in 1993. Since
around 1995, Roberto has written and maintained the bulk of the code.
I’m responsible for a small part of the code: the bytecode dump/undump
modules and the standalone compiler, luac. We have always done code
revisions and sent suggestions by email to the others about changes to
the code, and we have long meetings about new features and their
implementation.

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Lorenzo Donati-3
On 10/03/2018 07:33, Dirk Laurie wrote:

> 2018-03-09 22:53 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>>
>> I think you are mistaken. In fact, Lua is maintained by one man
>> (Roberto) whereas LuaJIT has regular and sometimes large contributions
>> from external contributors.
>
> The nature of collaboration is often such that the tip of the iceberg
> looks like one person only.
>
> May I recommend the book "Masterminds of Programming" by Federico
> Biancuzzi and Shane Warden (O'Reilly 2009, e-book available) which
> inter alia features an interview with Roberto and Luiz, from which
> I'll quote one paragraph.
>
> Interviewer: How do you share development responsibilities—in
> particular, writing code?
>
> Luiz: The first versions of Lua were coded by Waldemar in 1993. Since
> around 1995, Roberto has written and maintained the bulk of the code.
> I’m responsible for a small part of the code: the bytecode dump/undump
> modules and the standalone compiler, luac. We have always done code
> revisions and sent suggestions by email to the others about changes to
> the code, and we have long meetings about new features and their
> implementation.
>
>
Well, according to lua-l activity and (IIRC) what Roberto and Luiz said
, Waldemar hasn't been involved in Lua for years now. Then there are two
of them.

OK, it is not a one-man effort, but two-men (but that citation again
states that Robert is responsible for the bulk of the code).

This doesn't change the gist of what Dibyendu said. *Most* of Lua is
maintained by one man (and development in general is done by two).

Unless there are "unnamed" contributors we don't know of (occasional
Roberto's or Luiz' PhD students?), Dibyendu is substantially right.

cheers!

-- Lorenzo


Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Luiz Henrique de Figueiredo
> Well, according to lua-l activity and (IIRC) what Roberto and Luiz said ,
> Waldemar hasn't been involved in Lua for years now. Then there are two of
> them.

That is definitely not true.
Waldemar is very much involved in Lua.
All three of us are directly involved in the design of Lua.

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Lorenzo Donati-3
On 10/03/2018 11:58, Luiz Henrique de Figueiredo wrote:
>> Well, according to lua-l activity and (IIRC) what Roberto and Luiz said ,
>> Waldemar hasn't been involved in Lua for years now. Then there are two of
>> them.
>
> That is definitely not true.
> Waldemar is very much involved in Lua.
> All three of us are directly involved in the design of Lua.
>
>
Happy to hear that!

The fact that Waldemar hasn't posted any message on lua-l for at least
the last 6-7 years (I don't remember having seen one in all that time -
I stand to be corrected) together with your statement that only you and
Roberto actively develop Lua led me to think Waldemar has left active
Lua development.

Cheers!

-- Lorenzo

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Dirk Laurie-2
2018-03-10 13:54 GMT+02:00 Lorenzo Donati <[hidden email]>:

> The fact that Waldemar hasn't posted any message on lua-l for at least the
> last 6-7 years (I don't remember having seen one in all that time -
> I stand to be corrected) together with your statement that only you and
> Roberto actively develop Lua led me to think Waldemar has left active Lua
> development.

The surface is calmest where the river runs deepest.

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

dyngeccetor8
In reply to this post by Lorenzo Donati-3
On 03/10/2018 01:41 PM, Lorenzo Donati wrote:
> This doesn't change the gist of what Dibyendu said. *Most* of Lua is maintained
> by one man (and development in general is done by two).

Is it considered harmful?

I think it's interest field of research: is there any correlation
between number of contributors and language appreciation by
community?

(We should try to exclude attempts to force usage from corporations
(like Oracle PL/SQL).)

FORTRAN, ALGOL, LISP, SNOBOL, C, QBASIC, Pascal, Lua, Perl, Python, Go.

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Dibyendu Majumdar
On 10 March 2018 at 23:04, dyngeccetor8 <[hidden email]> wrote:
> On 03/10/2018 01:41 PM, Lorenzo Donati wrote:
>> This doesn't change the gist of what Dibyendu said. *Most* of Lua is maintained
>> by one man (and development in general is done by two).
>
> Is it considered harmful?
>

I don't think it is harmful in the case of Lua language, as the
implementation is small enough for one person to manage, and Roberto
has a strong vision of what Lua is, so that there is a coherence in
the implementation. It is also a beautiful implementation.

On the other hand, I think this model is harmful for the 'batteries'
part - which could easily be improved by allowing external
contributors.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Gregg Reynolds-2
In reply to this post by dyngeccetor8


On Sat, Mar 10, 2018 at 5:04 PM, dyngeccetor8 <[hidden email]> wrote:
On 03/10/2018 01:41 PM, Lorenzo Donati wrote:
> This doesn't change the gist of what Dibyendu said. *Most* of Lua is maintained
> by one man (and development in general is done by two).

Is it considered harmful?

In my experience, most of the best software is maintained by a very small group of people. SQLite, one guy. Linux. Clojure. Etc.

I think it's interest field of research: is there any correlation
between number of contributors and language appreciation by
community?

"Contributors" is a whole 'nother issue. My guess is that Lua, like most successful open-source projects, has a bunch of them.

-gregg

Reply | Threaded
Open this post in threaded view
|

Re: TechRepublic article about languages to avoid in 2018

Dibyendu Majumdar
In reply to this post by Lorenzo Donati-3
On 10 March 2018 at 10:41, Lorenzo Donati <[hidden email]> wrote:

> On 10/03/2018 07:33, Dirk Laurie wrote:
>>
>> 2018-03-09 22:53 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>>>
>>>
>>> I think you are mistaken. In fact, Lua is maintained by one man
>>> (Roberto) whereas LuaJIT has regular and sometimes large contributions
>>> from external contributors.
>>
>>
>> May I recommend the book "Masterminds of Programming" by Federico
>> Biancuzzi and Shane Warden (O'Reilly 2009, e-book available) which
>> inter alia features an interview with Roberto and Luiz, from which
>> I'll quote one paragraph.
>>
>> Interviewer: How do you share development responsibilities—in
>> particular, writing code?
>>
>> Luiz: The first versions of Lua were coded by Waldemar in 1993. Since
>> around 1995, Roberto has written and maintained the bulk of the code.
>> I’m responsible for a small part of the code: the bytecode dump/undump
>> modules and the standalone compiler, luac. We have always done code
>> revisions and sent suggestions by email to the others about changes to
>> the code, and we have long meetings about new features and their
>> implementation.
>>
>>
> This doesn't change the gist of what Dibyendu said. *Most* of Lua is
> maintained by one man (and development in general is done by two).
>

Okay here is my understanding.

Roberto pretty much is the sole developer of pretty much all of Lua
except the two bits mentioned above - don't believe that has changed
since 1995. You can do the maths in terms of percentage share.

Roberto maintains the bug list I think.

Luiz maintains the website, mailing list etc. Also the luac tool and
the dump/undump features in Lua, as mentioned above.

I don't believe any code is taken from anyone not even students.

I only pointed this out as folks comparing Lua and LuaJIT often
complain how LuaJIT is a one man show etc etc. In fact the two
projects are entirely similarly run when it comes to the core
codebase, with LuaJIT recently taking more external contributions.

Regards
Dibyendu

12