4 ms·

Well, my lament in the first place is that Lua could be a good and fast general-purpose scripting language. Instead, I can have ‘good’ but then I'll have to sit

• nikki93 6y ago
  Have you tried lua-cjson, out of curiosity? They use a cjson.null (or something like that) value for nulls in JSON. But yeah agree with what you've said in general, if I had to do some API JSON manipulation Lua isn't what I'd jump to, even though I'm pretty familiar with it. Do Python or JS actually take that much longer to start up for a script? Node starts up pretty quickly on my system.
  • aasasd 6y ago
    Now that I think of it, cjson.null might be workable even with data-transformation libraries, since it's some Lua meta-voodoo-value that can't come in the input from other systems. But then, of course, there's the problem that other data-exchange libs invent their own voodoo-values for null, like ngx.null. Precisely because they need it for actual integration use-cases. As for the performance, I happen to use an underpowered machine, which is how I discovered the drastic difference with Lua. However, performance still matters beyond just ‘pretty quickly’ if you consider desktop software, especially productivity software—which has to be snappy. Scripting your productivity software is a textbook case for dynamic languages, and almost the exact niche for Lua. Even on my machine, there was a moment when I had to make sure that Alfred actually called my Lua script—because the results popped up immediately (despite going through the command-line interpreter, not Luajit). Meanwhile, people are making productivity software with Electron or Python, which to me verges on ridiculous.
    • nikki93 6y ago
      Yeah, I definitely care about performance more in that tradeoff. In my experience when performance matters, these details about using such a null representation and what different representations lend themselves also tends to matter. vs. gluing libraries to libraries willy-nilly. At that point this null issue is far from the main thing that comes up bc. you care about data layout enough that you have control over that representation. One example I'm running into in practice these days is--I'm using chipmunk2d game physics engine in a library. It does heap allocations, while all the component data for other stuff in my game tends go be well managed into pools that I can walk through contiguously. Even if I use a custom allocator for it, it uses pointers to refer between objects internally so I can't "move" instances of its eg. `cpBody` object around in memory. Would've been so nice to just own its data and let the library be layout-agnostic but alas. But yeah those are the data-data glues I've been interested in--libraries that kind of own representation but not location I guess. For your particular issue though, I think it really is bc. Lua is a language that out of the box doesn't tend to own representation, to the point of not eg. having its own class system etc, and it mostly shines when used in ways that play into that strength (eg. you want to wrap your own object ontology for ppl to script). The best libraries for Lua have tended to the invent their own representation and expect you to care about and own the mappings between libraries. esp. for JSON, the impedance mismatch with Lua tables puts it in this weird uncanny valley. Tbh my fav method of using JSON is to not have an in memory document format at all and just treat it as reader / writer objects directly into domain data so that you don't keep paying this intermediatw representation conversion cost. eg. https://github.com/beached/daw_json_link https://github.com/beached/daw_json_link is interesting here In my own game stuff I just have game components accept reader/writer objects to read from / write to and each component tends to have domain logic about what it means to be missing something, what some defaults are, etc.
      • aasasd 6y ago
        > when performance matters, these details about using such a null representation and what different representations lend themselves also tends to matter. vs. gluing libraries to libraries willy-nilly Well, Lua juuuust about hits the sweet spot of a good ‘layman’ dynamic language with great performance, and my hope is that perhaps it could be moved a bit to the generic-scripting-language side without losing performance. Basically, since libraries invent magic values to use instead of null, presumably Lua could provide such a value for them all to agree on. > for JSON, the impedance mismatch with Lua tables puts it in this weird uncanny valley Not seeing the mismatch here: to my knowledge, tables can be employed as (untyped) arrays or dictionaries, exactly the structures in JSON—and what I've long been using in PHP, JS and Python. If I'm not forgetting something, null is the only thing missing from making this triumvirate an integrated quartet. > Tbh my fav method of using JSON is to not have an in memory document format at all and just treat it as reader / writer objects directly into domain data so that you don't keep paying this intermediate representation conversion cost As we're discussing this on a post about a Lispy thing, I personally can't back your approach, for I'm lately buying into functional transformations big-time. Here I'm more on the convenience side: it seems to work fast enough for interactive desktop cases, though I've heard that the in-place method works wonders for busy web apps. In fact, afaik some high-level languages/environments kinda do the in-place thing implicitly by not copying strings between structures or when extracting substrings, and possibly by doing COW. Dunno if Lua does any of that (afaik it copies pointers between structures, not the data—this behavior is pretty much expected of runtimes these days). However, I occasionally do wish that Clojure-style lazy structures were more widely employed, so I could use transformations without worrying that they might crunch some stuff needlessly.