λ - programming

>>9075
language is very situational

I have always been incredibly disappointed that no smartphone company had made lua a defacto lang for apps

FirefoxOS missed that opportunity tbh

I hear it's taking off as a machine learning language - the best toolkit for recurrent neural networks is scriptable in Lua
>Array indices start at 1

>>9085
Yea I noticed, but not too sure what makes it better choice than others

>>9075
i actually prefer lua to python i think. i have heard it is good for programming micro controllers.

>26 – Calling C from Lua
http://www.lua.org/pil/26.html

>>9084
>FirefoxOS missed that opportunity tbh
firefox os is not called like that for no reason, it's supped to be an os that works with web tech AKA javascript

actually have a tutorial open right now! need to learn it to develop a small mod

it seems well put together and... friendly?

>>9075
It's an interesting language, I might pick it up again soon once I've made a couple video games. >>9085 is very promising and I'm thinking maybe I could use it to rope together a graphics, physics, and audio system together into a basic game engine even without using Love2D. The thing is to actually use those libraries I'll have to make libraries just to call those libraries from Lua, or rather a main loop that calls both those libraries and Lua. Unfortunately I'm using Windows, and library management in VS is not good.

>>9193
Fellow gamedev. Lua is great. However creating bindings for it is a pain.

IMO, it's best used as an embedded language where most of your program is native C/C++, etc. and you make these powerful things user scriptable in Lua. That lets levels / mods have new logic without requiring adding code to the engine. This is also what some machine learning systems do. Lua could be swapped out with Javascript, Lisp, or Perl and it wouldn't matter there: It's not like Lua is doing the heavy AI work, it's just being used as an embedded glue language (like Javascript was designed to be).

Even with Lua JIT it's not yet great for doing the heavy lifting on its own.

My problem is that if I make my codebase modular enough to embed Lua e.g. call a function pointer from the mainloop for per level logic: level.tick( elapsed ), then just have a level_XX.c file for each level (which adds an entry to linked list of such level structures), then I get the same sort of per-level customization, and efficient compiled code, for a LOT less coding time than creating Lua bindings, albeit without runtime scripting Lua grants. There is something to be said for debugging projects in a single language vs two languages and a binding shim.

Lua is very worth learning if you really need an embedded runtime scripting system. However, I'd argue that Javascript would be more familiar for end users. In my past projects I just implemented a simple MIPS virtual machine (it's really not hard). Then you can have runtime "mods" written in C/C++, Lua, Lisp, FORTH, Fortran, basically any existing language there is with a compiler for MIPS. Just provide the header files to compile against -- these take the place of in-source "binding" glue for Lua.

I think Lua is a pretty good stopgap, but still just a stopgap. What we really need is an Algo-like (C-ish) compilable language that is also its own scripting language. I once began implementing a runtime compiler for C, but the standards are so damn boated it's ridiculous to use it as a scripting language without making it incompatible with the standard's syntax.

Lua (and other glue-langs) shine now because we don't have a good compilable language that you can also just take it's compilable code and run it as a script at runtime -- or take a piece of runtime script that you've been working on and speed it up by marking it as compilable pre-release.

Perhaps Lua could be extended to a general purpose compilable language and provide transparent script-ability, but it suffers in this regard for the same reason Lisp's design does: Neither was designed to do the task we really want (hybrid compiled/scripting language). Lisp already exists and can be somewhat compiled + scriptable, but it wasn't really designed to play well with the realities of underlying architectures and (despite the beauty of it's logic) it was designed to be dynamic (also the the syntax is like kicking dead whales down the beach)
))))))))))))))))

Lua, and other hybrid "embed a VM in your C" solutions are answers to the problem that only exists because modern compilable languages don't have simple to compile syntax and provide a hook to invoke the compiler at runtime. We are going that way though. In other words: Interpreted languages already dissolve the difference between "runtime" and "compile time", compilable languages will eventually dissolve the distinction too. Until then Lua is a great stopgap solution to the runtime inadequacies of modern compilable langs.

