Domain: lua.org
Stories and comments across the archive that link to lua.org.
Comments · 125
-
Re:Yawn
Why don't they 1-index then?
Because they forget to, and because all the algorithms and data structures that they learned elsewhere, such as heap priority queues, have to have their logic changed between 0- and 1-indexing and between arrays that do and do not allow nil to be an element. For example, any SQL database will produce NULL values in the result of a LEFT JOIN statement, but in the iterator protocol used by Lua's for statement, nil is the terminator.
Are they that stupid?
Some people would interpret this question as carrying a hidden assumption that even if a language's design is flawed, a programmer can be just as productive in it as in any other language. If you are not trying to imply that, then yes, programmers are fallible, and a language design can help a programmer produce a correct program more quickly by protecting the programmer from his own mistakes. See, for example, widely cited accusations leveled at PHP. But if you are trying to imply that, then why not just have everybody program in assembly language?
-
Re:Most uninteresting
So, functions are first class data members? Is it weakly typed then, like Lua? In that language, defining a function is just syntactic sugar for assigning a chunk of code to a variable of the assigned name, so you can use it just like any other variable.
That's not quite the case in Lua, where a function can be a closure.
Most modern dynamic languages support closures, as do several statically typed ones (e.g. F#, OCaml, Scala).
-
Python is alright
Python is alright if you ignore the performance issues but the whitespace thing annoys the hell out of me. Cut and paste often results in broken code, even when I'm just trying to test something simple and stupid.
Lua is higher performance and cleaner than any other "easy" language out there IMHO. Kids should always learn C at some point though.
-
Re:Perl 6ers just can't get shit done.
- Perl 5 and earlier: An interpreter written in C.
Not exactly. The interpreter compiles the source files into a bytecode and executes it on a stack-based virtual machine: ahref=http://perlbin.sourceforge.net/perlcompiler/perl.internals.pdfrel=url2html-14852http://perlbin.sourceforge.net...>
- Python: An interpreter written in C.
A virtual machine in C: http://www.troeger.eu/files/teaching/pythonvm08.pdf
- Ruby: An interpreter written in C.
A virtual machine in C: http://en.wikipedia.org/wiki/YARV
Or in C++: http://rubini.us/
Or against the JVM (which is written in C++): http://jruby.org/
- Lua: An interpreter written in C.
A virtual machine in C: http://www.lua.org/doc/jucs05.pdf
- Tcl: An interpreter written in C.
A virtual machine in C: https://www.tcl.tk/community/tcl2002/archive/Tcl2002papers/kenny-bytecode/paperKBK.html
- PHP: An interpreter written in C.
Hey, you got one. However the they are currently revising the language to make it compatible with adding a JIT later: http://www.computerworld.com/s/article/9248637/PHP_keepers_plot_radical_revision_of_the_language
And Facebook has their own C++ VM: http://hhvm.com/
- UNIX shells: Interpreters written in C.
Different problem space.
-
Re:You mean it has ever been alive?
Actually I hear more about Lua than I hear about ruby.
FTFY. Lua is not an acronym. http://www.lua.org/about.htmlhttp://www.lua.org/about.html
-
Re:"So who needs native code now?"
Wow, completely and utterly wrong. Modern GC are faster than any other method for complex data and comparable for simple data. The first claim is well established and easy to prove: given an arbitrary graph of data to manage GC is the only algorithm which can manage it. If the graph is merely acyclic reference counting will do, but modern GC are still faster than any reference counting scheme. In fact a new reference counting scheme with a specialised allocator has just been developed which is almost as fast as GC, and that's considered to be quite a breakthrough. The primary problem with GC systems is that it is hard to make them real time, that is, to spread the load evenly so there's no noticeable jitter. Naturally if you have a simple data structure were the number of references is statically known, then the cost of determining if a block is unreachable can be reduced to zero. However unless you're using a language with a really advanced type system like ATS2 it will be very difficult to be certain your code is correct: the only serious exception to that is a purely stack protocol data structure. Indeed the poster is so completely ignorant e doesn't even realise Lua 5.2 actually uses a garbage collector: http://www.lua.org/manual/5.2/manual.html#2.5
-
Re:JavaScript, its better than a kick in the head.
Well supported in-browser? No, but Lua is a better Javascript than Javascript.
-
Doubtful
I doubt they looked a Lua because I'm sure it's one of the lowest if not the lowest. Definitely lower than Python. It's probably the most stable piece of software I use regularly.
-
Re:Finally Fixing the Date stuff
I think the most reasonable definition of syntactic sugar is that it is any feature of the language that can be achieved by a purely syntactic rewrite of the code (usually with the caveat that it can use otherwise unaccessible generated identifiers) - i.e. it's syntax that's a higher-level abstraction of another syntax. So e.g. while-loop is syntactic sugar for if+goto. In many cases, this kind of thing is explicit in the language spec. For example, if you read the language spec for Lua, it defines the for-loop as a syntactic rewrite.
I've never heard of the term carrying any negative connotations.
-
Re:Not that surprising
I'll just add a language where the team wasn't afraid to cull and rebuild major parts of it for better and cleaner architecture even though it's quite widely used. As the effect, it's arguably one of most elegantly engineered languages (and with LuaJIT - damn fast as well).
-
The same language
Java and C# are not different languages. They are the same language - much more similar than, for example Medley Common Lisp and Franz Allegro Common Lisp, and those are two implementations which both conform to the same published specification. Java and C# have very slightly different syntax, and slightly different core libraries. But if you can read (or write) one you can read (or write) the other. The compilers work in very much the same way, and even the object code and virtual machines are similar.
Which isn't surprising. Microsoft based C# on its own implementation of Java, changing it (only) just enough to get around legal problems with Sun. It's a very sincere flattery. C# is slightly newer, so it has slightly less legacy cruft. Apart from that, you are comparing apples with apples here. If you want a more interesting comparison, compare Java/C# with Ruby, Python, Lua, JavaScript/EcmaScript or Clojure.
-
Re:Ruby is Python for Asians
-
minetest, codecademy,
Many games use java and or lua.
Minetest-C55 Block style 3D building game. (Open source)
http://minetest.net/also
http://www.codecademy.com/
http://www.lua.org/http://en.wikipedia.org/wiki/Category:Lua-scripted_video_games
I haven't tried Infon Battle Arena (yet) though it looks promising. :) -
Re:if php is broken what is javascript?
-
Please, it's "Lua", not "LUA"
"Lua" (pronounced LOO-ah) means "Moon" in Portuguese. As such, it is neither an acronym nor an abbreviation, but a noun. More specifically, "Lua" is a name, the name of the Earth's moon and the name of the language. Like most names, it should be written in lower case with an initial capital, that is, "Lua". Please do not write it as "LUA", which is both ugly and confusing, because then it becomes an acronym with different meanings for different people. So, please, write "Lua" right!
-
Spell the language correctly
Even on Lua's site (which Fox links to), they have a section explaining how to spell and pronounce the name.
Please do not write it as "LUA", which is both ugly and confusing, because then it becomes an acronym with different meanings for different people. So, please, write "Lua" right!
You think they'd at least get that part right (when they link to the website).
-
Has anyone embedded Guile?
I've heard of Guile in the past, but I never managed to come across any application that actually uses it. Guile's own project list is rather meek, and whenever people talk about embedding a programming language, the talk appears to always shift to Lua. Does anyone know why no one picks Guile for any task? It would be great if it was possible to hear from anyone who actually gave Guile a try in any project.
-
Re:This isn't nearly as bad as the division bug
Not according to this:
The number type represents real (double-precision floating-point) numbers. Lua has no integer type, as it does not need it. There is a widespread misconception about floating-point arithmetic errors and some people fear that even a simple increment can go weird with floating-point numbers. The fact is that, when you use a double to represent an integer, there is no rounding error at all (unless the number is greater than 100,000,000,000,000). Specifically, a Lua number can represent any long integer without rounding problems. Moreover, most modern CPUs do floating-point arithmetic as fast as (or even faster than) integer arithmetic.
Perhaps you have a code snippet for a specific IEEE 754 machine that can prove otherwise?
-
Lua is fine, but has some small problems
For example, the lua table object is used by the standard library (table functions) to represent C arrays with integer indexes or more accurately C++ vectors. However, in general you should not attempt to use the resulting table object in any other way than provided for by the table functions. It would have been more user-friendly to have an own vector type for this.
Although it isn't a problem most of the time, sometimes you want to preserve the order in an associative array with non-numerical indexes like you are used to for example in PHP. As far as I know this can only be achieved by having a second table defining the order.
I really like using "or" to express default initialization anywhere though, this will assign "die" if funny is null (or false):
function be(funny)
funny = funny or "die" ..
end -
Re:Objective-C growth
Lua does intern all strings, which has many, many nice benefits.
However, if you are dealing with hundreds of megabytes of strings that are being mutated a lot, then this interning process may be a performance problem. However, there are usually good solutions to these kinds of problems. Hop on over to the Lua mailing list or Lua SubReddit and ask for advice. Many other languages often need high-perfomance byte string implementations that for some situations.
-
Objective-C growth
Objective-C's growth in popularity coincides with the Flurry Analytics study that showed most mobile developers targeting iOS, with support for Android dropping by a third over 2011. C# will probably continue to see increasing interest because of WinRT. Lua is unsurprising because of its popular use in games, and they just released 5.2 last December. What I find most interesting is that plain old C is set to overtake Java.
Of course, if you don't take the Tiobe rankings seriously, than all of this is moot, but I guess it's something to talk about on a Friday.
-
Lua (programming)
It seems no one has mentioned it yet, so I will.
I believe Lua (the programming language and virtual machine) is from academia -- the Pontifical Catholic University of Rio de Janeiro in Brazil.
Lua is used in a lot of games and embedded in a lot of software. I think even World of Warcraft makes use of it.
For more information and links, see About Lua.
-
Re:Lua would be better
Lua is very Javascript-like already except it's very small, simple, clean, and fast. Much faster; LuaJIT is incredible.
LuaJIT is not much faster anymore.
LuaJIT gets to about 2-3X slower than the fastest gcc, while the latest JS engines (V8 with CrankShaft, SpiderMonkey with TypeInference) get to 3-5X slower than gcc. That's still a significant difference, but the JavaScript engines are also improving faster. In a year or so the difference will have vanished.
Those numbers are also a little misleading. They are mainly simple benchmarks, where LuaJIT's tracer is phenomenal. But if you take a complete program, with a lot of use of classes/inheritance/closures/etc., LuaJIT won't do as well - it hasn't been tuned for those things. In other words, on real-world code the difference would be nonexistent or even reversed. But what is representative 'real-world code' is debatable so it's hard to come up with numbers for that. (But you will often see it in practice in the field.) -
Lua would be better
-
He must be kidding ...
The article doesn't contain a single argument for the use of Guile as an extension language. It tries to show off a few language features that LISP people will obviously love (and all other people never miss), but for an extension language other things should matter: small footprint, easy to pick up, no nasty surprises, successful use cases, robustness. Why the hell would one need to make the extension language extensible in an elegant way or want it to be "multi-paradigm"?
The sensible choice would be Lua and the GNU people should think long and hard about whether they really want to hamper their GNU evangelism by burdening it with evangelism for obscure (sorry LISP lovers) languages or perhaps choose something that doesn't get in the way of their important goals... -
The obvious answer used to be ZOE
Back in the day, ZOE was exactly what you're looking for. It's an open source, cross platform turn-key, solution (Simple Server is built-in) that is designed to archive, index and search your email (using the Apache Lucene search engine). Jon Udel has a good article on O'Reilly that includes some screen shots.
ZOE meets all of your requirements, though data import is a bit of a problem. There are several different strategies for data import, so one of them may meet your requirements.
Unfortunately, ZOE is abandonware so it's not for the faint of heart. The original author was on the bleeding edge and tended to make 'interesting' technology choices like Tapestry for the framework, and using his own, home-grown build system and a Creative Commons license that isn't usually used for software. He eventually abandoned Java development for Lua and let the registration for the home page lapse. As a result, it's difficult to recommend this for all but the most determined, high functioning users.
-
Ruby is irrelevant
There's plenty of programming languages out there worth learning as a primary language and ruby isn't one of them.
Ruby is one of those languages that you learn in addition to another more general language. In that respect, PHP and ruby are about the same. As respects performance, both PHP and ruby are toys.
-
Re:it's an interesting case
``It's hard to place the language in any camp, because it does furnish functional programming and object-oriented features without really committing to the dogma of either one. It gives you a ton of interesting features that seem to work really well in concert''
There actually is a camp for languages like that. They're called multi-paradigm languages, and I believe a language that can elegantly express many paradigms is a Good Thing. Languages commonly considered to be multi-paradigm include Ruby, Lua, Common Lisp, and OCaml.
-
Re:Don't worry
everyone will get fed up and just use the next big thing instead.
I predict. lua.
That would be the next small thing; the reference Lua interpreter is only 153kB apparently...
-
Re:Already possibleYou raise a good point with your analogy, but it's not quite so apt. While you are correct in analyzing this as a cost-benefit ratio, you make the mistake of ignoring the fact that third-parties already have invested most or all of the cost, and have made their services available to anyone for free! The current state of things is such that:
- There are already free services that do refreshing and time-tracking.
- There are plenty of scripts available that already do that.
- Writing a LUA script is extremely simple
Due to the current suites of tools available, the cost-benefit is extremely low. This change increases the accuracy of the results and decreases the work necessary for existing sites to perform. They're already performing, mind you
... it's just less load on theirs and Blizzard's servers now.I would wager that the largest impact this change has is:
- How these third-party sites gain their data, and
- The cost of entry for new third-party sites
From the user's point of view, things will likely remain relatively constant.
-
Re:Getting JS out of the browser is a *great* idea
The idea of Javascript is nice. In practice it's hardly what you describe.
Consider how closures work in Javascript. It's totally retarded and the scoping doesn't work like you think it would.
Lua has basically the same semantics as Javascript but it much simpler, faster, and you get a better design (eg. closures work like they should). Lua is a better Javascript than Javascript.
-
Re:How about a Javascript - to - python convertor?
In most ways (no explicit integer type being an exception) Javascript is a remarkable and beautiful language.
Sort of. It actually sucks, just look at the gigantic EMCA specification and all the convoluted crap in Javascript. The semantics are nice though. The thing is, Lua also has these beautiful semantics and is actually quite similar to Javascript. EXCEPT, Lua actually is beautiful. Very tiny, easy to embed, easy to extends, fast, powerful, simple specification. All that and it does practically the same thing as Javascript. Lua is what Javascript should have been.
-
You want fun?
I sure wouldn't be doing Python (gack, too verbose, might well be using C or Java) or Ruby (slow, slow, slow).
Use Lua.
-
Re:Expect to see much more of this in the future..
I don't know why you hate web applications so much but I agree that Javascript is a horrible language. The specification is gigantic and the language is overcomplicated.
Lua makes a much better Javascript than Javascript. Small, lightweight and fast. Besides the syntax differences Lua is otherwise semantically very similar to Javascript except with a much better design... and Lua does it with a minuscule language syntax and VM.
-
Re:At least one Wii game uses opensource
"Lua is free software: it can be used for any purpose, including commercial purposes, at absolutely no cost. No paperwork, no royalties, no GNU-like "copyleft" restrictions, either."
Released under the MIT license, which is a pretty typical non copyleft OSS license. What the author probably meant was that Nintendo prohibits copyleft licenses, which is a small technicality. -
Re:Again: Why? Has anyone actually thought about w
-
Re:JavaScript assembly language
I don't know, Lua would fit that role a whole lot better. It's semantically similar to Javascript but is much cleaner. Javascript is a disgusting hack of a language with bizarre bit and pieces shoehorned into it over the years.
The fastest Javascript engines will never be as fast as the fastest Lua engines. Javascript is too tied down by cruft. LuaJIT already beats every other Javascript engine out there in all tests except a few and it's not even using tracing yet (the fastest JS engines are using tracing). LuaJIT 2 with tracing is supposed to be out at some point here and that will probably blow the doors off everything else.
-
Pure scripting: Lua
I'm surprised there was no mention of Lua. Besides Javascript, Lua is probably the most widely used scripting language out there. Usually its use is hidden from the end-user but it's in everything from embedded devices to World of Warcraft.
It has a very simple design and is very fast (especially with LuaJIT). The semantics are similar to Javascript but Lua is a lot more pure and simple. There probably will never be a Javascript engine as fast as the fastest Lua engines.
-
Re:That's great!
If there's one thing that will make me buy into the whole browser-as-OS thing, it's an efficient, bare-bones and flexible Javascript implementation, kind of like programming in C for your browser.
Then consider Lua. Lua would have made a better Javascript than Javascript. While the syntax is different, the semantics between Lua and Javascript are almost the same (basically the languages are twins). Lua is a whole lot more pure though. Simple and with LuaJIT way faster than any Javascript engine I have tested. Lua is incredibly small and easy to embed too. It has the same power as Javascript though.
I believe the Javascript language itself has critical design flaws that will keep it from reaching the performance levels of better designed scripting languages. Read the history of Javascript. It grew out of Netscape as a hack. Very poor planning left lots of room for all kinds of crap patches and hacks leading up to the huge EMCA specification. It's a big mess really.
-
Lua
Lua:
Official website: http://www.lua.org/
Direct link to manual: http://www.lua.org/manual/5.1/
Lua community: http://lua-users.org/wiki/ -
Lua
Lua:
Official website: http://www.lua.org/
Direct link to manual: http://www.lua.org/manual/5.1/
Lua community: http://lua-users.org/wiki/ -
Re:Think Python
Meh, Python sucks as a programming language. As verbose as C/C++ with all the slowness of a large scripting language, wee!
There are better scripting languages such as Lua which would be perfect. Once they learn that they will also have a leg-up on learning Javascript because it has a very similar feel (JS is poorly designed though so I wouldn't suggest learning that first). Then they can go about learning Python if they want to. Personally I see no reason to use that awful language. Perl would even make more sense because it provides a nice concise interface for text processing.
-
Re:Glaring Omission: Groovy
-
Cool, with C you can run Lua
OK, I admit I learned Lua programming Warcraft addons, but I've found Lua to be a really friendly language for the hobby-programmer that I am, and now I'm using it for other projects. If a brower could run Lua I'd be tempted to take my web pages beyond HTML and CSS.
-
Lua
If you're partial to Lua, it has SQLite bindings (and various other DB engines).
I've not used LuaSQLite personally so I can't give you a code sample, but I wouldn't imagine it would be much more code than the Python example.
As a bonus, Lua was primarily designed as an embedded language (of course Python can be embedded too). -
Re:The problem is ruby
True but Python is just the next step towards Lua which will eventually show everyone up. Lua is tiny, fast, easy to extend, and simple yet powerful enough to do anything the other scripting languages can do (the LPeg extension is especially excellent).
Although there is no real web framework for Lua, it's only because no one has taken the time (the Kepler project has done some work in this area but I don't really care for their stuff). -
Regular expressions are out
Parsing Expression Grammars are the future.
They are generally faster and more powerful. It's easy to do regular expression-like stuff as well as really complicated things like a programming language parser.
Lua's LPeg extension is really excellent. -
My listMy list wish-list of "languages to learn next" looks something like this, in no specific order:
Haskell
Ruby
Erlang
R
Prolog
Groovy
Scala
Lua
Lisp
Smalltalk
Scheme
Ocaml
Ruby and Erlang are the two I've spent the most time with so far. I like Ruby enough so far, that I've decided to write the initial
batch of install scripts for OpenQabal in Ruby.
Outside of that wish-list, I also harbor some vague hope of one day finding time to dabble with Forth, Fortran, Perl, and maybe Dylan. -
Re:About Parrot ..Also, the register based parrot engine underneath is supposed to be much faster than the purely stack based
.net and java VMs. Lua is arguably one of the fastest dynamic scripting languages. It is very small and lightweight with a very tight core. It wasn't long ago that it was switched from a stack based VM to register based and the performance difference wasn't that great at all. The benchmarks I have seen on Parrot seem to support this.
Also, Parrot is considerably slower than the Lua VM despite being much larger. The Lua compiler, VM, and runtime environment is WAY smaller than just the Parrot VM alone. -
Lua lends itself well to FP and has tail calls
If you like Python, you might also want to try Lua for FP. Unlike Python, it does feature tail call optimization and named functions work exactly the same as anonymous lambda-style constructs.