jump to navigation

Lua vs. Python, Embedding July 13, 2011

Posted by PythonGuy in Lua, Python.
15 comments

People whine about embedding Python is a pain.

I feel their pain, but not the pain of embedding Python. I feel their pain of being forced to write code in C.

As Glyph Lefkowitz so clearly explains, the fact that Lua is easily embedded doesn’t make it a good choice. Embedding is the wrong engineering choice to begin with.

What you should be doing as a programmer is creating usable code fragments. If the Free Software movement has taught us anything, the survivability of code depends on its usefulness, and that usefulness goes into how other programs can tap into its power.

If you’re writing an environment from which you expect other programmers will confine themselves within, you are making a big mistake. Those programmers who fall into this trap will one day realize that they’ve wasted their lives in pursuit of the impossible. If you want to know where things will go, go read about Emacs and Lisp. That’s what you’re recreating.

If, instead, you’re writing components of programming intelligence, buried into .so’s or .dll’s, then other programmers can follow after you and incorporate your program into theirs.

Lua might be a nice embedded language, but embedded languages are not what you really want.

Advertisements

Python v. Lua, Complexity and Simplicity July 13, 2011

Posted by PythonGuy in Lua, Python.
11 comments

One of the biggest arguments against Python and for Lua is simplicity. That is, the Lua fans claim that Lua is more simply than Python, because it’s language is much smaller.

I agree and concede the point that Lua’s language is smaller. I also admit that Lua’s code base is much, much smaller.

However, does this translate to simplicity for the programming task?

I think Lua is wonderfully engineered. The guts of Lua are beautifully assembled. It is a wonderful structure to behold, much like the Taj Mahal.

However, people don’t live in the Taj Mahal. They live in modern homes which are an engineer’s nightmare. Modern homes are much more comfortable because the modern conveniences that make living simple are readily available.

Behind the faucet is miles of piping. Behind the outlet is an electrical system that will confuse even the most experienced electrician. But we know that if we want to live, we would rather live in a modern home than the Taj Mahal.

Yes, the Taj Mahal is simpler, being constructed out of stones that fit perfectly together. Yes, we can appreciate how a few simple components have come together to make something greater than the whole. But that’s about all we can do.

A very, very good example is how Python approaches Object-Oriented Programming versus Lua’s approach to Object-Oriented Programming.

Python provides not insignificant language constructs, embedded deep within the syntax and interpretation, that make simple classes trivial to create, and hard classes easy.

Python’s OO system is easily learned. When you need special behavior, such as attribute look up and assignment magic, the way to do so is plain and easy.

Lua’s OO system, on the other hand, is extremely limited. You only have two or three syntactic elements to support OO programming, and these are not “magic”, nor can the magic be modified to fit the task.

Where is SQLAlchemy in Lua? It cannot exist. For Lua’s “simple” system, you will never have declarative ORM, and never understand what it means to have a class backed by a database. Sure, SQLAlchemy is much more complicated than anything you would ever dream of writing in Lua, but Python has provided the modern conveniences that not only make writing SQLAlchemy possible, but almost easy.

Why does Python have so many modules? Because it is so easy to create new modules that do interesting things, whereas in Lua, this is simply not done.

Yes, Lua, the language, is simpler. But I don’t want to use a language that is simpler. I want a language that makes my job, the task of programming, easier. I don’t care how complex that language is, anymore than I care whether how complicated the grammar in English is. I simply care how hard it is to do my job, and Lua makes my job harder, not easier.

Python v. Lua, Coroutines July 13, 2011

Posted by PythonGuy in Lua, Python.
3 comments

I am seriously studying Lua now. I’ve realized that a better language to compare to Lua is Javascript.

Reading about Python vs. Lua on the web I’ve discovered that the deciding factors in favor of Lua are argued to be:

  1. Lua is smaller, easier to master.
  2. Lua is faster.
  3. Lua doesn’t change as rapidly.
  4. Lua supports coroutines.
  5. Lua is easily embedded.

I can argue against each of these points to my satisfaction. I am a Python fan for a reason, and none of these attack the reason I am a Python fan.

Now, one important topic would be convincing, if it were true: coroutines.

Unfortunately, it seems the Lua fans have missed out on Python’s greenlets module. If you still say that Python lacks sufficient coroutines after seeing the greenlet module, then I’d like to understand what makes you say so.

