jmesserly · HackerTrans

This is addressed in the article:

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

jmesserly

11 anni fadiscuss

Well in 2014 they did finally repeal the rule that prevented the network hardware from being installed: http://www.geekwire.com/2014/seattle-approves-bill-allows-fi...

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.

jmesserly

11 anni fadiscuss

I'm not an economist either, but applying textbook theory from school, it could help. A lot depends on the size, and making sure it isn't too big to discourage employment. http://en.wikipedia.org/wiki/Basic_income would be a demand side stimulus, with money going to the folks most likely to spend by taxing the folks most likely to save (you wouldn't want to do it by "printing money"). That particular effect would point in the direction of increased GDP (assuming we start from a deflationary trap with inadequate demand and large private debt overhang). However the risk would be too much employment lost, which points in the direction of decreased GDP.

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

jmesserly

11 anni fadiscuss

> This is just a big lie thrown in my face!

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

jmesserly

12 anni fadiscuss

They're planning to use AtScript to transpile to ES6 and Dart by extending the ES6 transpiler called Traceur (source: https://docs.google.com/a/google.com/document/d/11YUzC-1d0V1...). The basic issue for Angular is they'd like to support users of ES5, ES6, and Dart with the same code base. That's currently a bit hard to do with a Dart code base (although a lot of us want to see that get better!)

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

jmesserly

12 anni fadiscuss

Aha! Good call on the ByRef. Totally had forgot about that. Yeah, that was very important for correctness.

jmesserly

12 anni fadiscuss

Hah. Or Tomas. Not sure. The S.L.E.Interpreter is after my time :)

jmesserly

12 anni fadiscuss

Funny, I had something to do with this code back in the day! I'm guessing it was a copy+paste bug and they copied from the LambdaCompiler, which uses StrongBox<T> for its closed-over parameters[1], since StrongBox<T>.Value is a field. The idea was to have the closures be really fast.

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

jmesserly

12 anni fadiscuss

Regarding performance: it will get much better once browser have implemented http://www.w3.org/TR/2014/WD-shadow-dom-20140617/. Shadow DOM is not easy to polyfill (especially because of some issues in how the browser's C++ objects were presented to JavaScript as prototypes.)

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.

jmesserly

12 anni fadiscuss

Wow, seriously? I've been using Beta and not noticed any breakage (but that doesn't mean there isn't any). Do you have any more context?

jmesserly

12 anni fadiscuss

disclaimer: I'm a huge fan of TypeScript and the folks working on it, but now work on Dart and JS stuff at Google, so I'm probably biased in all kinds of ways :)

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

TL;DR -- TypeScript is a targeted fix, Dart tries to fix all-the-things. Both approaches have merit.

jmesserly

12 anni fadiscuss

fyi, I think most of my original complaints in that bug are either fixed, or largely mitigated. I don't think we've had any issues for over a year now (since Dart 1.0). I still wish it was even more bulletproof, but it isn't scary anymore like it was. Google is building lots of stuff in Dart too, so we're on the hook if something breaks.

jmesserly

12 anni fadiscuss

That should work as of this week with Polymer's paper-elements: http://www.polymer-project.org/docs/elements/material.html, available for Dart at https://github.com/dart-lang/paper-elements.

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

jmesserly

12 anni fadiscuss

> How well does Dart interact with JavaScript, especially libraries that are asynchronously loaded? I know that the Dart compiler is a whole-program optimizer, and I get the impression that Dart wants to own all the code on the page.

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

comments