S.W.O.T analysis

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

S.W.O.T analysis

Patrick Mc(avery-2
I started a new thread because my Panda bears will die title was offensive.

Strengths.Weaknesses.Opportunities.Threats

To answer this:
"""Why does Lua needs to compete with the fat language?  There are plenty to choose from: PHP, Perl, Ruby, Python, etc.  

I view Lua a very nice little language that can be easily embedded in other software systems.  Or something small enough that you can put it on tiny hardware (e.g., eLua).  There are plenty of large "fat" languages that are feature rich, have bazillions of packages and much "power", whatever someone might think that is.  But there are very few small, compact language implementations in the space that Lua is in.  The closest is probably Tcl which is pretty old at this point, and I think Lua is a wonderful, "modern" replacement for the space that Tcl was popular in.  Perhaps ficl is another, somewhat less well known example."""

I think Lua is coming to a cross roads. I know it is bad etiquette to discuss one's computer but please forgive this under this context, my machine has 8Gs of ram. I'm not bragging, yours probably has more but it is important. If this is about average now, in 5 years it will be 4X this.

If Python runs something in 200ms and Lua runs it in 50ms I don't care, it's still a blink of an eye.

Python is so much easier to learn then Lua and Haskell seems a have more built in facilities for advanced programming(I've only started to learn it).

I wonder if Forth died because the memory savings no longer offset and difficult programming model? It also looks like the Forth community tore it in half, with one camp wanting it bigger and more feature rich while the other camp wanted it small and simple.

I think there is a real danger of ignoring the non-programmer(are modules simple to them? and how many geologists understand weak tables?) and not focusing on adding in the facilities for easier programming. I think there is also a real danger of not having enough advanced features to compete with Haskell and other fat FP languages.

Ultimately the Lua team will know best but I have been with Lua for two years now, not due to it's small size but to it's wonderful community(aside from module debates). I love how Luiz and Roberto are here everyday helping out and not off in an ivory tower somewhere else. If they weren't here I would not be here either.

-Patrick



Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

steve donovan
On Wed, Oct 19, 2011 at 1:54 PM, Patrick Mc(avery
<[hidden email]> wrote:
> If Python runs something in 200ms and Lua runs it in 50ms I don't care, it's
> still a blink of an eye.

Ah, but many of us work with dinky little processors, and even now
that smartphones are more powerful than 70s mainframes, you still have
the iron law that inefficiency is costly in power use.  Battery
evolution has been fantastic, but there are limits.

> Python is so much easier to learn then Lua

Not sure how generally true that is. If we took some young noobs and
gave them a feature-rich Lua environment, then I think there's less
gotchas than in Python, which has so many types and special syntax to
handle them.  ('feature-rich' is however the catch!)

> I think there is a real danger of ignoring the non-programmer(are modules
> simple to them? and how many geologists understand weak tables?)

Well, the set of 'languages friendly to non-programmers' certainly
does not contain Haskell ;)  (Though some pure mathematicians might
take it to it readily)

Also, no _consumer_ of a library should need to know about weak
tables.  That should all happen in the backroom somewhere.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Patrick Mc(avery-2
{snip}
Hi Steve

I did not mean to imply that Haskell was for non-programmers, quite the
opposite! I think it's power is a threat if it drains away
professional-programmers, while Python has the potential to become the
"Walmart" of programing languages, swallowing up family-sized ones. I
could never have understood Lua's prototype-like object system without
having understood Python's plain class based object system first. I know
saving CPU cycles is always a concern and Lua has the edge today but if
savings CPU cycles did not save Forth, then in the long run it might not
save Lua.

Thanks


Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Enrico Colombini
In reply to this post by Patrick Mc(avery-2
On 19/10/2011 13.54, Patrick Mc(avery wrote:
> If Python runs something in 200ms and Lua runs it in 50ms I don't care,
> it's still a blink of an eye.

In a game environment, for example, 1 ms per frame could be way too
much. Same thing for memory, in many embedded applications.

I fail to understand this drive to "let's change Lua to make it the same
as any other generalist language".

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Andre Leiradella-2
In reply to this post by Patrick Mc(avery-2
<snip>

> I know
> saving CPU cycles is always a concern and Lua has the edge today but if
> savings CPU cycles did not save Forth, then in the long run it might not
> save Lua.

I'm not claiming that Lua needed salvation, but it is used in a *lot* of games exactly because it's lean and fast. I think you mentioned Lua being used in World of Warcraft... Do you think it would have been used there if it was fat and slow?

If you consider the videogame console world, being small and fast is even more critical. Otherwise, how would it fit in so little memory, and be able to execute game logic in the time of one frame?

Cheers,

Andre



Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Patrick Mc(avery-2
In reply to this post by Enrico Colombini
On 11-10-19 08:42 AM, Enrico Colombini wrote:

> On 19/10/2011 13.54, Patrick Mc(avery wrote:
>> If Python runs something in 200ms and Lua runs it in 50ms I don't care,
>> it's still a blink of an eye.
>
> In a game environment, for example, 1 ms per frame could be way too
> much. Same thing for memory, in many embedded applications.
>
> I fail to understand this drive to "let's change Lua to make it the
> same as any other generalist language".
>
Hi Enrico

Actually I don't want to change Lua per say, it's just that with all the
module discussion I feel that a large part of the list is arguing for
the wrong sort of things. I think that there should be more attention
paid to making it simpler to use. Perhaps that puts me in the
anti-module camp but if it does, I don't think the revision goes far
enough to bring it to the easy of use of python/import, PHP/include.

Again I don't understand the internals and if this sort of thing will
cause too much overhead then it's pointless as Lua has to find some safe
space between the fat/feature-rich languages.

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Pierre Chapuis
In reply to this post by Patrick Mc(avery-2
On Wed, 19 Oct 2011 07:54:02 -0400, Patrick Mc(avery wrote:

> If Python runs something in 200ms and Lua runs it in 50ms I don't
> care, it's still a blink of an eye.

Depends how many times.

$ time for i in $(seq 1 100); do python -c "print('hello world')"
 >/dev/null; done

real 0m1.921s
user 0m0.995s
sys 0m0.875s

$ time for i in $(seq 1 100); do lua -e "print('hello world')"
 >/dev/null; done

real 0m0.384s
user 0m0.049s
sys 0m0.296s

$ time for i in $(seq 1 100); do luajit -e "print('hello world')"
 >/dev/null; done

real 0m0.341s
user 0m0.032s
sys 0m0.283s

Which one would you (not) choose to serve CGIs?

> Python is so much easier to learn then Lua and Haskell

At a basic level, Python is slightly easier to learn than Lua.
Both are much easier to learn than Haskell.

If you want to know the language inside-out and be able to make
it co-operate with C, Lua wins over both other languages.

> I wonder if Forth died because the memory savings no longer offset
> and
> difficult programming model? It also looks like the Forth community
> tore it in half, with one camp wanting it bigger and more feature
> rich
> while the other camp wanted it small and simple.

Does this mean you have to opt for intermediate mediocrity, or
does this mean you have to chose your side?

> I think there is a real danger of ignoring the non-programmer(are
> modules simple to them? and how many geologists understand weak
> tables?) and not focusing on adding in the facilities for easier
> programming. I think there is also a real danger of not having enough
> advanced features to compete with Haskell and other fat FP languages.

Lua is not a FP language, although it has the features required to
do untyped FP (closures, true tail calls, 1st class functions).
It is very far from being Haskell. I would rather compare it to
LISP. Actually, I see Lua as Lisp with a more imperative style
and another base data structure.

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

steve donovan
In reply to this post by Patrick Mc(avery-2
On Wed, Oct 19, 2011 at 2:31 PM, Patrick Mc(avery
<[hidden email]> wrote:
> opposite! I think it's power is a threat if it drains away
> professional-programmers, while Python has the potential to become the
> "Walmart" of programing languages,

Ah, but your marketing analysis assumes competition in a single
market, whereas it's much more about niches and how well a language
can fill that niche.

Also, note although people regularly bitch about Java, they are
looking ahead to new JVM languages.  No one wants to do their serious
banking infrastructure in Python!  Again, a niche.

> never have understood Lua's prototype-like object system without having
> understood Python's plain class based object system first.

Except that it probably helps to have 'beginners' mind' and stop
pining for classes ;)   Learning about the power of closures makes a
lot of class-y machinery redundant!  Old news to the Schemers, but man
it did blow my mind.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Patrick Mc(avery-2
In reply to this post by Andre Leiradella-2
{snip}
> I'm not claiming that Lua needed salvation, but it is used in a *lot* of games exactly because it's lean and fast. I think you mentioned Lua being used in World of Warcraft... Do you think it would have been used there if it was fat and slow?
>
> If you consider the videogame console world, being small and fast is even more critical. Otherwise, how would it fit in so little memory, and be able to execute game logic in the time of one frame?
>
> Cheers,
>
> Andre
>
Hi Andre

No I don't want Lua to be fat and slow at all.

Okay let me rephrase, it this way, if we could trade weak tables and
closures for a simple python/import mechanism then I think that would be
better for the language. I think it needs to stay small to stay away
from the bigger language's market but not so much that it is hard for a
non-programmer to use and that non-programmer friendly features should
trump advanced FP features.

It is my understanding that TCL ended up nether small like Lua for
embedding nor feature rich like Python. I guess I am trying to say there
is a dangerous balancing act here.

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Axel Kittenberger
In reply to this post by Pierre Chapuis
> Which one would you (not) choose to serve CGIs?

Only that CGIs are more and more becoming a concept of yesterday in
favor of event-based scripting servers.

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Enrico Colombini
In reply to this post by Patrick Mc(avery-2
On 19/10/2011 14.48, Patrick Mc(avery wrote:
> Again I don't understand the internals and if this sort of thing will
> cause too much overhead then it's pointless as Lua has to find some safe
> space between the fat/feature-rich languages.

Has it? Why?

I have an original Swiss Army knife: 30 years and still as good as new.
It works beautifully and I bring it with me whenever I go hiking in the
Alps.
I also keep a large, heavy, full-featured toolbox at home, but I never
dreamt of changing the former into the latter :-)

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Pierre Chapuis
In reply to this post by Axel Kittenberger
On Wed, 19 Oct 2011 14:57:42 +0200, Axel Kittenberger wrote:
>> Which one would you (not) choose to serve CGIs?
>
> Only that CGIs are more and more becoming a concept of yesterday in
> favor of event-based scripting servers.

Maybe because using CGIs is becoming more and more expensive. Now
which one is simpler: CGIs with Lua or Python+Twisted?

Don't get me wrong, I like event-based programming, but a lot of
Web developers use it for bad reasons. AS we say in France, you
shouldn't use a hammer to crush a fly.

This http://teddziuba.com/2011/10/node-js-is-cancer.html is
certainly questionable but I agree with at least one point:
the Unix way of building systems (small blocks communicating
through pipes) is proven and should be the default.
And if you use a scripting language in such a setup you want
fast interpreter boot time.

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Axel Kittenberger
Pierre seriously rethink what kind of links you republish, "jackass
who whines", etc...

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Pierre Chapuis
On Wed, 19 Oct 2011 15:34:48 +0200, Axel Kittenberger wrote:

> Pierre seriously rethink what kind of links you republish, "jackass
> who whines", etc...

Maybe I shouldn't have posted the link. He *is* a troll.
But the point was : don't think event-driven Web servers are a
silver bullet because they're hot and trendy. They are just
another tool.

I do not see this https://github.com/ignacio/luanode or this
https://github.com/creationix/luvit becoming dominant anytime soon
as interesting as they can be.

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Javier Guerra Giraldez
In reply to this post by Patrick Mc(avery-2
On Wed, Oct 19, 2011 at 6:54 AM, Patrick Mc(avery
<[hidden email]> wrote:
> Python is so much easier to learn then Lua

it _might_ be easier to dabble in Python than in Lua (i don't think
so, but there are people who do); but definitely it's FAR easier (and
cleaner) to do advanced programming in Lua.

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Michael Richter
I think the funniest thing that I've taken from this rant and ensuing thread is the news that Forth is dead.  (Here's a hint: just because you can't see it doesn't mean it's not there.  Forth is about as dead as, say, mainframes.)

If Lua was as dead as Forth I'd have no fears at all for Lua's future.  (I don't have any fears at all for Lua's future.  Make of that what you will.)  Even the interminable and flame-ridden discussions over bike-shedding modules won't kill Lua.  They'll just get particularly vociferous participants thrown into kill files.

--
"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Gé Weijers
In reply to this post by Patrick Mc(avery-2
On Oct 19, 2011, at 5:56, "Patrick Mc(avery"
<[hidden email]> wrote:

>
> Okay let me rephrase, it this way, if we could trade weak tables and closures for a simple python/import mechanism then I think that would be better for the language. I think it needs to stay small to stay away from the bigger language's market but not so much that it is hard for a non-programmer to use and that non-programmer friendly features should trump advanced FP features.

Without closures Lua degenerates into another clumsy language. There's
plenty of those, laguages with lots of ad-hoc features and little
expressive power. Python actually implements a simple form of
closures. Java and C++ are getting there too.



Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Dirk Laurie-2
In reply to this post by Patrick Mc(avery-2
2011/10/19 Patrick Mc(avery <[hidden email]>:

> Okay let me rephrase, it this way, if we could trade weak tables and
> closures for a simple python/import mechanism then I think that would be
> better for the language.

No need to change the language.  Formulate conventions for the
directory structure of the library containing the modules, write a
program (by all means call it `setup.lua`) that generates a module
loader for each subtree, and the difference will be as insignificant
as this:

python:

import library.module as mylib

lua:

mylib = (require "library").module

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Patrick Mc(avery-2
{ snip}

> No need to change the language.  Formulate conventions for the
> directory structure of the library containing the modules, write a
> program (by all means call it `setup.lua`) that generates a module
> loader for each subtree, and the difference will be as insignificant
> as this:
>
> python:
>
> import library.module as mylib
>
> lua:
>
> mylib = (require "library").module
>
> Dirk
>
>
That would be gold! Would there be a performance penalty? Could this
also co-exist with the 5.2 mechanisms?

  If so why not? It would be so much nicer for non-programmers to work with.

Reply | Threaded
Open this post in threaded view
|

Re: S.W.O.T analysis

Patrick Mc(avery-2
On 11-10-19 10:42 AM, Patrick Mc(avery wrote:

> { snip}
>> No need to change the language.  Formulate conventions for the
>> directory structure of the library containing the modules, write a
>> program (by all means call it `setup.lua`) that generates a module
>> loader for each subtree, and the difference will be as insignificant
>> as this:
>>
>> python:
>>
>> import library.module as mylib
>>
>> lua:
>>
>> mylib = (require "library").module
>>
>> Dirk
>>
>>
> That would be gold! Would there be a performance penalty? Could this
> also co-exist with the 5.2 mechanisms?
>
>  If so why not? It would be so much nicer for non-programmers to work
> with.
>
>
Sorry on second thought, is there a way to do something like this(and
please keep in mind I have not touched Python for 3 years)

file foo.py
some foo function

import * foo
now I can call foo

That is, without having the use of functions in tables forced on me?

123