Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MuJS: an embeddable JavaScript interpreter

mujs.com

Post reply on HN
Print view View original

31–40 of 57 posts

Re: MuJS: an embeddable JavaScript interpreter

#31

Post by nknighthb »

xavel wrote: post #28
nknighthb wrote: post #18

Earlier quoted context omitted.

> And what if those companies wish to provide their software to customers? 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…

>They can abide by the free license, or pay for a different license 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').…

> My point is about the clause in the GPL that enforces developers to enclose the source of their entire software, not just the library.

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?

Re: MuJS: an embeddable JavaScript interpreter

#32

Post by xavel »

marktangotango wrote: post #29
xavel wrote: post #27

Earlier quoted context omitted.

The grand majority of programming language APIs do not use a stack-based API. Really, stack-based APIs are an exception in just about every way, but not in a good way. 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.

>> What's would you do instead of the stack-based API? Did not see you answer the question here. You have a strong opinion, what would you like to see instead?

It's not so much about what I would like to see, but rather why some developers insist on copying Lua's stack-based API, merely because so many people have accepted Lua as the very definition of a lightweight, embeddable programming language.

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.

Re: MuJS: an embeddable JavaScript interpreter

#33

Post by xavel »

nknighthb wrote: post #31
xavel wrote: post #28

Earlier quoted context omitted.

>They can abide by the free license, or pay for a different license 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').…

> My point is about the clause in the GPL that enforces developers to enclose the source of their entire software, not just the library. 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…

> Nitpick about what? Subtle about what? What are you talking about?

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.

Re: MuJS: an embeddable JavaScript interpreter

#34

Post by nothrabannosir »

xavel wrote: post #14
nothrabannosir wrote: post #10

I see hate for the licensing model they chose. But think of it this way: who is their target audience? Who would want a small, embeddable JS engine? I think they're targeting businesses who want to deploy node.js code on micro to small devices. Routers, NASes, that sort of thing. 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 reser…

And what if those companies wish to provide their software to customers? Enter a terrible hell of "how are we going to relicense our stuff", that'll most likely end up with said companies switching to a different library. 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…

Guys, it's double licensed. You are describing exactly the point: they don't want companies to use this without paying. Pay, and you can redistribute it to your clients.

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.

Re: MuJS: an embeddable JavaScript interpreter

#35

Post by LukeShu »

yellowapple wrote: post #22
robmccoll wrote: post #11

Earlier quoted context omitted.

One immediately apparent difference: duktape has a more liberal and commercial friendly license (MIT), while MuJS has a much more restrictive license (AGPL).

This is a pretty big deal for me. MuJS is a non-starter if I can't even use it in GPL'd software (let alone copyfree-licensed software; my preference for my own projects is the MIT license, so being able to include something without having to change that - as duktape offers - is ideal).

Sure you can use it with GPL'd software[0] or MIT licensed software! It doesn't stop the GPL from applying to any GPL'd code, nor the MIT license to any MIT'd code. The AGPL does say that when it is used, the sources must be available to the users; but that doesn't mean that when someone takes your (MIT or GPL) code and changes it, and uses it [without MuJS or other AGPL code], that the AGPL applies.

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

Re: MuJS: an embeddable JavaScript interpreter

#36

Post by angersock »

xavel wrote: post #27
chubot wrote: post #26

Earlier quoted context omitted.

What would you do instead of the stack-based API? That's the best design there is AFAIK. 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.

The grand majority of programming language APIs do not use a stack-based API. Really, stack-based APIs are an exception in just about every way, but not in a good way. 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.

The grand majority of programming language APIs do not use a stack-based API. Really, stack-based APIs are an exception in just about every way, but not in a good way.

Um, what is the C ABI for invoking functions?

:|

Re: MuJS: an embeddable JavaScript interpreter

#37

Post by jaen »

xavel wrote: post #13

Maybe it's just me, but I'm not a particular fan of Lua-inspired pseudo-stackbased APIs. 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 lik…

Explicit stack-based interfaces are used for good reason: This allows simple accurate garbage collection (see eg. the Ruby API which requires somewhat error-prone conservative GC, Python which requires refcounts all over the place, or OCaml which requires annotating all local variables in a special block). A custom frame stack is also needed to have coroutines in pure ANSI C (two of the reasons Lua is popular).

Re: MuJS: an embeddable JavaScript interpreter

#38

Post by have_humility »

rossy wrote: post #17
nothrabannosir wrote: post #10

I see hate for the licensing model they chose. But think of it this way: who is their target audience? Who would want a small, embeddable JS engine? I think they're targeting businesses who want to deploy node.js code on micro to small devices. Routers, NASes, that sort of thing. 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 reser…

The AGPL is a pain though. MuJS was going to be used to add JS scripting to mpv, but the patch has been put on hold since the devs realised it was AGPL licensed and it could cause license compatibility issues with compiled binaries or libmpv users. I don't think MuJS will be used by anyone outside of GhostScript until they change their license to a more reasonable one.

It's already used with MuPDF, and things that embed it. I was eyeballing it last week in the source tree for the EBookDroid fork "Document Viewer".

Re: MuJS: an embeddable JavaScript interpreter

#39

Post by namuol »

passthefist wrote: post #16
0x0 wrote: post #8

Strange that the example has 'js_dofile("config.lua")'... Is there lua in here?

Which begs the question: why not use Lua to begin with, at least when starting a project? I totally get the use for this if you've got some existing JS and for some reason you need to talk to C. I've seen crazier things. But 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 key…

Seeing as this was built by the creators of MuPDF [1], I'm guessing they built this because they need to use JS to support embedded JS forms.

1: http://www.mupdf.com/ (artifex)

Re: MuJS: an embeddable JavaScript interpreter

#40

Post by sesquipedalian »

xavel wrote: post #13

Maybe it's just me, but I'm not a particular fan of Lua-inspired pseudo-stackbased APIs. 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 lik…

Agreed. The biggest drawback IMHO is you defer errors that could have been caught at compile time to runtime if you had a saner interface.
Post reply on HN