10 ms·

Typed Lua: An Optional Type System for Lua [pdf]

54 points by ihnorton 12y ago

tendom 12y ago
I'm good with options, but I like the way Lua is, as it is. I don't really accept that types are needed for safety in my games, or any application I've used Lua (okay, almost exclusively games). What would be the use cases for this? In my tiny brain, it makes as much sense as dynamic C.
- adamnemecek 12y ago
  Generally, statically typed languages are less bug prone than dynamically typed languages. Dynamically typed languages are OK for smaller projects but as projects grow in size, you have to write a lot of tests to be sure that everything works. Also, projects written in statically typed languages are easier to read and navigate for humans and it's also easier to write static analysis tools for them.
  - fithisux 12y ago
    Dynamically typed languages are good for very small programs. Typed Lua is going to be a big innovation.
  - srean 12y ago
    If there are consequential performance gains to be had then even better. An interesting case is Dart. The implementers have a strong dynamic typing bias and wanted to keep Dart as dynamically typed as possible. Their position was we dont need any static typing for speed. They have since relented. You realize that you just planted a good solid troll magnet of the "I never make any type errors" variety. Some people get annoyed by the notion that you can enlist the compiler (using succinct syntax) to write and validate tests that they ought to be writing. They would rather write the tedious tests themselves. @spankalee They had a blogpost along those lines, sadly not bookmarked, but you might be able to find it.
    - spankalee 12y ago
      What makes you say that Dart "relented" on not using type annotations in the runtime? The VM basically throws the type annotations away. In production mode, the type annotations can be completely wrong and your program will still function, and still be just as fast.
  - taeric 12y ago
    Is there empirical evidence of your first claim? Or any claim, honestly.
    - adamnemecek 12y ago
      What sort of evidence are you looking for? E.g. http://www.infoq.com/presentations/Types-Tests http://www.infoq.com/presentations/Types-Tests ? But googling something like static vs dynamic typing will give you enough results to choose from. Or go to your local Haskell user group meetup :-).
      - taeric 12y ago
        No, googling those results doesn't really work. :) You get a ton of dogma with a lot of logical arguments. All of which are very appealing. Appealing arguments worry me, though. What I have not seen, is evidence that any of your claims are true. I have seen easy to read programs in both dynamic and static languages. So far, I've seen very little correlation between the two as to which is desirable. The static languages are typically a bear on some algorithms because you have to provide so much more to the compiler for it to trust you. This does feel like it would lead to less bugs, but it goes against the "readable" and possibly the "more productive" ideas.
        adamnemecek 12y ago
        How do you determine the return value of a C function? You look at the function prototype. How do you determine the return value of a Python function? You have to read the whole thing. If you are working with large code bases, reading the whole thing is not really possible.
        taeric 12y ago
        You are just trying to make an appealing argument. This literally adds nothing to the debate. A simple survey of open source software would be more convincing. And even that wouldn't be definitive.
  - fit2rule 12y ago
    There isn't really much evidence of this out there, other than groupthink, in my opinion. What makes a language 'okay for smaller projects' but suddenly unsuitable when it gets larger? Having a minimal set of types doesn't necessarily mean you're going to have 'more bugs as the codebase grows' - the only place it really makes sense to say that dynamically-typed languages 'break' is when they don't have the types that the application needs. In Lua's case, the only thing I can think of it missing is native floating-point support, and that's really it. Everything else: you can get there with nil, number, string, function, CFunction, userdata, and table. (But CFunction and userdata should be enough for anyone! :)
    - adamnemecek 12y ago
      If nothing else, it kind of follows from Curry-Howard correspondence. What makes it okay? This Python program will not throw an exception when ran def f(x): return x if False: f(1,2) even though the types are wrong. Are you 100% certain that you will never make a bug like this even when there are 10^13 conditions and the call stack is deeper than the Mariana trench? Note that that this is not the only type of bugs that static typing prevents.
    - dottrap 12y ago
      Lua already has native floating support (by default). The number type is double by default. Lua 5.3 (work 2 already available) introduces integer subtypes so now you can have both floating point and integers.
    - Jtsummers 12y ago
      > What makes a language 'okay for smaller projects' but suddenly unsuitable when it gets larger? One and one makes two. Two and two makes four. Four multiplied by eighteen is seventy-two. Compare to: 1+1=2 2+2=4 4*18=72 Notation, aka language, has scaleability as a feature, whether the designers intended it or not. Dynamically typed languages are nice, I love them for prototyping, and some of them, I think, are suitable for large scale applications. But not all of them. The notations made available in some languages just make large scale development easier or harder (for various reasons). Consider using maps/json objects to produce data constructs, this is a sort of duck typing unless you add some sort of schema checker to it. At which point it's either a runtime error or you're running your code through a static analysis tool. Why not use an actual type system for this that the compiler checks at compile time? I feel like a broken record this past week. Dynamic languages are good, I can't imagine doing the sort of exploratory/prototyping stuff I've done in them with typical statically typed languages. I wouldn't even object to using erlang for a large scale project (actually, I'd love to do this), it's got features in both syntax (bit syntax, I love it) and semantics (concurrency) that make it ideal for certain problem domains. It's got dialyzer which gets back a lot of the static analysis that statically typed languages offer. On the other hand, javascript offers duck typing, weak typing, dynamic typing, it's fine for certain applications (and essential for anything living in a web browser these days), but it's type system holds it back for large scale work. Experienced programmers may be able to get passed it with relatively few errors, but it's still going to suffer huge performance issues because there's only so much that can be known about the values passing through a block of code. Does `a + b` mean we're adding two numbers? A number and a string? two strings? The result changes depending on those circumstances and the interpreter/compiler just doesn't know enough to optimize it significantly. Similarly, it doesn't know that one is an error right away, the actual error may start here, but only appear in some function that's a child/parent/cousin in the call tree, obfuscating the cause and creating a great deal of work for the developer and tester.
  - dragonwriter 12y ago
    > Dynamically typed languages are OK for smaller projects but as projects grow in size, you have to write a lot of tests to be sure that everything works. Or build your large systems as compositions of smaller systems. If dynamically typed languages are really okay for smaller systmes, than avoiding bad architecture of large tightly-coupled systems in favor of loosely coupled compositions of smaller subsystems means that it is also okay for large systems. > Also, projects written in statically typed languages are easier to read and navigate for humans This is not my experience. > and it's also easier to write static analysis tools for them. Well, yes, since you have to write a static analysis tool for a statically typed language (since the compiler must include such a tool), its not at all surprising that the structure of statically-typed languages is always designed specifically to serve static analysis tools. IME, that's why they've historically been harder to read and navigate for humans, though some exceptional modern statically typed languages have largely closed that gap (but not reversed it, IMO.)
    - imanaccount 12y ago
      >If dynamically typed languages are really okay for smaller systmes, than avoiding bad architecture of large tightly-coupled systems in favor of loosely coupled compositions of smaller subsystems means that it is also okay for large systems. It doesn't mean that at all. You might as well say "if shoes are good enough for going to the corner store, then multiple pairs of shoes are good enough for going to the moon". The notion that large systems are no more complex than small systems if you simply make the large system out of small systems is not supported by anything I can find. >IME, that's why they've historically been harder to read and navigate for humans That doesn't make any sense at all. How is having information written down instead of having to constantly remember and/or deduce it an impediment to reading?
      - dragonwriter 12y ago
        > It doesn't mean that at all. You might as well say "if shoes are good enough for going to the corner store, then multiple pairs of shoes are good enough for going to the moon". A large system can be decomposed into a set of loosely-coupled smaller systems (indeed, that's often a preferred architecture for a variety of reasons independent of whether the language is static or dynamic). A trip to the moon cannot be decomposed into a series of walks equivalent to a walk to the corner store. Therefore, no, your analogy is not valid. > That doesn't make any sense at all. How is having information written down instead of having to constantly remember and/or deduce it an impediment to reading? Visual (and mental, really) noise, mostly -- there is a reason why clear, effective, easy-to-read writing is often not writing that avoids all potential ambiguities and is sure to define as much as possible to avoid people having to deduce things. Making everything explicit is generally generally in tension with readability, not an aid to it.
