185 karma · joined May 4, 2011
> The good news is electricity is getting cleaner. Since 2013, the world has been adding more electricity-generating capacity from wind and solar than from coal, natural gas, and oil combined.
with a link to: http://www.bloomberg.com/news/articles/2015-04-14/fossil-fue...
Then they fixed the TV franchise issues: http://www.geekwire.com/2015/seattle-city-council-approves-l...
As a result of the first CenturyLink started rolling out (expensive) fiber, and after the second CL started offering Prism TV. So I think most of the blocking issues have been fixed now. Remains to be seen if/when Google Fiber will reconsider Seattle.
A safer way to do the same thing would be to just spend government money on things like building infrastructure. In current conditions, that translates into increased GDP without the reduced employment risk. Similarly reduced taxes on lower incomes would be less risky but work through the same means.
(This isn't addressing whether basic income would be morally good or bad. Just the macro effects.)
> please correct me if I'm wrong!!!
You're wrong. Deflation is basic economics. If you take a college macroeconomics course it will be covered.
It's hard to summarize in a way that will convince you in an internet debate. Sort of like trying to argue electromagnetism with someone that never learned about Maxwell's equations. An econ textbook would be ideal, but another place to start would be: http://en.wikipedia.org/wiki/Deflation
(By the way, no offense intended with that. It's hard for anyone to comment on a scientific subject if they didn't learn the background, even super smart folks.)
There are several things wrong with your story, but the first one that jumps out is that some prices are more sticky than others. For example, wages are likely to not go down much, instead firms tend to cut employment. There's a lot of evidence for this: http://en.wikipedia.org/wiki/Nominal_rigidity. Another big factor is the effect of debts, which are not reduced: http://en.wikipedia.org/wiki/Debt_deflation
Here's another summary on deflation, intended for a popular audience: http://krugman.blogs.nytimes.com/2010/08/02/why-is-deflation...
disclaimer: I've worked on the Dart team and on the Traceur compiler in the past too. So I'm definitely not unbiased on these topics :)
The history of ET compiler: it started with LINQ in .NET 3.5. Originally it was pretty simple and just handled expressions. In .NET 4.0 we merged the entire codebase with the IronPython/IronRuby compiler trees, expanding the "expression trees" to handle statements. IIRC, it can generate almost any IL construct that you might need, and is usually a lot easier to work with. But we found .NET's runtime compiler (DynamicMethod) was a bit too slow for a lot of use cases. It also wasn't supported on some CLR configurations. To address this we wrote an interpreter and some heuristics to switch from interpreted to compiled. But the actual System.Linq.Expressions.Interpreter must have happened after 4.0, because I don't remember that at all. Instead we just shipped it as a shared library used by IronPython and IronRuby.
Here's the normal ExpressionQuoter: https://github.com/IronLanguages/main/blob/7be8b73e246bfb029...
And here was the interpreter. I don't see the ExpressionQuoter, so either that's a newer fork of the code that was rolled into System.Core, or maybe a completely new implementation. https://github.com/IronLanguages/main/tree/master/Runtime/Mi...
IIRC, ExpressionQuoter was mainly to support the Quote expression, and was always a bit buggy. The 3.5 version was seriously messed up, and our prerelease versions of .NET 4.0 also had various bugs, and very few tests. I tried to fix it by having it use the same reuse closure mechanism as the normal compiler. Funny that same feature caused issues later on.
[1] one might wonder: why use StrongBox<T>, essentially boxing every parameter, rather than just generating a type with only the right fields? The reason was that generating a type in .NET 4.0 timeframe was absurdly slow. Like, a few hundred per second slow. I think this has been largely fixed now, but it was a huge performance problem for Iron* language runtimes back in the day
Regarding IE failures -- do you have any more information? All of the elements should be cross platform. It would be great to file these issues at https://github.com/Polymer, if you haven't already.
The way I like to think of it:
If the main thing you want in JavaScript is types and classes, TypeScript is brilliant. It adds exactly those things, and does so in a very attractive and seamless way. Classes are already in EcmaScript 6, and I wouldn't be surprised if TypeScript annotations make it into a future version ES (there's a strawman proposal: http://wiki.ecmascript.org/doku.php?id=strawman:types), so the forward compatibility story is good too.
If you want to fix more things in JS, such as:
* massively improve all core libraries and types
* improve the DOM
* add integers
* add operator overloading including [] []=
* make Map a distinct type, instead of all objects being maps
* switch from prototypes to classes
* removed undefined
* fix == operator
* remove implicit conversions
* tree shaking: no worries about which library is less KB's
* add named arguments
* add many features ES could add but at a faster velocity
* consistent libraries (e.g. Dart standardized on Futures)
* ... probably more stuff I'm forgetting ...
You could either build it as a mobile web app, or if you need more of Android's APIs there's https://cordova.apache.org/.
Great question. Generally dart:js will let you do interop: https://www.dartlang.org/articles/js-dart-interop/. It's designed to interact pretty well with the dart2js compiler. However it feels a lot like you're using a foreign function interface. For example, calling a the global method Object.keys is: js.context['Object'].callMethod('keys', [obj]);
For Custom Elements (one of the new web components specs) we did something better: you can register the Dart wrapper type associated with that element. Then whenever you get one of those elements, it automatically looks like the Dart type. We used this heavily in the new core_elements and paper_elements packages. Here's an example of defining a type like that: https://github.com/dart-lang/core-elements/blob/master/lib/c...
Ultimately we'd like to make something similar for all JavaScript objects and expose it from dart:js. That would make interop almost seamless (especially if we could generate the types from DefinitelyTyped's APIs).
"In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). This can protect against recent incidents where a CA has its authority abused, and generally protects against the proliferation of signing authority."
(disclaimer: I work for Chrome but not on these features.)
I see this meme a lot, but I don't get it how the analogy is supposed to work.
There is actual evidence that Microsoft in the 90's was trying to sabotage standard protocols and open source software, e.g. http://en.wikipedia.org/wiki/Halloween_Documents.
The key part of "embrace, extend, and extinguish" strategy was extending the standard in proprietary ways, thus making it incompatible and no longer implementable via open source software, thus killing it.
I don't get how any of this applies to any web company, where nearly the entire business is based on the web and the standards that back it. It's no wonder that many of these companies contribute back to the web standards and open source software. Sure, these contributions are in the company's interests--but that's the whole point. We reached a time when it's in interests of many big (and small) corporations to contribute to open source and standards (including Microsoft!).
Some people see efforts to improve standards or contribute new ones as somehow bad, "embrace and extend". When actually it's the opposite: investing in the commons to promote its welfare.
Obligatory disclaimer: speaking for myself here, not any employer past or present.
I don't have a problem with X selection+paste if I'm just using Linux. But using it when connected to a remote machine via various remoting technologies (NX, Chrome Remote Desktop), and then mix in that the host machine is a Mac with its terrible command/control split, and the result is pretty confusing.
disclaimer: I'm on the Dart team (libraries, not core language/VM/dart2js). As exciting as it would be to have Dart VM in Chrome, personally I hope the order is more like:
* dart2js and VM work the same way (basically true already, modulo a few quirks unlikely to affect program behavior. It's not any worse than your typical web standard polyfill, probably a lot better.)
* The language spec is standardized.
* People like Dart, and it becomes really popular for building web apps.
* We have great Dart<->JS interop and it's possible to make the two native VMs work nicely together in the same browser.
* The toolchain makes it practically impossible for a web developer to publish an app that only has .dart files, without the .js version that works on all browsers.
* At that point, it might make sense to add the Dart VM to a browser purely a performance optimization.
Of course a lot could change between now and then. For example, if JS engines keep getting faster and introduce enough fast stuff (like typed arrays, asm.js, etc), maybe we can achieve the speed we need with dart2js.
Fortunately, there are plenty of folks that work on Blink/Chromium that share both the enthusiasm and skepticism that the web community has about Dart. As someone that works on it, I deeply want our team to succeed, but I would like to see it happen in the right way--open web and open source friendly.
As much as I was sad to see it go, I sympathize with their problem. If you just have a single C/C++ implementation with no spec, it's a lot harder to know, as a user/web developer, what the correct behavior is and what you can rely on.
Additionally: we have had experimental Dart+Chromium builds for a long time, they use a different approach (V8 bindings layer) that doesn't require WebKit changes. However we only use these builds for fast development edit+refresh, for deploying Dart code you should use dart2js (it's just like deploying CoffeeScript, C code via emscripten, etc).
Right, that's the point. This is a common style in economic blogs. They often follow the form: assuming some set of data, what are the economic implications?
> He does describe interesting models/theories, but I don't actually think they're relevant.
Right, they may or may not be relevant to this specific case (Reader), but I still found it interesting to learn about.
> It seems cheap and link-baity.
Hmmm, here we have a distinguished economist, who could no doubt live easily from his university job, instead spends time trying to bring scientific economic analysis to popular topics. Not sure how that is cheap and link-baity.
He does have a knack for catchy titles, though. If you aren't familiar with his blog style, "evil google" probably sounds bad (and emotionally charged), but I really doubt it was meant to be taken literally.
Disclaimer #1: lack of mutable types/scopes might change in the future with mirror builders. Presumably mirror builders will be structured in such a way that they cause minimal effect on optimizations.
Disclaimer #2: I don't work on the VM so take this FWIW.
It's an attempt to standardize widgets at the browser level. Really cool stuff.
It's based on ShadowDOM, which is an encapsulation notion: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shado...
There are a few polyfills for playing with web components, such as Mozilla's http://x-tags.org/ and http://html5engineers.com/projects/playing-with-web-componen...
Also some of the frameworks do have a "widget" or "component" notion. For example, see "Create Components" at http://angularjs.org.
http://www.chromium.org/nativeclient/pnacl/building-and-test...
Source: http://src.chromium.org/viewvc/native_client/trunk/src/nativ...
That wasn't hard to find.
Article is right in one way: software is very different from physical goods. The marginal cost of each additional unit of software is 0. And there's evidence (such as appears frequently on HN) that a bigger firms do not necessarily produce software more efficiently. I've always suspected the software industry is more dominated by network effects[3], which has a similar effect on the market as returns to scale: a small number of firms & high likelihood of natural monopolies.
[1] http://en.wikipedia.org/wiki/Economies_of_scale
Now, it's true that as a percent of GDP, China is the largest manufacturer. But per capita it is either Japan or Germany (depending on which charts I was looking at), with US not far behind.
(Unfortunately as the world's largest national economy, a beggar-thy-neighbor export policy doesn't work so well for us.)