xavel's comments

That explains why these kind of news have been entirely absent from slashdot (with the exception of that one heavily castrated entry).

The link in question is actually "http://yurivish.com/Silk%20Static/Silkura%20-May%2002%20-loo... - yurivish.com seems to be a loop to localhost (maybe broken DNS or something, I don't know). Apparently it's supposed to have some music playing in the background, as is also indicated in the message when you click the question icon in the top right corner.

Is that argument supposed to be in favor of Kallithea? Because I don't see how it does, tbh.

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

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

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.

About 'correctness' and 'small size' ... as soon as they'd add unittests as extensive as V8, JSCore, or SpiderMonkey, it'd grow big quite dramatically. :-)

I'd be interested to see how ES5-compliant MuJS really is. My guess is probably different from what they claim.

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

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.

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.

Well, that's just Oracle being Oracle. They did the same nonsense with Opensolaris, if I recall correctly.

I noticed that too. My theory is that MuJS started out as a fork of Lua, with all sorts of Ecmascript-compat bolted on. Use with care, I suppose.

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

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

Aw, now I'm really interested in seeing what the jsfiddle was, but the post got killed... :(

I'm from Germany, so I see what you mean -- in Europe, especially central and northern europe, there's hardly any need to share files physically. But alternatives are necessary in times like these, which is why I'm glad things like P2P-services exist.

I guess you could say I'm merely planning for the future. Not that I wish that I'd ever actually have to go about sharing data via physical mediums, but I wouldn't exactly bet on it.

1.50$ for an entire pack of USB sticks? Where did you find such an offer? Because according to amazon, the cheapest they have are a pack of 10 USB sticks, 1GB, for 39$:

http://www.amazon.com/dp/B00E3MII96/

Not exactly cheap, if you ask me. Not exactly super-expensive either, of course, but definitely not cheap. And I think the reasons the price for floppy disks doesn't seem to go down is because only certain people still use floppy disks, i.e., the need for floppy disks is nearly non-existant.

>Can you elaborate on why you feel a need for such physical media?

Maybe it's not perceived the same way in the USA, but in Europe, most people who use cloud-services find it increasingly difficult to trust american cloud-services, thanks to the NSA. Hence why I'm looking for alternative ways to share sensitive information, programs, documents, you name it.

There's of course also owncloud, which is nice enough, but let's just assume that some may not even have access to the internet in the first place.

So, with respect to the point you made (make no mistake, it's a very good point), I say that there are scenarios that justify need for physical mediums to share data.

Oh man, and I'm glad they finally settled for Phobos. I don't use D much, but thanks to gdc, the gcc frontend to dmd, and Phobos, writing D actually became acceptable, almost enjoyable. There's, of course, still the fact that D is not very widely used.

Pretty impressive, I didn't know Erlang was suitable for web programming. :-)

Nonetheless, you really should make sure that input is sanitized. XSS attacks are a nasty thing.

Not to worry, but sanitizing input literally takes no more than one additional function call (at least for php/ruby/python/perl/nodejs/java/c#/ocaml).

I can understand that this might be a hassle if you've written this app in COBOL, or some other word-heavy language. In which case, my most sincere condolences.