lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Cosmin Apreutesei wrote:
[snip snip]
Unfortunately I find that the stdlibs, and especially the filesystem
libs in Lua suffer from lack of focus, eg. you have be firm in your
choice between performance, API coverage and portability -- you can't
have them all, and users usually know what they are looking for and
what they are willing to trade... they make their choices at the start
of the project, and they look for the best library that matches those

Which library are you talking about *specifically*? What is "lack of focus"? What is "you have to be firm"? Aren't these phrases all intensely vague? Can you provide the list with specific examples? I'm interested in learning about your specific examples of weaknesses in the libraries you mention.

But we'll always have less than perfect design. How many of us have good hands-on experience with (and access to) three major platforms, *nix, Mac OS X and Win32? And 32-bit plus 64-bit? If one's expectations is so high, almost every library will be of weak design, nothing will be up to one's level of expectations. Tradeoffs are always judgment calls, opinion calls. There is no one Perfect Call. One person's great call is another one's poison. A great Win32 library may be stuck on Win32 forever, and it may not gel with policies for a common library aggregation. Linux evolve too, things get ripped out and replaced.

For example: people writing shell stuff for linux will always look for
full API coverage and will happily trade in portability. Those writing
portable apps will opt for the lowest common denominator like Lua's
own io lib, etc. Some lib developers don't get this and make
abstraction layers that give the illusion of portability, in the quest
for creating perfect lib for every purpose/platform/choice. IMHO (and
I know this is heresy, especially among OOP folks), abstractions
should be delayed as much as possible into the application code --
early abstraction is as bad as early optimization.

Why "illusion of portability"? Portability is portability when you need to have "the lowest common denominator", sacrifices and tradeoffs must be made, so what do you specifically mean by "illusion"? Examples, please.

You give two parties, one for "full API coverage" and the other for "portable apps". Which party are you for and against? If you want to have both, can you propose ways in which the two can live together peacefully? And if you need portability, it has to be simpler, so what are the bad "abstractions" you are referring to? Many libraries expose basic objects, can you provide clear examples where in your opinion the objects were overcooked?

Gotta stop now, getting off topic and post already too long :)

I think this is not off-topic at all, this has to do with issues surrounding library or module development. We may not end up with anything done or any code written, but the issues are relevant.

The point in my earlier post is that it is not the "product" (i.e. library or module) that is the elephant in the room, it is the process and methods in which we evolve a "product" that end-users are lulled into thinking is good, stable and utterly dependable. Is it do-able or still a gleam in our eyes? Can individual developers satisfy multi-platform commitments and maintenance commitments, or must such compatibility and maintenance be enforced by a different kind of organization? Such a scheme may be non-trivial and require considerable commitment of resources by developers for an extended period of time.

On Thu, May 28, 2009 at 20:10, KHMan <...> wrote:
Florian Weimer wrote:
* Mark Hamburg:
[snipped all]

Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia