Slashdot Mirror

Why would anybody want to migrate towards a new Open Source database server when there are already two, one of which is its own bastard cousin? See, if the fact of your DB server being Open Source is that vitally important -- say, a "no source, no sale" procurement policy -- then you will already have chosen one of the Big Two:

PostgreSQL is an indirect descendant of an earlier version of Ingres; and, having been Open Source all along, ought to have improved slightly faster than the original Ingres project. It has a reputation for slowness; but, then again, so does Ingres.

MySQL is undisputedly fast; but when you actually look at what it had to jettison in order to get that speeds boost, you might think twice about deploying it. Think of it more as a sort of scripting language extension for handling a special kind of array, than a "proper" relational database server. {But, said the amateur tech pundit, watch out; because someday soon, Lua is going to find its way into MySQL, giving it those fancy "staw'd pro-cee-joor" deeleys.}

If it is not important that you are using an Open Source solution, and you aren't using one of the Big Two anyway, why are you going to suddenly want to switch to Open Source? And if you were already thinking of switching to Open Source, chances are you've already chosen Postgres or My.

Why not Lua or Ruby? They can both be embedded easily (and Lua has even been used in Monkey Island 4). Were there other advantages for PHP?

There are other goodies in yzis, like syntax highlighting file (which will soon be used for folding too) written in xml and easier to write than the one of vim.

Lua is spectacularly elegant. A functional language just as powerful as any other, but very simple and readable.
Also has a powerful alternative to object programming.

As an introduction to progamming, PDA programming is a good start, because small programs can be useful on these. is a Lua implementation for Palm with a simple and effective integrated UI language that is all thoughtfully designed.

Lua switched from a stack based VM to a (semi-unbounded) register based VM for Lua 5. The speed improvement is quite noticeable (>30% if you do not account for time spent in C libraries). And there is still room for improvement if you are willing to drop portability and/or debugging/tracing.

The source code is very concise and reads nicely. The VM interpreter core loop is < 400 lines in src/lvm.c. Read this along with src/lopcodes.h.

Please read and understand both Lua 4 and Lua 5 VM core BEFORE designing your own VM. Go and download the code at www.lua.org/ftp/, it's less than 200K each.

BTW: It has tail calls, too.

No, people certainly don't use Prothon. And there is only a small group of people using Slate. However, there was once a lot of folks using an older proto-oo language with a biggish installed base and lots of apps to be found written in it: NewtonScript, the preferred language on the Newton PDA lines.

But that can be brushed aside- the Newton is all but dead. There happens to be another proto-oo language that is used quite a bit- Lua. It is a pretty heavily used scripting language, incidentally a lot like NewtonScript. It is small- 100KB runtime and base lib, very easily embeddable (esp compared to monsters like Python and Perl), and used a lot in gaming scripting languages.

So what's wrong with Io? It's been around for a while and announced on Freshmeat. Also already has code written in it. Or Lua, which has been around longer. Or, hell, just update one of the Self implementations. Why yet another language implementation other than ego?

If you want a nice, clean, prototype-based OO scripting language, check out Lua. Its implementation is mature, it is widely used (a favorite among game developers), and it compiles into compact executables. It also has one of the fastest scripting language interpreters around (short of a JIT). And there are excellent tools for binding C and C++ code to it.

Lua is the embedded interpreted language of choice for game designers.

Says who? I only recognize 3 of the games on their list, and the major game engines are all conspicuously absent.

Maybe it's a great choice, but it doesn't look like game designers have made it "the language of choice."

Lua is the embedded interpreted language of choice for game designers. Lua's great for writing the game AI (you don't have to wait for a half hour C++ build). Lua's under 200K, threadsafe, has good OO abstractions, integrates with C very easily, and most important of all - it has a commercial friendly license.

Lua is the embedded interpreted language of choice for game designers. Lua's great for writing the game AI (you don't have to wait for a half hour C++ build). Lua's under 200K, threadsafe, has good OO abstractions, integrates with C very easily, and most important of all - it has a commercial friendly license.

How about Lua?

Lua

adict = {key='val', key2='val2', key3=3.14}
for k,v in adict do
print(k.." -> "..v)
end

Why is Lua relevant to this thread? For better or worse, Lua is very small, in a number of dimensions. The number of things you have to remember is small, and you can get by with even fewer. I suppose you could go functional if you wanted to:

foreach(adict, function (k,v) print(k.." -> "..v) end)

...but there's more brainwork involved. As other posters have mentioned, functional iterators don't get you much if you're just running the function for side effects. "Code should be organized vertically, not horizontally."

