The source file culture

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

Re: The source file culture

Asko Kauppi
LuaRocks should really have taken care of this by now. Has it not?

Would adding something like Hamster to do the builds help? In other  
words, does LR allow defining build rules in a platform independent  
way? I thought it does.

- asko

On 8.9.2009, at 17.03, steve donovan <[hidden email]> wrote:

> On Tue, Sep 8, 2009 at 3:35 PM, David Given<[hidden email]> wrote:
>> I remember one rather interesting conversation here a while back;  
>> someone
>> was asking about using Lua for some purpose... enterprise data  
>> processing, I
>> think. I was rather struck by the difference in attitude between  
>> the people
>> here and the kind of community you get in, say, Ruby or Python:
>
> Well, I think we've experienced two users with very different laments,
> Andre de Leiradella talking about the good old days when you could
> 'just' knock some C together with Lua and have an app, and George
> talking about the difficulties of doing Lua without having to do C.
> Both were not very coherent complaints, but that is the nature of a
> lament, and attacking incoherence does not advance the cause.
>
> OK, so what is the cause?  Most of us are embedded Lua people, and
> have forgotten our frustrations with command-line tools, forgiven C,
> and often content to use 30-year old technology (e.g emacs/vi, make).
>> From that perspective, not wanting to go that path seems like a sign
> of not being serious.  Then there are people who are attracted to a
> fast, sane little programming language and want to use it in wider
> applications, maybe even as an application library.  I'm in both
> camps, I like Lua because it reduces the amount of C++ I need write;
> the headaches I get with C++ are not related to my skill level, just a
> recognition that most C++ is probably premature optimization in the
> Knuth sense.
>
> There are initiatives to make Lua a better all-purpose scripting
> language, and mostly these don't worry the embedders, unless like
> Andre they think it is complicating that simple idylic C + Lua life.
> So maybe when a scripter complains, then the embedders should remember
> their own frustrations, just a little?
>
> Otherwise, we do come across as elitist and snotty, and that does us
> no favours in the long term.
>
> steve d.
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

Cosmin Apreutesei
In reply to this post by steve donovan
> [...] So the real
> challenge is to make something like LuaRocks understand how to get and
> install those external dependencies. [...] and you can see that the module author
> (or maintainer) has to be an unusually dedicated person!

However, there's really no other way. The infrastructure people
(LuaRocks authors, Lua authors, etc.) are the only ones who can make
auto-building happen. Shifting this responsibility to other developer
groups won't make it happen because of the simple fact that - in this
free market as it is - they pursue different objectives - they
represent different groups of interests that are only _marginally_
intersecting. Those developer groups are 1a) application
developers/standalone, 1b) application developers/embedded, 2) library
developers, 3) Lua language and platform developers.

With this perspective in mind, it's easy to observe why people in
different groups whine about what they perceive as being someone
else's responsibility. They are all right of course.

Standalone app developersare right that compilation and C knowledge is
not their primary goal and should not be inflicted upon them -- be
they afraid, lazy or unknowlegeable -- it simply doesn't serve their
best interest to build modules by hand, so it's futile to continue
calling them names. They will simply move away to other more
integrated platforms.

Not sure why embedded devs complain about the module system and
distribution of binaries -these things weren't made for them in the
first place :)

API developers are right that (the portability part of) building
process is not their primary goal and should not be inflicted upon
them -- bad Makefiles reflect that very clearly (they also reflect
that Make doesn't by itself provide any facilities to help with the
portability goal, unlike LuaRocks or autotools). They are happy if an
automated build system helps the widespread of their libraries, but
they won't produce one unless the effort pays off in _their_ currency
(that is, adoption of their libraries). I think it's what made
LuaRocks possible.

Finally, the language/platform people are like the government, they
provide the infrastructure for all other to do their business, except
they are not _invested_ by other people to do so, they don't tax other
people and don't produce inflation :) They have their own reasons for
doing what they do as does everyone else in the ecosystem. But however
those are, the pressure to make an appealing app. platform out of Lua
is on them and there's little that the other groups can do about that.
Some people from other groups might jump in and help, but again, only
if the effort pays off in _their_ own currency. Good or bad as it is,
it's a fact of the market.

