Re: Status of lposix?

[KHMan <keinhong@...>]

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
> choices.

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]

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