Suggestion, Lua Sizes

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Suggestion, Lua Sizes

Patrick Mc(avery-2
A few months ago I started a thread "panda bears will die, sloths will live on". I really regret it. I upset some people, people I respect.

Having said this, I meant well and I think some of the issues I failed to articulate are still valid today.

I think that list members are often pushing the Lua team in directions they probably should not go in. For instance, I was pushing for an easier way to split code into separate files and was comparing Lua to Python and PHP, I wasn't worried if Lua got a bit bigger.

Now I am not doing desktop work with Lua and am more interested in the embedded side and I want Lua to be smaller. I am impossible to please and as a whole so is the list.

I have a suggestion.... why not divide the language into sizes? For instance lets say standard, vanilla, PUC Lua was size 3. Size 2 could be the same Lua shipping with long int's and size 1 could be Lua shipping with plain int, or something like this, others would be better qualified to sort this.

Now this is not very interesting but what about Lua size 4, the community edition? Why not make a bigger, slower, more feature rich Lua that the general community could develop.

Perhaps this would end, the endless discussions about what is missing or wrong with Lua, whatever was missing could be added to the design-by-committee version and the Lua team could focus on the version they want to work on with just a few smaller sizes pre-compiled for convenient number types.

If you like my idea great, if not, that's fine but I would like to pay my respects to a wonderful community that has helped me a lot and if this suggestion stinks, I will keep trying-Patrick
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

Sean Conner
It was thus said that the Great Patrick once stated:
> I have a suggestion.... why not divide the language into sizes? For
> instance lets say standard, vanilla, PUC Lua was size 3. Size 2 could be
> the same Lua shipping with long int's and size 1 could be Lua shipping
> with plain int, or something like this, others would be better qualified
> to sort this.

  There are problems with this.  I might want to keep Lua with doubles, but
dump the compiler and only deal with Lua bytecodes.  Or I might want a Lua
with long ints, the compiler, but not the standard libraries (table.*, io.*,
etc).  

  I think there are two classes of people, those who embed Lua and thus,
can deal with changing lua_Number to a long int, or excluding certain
portions of Lua, and what not.  Then there are the people who want to use
Lua as Lua and tend to use the Lua standalone interpreter much as one would
use python or perl or ruby.  These people want the batteries to be included.

  Me, I work with Lua as a library, so I don't particularly care if the
batteries are included (I rather like it as it, sans batteries).  But that's
my preference.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

Patrick Mc(avery-2

>    There are problems with this.  I might want to keep Lua with doubles, but
> dump the compiler and only deal with Lua bytecodes.  Or I might want a Lua
> with long ints, the compiler, but not the standard libraries (table.*, io.*,
> etc).
>
>    I think there are two classes of people, those who embed Lua and thus,
> can deal with changing lua_Number to a long int, or excluding certain
> portions of Lua, and what not.  Then there are the people who want to use
> Lua as Lua and tend to use the Lua standalone interpreter much as one would
> use python or perl or ruby.  These people want the batteries to be included.
>
>    Me, I work with Lua as a library, so I don't particularly care if the
> batteries are included (I rather like it as it, sans batteries).  But that's
> my preference.
>
>    -spc
>
>
>
Thanks Sean

It would have been easy to ship Lua with different number types already,
so I agree with you, it must unnecessary.

However what do you think about a fatter community edition? Even if you
like Lua the way it is, would you find the list a nicer place if the
discussion changed from Lua-team-do-this, Lua-team-do-that, to" let's
add this to the community edition"?

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

Petite Abeille

On Feb 9, 2012, at 10:39 PM, Patrick wrote:

> fatter community edition?

Like Lua for Windows (LfW)?

http://code.google.com/p/luaforwindows/


Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

William C. Bubel
In reply to this post by Patrick Mc(avery-2
On 02/09/2012 03:56 PM, Patrick wrote:

> A few months ago I started a thread "panda bears will die, sloths will
> live on". I really regret it. I upset some people, people I respect.
>
> Having said this, I meant well and I think some of the issues I failed
> to articulate are still valid today.
>
> I think that list members are often pushing the Lua team in directions
> they probably should not go in. For instance, I was pushing for an
> easier way to split code into separate files and was comparing Lua to
> Python and PHP, I wasn't worried if Lua got a bit bigger.
>
> Now I am not doing desktop work with Lua and am more interested in the
> embedded side and I want Lua to be smaller. I am impossible to please
> and as a whole so is the list.
>
> I have a suggestion.... why not divide the language into sizes? For
> instance lets say standard, vanilla, PUC Lua was size 3. Size 2 could be
> the same Lua shipping with long int's and size 1 could be Lua shipping
> with plain int, or something like this, others would be better qualified
> to sort this.
>
> Now this is not very interesting but what about Lua size 4, the
> community edition? Why not make a bigger, slower, more feature rich Lua
> that the general community could develop.
>
> Perhaps this would end, the endless discussions about what is missing or
> wrong with Lua, whatever was missing could be added to the
> design-by-committee version and the Lua team could focus on the version
> they want to work on with just a few smaller sizes pre-compiled for
> convenient number types.
>
> If you like my idea great, if not, that's fine but I would like to pay
> my respects to a wonderful community that has helped me a lot and if
> this suggestion stinks, I will keep trying-Patrick

I think what you're really asking for is, in addition to all of the
existing Lua versions, a version that's designed to take on the web in
the same way that PHP has. If you consider Perl, which has CPAN, then
Lua already has this in the form of LuaRocks. And of course, PHP has
Pear, Python has Egg, and Ruby has Gems. As I see it, that's just a
matter of having the community pull together and focus efforts into one
place.

I think the challenge, however, is getting members of the community to
step up and perform the unpaid and highly criticized work that everyone
else will eventually benefit from.

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

Dirk Laurie-2
In reply to this post by Patrick Mc(avery-2


Op 9 februari 2012 22:56 schreef Patrick <[hidden email]> het volgende:

I think that list members are often pushing the Lua team in directions they probably should not go in.
:gsub("pushing","trying to push")

The Lua team has shown admirable imperviousness to such attempts.


Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

Ross Bencina
In reply to this post by Patrick Mc(avery-2
Hi Patrick,

On 10/02/2012 7:56 AM, Patrick wrote:
> Now this is not very interesting but what about Lua size 4, the
> community edition? Why not make a bigger, slower, more feature rich Lua
> that the general community could develop.
>
> Perhaps this would end, the endless discussions about what is missing or
> wrong with Lua, whatever was missing could be added to the
> design-by-committee version and the Lua team could focus on the version
> they want to work on with just a few smaller sizes pre-compiled for
> convenient number types.

As a Lua embedder I have a couple of thoughts on this:

First, the down side: I would never use the community edition because if
I wanted something bloated like that I would use Python (which I use all
the time as a scripting language but wouldn't consider embedding these
days).

Second: on the other hand, I think a community edition would have some
advantages even for my use-case. For example, at the moment there is no
single standard library for Lua. This means if you want (say) container
classes, you have to write them yourself or cobble together something
out of a combination of other projects. That's fine, but it means that
everyone who embeds Lua may end up with a different
combinations/versions of what really should be the same "standard"
stuff. I'm not saying that everyone needs (e.g.) a "stack" type, but for
those who do, they should probably all be using the same one. Without
this Lua scripting skills (and scripts) arn't very transportable between
systems that embed it. I think centralising standard library development
in a community edition could help with that -- even though I wouldn't
use the community edition myself, I'd bundle some of the modules. I'd
feel much better about bundling a set of "official" modules from the
community edition than bundling a bunch of random stuff from all round
the net.

Same goes for object models -- would be nice to have some ordained
"standard" or "reference" ones.

Whether this can be achieved within the required constraints I don't
really know. Maybe there are too many conflicting (but equally valid)
aproaches to have a single unified "official" community edition.

Just my two cents,

Ross.

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

Tim Hill
In reply to this post by Dirk Laurie-2
.. and I for one want to _thank them_ for that imperviousness. Language (or, more specifically, run-time library) bloat is a huge problem imho. See the Java and .Net libraries for classic examples.

On Feb 11, 2012, at 4:55 AM, Dirk Laurie wrote:



Op 9 februari 2012 22:56 schreef Patrick <[hidden email]> het volgende:

I think that list members are often pushing the Lua team in directions they probably should not go in.
:gsub("pushing","trying to push")

The Lua team has shown admirable imperviousness to such attempts.



Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

Jay Carlson
On Sat, Feb 11, 2012 at 7:11 PM, Tim Hill <[hidden email]> wrote:
> .. and I for one want to _thank them_ for that imperviousness. Language (or,
> more specifically, run-time library) bloat is a huge problem imho. See the
> Java and .Net libraries for classic examples.

Java-the-language is a particularly egregious example of
imperviousness to change; it took how long to get foreach? Well, until
the C# bleeding got too bad. And Java lacks sugar for design patterns
set in stone. I tell people to head over to Lombok[1] the moment I
hear they're stuck in Java-the-language.

Jay

[1]: http://jnb.ociweb.com/jnb/jnbJan2010.html --
http://projectlombok.org/slideshow.html

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

steve donovan
In reply to this post by Ross Bencina
> Second: on the other hand, I think a community edition would have some
> advantages even for my use-case. For example, at the moment there is no
> single standard library for Lua. This means if you want (say) container
> classes, you have to write them yourself or cobble together something out of
> a combination of other projects.

We know that Lua tables are very flexible and powerful, but to
communicate programmer intent it's useful to work with specialized and
commonly-known data structures. That convenience becomes magnified
when there are 'standard' implementations (particularly true of
'classes')  Most of us have toolboxes of convenient functions, and
they get used in any non-trivial project. Like functions to split
strings into tables.  I still do this because I don't want to burden
every one of my public projects with Penlight. Granted, it is very
straightforward to make it a dependency using LuaRocks, but this is
not a universally used platform, particularly for the embedded case.

> (e.g.) a "stack" type, but for those who do, they should probably all be
> using the same one.

Personally, 'local push, pop = table.insert, table.remove' does just fine ;)

> even though I wouldn't use the community edition myself, I'd bundle some of
> the modules.

Penlight is designed to be as modular as possible; most modules depend
on pl.utils but otherwise I try to avoid excessive coupling. The file
path manipulation module pl.path has a LuaFileSystem dependency (but
even that is not cast in stone)  It does not depend on the extended
Python-like string functions in pl.stringx.  Similarly the
command-line parsing framework pl.lapp only needs pl.sip ("text
parsing for dummies");  the configuration-file parser pl.config has no
other dependencies.  I am trying to avoid a situation where including
a single useful module (or even function) might implicitly pull in
thousands of lines of library code.

Otherwise, the idea is to use straightforward, idiomatic Lua
implementations suitable for copy 'n paste reuse. That was the
motivation for the snippets site, to collect useful little recipes
together in a more organized way than the wiki.

An interesting possibility is 'static linking' of Lua programs; tools
like Squish[1] point the way here. So the final code has as little
dead code as possible, and is self-contained (very useful in the
embedded space).  The minimal-coupling/straightforward-implementation
design constraints are necessary preconditions for this to work
optimally.

> Same goes for object models -- would be nice to have some ordained "standard" or "reference" ones.

Oh yes. If only the etc directory had a little Lua module called
class.lua!  We would bitch about it (because naturally it would not be
optimal for all use cases) but it would have established a standard
model of inheritance that people would build on.

steve d.

[1] http://matthewwild.co.uk/projects/squish/home

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

云帆江
In reply to this post by Patrick Mc(avery-2
agree with this, although i care about size, but consider murgaLua, it pack almost full features in about just 500k size
which include fltk, socket, xml, sqlite, etc.


On Fri, Feb 10, 2012 at 4:56 AM, Patrick <[hidden email]> wrote:
A few months ago I started a thread "panda bears will die, sloths will live on". I really regret it. I upset some people, people I respect.

Having said this, I meant well and I think some of the issues I failed to articulate are still valid today.

I think that list members are often pushing the Lua team in directions they probably should not go in. For instance, I was pushing for an easier way to split code into separate files and was comparing Lua to Python and PHP, I wasn't worried if Lua got a bit bigger.

Now I am not doing desktop work with Lua and am more interested in the embedded side and I want Lua to be smaller. I am impossible to please and as a whole so is the list.

I have a suggestion.... why not divide the language into sizes? For instance lets say standard, vanilla, PUC Lua was size 3. Size 2 could be the same Lua shipping with long int's and size 1 could be Lua shipping with plain int, or something like this, others would be better qualified to sort this.

Now this is not very interesting but what about Lua size 4, the community edition? Why not make a bigger, slower, more feature rich Lua that the general community could develop.

Perhaps this would end, the endless discussions about what is missing or wrong with Lua, whatever was missing could be added to the design-by-committee version and the Lua team could focus on the version they want to work on with just a few smaller sizes pre-compiled for convenient number types.

If you like my idea great, if not, that's fine but I would like to pay my respects to a wonderful community that has helped me a lot and if this suggestion stinks, I will keep trying-Patrick



--
--
cheers
    Yunfan Jiang
{'nick':['jyf', 'geek42'], 'im': {'gtalk': '[hidden email]', 'irc': 'irc.freenode.net#ubuntu-cn'}, 'blog': 'http://geek42.info', 'interesting': {'teck': ['linux', 'pyt    hon', 'lua', 'c', 'nosql', 'redis', 'nginx'], 'history': ['chinese history',], 'sf': [42,], 'music': ['NewAge style', 'chinese old theme', 'Any strange music']}}

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

Jay Carlson
In reply to this post by steve donovan
On Mon, Feb 13, 2012 at 5:25 AM, steve donovan
<[hidden email]> wrote:

> Most of us have toolboxes of convenient functions, and
> they get used in any non-trivial project. Like functions to split
> strings into tables.  I still do this because I don't want to burden
> every one of my public projects with Penlight.

[...]

> An interesting possibility is 'static linking' of Lua programs; tools
> like Squish[1] point the way here.

Squish was too complex for me. See and/or seize
http://place.org/~nop/soar-0.0.tar.gz which does static/dynamic
dependency analysis, and creates the expected chunk form:

local function _main()
require "ml"
require "loml"
<body of script goes here>
end
package.preload["ml"] =function()
<body of ml>
end
package.preload["loml"=...
end
_main()

...except with more junk around it for various good and not so good
reasons (setenv UNSOAR to get the original script back on stdout etc.)
I blame pl/init.lua for the dynamic analysis, but it does seem to get
penlight apps right if you can hit all the code paths.

Between soar and Squish, "I want to ship a single .lua file" is no
longer a reason to be cut&pasting code into your apps.

Jay

> [1] http://matthewwild.co.uk/projects/squish/home

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion, Lua Sizes

steve donovan
On Fri, Feb 17, 2012 at 12:30 AM, Jay Carlson <[hidden email]> wrote:
> Between soar and Squish, "I want to ship a single .lua file" is no
> longer a reason to be cut&pasting code into your apps.

That's very cool. Yes, mea culpa, pl/init.lua is a devious piece of code.

For those unfamilar with the strategy, it does lazy loading of
modules.  This is to make life easier for lazy programmers:

require 'pl'
local d = arg[1] or error 'provide a directory'
if path.isfile (d) then
   for f in dir.dirtree(d) do
      print(f)
   end
end

require 'pl' does not actually bring in the whole 10K of the complete
library, but defines the subtables like 'path', 'dir', etc with a
custom __index. If you try to access a function in path it will do a
require 'pl.path' on demand.

Needless to say, this is a terrible thing to inflict on tool writers.

steve d.