- anonymoushn 12y ago
  I make an online card game. The rules are pretty simple, about as complex as Duel of Champions. There are no ongoing effects, no instants, no stack, no replacement effects, and so on. What the game does have is literal thousands of triggered abilities. When combat happens, the attacker's triggered abilities will happen, then the defender's triggered abilities, then the attacker will attack the defender. Lots of triggered abilities interact with the attacker or defender, and some may cause it to die (it dies immediately, not at the end of combat). Subsequent triggered abilities might crash if they depend on the attacker or defender existing. In my implementation, these triggered abilities are functions with signature triggered_ability(player: Player, my_idx: number, my_card: Card, skill_idx: number, other_idx: number, other_card: Card?) Having the type system enforce null checks on uses of other_card (and also on all uses of cards from other zones, like the opponent's battlefield or the player's hand) would have saved me a lot of trouble. As it is, I use a fuzzer to play lots of games between AI players and look for errors, but most of the errors I look for could have been caught by a compiler instead.
- ufo 12y ago
  The main advantage is that anything that you can turn into a a type error will be reported at compilation time, much earlier in the development cycle. This is not just a matter of safety but also helps in terms of refactoring and testing. This includes things like typos (wrong method names, etc) but where types really shine is refactoring. If you want to add or remove a parameter from a function or change a string field to an integer then you can use guidance from the type checker to be sure that you didn't forget to update anything. Its a bit like adding bumpers to the side of the bowling lane - it lets you be more reckless, updating things until the compiler shuts up without needing to carefully go through each line. --- Also, don't forget that gradual typing solutions such as Typed Lua are all about letting you program dynamically if you want. The idea is that you would only convert to the typed dialect in the parts of your program where that would suit you.
