LUA is a great language

Who's with me?

yeah, why not

YEAH!  I've never used it

>>1
Not the creators of Lua, that's for sure.

>>1
Not the creators of Lua, that's for sure.^{[citation needed]}

>>5
Do the citation or back to wikipedia

I'm looking forward to finding time for learning how to embed lua in C. And the other way around. Somehow. Like nmap and awesome.

And world of warcraft, hurr

>>7
Something is not clear to me... I never heard a WoW player which is also a good programmer. A good programmer has no time for playing wow. The Real Programmer has no time for eathing either.


Besides: sorry for all that spoiler tags, but I didn't want to ruin the surprise of reading >>7san's spoiler tags.

>>8
Real programmer=greased neckbeard chewing junk food in damp basemnet?

>>8
I wouldn't say it's wow players who write this mods. Some devs probably.

>>8
eathing

>>9
somewhat. but you can be a skilled neckbeard or a unskilled one.

Best Languages
1 - Scheme
2 - Lua
3 - C
shit tier - everything else

>>13
Best Toy Languages
1 - Scheme
2 - Lua
3 - Lisp

Fixed that fer ya

>>14
Best Toy Languages
1 - Scheme
2 - Lua
3 - Lisp

Fix'd that 4 u

>>15
Best Toy Languages
1 - Scheme
2 - Lua
3 Lisp
Fix'd that 4 u

>>16
(best-toy-languages
  '((1 . Scheme)
    (2 . Lua)
    (3 . Lisp)))

(fixed 'that 4 #\u)

What's the best Scheme implementation for embedding?

>>5
http://www.lua.org/about.html#name

I believe you have been told. YHBT.

>>14
A scripting language as powerful and in such widespread use as Lua simply cannot be called a toy language.

http://www.satori.org/2009/03/the-engine-survey-general-results/

>>19
A scripting language as powerful and in such widespread use as Lua simply cannot be called a toy language.
In /prog/ everything can be called a toy language.

>>20
Okay. That may be true, but they still can't call C a toy language without being an obvious troll.

>>21
>>14 was an obvious troll, too, but that didn't stop you from being Troll'd.

>>21
There are no toy languages, except maybe Go, which I guess is Google's toy.

>>19
People who say "LUA" aren't mistaking it for an acronym, they're just saying it VERY LOUDLY.

>>24
That's why they say "LUA is a great language" instead of "LUA IS A GREAT LANGUAGE," right?

>>23++

What's the best Scheme implementation for embedding?

>>27
In which language? There are about 1000 different scheme implementations if you look hard enough.

>>28
In C. Basically, what is the most suitable Lua replacement in the Scheme world? I tried Googling, but the 1000 different Scheme implementations are obscuring my view.

>>29
Tinyscheme? It's what the GIMP uses. There is another popular embedding one, but I can't remember which one atm.

>>30
[u]GNU[/i] Guile.

About LUA I have to say that I'm impressed by the good design they made, but I feel a little disappoint by the seeming total lack of library.

By example, what if I need a fucking linked list, queue or stack?

>>32
By example, what if I need a fucking linked list, queue or stack?
You write one? Annoying yes, difficult no.

>>32
Have you read your `Programming in Lua' today?

It shows with many examples how to coerce tables into effectively being whatever data structure you want them to be, with minimal code. After reading it, I'm pretty convinced that Lua really doesn't need a standard container library.

>>32
If you can't turn an associative array into a queue, back to reddit.

>>33
>>34

Well, of course, but take it in python:

l = []
l.push(10)
hax = l.pop(0)
Easy peasy.

Today's needs is: be slow. I don't want to waste my time in reimplementing the wheel while I have a lot of things to do.
It can be feasible in C, where my first objective is to produce some highly optimized code, but from a high level language I expect to have a container library.

>>36
Perhaps you have fundamentally misunderstood the point of lua. Back to python with you.

>>37
Ouch! Can you please enlighten me on it? (srsly, not trolling)

>>38
Small, easily embeddable. It's goal was not anything like batteries included. You can run lua easily on microcontrollers. It's the most popular scripting language in game development. Etc. It is not there to provide your favorite container class.

>>39
I see. Well, I guess there should be some minimal libraries as well. ...probably it's some third party stuff.

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

>>80
Examples of such usages:
 1) Writing some code hook library. This means you have to assemble some call's/jump's at specific places, as well as possibly disassemble some code which was replaced by the jump/call and reassemble it someplace else.
 2) Adding a new VOP(a sort of instruction which will get translated to native code) to a compiler for efficienty purposes. For example you want to make a compiler use some specific FPU instructions for floating point calculations, or maybe you want to add support for MMX/SSE/...
 3) Calling an interrupt directly or writing an interrupt handler. Such code can arise both on user-mode and in kernel-mode(driver).
 4) Writing a custom boot loader.

Most of the time I have to do this is when I'm interoperating with proprietary code which I don't have the source code to, but it can be needed even outside of such situations.

>>81
2) is kind of a trivial case. Obviously you would need assembly at some point to write a compiler that compiles to machine code.

84 Name: Anonymous 2011-05-15 14:31

Ignore this.

 _______
|       |
|       |
|       |
|       |
|_______|