So, the author's justification is that Apple now has Swift for iOS, so Google should bring Dart to Android.
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 think people, or at least people like me, want languages that don't suck to develop in. Write once is great, but being able to spit some code out without really old language cruft getting in the way would be nice too. Objective-C was written forever ago. I don't want to type 30 character method names and write 6 lines of code to do simple "map" operations. Swift and Dart make these things better. They are hopefully fast enough to also not make the end product not suck too. I've worked at at least a handful of companies doing both iOS and Android and they've all done multiple versions of the same app; these write-once libraries and projects just don't do it well enough IMHO.
You're totally correct and I certainly don't disagree that Swift is an improvement to Obj-C. I just wish some one [who counts, i.e. not Microsoft, apparently] would just attempt to pick up the 'write once' torch.
Except that Dart compiles to JavaScript so you can still 'write once' and have it run anywhere. Also I don't really see how Dart is "proprietary" since it is being standardized in Ecma TC52 and is licensed under the BSD license.
> Also I don't really see how Dart is "proprietary" since it is being standardized in Ecma TC52 and is licensed under the BSD license.
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?
I'm skeptical that write-once would truly catch on; it typically requires stronger architectural skills than most devs want to undertake.
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).
I'd say "Bring Scala to Android" would be more comparable? Bring Clojure and I'd say you're stealing a lot of developers away who think Swift is a half measure.
Performance is not just about the language; Scala and Clojure can be just as fast as Java on the Oracle JVM or OpenJDK. The Android Dalvik VM is just incredibly ineffective at optimisation compared to a real JVM, and Google has done little to improve it. Things might change with the new ART VM, however.
Or Google could just embrace Scala. You can already use it to develop on Android, it already has all the good stuff Swift has (and more), you can use all the existing ecosystem because of the compatibility with Java.
Having it officially pushed by Google would mean better tooling and more Scala-ish APIs.
Although I love Scala, I don't think it will work as a primary language for an app platform such as Android. Idiomatic Scala is just too alien for most people to comprehend quickly.
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.
My argument was also about familiarity. The imperative subset of Scala is really familiar to Swift, you're absolutely right (+1 for posting that comparison). However, real-world Scala is different. With powerful trait-based OO programming, its functional style with routinely chaining monad after monad, and implicits everywhere. It's incredibly powerful, but not an accessible language for an app platform as large as Android's.
People can always stick to a style they are comfortable with.
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.
There will always be somebody to go wild with scalaz and/or shapeless. Scala has the same problem as C++ - you have to agree on a reasonable subset within a team and ensure that everyone sticks to it.
Why not Groovy? Scala is a beautiful language but it has a complex type system and it's multi-paradigm which can be confusing for new developers. Groovy, on the other hand, is very simple (especially if you already know Java) and suits well fast prototyping. When I saw Swift announced at WWDC the first thing I thought was "Google could bring official support for Groovy to Android"
> 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.
The main thing Swift is lacking compared to Scala is support functional programming. I'm not sure that's the part which you want to back away from.
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. :-)
I think SICP is still very important from an educational POV.
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.
Scala's dependencies on the JDK are minuscule, certainly a lot smaller than what's considered "the core packages required by/to support the Java language" by the court.
I'm not sure if Dart is the answer, but Google definitely has to do something about it's "language problem" on Android. Especially with Apple introducing a modern language in Swift. It's a shame that all of the great JVM languages don't easily work on Android or they wouldn't have the problem.
Though I understand their reasoning to a degree, it does seem perverse that they adopted the most pedestrian bit of java -- the language -- while jettisoning the crown jewel -- the JVM.
It hasn't been trivial to get other JVM languages working on Android, and ironically that list now includes Java 8.
You can't make an open source platform around a core that requires a commercial license. Had Google done as you suggest, there would be no AOSP, which is fairly strategically central to Android.
Tactical choices are constrained by strategic goals.
> I was talking about third-party OS builders, which could anyway pay for licenses as they always did.
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".
I think it makes very much sense for Google to start pushing Kotlin. It runs on JVMs. It is compiled. It's a simple language to migrate to for Java developers, but provides more convenience than Java 8. It does not have the impedance mismatch with Java that some of the other new JVM languages have. Moreover, it's well-supported by IntelliJ and consequently by Android studio.
I'm surprised you were downvoted. I think this suggestion makes a ton of sense. It's certainly the shortest path to having a significantly improved first-party language for Android and Google does have a working relationship with Jetbrains.
That would be neat and a very pragmatic choice, but I'm not sure that Kotlin provides enough of an advantage over Java to make migrating worth for a significant amount of Android developers. Scala goes a step or two further, but the overhead (cognitive and at runtime) are a problem too.
Agree. Kotlin is pretty much Java 8 with Scala syntax. It's neat, but mostly useless.
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.
Agree. Kotlin is pretty much Java 8 with Scala syntax. It's neat, but mostly useless.
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.
> Also, I assume that JetBrains would be open to other features
> that Google would like in a Java-replacement.
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.
Why Dart and not Go? And isn't Dart's performance more in line with Javascript than Java? Android needs something that has better performance than Java, not worse, but also easier to learn and use to appeal to a broader range of developers, especially new developers, that will be growing up with Android in many countries.
A lot of Android developers don't like Java because of its syntax. Dart seems very similar in syntax to Java (which I assume was intentional, but the wrong thing to do)...so not much improvement there. No wonder Dart hasn't been getting anywhere near the excitement Go has received.
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.
Actually I think Dart has a lot of benefits in terms of syntax compared to Java. I am working with java since 2001, so I can tell. If you are interested to briefly look at it, you can do that here: https://www.dartlang.org/docs/synonyms/
Well, comparing with Java is aiming a bit low, isn't it?
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);
}
Let's remove the comments for a more visually fair comparison:
class Person {
String name;
Person(this.name);
}
vs
class Person(val name: String)
Ok, you save a line. I don't think that's a big deal. Also, the Dart version is very clear about what's a field or not. The first example I found of Scala classes on their site is this:
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 + ")";
}
With text that says `x` and `y` are the fields. What about `xc` and `yc`, I thought those were the fields?
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;
}
Optional constructor args:
class Person {
String name;
Person({this.name});
}
Super call:
class Person extends Animal {
String name;
Person(this.name) : super() ;
}
The short Scala form may do that as well for all I know,
> Let's remove the comments for a more visually fair comparison:
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.)
Yes. It's probably the same weird confusion I had, too ... because all "experts on the Internet" complain about Scala being a kitchen-sink of features, but if you actually walk into it, you just wonder how they managed to reduce and condense features into such a small, well-designed orthogonal core ... and wonder why no one else did it before.
In hindsight, Scala is much smaller than C#, F#, C++, OCaml, etc. while still being more expressive and comfortable to use.
ART seems to be the future runtime on Android. Since it has an LLVM backend it would be interesting to investigate LLVM IR bitcode as the "code" format used in the apk. This would make Android development technically possible feasible a number of languages. Microsoft has already done this with the CLR.
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.
> I like it. Even more than Java' which I used for a long, long time. Even more than PHP' which I used since I started with web programming. Even more than JavaScript, with which I am happy to work with.
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.
Golang would be sweet on Android. It'll still need to run on top of the Java runtime but that's not too bad given that ART will be the default rather than Dalvik.
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++.
I'm pretty skeptical Google is going to push anything based off of it as a first class citizen, ever.
(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~)
Right, but I was thinking of Golang as an optional language that you could use to build parts of your app - the ones that require concurrency, performance etc. and can leverage Golang's strengths. So instead of writing C/C++ you would write Go code. You would still use Java for the UI part - that's not bad at all - you have memory safety, maturity, Garbage Collection and some time later even some of the cooler JDK8 features. No point in throwing all that away.
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.
I don't understand (this is not a rhetorical device, I honestly don't understand) what makes mobile development so different from desktop or server development, where choice of OS != choice of languages. On a Linux server, I can have Perl scripts interacting with Python scripts interacting with MySQL stored proceedures interacting with applications written in C, and use Bash scripts to automate the whole thing. On Windows, I can use applications written in C, C#, Java, Python and a host of other languages, and for the most part not care or even notice what language they were written in. Why do so many of the new development platforms (Android/iOS/HTML5) embrace this "one or two languages" paradigm?
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?
I'd like to see some comments on how Java falls short. I always felt that it had an undeserved bad rap. One way in which it was very bad is terseness - but that's getting much better today with better type inferencing and lambdas.
Java's problem on Android is that your code quickly fills up with annotations and inner callback classes.
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.
Probably the best move for Google would be to write a super fast WebView implementation. This will let the huge mass of web developers to use JavaScript at a speed comparable to Java.
In terms of priorities, I'd think replacing JavaScript with Lua on the browser would rank higher -- it would at least make a lot more developers far happier.
It would be complete insanity from a branding perspective to take an absolute blockbuster brand like Android and to deprecate it in favour of ChromeOS which hardly anybody has even heard of outside the tech scene. Android has a name recognition on par with some of the biggest brands out there.
Branding and marketing are a minor detail, and almost completely decoupled from technical issues. They could figure out something clever... or something simple like calling it Android 5.
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.