aaron-lebo 12y ago
So Lua is faster/simpler/smaller than pretty much every other dynamic language and now has optional typing as well. Why have we not seen an effort to build a solid ecosystem around it the way node has with JS? Lua with equivalent libraries to Python/Ruby/Javascript/PHP would be superior to any of them.
- srean 12y ago
  You may want to take a look at openresty [1] moonscript [2], Lapis [3] and Kepler [4] . There has been some more direct efforts to port the "Node.js way" to Lua, one such is luvit [5] (significant overlap in the developers list) on the otherhand luv [6] exposes the underlying libraries slightly differently. Lua really ought to be considered JS done right and Eich should really have been given enough time to bring scheme to the browser (syntax could have been negotiable). Another interesting project is Typed Racket http://docs.racket-lang.org/ts-guide/index.html?q=typed http://docs.racket-lang.org/ts-guide/index.html?q=typed and Guile http://wingolog.org http://wingolog.org if this sort of things interests you. [1] http://openresty.org/ http://openresty.org/ [2] http://moonscript.org/ http://moonscript.org/ [3] http://leafo.net/lapis/ http://leafo.net/lapis/ [4] http://www.keplerproject.org/ http://www.keplerproject.org/ [5] http://luvit.io/ http://luvit.io/ [6] https://github.com/richardhundt/luv https://github.com/richardhundt/luv
  - vbit 12y ago
    Another related effort is http://turbolua.org/ http://turbolua.org/