If you think of Python as Common Lisp, Lua is like Scheme. Except Lua's in a lot more console games than Scheme. :-)

Let's not forget Lua. Nice ANSI (or close to ANSI) C implementation, light, fast, easily embeddable, and with a simple syntax. I remember that with version 4.0 you could strip the distribution down to less than 50k. Yep... 50k. There are several commercial games that use Lua as their scripting engine. It's worth a look for mobile phones.

I'm the second person who hate python white space syntax then. That was when I started using lua

The author claimed that it wasn't a QBasic application, but the error messages when it crashes tell a different story.

The QBasic integrated editor was a real joy, and it's hard to find a good, lightweight equal. Python is too big, C++ lacks the "fun" factor...

Lua with the SciTE editor comes close, if only it had builtin help.

I only stopped using QBasic after repeatedly running into the 32K memory barrier. I moved to Euphoria, a nice interpreted language. I missed the QBasic editor that I ended up writing a clone for Euphoria.

Heck, QBasic left such a mark that I ended up writing a Basic interpreter of my own.

Not true. Grim and EMI are both written in LUA, not SCUMM.

But come on.

Python is "some obscure scripting language"?

Python's not some obscure scripting language. Lua might qualify as "some obscure scripting language". Maybe you could also qualify pike as "some obscure scripting language".

But in any case, the BitTorrent developers completely document their protocol at the network level; for example, nothing depends on how Python serializes or deserializes a certain structure - it's all specified in terms of bytes carried in standard IP packets.

First, a shameless plug: I'm working on a couple of C++ applications that are currently using FOX for the GUI (and other parts). The first one is a front end to the open source stats language R and it is called Obversive. This is the most active project, but it is still real tiny. The second project is a little chat client I'm writing called Bombyx which will work on the SILC and hopefully IRC. In addition to Bombyx, I've also developed a little GUI generator with Lua that makes FOX widgets pretty quickly. It's called GIG and you can get it from the Bombyx site mentioned previously. The intention with GIG is to make it work for any toolkit, but right now it does FOX only.

When I was working on these projects, I went through a huge number of toolkits and actually tried developing fast "mock-ups". My test was to see if I could get the first window I wanted in each project using available resources. If that worked, then I would try a couple of other windows. I also reviewed the designs of each and then went with what worked best at the time.

Here's my review of each of the toolkits I used. These are just my opinions, but they are based on actually using them in various platforms (or trying to).

