[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Microlight (was Re: paving cowpaths with libraries)
- From: Jay Carlson <nop@...>
- Date: Fri, 17 Feb 2012 00:33:46 +0000
On Thu, Feb 16, 2012 at 10:21 PM, marbux <marbux@gmail.com> wrote:
> On Thu, Feb 16, 2012 at 1:43 AM, steve donovan
> <steve.j.donovan@gmail.com> wrote:
>> I don't think we're shopping for a standard library here; there's this
>> new sport called 'code golf'; this particular little exercise is more
>> like 'library golf' - see how much useful stuff we can pack into a few
>> functions.
>
> Got it now. Maybe sometime we could have another 'code golf' game with
> an eye toward documentation needs of newbie and beginner scripters.
Less code in a basic library means less to document....
Well. sorta. A lot of the tools in microlight are useful in a *lot* of
situations, but it is not immediately obvious what all the situations
all are. New users aren't going to say "ah, I'll use update() on _G to
import symbols like 'from foo import *'." This seems like an obvious
use to me, but I'm not the audience; there are other corners of Lua I
don't know very well and I can use help there.
It's better in that fewer functions means less memorization and more
regularity, hopefully making them easier to keep in your head. And
once you look at how something like throw() works in a cookbook way,
you may find out it works for some other problem you've come across.
Or not. Doing stuff out of a cookbook is fine, it's not like there's
some moral superiority to understanding the nuts and bolts of every
last tool you use. It may make life easier eventually, it may make it
easier to ask and answer questions, but *of course* I have never
cut&pasted some example C++ template code I had no clue how about. And
especially not this week. :-/
At least this time I didn't have to disassemble it in the debugger to
find out what the hell it meant.
Jay