LLVM are only getting funding because Apple wants to undermine GCC.
What on Earth would Apple gain by undermining GCC? I guess it would benefit Apple's buddy Intel, but Intel's compilers are already superior to GCC on its own chips, so I don't imagine it's too bothered.
Yes, this is exactly the issue. GPL isn't "more free" than BSD. Quite the opposite. GPL is far less free as it grants the users less freedoms.
The BSD approach is "Here is something nice I made - have it and do what you like, hope you have fun!"
The GPL approach is "Here is something nice I made - you can use it, but if you you have to let me play with you stuff. I don't care that your thing might be vastly better or more complicated than mine, if you're using my stuff you sure better make sure I can use everything you make."
I think you've mischaracterized the GPL approach. By using the personal pronoun, you make it sounds like the GPL forces people who make derivative works to do things for the original developer. That's not the intent at all. The intent is to make sure that people who make derivative works do things for everyone – meaning everyone collectively, not individually. GPL grants users lots and lots of freedoms; the one freedom it does not grant is the freedom for you to withhold from others the freedoms that you yourself enjoy. BSD does grant you that freedom.
Yeah
What is with all the HAL©, HAL(Circle-C) nonsense in the submission? Is that supposed to be some kind of joke? Looking at the website, the company doesn't style the product name that way. Is it supposed to be some sort of winking reference to copyright (hurrr, hurrr)? Because that doesn't make any sense...
It is not random. If you have enough knowledge and the ability to comprehend that knowledge, you can predict what will happen. Nothing is random.
Sure, as long as you start a program and let it run all by itself without touching anything. As soon as you introduce human input, the system may still be deterministic, but the output of the program is in effect random because the behavior of the operator cannot be predicted. The kind of "knowledge and the ability to comprehend that knowledge" that you describe is known as omniscience, and most IDEs currently don't support it.
40 here, birthday's in March.
A really common one is simply, "I feel fine. I feel better than I have in years, and I've felt this way for months." That's when people really start looking at side effects with a critical eye ("it makes me foggy") and decide they can go it on their own. And often it's insidious; if someone is manic, for instance, at what point do family members step in and say "you're not doing as well as you think you are"? If you're skipping your treatment, you're probably not getting the feedback you need to properly evaluate where you're at.
What are you talking about? JavaScript must always necessarily be slower than native code due to its abstracted nature. If it needs an interpreter, or virtual machine, or any other intermediate process between the program code and the CPU, there will be overhead.
This is kind of an old-fashioned argument. Modern VMs are often essentially executing native code by the time the code is actually running. If the bulk of the overhead happens at launch time, or a JIT compiler only has to step in every so often, the level of performance can be such that the difference from "pure" native code is insignificant for most applications. Don't mistake a modern VM for a 1980s style Basic interpreter. The two are very different beasts.
I think ASM.JS is dead out of the water as Google refuses to support it.
No, that's not true. You maybe have things backwards. Mozilla refuses to support NaCl, which is Google's similar-goal-different-approach technology.
I don't like Emscripten. A language divorced of the prototype hogwash and weird 'this' scoping of JS which causes (OOP headaches) would be nicer.
You mean like C++? Because that's what you compile with Emscripten.
Why do you think that single process has anything to do with this ? The Mozilla developers clearly want to do this, it just is a massive effort to change their code to suite the model.
Really? You're saying the Mozilla developers "clearly" want to switch to Pepper/PPAPI? Because I don't think that's very clear at all.
As for NaCl, Mozilla has been pretty adamant that it's not interested.
Is not that it is slow (although it is..) it's that it sucks. It doesn't allow good coding practices, let alone enforce them.
You've been modded flamebait, but there is some truth in what you say. I'd argue, however, that it's not that JavaScript doesn't allow good coding practices -- it does -- but that it does nothing to encourage them, and even discourages them in some cases.
You can write good JavaScript code if you know how and use some discipline. In his book JavaScript: The Good Parts, Douglas Crockford encourages developers to use only a subset of JavaScript's features. The subset he recommends isn't as strict as Asm.js, but he isn't afraid to admit that some features of JavaScript are just poorly designed and shouldn't be there -- so if you want to write good JavaScript code, you should ignore them.
I recommend the book. It's a quick read. It doesn't aim to be a tutorial or a comprehensive bible of correct JavaScript practice. At the very least, though, anybody who works with JavaScript will probably come away from it having seen a new perspective on how the language works and how one should approach it.
Asm.js isn't Javascript. It's a statically typed language that looks like a subset of Javascript. There isn't even DOM support.
This isn't really accurate. As you say yourself in a post below, any Asm.js code you can find will execute in ANY JavaScript virtual machine available today. Thus, Asm.js is JavaScript. It's just JavaScript restricted to a very strict, very specific set of rules, with everything else thrown out. It doesn't "look like" a subset of JavaScript; it is a subset of JavaScript.
He didn't say C++.
But the final sentence of the article isn't targeted at people doing heavy lifting. Is an "attack" at Google's Native Client (NaCl). I peeked at NaCl, and you needed a some set up and some APIs to run some native code invoked from the browser. ASM.js is way simpler, since is just a subset of JavaScript, and has much more possibilities of being followed by vendors like Opera or even Microsoft.
Yes, but even if you're using Asm.js, you should maybe still think about NaCl as an interesting potential option.
One reason is that you typically don't write Asm.js code by hand. You could, but you'd probably be bad at it (kind of like assembly language -- compilers just know it better than you do). What you typically do is write your code in C/C++, then "compile" it into Asm.js using a tool like Emscripten.
Thus, if you're writing your code in C/C++ anyway, it wouldn't be such a stretch to take that same code and also compile it into a native binary module for those clients that support NaCl (which so far means only Chrome, and it looks like it's going to stay that way).
In other words, you don't need to look at it as an either/or choice. It's perfectly feasible to use both tools, possibly without much additional development overhead.
The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.
