Metaprogramming

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

Metaprogramming

Carlos Pita
Hi all,

as I'm coming to lua from the lisp/scheme world, metaprogramming
facilities are at the top of my checklist. Also, since lua is
minimalistic and provide powerful and generic building blocks
(resembling scheme in both aspects) metaprogramming is synergic with
the language design principles.

I know of metalua, which is a compiler, and of luamacro, which is a
preprocessor. But, as a newcomer, I'm still unable to completely grasp
many details about versions, interoperability, tooling, and the like.
So some questions are in order:

1) As metalua produces bytecode and luajit doesn't read any bytecode
but its own, is it possible to combine metalua with luajit somehow? Is
it possible to use metalua as a preprocessor? If it is, are there
convenient tools to do this or will I instantly become a maverick
(which I don't want at all)?

2) Is there any editors/ides supporting syntax extensions out of the
box? I mean editors that become syntax-extension aware without a lot
of effort from the user.

3) Up to this point my plan is to:
   i) Use luamacro, as it produces standard lua source code, which
makes it more interoperable with other tools.
   ii) Use scintillua (inside textadept) to quickly hack new syntax
constructs support using a bit of lpeg.
What do you think of this approach?

Any informed opinion will be very welcomed.

Cheers
--
Carlos

Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Carlos Pita
PS: at the risk of not getting precise answers for my more technical
questions, I would like to hear your opinions about the need of
metaprogramming in lua. As scheme, lua provides powerful basic
mechanisms that lend themselves to implement new control structures,
programming paradigms, etc. This often implies boilerplate code that
cannot always be abstracted out into reusable functions (maybe because
the function calling syntax isn't ideal for the specific construct,
maybe because the function calling semantics is inadequate).

On Fri, Jul 4, 2014 at 2:45 PM, Carlos Pita <[hidden email]> wrote:

> Hi all,
>
> as I'm coming to lua from the lisp/scheme world, metaprogramming
> facilities are at the top of my checklist. Also, since lua is
> minimalistic and provide powerful and generic building blocks
> (resembling scheme in both aspects) metaprogramming is synergic with
> the language design principles.
>
> I know of metalua, which is a compiler, and of luamacro, which is a
> preprocessor. But, as a newcomer, I'm still unable to completely grasp
> many details about versions, interoperability, tooling, and the like.
> So some questions are in order:
>
> 1) As metalua produces bytecode and luajit doesn't read any bytecode
> but its own, is it possible to combine metalua with luajit somehow? Is
> it possible to use metalua as a preprocessor? If it is, are there
> convenient tools to do this or will I instantly become a maverick
> (which I don't want at all)?
>
> 2) Is there any editors/ides supporting syntax extensions out of the
> box? I mean editors that become syntax-extension aware without a lot
> of effort from the user.
>
> 3) Up to this point my plan is to:
>    i) Use luamacro, as it produces standard lua source code, which
> makes it more interoperable with other tools.
>    ii) Use scintillua (inside textadept) to quickly hack new syntax
> constructs support using a bit of lpeg.
> What do you think of this approach?
>
> Any informed opinion will be very welcomed.
>
> Cheers
> --
> Carlos

Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Jay Carlson


On Jul 4, 2014 2:02 PM, "Carlos Pita" <[hidden email]> wrote:
>
> PS: at the risk of not getting precise answers for my more technical
> questions, I would like to hear your opinions about the need of
> metaprogramming in lua. As scheme, lua provides powerful basic
> mechanisms that lend themselves to implement new control structures,
> programming paradigms, etc. This often implies boilerplate code that
> cannot always be abstracted out into reusable functions (maybe because
> the function calling syntax isn't ideal for the specific construct,
> maybe because the function calling semantics is inadequate).

Lua is militant that compile aka loadstring(s) is a pure function of the value s. This by itself is enough to eliminate most uses of macros, as you can't import them.

Many of the things you'd do in macros have relatively tasteful Lua syntax. For example, not only is [[ struct "t" ]] available,

  struct "t" {
    int "a",
    float "b"
  }

is as well.  The cost is that the domain syntax cannot be checked at compile-time, it must be interpreted (at least once) at run-time, any diagnostic messages will be weird, and you often end up having a cons-y interface. Plus poor interaction with lexicals, but that's a pet issue.

The only way to delay evaluation of an argument is to pass it as a thunk. Because function()end is kinda bulky, people seem avoid it.

