MuJS: an embeddable JavaScript interpreter • Hacker News Board

Re: MuJS: an embeddable JavaScript interpreter

#51

Post by xavel » Tue, Mar 17, 2015, 2:29 PM UTC

angersock wrote: post #36

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.

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? :|

Yes, of course. But that's ABI, not API.

Re: MuJS: an embeddable JavaScript interpreter

#52

Post by dmytrish » Tue, Mar 17, 2015, 3:03 PM UTC

Pretty good implementation:

    > [] == []
    false
    > [] + []

    > {} + []
    0
    > [] + {}
    [object Object]
    > {} + {}
    NaN

Although it fails in this part (should be [10, NaN, 2]):

    > [10, 10, 10].map(parseInt)
    10,0,2

Re: MuJS: an embeddable JavaScript interpreter

#53

Post by Aldo_MX » Tue, Mar 17, 2015, 4:01 PM UTC

justincormack wrote: post #48

Aldo_MX wrote: post #42

Earlier quoted context omitted.

You are making assumptions about the needs of a project to endorse your favorite language. 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…

(a) Tessel produced a pretty complete open source JS to Lua converter, which runs node[1] (b) People are not dumb, they can learn Lua. It is easier than learning JavaScript. [1] https://github.com/tessel/colony-compiler

> (b) People are not dumb, they can learn Lua. It is easier than learning JavaScript.

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.

Re: MuJS: an embeddable JavaScript interpreter

#54

Post by angersock » Tue, Mar 17, 2015, 4:11 PM UTC

xavel wrote: post #51

angersock wrote: post #36

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. Um, what is the C ABI for invoking functions? :|

Yes, of course. But that's ABI , not API.

An ABI is the API a computer understands.

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.

Re: MuJS: an embeddable JavaScript interpreter

#55

Post by kodablah » Tue, Mar 17, 2015, 5:29 PM UTC

chc wrote: post #4

kodablah wrote: post #3

I understand the AGPL and the want to monetize the work, but it just feels so disingenuous to have to contact for commercial details.

How is that disingenuous? It seems pretty forthright about its licensing to me.

Because they have to be contacted to determine a price instead of making pricing clear. (I am not saying that they will not price consistently, I'm just saying it's a bit off-putting)

Re: MuJS: an embeddable JavaScript interpreter

#56

Post by yellowapple » Tue, Mar 17, 2015, 7:53 PM UTC

LukeShu wrote: post #35

yellowapple wrote: post #22

Earlier quoted context omitted.

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…

AGPL code can be dynamically linked to GPLv3 code. That's about the extent of their compability. Statically linking MuJS in even a GPLv3-licensed program would be a violation of at least one or the other, and virtually all other cases of linking - dynamic or static - with AGPL code would also be a violation of at least the AGPL (and possibly the other license, depending on its terms).

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

Re: MuJS: an embeddable JavaScript interpreter

#57

Post by chc » Tue, Mar 17, 2015, 8:16 PM UTC

kodablah wrote: post #55

chc wrote: post #4

Earlier quoted context omitted.

How is that disingenuous? It seems pretty forthright about its licensing to me.

Because they have to be contacted to determine a price instead of making pricing clear. (I am not saying that they will not price consistently, I'm just saying it's a bit off-putting)

That's pretty common in enterprise sales. It's a way to have some leverage in implementing pricing gradients. For example, you might want to charge $200k to Microsoft for a given technology, but charge much less to an indie game company since there's no way in hell they could swing $200k for whatever you're selling. Different companies often even want different terms in their contract, so it makes decent sense.