- zorked 12y ago
  Lua is very popular in some niches, like games and embedded stuff. Language adoption is a very social thing though. Maybe if Rails was a Lua framework we would be wondering why Ruby never made it big.
  - stevekemp 12y ago
    Agreed. Lua is embedded in things like Redis, and is often uses as an extension/configuration language for small projects. I based my mail client(http://lumail.org/ http://lumail.org/) around Lua as a configuration language because I kept getting annoyed by the almost-configuration-language used in mutt. Actually writing applications in Lua is also possible, for example the chat/Jabber server Prosody.
fuzzythinker 12y ago
Link to the missing github page (maybe the paper is written before his github page was ready)? https://github.com/andremm/typedlua https://github.com/andremm/typedlua
- ufo 12y ago
  The github page has always been there, even before he started writing the paper. Its still very experimental though and I don't think its ready for general use yet.
lomnakkus 12y ago
Is it just me, or does anyone else feel that gradual/optional typing isn't good enough? I've been trying out Typescript in a couple of nontrivial projects, and sure, it does catch some errors, but as long as you're forced to integrate with an unityped world it doesn't really catch enough problems to be worthwhile, IME. You can of course write type declarations for all your "foreign" libraries, but that's just an added burden that you (the programmer, not the language) have to get right. Plus, since the unityped language is so flexible (and thus conventions are different vs. a multityped language), there are things in the unityped language that cannot be sensibly typed without just resorting to saying "any" (which is the only type of the unityped language).
- smrq 12y ago
  The biggest benefit of Typescript in my opinion is the potential for stronger tooling. There's definitely room for improvement (I suspect type unions would fix a majority of the times you are forced to use "any"), but I have found type declarations to be relatively low overhead for a substantial gain. Re: foreign libraries, as long as you are using TSD / DefinitelyTyped (http://definitelytyped.org/tsd/ http://definitelytyped.org/tsd/), that burden is crowdsourced. I've written a few library type declarations, but used many more from others. The flipside of the complaint is that I've found it really quite nice to have type checking for libraries I don't know inside and out. And you can always cheat and declare your external libraries as "any" for the sake of making the compiler happy, if you don't want to go through the effort to get the reward. Obviously, to get something like DefinitelyTyped going, you need a critical mass of developers, so that may or may not work out for Typed Lua.
  - lomnakkus 12y ago
    My experience is that DefinitelyTyped definitions are actually not very accurate in practice. This may be a consequence of language restrictions or just typical (and understandable) programmer laziness ("good enough!") -- or, as you say, the lack of type unions. It's better than nothing, but not really good enough. But then I have been spoiled by Ocaml and Haskell, so... (There's also the whole external/internal module confusion in TS, but that's not related to the general theme of gradual typing per se, so it's not really relevant to non-TS contexts.)
malkia 12y ago
Luajit is awesome too, but if you are looking for tighter debugger integration in MSVC then look at HavokVM - which is lua vm - you can mix native/lua callstack and it works just fine. http://www.havok.com/products/script http://www.havok.com/products/script

54 points by ihnorton 12y ago

I'm good with options, but I like the way Lua is, as it is. I don't really accept that types are needed for safety in my games, or any application I've used Lua (okay, almost exclusively games). What would be the use cases for this? In my tiny brain, it makes as much sense as dynamic C.

adamnemecek 12y ago
Generally, statically typed languages are less bug prone than dynamically typed languages. Dynamically typed languages are OK for smaller projects but as projects grow in size, you have to write a lot of tests to be sure that everything works. Also, projects written in statically typed languages are easier to read and navigate for humans and it's also easier to write static analysis tools for them.
- fithisux 12y ago
  Dynamically typed languages are good for very small programs. Typed Lua is going to be a big innovation.
- srean 12y ago
  If there are consequential performance gains to be had then even better. An interesting case is Dart. The implementers have a strong dynamic typing bias and wanted to keep Dart as dynamically typed as possible. Their position was we dont need any static typing for speed. They have since relented. You realize that you just planted a good solid troll magnet of the "I never make any type errors" variety. Some people get annoyed by the notion that you can enlist the compiler (using succinct syntax) to write and validate tests that they ought to be writing. They would rather write the tedious tests themselves. @spankalee They had a blogpost along those lines, sadly not bookmarked, but you might be able to find it.
  - spankalee 12y ago
    What makes you say that Dart "relented" on not using type annotations in the runtime? The VM basically throws the type annotations away. In production mode, the type annotations can be completely wrong and your program will still function, and still be just as fast.
