LÖVE

Click here for the Lua Starting Guide

The link above leads to a starting guide to the Lua programming language that I recently wrote. It's not yet fully "complete", and I deem it always open for improvement. Therefore I did even set up a GitHub repository, so you can notify me easily about any mistakes (like example codes not working or typos or some wrong information, or vital parts of Lua not covered, etc. etc).

Now this guide is about Lua in general, although I did dedicate one chapter to the basics of LÖVE, as Lua is by itself not able to do much, unless attached to an engine, and since LÖVE is a simple, yet free and pretty complete engine for 2D games, it could do well to demonstrate Lua in full action, but of course, with the note that if you prefer a different engine, stuff may work differently, but that the Lua language itself will basically be the same.

I've NOT covered adding APIs in C to Lua, and I don't plan to, for 2 reasons. a. Although I can code in C, I suck in C, so I may not be the best person to explain anything about C. b. I only wanted to cover the scripting side of Lua from the start, and even if I were to cover the C-side of Lua, I think it would be best to cover that part in a guide for the advanced Lua user. I actually wonder how many Lua programmers are actually using writing their own stuff for Lua in C... I really don't know... :-/

Of course, the guide may not be for the experienced LÖVE user (I don't think it will tell anything new to you if you are an experienced LÖVE user), but hey, if people who never used Lua before consider LÖVE this guide can help them to understand Lua itself.


(Apologies if this was the wrong board to post this).

I hate him

Sorry about that.... I just wanted a "nerdy" icon for the more "nerdy" passages, and this was the only one I could quickly find in the public domain (as I shall be fair on it that I didn't draw him myself. I did the guide, and I did the code it contains)

So, i tried reading the 60-ish pages, and to be completely honest with you, without intending any offense, apart from the spelling mistakes (scoop instead of scope, for example) or the grammar that's a bit un-english (both of these are understandable given that, if my assumption holds, it's not your native language), the content itself has quite some errors in it... in fact, i don't think i'm either qualified enough, or would have the time, to list everything that's either misleading or flat out wrong.

I am appreciative of the fact that you most probably did work your ass off with writing and designing all of this, thinking out the chapters and such, but ultimately, as it is right now, i'd not suggest this guide to anyone; in my opinion, beginners shouldn't be taught things that are not true (omissions may be acceptable, but incorrect statements don't help anyone), and advanced users, as you said before how this didn't target, will not use it for much of the same reason, because they can find more correct resources.

Also, this negative criticism wasn't meant to dissuade you either; in fact, try to look at the most used sources people use to learn lua, the PiL or the reference itself; if something's not clear, test it on the online lua testbed (and/or with other versions as well), and you can improve both the guide and your own understanding of the topic as well!

And of course, here's hoping others will submit fixes to the repo as well.

English is indeed NOT my first language, and this is only the first concept of a guide on which I was working in a rather short time. It did stood its first test as a scratch user did successfully get over onto Lua thanks to this guide. Spelling and grammar were in this first concept not my first concern. I was prepared a lot needed to be changed, and once the guide is getting more and more unlikely to get changed anymore, that would be a more proper moment to fix any grammar/spelling errors. Content first, spelling later as the content will only suffer when you are too eager to put the spelling right from the start.

Now stating things are wrong or incorrect without stating what is not going to get me anywhere, as this guide had more functions that just to teach people Lua. It was also a personal experiment to set up guides in general about anything. Some omissions are planned to be added later, as I just needed something to get on the road. Set up a basic concept and expand it later into a full guide, that was the idea.

Please note that I've been coding for 35 years now (so I am not exactly "green"), and I was encouraged by a professional in the field of coding (and training to code) to share my knowledge and that also led eventually to this guide. All code in the guide has been tested (and those that cause errors, do so because I MEANT to make them do so, as I did put up a few faulty codes in the guide on purpose, in order to make the reader figure out why the code doesn't work), although I cannot guarantee a few errors did slip past my notice despite the care I took in setting it all up. This was the first concept after all. And also note that I may have discouraged things which you may find in my own code all over (As Scotty said (in Star Trek) that when teaching you should always be more careful that you'd be for real). It's always a big challenge to "tune down my own level" to that of those who do not know what I know, and as I know better than to judge where I was successful in that and where I failed, I do need details. The guide can only improve when I got details.

Also note that coding has also become a matter of opinion these days, and especially as far as Lua is concerned. In Lua there can be hours of debate if you should write "function hello()" or "hello = function()" for starters, where in Go for example it's for a usual function just "func hello() {" (unless you need a variable to contain a function), but despite Go being very very strict on the programming style you use even there can be tons of debate on how to do things. So what is incorrect, and what is a coding style you don't agree with? (I have to ask, as I met many coders who took opinions for facts, and since Lua was designed to cover the needs of very varying opinions giving the coder much freedom, Lua is maybe a very big trapdoor in this (maybe even more than JavaScript which already has a pretty bad reputation in this department)). Lua being so much open for debate also led me into confusion when I began working with it, as on many forums people were not in agreement. In the end I just chose the methods I preferred, and the stuff I've written in Lua could not be possible when I had my facts wrong and were completely ignorant about what I was doing, so I wonder, where are the facts wrong and what is a matter of opinion on which you disagree with mine? Even after 35 years of experience I still learn new stuff, and not only in Lua (and yeah, since aside from Lua, I've also coded/scripted C64-BASIC, P2000T-BASIC, GW-BASIC, Q-BASIC, Turbo Pascal, Blitz Basic, BlitzMax, Python, C (although C is a language I'm pretty sucky in, I'll admit), C#, Go, Visual Basic, php, ASP(VBScript), JavaScript and maybe even a few languages I don't remember, and even a few experimental languages I've set up myself, I am aware that some coding styles common for Pascal but not for Lua may still have gotten a bit into me for some reason and made it into this guide as well without me realizing it. The teacher who encouraged me to share my knowledge also saw that I was tempted to follow "MyClass.MyMethod" (C# convention,as a matter of fact, the version Visual Studio I have even warns me when I do it differently) as in C, Lua, Java(Script) and many other languages (myClass.myMethod) should be followed (as is also done in the APIs LÖVE adds to Lua) (and Go is even more terrible as "MyClass" is public and "myClass" is private, as first letter capital denotes public in Go, just to make the confusion complete), but I was glad he alerted me on that so I can keep it in mind for code I need to share. XD

And one reason I also wonder is because I told someone something that I read in a programming book (I don't remember what it was, but that's not relevant), causing him to say that the author didn't know his stuff, causing me to reply "So Peter Norton doesn't know his stuff?" (The name "Norton" was high quality stuff back then... Unfortunately that all changed once Norton sold it all to Symantec... figures). Since you've not been telling me what is downright misguiding or incorrect, I'm getting more and more suspicious, by remembering that one.

I've set up an issue tracker for this guide for a reason

Hope you don't mind if I chime in to comment on a few things.

I have read the guide in diagonal, because I find it tiresome to read stuff that I already know. Still, I have to agree with Zorg that there's more than one wrong statement. I've found three from that very quick look, there are probably more. Maybe Zorg wants to add more.


This sentence:

Strictly speaking Lua only has 5 data types for variables: nil, boolean, string, number, table and function.

is not right. First, it says there are 5 types but it enumerates 6. Second, Lua actually has 8 data types. "Strictly speaking" is supposed to introduce a rigorous assertion, but that one is not.


Something that is not exact either is this:

Now in Lua you cannot do any mathematic things on strings

Try for example: print("2"+"3")


Another issue:

As the example above is basically a textbook example for OOP programming, and although Lua does officially not support OOP, Lua can cheat its way around that to "pretend" an OOP environment, and to fake the class system

This is also wrong. Lua does officially have support for OOP, in the form of colon syntax (which makes little sense otherwise) and metatables. From the very first paragraph of the Lua 5.1 manual:

Lua is an extension programming language designed to support general procedural programming with data description facilities. It also offers good support for object-oriented programming, functional programming, and data-driven programming.

The fact that Lua classes are implemented as tables does not mean they are more fake than e.g. C++ classes. There's a reason why C++ classes can also be defined as structs. Lua classes as tables do adhere to the definition of a class. From Wikipedia:

In object-oriented programming, a class is an extensible program-code-template for creating objects, providing initial values for state (member variables) and implementations of behavior (member functions or methods).

Using an __index metamethod to make a table behave as a class is not "faking" a class, it's "implementing" a class, pretty much like adding a method to a C++ struct is not "faking" a class, it's making it behave as a class. Your wording makes it sound like Lua is nothing more than a toy language oriented to non-serious uses, in which you need to do some trickery to make things look serious, but that's very wrong. Prosody, a Jabber server, is written in Lua. I wrote a DNS proxy myself in Lua. The LuaJIT compiler/interpreter is the fastest among interpreted languages for most uses, and that makes it useful in many areas where a dynamic language is more convenient than a statically compiled one, and I think it deserves more recognition than it currently gets in that area.

In your defence I must say that the PIL book also paints classes like an emulated thing.


One more problem is that you don't mention the version of Lua that your guide applies to, at least in the introductory sections. This can cause confusion to those that want to know more after reading your guide and find the Lua 5.3 manual, only to realize that certain features don't work, and they won't know why. LuaJIT only supports Lua 5.1 plus a few features from later versions that can't make a correct 5.1 program fail.


In the post above you say:

Tricky wrote: ↑Sat Jan 19, 2019 10:20 amAlso note that coding has also become a matter of opinion these days

I wholeheartedly disagree. Coding is not a matter of opinion; coding is like maths, purely objective. A program either works for all inputs, or it doesn't, or it works but we can't possibly know for sure, just like in mathematics, a universal statement is true, false, or true but undecidable.

Coding style, on the other hand, is a matter of opinion. Not only these days, it has always been. That's the reason I don't give any style advice in the forums: each person has their own, and I don't want to get in the middle of that.


Lastly, you say:

Tricky wrote: ↑Sat Jan 19, 2019 10:20 amI've set up an issue tracker for this guide for a reason

You have to be realistic with what to expect from that. When I have a problem with a free software program, I can go to the bug tracker and report it. I get the benefit of getting the problem solved, and the author gets the benefit of offering a better product. Now, what benefit does anyone who already knows about Lua and doesn't need your guide, get from helping you enhance your guide?

There are all kinds of people, therefore some of them may feel altruistic enough to help you with some enhancements, but that chance is slim if you don't reach a wide audience. But even within the group of those for which your guide was actually helpful, most people are selfish and won't bother giving back to you even a small portion of what they got, in the form of helping you improve the guide when they find an inaccuracy. On the contrary, it's more likely that they will blame you for having given them incorrect information.

It happens also with all free software programs: very, very few people bother to give back to the authors of the programs they use, or in some cases even make money from, by just filing bug reports when they find an issue; it ends up being a question of luck. I've seen quite often the case where maintainers of a certain program were puzzled because a long-standing bug has been unnoticed for a long time and no one reported it. It's most likely that it was noticed, but still no one bothered.

I liked the bit about syntax sugar being "not official, but the compiler/parser accepts it as legit" or something like that, which is of course also false.

Or the 'var or constant' dirty code...

Oh and that "If"s, or branches, are evil and stuff You wouldn't have a turing capable language without some form of branching.