Simon Cozens
2015-07-14 14:17:34 UTC
Hello!
I maintain SILE, which is quite a large, complex application written in
Lua. Because it's an application, I can't control which versions of Lua
its end-users will be using, so we have to support a range of
environments. At the moment we have support for 5.1, 5.2 and I have
recently added support for 5.3.
If I was starting again, though, I would probably not use Lua.
When 5.3 came out, SILE stopped working for users who had upgraded. Not
only SILE's code directly, but code that SILE was using indirectly
through libraries and luarocks simply stopped working and started giving
errors. I don't think this is a great state of affairs.
In particular, one of the changes in 5.3 was that the core "unpack()"
function for handling variable arguments was removed. You might argue
that it was moved to table.unpack, but that's irrelevant: the end result
from a user's perspective was "attempt to call a nil value (global
'unpack')".
A backwards-incompatible change that breaks end-user code is the sort of
thing that probably should be documented, perhaps in the changelog. The
changelog says that "the reference manual lists the incompatibilities
that had to be introduced". Perhaps it was an oversight, but there's no
mention in chapter 8 of the reference manual that a core function was
incompatibly removed. In the changelog, it lists "functions for packing
and unpacking values" under "main changes", but that's as much detail as
you get.
I had to hunt around to find out what was going on, because I didn't
expect built-in functions to silently disappear, and passing variable
arguments to a function is a pretty key thing to suddenly vanish without
trace or documentation.
One more thing: from an application writer's perspective, having
backward-compatibility options available in luaconf.h makes things a
whole lot worse, not better. Because now you have to write code for two
possible platforms, both calling themselves Lua 5.3, but actually with
different and incompatible functionality. What could possibly go wrong?
I know that Lua is an evolving language and I don't think you should
never be able to make any core changes ever. But at the least, could we
please have a deprecation cycle with warnings that code needs to be
updated, rather than unceremoniously breaking end-user code?
Could we also please have a commitment to full documentation of
incompatible changes, with explanation of what needs to be done to older
code to make it work?
And please, can we think about the impact on third-party code of
shifting things around in the core? To make a Lua application
compatible across Lua versions, I have to stuff my code with lines like
unpack = unpack or table.unpack
That's not a hard thing. Lua could actually do that for me, but now I
have to do it. In other words, making code backwards-compatible in Lua
is a burden, and the burden is being placed on the developer, not on the
language. I don't think that's not a good state of affairs either.
Knowing that, when 5.4 comes out, my code is probably going to stop
working again, through no fault of my own, does not really fill me with
confidence or joy.
Simon
I maintain SILE, which is quite a large, complex application written in
Lua. Because it's an application, I can't control which versions of Lua
its end-users will be using, so we have to support a range of
environments. At the moment we have support for 5.1, 5.2 and I have
recently added support for 5.3.
If I was starting again, though, I would probably not use Lua.
When 5.3 came out, SILE stopped working for users who had upgraded. Not
only SILE's code directly, but code that SILE was using indirectly
through libraries and luarocks simply stopped working and started giving
errors. I don't think this is a great state of affairs.
In particular, one of the changes in 5.3 was that the core "unpack()"
function for handling variable arguments was removed. You might argue
that it was moved to table.unpack, but that's irrelevant: the end result
from a user's perspective was "attempt to call a nil value (global
'unpack')".
A backwards-incompatible change that breaks end-user code is the sort of
thing that probably should be documented, perhaps in the changelog. The
changelog says that "the reference manual lists the incompatibilities
that had to be introduced". Perhaps it was an oversight, but there's no
mention in chapter 8 of the reference manual that a core function was
incompatibly removed. In the changelog, it lists "functions for packing
and unpacking values" under "main changes", but that's as much detail as
you get.
I had to hunt around to find out what was going on, because I didn't
expect built-in functions to silently disappear, and passing variable
arguments to a function is a pretty key thing to suddenly vanish without
trace or documentation.
One more thing: from an application writer's perspective, having
backward-compatibility options available in luaconf.h makes things a
whole lot worse, not better. Because now you have to write code for two
possible platforms, both calling themselves Lua 5.3, but actually with
different and incompatible functionality. What could possibly go wrong?
I know that Lua is an evolving language and I don't think you should
never be able to make any core changes ever. But at the least, could we
please have a deprecation cycle with warnings that code needs to be
updated, rather than unceremoniously breaking end-user code?
Could we also please have a commitment to full documentation of
incompatible changes, with explanation of what needs to be done to older
code to make it work?
And please, can we think about the impact on third-party code of
shifting things around in the core? To make a Lua application
compatible across Lua versions, I have to stuff my code with lines like
unpack = unpack or table.unpack
That's not a hard thing. Lua could actually do that for me, but now I
have to do it. In other words, making code backwards-compatible in Lua
is a burden, and the burden is being placed on the developer, not on the
language. I don't think that's not a good state of affairs either.
Knowing that, when 5.4 comes out, my code is probably going to stop
working again, through no fault of my own, does not really fill me with
confidence or joy.
Simon