LUA is a great language

Who's with me?

lua rocks

>>36
I mean, it really isn't that hard in Lua.


function push (q, v) q[#q+1] = v end
function pop (q) local v = q[#q]; q[#q] = nil; return v end

>>41
MOONSTONES

If you think about it, Lua is replacing scientists with artists.

>>36
Back to Python. Understanding tables is paramount to using Lua. Tables can effectively emulate any container and more. They're like NAND gates. So universal and hot... they make me （　♥‿♥）.

Python has done a lot of damage to programming languages. It rehashes bad mistakes of programming languages, but covers it by giving the programmer a ridiculously large standard library in order to tempt them. And it has been successful, a lot of programmers now prefer a bad standard to a good non-standard, and it will be very difficult for new and innovative languages to gain marketshare in the future.

>>46
I realized that every time I want to do some plumbing I reach for Python, solely because it has its huge standard library. I plan to change that in the near future and use Perl and Lua instead.

>>47
There's nothing intrinsically wrong with a large standard library. Unfortunately, languages with large libraries tend to be shitty. As >>46 suggests, this may be because the only reason to stick with a language that you discover to be shitty is the massive library. You can view the growth cycle like this: toy language finds a niche, people like it in that niche and wish to expand it to everything, then you end up with a shitty language and a huge library.

>>46
Python 3 is an attempt to rectify some of the mistakes of Python. As usual, languages that concern themselves over backward compatibility always become an incomprehensible clusterfuck of awful.

>>48
Large standard libraries reduce the workload of the user of the language, it's obvious why they're universally hailed as good when they're monolithic and gargantuan.

There are lots of common things that people write in every language, so to save time, the author of the language decides that they should include a standardized structure/function/etc. within the standard library. Programmers appreciate this for obvious reasons, especially when the performance is on par or above what they could write.

Standard libraries don't inherently decrease performance, though they do make it harder to use the language on small devices. There's also the principle of abstraction that's becoming more and more important as techniques for everything are more advanced and there are more things to concern yourself over as a programmer.

The growth cycle works more like this:
1. "Hey, this language is pretty cool. It saves me a lot of time."
2. "Hey, language creator, save me more time by including <feature/class/whatever>!"
3. Language creator decides between one of two things.
3a. YES, I don't want to make my users angry.
3b. NO, my language only serves x purpose. That's what it's for and it will always be this way.
4a. "Wow, thanks for saving us so much time!"
4b. "Fine! Then I'll stop using your language!"
5a. Go to 2.
5b. "Very well, then. I still have my niche users. See you later."

Lua, of course, took the B route and I'm very glad they did. But there needs to be at least one language that takes the A route, because there is always something that you could do to "improve" a given language to certain constraints, there will always be a market for languages.

Of course, there are things we haven't discovered yet either, being that computer programming is still a relatively young field of study, less than 100 years old. As we continue to develop experience, knowledge, etc., it's going to be important to create new things to take advantage of these.

>>49
That raises the question of whether or not they did in fact fix them. I have several complaints (nonlocal/global, poor support for functional programming, everything is public) that I don't think guido will ever fix and I've been looking for a replacement because of that.

I also don't mean to suggest that a large standard library is inherently bad, I just feel that an over-large library leads to a kind of vendor lock-in.
I don't foresee any new programming languages hitting it off in the next decade (although I will no doubt be wrong) due to having an ever increasing barrier to entry.

>>50
That completely ignores the point that a programming language is not suitable for every purpose, and if it is suitable for every purpose, it's bloated.

One might argue that the barrier to entry is lower because you can create niche languages easier than ever before.

>>49
I'm not really sure that makes sense. A lot of popular languages don't have a benevolent dictator, and they are meant to be general-purpose languages. Scheme and C++ are two examples of this. It is interesting that as different as the languages are in terms of scope of the core, non-trivial programs written in either are also not trivially portable, yet there is a perception that C++ is more usable than Scheme, even though large distributions of both have a shitton of libraries (e.g. MS C++ and PLT Scheme).

>>51
That completely ignores the point that a programming language is not suitable for every purpose, and if it is suitable for every purpose, it's bloated.
Yes, absolutely. Sepples should have taught us that, but I think we need to be reminded of this every so often.

>>52
For all intents and purposes, the ISO committee is the "benevolent dictator" of Sepples. Lisp and its derivatives are the only languages that don't really have an overlord, and even some of the derivatives do.

>>54
Common Lisp doesn't have one, but as for Scheme
Scheme is also languages designed by dictators! PLT-Scheme has a dictator; Chez-Scheme has one; and so does Ikarus-Scheme. If you like the idea of having a single dictator, we have so many of them to choose from. That is, you have a choice in how to limit your own choices. :-)

The Standard here is like the "The Official Recommendations of the Sixth Meeting of The Council of Scheme Dictators".^[1]

<sub>-- References --
1. Abdulaziz Ghuloum, http://www.artima.com/forums/flat.jsp?forum=106&thread=255612</sub>

>>54
If you are willing to consider committees as dictators then every language has at least one dictator. That's not a particularly useful definition of "dictator," as it is a symbol that you may place in front of every group, it which case it fails to signify anything at all.

>>55
That's a funny way of putting it but it is 100% accurate and reflects the problems in C++ development as well.

The bottom line is probably that you cannot have a general-purpose language, as >>51 indicates, without leaving it relatively featureless or having it splinter into specific distributions.

IMO there's nothing wrong with sticking to a particular distribution, if that distribution is itself portable. What's strange is that C++ programmers never seem to be bothered much by it, while vocal schemers get tied in knots over it.

>>32
Everyone's talked about tables, but I might as well point out that the vararg can act like a linked list surprisingly well:

filter = function (f, a, ...)
  if a then
    if f(a) then return a, filter(f, ...) end
    return filter(f, ...)
  end
end


print(filter(function (z) return z % 2 == 0 end, 4, 5, 2, 7, 8, 3)) -->prints "4 2 8"

t = {1, 2, 3, 4, 5, 6, 7, 8, 9}
f = function (z) return z % 3 == 1 end
print(filter(f, unpack(t))) -->prints "1 4 7"

>>50
That raises the question of whether or not they did in fact fix them. I have several complaints (nonlocal/global, poor support for functional programming, everything is public) that I don't think guido will ever fix and I've been looking for a replacement because of that.
There are even more critical problems than this, both with the reference implementation and with the language design. Honestly they fixed almost nothing in the change to 3.0.

For example memory management is still reference counted. This is why even Google can't make it faster, because of the GIL. Jython is a rewrite to fix this.

Another problem is that the VM stack still grows on the native stack. It's still possible to crash the interpreter in a stack overflow. Stackless is a rewrite to fix this.

Of course since Python's massive library only really works with the reference implementation, these rewrites are fairly useless.

The language design itself also has more problems. The ones you mentioned are pretty critical; in particular how everything is public, and it internally renames fields based on naming convention (double underscore??) to prevent name clashes in inheritance trees.

I have a big problem with the inconsistent method syntax. For example, you implement x.__len__() to support calling len(x). Why don't you just implement x.len(), and call x.len(), like every other class method?

All this being said, Python is still the language I choose for almost any project that isn't performance-bound. You learn to live with its faults I guess.

I've never used Lua. Can someone explain the main differences between Lua tables and Python dicts?

>>58
Jython

Why the hell would they name it that? Couldn't they have just named it after a different snake instead of fucking with the consonants in Python?

>>55
And wait until all of those dictators sit on the Scheme Committees! I got myself signed up for the large Scheme working group.

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html

>>61
[warning very long]

>>58
I have a big problem with the inconsistent method syntax. For example, you implement x.__len__() to support calling len(x). Why don't you just implement x.len(), and call x.len(), like every other class method?
How did I miss that one? *facepalms*

I was also only complaining about the language itself, the implementations are, of course, a whole different matter.

>>58
I've never used Lua. Can someone explain the main differences between Lua tables and Python dicts?
Basically, they are a combination of a dict and a dynamically sized array, with an implementation that guarantees good performance and DWIM behaviour in most of the cases you can dream up, plus some syntactic sugar so you can make them look like objects, and a nifty metatable mechanism so you can cook up an object system of you preferred flavour (or anything else meta) in a few lines of code.

LUA

Lua was good for my project, I thought about using Python but Lua suited my needs better, I guess Python wouldn't have had that much overhead, but it just felt so full blown.
And growing your executable size/adding a dll by 150-200kB is better than dragging Python along with.

>>66
tinypy fits in 64kb.

>>67
No-one cares, phil

>>67
1.0 is 64 kb. The new versions are larger, after adding such complex features as the "math library".

>>69

C has a math library. I fail to see the problem.

>>66
That and it is shit to embed compared to Lua.

Can I use scientific libraries like LAPACK, BLAS?
Or, is there something like Boost++ or Numpy/Scipy?

http://docs.python.org/3.1/whatsnew/3.1.html

Mostly just tacks on more shit.

>>72
should have gone into plumbing if you enjoy using prefab shit so much

>>74
and I suppose you like to write in pure machine code, maybe a little assembly when you're feeling lazy

>>75
Scheme, Lua, and C. It's all you need.

>>76
Not really, being able to write in your platform's assembly can solve some problems those languages can't solve directly (at least without implementing an assembler in them and calling it, then running that code).

>>77
We were discussing awesome libraries, not your premature optimizations.

>>78
Not talking about that either. I rarely write assembly code, but when I do, it's absolutely necessary.

>>79
Please give an example. I program embedded systems and never have to use assembly (though I know it, should the need arise).