Jay

[my pet issues: prompt diagnosis of invalid UTF-8, and errorism in general; making it easier to use parsed structures than string concatenation (which means lexical references in freeform syntax); least-intrusive syntax for domain-specific control flow.]

Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Javier Guerra Giraldez
On Fri, Jul 4, 2014 at 1:58 PM, Jay Carlson <[hidden email]> wrote:
> Because function()end is kinda bulky, people seem avoid it.


not me.  i do find anonymous lambdas a handy construct and use them
extensively.  I also think that the 'short lambda syntac' patches
around are a waste of time.

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Carlos Pita
> not me.  i do find anonymous lambdas a handy construct and use them
> extensively.  I also think that the 'short lambda syntac' patches
> around are a waste of time.

I understand everyone has his preferred syntax for this or that, and
that function() ... end syntax is all right for most use cases, but
standard function calling syntax & semantics plus some lambda shortcut
like | ... | could go a long way in the direction of implementing
custom control structures or language constructs, without requiring
macro support at all.

Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Steve Litt
In reply to this post by Carlos Pita
On Fri, 4 Jul 2014 15:01:52 -0300
Carlos Pita <[hidden email]> wrote:

> PS: at the risk of not getting precise answers for my more technical
> questions, I would like to hear your opinions about the need of
> metaprogramming in lua. As scheme, lua provides powerful basic
> mechanisms that lend themselves to implement new control structures,
> programming paradigms, etc. This often implies boilerplate code that
> cannot always be abstracted out into reusable functions (maybe because
> the function calling syntax isn't ideal for the specific construct,
> maybe because the function calling semantics is inadequate).

I don't know.

But I sure want to hear what you and everyone else have to say. When
somebody has a faster, more accurate or more secure way of writing
programs, I'm all ears.

From here on down I'll give some disjoint opinions not at all specific
to Lua...

I use templates with tokens a lot. Data for my program that prints
diplomas for students who have taken my Troubleshooting Course consists
of a non-compressed .svg file, with tokens where the student name, the
customer name, and the dates should be. A second piece of data is a
Yaml file with the customer name, dates, and an array of student names.
My program mailmerges the two and spits out diplomas for everyone.

The late 1980's featured the fastest developing Rapid Application
Development environment I've ever seen: Clarion 2.1. Developed much
faster than Rails or the various other frameworks. Faster than
Delphi and Powerbuilder and all those 1990's RADs. Basically, you just
laid out forms with database fields, applied any field specific logic
on the field, and you were done. Creating a 4 table app in a day,
starting with no database or anything else, was no problem at all. Can
you imagine what that capability did for a freelance programmer?

The way Clarion 2.1 worked was they had a "Model File", which was a
template with all sorts of tokens that told Clarion both how to shape
the Clarion user interface for the programmer, and how to interpret
what the programmer laid out in his forms, menus, reports, and special
source code files. People a lot smarter than I could change the Model
Files to change the whole look of Clarion programs, or the way the
development environment worked.

There's an outline processor called Leo, in which you outline your app,
run a process, and it's a Python program. Unfortunately, to the best of
my knowledge, it works only with Python.

Anyway, you brought up one heck of an interesting topic, and I hope
there are a lot more responses.

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

steve donovan
In reply to this post by Carlos Pita
On Fri, Jul 4, 2014 at 9:16 PM, Carlos Pita <[hidden email]> wrote:
> standard function calling syntax & semantics plus some lambda shortcut
> like | ... | could go a long way in the direction of implementing
> custom control structures or language constructs, without requiring
> macro support at all.

I appreciate this point as well;  although I went to trouble to get
LuaMacro right, I no longer believe that ad-hoc syntax extension is
appropriate for code shared with other people[1]. I'm also a fan of
the |...| syntax that's enabled with GSL Shell - the author's
rationale is that it makes interactive experimentation less verbose.
But there doesn't seem much chance of it making into mainstream Lua.

Another approach is to use a different but consistent notation for Lua
programs, for example Moonscript - this has a lightweight function
syntax. Together with the very low precedence of the call operator
this makes it an excellent candidate for implementing DSLs.  It
compiles to straightforward Lua and so access to the Lua ecosystem
(and LuaJIT) is straightforward.

For instance, defining a function is straightforward:

sqr = (x) -> x^2

Table sorting (note the low call operator precedence)

table.sort t, (x,y) -> x.name > y.name