- taeric 12y ago
  Is there empirical evidence of your first claim? Or any claim, honestly.
  - adamnemecek 12y ago
    What sort of evidence are you looking for? E.g. http://www.infoq.com/presentations/Types-Tests http://www.infoq.com/presentations/Types-Tests ? But googling something like static vs dynamic typing will give you enough results to choose from. Or go to your local Haskell user group meetup :-).
    - taeric 12y ago
      No, googling those results doesn't really work. :) You get a ton of dogma with a lot of logical arguments. All of which are very appealing. Appealing arguments worry me, though. What I have not seen, is evidence that any of your claims are true. I have seen easy to read programs in both dynamic and static languages. So far, I've seen very little correlation between the two as to which is desirable. The static languages are typically a bear on some algorithms because you have to provide so much more to the compiler for it to trust you. This does feel like it would lead to less bugs, but it goes against the "readable" and possibly the "more productive" ideas.
      - adamnemecek 12y ago
        How do you determine the return value of a C function? You look at the function prototype. How do you determine the return value of a Python function? You have to read the whole thing. If you are working with large code bases, reading the whole thing is not really possible.
        taeric 12y ago
        You are just trying to make an appealing argument. This literally adds nothing to the debate. A simple survey of open source software would be more convincing. And even that wouldn't be definitive.
- fit2rule 12y ago
  There isn't really much evidence of this out there, other than groupthink, in my opinion. What makes a language 'okay for smaller projects' but suddenly unsuitable when it gets larger? Having a minimal set of types doesn't necessarily mean you're going to have 'more bugs as the codebase grows' - the only place it really makes sense to say that dynamically-typed languages 'break' is when they don't have the types that the application needs. In Lua's case, the only thing I can think of it missing is native floating-point support, and that's really it. Everything else: you can get there with nil, number, string, function, CFunction, userdata, and table. (But CFunction and userdata should be enough for anyone! :)
  - adamnemecek 12y ago
    If nothing else, it kind of follows from Curry-Howard correspondence. What makes it okay? This Python program will not throw an exception when ran def f(x): return x if False: f(1,2) even though the types are wrong. Are you 100% certain that you will never make a bug like this even when there are 10^13 conditions and the call stack is deeper than the Mariana trench? Note that that this is not the only type of bugs that static typing prevents.
  - dottrap 12y ago
    Lua already has native floating support (by default). The number type is double by default. Lua 5.3 (work 2 already available) introduces integer subtypes so now you can have both floating point and integers.
  - Jtsummers 12y ago
    > What makes a language 'okay for smaller projects' but suddenly unsuitable when it gets larger? One and one makes two. Two and two makes four. Four multiplied by eighteen is seventy-two. Compare to: 1+1=2 2+2=4 4*18=72 Notation, aka language, has scaleability as a feature, whether the designers intended it or not. Dynamically typed languages are nice, I love them for prototyping, and some of them, I think, are suitable for large scale applications. But not all of them. The notations made available in some languages just make large scale development easier or harder (for various reasons). Consider using maps/json objects to produce data constructs, this is a sort of duck typing unless you add some sort of schema checker to it. At which point it's either a runtime error or you're running your code through a static analysis tool. Why not use an actual type system for this that the compiler checks at compile time? I feel like a broken record this past week. Dynamic languages are good, I can't imagine doing the sort of exploratory/prototyping stuff I've done in them with typical statically typed languages. I wouldn't even object to using erlang for a large scale project (actually, I'd love to do this), it's got features in both syntax (bit syntax, I love it) and semantics (concurrency) that make it ideal for certain problem domains. It's got dialyzer which gets back a lot of the static analysis that statically typed languages offer. On the other hand, javascript offers duck typing, weak typing, dynamic typing, it's fine for certain applications (and essential for anything living in a web browser these days), but it's type system holds it back for large scale work. Experienced programmers may be able to get passed it with relatively few errors, but it's still going to suffer huge performance issues because there's only so much that can be known about the values passing through a block of code. Does `a + b` mean we're adding two numbers? A number and a string? two strings? The result changes depending on those circumstances and the interpreter/compiler just doesn't know enough to optimize it significantly. Similarly, it doesn't know that one is an error right away, the actual error may start here, but only appear in some function that's a child/parent/cousin in the call tree, obfuscating the cause and creating a great deal of work for the developer and tester.
