On Wed, Sep 24, 2014 at 12:48 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Mon, Sep 22, 2014 at 6:55 PM, Chris Angelico <ros...@gmail.com> wrote: >> Lua is a much simpler language than ECMAScript, incredibly >> light-weight, and easily sandboxed. It doesn't work with Unicode (I >> think its string type is eight-bit, so you have to work with encoded >> bytes), which is a serious downside in my opinion. Learn Lua if you >> want to work with something that embeds it. Otherwise, don't bother >> for now. > > Apart from the Unicode issue, I'm curious what makes you describe it > as "much simpler" than ECMAScript. Lua has coroutines built into the > language, stricter typing than ES (still not as strict as Python, but > at least you don't have to deal with a === operator because the == > operator is broken), operator overloading, iterators, block-level > scoping, closure construction that binds loop variables the way the > programmer expects (unlike both Python and ES), and associative arrays > that allow arbitrary keys rather than coercing the keys to strings.
Mainly that's based on a feeling, rather than anything specific; I've worked with both Lua and JS from both ends (although the extent of my experience with embedding Lua is an evaluation exercise only; the project ended up going with ECMAScript via the V8 engine, which was the other major choice), and Lua seems rather less featured. Partly this might be a consequence of using a very full-featured JavaScript implementation (V8), but it felt like embedding Lua meant doing a lot more of the work myself. Also, from the script writer's point of view, Lua's table type seems less powerful than the JS object, although that may be a flawed appearance due to my greater experience with the latter. In any case, it fits into a very specific niche: you learn Lua if you want to script something that offers Lua scripting. That's technically the same as the JavaScript niche, except that there's a really big "something" that everyone wants to script, and that's web browsers. (Plus, node.js means you can write server-side code in JS, though personally I wouldn't recommend it; I've seen nothing that node.js can do that Python with a good framework can't do just as easily, and without UTF-16 baggage.) >> * SQL is the one and only database query language you should ever need >> to bother with. (You might skip SQL too, if you use something like >> SQLAlchemy, but you certainly won't need any other query language - >> not in 2014.) It's well worth getting to know SQL at some point; >> whether you use Python, Pike, C, or any other language for the >> application, your SQL code will be the same. > > SQLAlchemy lets you use SQL without actually writing SQL, but I would > argue that it's still basically necessary to understand SQL and what > the SQLAlchemy calls translate to in order to use it. What I'd say is that you have to understand database design. There are concepts that go beyond the actual language used (figuring out what a table's primary and unique keys are, handling joins, knowing how to trace logical structure through a series of tables, etc) that you're never going to get away from. With a framework like SQLAlchemy, you shouldn't have to worry about things like the esoteric quoting rules of different DBMSes (why, oh why, can't we just stick to the standard - 'quoted string', "identifier", and not use backticks at all??), but you still have to craft a sane database structure. When I say that you won't need any *other* query language, I mean that you're unlikely, in 2014, to use the BTrieve API calls that I worked with in the 1990s to interface with Pastel Accounting, nor the DBase calls that manipulate those fragile .dbf files that oh so easily get damaged if two people try to use them at once, etc, etc, etc. You might use a wrapper around SQL if you choose, but certainly if you know SQL you should be able to handle any database. And that's a Good Thing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list