You could argue that this isn't Lua any more, but then neither would
be any customized dialect... one sacrifices the syntactical simplicity
of Lua for a gain in expressiveness. [2]

steve d.

[1] it also complicates tool support
[2] but the syntax is consistent and fixed, so (e.g.) latest version
of ZeroBrane Studio can debug Moonscript as well.

Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

William Ahern
On Sat, Jul 05, 2014 at 12:41:19PM +0200, steve donovan wrote:

> On Fri, Jul 4, 2014 at 9:16 PM, Carlos Pita <[hidden email]> wrote:
> > standard function calling syntax & semantics plus some lambda shortcut
> > like | ... | could go a long way in the direction of implementing
> > custom control structures or language constructs, without requiring
> > macro support at all.
>
> I appreciate this point as well;  although I went to trouble to get
> LuaMacro right, I no longer believe that ad-hoc syntax extension is
> appropriate for code shared with other people[1]. I'm also a fan of
> the |...| syntax that's enabled with GSL Shell - the author's
> rationale is that it makes interactive experimentation less verbose.
> But there doesn't seem much chance of it making into mainstream Lua.
>
> Another approach is to use a different but consistent notation for Lua
> programs, for example Moonscript - this has a lightweight function
> syntax. Together with the very low precedence of the call operator
> this makes it an excellent candidate for implementing DSLs.  It
> compiles to straightforward Lua and so access to the Lua ecosystem
> (and LuaJIT) is straightforward.
>
> For instance, defining a function is straightforward:
>
> sqr = (x) -> x^2
>
> Table sorting (note the low call operator precedence)
>
> table.sort t, (x,y) -> x.name > y.name
>
> You could argue that this isn't Lua any more, but then neither would
> be any customized dialect... one sacrifices the syntactical simplicity
> of Lua for a gain in expressiveness. [2]
>
> steve d.

I never understood DSLs which did little more than add syntactic sugar and
some object management automation. The last DSL I wrote for Lua was an
event-oriented, declarative language for a mail server. Using a simple
declarative syntax which wrapped small blocks of plain Lua code, I could
easily introspect the filtering code to optimize execution of events
including automatic short-circuiting, parallelization, and conflict
detection. And the declarative syntax made it incredibly easy to define
rules which previously had grown (over a decade of feature accretion) into a
horrendous mess of parameters and configuration tables.

When I think of DSLs that's the kind of power I see; not the ability to code
more efficiently in the exact same paradigm. That's a ton of effort and
expense for comparatively little return.

Depending on one's preferences I can understand the desire to tweak various
elements of Lua. But if someone is just tweaking things so they can more
easily implement precisely the same solution, just a little more
elegantly... I don't get that.

Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Carlos Pita
If you do a lot of work with tables you will dislike the syntax:

table{ ....}end

and certainly won't consider {} syntax sugar.

Similarly, if your coding style relies a lot on higher order functions
you may find:

function()....end

too noisy in contexts like:

seq:foreach(....) or

seq:map(....) or, worst:

switch(
   ...., ....,
   ...., ....,
   ...
)

Lua semantics doesn't preclude this coding style at all (which, btw,
is not just about toy dsls). But it syntax discourages it.

I really can't see the ton of effort for a little return here.



On Sat, Jul 5, 2014 at 10:13 PM, William Ahern
<[hidden email]> wrote:

