TIOBE: Lua in the Top 20

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

TIOBE: Lua in the Top 20

Hisham Muhammad
And Lua makes the TIOBE headline again:

http://www.tiobe.com/tpci.htm

Congrats!

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

Glauber Prado
Hisham Muhammad wrote:
And Lua makes the TIOBE headline again:

http://www.tiobe.com/tpci.htm

Congrats!

-- Hisham

a useless post but to make some voice here, congrats!

Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

Frederico Rodrigues Abraham-2
hehe
its made the top 18 already :)
--- Fred
Hisham Muhammad wrote:
And Lua makes the TIOBE headline again:

http://www.tiobe.com/tpci.htm

Congrats!

-- Hisham

a useless post but to make some voice here, congrats!



Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

Spencer Schumann-2
The detailed chart for Lua (http://www.tiobe.com/tiobe_index/Lua.html) shows a huge jump in popularity in the last few months.  Does anyone have a theory as to what caused this dramatic rise? 
Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

Petite Abeille

On Jul 10, 2007, at 19:54, Spencer Schumann wrote:

The detailed chart for Lua (http://www.tiobe.com/tiobe_index/Lua.html) shows a huge jump in popularity in the last few months. Does anyone have a theory
as to what caused this dramatic rise?

A bug in TIOBE's code?


Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

Roberto Ierusalimschy
In reply to this post by Spencer Schumann-2
> The detailed chart for Lua (http://www.tiobe.com/tiobe_index/Lua.html) shows
> a huge jump in popularity in the last few months.  Does anyone have a theory
> as to what caused this dramatic rise?

The book "Beginning Lua Programming"? It has the exact fragment
"Lua programming" that TIOBE looks for, and it was released exaclty
when Lua's index did the big jump...

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

xxmplus
On 7/11/07, Roberto Ierusalimschy <[hidden email]> wrote:
> The detailed chart for Lua (http://www.tiobe.com/tiobe_index/Lua.html) shows
> a huge jump in popularity in the last few months.  Does anyone have a theory
> as to what caused this dramatic rise?

The book "Beginning Lua Programming"? It has the exact fragment
"Lua programming" that TIOBE looks for, and it was released exaclty
when Lua's index did the big jump...

-- Roberto


World of Warcraft was released during that time, I bet it's the reason.
--
Any complex technology which doesn't come with documentation must be the best
available.

Reply | Threaded
Open this post in threaded view
|

RE: TIOBE: Lua in the Top 20

Patrick Donnelly-2
In reply to this post by Hisham Muhammad

> On 7/11/07, Roberto Ierusalimschy <[hidden email]> wrote:
> > > The detailed chart for Lua (http://www.tiobe.com/tiobe_index/Lua.html) shows
> > > a huge jump in popularity in the last few months. Does anyone have a theory
> > > as to what caused this dramatic rise?
> >
> > The book "Beginning Lua Programming"? It has the exact fragment
> > "Lua programming" that TIOBE looks for, and it was released exaclty
> > when Lua's index did the big jump...
> >
> > -- Roberto
> >
>
> World of Warcraft was released during that time, I bet it's the reason.

WoW was released in 2004. The spike occurred in early 2007. I doubt WoW had anything to do with it, unless you think a couple thousand people got Burning Crusade because they could write addons in Lua.

I got started in Lua because of WoW. Probably the only thing good I got out of that devil game.


-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing to do and always a clever thing to say."

-Will Durant

Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

jason-lu
In reply to this post by Spencer Schumann-2
Spencer Schumann wrote:
The detailed chart for Lua (http://www.tiobe.com/tiobe_index/Lua.html) shows a huge jump in popularity in the last few months. Does anyone have a theory as to what caused this dramatic rise?

I became re-interested in Lua since Adobe Lightroom was released in late February, 2007. The rumors of an SDK (requiring lua skills) after the 1.1 release prompted my subscription to this list (yes, 1.1 has been released, but no, the SDK hasn't been released yet).

Jason


Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

Sherry Zhang
On 7/12/07, [hidden email] <[hidden email]> wrote:
Spencer Schumann wrote:
> The detailed chart for Lua (http://www.tiobe.com/tiobe_index/Lua.html)
> shows a huge jump in popularity in the last few months.  Does anyone
> have a theory as to what caused this dramatic rise?

I became re-interested in Lua since Adobe Lightroom was released in late
February, 2007.  The rumors of an SDK (requiring lua skills) after the
1.1 release prompted my subscription to this list (yes, 1.1 has been
released, but no, the SDK hasn't been released yet).

Jason



I became interested in lua when I heard about the LuaTeX project.
It is great fun to embed a functional/dynamic programming language into TeX.
but I wonder whether Lua can do the job because it lacks full support
for Unicode strings, and it is too slow to use Lua to handle the
Opentype/Truetype font information, especially CJK fonts.

Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

Luiz Henrique de Figueiredo
> I became interested in lua when I heard about the LuaTeX project.
> It is great fun to embed a functional/dynamic programming language into TeX.
> but I wonder whether Lua can do the job because it lacks full support
> for Unicode strings, and it is too slow to use Lua to handle the
> Opentype/Truetype font information, especially CJK fonts.

If you can, go to TUG 2007 next week and see for yourself and ask the
LuaTeX people. They seem quite enthusiastic about Lua in TeX.

Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

David Kastrup
In reply to this post by Sherry Zhang
"Sherry Zhang" <[hidden email]> writes:

> I became interested in lua when I heard about the LuaTeX project.
> It is great fun to embed a functional/dynamic programming language
> into TeX.  but I wonder whether Lua can do the job because it lacks
> full support for Unicode strings, and it is too slow to use Lua to
> handle the Opentype/Truetype font information, especially CJK fonts.

Handling Unicode support in TeX as compared to Lua is like shooting
yourself in the foot with a mortar rather than with lawn darts.

I'd still very much prefer a Lua variant which defaults to uninterned
strings _until_ one uses them for indexing.  But it still beats using
TeX for string manipulation.

-- 
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

Tony Finch
On Thu, 12 Jul 2007, David Kastrup wrote:
>
> I'd still very much prefer a Lua variant which defaults to uninterned
> strings _until_ one uses them for indexing.

What would be the advantage of that?

Tony.
-- 
f.a.n.finch  <[hidden email]>  http://dotat.at/
ROCKALL WEST MALIN: WEST BECOMING VARIABLE 3 OR 4, OCCASIONALLY 5 AT FIRST.
SLIGHT OR MODERATE. RAIN OR SHOWERS, FOG PATCHES. MODERATE OR GOOD,
OCCASIONALLY VERY POOR.

Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

David Kastrup
Tony Finch <[hidden email]> writes:

> On Thu, 12 Jul 2007, David Kastrup wrote:
>>
>> I'd still very much prefer a Lua variant which defaults to uninterned
>> strings _until_ one uses them for indexing.
>
> What would be the advantage of that?

It would open the possibility for later implementing compacting
garbage collection of the string pool.  It would also prevent cache
poisoning (a principal feature of large hashes and string copying).
It would spead up the creation and handling of throwaway strings that
are never needed for indexing and possibly even never at all: since
Lua is quite viable as an _extension_ language, making the passing of
string data into and out of it as cheap as possible is a boon.  Not
interning throwaway strings into the global string table will help to
keep the global string table limited in size implying fewer cache
misses for every operation involving it.

So it benefits _both_ operations not needing the hash _and_ those
needing the hash to postpone interning strings.  The only operations
where interning is useful is indexing and comparison for equality.
Comparisons for equality where a large prefix of the compared strings
matches are not really likely to occur often, and indexing would
trigger interning.

-- 
David Kastrup


Reply | Threaded
Open this post in threaded view
|

RE: TIOBE: Lua in the Top 20

Vijay Aswadhati
In reply to this post by David Kastrup
On Thursday, July 12, 2007 12:57 AM, David Kastrup wrote:

> I'd still very much prefer a Lua variant which defaults to
> uninterned strings _until_ one uses them for indexing.  But it
> still beats using TeX for string manipulation.  

Count my vote as well, perhaps for Lua 6.0? In Ruby strings are
mutable. Ruby introduces a new type called 'symbol' that are
interned and used for indexing and comparison [1]. I think such a
scheme would resolve a couple of issues (at least for me); for
example I could then use Lua string for mutable binary data buffers
instead of having to create a new user data.

While we are off topic, let me also include my wish for an integer
number type. I hate to maintain special builds of Lua.

-- Vijay

[1]
http://blog.zacharypinter.com/articles/2005/12/13/what-are-ruby-symb
ols



Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

David Kastrup
"Vijay Aswadhati" <[hidden email]> writes:

> On Thursday, July 12, 2007 12:57 AM, David Kastrup wrote:
>
>> I'd still very much prefer a Lua variant which defaults to
>> uninterned strings _until_ one uses them for indexing.  But it
>> still beats using TeX for string manipulation.  
>
> Count my vote as well, perhaps for Lua 6.0? In Ruby strings are
> mutable. Ruby introduces a new type called 'symbol' that are
> interned and used for indexing and comparison [1]. I think such a
> scheme would resolve a couple of issues (at least for me); for
> example I could then use Lua string for mutable binary data buffers
> instead of having to create a new user data.
>
> While we are off topic, let me also include my wish for an integer
> number type. I hate to maintain special builds of Lua.

I actually don't see much of a point with that.  Integers convert into
floats fast, and Lua being an interpreted language not being able to
make use of register scheduling and other compilation tactiques,
performance impact on modern architectures is negligible.

While conceptually integers and floats may be less similar than
interned and non-interned strings, there is no significant performance
advantage gained from letting this difference into the language, with
the single difference from converting large amounts of data structures
repeatedly and tentatively that might not get processed by Lua at all.

What might be more interesting for this kind of enterprise is a
non-opaque structured user type.  Supporting more diverse basic data
types in such structures might make the need for them inside of Lua
itself less compelling.

-- 
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: VM object types (was: TIOBE: Lua in the Top 20)

Mike Pall-75
Hi,

Vijay Aswadhati wrote:
> Count my vote as well, perhaps for Lua 6.0? In Ruby strings are
> mutable. Ruby introduces a new type called 'symbol' that are
> interned and used for indexing and comparison [1]. I think such a
> scheme would resolve a couple of issues (at least for me); for
> example I could then use Lua string for mutable binary data buffers
> instead of having to create a new user data.

Ruby's mutable strings create all sorts of difficulties when one
tries to speed it up (e.g. by compiling it). This is a common
symptom of Ruby's excentric semantics: it's slow as molasses.

And ... IMHO mutable strings probably won't have less management
overhead than buffers implemented with userdatas. Yes, I know,
passing userdatas to C APIs expecting plain strings doesn't work
right now. But this can be changed.

David Kastrup wrote:
> Vijay Aswadhati wrote:
> > While we are off topic, let me also include my wish for an integer
> > number type. I hate to maintain special builds of Lua.
> 
> I actually don't see much of a point with that.  Integers convert into
> floats fast, and Lua being an interpreted language not being able to
> make use of register scheduling and other compilation tactiques,
> performance impact on modern architectures is negligible.

This is certainly true on all common, non-embedded platforms as of
today.

> While conceptually integers and floats may be less similar than
> interned and non-interned strings, there is no significant performance
> advantage gained from letting this difference into the language, with
> the single difference from converting large amounts of data structures
> repeatedly and tentatively that might not get processed by Lua at all.

I agree that it shouldn't spill into the language. A sufficiently
advanced VM (probably employing a compiler, not an interpreter)
needs to use type inference, anyway. This allows narrowing of
numbers to integers whenever it's profitable (e.g. for array
indexing).

> What might be more interesting for this kind of enterprise is a
> non-opaque structured user type.  Supporting more diverse basic data
> types in such structures might make the need for them inside of Lua
> itself less compelling.

Funny coincidence ... some random code:

local TValue = typedef.union{
  "n",          "number",
  typedef.struct{              -- Anonymous struct
    typedef.union{             -- Anonymous union
      "gc",     "gcobject",
      "p",      "ptr",
      "i",      "int32",
    }
    "type",     "int32",
  },
}
local Stack = typedef.varray(TValue)

local stack = Stack()
for sp=1,100 do
  stack[sp].type = TYPE.INT    -- Sub-tables are created on-demand
  stack[sp].i = 42
end

typedef.def("ssaref", "short")
local FuncState = typedef.struct{
  ...
  "base",	"int",
  "value",      typedef.varray("ssaref"),
  "varname",    typedef.varray("string"),
  ...
}

local function searchvar(F, name, top)
  for v=F.base-1,1,-1 do
    if F.varname[v] == name then
      return VT.LOCAL, F.value[v]
    end
  end
  ...
end

I think you get the idea ... just pretend ever aggregate is a
table. Standard Lua syntax can then be used to access structs and
arrays. This works even on plain Lua with an emulation layer
(create sub-tables for sub-structures when accessed etc.).

But when compiled, only the raw structures are allocated and all
accesses are translated into efficient machine code. And the GC
traversal is compiled on-demand, too. (No, I'm not there yet ...)

Bye,
     Mike

Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

Alex Queiroz
In reply to this post by Vijay Aswadhati
Hallo,

On 7/13/07, Vijay Aswadhati <[hidden email]> wrote:

Count my vote as well, perhaps for Lua 6.0? In Ruby strings are
mutable. Ruby introduces a new type called 'symbol' that are

    Plus Ãa change...

--
-alex
http://www.ventonegro.org/


Reply | Threaded
Open this post in threaded view
|

Re: VM object types (was: TIOBE: Lua in the Top 20)

Roberto Ierusalimschy
In reply to this post by Mike Pall-75
> And ... IMHO mutable strings probably won't have less management
> overhead than buffers implemented with userdatas. Yes, I know,
> passing userdatas to C APIs expecting plain strings doesn't work
> right now. But this can be changed.

This seems a more promissing approach. Diego suggested something in
these lines some time ago. (Of course, the userdata must be converted to
a char*, not to a Lua string; this is tricky with metamethods...)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: TIOBE: Lua in the Top 20

Sherry Zhang
In reply to this post by Vijay Aswadhati
On 7/13/07, Vijay Aswadhati <[hidden email]> wrote:
On Thursday, July 12, 2007 12:57 AM, David Kastrup wrote:

> I'd still very much prefer a Lua variant which defaults to
> uninterned strings _until_ one uses them for indexing.  But it
> still beats using TeX for string manipulation.

Count my vote as well, perhaps for Lua 6.0? In Ruby strings are
mutable. Ruby introduces a new type called 'symbol' that are
interned and used for indexing and comparison [1]. I think such a
scheme would resolve a couple of issues (at least for me); for
example I could then use Lua string for mutable binary data buffers
instead of having to create a new user data.

While we are off topic, let me also include my wish for an integer
number type. I hate to maintain special builds of Lua.

-- Vijay

[1]
http://blog.zacharypinter.com/articles/2005/12/13/what-are-ruby-symb
ols



integer is also a probelm for LuaTeX.
TeX has no support for floating number while Lua has none for integer.....

12