I think the ones that missed the point were the developers and reporters. The whole point of an AI helper is that it behaves as if it were alive, and there is absolutely no way you can accomplish that in 8 hours of work. It's the details that matter for the life-like experience, not the general idea.
States already make vaccination mandatory, including some during pregnancy. It's not that crazy to imagine a "vaccine" for Alzheimer's.
News flash: it won't and it will only get better.
Remember that most users are not technologically literate.
That used to be true. People are getting more and more tech savvy and everyone in the tech industry is aware of it.
It will probably be patentable, and even the algorithm could be patented, but that would hardly be a useful patent. See what the creators of Graphene said about it
We considered patenting; we prepared a patent and it was nearly filed. Then I had an interaction with a big, multinational electronics company. I approached a guy at a conference and said, "We've got this patent coming up, would you be interested in sponsoring it over the years?" It's quite expensive to keep a patent alive for 20 years. The guy told me, "We are looking at graphene, and it might have a future in the long term. If after ten years we find it's really as good as it promises, we will put a hundred patent lawyers on it to write a hundred patents a day, and you will spend the rest of your life, and the gross domestic product of your little island, suing us." That's a direct quote.
Some performance tips make sense. CSS transforms basically paint an image into GPU memory, so this makes a lot of sense:
Keep layers small
– Don’t inadvertently create gigantic layers
– Memory consumption = width x height x 4 (bit depth)
However, other tips don't make as much sense:
Use closures sparingly & only where necessary
Closures are in the heart of JavaScript. You can't avoid them even if you want to. Instead, learn to write destruction lifecycles for your objects in which you expressively remove references that may cause leaks.
Maybe they need to come up with some kind of "use sanity" mode to build on the existing "use strict",
That's the idea. You'll be able to set "application/ecmascript-6" or something similar to the type attribute of the script tag.
I think in the context of a discussion related to a (not even published) new language that aims to fix front-end development, the future of JavaScript is more relevant than its present.
Global-by-default-unless-declared for variables is a recipe of disaster.
ES5 strict mode already disallows that.
If I declare a "var" inside a pair of curly braces, it should only be visible in those curly braces
The "let" keyword will fix that. It has block scope. Eventually all variables should be declared with "let".
Syntax for lambdas is overly verbose
There is still no agreement in the ECMAScript comitee about which option to take, but there are two very good proposals:
- Arrow function syntax taken from CoffeeScript: (x) -> x * x;
- Block lambdas, which allow you to treat chunks of code as data
Personally, I love arrow functions.
"new Boolean(false)" is considered true in a conditional expression..
I never heard of that particular example and trying "true == new Boolean(false)" always evaluates to false in a console. But yes, the == type coercing operand is the worst part of JavaScript. The === operator solves 99% of cases. For the 1% that it doesn't help with, ECMAScript 6 will have an "is" operator, and before that probably an Object.is() function.
While we're at it, what's up with the whole separation into primitives and objects?
I agree with you, everything should've been an object from the start. That's probably because of the Java legacy.
Maybe the question should be how to promote policies that prevent software engineers from going to the evil dictator side.
I can't believe I found out first on Slashdot.
I'd like to thank my very smart representatives, courts, lawyers and public prosecutors who made this happen. Apparently Google will be investing in solving the situation, otherwise those of us technologically not challenged will be doing what we can.
The functionality is awesome. But the API is too Java-like. Someone make it more JavaScript friendly please!
This week the online community managed to get the attention of the lawmakers in Argentina and paused the approval of a law that would instate a private copy levy on MP3 players, CDs, DVDs and even hard drives. This law would be similar to the ones already in place in Europe and that are being contested by the Court of Justice of the European Union.
Those of us who got informed in time were able to watch the session of the Congress during which the proposed law was presented and different groups that represent copyright holders (record labels, filmmaking producers, etc) expressed their views about it. Many representatives of these groups were over 70 years old. By repeating phrases such as "artists have a right to make a living" they were continuously showing that they have no grasp of the current market. It was clear that most of them were there to be shown in camera and to be certain that their groups got included as recipients for the levy. There were no dissident voices, not one member of Congress or representative of technology groups that expressed arguments against the approval of the law. In fact, the only congressmen present were "ready to approve the law tomorrow" as one said.
Lobbying at its finest.
Right, so they put a language designer (a theorist), a developers relations manager (a PR guy) and an infrastructure engineer (someone who talks wires and servers) to talk about front-end development. How about calling actual front-end engineers to talk about their craft? How about asking the guys behind the Aves game engine what can be done realistically with HTML5?
Personally, I'd rather use a slow dynamic scripting language to glue the fast compiled language code together, (see: Perl), not write the whole damn server in slow JS.
That is the whole idea. Write processor intensive tasks in a fast compiled language (C or whatever) and glue them with a server that is good at handling asynchronous requests. That's what Node.js is about and JavaScript is actually a good fit for it because of closures.
Never test for an error condition you don't know how to handle. -- Steinbach
