[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Upstream is not the last word (was Re: [ANN] Lua 5.1.5 (rc1) now available)
- From: Ross Bencina <rossb-lists@...>
- Date: Tue, 14 Feb 2012 21:01:33 +1100
On 14/02/2012 7:39 PM, Sean Conner wrote:
It was thus said that the Great Ross Bencina once stated:
Should I laugh or cry?
> I'm going to attempt an answer, from my perspective:
> Use case #1: application development language
[ snip ]
> Use case #2: user extension language
[ snip ]
> For use case #1 above (developing) it probably doesn't matter, people
> can do what they like, but for use case #2 (user extension) I really
> don't want to wear the "object system and language library designer" hat
> and be held accountable by my users of how such basic facilities work --
> I'm more than happy to do it the "standard base way".
> Does that make sense?
Not really. I don't see any real difference between #1 and #2, so I'm not
even sure what you are asking.
I would put your use in case #1: you control the development and runtime
environment, the whole code base, *and* the developers, *and* the users.
You have captive users too -- you can treat them any way you like.
Case #2 is like, well I can't think of a Lua example, but let's say,
it's like "Visual Basic for Applications". You give the user an App, and
it has a scripting environment where they can write extensions. The user
will write code. In this case you're providing a programming environment
to the user -- either it's plain Lua or it comes with some "batteries."
Even though I don't expect "batteries" with Lua, end-users sure will --
and it really shouldn't be a nightmare on the scale of this thread for
an embedder to provide "the standard batteries".
All I'm saying is that for cases where batteries are included, they
should be the same batteries (or at least compatible batteries), and it
should be easy to find and package them. Otherwise App A embedding "Lua"
could use it in a completely different and incompatible way to App B.
That's fine if there's a good reason for it, but it's a big headache if
it's just becausefunction names or core idioms aren't standardised. Or
the embedder (like me) wasn't a Lua guru, and didn't really know what
the right batteries looked like.
> Also, I'm not a big proponent of object
> oriented programming, and I find what Lua provides just fine
> for my own needs (I stay as far away from C++ as possible),
> so I don't quite understand this whole obsession over objects.
> From what I can see, Lua support of "objects" is fine.
Fair enough. The same would apply if we were discussing functional
programming. There are a standard set of functions in that style too
(e.g. map() )
> So for my use case, it's important to be able to statically
> compile modules into the program. It's less important to
> have a "base library" or "base object system" because what
> Lua provides is enough (or rather, I have to supply quite a bit,
> but it's all custom coding anyway).
Do you think every line of what you supply needs to be custom? Are you
really using absolutely no standard utility functions? no reusable
abstractions? generic functions? If not, then colour me surprised. I had
to write a bunch of abstractions just to get started. Sure, they were
light weight and simple, but they were still necessary to make the code
My assertion is that if there is no "base library" then every Lua
embedder has to concoct their own base library. Which is fine for custom
jobs, but not so easy to manage when the whole thing is then published
as an open programming system for other end-user-developers to use.
Every such publisher becomes their own Cardinal (to use the previous
blessing analogy) -- I have enough jobs already, I don't want to be a
Lua language Cardinal, I just want to publish something with a "standard
base" that's usable.. whether the standard base is object-oriented or
functional is less important that it is usable by end users without me
or end users writing a bunch of expected "standard" infrastructure.