It's time: bring Dart to Android
grobmeier.de
grobmeier.de
In my opinion, Swift, although great for shepherding more devs onto the Apple platform, fundamentally directs us further away from the fabled 'write once' dream. Introducing Dart to Android would just further this back-and-forth between proprietary platform holders.
And Microsoft, once again, is left utterly bemused, as it decided to focus away from proprietary languages and allow people to write native apps in JavaScript. But now people are excited about Swift, so is vendor-specific languages what people wanted all along?! How confusing.
I guess most people feel that it's some OOXML-like rubber-stamping process. Or how many of Darts numerous flaws have been fixed in ECMA through the participation of other members?
Compare Dart and Microsoft OOXML is unfare.
- OOXML implementation is not open source nor under BSD licence
- Poorly defined => 6546 pages vs 867 pages for ODF to achieve the same goal
- Given the huge amount of work Microsoft decided to go with... the fast track ISO procedure!
- Corruption of ISO members?
- ...
> how many of Darts [...] flaws have been fixed in ECMA [...]?
None yet, it is just the beginning of TC52.
I suspect most devs actually want a universal platform they can get native-like UIs with while only writing UI code once. Although I don't think that would work out well either (it seems a little soon to be re-learning the lessons of Swing).
If you want functional on Android, I'm betting F# is the premiere method today performant enough to write real apps in.
Having it officially pushed by Google would mean better tooling and more Scala-ish APIs.
The beauty of both Swift and Dart is that they are very "light" languages. You can read a piece of Swift/Dart and see what it's supposed to do immediately. Most people with a JS/Ruby/Python/Java/C# background can immediately see what's going on, and probably quickly pick it up. Yet they still provide productive modern language features. Scala's learning curve is much greater.
Yes, Swift is pretty much missing the FP parts, but isn't that an argument about familiarity, not simplicity?
Preventing bad code is a lot harder than that.
It's perfectly possible to use code which uses "powerful trait-based OO programming, its functional style with routinely chaining monad after monad, and implicits everywhere" without having to know that part of the language.
Just have a look at their mailing lists. Or the issues they are currently struggling with.
It seems that today's Groovy mainly exists for its owning company (which seems to change every now and then) to sell training.
But considering Google's taste for mediocre languages, Groovy would fit right in next to Dart and Go.
Groovy's dead for JVM scripting, and Grails is losing adoption share rapidly, but it's rebounding as the DSL in Gradle. I've yet to see a Gradle build script that actually drops out of the DSL to use Groovy to do any programming, though - perhaps Gradle's too good at what it does.
Developers like Gradle because it has Maven-depth functionality with a JS/CSS-like syntax. Gradle would have more uptake if it enabled developers to plug in other dynamic JVM languages, e.g. JRuby, Jython, Clojure, Nashorn, JDart. Even Scala's dynamic mode might work.
I've looked briefly at Gradle's source and Groovy seems to be entangled deeply in it - Gradle even manipulates Groovy's AST all over its source. I suspect Gradle was set up with the specific intention of promoting Groovy and making it difficult to work with other languages, despite the quote on gradle.org: "We happily support any community effort to create additional build script engines".
Gradle needs to expose an API for its use like other products do if anyone is going to believe they're not going to change their source to prevent other build script languages being plugged in, just like Groovy 1.7 and 1.8 source changed to give Groovy++ and others the runaround around 2010 / 2011. But I suspect the same people behind that are ultimately behind Gradle.
That's why I have no interest in Scala. I prefer languages with only a handful (or less) of "good stuff" that you can then build on top of.
Apart from that, Scala is built on an impressively small amount of orthogonal concepts (at least compared to stuff like C#, F#, C++, OCaml, etc.) despite what all those "experts" on the Internet say. :-)
But I also think standards should reflect the progress made in the last few decades and shouldn't pretend that it's still 1960. Otherwise, things like Go happen.
So, yes, functional languages these days should probably require types (not specific to functional languages, just a general requirement to throw out all untyped languages without wasting time), typeclasses, and at least one of higher-kinded types, linear/dependent types, type families, or something like the fusion of type-level and value-level programming like in Idris.
If Google wanted to stay conservative, they could just support Java 8, but if they wanted something considerably superior ... well, Kotlin is not participating here.
But hey, Google sucks so much at programming languages (see Go and Dart) that I don't expect that they do anything that makes sense for developers.
It does contain many features people have been asking for in Java for years, but that Java 8 does not provide, such as: properties, mixins, type inference, pattern matching, operator overloading, etc.
Also, I assume that JetBrains would be open to other features that Google would like in a Java-replacement.
At any rate, all JVM languages, including Scala are going to be limited by the VM and bytecode. So, you'll have to live with type erasure, without your own value types, etc.
I could totally understand that, it would probably their last and only chance to get some users.
I don't want to sound harsh, but their situations must be quite dire right now. The language is still stuck in some 0.x-land (unlike Ceylon), Java 8 shipped with most of their features already, they are unable to compete with better languages (like Scala) and the tooling and IDE situation looks pretty bad, too.
> At any rate, all JVM languages, including Scala are going to be > limited by the VM and bytecode. So, you'll have to live with type > erasure, without your own value types, etc.
Because having a VM with value types and working Generics is such an impossible feat that no one managed to implement it? I guess not.
No one is preventing them from supporting a superset of the class file format which allows value types and better Generics.
I think it's very unlikely that this is in the works since, if it were, you'd expect Google to have thrown significant weight towards kotlin development (https://github.com/JetBrains/kotlin/graphs/contributors).
It hasn't been trivial to get other JVM languages working on Android, and ironically that list now includes Java 8.
Oracle are largely to blame, I suppose.
Tactical choices are constrained by strategic goals.
End users have no use for open source, besides free beer.
Or they could build their own OS's from scratch, as they always have also done, sure; but an important part of Google's strategy, though, was to make the core of Android open source, which they couldn't do if something as fundamental as the basic runtime required a paid license from a third party. And AOSP is -- empirically -- not useless to third party builders without the separately-licensed Google services.
> End users have no use for open source, besides free beer.
Just-for-me modifications are a real thing, if maybe not all that common, so I wouldn't say "no use".
What Android needs isn't just a slightly better Java that isn't owned by Oracle, but something more like Python that has the performance of C++, for the next generation of developers. If they're going to deprecate Java in Android and cause everyone a lot of grief over it anyway, they might as well do it right, and for something truly exciting to make people rally around it.
Dart makes me excited, when i am honest :-)
Compare Dart's "shorter alternative" of a bog-standard class ...
// Shorter alternative
class Person {
String name;
// parameters prefixed by 'this.' will assign to
// instance variables automatically
Person(this.name);
}
class Person(val name: String) // Done.C# 6 also copied it (although it doesn't really look that clean, because of their incompatible mess in fields vs. methods vs. properties).
In hindsight, Scala is much smaller than C#, F#, C++, OCaml, etc. while still being more expressive and comfortable to use.
class Person {
String name;
Person(this.name);
}
class Person(val name: String)
class Point(xc: Int, yc: Int) {
var x: Int = xc
var y: Int = yc
def move(dx: Int, dy: Int) {
x = x + dx
y = y + dy
}
override def toString(): String = "(" + x + ", " + y + ")";
}
Another thing I like about Dart is that the possible variations on the constructors fall into place, consistently:
No constructor args:
class Person {
String name;
}
class Person {
String name;
Person({this.name});
}
class Person extends Animal {
String name;
Person(this.name) : super() ;
}
It was not meant to be unfair, I just took an existing example. If the Dart devs thought they needed the comments to make it clear what happens, then it's a decision I respect.
> Ok, you save a line.
Three.
> With text that says `x` and `y` are the fields. What about `xc` and `yc`, I thought those were the fields?
For standard classes, the compiler just does what you tell him:
If you write that you want a "val", you get an instance value, if you write a "var", you get an instance variable, if you write nothing (like in this case), you will usually get ... nothing.
That's perfectly clear in my book.
> Another thing I like about Dart is that the possible variations on the constructors fall into place, consistently:
In most languages, allowing a constructor which forgets to initialize things is considered a compiler/language bug.
(And having more than one constructor is pretty much considered to be an anti-pattern in Scala anyway.)
> Super call:
In Scala:
class Person(val name: String) extends Animal- MobileChromeApp[1] converts Chrome Apps into Android apps. Developed by Googlers.
- Web Components enable modular, re-usable code. Polymer[2] is backed by Google.
- AngularJS[3] is a modern UI framework for the Web and is backed by Google.
- Dart[4] is a new language, with tools and libraries, for scalable Web app engineering from Google.
- AngularDart[5] is Angular on Dart.
- ART[6] is a new Android runtime that leverages LLVM, opening the possibility of offering alternative front-ends for Android other than Java.
- Sundar Pichai runs both Chrome and Android.
- The rumored Hera project is supposed to marry Android to the Web.
Dart + Angular + Polymer + ART = new Android Development
My bet is that the future of Android is Dart, Polymer, and AngularDart.
[1] http://github.com/MobileChromeApps
What I am not clear on is how this would integrate with external libraries. Would you need LLVM IR based "shared libraries/dll's" for this to work? Google could provide LLVM IR bitcode (.o) files for the Android platform, and the llvm compiler/linker could reference those (this would be equivalent to the DLL's used in the CLR). Open source apps could do the same, but I am not sure how third party vendors feel about providing IR bitcode for their products. The optimized LLVM IR (bitcode) would then become part of the apk.
Since ART does install time compilation, it could take the optimized LLVM IR in the apk and generate native code for that specific device.
Those aren't the greatest references to praise a language with. While these three languages are obviously very popular, I thought they were widely considered to be poor examples of language design:
* Java is extremely verbose. I wasn't aware of this when I first learned Java, as it was one of my first languages, but having recently returned after, I was surprised at how repetitive doing anything is. (Though I'm personally quite a fan of the platform design and consistency of Java, which I find very clean and intuitive.)
* JS and PHP, while both being major driving forces behind todays (and yesteryears) web, are renowned for their inconsistent design.
That's not to say Java is as bad as ObjC however ;) But something less verbose and more modern like Golang will be a great option to have.
...but to be fair, writing UI and graphical applications has never been it's strong point, and still is not.
Although you can write NDK applications which steal the raw graphics context to do whatever they like (mandala, xamarin, unity, etc.), tapping into the android UI layer is significantly slower and more complex.
Given that the NDK website still says:
In general, you should only use the NDK if it is essential to your
app—never because you simply prefer to program in C/C++.
(That said, the upcoming I/O has what, 4 or 5 slots devoted to NDK related things; clearly despite the android team, at least someone is paying attention to the fact that people use it. A lot. So you never know~)
For that usecase may be Google can extend ART to convert Go code into something that plugs into the ART and outputs something that can be mixed with the AOT compiled Java code.
The ticket for Go support on Android is open since 2012 and no one from the Android team seems to care.
The Go team has reopen the discussion of, maybe, trying to add support for it in the 1.4 release.
Just go look what were the official programming languages from the OS vendors, along the computing history.
What you have lacking is that nowadays, thanks to opensource, outside OS vendors, companies see little value investing into compiler development.
So very few companies produce compilers the mobile OS.
As a result you are left with the open source community, with very few resources tackling these issues.
This all leads to the situation, where the only production quality compilers are the official ones.
About the other languages/plateforms :
Scala/Clojure/Kotlin... already work on the JVM...so they work on Android.
Go is nice.But devs want explicit classes, generics, ... go has no generics.
ChromeOS :a wide range devs dont want to deal with web techs,and neither WebOS or FirefoxOS has proven they are a successfull plateform.Android definetly is.
But I dont see google replacing all the toolchain the JVM provides anytime soon.The only thing they could do is design a language that runs on it and provides the tooling for that.Now can Dart run on the JVM?
Java 8's first class functions should be a big improvement, but you're still left with a lot of terseness, still so-so type inferencer, its limited OO features, and annotations everywhere.