if name == "world" {
print("hello, world")
} else {
print("I'm sorry \(name), but I don't recognize you")
}
for index in 1...5 {
print("\(index) times 5 is \(index * 5)")
}
switch someCharacter {
case "a", "e", "i", "o", "u":
print("\(someCharacter) is a vowel")
case "b", "c", "d", "f", "g", "h", "j", "k", "l", "m",
"n", "p", "q", "r", "s", "t", "v", "w", "x", "y", "z":
print("\(someCharacter) is a consonant")
default:
print("\(someCharacter) is not a vowel or a consonant")
}
let someResolution = Resolution()
let vga = Resolution(width: 640, height: 480)
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
And Dart drowns in a see of uncertainty, with no public commitment being shown at all.
Also, Swift designers were a lot bolder, and yet, Swift is still familiar.
From top Google strategists to Dart's language designers, maybe some could use a pair of balls.
Putting Dart into Chrome would over time have made Dart very popular, but that isn't going to happen. The idea of having a good, free, IDE (Dart Editor, Chrome Dev Editor) was great. Maybe we could enhance Dartpad to the point where it could be useful for basic programs (proper imports, project file structure, launch in browser) so there is a better path for those wanting to explore or learn Dart. Providing an easy way to use Dart on Google App Engine would be great too, but we're not there (yet?).
I'd still love to see a native json serialization mechanism that's as simple and easy to use as JSON.parse and JSON.stringify are for JavaScript. I understand that since type annotations are for documentation only, this is currently hard to accomplish without a lot of extra information at runtime (code bloat). I'm hopeful that Dart 2.0 or the new JS interior library can resolve this somehow. I personally believe that this is one of the few areas where JavaScript still has Dart beat.
Although this 'sugar' is not critical, at least it is something positive that improves the developer experience.
Putting Dart into Chrome would over time have made Dart very popular, but that isn't going to happen. The idea of having a good, free, IDE (Dart Editor, Chrome Dev Editor) was great. Maybe we could enhance Dartpad to the point where it could be useful for basic programs (proper imports, project file structure, launch in browser) so there is a better path for those wanting to explore or learn Dart. Providing an easy way to use Dart on Google App Engine would be great too, but we're not there (yet?).
But the results are much different when lim and i change.
lim = 999 and i = 10:
Dart2js hashmap: +/- 3800 milliseconds
Javascript object: +/- 640 milliseconds
lim = 99 and i = 100:
Dart2js hashmap: +/- 120 milliseconds
Javascript object: +/- 210 milliseconds
Am Montag, 19. Oktober 2015 20:13:02 UTC+2 schrieb Gen:I made a small test and I was wrong about dart:collection being useful. The dart2js version is much slower than the comparable Javascript/Typescript version.
Dart code compiled with dart2js : +/- 20 000 milliseconds on my computerimport "dart:collection";
class A {
int x = 0;
}
generator() {
return new A();
}
main() {
Stopwatch stopwatch = new Stopwatch()..start();
HashMap<String, A> map = new HashMap();
String key = "";
int lim = 9999;
for (var x = 0; x < 1; x++) {
for (var i = 0; i < lim; i++) {
key = key + i.toString();
map.putIfAbsent(key, generator);
}
key = "";
for (var i = 0; i < lim; i++) {
key = key + i.toString();
map.remove(key + i.toString());
}
}
stopwatch.stop();
print(stopwatch.elapsedMilliseconds);
}
Javascript/Typescript: +/- 870 milliseconds on my computervar A = (function () {
function A() {
this.x = 0;
}
return A;
})();
function generator() {
return new A();
}
function main() {
var process = require("process");
var map = {};
var key = "";
var lim = 9999;
console.log(map[key] == undefined);
for (var x = 0; x < 1; x++) {
for (var i = 0; i < lim; i++) {
key = key + i.toString();
if (map[key] == undefined) {
map[key] = generator();
}
}
key = "";
for (var i = 0; i < lim; i++) {
key = key + i.toString();
delete map[key];
}
}
console.log(process.uptime());
}
main();
--
I do not understand your message.
I tested the output of dart2js and not the Dart VM. If I would limit myself to server programming then I would use Dart anyway.
Thanks for the clarification.
I assume by time you mean number of iterations.
I made all tests with nodejs 4.2.1 and used dart2js from SDK 1.13.7.
Dart has absolutely no official backup and not even a word of acknowledgment from the Android teams.
And it takes at least half an hour for a newbie to setup a decent development environment.
I don't see a strategy here.
If Android Studio supported apps based on Mojo IPC with, optionally, the Flutter engine with, optionally, the DartVM... THAT would be something to look forward to.
Google killed dartium in chrome and typescript stole the majority of its thunder wrt being a more strongly typed language for web development because of its backwards compatibility with JavaScript is simpler and it works. It also generates very clean code.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
Since google autocompiles tools to dart (for what I've seen), now ask your self what that means!
I think Swift's strength is also Apple's commitment. People know Swift is the way to go on iOS/OSX.And Dart drowns in a see of uncertainty, with no public commitment being shown at all.
Also, Swift designers were a lot bolder, and yet, Swift is still familiar.
From top Google strategists to Dart's language designers, maybe some could use a pair of balls.
But seriously Google need to give a client side roadmap - especially to break down the barriers between web and mobile.How many client side runtime's - V8, ART, Dart, Go - does Google need ?
// named params - no overloading - msg resolved at runtime - types are annotations only (no runtime effect)
obj.msg(param1: 1, param2: "two");
But seriously Google need to give a client side roadmap - especially to break down the barriers between web and mobile.How many client side runtime's - V8, ART, Dart, Go - does Google need ?Let's take this one at a time...
V8 - If you build a web browser you need to be able to run JavaScript. If Google made Chrome without a JavaScript VM nobody would use it. The roadmap for web browsers is mostly predetermined, or rather, is not solely up to Google to determine. Not much room to innovate other than making things faster, which Google did with V8.
ART - This one is mostly due to momentum. Android has to keep moving forward and competing. Even if Flutter might be on the horizon they can't just freeze all Android development, that would be a disaster. We still have many years of Java on Android and this path needs to work well (just as Objective-C still has many years with Apple until more people switch to Swift).
Dart - Seems like the current long term bet for Google.
Go - Not client side runtime. My understanding is that this was designed for server side applications.
Go - Not client side runtime. My understanding is that this was designed for server side applications.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
V8 - If you build a web browser you need to be able to run JavaScript. If Google made Chrome without a JavaScript VM nobody would use it. The roadmap for web browsers is mostly predetermined, or rather, is not solely up to Google to determine. Not much room to innovate other than making things faster, which Google did with V8.No. See Strong mode and SoundScript. Also WASM.
ART - This one is mostly due to momentum. Android has to keep moving forward and competing. Even if Flutter might be on the horizon they can't just freeze all Android development, that would be a disaster. We still have many years of Java on Android and this path needs to work well (just as Objective-C still has many years with Apple until more people switch to Swift).
No. The ART runtime could migrate to a new toolkit like Flutter. And ART really isn't Java anyway - there's no byte code interface - the interface is still Dalvik. So Google could bless something like Kotlin and evolve in it's own direction via Jack and Jill.
Dart - Seems like the current long term bet for Google.The problematic word here is seems. If there's an memo as entertaining and informative as the infamous one from 2010 giving a current roadmap I wouldn't mind seeing it.
Go - Not client side runtime. My understanding is that this was designed for server side applications.Some 'experimental' work is being done in this area on Android.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
"GWT was a nice Idea but with Dart you save compile time and get documented use cases, repository etc."Sorry but GWT still is a nice idea. Wayyy advanced than dart. And since we dont have a dart VM in the browser Dart will need a compilation step for web apps too.
GWT was a great idea for its time when browser incompatibility in terms of JS was at an all-time high, things are much better now and I'd argue GWT is semi-obsolete, unless you enjoy that horrendous long latency between making a one line change and waiting, refreshing and hitting permgen then restarting the devmode or needing Java developers to do the designer's work.
It just took forever getting anything done in GWT and then on large projects, compile time was insane.
Dart on the other hand got rid of the boilerplate and the latency GWT had and compile time is a small fraction for similar sized projects.
I guess u have not checked GWT in a while. Devmode is gone.
Nothing against Dart just don't see it solving something GWT has not.
On Tue, Oct 20, 2015 at 10:46 AM, kc <kevin...@gmail.com> wrote:V8 - If you build a web browser you need to be able to run JavaScript. If Google made Chrome without a JavaScript VM nobody would use it. The roadmap for web browsers is mostly predetermined, or rather, is not solely up to Google to determine. Not much room to innovate other than making things faster, which Google did with V8.No. See Strong mode and SoundScript. Also WASM.Removing features from a language so that it can be faster on a specific runtime but still run on other JS VMs is not the kind of groundbreaking innovation that will change things.Roadmap for V8: make JS code run faster in the browser.This was the original goal and this is still the goal of the projects you mention.There was a time when V8 being fast was innovative. Somehow I don't think there will be new breakthroughs on that front to cause everyone to stop what they are doing and pay attention again.
ART - This one is mostly due to momentum. Android has to keep moving forward and competing. Even if Flutter might be on the horizon they can't just freeze all Android development, that would be a disaster. We still have many years of Java on Android and this path needs to work well (just as Objective-C still has many years with Apple until more people switch to Swift).No. The ART runtime could migrate to a new toolkit like Flutter. And ART really isn't Java anyway - there's no byte code interface - the interface is still Dalvik. So Google could bless something like Kotlin and evolve in it's own direction via Jack and Jill.Are you saying that the .dex format makes no assumptions about the input language being Java? And as a result the subsequent tools in the chain?
Java is the official language for developing Android apps. ART is just another step in the optimization of that tool chain.
Dart - Seems like the current long term bet for Google.The problematic word here is seems. If there's an memo as entertaining and informative as the infamous one from 2010 giving a current roadmap I wouldn't mind seeing it.Okay, here is something from less than two months ago:That pretty clearly states the top goal is mobile app development.
Go - Not client side runtime. My understanding is that this was designed for server side applications.Some 'experimental' work is being done in this area on Android.I don't think you can even begin to compare the investments Google is making in Flutter vs the golang mobile project. Not to mention that there doesn't appear to be any mention of UI framework for go on mobile where as for Flutter you get a full dedicated UI.
If we get Strong mode / Soundscript, async, and es6/es7 features such as collections in the next year or so, then what will keep Dart compelling? Typescript ate up a lot of the reasons for adoption.
But can this runtime model with GC/JIT compete with ART (no JIT/AOT) and Swift (no GC) on mobile with Flutter.
But can this runtime model with GC/JIT compete with ART (no JIT/AOT) and Swift (no GC) on mobile with Flutter.JIT or AOT? Why not both? ;)
The Dart VM is way too much of a black box.Some info on how the the Dart VM is engineered - especially to interact with the Flutter engine (with a nice surface syntax) - would help make the sale.
There is a lot of talk about Dart being not popular enough. I think most people here love dart, and everybody thing he knows how Dart can get popular, including me ;) But of course, most of this is just pure speculation and guessing...I think it is also easy to confuse your own wishes for the future of dart with the things that really makes a language being picked up by the mass.I think that Dart would get much more popular, if it pushed the tooling support to be closer to what IntelliJ provides for Java or Visual Studio provides for C#. But yeah, to be honest, that is just what I personally would love. I have no idea what the "mass" wants. I once saw a poll that showed the NotePad++ is still the most popular editor...
So therefore let's look some actual data for once, the stackoverflow developer survey.One result that got my eye is "the most loved language of 2015". It turns out to be Swift. It is not the most used language of course, but people that use Swift love it, and programmers want to start coding in Swift.Okay, so that is just a fact: Swift is loved. So, considering Dart 2.0 and breaking changes etc. I think it would be smart to very consider at what Swift is doing. Because they do something right it seems, not only to attract the mass, but also being loved.One thing that Swift may does very well. Is that it looks very familiar, but with all the familiarity it is never completely the same as you used to, there seems in every feature always something that is a bit better then you are used to from older languages. At least it pretends to be. For example:
1. You can just declare variables as you used to, but you don't need a semicolon anymore.2. You can declare variables as constant (in dart we would say final).But instead of writing the standard 5 letter word const, you can now write a 3 letter word let. That lines up nicely with var.3. You can just write if/else statements as you used to, but you don't need parenthesis anymore.
if name == "world" {
print("hello, world")
} else {
print("I'm sorry \(name), but I don't recognize you")
}
- 4. You can just write for statements like you used to, but instead of writing for(int i = 0; i < 5; i++) you can now write:
for index in 1...5 {
print("\(index) times 5 is \(index * 5)")
}
- 5. You can just write switch statements like you used to, but you don't need break statements anymore:
switch someCharacter {
case "a", "e", "i", "o", "u":
print("\(someCharacter) is a vowel")
case "b", "c", "d", "f", "g", "h", "j", "k", "l", "m",
"n", "p", "q", "r", "s", "t", "v", "w", "x", "y", "z":
print("\(someCharacter) is a consonant")
default:
print("\(someCharacter) is not a vowel or a consonant")
}
5 . 6. You can write new instances of objects, but you don't need the new keyword anymore:
let someResolution = Resolution()
- let someVideoMode = VideoMode()
let vga = Resolution(width: 640, height: 480)
SYSo well okay, I think you see the pattern. To be honest, all this little sugar, is in practice not that important. In my eyes, in daily programming, having a very good analyser, and debugging experience, is much more important for productivity. However, I can understand that things like this sells very well. If there are going to be breaking changes in dart 2.0, I think it may be smart to consider what Swift is doing here. Swift is the most loved language of 2015. Dart wants to get a little bit more love, maybe learn a bit from a winning team?a
+1 to Günter: Swift is great, but it's popular because of the reference point (Obj-C). Introducing Swift was a big jump DevExp / productivity jump for iOS devs.Also, Swift is a more dynamic language than Obj-C, while Dart could be seen as less dynamic than JavaScript. When you remove the bounds from a statically typed language with manual memory management (Obj-C), you'll get a lot of love from the majority of developers. When you add bounds (a.k.a. sanity) to an (arguably overly permissive) scripting language (JavaScript), majority of devs won't appreciate it. Dart (without the tooling) is only appealing for senior devs.I personally agree that Dart is going to be successful through tooling.Thanks for pointing out the SO dev survey. I know the Dart team is looking at data like this. To me, the most interesting part of the survey was [a] Windows (all versions) having 54.5 % of dev market share, [b] all of the most popular IDEs being text editors (NotePad++, Sublime, Vim, ...), [c] tabs winning over spaces, and [d] side projects getting as many hours of a devs week on average as it does.— Filip
Why DART was named DART?
At least I think because it was a promisse of clean conde,running in a clean VM.
See this in Youtube
https://www.youtube.com/watch?v=5AqbCQuK0gM
Now I see myself clapping every Lars speech and
Speech.
Believe me or not,I don´t thing that Anders itself believes in a word that he said.
I remember having some talkings in the NET with people that have choosen TypeScript over DART.
Their arguments:You can have TypeScript and JavaScript Libraries in the same project,all browses VMS run javaScript.
My arguments:Performance is the most important thing in Internet where resources are lower and more expensive than Desktop Applications.
I Can use Dart both in the Client and in the Server.
JavaScript code is garbage and should never had been written,it was written in 20 days,and it is really bad for what could have been done 20 years ago.
It is like having a religious ex- seriall killer living in your house.
The other browsers will have to acept DART or become turtles.
I Don´t care how many years google would take to do this,I don´t mind having two browsers,one to run stupid old javascript code,and one to run corporate code.
But Google said We will never have a DART VM,thats really disapointing.
At first i thougt that´s pure marketing.
But even for the market point of view,that was really bad,I think it is affecting the language aceptance and users Growth.
Being revolutionary was one of DART´s most appealing reasons.
What I´m traying to say is:Its harder to Sell Dart to your Boss today than it was in 2014.
“All men should keep their word, kings most of all. “
I think thats from Game of Thrones
Google is not acting as a King, at least in my opinion.
In fact I don´t produce Code rigth now,I left my job as a CIO ,I know have time to code again,Just a Starter with DART.
Marcello
|
|
|
|
|
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
With Apple's commitment, Swift has a brighter future. At least swift will not die in about 20 years and Apple will use it as a primary language for sure.
Oh, the humanity! (pun intended)
If it wasn't for lifecycles, I guess Adam and Eve would still be punching cards :P
OMG does this mean that if I use Dart, I'll die?
Please don't forget NewtonScript!!!
On Sat, Aug 20, 2016 at 12:58 PM, Song Lusic <sgo...@gmail.com> wrote:With Apple's commitment, Swift has a brighter future. At least swift will not die in about 20 years and Apple will use it as a primary language for sure.
In the past twenty years, Apple canceled Dylan, HyperTalk, and Object Pascal. They certainly aren't putting much effort into Objective-C these days, either.
Every large technology corporation with a long history has a big pile of terminated projects. Death is part of the technology lifecycle.
On Tuesday, August 23, 2016 at 6:11:13 PM UTC+1, Bob wrote:On Sat, Aug 20, 2016 at 12:58 PM, Song Lusic <sgo...@gmail.com> wrote:With Apple's commitment, Swift has a brighter future. At least swift will not die in about 20 years and Apple will use it as a primary language for sure.
In the past twenty years, Apple canceled Dylan, HyperTalk, and Object Pascal. They certainly aren't putting much effort into Objective-C these days, either.Need to mention Apple pre vs post Jobs.Jobs canned Dylan and the Newton. Then Apple backed Objective C plus frameworks - avoiding the siren song of Java on OS X and JS on iOS. Developers thus had a platform to build on.Now Apple have a new language - Swift - which offers an evolutionary path from the Objective C frameworks.So developers want to get a feel if Google is giving backing to Dart the same way Apple backed Objective C and now Swift.(An irony is that Dart is more of what some devs were after - Objective C without the C - then Swift).
K.
Every large technology corporation with a long history has a big pile of terminated projects. Death is part of the technology lifecycle.