The patent appears to be about selecting a network carrier using a bidding process. The device can choose a network based on price and quality of service. What prior art is there for this?
258 karma · joined September 9, 2011
i.e. From docs: "Creates a new stream from this stream that converts each element into zero or more events."
Stream.takeWhile(f) is takeUntil with the return value of the f argument negated.
But sure, you can always add more features to a core library, the difficult decision is when to stop, and leave the rest to libraries.
https://api.dartlang.org/apidocs/channels/be/dartdoc-viewer/...
https://api.dartlang.org/apidocs/channels/be/dartdoc-viewer/...
Javascript has a number of issues that make static analysis hard. It also has implicit conversions and other oddities which mean that code often keeps on trucking after a programmer error, rather than failing where the initial problem was.
These problems were solved in other languages decades ago - which is why many developers "hate" switching to Javascript. It's coding on a tight-rope without a safety net.
The meme: "You're just a hater, because you don't know how to use it", is a joke. Javascript has issues, hopefully they can be fixed, but fixing them without breaking compatibility is difficult. Being honest about Javascript's flaws doesn't make you a "hater".
For the record my first JS project was Netscape 2 compatible. So I'm pretty sure I know how to use it.
class Node { ... }
class FancyNode extends Node { ... }
function createNode() : Node => new FancyNode();
function doStuff(Node n) { ... }
doStuff(createNode()); // Static error - developer scratches his head - how do I fix this
doStuff(<FancyNode>createNode()); // There I fixed it. But at what cost to productivity.
Or perhaps (Not sure how Any<T> works - just guessing):
function doStuff2(Any<Node> n) { ... } // Developer - hey what's this Any<T> thing? More head scratching.
Is the extra complexity worth it, what benefits does it bring, and what are the productivity costs? Will soundness actually help runtime performance (Not proven). Will it make security harder? i.e. performance optimisations that rely on the sound type system mean that type spoofing can lead to vulnerabilities.
I keep on rambling - sorry - I find this stuff fascinating. Fun job you've got ;)
"Dart and any real-world usage data from it are nowhere, while StrongScript is "on" and should generate V8-based data this year."
I'm watching with interest to see how Soundscript turns out. In the meantime, Dart and its tooling has helped me be productive. And I hope you and your colleagues at TC39 are able to bring the same feeling of productivity to ES.
I'm not hugely excited about the casts required in Typescript (and I assume Soundscript) when interacting with the DOM. For example as a developer I don't find it helpful that the following is a static warning:
var input : HtmlInputElement = document.querySelector('input');
A cast fixes the warning, but is pretty verbose and ugly:
var input : HtmlInputElement = <HtmlInputElement> document.querySelector('input');
I believe this was one of the motivations behind the implicit downcasts in Dart. But I will give Soundscript a shot, and see if a sound type system helps me catch more bugs and be productive.
I also wonder how much complexity variance will bring to generics in Soundscript. I believe they are invariant in the initial doc that I saw.
Thanks for taking the time to share your views - I do honestly appreciate it. And I am very grateful that you got first class functions into JS1 - so that we've all had an ok language since the start. Definitely not accusing you of being a slacker.
> I'm still right that this took too long by 5 years at least
I think you overstate your case. But I've used enough of your valuable time already.
It also sounds like you're now happy with the outcome, the Aarhus leadership sidelined, and new people on V8 with views more similar to your own. Go for it - get optional types shipped!
JS cannot be replaced in the short term. However you can implement a VM (or mode) which supports only a subset of JS with some of the legacy cruft removed. Strongscript is a step in this direction. (Side note - deprecate a few more features and you can start reusing some of the optimisations in the Dart VM.)
It is also possible to treat JS source as an AST serialization format an to display code differently when viewed by the developer. When language semantics are close to 1:1 this can work seamlessly (unlike of the big unintelligible balls of source required to work around ES5 semantic gaps).
And who knows, give it 10 years, and perhaps TC39 members will agree on a new language syntax that fits the existing "use strong" semantics. Note there is no need for expensive new VMs in this scenario, it is just a new parser generating AST nodes in the existing VM. This seems pretty obvious, I mean it's a bit of cruel joke to make developers use === for the next few decades. Surely this can be fixed some day.
Forgive my naivety about TC39 and standards, but I would have thought when standardising a new language feature that it makes sense to review similar features in other languages, and to perhaps reach out to implementers, for a presentation, or at least some email discussion. Seems prudent to learn from other's mistakes.
Btw. It is trivial to statically analyse Dart code, and even ignoring type annotations, decide whether a number literal is an integer or a double. And yes such automatic translation wouldn't be possible until changes like strongscript and bignums have landed in ES. But perhaps I misunderstand your point.
"any real-world usage data from it are nowhere"
Ignoring available data from existing optionally typed VMs during the standardisation process doesn't seem like a smart idea.
Anyway, I hope there is good discussion at TC39 about Nominal typing with implicit interfaces, vs Structural typing. I'm not really a fan of structural typing - I think the Dart team made the right call here.
> Alan Kay was right, the best way to predict is to invent.
You mean to invent something compatible with legacy technology and easily adopted ;)
Bignums - ok - you claim that bignums could have made it into ES6 if google had provided more support. I'll take your word for it, but you can probably understand my scepticism.
I'm not religious about language either. I don't care much about syntax. What I really care about is being productive.
IMHO the main things that help my productivity are:
* optional types
* completion
* doc popups
* development-time runtime type checking
* good debugger
* Few implicit conversions
* Consistent core library
Now you argue that google would have been better off building these language features and tooling on top of ECMAScript instead of creating the Dart stack. What would this alternative scenario actually look like - especially from the point of view of a developer?
* It could be a mode in V8, or a fork of V8 (I'll call it "V8FutureMode"). V8FutureMode would be incompatible with other vendors JS VMs. Just as Dart is.
* Each time ES standardises a new feature already in implemented in V8FutureMode, then all your existing code would need to be updated to match the ES spec. This regular churn is painful for developers.
Now let's consider another scenario where google develops Dart, and ES20 arrives in 2020 with optional typing.
* 2013-2020. Stable language no breaking changes.
* In 2020 I can port my code over to ES20 (trivial as near 1:1 semantics, 99% automated).
This scenario is better for me as a developer. It also insulates me from the risk that optional types don't make it into ES until 2030. I also think it gives a lot of real world usage data helpful for getting optional types into ES. (You seem to disagree here.)
From the Dart team's perspective the Dart scenario is better too:
* Can build a core library and tools on a stable language, rather than having to regularly deal with breaking changes.
* Able to experiment with VM optimisations which are difficult to do in JS due to legacy compat.
* Personal motivation - this is what the developers really want to work on. (Being told by your boss to drop your experimental project, and continue doing the same old thing isn't always a good management approach)
I'm optimistic that over time experiments such as "use strong" will mean that the same optimisations implemented in the Dart VM will be able to be used in other JS VM's. Perhaps if a developer guarantees that all JS code is "use strong ES20", then it would be possible for a browser to even use a different VM behind the scenes (in Chrome perhaps even using the original Dart VM codebase, but with the language front-end changed to compatible with ES20).
The future is uncertain and difficult to predict. There are multiple ways to evolve JS - you seem quite certain that incrementally fixing JS is the only approach. I think building a new programming stack, and simultaneously evolving JS in that direction with insights learnt from the new stack, is also a valid approach. I don't understand why you have been so hostile towards this.
In JS the overflow is often silent and is easy to miss. Since the DartVM can throw an exception on overflow this makes it easier to catch. So the Dart toolchain is an improvement, but also not ideal.
Where correctness is important there are also 32/64bit and bignum libraries which can be compiled to js but are slow.
Edit: Mythz used exactly the same phrase. Jinx.
Ok, let's say JS continues to evolve over the next 5-10 years, and by this time all browsers support integers, optional types, operator overloading, less implicit conversion, and mixins. By this point compiling Dart to JS is trivial, and the cross compiled code is also completely readible. So I can take my existing Dart project and compile it to ES11, clean up a few things by hand, and then continue developing in ES11. In the meantime I've had 5-10 years being very productive developing in Dart with good tool support. This seems like a win to me.
Having a VM is also incredibly beneficial for development and debugging. These points alone justify investment in Dart.
But there are more benefits. Providing a testing ground for VM engineers to try out new features without legacy compatibility constraints. They haven't really got started on performance yet, and they're already solidly ahead of V8. This can provide insights for TC39, to see what kind of performance/memory improvements are possible if changes are made to the language.
> Bignums
I'm aware of the bignums strawman, and I'm aware the page on the wiki dates to 2010. But I repeat: even if the V8 team had implemented bignums behind a flag in 2010, do you really think that the other vendors (including MS and Apple) would have also implemented them already? I find this scenario unlikely. (But kudos to MS/A for implementing the new ES6 features. I'm glad to see JS evolving)
> [Snapshotting] could be added to JS if it could be done for Dart.
My understanding was that the V8 team actually implemented snapshotting and initially used it for loading their JS core library. They didn't think it was possible to use it for loading cached web code. Not because of the globals object, but because javascript code must be executed to build up classes, i.e. setting prototypes etc. Because execution and structure is interleaved, top level code and initialisors could perform side effects before the static program structure exists.
> there hasn't been much uplift over five years.
It looks like Dart is a longer term bet. It will be interesting to see what kind of an influence it has over the next decade or so. Especially given the recent talk around adding optional typing to JS. The Dart team are also currently experimenting with co-operative threading, growable stacks and concurrency primitives. https://github.com/dart-lang/fletch/wiki/Coroutines-and-Thre...
> My point about opportunity costs stands. We could have come a lot farther, faster.
I'm not convinced. I don't see how the development resourcing on the V8 development team could have sped up the ES6 standards process. The ES6 process includes getting consesus with Apple/Microsoft - this process isn't time constrained by V8 development resources.
Consider the opportunity cost if they chose not to develop Dart. Developers have to wait a lot longer to get modern tooling, with: completions, doc hovers, code navigation and static analysis. These really make a huge difference to developer productivity. All of the experience gained here can feed back into javascript tooling (assuming optional typing makes it into ES).
Also consider the individual developer's motivations. It's great that you are excited about working on JS and spidermonkey year after year. But what were the motivations of the developers at google? If the developers are passionate about the web like yourself, then they can continue to work with the V8 team. But if what excites them, is working on a state of the art dynamically typed VM, well then removing some of the legacy JS constraints allows them freedom to innovate. If their only choice had been to work on V8, they could well leave the company and work on another VM project somewhere else. So what would the cost have been if google management said no you can't do Dart?
> You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling" ... What's with the goalpost moving ... ?
The shifted goal post was: "Dart ain't gonna replace JS in the foreseeable future". I never claimed that Dart will, or needs to, replace javascript.
It's great that Apple and MS are on board with ES6. But even if the V8 team had implemented bignums behind a flag in 2010, do you really think that the other vendors would have also implemented it already? I find this scenario unlikely - but you obviously have a better view of this than I do.
> Snapshotting would be relatively easy to do with ES6's module system. People would have to refrain from abusing the global object, or snapshotting might fail.
I guess you'd need to add some extra restrictions, such as no top level code outside of functions including variable initialisers, and no modification of prototype chains. This seems hard to do with JS as it is written today. Perhaps the "use strong" experiment will make this easier.
> ES6 modules plus the asm.js work to avoid loading too much cold code is likely to bear more fruit than a new VM's bespoke snapshotting tech
This is your intuition and opinion. Some people disagree, and have chosen to put their effort into another approach. Maybe you're right. Maybe they're right. Personally I think it's better to try both approaches, and let benchmarks settle this. From the benchmarks I've seen, snapshots look very promising.
> Dart ain't gonna replace JS in the foreseeable future
Flamebait! It doesn't need to. It just needs to provide good development tooling for some developers who prefer using it than vanilla javascript.
In my view having the Dart team trial new features in a new codebase without the legacy constraints allows them to move quickly, and get feedback about new features by shipping real code in real products. The results of this process can give good input back to the ECMAScript process. Perhaps this has already happened, I guess good examples would be SIMD, and the scoping rules around for of loops.
One of the most important improvements I see in Dart, is the focus on reducing start up time. i.e. snapshots and lazy evaluation of top level variable initialisers. They are currently claiming a 10x start up time when snapshots are used. This would be a huge benefit for mobile apps.
Is there any one investigating how you chould change or subset Javascript to allow for snapshotting? Snapshotting seems really beneficial for the web, especially for the mobile web vs native. Currently I only see the Dart team working on this.
The dart2js numerics divergence isn't a problem in practice, as during testing/development the Dart VM is run with a flag which throws if an integer escapes the 2^53 safe range. And if an integer is overflowing to a double in production code then this is a bug anyway.
It would be nice if Javascript VM's could also provide a similar feature, at least until bignums land. But I guess this is difficult as there is no way to distinguish which numbers are intended to be integers and which are actually doubles.
var s : String = "bar";
var a : any = s;
var i : int = a;
class A { foo() { print('A'); } }
class B { foo() { print('B'); } }
var a : A = new A();
var b : B = a;Options _Map_. There I fixed it.
Google is capable on working on improving JS and Dart simultaneously. You can see Dart as a test ground for features that may make it to JS. Cross-browser improvements made to JS will also benefit the Dart ecosystem, as it is a compile to JS platform.
Don't expect Dart to disappear any time soon. Despite popular rhetoric, Google actually has a good history of supporting its web programming platforms, for example GWT and Closure.
Async/await is just sugar, it doesn't actually change APIs at all. Note C# also added async/await long after their first release.
var length = rtts.type(name.length, rtts.int);
https://docs.google.com/document/d/11YUzC-1d0V1-Q3V0fQ7KSit9...
var price = document.querySelector('input#price').value; // "10"
var tax = document.querySelector('input#tax').value; // "1"
var total = foo(price, tax); // "101"
I find this type of fast feedback improves programmer productivity. It means that you get warned straight away, and don't have to do a trip through the debugger to find the problem.
Just because the compiler can infer that a specific type could be passed to a function, that does not mean that the developer intended that function to be used with that type.
What should an IDE tell the user about the types of a and b in the completion popup?
function foo(a, b) { return a + b; }
Good point. I imagine it would be possible to transfer ownership of a SharedArrayBuffer to the main thread from a worker, just as it is done today with zero-copy transferable ArrayBuffers.
References to the SharedArrayBuffer in all workers would be made unusable. When the code on the main thread is done it can transfer ownership of the SharedArrayBuffer back to the workers.
https://github.com/domokit/mojo/tree/master/sky https://github.com/domokit/mojo/tree/master/sky/specs
Dart also has async/await, and synchronous generators using yield.
Nit - actually the JSON standard doesn't specify a precision for the number type, but most JSON implementations don't support arbitrary precision numbers.
Though the more recent RFC does have some implementation notes for interoperability.
http://rfc7159.net/rfc7159#rfc.section.6
> "This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available."
> "Note that when such software is used, numbers that are integers and are in the range [-(253)+1, (253)-1] are interoperable in the sense that implementations will agree exactly on their numeric values."
import 'dart:convert';
main() {
print(JSON.decode('{ "mybigint" : -123434580239458203948203982345723458 }')['mybigint']);
}
i.e. it doesn't matter if you take CO2 out of the surface ocean or the atmosphere. Both will reduce the concentration of CO2 in the atmosphere.
The problem with fossil fuels is that they transfer old carbon which used to be stored underground into the atmosphere.
This process only uses carbon that is already part of the active carbon cycle, so it is carbon neutral as long as the electricity source is.