FOX After all of this evaluation, I found that FOX was pretty much the best at the moment for clean, simple GUI building. It has pretty good docs (way better than wxWindows), and is fairly natural for coding. It also has some nice language bindings for various languages like Python, Ruby, and Eiffel. It doesn't have quite as many controls as wxWindows, and it doesn't work natively on as many platforms, but it is much easier to build and work with and much smaller. If you are porting a Windows application to another platform, you will probably be better off with wxWindows since they try to mimick the API design as much as possible (and of course, all it's problems too). Also, if you hate macros then you'll have a problem with FOX (and wxWindows too). A testimony to how easy FOX is comes from Obversive, where one developer had no C++ or FOX experience and has already created several complicated controls. Another developer has good C++ skills, but only worked with KDE previously. He not only developed an excellent Twin Table control, but also added lots of great features to it and in very little time.

FLTK I did the original work on Bombyx with FLTK. FLTK is a nice library, but it was just missing too many widgets to be useful. It was also rather buggy and it was a real pain to do delegation. There are, however, two really nice things about FLTK: no macros, excellent GUI builder. One of huge problems with ALL other toolkits I've ran into is that, when the developers start to make their GUI builder, the decide they need an entire IDE. I already have one thank you. I doubt some OSS project is really going to out-do my tool chain right now, especially if it's also working on the widgets. Just give me a simple builder please. FLTK got it right with FLUID--their GUI builder. It's real easy to use, super fast, and does one thing well: build interfaces. It was a little weird at times, but I checked out the latest and it worked great. Also, FLTK does not use macros for messaging which is nice for the C++ purists.

Cocoa I love Cocoa, but, Apple made a huge mistake by making it a MacOSX only beast. I think Apple could rule the world if I could spend my time writing my apps with a nice UI, great tools, and an easy language (Objective-C), and then click a button and have a Windows, Linux, HP-UX, and Solaris binary. You could do this with the original NeXT stuff, but Apple crippled Cocoa and friends. So, I reserve Cocoa for other useless programming that I only do on my MacOSX. There is GNUstep, but I couldn't get anything to work with it, and half the fun of Cocoa development is using Interface Builder (IB). BTW, IB is another GUI builder that is excellent, and also does just GUI building. Let's hope the wxWindows guys figure out this pattern and write a small GUI builder rather than their entire IDE which nobody seems to be able to compile but three dudes inside the cabal (sorry, it really burns me).

wxWindows I must say that wxWindows has a ton of nice widgets (I may steal their HTML widget) and works on a huge number of platforms. But, I kept getting burned in three areas: docs, dependencies, and bugs. Their docs are horrible. You have to hunt around the net looking for tutorials which are not very good anyway. Half the example applications in the distro don't even work so you can't rely on them, and it's just really hard to figure out what to do. I also hated having to add a billion other libraries to my build just to get wxWindows to work. I found it a problem when linking my application took longer than compiling all the files from scratch. Finally, just about everytime I went to use some widget, I found some bug or limitation that made it unusable. They have improved quite a lot from what I have heard, and people really rave about it, so I think everyone should give it a try. One thing also that annoyed me about wxWindows is that it does not support delegation very well. All the other toolkits I used either support delegation easily or practically require it. In wxWindows, I spent the better part of a week just trying to get one simple delegation design working and couldn't do it despite lots of help from people on various IRC channels. To me, things are broken if I have to subclass every time I want a widget. The wxWindows XML based resource files are supposed to fix this, but I won't hold my breath.

JFC/Swing The original version of Obversive was done in Swing with lots of other goodies. Java is my primary work language, and I really wanted to use it on the Obversive project, but we just kept running into performance problems. Frankly, Swing is just a P.I.G. and is really hard to code. None of the GUI builders available we tried proved to be that useful, and eventually we dropped it becuase it was just too huge. Ironically, we were able to prototype an almost complete GUI using FOX which runs on Linux, *BSD, Windows, and MacOSX (through the XDarwin or Apple X ports) in about 3 weeks time. This was mainly in part due to the slick design of FOX and simplicity, and partly in part because of the GIG code generator I put together. Oh, and we looked at SWT, but balked at the Linux or Windows only (and the fact that the flagship, Eclipse, ALWAYS crashes on Linux does not make me happy).

So, that's my experiences with these toolkits. I hope that helps answer the question, and I hope the reply wasn't too long. To summarize: Use FOX if you need C++ and good design. Use wxWindows if porting from MFC or if native controls are important. Use Swing if speed is not a problem, but cross platform really is. Use Cocoa if you only care about MacOSX and need to get something out quick. I actually prototype some UIs in Interface Builder on MacOSX, which says a lot.

That's not to say anything bad about wxPython itself - it's just a matter of style.

You might want to have a look at wxLua, a nice mixture of Lua and wxWindows.

"Lua" is Portuguese for "Moon". Lua is a Brazilian project.

In that case, why use Java? You could use another interpreted or scripting language that has all what you want and make the critical components in C/C++, Java's JNI isn't the nicest looking interface around, I'd prefer using something like Python, or going even simpler to Lua which has a small footprint and a clean binding interface, also giving you greater runtime control/interactivity, examples of scientific uses of this can be found at there website.

Lua the programming language, BTW, is a Open Source (but not GPL copyleft) Brazillian developed language.

What a wussy response. So what you're saying is that those languages are all good, except when they're not.

I love Intercal because it destroys all the "they're all very nice" language relativity arguments. Here's a language that's specifically designed to be as annoying as possible. I dare you to advocate Intercal in the same way you did above.

Both the PHP language and its implementation have significant problems. Regular users of PHP already have their own list of language design annoyances ("it has to be a global??") and you can see some of the implementation problems here. You will note PHP's implementation getting beaten by Tcl, gawk, xemacs, and njs. :-(

PHP would have been better off if the implementors had used an existing language like Lua (80k of x86 code for standalone interpreter+core libraries!) and focused on the embedding features unique to the application area.

There are still millions of lines of COBOL, FORTRAN. And you can still develop in ADA, LISP, Scheme, etc. Compilers exist.

Sure - Java, Pythol, C# are pretty similar. But what about Lua? PERL? Or CURL?

Sounds like a case of the "good ol' days".

Smalltalk: You send the message shoot to gun, with selectors bullet and foot. A window pops up saying Gunpowder doesNotUnderstand: spark. After several hours fruitlessly spent browsing the methods in Trigger, FiringPin and IdealGas, you create ShotFoot, a subclass of Foot with a new instance variable bullet hole.