Re: Status of lposix?

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

On Fri, May 29, 2009 at 07:52, KHMan <keinhong@gmail.com> wrote:
> 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*?

stdlib, ex, lposix, luasql... they contain some form of abstraction
(flame alert: it's not my intention to trash those libs in any way!!)
which I'd like to see more on application frameworks and application
code, and less on libraries (*). Following a standard (like io does)
is an entirely different matter and should not be confounded with
abstracting away similar platforms -- similarity is deceiving. You
either code for a standard or you code for a specific implementation,
or platform (still a standard underneath -- a specific frame of
reference). I can understand this urge to abstract at a psychological
level though :)

(*) inherently abstract domains, like 2D/3D graphics, although not
following a standard or platform in the conventional sense, they are
well-defined APIs apriori of any implementation. Filesystems and
RDBMSs are not. I have mixed opinions about GUI toolkits :)

> What is "lack of focus"?

Focus means stating the goals and following them, instead of trying to
be everything for everybody.

> What is "you have to be firm"? Aren't these phrases all intensely vague?

Yes.

> Can
> you provide the list with specific examples? I'm interested in learning
> about your specific examples of weaknesses in the libraries you mention.

I'll prepare something :) (examples are in this thread too...
make_backslash(), add_extension() -- what's an extension in unix?)
meanwhile...

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

Aren't these phrases all intensely vague? :)

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

Abstractions leak. You can't just "create" portability with
abstraction. The lowest common denominator is _designed_, and turns
into a standard (there are other ways to get there too), then
implementors _follow_ that standard and achieve portability. In that
order. Taking a Windows fs lib and a Unix fs lib and abstracting away
the differences can be fun, especially in lua, but won't get you
portability, just leaky abstraction. Likewise, taking away specific
connection options from a database backend, just because _other_
backend doesn't support it doesn't get you "the lowest common
denominator", just a useless backend nobody will use for real projects
-- any ORM library gives justice to this statement... they're all a
butcher's shop, as they should be.

>
> You give two parties, one for "full API coverage" and the other for
> "portable apps". Which party are you for and against?

I'm not for or against any of these goals. It's the designer's choice.
In practice I always endup needing the full coverage libs. You forgot
the third goal: "performance".

> If you want to have
> both, can you propose ways in which the two can live together peacefully?

I think you can't. You have to choose and stay focused on your goals.

> 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?
>

Ugh, rant is easy, research is hard, and I don't want to start a fire :)