- dragonwriter 12y ago
  > Dynamically typed languages are OK for smaller projects but as projects grow in size, you have to write a lot of tests to be sure that everything works. Or build your large systems as compositions of smaller systems. If dynamically typed languages are really okay for smaller systmes, than avoiding bad architecture of large tightly-coupled systems in favor of loosely coupled compositions of smaller subsystems means that it is also okay for large systems. > Also, projects written in statically typed languages are easier to read and navigate for humans This is not my experience. > and it's also easier to write static analysis tools for them. Well, yes, since you have to write a static analysis tool for a statically typed language (since the compiler must include such a tool), its not at all surprising that the structure of statically-typed languages is always designed specifically to serve static analysis tools. IME, that's why they've historically been harder to read and navigate for humans, though some exceptional modern statically typed languages have largely closed that gap (but not reversed it, IMO.)
  - imanaccount 12y ago
    >If dynamically typed languages are really okay for smaller systmes, than avoiding bad architecture of large tightly-coupled systems in favor of loosely coupled compositions of smaller subsystems means that it is also okay for large systems. It doesn't mean that at all. You might as well say "if shoes are good enough for going to the corner store, then multiple pairs of shoes are good enough for going to the moon". The notion that large systems are no more complex than small systems if you simply make the large system out of small systems is not supported by anything I can find. >IME, that's why they've historically been harder to read and navigate for humans That doesn't make any sense at all. How is having information written down instead of having to constantly remember and/or deduce it an impediment to reading?
    - dragonwriter 12y ago
      > It doesn't mean that at all. You might as well say "if shoes are good enough for going to the corner store, then multiple pairs of shoes are good enough for going to the moon". A large system can be decomposed into a set of loosely-coupled smaller systems (indeed, that's often a preferred architecture for a variety of reasons independent of whether the language is static or dynamic). A trip to the moon cannot be decomposed into a series of walks equivalent to a walk to the corner store. Therefore, no, your analogy is not valid. > That doesn't make any sense at all. How is having information written down instead of having to constantly remember and/or deduce it an impediment to reading? Visual (and mental, really) noise, mostly -- there is a reason why clear, effective, easy-to-read writing is often not writing that avoids all potential ambiguities and is sure to define as much as possible to avoid people having to deduce things. Making everything explicit is generally generally in tension with readability, not an aid to it.
anonymoushn 12y ago
I make an online card game. The rules are pretty simple, about as complex as Duel of Champions. There are no ongoing effects, no instants, no stack, no replacement effects, and so on. What the game does have is literal thousands of triggered abilities. When combat happens, the attacker's triggered abilities will happen, then the defender's triggered abilities, then the attacker will attack the defender. Lots of triggered abilities interact with the attacker or defender, and some may cause it to die (it dies immediately, not at the end of combat). Subsequent triggered abilities might crash if they depend on the attacker or defender existing. In my implementation, these triggered abilities are functions with signature triggered_ability(player: Player, my_idx: number, my_card: Card, skill_idx: number, other_idx: number, other_card: Card?) Having the type system enforce null checks on uses of other_card (and also on all uses of cards from other zones, like the opponent's battlefield or the player's hand) would have saved me a lot of trouble. As it is, I use a fuzzer to play lots of games between AI players and look for errors, but most of the errors I look for could have been caught by a compiler instead.
ufo 12y ago
The main advantage is that anything that you can turn into a a type error will be reported at compilation time, much earlier in the development cycle. This is not just a matter of safety but also helps in terms of refactoring and testing. This includes things like typos (wrong method names, etc) but where types really shine is refactoring. If you want to add or remove a parameter from a function or change a string field to an integer then you can use guidance from the type checker to be sure that you didn't forget to update anything. Its a bit like adding bumpers to the side of the bowling lane - it lets you be more reckless, updating things until the compiler shuts up without needing to carefully go through each line. --- Also, don't forget that gradual typing solutions such as Typed Lua are all about letting you program dynamically if you want. The idea is that you would only convert to the typed dialect in the parts of your program where that would suit you.

aaron-lebo 12y ago

So Lua is faster/simpler/smaller than pretty much every other dynamic language and now has optional typing as well. Why have we not seen an effort to build a solid ecosystem around it the way node has with JS? Lua with equivalent libraries to Python/Ruby/Javascript/PHP would be superior to any of them.