>>9200
Your post made me remeber that the language Terra exists.
http://terralang.org/index.html
So now there's a compiled language that was made to work well with Lua, which is an interpreted language made to work well with C. I wonder if that back and forth will continue.

>>9199
Yeah, who would want to program with actual moon logic?

>>9200
I don't use Scheme, preferring Common Lisp, but Guile is specifically designed for this.

>))))))))))))))))

          }
       }
      }
    }
   }
 }
}

Lua fans check out MoonScript

>>9200
Im going to sound like a huge lisp weenie just by asking but have you used much lisp before taking issue with the syntax. And if you have use it have you used it in a "smart" editor to avoid having to count parens, for instance it should never concern the programmer to see at the end of a chunky expression a bunch of )))))'s because the indentation should make it immediately obvious which expression you are currently typing in. If your editor doesnt know how to auto-indent expressions and highlight matching parens its time to switch. On top of that a pretty common emacs minor-mode is paredit which reduces even further the lisp programmer's need to think about parens ever by letting you move expressions inwards or outwards both left and right.
https://www.youtube.com/watch?v=D6h5dFyyUX0
>>9201
check out
https://bitbucket.org/duangle/none/overview
to see a custom Lisp added on top of the Terra/Lua/C pile. I havent used it myself but anything with hygenic macros cant be bad. Its made by a cool former demoscene guy turned gamedev who found out about Lisp halfway through his big game's development. He also has an older post about his journey towards Lisp and his first attempts at adding it to his development environment, probably not very representative of it currently
http://blog.duangle.com/2015/01/conspire-programming-environment-for.html

>>9224
Your stance is valid, and I respect it.

However, my standards are higher. I want a language that I don't need a program to help me understand. I am a sentient being capable of understanding complex mathematic expressions, and spoken language semantics, I can handle a language with more complex syntax than the absolute minimum required for a computer to understand, especially if things like subscripts and curly braces make my code easier to understand at a glance.

Lisp syntax is nice because it is minimal enough for a programmer to create a program that can program programs in it. However, I'm of the opinion that the syntax not need to be so simplistic in order to achieve the similar results in a more readable way. In other words, the syntax bent to the problem space too far. I think languages should be for humans, not for machines... Or, rather, that we should teach the machine to understand human-like language rather than overly constrain the symbols used by humans in order for machines to understand them.

This is largely a philosophical difference. It's not that I can not be bent into thinking like Lisp. I write code in assembly and machine languages. When I do write code in machine language / Assembly, I greatly prefer a CISC instruction set to RISC. The RISC instruction set is like Lisp in that the symbolics are reduced to their minimum, and makes it harder for the programmer -- the programmer on RISC need use a compiler or advanced assembler whereas it's easier on CISC chipsets to write machine code directly. Likewise, you are proposing that I use a more advanced editing program -- in fact, a parser / compiler for that language, because Lisp is like the RISC. That's a crapy language design in my opinion, but you're free to disagree.

The primary thing I don't like about Lisp and do like about Lua is that Lisp is a dynamic language. I have nothing against language dynamism, and indeed use Lisp and Javascript and Perl, etc. frequently. However, it's not the right choice in every instance. When you need performance and runtime determinism is a must (for instance, in gamedev [see: client side prediction {see also: what I did there}] and some forms of AI), then dynamic languages are not the best choice.

Also, I can easily constrain Lua to consume no more than its image, and I can snapshot/restore that image quite simply. Doing the same safely in Lisp is a trickier proposition. You do want to QUICKLY checkpoint and reload, yes? My point is not that Lisp can not be used, it's that Lua and other languages are actually better designed for some roles than Lisp is. Lisp is a great compilation target for a recursive macro processor processor. I don't need a "better" editor, I have a Perl program that generates Lisp for me.

>>9229
>The primary thing I don't like about Lisp and do like about Lua is that Lisp is a dynamic language. I have nothing against language dynamism, and indeed use Lisp and Javascript and Perl, etc. frequently. However, it's not the right choice in every instance. When you need performance and runtime determinism is a must (for instance, in gamedev [see: client side prediction {see also: what I did there}] and some forms of AI), then dynamic languages are not the best choice.
Lisp and static type systems are not mutually exclusive. (No matter what that one article by PG that gets parroted around says.) Lisp with a good static type system is still an open problem. Fortunately, compile time metaprogramming makes it possible to implement them without writing a buggy parser or a toy language.
http://docs.racket-lang.org/ts-guide/
https://github.com/clojure/core.typed
http://www.shenlanguage.org/ (Yes, Shen is a toy language.)

