4 ms·

It goes beyond that, though. One of Lua's goals is to be implemented in 100% portable C, to the extent that it has no platform-specific #ifdef's (no #ifdef's at

It goes beyond that, though. One of Lua's goals is to be implemented in 100% portable C, to the extent that it has no platform-specific #ifdef's (no #ifdef's at all, actually). This means that to use a lot of incredibly basic functionality supported on all relevant operating systems (like, as mentioned in another comment, changing directories), you need (for vanilla lua and luajit on platforms that don't support the ffi) a C library dependency, or a wrapper script (for luajit on the other platforms). This is pretty silly; any user of a platform without a filesystem would surely know that chdir would not be supported. Beyond that kind of indefensible omission, there is much ecosystem fragmentation and duplicated effort that could be solved by standardizing tools like a package manager without requiring you to install it on embedded targets.

catwell 12y ago
This "indefensible omission" is solved by using LuaFileSystem. Not having it in the core language is not such a problem. Another example is sleep(), which is not portable. You can find a sleep function in libraries like LuaSocket and luaposix. Fragmentation, however, is a problem. The Lua authors have often refused to "bless" (term used by the community when discussing this) libraries. Roberto Ierusalimschy even said during a Q&A he'd rather "bless" a group of people to do it instead of him. The problem is, as several people said in this thread, that it is very hard to write a library that fits every use case. Even something almost "standard" like LuaSocket is not used by everybody. Some people in the community (including me) are trying to reduce the fragmentation. The authors of the two main ways to manage "packages" (LuaRocks and LuaDist) are working together, etc. But I think we will never manage to standardize on One True Library for everything.
- ANTSANTS 12y ago
  I didn't say you couldn't write a trivial library to access sleep or chdir, just that I think it's ridiculous to need to do so. You may disagree, and clearly we can still get work done in the language, but IMHO Lua is suboptimally small, and the local maxima for "tiny yet useful" languages would have a lot more in the standard library and a few "blessed" tools to boot. A language with the goal of implementing in the standard library everything trivial, fungible (one chdir wrapper is as good as any other), useful for most users, and portable across major desktop and mobile OSes (embedded users will know if they don't have e.g. a filesystem) would be a lot more useful yet probably not meaningfully larger than the existing implementations of Lua. Sure, this would mean more stuff to lock down if you're using it as a sandboxed scripting language, but a compile-time flag with reasonable defaults for a sandboxed environment could be provided.
- Houshalter 12y ago
  The os.execute function does all this. os.execute("timeout "..seconds) for example. More complicated for file system operations, but it's possible. This is significantly less than optimal though.
  - catwell 12y ago
    And not portable (or safe, for things like path manipulation). But sure, you can still use os in small scripts.
vertex-four 12y ago
Why would you want somebody to be able to chdir or otherwise manipulate global state in, say, a dialog script for a game engine, though? You probably don't. You probably don't want them to be able to do lots of things. Hence the standard library lacking most things. Yes, having a package manager might solve some issues, but not for any of Lua's primary use cases. It's not supposed to be the language you write your web app in, or a shell script replacement, or whatever else, and the language developers really don't care about those use cases. It's not supposed to be anything out of the box aside from some syntax and semantics that are Turing-complete and reasonably usable. Where I've seen Lua used, often even the existing standard library is modified or not used at all due to constraints from the embedding program. What point is a package manager if you can't use most of the packages in many environments? This isn't just embedded ones - this is on the desktop as well. If you're looking for something more capable out-of-the-box, I'd go for embedding Python or Ruby. Lua simply serves a different niche.

catwell 12y ago

This "indefensible omission" is solved by using LuaFileSystem. Not having it in the core language is not such a problem. Another example is sleep(), which is not portable. You can find a sleep function in libraries like LuaSocket and luaposix. Fragmentation, however, is a problem. The Lua authors have often refused to "bless" (term used by the community when discussing this) libraries. Roberto Ierusalimschy even said during a Q&A he'd rather "bless" a group of people to do it instead of him. The problem is, as several people said in this thread, that it is very hard to write a library that fits every use case. Even something almost "standard" like LuaSocket is not used by everybody. Some people in the community (including me) are trying to reduce the fragmentation. The authors of the two main ways to manage "packages" (LuaRocks and LuaDist) are working together, etc. But I think we will never manage to standardize on One True Library for everything.

ANTSANTS 12y ago
I didn't say you couldn't write a trivial library to access sleep or chdir, just that I think it's ridiculous to need to do so. You may disagree, and clearly we can still get work done in the language, but IMHO Lua is suboptimally small, and the local maxima for "tiny yet useful" languages would have a lot more in the standard library and a few "blessed" tools to boot. A language with the goal of implementing in the standard library everything trivial, fungible (one chdir wrapper is as good as any other), useful for most users, and portable across major desktop and mobile OSes (embedded users will know if they don't have e.g. a filesystem) would be a lot more useful yet probably not meaningfully larger than the existing implementations of Lua. Sure, this would mean more stuff to lock down if you're using it as a sandboxed scripting language, but a compile-time flag with reasonable defaults for a sandboxed environment could be provided.
Houshalter 12y ago
The os.execute function does all this. os.execute("timeout "..seconds) for example. More complicated for file system operations, but it's possible. This is significantly less than optimal though.
- catwell 12y ago
  And not portable (or safe, for things like path manipulation). But sure, you can still use os in small scripts.

vertex-four 12y ago

Why would you want somebody to be able to chdir or otherwise manipulate global state in, say, a dialog script for a game engine, though? You probably don't. You probably don't want them to be able to do lots of things. Hence the standard library lacking most things. Yes, having a package manager might solve some issues, but not for any of Lua's primary use cases. It's not supposed to be the language you write your web app in, or a shell script replacement, or whatever else, and the language developers really don't care about those use cases. It's not supposed to be anything out of the box aside from some syntax and semantics that are Turing-complete and reasonably usable. Where I've seen Lua used, often even the existing standard library is modified or not used at all due to constraints from the embedding program. What point is a package manager if you can't use most of the packages in many environments? This isn't just embedded ones - this is on the desktop as well. If you're looking for something more capable out-of-the-box, I'd go for embedding Python or Ruby. Lua simply serves a different niche.