> On Sat, Jul 05, 2014 at 12:41:19PM +0200, steve donovan wrote:
>> On Fri, Jul 4, 2014 at 9:16 PM, Carlos Pita <[hidden email]> wrote:
>> > standard function calling syntax & semantics plus some lambda shortcut
>> > like | ... | could go a long way in the direction of implementing
>> > custom control structures or language constructs, without requiring
>> > macro support at all.
>>
>> I appreciate this point as well;  although I went to trouble to get
>> LuaMacro right, I no longer believe that ad-hoc syntax extension is
>> appropriate for code shared with other people[1]. I'm also a fan of
>> the |...| syntax that's enabled with GSL Shell - the author's
>> rationale is that it makes interactive experimentation less verbose.
>> But there doesn't seem much chance of it making into mainstream Lua.
>>
>> Another approach is to use a different but consistent notation for Lua
>> programs, for example Moonscript - this has a lightweight function
>> syntax. Together with the very low precedence of the call operator
>> this makes it an excellent candidate for implementing DSLs.  It
>> compiles to straightforward Lua and so access to the Lua ecosystem
>> (and LuaJIT) is straightforward.
>>
>> For instance, defining a function is straightforward:
>>
>> sqr = (x) -> x^2
>>
>> Table sorting (note the low call operator precedence)
>>
>> table.sort t, (x,y) -> x.name > y.name
>>
>> You could argue that this isn't Lua any more, but then neither would
>> be any customized dialect... one sacrifices the syntactical simplicity
>> of Lua for a gain in expressiveness. [2]
>>
>> steve d.
>
> I never understood DSLs which did little more than add syntactic sugar and
> some object management automation. The last DSL I wrote for Lua was an
> event-oriented, declarative language for a mail server. Using a simple
> declarative syntax which wrapped small blocks of plain Lua code, I could
> easily introspect the filtering code to optimize execution of events
> including automatic short-circuiting, parallelization, and conflict
> detection. And the declarative syntax made it incredibly easy to define
> rules which previously had grown (over a decade of feature accretion) into a
> horrendous mess of parameters and configuration tables.
>
> When I think of DSLs that's the kind of power I see; not the ability to code
> more efficiently in the exact same paradigm. That's a ton of effort and
> expense for comparatively little return.
>
> Depending on one's preferences I can understand the desire to tweak various
> elements of Lua. But if someone is just tweaking things so they can more
> easily implement precisely the same solution, just a little more
> elegantly... I don't get that.
>

Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

William Ahern
On Sun, Jul 06, 2014 at 12:15:16AM -0300, Carlos Pita wrote:

> If you do a lot of work with tables you will dislike the syntax:
>
> table{ ....}end
>
> and certainly won't consider {} syntax sugar.
>
> Similarly, if your coding style relies a lot on higher order functions
> you may find:
>
> function()....end
>
> too noisy in contexts like:
>
> seq:foreach(....) or
>
> seq:map(....) or, worst:
>
> switch(
>    ...., ....,
>    ...., ....,
>    ...
> )
>
> Lua semantics doesn't preclude this coding style at all (which, btw,
> is not just about toy dsls). But it syntax discourages it.
>
> I really can't see the ton of effort for a little return here.
>

What's the #1 excuse for not using a language like Lua: popularity.

It's a valid excuse, because using an unpopular language means more time and
expense training your engineers, or finding engineers comfortable in that
language, compounded by the the looonngggg maintenance curve. Plus, it makes
it more difficult to integrate or reuse modules and libraries. (Even if your
syntax change doesn't hinder using third-party modules, it does hinder your
ability to reuse your code elsewhere.)

Now, as niche of a language Lua is, any DSL based on Lua is infinitely more
so.

That's a _huge_ cost.

Python can't hold a candle to the power and capability of PUC Lua, yet when
a corporation chooses a language like Lua over Python, it's a very serious
decision because there are immense costs involved, immediate and
prospective.

The same considerations apply regarding a DSL, and as nice as some of these
enhancements to Lua are, are they really the same order of difference as
between Lua and Python? IMO they should be to justify the costs.

Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Andrew Starks



On Sat, Jul 5, 2014 at 10:46 PM, William Ahern <[hidden email]> wrote:
On Sun, Jul 06, 2014 at 12:15:16AM -0300, Carlos Pita wrote:
> If you do a lot of work with tables you will dislike the syntax:
>
> table{ ....}end
>
> and certainly won't consider {} syntax sugar.
>
> Similarly, if your coding style relies a lot on higher order functions
> you may find:
>
> function()....end
>
> too noisy in contexts like:
>
> seq:foreach(....) or
>
> seq:map(....) or, worst:
>
> switch(
>    ...., ....,
>    ...., ....,
>    ...
> )
>
> Lua semantics doesn't preclude this coding style at all (which, btw,
> is not just about toy dsls). But it syntax discourages it.
>
> I really can't see the ton of effort for a little return here.
>

What's the #1 excuse for not using a language like Lua: popularity.

It's a valid excuse, because using an unpopular language means more time and
expense training your engineers, or finding engineers comfortable in that
language, compounded by the the looonngggg maintenance curve. Plus, it makes
it more difficult to integrate or reuse modules and libraries. (Even if your
syntax change doesn't hinder using third-party modules, it does hinder your
ability to reuse your code elsewhere.)

Now, as niche of a language Lua is, any DSL based on Lua is infinitely more
so.

