This is awesome. I will take [a single huge list of self-explanatory example snippets (with a few short comments here and there) for 95% of use cases] over [detailed walls-of-text docs pages spread across a hierarchy of topics] any day.
I agree, but can't help but wonder if the "me" from 20 years ago would have found this very confusing while I was learning to program. I learned from books with all that long-winded banter - so now I'm not sure if I actually NEEDED all that stuff in order to learn. Guess I'll never know.
This method, however, is PERFECT for anyone who already knows how to program. I love it, and actually came here to say that I wish everything everywhere had a page like this on the web.
The brass tax, get down to business, of ANY topic in 15 minutes.
I'm glad this comment sits at the top of this thread. I do hope that more and more learning resources come to us in this form, which is a very good thing to give you an idea of wether you would like to jump into a language (or maybe even a framework/platform?). OP did a very good job.
That said, Lua is quite the special case, as it does not require much time to get up and running with it. This is one of the reasons why it is the scripting language of Redis by the way (Antirez even wrote Total time require to master it enough? 5 minutes.[1] regarding building scripts for Redis).
Along the same lines is http://hyperpolyglot.org/ (which has been posted here a few times). This is useful both for learning a new language and for a quick reference for languages you're not so hot on. It's also very interesting to compare similarities and how languages have influenced each other.
It seems (from the comments here and my own experience) that many people really like this style of learning. It would be great to see it applied in more areas.
I was so happy with Lua and thought it was such an elegant and clean language.. then I looked at the side-by-side comparison between Lua and Io on the site you linked.. and now it seems clumsy and ugly.
Unfortunately a language is only as good as its implementation and tooling and Io's implementation is "experimental" at best (and development is pretty much dead) + the utter lack of tools and third-party support so I will have to stick with Lua.. and try very hard to forget Io again.
This is a good start, but there's also some deeper ideas in Lua. It has a good implementation of coroutines, for example; if you're familiar with continuations from Scheme, they fit most of the same uses. (They're like generators from Python or fibers from Ruby, but with less edge cases.)
The C interop is also a Big Deal. Lua seems like a cute little language, like a cleaner Javascript, but it's a LOT more useful if you're also proficient in C. Also, Lua will run anywhere you have an ANSI C compiler and a modest amount of space.
Coroutines are tricky, and you need to explain them, not just present a bit of code. I think it is the right decision to omit them from a 15-minute intro. The C API is way out of scope.
I would cover assert() statements and the common (exit_status, result) var return, since that is so idiomatic. Maybe also loading chunks.
On that note, I don't understand all the javascript craze. Lua has been around for quite some time, and it's small, with well-defined semantics, a nice set of features, the interpreter is small and very fast, you can get even faster with LuaJIT, etc. Browsers should have adopted that ages ago.
Javascript being used by non programmers is 95% of the problems with javascript.. care to explain your problems with js and maybe expand on how lua is done right?
Lua is a much smaller language and overall it is much more consistent and has less corner cases than Javascript since the language had the opportunity to evolve over the years instead of needing to retain backwards compatibility with browsers from 1995. For example:
* Lua has proper lexical scoping instead of the confusing "function scoping" of Javascript (so there is no need to use the IIFEs hack).
* Lua has a Python-style lexicaly scoped self instead of the error prone dynamically scoped "this". No need to use `var taht = this` if you have nested functions.
* The metatable system is much more flexible than the simple JS prototypal inheritance system (you can sort of implement "method missing" instead of being forced to only delegate to a concrete table.
* You can use anything as a Lua table key. In JS all keys are converted to strigns. Lua also supports weak references.
* Coroutines! Its sort of like ES6 generators and is super awesome. Async programming is infinitely more pleasant in Lua than it currently is in JS because you don't need to convert code to continuation passing style.
> Javascript being used by non programmers is 95% of the problems with javascript..
Well, I wasn't advocating Lua as a good language for non-programmers to write programs, but for scripting. When I make games/applications scriptable, it's closer to configurating than programming, and Lua's table constructors allow for great declarative DSLs.
Unicode is not included because currently they target ANSI C. Pure ANSI C.
Not POSIX.
Plain old C.
Until C11, unicode didn't exist in C. And it will be a long time before C11 is the default. Hell, there's lots of places where C99 is the exotic interloper.
I had hoped that someone would mention what specific thing was missing, because as far as I know it's trivial to do anything one would want to do when making games already. That is, it is very easy to accept UTF-8 input, output UTF-8, munge UTF-8 strings together prior to outputting them, compare UTF-8 strings for equality, and so on. If the game needs UTF-8-aware strlen (for limiting the length of a field or alphabetizing things), it is like 10 lines of code.
Actually, the Lua Missions are excellent! I highly recommend taking the time to work through them. More than just a series of exercises (like most of the foo-koans), there's actually a narrative and a larger lesson you can learn if you work through the full problem set.
Lua can be great. I've worked with it extensively on a personal project, where I've embedded it in a C++ app. However, there are some things that you will hate:
* Trying to correctly do "inheritance"
* Having to write all of your batteries for common ops
* Array indices begin at 1!
* Poor debugging support
Aside from those thing, Lua is great. It's crazy fast and easy to embed.
I prefer learning this way also, so I wrote something sort of similar for Vimscript a while back. The # of people that ever need to use vimscript is low, but it's out there for people to get their feet wet.
Almost the same experience but with Love2D[1] instead of Corona.
After learning Lua I also suggest to take a look at MoonScript[2] a dynamic scripting language that compiles into Lua, you can think about it as the CoffeeScript of Lua.
Since I became a Lua programmer, I really can't stand any other languages, and I've rapidly switched to it for my scripting needs. Tables are just soooo lovely. ;)
Well, it helps a lot that Lua is by design a very small language :)
Python is actually much bigger nowadays -- I would challenge someone to come up with something this simple that doesn't leave out a lot of stuff you will encounter in real code.
The extra features ("bloat") do matter. I like the idea of Lua a lot, but when I started programming in it, it unfortunately felt like a less capable Python to me.
Lua and Javascript are quite similar in that way: nice little languages that fall apart really quickly when you try building anything reasonably large or complex.
I don't really understand the attraction, except in certain niches like Lua as an embedded scripting engine, when you really need something that can be trivially sandboxed.
This looks interesting, can you explain the difference between Zoetrope and LÖVE?
The former seems to be built on top of the latter, yes? Are there particular things lacking in LÖVE that Zoetrope fills in? I couldn't find this info quickly on their sites.
Looks like it has collision detection whereas for LÖVE you'd use Hardon Collider, has Tiled level loading whereas you'd need a plugin for LÖVE, etc. Basically, lots of stuff that you'd include in your games anyway.
Looks nice and has better documentation than LÖVE. Thanks for posting it, I didn't know about it before.
That took me 30 minutes to read. I think I might feel like I've learned the language after spending 8 hours working the examples a la "Learn Python the Hard Way". Luckily, I'm not competing with the folks here that learned it within 15 minutes ;-).
The title is a bit optimistic :) That's how long it takes me to read as if I were reading a novel, which isn't quite fair.
I wanted to express something like "hey, this guide is for programmers and is surprisingly short and easy to consume considering it covers the large majority of the language." The current title seemed a bit snazzier.
This is a neat little reference but I can't waste the opportunity.
I've seen people say they've never seen complaints about fonts being too big? Well here I am, complaining that the fonts are so big this page is hard for me to read without zooming out.
That was a pretty cool crash course on Lua Tyler! Thanks for putting that together and sharing it. After having had worked with numerous languages over the years such as Fortran, Pascal, Ada, C, Java, C++, C#, Python and Objective-C, I must say that working with Lua is my favorite. I'm thankful to a buddy of mine for introducing it to me. My own personal experience has shown me that working with Lua really allows you to focus on solving the problem versus getting wrapped around the axle at the programming language level. Thanks again
I learned to love lua when writing basic sysadmin scripts for OpenWRT based systems. I had previously used perl for sysadmin stuff, but perl (even microperl) took too much space on OpenWRT boxes with 4MB flash drives. Lua to the rescue. Now I chafe when I have to go pack to perl.
I do wish someone had handed me this on the first day I realized I needed lua.
You have a keen eye for subtle references! I didn't expect many people to get that one :) There's another math anecdote reference hidden in there as well - probably even more obscure than Karl's sum.
Ramanujan and Hardy are two well-known mathematicians who collaborated in Britain between 1914 and 1920. One day Hardy took taxi number 1729 to visit Ramanujan, and remarked to him that he (Hardy) could think of nothing special about the number (1729). Ramanujan replied that it was in fact the first number expressible as the sum of two cubes in two different ways (1^3 + 12^3 = 9^3 + 10^3). The story has since become an anecdotal symbol of Ramanujan's brilliant mind.
This is very cool, the only way I can see this could be improved upon is by adding unit tests somehow (so that you can catch behavior changes when upgrading to a newer version of lua).
Having a font size of 25.33pt makes the website impossible to read without zooming out 3 steps. I would be happy if people stopped using tiny and huge default font sizes.
Well, it looks very good and reads very good on my ipad and on my tiny screen on my notebook. Otherwise I would've to zoom in, not a big deal though, do you think?
Could you tell us anything about why these things are bad?
Regarding the last point (the one that you cannot change), I'm not sure I prefer the behavior of any other language. In Python, for instance, all of the number-like things I tried were falsy iff they were 0, and I found that almost any container is falsy iff it is empty, but Queues are always truthy. This is a weird exception, and I would rather not have to remember it. Collections and numeric types defined in external libraries can easily have the same problem.
Global automatically declared variables is a well-known bad feature of some non-modern languages that gives nothing but an opportunity to make hardly detectable mistakes because of misprints.
Arbitrary nonsensical type casts must be prohibited. The compiler/interpreter/IDE must infer types and help the programmer to catch their mistakes as early as possible.
As a general rule of language design, if something looks unintentional or ambiguous to a human, it should look so to a compiler/interpreter. The more coherent the programming environment is to your conscience, the easier the programming is.
Thanks. I agree that Haskell is a great language, but this is a dynamically typed scripting language. As such, perhaps it would be more useful to compare it to languages that are actually comparable, like Ruby, Perl, your favorite LISP, Javascript, or Python.
This language does not include any nonsensical type casts. You cannot add a table to a string, take the arithmetic negation of a function, or index a number. (Actually, if you wanted to you could write code that permits you to do most of these things. For instance, I usually use some code that adds the ability to index strings.) String concatenation and arithmetic addition are different operators, so unlike in some prominent scripting languages you cannot find a and b such that +(a+b) == 50005 and +(b+a) == 55.
It does, however, include some forms that allow you to branch based on whether or not a value is a member of the set {nil, false}. I suppose that it would be better for the compiler to be able to guarantee that the value was a member of the set {true, false} and to yell at you rather than running your code if it was not, but this is a fairly rare property across all programming languages. I frequently use a programming language called Scala, and it pretends to provide some typechecks, but in reality all reference types are silently nullable, and all method calls are silently of the bottom type.
