Re: Breakthrough dream or Selenophobia

[Peter Aronoff <telemachus@...>]

Dirk Laurie <dirk.laurie@gmail.com> wrote:
> I consider myself an experienced Lua programmer by now, and I dread
> having to modify a program that someone else wrote.

If this is right, it's awfully depressing. It suggests that Lua is (has
become?) one of those "write-only" languages that you hear so much about.

> 1. Modules
> 
> At the top of a program you see
> 
>    local pkg = assert(require "obscuremodule")
> 
> The author of the program knows the API for that module. The reader
> does not. Does the author document any of that API? Of course not.
> It's documented, if at all, inside the module. However, if that "require"
> goes through, "pkg" could be any Lua value, any global variable may
> have been set, any system library may have been monkey-patched.
> The reader has to discern which.

I'm not quite sure what you're upset about here. In my experience (in any
language), the documentation for an imported module is not found in the
code that imports it, it's found in the module itself. In this regard,
I find Lua modules to be on par with Ruby modules in terms of
documentation. That is, documentation for modules is found either (1) in
a formal set of documentation shipped with the module (this is nicest) or
(2) online, usually on the README of the module's repo. Some Ruby modules
provide no docs, just code. I avoid those for all the obvious reasons.
Ditto for Lua.

> 2. Objects
> 
> There are any number of object paradigms floating around. Is the
> constructor the callable metatable? Is __index distinct from the
> metatable. Does the author document any of that? Seldom.

This is absolutely true. It's part of the price you pay for trying to have
something that the language itself doesn't provide (and thus standardize).
But in this regard, Lua is no worse than, say, Perl. If you use OOP in
Perl, someone picking up your code usually[1] has to go to whatever code
you require from CPAN to see how _that_ specific OOP works. (I suppose that
things in Perl are better because so many people use Moose. But a new
programmer must still learn Moose in addition to Perl.) Partly for this
reason, I avoid using OOP in Perl and Lua. (I know many people won't like
that solution.  Just saying.)

> 3. Metatables
> 
> That one word says all. You know what you do with them. Does
> anybody else know?

Again, I agree here. And, again, as a result, I avoid writing or
using code with metatable magic. Again, many people won't like this
solution.

In replying, I've mostly convinced myself that you're right. How sad.

P

[1]: I'm assuming that nobody uses "raw" or built-in Perl OOP since I don't
     think I've ever run across it in the wild, though lots of Perl coders
     claim that it's just great.

-- 
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System