
Typed Lua: An Optional Type System for Lua [pdf] - ihnorton
http://www.lifl.fr/dyla14/papers/dyla14-4-typed-lua-an-optional-type-system.pdf
======
aaron-lebo
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.

~~~
fit2rule
I think what happens with Lua (which does, incidentally, have many solid
ecosystems built with it) is that it just gets quietly used in industrial-
strength ways which don't require too much fanfare/promotion in order to
propagate it as a tool - which is not the case with node, which aims to be a
solution to industry-wide problems which Lua solves in other ways.

One thing that I think people get confused about Lua is that its
simultaneously a VM, a language, and a very minimal framework, around which
many, many things can be glommed. The glomming of those things is so flexible
and versatile that - indeed perhaps we see _too much diversity_ in the Lua
appliance world, for there to be any common centralized traction around
promoting it, as has happened with node.

If you want to see how Lua really has a solid ecosystem, then you have to look
for projects that have embedded the VM and are using it as the basis for their
application run loop. And indeed, there are plenty of projects out there doing
this, that it can't really be said Lua doesn't have traction; it just doesn't
attract as much hype. Lua has _plenty_ of libraries; its just that the "FFI
all the things!" approach means that you can, pretty much, indeed FFI all the
things. No standards committee required!

~~~
malkia
Same with P4 :)

------
lomnakkus
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 _uni_ typed 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
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
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.)

------
fuzzythinker
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
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.

------
malkia
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)

------
tendom
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
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.

~~~
fit2rule
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! :)

~~~
ufo
Similarly to Javascript, all numbers in Lua are floating point numbers and all
number operations are floating point operations. Integers can be represented
accurately up to 2^53.

~~~
nly
Changing the Lua number type from a float to an integer type is something like
a 3 line patch.

