 |
lua-l archive |
|
|
||
|
On 5 Nov 2015 06:58, "Dirk Laurie" <dirk.laurie@gmail.com> wrote:
>
> 2015-11-05 0:30 GMT+02:00 Stefano <phd.st.p@gmail.com>:
>
> > What I am stating is that the pervasive mentality in the Lua community
> > (reinvent the wheel just a bit differently, no backward compatibility,
> > no standard functionalities included, no conventions, 300 mini-modules
> > promptly abandoned) does not seem to have resulted in a solid
> > ecosystem with a good number of high profile packages.
>
> <apology> Maybe I'm hijacking your thread by singling out this remark
> for further comment. </apology>
>
> Coming from Python, I also lamented the lack of an ecosystem when
> I was new to the game. I made a beautiful `dirk.lua` full of tiny utilities
> that I was sure I would require in every project. Like this one:
>
> local into = function(tbl) -- receptacle for gsub
> return function(item) append(tbl,item) end
> end
>
> Gradually I discovered that Real Lua Programmers do as you say,
> and nowadays I paste those uitilties into every project that actually
> needs them. I shamelessly plunder collections like Microlight instead
> of requiring the module and make tiny modifications to the routines.
> It does not bother me. I think it is easier to read the actual code than
> to consult somone else's documentation, if any [1].
This way you are duplicating code endlessly, which is not exactly best practice.
Moreover, because of the modifications, anyone reading your code will have no idea what your split() function does even assuming that he/she is familiar with microlight (itself, unlikely).
The point here is that the lack of standard batteries covering enough ground hinders collaborative development.
When you read xstring.split(s) you have no idea of what it's doing. Will it split over commas or spaces? Will it return a table or multiple arguments? How does it handle corner cases?
Imagine if Lua didn't have table.sort(), the same issues would arise for sorting.
Or imagine C++ without the STL.
Reading code to figure it out only works for extremely small code bases. It is not a realistic approach for anything else.
Even having to consult documentation for basic utilities (because everyone is using a different library) is too much.
And the situation *is* as bad as I am making it.
Torch guys inject xutil, some other guys use penlight / microlight / std, some others copy and paste from different sources and then modify the code.
As a matter of fact, the number of modules involving more than one core developer is extremely limited.
>
> > I am not sure to what extent this can be argued against.
>
> It is a consequence of the fact that Lua is so minimalistic, and that
> is not going to change.
There is a difference between the language itself being minimalistic and the batteries being minimalistic.
Honestly, I don't find the Lua language, nor its implementation, any less suited to general purpose programming than Python.
The issue is with the batteries/libraries only and the lack of agreement over conventions.
On one point you are right.
The case I am making has been argued for multiple times already, even by people with a very high profile, and nothing has changed.
So it's safe to assume that it will not change in the future as well.
>
> This is not to say that there is no place for an ecosystem, but what
> we need is not batteries, it is appliances.
On this, I disagree, for the reasons listed above.
Indeed, if when you started Lua programming such batteries were available and commonly used, you would have followed.
I surely would have coped with the fact that string.split() would not split by default over my favorite char and have just used it instead to focus on more productive stuff. :)
And I too am guilty of this proliferation (even though when I started Lua 6 years ago the situation was way messier than it is today) with my Xsys module, which I am going to deprecate as soon as possible.
> The Lua modules that
> I `require` and use unchanged are those that package expertise
> (lpeg, ansicolors, socket, mime, mathx, etc). They save me time
> and bother. Yet another elegant implementation of a class system,
> for example, saves me nothing.
The issue I mention is particularly acute for class systems.
Unless everyone uses the same they just make the code more difficult to read. Hence, I as well am not using any.
>
> <retraction> Actually I think all the above is quite pertinent to
> the basic philosophy of what you are trying to do. </retraction>
It is indeed.
My efforts for ULua are toward:
1. Providing an easy "1-click" install for Lua and its libraries
2. Providing an informative aggregation of the libraries with the hope that developers will eventually gravitate toward the most promising one for each domain. As it is a reinforcing cycle, this is reasonable.
Stefano
>
> [1] Microlight itself is very well documented. I plunder its
> documentation method too. :-)
>