That's a _huge_ cost.

Python can't hold a candle to the power and capability of PUC Lua, yet when
a corporation chooses a language like Lua over Python, it's a very serious
decision because there are immense costs involved, immediate and
prospective.

The same considerations apply regarding a DSL, and as nice as some of these
enhancements to Lua are, are they really the same order of difference as
between Lua and Python? IMO they should be to justify the costs.



I think that many people pick Lua because their use case has no alternative. There is not another language implementation that can provide scripting or a dynamic language that will work as fast as Lua. If we liked Python or JavaScript, we couldn't have used it for our task.

Also, many companies use Lua to provide scripting (or what have you) to their users. They may also use Lua for application code, but that might be separate. Many use cases operate out of the assumption that their users don't know any programming, so why bother bending to a familiar language when your users are familiar with nothing?

Finally, some companies will futz with out of ego or out of a desire to make it special to them. Maybe they want lock-in or maybe there is a legitimate domain problem that is better served by a slightly different language than PUC Lua.

More than any other niche or dynamic language, Lua has opportunities that make it ripe for modifying.
Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Tim Hill

On Jul 5, 2014, at 9:44 PM, Andrew Starks <[hidden email]> wrote:

What's the #1 excuse for not using a language like Lua: popularity.

It's a valid excuse, because using an unpopular language means more time and
expense training your engineers, or finding engineers comfortable in that
language, compounded by the the looonngggg maintenance curve. Plus, it makes
it more difficult to integrate or reuse modules and libraries. (Even if your
syntax change doesn't hinder using third-party modules, it does hinder your
ability to reuse your code elsewhere.)

Now, as niche of a language Lua is, any DSL based on Lua is infinitely more
so.

That's a _huge_ cost.

Python can't hold a candle to the power and capability of PUC Lua, yet when
a corporation chooses a language like Lua over Python, it's a very serious
decision because there are immense costs involved, immediate and
prospective.

The same considerations apply regarding a DSL, and as nice as some of these
enhancements to Lua are, are they really the same order of difference as
between Lua and Python? IMO they should be to justify the costs.



I think that many people pick Lua because their use case has no alternative. There is not another language implementation that can provide scripting or a dynamic language that will work as fast as Lua. If we liked Python or JavaScript, we couldn't have used it for our task.

Also, many companies use Lua to provide scripting (or what have you) to their users. They may also use Lua for application code, but that might be separate. Many use cases operate out of the assumption that their users don't know any programming, so why bother bending to a familiar language when your users are familiar with nothing?

Finally, some companies will futz with out of ego or out of a desire to make it special to them. Maybe they want lock-in or maybe there is a legitimate domain problem that is better served by a slightly different language than PUC Lua.

More than any other niche or dynamic language, Lua has opportunities that make it ripe for modifying.

Why we picked Lua for our work:

— Fast: Passed all our performance tests with flying colors
— Robust: We didn’t find a SINGLE bug when stress testing Lua 5.2 (example: we created 25,000 Lua states and ran them all for a month)
— Clean syntax: Yes, it’s not a language everyone knows, but if you can’t pick up Lua in a few days max you aren’t a developer.
— Compact: The footprint is important to us for low power and operation on a wide range of devices: embedded to server
— Stable: The release cycle seems sensible, with carefully thought out releases with significant improvements
— Rational C API: Ever looked at the Python one?

—Tim



Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

steve donovan
In reply to this post by William Ahern
On Sun, Jul 6, 2014 at 5:46 AM, William Ahern
<[hidden email]> wrote:
> The same considerations apply regarding a DSL, and as nice as some of these
> enhancements to Lua are, are they really the same order of difference as
> between Lua and Python? IMO they should be to justify the costs.

This is a good argument against ad-hoc syntax modification. Say a
developer embeds stock Lua; then their users can use online resources
like Stackoverflow and any Lua tutorial without confusion - in this
way, the developer can outsource documentation and concentrate on the
specific API they have exposed.  Syntax changes mess up this
complementary situation and the developer must document these changes
in addition; this applies also to extensions to standard library
namespaces.  Something like string.split is useful, but that name will
cause confusion when users seek help (and I've seen precisely this
kind of thing happening on Stackoverflow) so it should have a distinct
namespace.

