MuJS: an embeddable JavaScript interpreter
mujs.com
mujs.com
[0]: GPLv3, that is. Fortunately, most GPL stuff is "v2, or at your option, any later version." Unfortunately, there is quite a bit of just v2 stuff out there.
So yeah, sure, you can incorprate MuJS in an MIT-licensed project, but by doing so, you're effectively required to license the entire work (your code + MuJS) under the AGPL (or a license - like the GPLv3 - that's explicitly authorized for dynamic linking; this, again, doesn't apply for static linking).
Remember that languages are tools, not sport teams.
There are needs that completely disregard any of the benefits you mentioned with lua, for example:
a) How can Lua help me run existing JavaScript code?
b) Why is Lua more cost-effective than embeddable JavaScript interpreters considering the
following:
1. the cost of learning how to embed and work with the Lua interpreter
2. the cost of learning the scripting language with all its implications: a different
syntax, a different way to work enforced by its standard library (ex. 1-indexed
arrays), new quirks (ex. commenting nested arrays), etc.
3. the cost of training people from other areas which are already accustomed to
JavaScript(b) People are not dumb, they can learn Lua. It is easier than learning JavaScript.
https://github.com/tessel/runtime
https://tessel.io/blog/102381339917/a-new-engine-for-your-te...
I was not saying that people is dumb, I was saying that learning it requires extra time and effort, and that increases the cost of a project.
In that light, it's great they even decided to publish the source under AGPL at all. They could just as well have kept it "all rights reserved".
No, the GPL, especially the AGPL is inherently bad for libraries. Libraries, mind you, not software in general. Like I've written in my other comment, the LGPL solves this issue painlessly.
Besides that, node.js won't run with MuJS, because node.js depends on V8 and libevent. Unless some poor sod actually reimplements the entire nodejs stack... but I hope people are smarter than that. :-)
They can abide by the free license, or pay for a different license. Or, yes, switch to a different library. They are not entitled to use this library, nor any other library.
> No, the GPL, especially the AGPL is inherently bad for libraries.
If this library were not available under any sort of open-source license, would you be making the same post, insisting it's "bad" for them not to give you free stuff?
Or... use a library that suffers none of these issues. :-)
My point is about the clause in the GPL that enforces developers to enclose the source of their entire software, not just the library. The LGPL however, does not require that, which is why the LGPL is also occasionally called "GNU Library License" (though the 'L' in LGPL stands for 'Lesser').
And lets not nitpick here, the GPL isn't exactly subtle about these things.
>If this library were not available under any sort of open-source license, would you be making the same post, insisting it's "bad" for them not to give you free stuff?
No. It's their right to choose whatever license they wish, but it's also my right to not choose their software.
I'm well aware of it. Everybody is. It's a term of the license. Just like "You must pay us $5000 to use this library" would be.
> And lets not nitpick here, the GPL isn't exactly subtle about these things.
Nitpick about what? Subtle about what? What are you talking about?
> No. It's their right to choose whatever license they wish, but it's also my right to not choose their software.
It certainly is.
But you said it's "bad". But it wouldn't be "bad" if they hadn't made it available under a free license at all.
This seems like a hypocritical and extremely entitled attitude. Under what moral code is it bad to offer alternative prices for alternative terms?
The clause I mentioned. I'm sorry if I was ambigious, but there were discussions in the past hovering about how the GPL still allows commercial software, and such. Yes, of course the GPL allows you to make good money, but in just about every example given, the actual bulk of the money isn't made from the software, but from the hardware the software just so happens to be running on (i.e., modems, smartphones, branded computers, mainframes, chipcards, etc).
> Under what moral code is it bad to offer alternative prices for alternative terms?
By claiming to offer Free Software™ with a very restrictive copyleft license with one hand, and expecting a 3-4 figure with the other in case you plan to use it on anything else than free software.
It's a little bit like imprisoning someone for their own safety, and expecting money if they wish to breath a little air.
I never claimed that there's anything wrong with the GPL/AGPL, but I do claim that there are cases where the GPL is a good choice, and then there are cases where it is not.
This is basically for-profit code from a for-profit company, with a side dish of "open source for open source projects." It's like... like Github. Like Travis-CI. Like QT.
Or you can release your code under the AGPL and keep all your money.
> This is basically for-profit code from a for-profit company, with a side dish of "open source for open source projects." It's like... like Github. Like Travis-CI. Like QT.
This is not like Github. Github does not release all of the source code powering their app.
An irrelevant anecdotal note: Router firms can make distribution of source code harder to circumvent GPL. A router firm that a friend works distributes source code using CDs. So if you bought a router and wanting the source code for modified kernel etc., you send your request using email/telephone/mail/fax and get your own copy via snail mail.
People willing to pay for a commercial license.
Many companies which want to sell software release a GPL-ed version as a kind of demo (and being able to add the "open source" buzz word to the description of their product does not hurt either).
That the (A)GPL makes this library unusable for most people is the reason why they chose that license; not because of Free Software idealism but because of commercial interests.
I'm not sure why so many language devs insist on this terrible design. I fail to see anything good about it; It doesn't make the code smaller, it doesn't make the code faster, but it does make abstraction a royal pain in the buttocks.
Also, they couldn't have possibly chosen a worse license for a library that is going to most likely embedded statically in a program. Of all licenses, why AGPL? If it has to be GPL (whyever is none of my concern), why not LGPL?
Lua started out with something like Python's API (Lua 3.0 I think), but they changed it to use the explicit context and stack.
If your question is about cheap memory storage, linked list algorithms already exist, so there's really no good reason to use a faux stack to store data.
Did not see you answer the question here. You have a strong opinion, what would you like to see instead?
It seems like a false promise to me is all I'm saying. People get lured in with a very questionable tactic, and then start to believe "stack-based API == tiny and great", whereas I think that this is a pretty bold statement.
In any case, I did answer your question - you can achieve the same level of minimalism by using linked lists, and yes, OOP in C. Shouldn't be exactly news to anyone who has learned C (not that difficult anyway). I don't see any compelling reasons to choose a stackbased API over anything else.
I've found myself figuratively battling with Lua when I tried to create nontrivial objects, such as metatables with constructors, indices, missing indices handling, etc, you name it. It's fun and easy for small things, but gets cumbersome really quick. And inline-evaluating Lua code just because the API has been updated in some odd ways, so that previously perfectly fine working code now compiles, but no longer works, just feels hacky to the max.
With a non-stackbased API, this is literally just a matter of walking function calls (the native program stack). But with a stackbased API, you have to walk the machine stack AND the API stack.
That's not fun. Not even remotely. This is how you teach a programmer to hate programming.
Um, what is the C ABI for invoking functions?
:|
It makes a great deal of sense, especially when dealing with an interpreter for a stack-like machine, to expose language bindings in terms of that stack.
It's not super friendly, mind, but it makes perfect sense.
"Why? Because V8, SpiderMonkey and JavaScriptCore are all too big and complex. MuJS's focus is on small size, correctness and simplicity."
I'd be interested to see how ES5-compliant MuJS really is. My guess is probably different from what they claim.
> [] == []
false
> [] + []
> {} + []
0
> [] + {}
[object Object]
> {} + {}
NaN
> [10, 10, 10].map(parseInt)
10,0,2But I'd say the solution to 'I need a scripting language to talk to C' is solved very well by Lua.
*Edit:
After looking at the example it's C API is surprisingly similar to Lua's, even using such keywords as userdata. So that's interesting, considering they're really similar languages.
The function js_dofile doesn't look like it's doing anything with lua, nor can I find any use of lua at a cursory look at the source. I'd guess that since Lua and JS share syntax they are loading a .lua file with valid JS syntax.
That said, there are plenty of other options out there. Even for JS embedding, there are projects like duktape that already address this need (supposedly; I haven't personally used duktape in any of my projects).
1: http://www.mupdf.com/ (artifex)