Lua vs. Python July 13, 2011

Posted by PythonGuy in Lua, Python.
25 comments

I’ve seriously looked into Lua for twice. The first time I was excited about some of the potential, but I quickly lost interest. This time I have forced myself to overcome.

My impression is that Lua’s closest cousin is Javascript. The rather Laissez-faire approach to syntax means that there isn’t a whole lot of consistency, and there wasn’t a lot of time spent thinking hard about how programmers might actually use the language. There are a number of cases where a bit more consistency could have been introduced, and the syntax could have been reduced in verbosity, but the designers, for some reason, decided not to do so.

Here’s my list of (hopefully objective) differences between Lua and Python.

I’ve declared a winner for each point, based on my personal preference. Obviously, that part is not objective.

  1. “local”. Python’s vars are naturally local, whereas Lua requires the ‘local’ keyword. This is like Javascript, which requires ‘var’ to get a local variable. Since local variables should be much more common than global ones, Python wins.
  2. Table declarations. The various ways to declare tables are confusing, and the fact that you can combine them is even more so. Compare to Python’s clear distinction between lists and dicts, and you’ll understand what I mean. Python wins.
  3. Lists are dicts are tables are objects. I actually like the dot-syntax for item lookup in dicts. I do think Python could benefit from merging lists, dicts, objects, and perhaps even sets into one data type. Score one for Lua.
  4. No variable declaration needed. If you try to access an undeclared variable, Lua gives you ‘nil’. In Python, an exception is thrown. You should never access variables that have not been declared and assigned to. Score one for Python.
  5. Local scope for if / for / while blocks in Lua. Python does not create a new local scope for if / for / while blocks, so you can declare variables within if statements and you can access the for iterator variable outside of the blocks. Additional code is needed to share the values outside of the blocks in Lua, which is all too common. Python wins.
  6. Non-critical whitespace. Lua doesn’t treat whitespace special, and so programmers need not organize their code neatly for it to compile. Python wins.
  7. Block delimiters. Lua requires do / then – end combinations, while Python’s indentation is parsed by the parser. Python wins. If you’re blind (so that indentation has no meaning for your non-visual perception of the code), then Lua wins.
  8. Two different version of for. Rather than create a function that returns an iterator given start, stop and step, Lua built it into their syntax. Simpler syntax means less work. Python wins.
  9. Statements need no separator in Lua. Although discouraged, this is clearly confusing. Python wins.
  10. Both repeat-until and while-do are in Lua, while Python only has while. Python is simpler, and repeat-until is no big advantage since it is trivial to build with a while loop. Python wins.
  11. No continue statement in Lua. You must wrap your code with an if statement. Python wins since flat is better than nested.
  12. No else block for while / for loops in Lua. Python is about the only language I know that has else blocks for the loop statements, and I actually find them useful. Python wins.
  13. Return and break must be last statement in a block. This requires you to do things like stick a return in a do-end block. Python wins.
  14. Parens optional on function calls in Lua, which makes a “special” function call syntax with a single table, which really isn’t that special. This inconsistency is very troubling because it doesn’t help anyone except those who like obscuring their code. I think this confusion is one of the biggest barriers to Lua for beginners. Python wins.
  15. Method calls with : in Lua, whereas Python has the magical binding process which can be overridden. Python wins, because once you understand the binding process, there is no magic. If you don’t understand it, it just works the way it should.
  16. Missing params or extra params in function calls are not an error. Missing or additional results are not an error. This will not expose broken code, particularly refactored code. Python wins.
  17. Function calls produce list but only if last in list. This is just confusing as heck. Python wins.
  18. 1-based indexing in Lua. The math is all wrong, and requires you to remember -1 or +1 as needed. You never have 1-off errors in Python because you never need to +1 or -1 with indexes. Python wins.
  19. No named parameters, but you can pass a single table in Lua. Python wins.
  20. No default parameters in Lua. The syntax is very simple and all but obvious. Python wins.
  21. Local function declarations require local var declaration before function declaration. This is evidence that variables should be local by default, including function declarations. Python wins.
  22. Early binding in function bodies for Lua. Although Python is slower because it has to lookup the symbols for every function call, Python’s way is much more intuitive, especially for junior developers. Python wins.
  23. That’s all I have for now. I am sure there are a number of other differences that people can identify. As a junior Lua developer, I really don’t understand much about the subtleties of Lua.