 |
lua-l archive |
|
|
||
|
|
Hello, How the risk of a Lua fork increases with the community size,
given the slow release pace and even slower features introduction pace? Lower releases pace to mature design idea combined to the flexibility
not to ensure ascending compatibility allowed the language to evolve
efficiently as long as there was a clear roadmap and as the release pace was
matching industrial project lifetime (until 4.0). As soon as the pace has slow down, it let other languages more
prone to (too?) early address requirements spreading. Sadly this happened at a
key moment when interpreted language interest was growing. This was very bad
for the language because it also kept community too small to maintain rich third
part libraries that are as important as the core language for the success of a
language. The mismatch with industrial pace and Lua releases also made
Lua cheia initiative appearing as a signal that Lua was strongly needing to
evolve. This pushed to release Lua 5 and 5.1 thus trying to come back closer to
an industrial project pace and suddenly community has grown again to reach a
visible state to the tiobe index. So are the requirements, even though most of
them are not new but stagnating in a proprietary/open source patch area for
serious users. But Lua’s authors have written: -
They have reached the point where
they have no idea which feature needs to be introduced. -
They worry about the core not the libraries
(very worrying: how to make a full language then?) -
They want to keep slow release pace -
Acknowledged that Lua has a single
maintainer The last major release has already an industrial project
lifetime, so that new projects may again not select Lua and one could then see
interest decrease. The condition that let Lua cheia appeared are met again and
the same reactions are seen: Idle, and LuaJIT. Their approach is different but
addresses parts of current requirements so that the pressure might be strong on
them to provide what the reference release doesn’t. Few points need to be addressed or at least discussed soon to
build a roadmap and give visibility. These are not all core features. - support for Unicode - richer pattern matching - just in time compilation - bitwise operators (this is a core feature, not a library
feature: just try to imagine using arithmetic operators as a library) - probably 0 indexed array (Lua has resisted to much more
disturbing changes…) - efficient class model Not addressing some may just alienate part of community
which may satisfy narrow embedded core community. So the risks are probably that: -
Lua interest drops -
Lua interest is maintained but may
escape from original authors to more active maintainers. |