Re: Status of lposix?

[Cosmin Apreutesei <cosmin.apreutesei@...>]

Good APIs are hard to design, they need focus, completeness, good
docs, inspire trust, get stable, evolve, etc.-- especially hard to
design are the "0-tire" packages (the stdlibs). Yet some do manage to
pass the popularity test and a critical mass of users and developers
is formed, and there's no turning back. Also, a good design is usually
the product of one mind and many followers, and less committees. What
I'm trying to say is that standardization efforts have little effect
in the face of a good lib and little they can do to help a badly
designed lib or an unfocused one, like an anachronic lib following a
bad standard or blindly following it with disregard for actual
platform coverage, etc. -- there are many pitfalls.

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.

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.

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

On Thu, May 28, 2009 at 20:10, KHMan <keinhong@gmail.com> wrote:
> Florian Weimer wrote:
>>
>> * Mark Hamburg:
>>
>>> So how do other languages manage the process of standardizing
>>> library APIs?
>>
>> In short: they don't.
>>
>> For instance, I think no language with a standardization process has
>> ever gained the ability to change file permission bits.  All languages
>> which I know and provide this functionality got it when there was no
>> standardization process and one implementation, basically.
>
> Great point! Or Python's deprecated rfc822 module. There's no such thing as
> no risk. Even languages change and source code cannot maintain compatibility
> across all versions.
>
> One has to question what we really mean, or want, by "standardization". Do
> we have really stable interfaces? Many modules tend to be human-designed, if
> we look at having to distill C APIs down to something more simple. If it's
> down to human choices, it may be well-crafted but still susceptible to
> change or deprecation, and it may be impossible to pin down precise
> standardization specifics except for guidelines and best practices.
>
> So by "standardization", is it something like the default libraries of Perl
> etc.? Some central authority, redundant developer resources, something you
> can rely on to be maintained? A one developer project is fragile. Say if
> there's "standardization" but modules are discrete and many are run by
> single developers, that is still a lot of fragility there.
>
> Reading into the issue of endorsement (definitely not practical), I think it
> is really a suggestion that we have some kind of central authority that can
> anoint modules as "the chosen ones" so there will be stability. I dunno if
> that's good or bad. But to have a wide-ranging scheme like this in the long
> run, I think module developers will have to cede some control to a central
> authority -- like aggregation into a single codebase -- so that end-users
> get the maximum peace-of-mind.
>
>> [snip]
>
> --
> Cheers,
> Kein-Hong Man (esq.)
> Kuala Lumpur, Malaysia
>