Slashdot Mirror

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?

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 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.

- 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.

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

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

Well supported in-browser? No, but Lua is a better Javascript than Javascript.

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.

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.

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).

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.

Then use Lua, or even better LuaJIT.

Ruby is for suckers. Suckers that like slow-ass software.

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. :)

Exactly.

Lua is better and has been around for ages. Very stable, simple, powerful, and faster than everything else (LuaJIT is probably the fastest scripting language ever made).

"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!

http://www.lua.org/about.html

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).

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.

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?

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

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'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.

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.

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 is very Javascript-like already except it's very small, simple, clean, and fast. Much faster; LuaJIT is incredible.

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...

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.

There's plenty of programming languages out there worth learning as a primary language and ruby isn't one of them.

• go
• javascript / V8 see also node.js
• lua and luaJIT
• racket
• ...

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.

``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.

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...

• 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.

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.

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.

I sure wouldn't be doing Python (gack, too verbose, might well be using C or Java) or Ruby (slow, slow, slow).

Use Lua.

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.

"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.

Lua is not an acronym. It's the name of the Moon in Portuguese.

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.

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.

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:
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:
Official website: http://www.lua.org/
Direct link to manual: http://www.lua.org/manual/5.1/
Lua community: http://lua-users.org/wiki/

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.

http://www.lua.org/

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.

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).

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).

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.

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.

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.