Just another point and and then I kick myself out of this long rant.
It's about the binaries vs sources issue. Windows app devs don't have
anything against sources _because_ of cultural reasons, it's the other
way around. As long as the build process is fully automated and
_works_, they wouldn't care less how the modules are installed and
found at runtime.

my2c.
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

Luiz Henrique de Figueiredo
In reply to this post by steve donovan
> I like Lua because it reduces the amount of C++ I need write;

That's most probably the case when Lua can replace C++ object hierarquies
or just plain glue application code (ie, the calling of libraries).

For any tasks that need performance you still need enough C or C++ libraries
that you can bind to Lua. This is also true for many tasks for which there
are mature C libraries, even if you don't need raw performance -- you just
don't want to reinvent the wheel in pure Lua just to have less C in your app.
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

Reuben Thomas-5
In reply to this post by steve donovan
2009/9/8 steve donovan <[hidden email]>:
> Both were not very coherent complaints, but that is the nature of a
> lament

No! Laments can be coherent and precise, and certainly should be in a
forum such as this. That was my principle criticism; I have nothing
against well-thought-out laments and complaints.

> Most of us are embedded Lua people, and
> have forgotten our frustrations with command-line tools, forgiven C,
> and often content to use 30-year old technology (e.g emacs/vi, make).
> From that perspective, not wanting to go that path seems like a sign
> of not being serious.  Then there are people who are attracted to a
> fast, sane little programming language and want to use it in wider
> applications, maybe even as an application library.  I'm in both
> camps, I like Lua because it reduces the amount of C++ I need write;
> the headaches I get with C++ are not related to my skill level, just a
> recognition that most C++ is probably premature optimization in the
> Knuth sense.

This looks like stereotyping to me. "Command-line tools, C, emacs and
make" have all evolved considerably in the last 30 years; equally,
there are other development environment styles which have come along
in that time. Using Visual Studio isn't "not being serious" any more
than using GNU is being stuck in the stone age. Worse, this sort of
dichotomy implies an unavoidable trade-off.

> There are initiatives to make Lua a better all-purpose scripting
> language, and mostly these don't worry the embedders, unless like
> Andre they think it is complicating that simple idylic C + Lua life.

This is more like it: it's only when one use is advanced at the
expense of another that there's a problem. What we need more of is the
sort of ingenuity that gets around these problems; far more often than
one might imagine, it's possible. The way that Emacs wraps batch tools
for interactive use, and the way that Visual Studio now exposes its
internals programmably are two obvious examples, as, more generally,
is the way that Mac OS X allows a far wider range of interactions
(both at the user and the API levels) than its predecessors.

> So maybe when a scripter complains, then the embedders should remember
> their own frustrations, just a little?

(I'm still a bit of both, as although I don't use Lua for writing new
scripts much, I still maintain old ones, and use it in certain
situations, like build systems for programs in which I already embed
Lua.)

> Otherwise, we do come across as elitist and snotty, and that does us
> no favours in the long term.

I'm not sure where the impression of elitism (which is to say,
exclusivity) is coming from. I've not seen anyone, at least in this
thread, who wouldn't like Lua to be easier to use for everyone.

Having fallen into the heffalump trap next to which I was trying to
erect a "BEWARE OF THE HEFFALUMP TRAP" sign, I shall now find
something more worthwhile to do.

--
http://rrt.sc3d.org
L’art des vers est de transformer en beautés les faiblesses (Aragon)
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

Daniel Silverstone
In reply to this post by David Given
On Tue, Sep 08, 2009 at 02:35:32PM +0100, David Given wrote:
> 35% of (participating) users have liblua5.1 installed (the shared  
> library). 1% have lua5.1 installed (the command line interpreter).

ion3, wireshark, vlc-nox. Those are three things which use Lua in library form
which may contribute towards it.  It seems ion3 is fairly negligible, but 20%
of popcon users have vlc-nox installed, and about 12% have wireshark-common.
While there will be some overlap, I imagine that counts for the vast majority
of the installed userbase.