>>9085
>>Array indices start at 1
Yeah, that's actually a good decision. The whole count-from-0 thing is a result of the fact that C's [n] operator isn't actually an array operator, but an offset operator. It actually means get value that is at the offset n units from the pointer it is applied to:

int* p;
// both of these are equivalent
p[2];
*(p + 2*sizeof(int));

If I type the number 4, I want the 4th fuarrrk ing item of the container, not the 5th, god damnit. 0-indexing doesn't make any sense at all outside of languages like C and C++ where it's an offset and not an actual index.

Maybe I don't know enough about Lua, but I do not understand why Lua is used so much in the game industry. Game design naturally lends itself to OOP, and many games are written in c++.

Lua can't call c++ class methods without importing a poorly implemented abomination of a binding library, due to name mangling. So to call into C++ you have to write C anyway in the form of

typedef int (*lua_CFunction) (lua_State *L);

So most people call into lua using the stack which amounts to pushing or popping primitive values or tables. Whats the big deal. If I want to use lua with no binding libraries to override an abstract class defined in C++ (or anything advanced from Lua->C++ really), I'm at a complete loss.

The only value I see is using it as a more advanced config file loader, so why boast about it.

>>9912

While I'm just getting into many game dev concepts, I've heard 3 major reasons for using Lua in a game. 1 is so designers can modify some things without diving into the (usually) C++ source code and mucking things up there, 2 is so you can quickly modify things you're going to change a lot and not have to recompile the whole game, and 3 is for mod support.

>>9912
>>9927
Just to add a few more reasons why people like Lua:
- Lua is really really fast for a scripting language
- Lua is a relatively nice and powerful programming language
- It's under the MIT license, so you can use it however you want for free
- There are a lot of good resources, libraries, and bindings available for Lua
- The binding libraries aren't really that bad, honest. Most binding libraries in C suck anyway.

>>9900
Very interesting. I've used C for a while, understand it's pointers but that was a really clear explanation.
Makes some sense.

How extensible is the AST that Lua runs on? I've been working on the syntax for a user-friendly spoken programming language, and the grammar is starting to look very Lua-esque, with a few additions. Rather than attempt to make my own language from scratch, I'd like to use something with some existing code and tool chain like Lua, and extend it to suit my needs.

>>9084
IIRC there was an IDE developed by some Brazilian dudes that allowed you to develop multiplatform apps with lua.
It was nice, even had some basic physics enging to make games and whatnot

>>9075
Y'know lua libs are written in C right? Well, the really cool thing about that is that for some magic reason it meshes and cross platforms danm near perfectly with python, meaning that you only have to do a small ammount to get python to make calls and run functions in in lua only envros and vice versa, like parsing soykaf .
You can merge the useablity of two languges to make some hybrid that gets near enough the best of both worlds. If you know one, the other is real easy to learn.

Anyone ever heard of the open source game engine Solarus? It was created to make a LttP clone at first, but it looks pretty good for pretty much any simple, lightweight 2d top-down game, which is exactly what I want to design. It's a really nice balance between a GUI editor and code--you arrange your map and elements in the game in the GUI, then set rules and processes for those elements in a code window for each element, in Lua.

The question is, is it worth learning Lua to use this? So far all my experience is in Python.

>>9900
This. Fortran got it all figured out from the beginning.

I've been interested in learning Lua for quite a while now.
What's the best/easiest resource for this? I'm much better with interactive stuff than I am with just reading.

>>10949

That's the magic of C anon, if two languages have a C FFI you can always get them to interoperate.

I've gotten Haskell and Guile Scheme to interoperate in the same fashion.

>>11011
Bump

>>11011
I've been learning how to use Lua by making a module for it using the Programming in Lua 3rd edition which uses Lua5.2