lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

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

Ross.