I have repeatedly told Debian and other free-software developers to "Just add
Lua" when asked "How do I make this more easily configured / customised" so
it's nice to see that some of them are taking note of the evangelism from the
Lua community.

D.

--
Daniel Silverstone                         http://www.digital-scurf.org/
PGP mail accepted and encouraged.            Key Id: 3CCE BABE 206C 3B69
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

KHMan
In reply to this post by Reuben Thomas-5
Reuben Thomas wrote:
> 2009/9/8 steve donovan <[hidden email]>:
>> Both were not very coherent complaints, but that is the nature of a
>> lament
>
> No! Laments can be coherent and precise, and certainly should be in a
> forum such as this. That was my principle criticism; I have nothing
> against well-thought-out laments and complaints.

Okay, I'm breaking my own suggestion...

principle -> principal, some precision missing there... ;-)

Let's be a bit more tolerant in a diverse community. Remember,
it's a bell curve. Other people do not always operate at your
level, and this kind of communication medium is notorious for
misunderstandings, etc. You said "marketing counts", but you're
not helping here...

We're not all IT professionals here; 'we' could be high school
students, etc. Please be a bit more patient with the slow people
like us, you know... :-)

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

Reuben Thomas-5
On Tuesday, September 8, 2009, KHMan <[hidden email]> wrote:
> principle -> principal, some precision missing there... ;-)

D'oh. And I read the word twice as I typed it.

> We're not all IT professionals here;

e.g. me, I'm a church singer.

--
http://rrt.sc3d.org
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

KHMan
Reuben Thomas wrote:
> On Tuesday, September 8, 2009, KHMan <[hidden email]> wrote:
>> principle -> principal, some precision missing there... ;-)
>
> D'oh. And I read the word twice as I typed it.
>
>> We're not all IT professionals here;
>
> e.g. me, I'm a church singer.

Quite.

Also, there are developers whose first language isn't English. If
there is a possibility that there are high school students whose
first language isn't English who want to ask questions in a forum
like this, I say that we need to make allowances for that, focus
on the positives, and facilitate the discussion.

I will take leave of this thread now, been talking too much. :-)

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

steve donovan
In reply to this post by Luiz Henrique de Figueiredo
On Tue, Sep 8, 2009 at 4:59 PM, Luiz Henrique de
Figueiredo<[hidden email]> wrote:
> For any tasks that need performance you still need enough C or C++ libraries
> that you can bind to Lua.

There's a sweet spot where the fast stuff is in C and the rest can be
done in Lua without much change in overall performance.  Where that
point lies depends on the application, and ultimately is a
semi-empirical engineering question.

> This is also true for many tasks for which there
> are mature C libraries, even if you don't need raw performance -- you just
> don't want to reinvent the wheel in pure Lua just to have less C in your app.

This is true; there is so much code to borrow or steal out there.  An
exception however is if the library suffers from bloat and excessive
scope, in which case I'd write 100 lines of Lua any day ;)

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

steve donovan
In reply to this post by Reuben Thomas-5
On Tue, Sep 8, 2009 at 5:11 PM, Reuben Thomas<[hidden email]> wrote:
> This looks like stereotyping to me. "Command-line tools, C, emacs and
> make" have all evolved considerably in the last 30 years; equally,
> there are other development environment styles which have come along
> in that time.

Yeah, sorry, that was a cheap shot.

After all, I was trying to make a plea for tolerance ;)

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

Petite Abeille-2-2
In reply to this post by David Given

On Sep 8, 2009, at 3:35 PM, David Given wrote:

> I think what I'm trying to say is that Lua users are weird and don't  
> necessarily fall into the same demographic as with other scripting  
> languages. I could be wrong, though --- I know *I'm* weird...

To paraphrase the Austin Independent Business Alliance's slogan:

Keep Lua Weird!

Cheers,

--
PA.
alt.textdrive.com/nanoki/


Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

Petite Abeille
In reply to this post by David Given

On Sep 8, 2009, at 3:35 PM, David Given wrote:

> I think most people here see Lua as a component, intended to be  
> customised and bolted into another product, rather than being used  
> on its own.

I take offense of your use of "most people" :D

I, for one, use Lua on its own :)