I brought Moonscript into the discussion, not because I think it's the
way forward, but because it's a consistent but different syntax to
regular Lua, backed by the same semantics.  It is better than ad-hoc
modifications because this new syntax is documented.  However, it's
not more beginner-friendly, since there's a good deal more syntax
involved and it's more terse and less readable by beginners.  So by
this logic, it's best to keep your Lua plain and vanilla.

In other words, I agree ;)

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Steve Litt
In reply to this post by William Ahern
On Sat, 5 Jul 2014 20:46:30 -0700
William Ahern <[hidden email]> wrote:

> On Sun, Jul 06, 2014 at 12:15:16AM -0300, Carlos Pita wrote:
> > If you do a lot of work with tables you will dislike the syntax:
> >
> > table{ ....}end
> >
> > and certainly won't consider {} syntax sugar.
> >
> > Similarly, if your coding style relies a lot on higher order
> > functions you may find:
> >
> > function()....end
> >
> > too noisy in contexts like:
> >
> > seq:foreach(....) or
> >
> > seq:map(....) or, worst:
> >
> > switch(
> >    ...., ....,
> >    ...., ....,
> >    ...
> > )
> >
> > Lua semantics doesn't preclude this coding style at all (which, btw,
> > is not just about toy dsls). But it syntax discourages it.
> >
> > I really can't see the ton of effort for a little return here.
> >
>
> What's the #1 excuse for not using a language like Lua: popularity.
>
> It's a valid excuse, because using an unpopular language means more
> time and expense training your engineers, or finding engineers
> comfortable in that language, compounded by the the looonngggg
> maintenance curve. Plus, it makes it more difficult to integrate or
> reuse modules and libraries. (Even if your syntax change doesn't
> hinder using third-party modules, it does hinder your ability to
> reuse your code elsewhere.)
>
> Now, as niche of a language Lua is, any DSL based on Lua is
> infinitely more so.
>
> That's a _huge_ cost.
>
> Python can't hold a candle to the power and capability of PUC Lua,
> yet when a corporation chooses a language like Lua over Python, it's
> a very serious decision because there are immense costs involved,
> immediate and prospective.

It's not just that. Training costs I could work with. I see the problem
as this: Python has so many proven, tested libraries to interface with
just about any technology, that you can start a Python project with
near-certainty that you won't get painted into a corner.

With Lua's less tested and approved add-ons, you can only hope.

Lua's a better language, but for a data processing or user interface
application, success is more certain with Python because of its
libraries.

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Steve Litt
In reply to this post by Tim Hill
On Sun, 6 Jul 2014 00:08:36 -0700
Tim Hill <[hidden email]> wrote:


> Why we picked Lua for our work:
>
> — Fast: Passed all our performance tests with flying colors

> — Robust: We didn’t find a SINGLE bug when stress testing Lua 5.2
> (example: we created 25,000 Lua states and ran them all for a month)

> — Clean syntax: Yes, it’s not a language everyone knows, but if you
> can’t pick up Lua in a few days max you aren’t a developer.

> — Compact: The footprint is important to us for low power and
> operation on a wide range of devices: embedded to server

> — Stable:
> The release cycle seems sensible, with carefully thought out releases
> with significant improvements

> — Rational C API: Ever looked at the
> Python one?

The last one is the big one, if you ask me. Python, Perl, and Ruby are
all fast enough for most situations, and the apps you build with them
are stable. Except Perl, they all have clean syntax, though not as
clean as "only complex data structure is a table" Lua.

Most people don't need compact.

But if you need to interface with C, going both ways, Lua's absolutely
the way to go.


SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


Reply | Threaded
Open this post in threaded view
|

Re: Metaprogramming

Tim Hill
>
>> — Compact: The footprint is important to us for low power and
>> operation on a wide range of devices: embedded to server
>
>> — Stable:
>> The release cycle seems sensible, with carefully thought out releases
>> with significant improvements
>
>> — Rational C API: Ever looked at the
>> Python one?
>
>
> Most people don't need compact.
>
> But if you need to interface with C, going both ways, Lua's absolutely
> the way to go.
>
>
> SteveT
>

I think compact is under-rated. Compact almost always equates to efficient, which maps to “low power” .. which *is* important in the modern world of portable devices. People either forget or do not realize the enormous power costs of CPU cache misses (and, worse, page swaps). The tight core of the Lua VM means that it is virtually running from the L1 cache on many modern processors (even ARM cores), which translates into very significant power reduction (and of course also improves performance).

—TIm