srean 12y ago
You may want to take a look at openresty [1] moonscript [2], Lapis [3] and Kepler [4] . There has been some more direct efforts to port the "Node.js way" to Lua, one such is luvit [5] (significant overlap in the developers list) on the otherhand luv [6] exposes the underlying libraries slightly differently. Lua really ought to be considered JS done right and Eich should really have been given enough time to bring scheme to the browser (syntax could have been negotiable). Another interesting project is Typed Racket http://docs.racket-lang.org/ts-guide/index.html?q=typed http://docs.racket-lang.org/ts-guide/index.html?q=typed and Guile http://wingolog.org http://wingolog.org if this sort of things interests you. [1] http://openresty.org/ http://openresty.org/ [2] http://moonscript.org/ http://moonscript.org/ [3] http://leafo.net/lapis/ http://leafo.net/lapis/ [4] http://www.keplerproject.org/ http://www.keplerproject.org/ [5] http://luvit.io/ http://luvit.io/ [6] https://github.com/richardhundt/luv https://github.com/richardhundt/luv
- vbit 12y ago
  Another related effort is http://turbolua.org/ http://turbolua.org/
zorked 12y ago
Lua is very popular in some niches, like games and embedded stuff. Language adoption is a very social thing though. Maybe if Rails was a Lua framework we would be wondering why Ruby never made it big.
- stevekemp 12y ago
  Agreed. Lua is embedded in things like Redis, and is often uses as an extension/configuration language for small projects. I based my mail client(http://lumail.org/ http://lumail.org/) around Lua as a configuration language because I kept getting annoyed by the almost-configuration-language used in mutt. Actually writing applications in Lua is also possible, for example the chat/Jabber server Prosody.

fuzzythinker 12y ago

Link to the missing github page (maybe the paper is written before his github page was ready)? https://github.com/andremm/typedlua https://github.com/andremm/typedlua

ufo 12y ago
The github page has always been there, even before he started writing the paper. Its still very experimental though and I don't think its ready for general use yet.

lomnakkus 12y ago

Is it just me, or does anyone else feel that gradual/optional typing isn't good enough? I've been trying out Typescript in a couple of nontrivial projects, and sure, it does catch some errors, but as long as you're forced to integrate with an unityped world it doesn't really catch enough problems to be worthwhile, IME. You can of course write type declarations for all your "foreign" libraries, but that's just an added burden that you (the programmer, not the language) have to get right. Plus, since the unityped language is so flexible (and thus conventions are different vs. a multityped language), there are things in the unityped language that cannot be sensibly typed without just resorting to saying "any" (which is the only type of the unityped language).

smrq 12y ago
The biggest benefit of Typescript in my opinion is the potential for stronger tooling. There's definitely room for improvement (I suspect type unions would fix a majority of the times you are forced to use "any"), but I have found type declarations to be relatively low overhead for a substantial gain. Re: foreign libraries, as long as you are using TSD / DefinitelyTyped (http://definitelytyped.org/tsd/ http://definitelytyped.org/tsd/), that burden is crowdsourced. I've written a few library type declarations, but used many more from others. The flipside of the complaint is that I've found it really quite nice to have type checking for libraries I don't know inside and out. And you can always cheat and declare your external libraries as "any" for the sake of making the compiler happy, if you don't want to go through the effort to get the reward. Obviously, to get something like DefinitelyTyped going, you need a critical mass of developers, so that may or may not work out for Typed Lua.
- lomnakkus 12y ago
  My experience is that DefinitelyTyped definitions are actually not very accurate in practice. This may be a consequence of language restrictions or just typical (and understandable) programmer laziness ("good enough!") -- or, as you say, the lack of type unions. It's better than nothing, but not really good enough. But then I have been spoiled by Ocaml and Haskell, so... (There's also the whole external/internal module confusion in TS, but that's not related to the general theme of gradual typing per se, so it's not really relevant to non-TS contexts.)

malkia 12y ago

Luajit is awesome too, but if you are looking for tighter debugger integration in MSVC then look at HavokVM - which is lua vm - you can mix native/lua callstack and it works just fine. http://www.havok.com/products/script http://www.havok.com/products/script