Cheers,

--
PA.
http://alt.textdrive.com/nanoki/
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

Pan, Shi Zhu
Lua is designed as a language to be embbeded. AFAIK it has two typical use:

1. to be embbeded in a product, and the users are end-users of the
product, i.e. non-programmers who should *not* add library to the lua
script. I usually design programms like this: if user can write the
lua script, I will restrict the use of "import". The libraries are
executed in the same thread of the hosting program instead of a
sandbox, we should not let end-users to add libraries.

2. to be used by the programmer himself, I embbed lua into my C
program because I use it, end-user of my program cannot see or change
the lua scripts. In this case I compile all library and statically
link with my program and release with my program. For this use, I
definetly need the C source.


Yes, there may be users who use lua as a general-purpose stand-alone
scripting language, but IMHO the vast majority of lua use, is to be
used within another product, for which, only the original programmers
should be able to add libraries, end-user are not expected to add
libraries.

IMO release windows-based binraries to the relatively small amount of
users doesn't seem to help a lot.
Reply | Threaded
Open this post in threaded view
|

RE: The source file culture

John Hind
I think you have hit the nail on the head here.

If we want to take Lua in the direction of a general scripting language we
need a more comprehensive and standardised runtime implementation and the
module system should be part of the runtime not part of the language itself.

> -----Original Message-----
> From: [hidden email] [mailto:lua-
> [hidden email]] On Behalf Of pan shizhu
> Sent: 11 September 2009 08:56
> To: Lua list
> Subject: Re: The source file culture
>
> Lua is designed as a language to be embbeded. AFAIK it has two typical
> use:
>
> 1. to be embbeded in a product, and the users are end-users of the
> product, i.e. non-programmers who should *not* add library to the lua
> script. I usually design programms like this: if user can write the
> lua script, I will restrict the use of "import". The libraries are
> executed in the same thread of the hosting program instead of a
> sandbox, we should not let end-users to add libraries.
>
> 2. to be used by the programmer himself, I embbed lua into my C
> program because I use it, end-user of my program cannot see or change
> the lua scripts. In this case I compile all library and statically
> link with my program and release with my program. For this use, I
> definetly need the C source.
>
>
> Yes, there may be users who use lua as a general-purpose stand-alone
> scripting language, but IMHO the vast majority of lua use, is to be
> used within another product, for which, only the original programmers
> should be able to add libraries, end-user are not expected to add
> libraries.
>
> IMO release windows-based binraries to the relatively small amount of
> users doesn't seem to help a lot.

Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

steve donovan
In reply to this post by Pan, Shi Zhu
On Fri, Sep 11, 2009 at 10:24 AM, John Hind <[hidden email]> wrote:
> If we want to take Lua in the direction of a general scripting language we
> need a more comprehensive and standardised runtime implementation

Well, I think the community has certainly provided all the bits
necessary for general scripting, but the trouble is of course when we
talk about 'standardized', given that this will involve getting cats
to self-herd.  Standardization involves a lot of work, mostly on the
level of 'what is the signature of the optional function os.sleep?'
and 'should access() be in the io or osex namespace?'.  It will then
require buy-in, and an inevitable time of confusion when the same
facilities are available from two locations, the old and the new. It's
the latter step which is awkward.

> and the module system should be part of the runtime not part of the language itself.

Well, technically the module system is a library and was for a time
implemented in Lua.

pan shizhu says:
> IMO release windows-based binraries to the relatively small amount of
users doesn't seem to help a lot.

Fortunately, it's already happening and should not cause problems for
those who don't like the idea ;)

Restricting the language and its libraries because it goes beyond some
common uses seems ... well, restrictive.

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: The source file culture

Pan, Shi Zhu
On Fri, Sep 11, 2009 at 6:09 PM, steve donovan
<[hidden email]> wrote:
> pan shizhu says:
>> IMO release windows-based binraries to the relatively small amount of
> users doesn't seem to help a lot.
> Fortunately, it's already happening and should not cause problems for
> those who don't like the idea ;)
Yes, providing windows-binary doesn't hurt, but I'm just explaining
why "the source file culture" is important for lua .
123