fun would have been better:
- ML heritage for named functions (fn was anon)
- muscle memory with the leading part of javascript function
- the other abbreviations take the leading part of the word
I would be interested in a Swift port for Linux server-side/command line dev. Not so much client UI dev. Swift on Linux servers could help Apple sell more Macbooks to developers.
And Microsoft puts money on F#, Haskell and OCaml, all of which already have better Linux support.
Swift is great for pushing functional programming down the throat to mainstream developers that wish to target iOS, but it is no more pragmatic than OCaml or F#.
For the OP use case, targeting Linux server software is already better served by the languages I mentioned.
> At some point, Sweet.js ties the knot and people can write hygienic macros and extend the language.... And it’s all based on a common set of primitives and that’s the important thing. You can reason about the primitives. You can compose them. They’re compositional. They compose orthogonally. That’s the goal here. JavaScript has a lot of warts in it, but if you weed those out or deprecate them you end up with stuff that is compositional. And that’s where I think we’re heading.
Odersky: That's going to be a more fundamental rethink of what Scala is. The main goal is to make it simpler, to review it or work out what its core is, and have a very simple core on which essentially the other features of Scala can all be based. Essentially, it's a way to modularize the language better, to base the features that we know from Scala on a very, very simple core that we can compile efficiently and reason precisely about. That's the main goals for Don Giovanni.
Java is neither 32 nor 64 bit, it is bitness agnostic to a large degree (or at least where it matters it is, datatypes aren't really a major advantage, and most of the new CPU registers can be utilised in the JVM without the code being aware or being recompiled).
You also say that they need something "richer" (whatever that means?), "more expressive," (huh?), and "open" (even though the JVM on Android ("Dalvik") is free and open source software).
Sorry but everything you said there is either confusing or wrong. You just wanted to bring up Swift and seem to know absolutely nothing about Java/JVC/Dalvik, except that it is "old" and therefore just assume it is "bad."
I actually think C# is a better language than Java (at least in their current iterations). However not for any of the reasons you cited, for real reasons that actually make sense.
I agree, it was pretty much buzzword fest.
Here : I think the Android framework (Java + Android APIs + Android dev tools) should evolve towards something less verbose.
Let's say I want to add a new type of selector in my ListView (for example for the active entry of the navigation drawer). I need to declare it in attrs.xml, use it in my layout and also to write custom versions of all the views that are going to use that selector in order to override onCreateDrawableState and inject it there, not to mention all the plumbing in different classes in order to get & set that state..
Ideally, I should be able to simply declare that state in my layout selectors and simply set it in the corresponding adapter.
There are many, many other examples where I need to modify many classes in order to do something relatively common.
There are also issues with some java aspects like the enums that are syntactically very nice to use but not that good for your performances. I also feel like a caveman each time I have to write a bitfield.
I should have a construct built into the language (or at least the IDE, I don't really care which one) that gives me the flexibility and type safety of enums while performing like a bitfield.
I don't know if getting rid of java is the answer here. I would not mind to, but it would be very traumatic for the Android ecosystem.
I hope that these pain points will be fixed (I/O 2015 ? ^^). I don't think that Google will ever use C#. However nice it is, it is controlled by Microsoft, which is probably reason enough for Google to avoid it.
There are other options though, Dart, Rust, Go, an entirely new language, ...
Value types with operator overloading. Expressive and good for performance.
Open? Java is owned by Oracle.
C# is better and more expressive than Java. Especially the functional/declarative features added after the initial Java influenced release - async/await, var, linq etc.
At the Google IO Android Fireside Chat, a developer asked the Android team about using an alternative to Java for development - Scala in his case. Pretty much 'no' was the response. But don't Google have any taste. Kotlin or Xtend imo are lighter than Scala and would be good fits for Android.
I totally agree with the original poster. I picked up Java in the mid-90's for server-side dev. Grew to loathe it.
When Google announced an open-source OS for mobile - I was so happy. But ... Java. Broke my heart. Don't Google have any taste. At least Google could bless an alt-Java Swift-ish alternative like Kotlin, Xtend, AnythingButJava.
Google have issues with Oracle. Why not bless an alt-Java and give developers a clear signal. The end game should be
Kotlin or Xtend or ? -> Dalvik/ART. Cut out Java.
Dart is interesting but a little too Jave-ery in both syntax and tools - Dart Editor is Eclipse based. Also, not sure how committed Google is long-term.
Google's issue is too many languages and runtimes:
Go, JS/ES6/V8, Dart/DartVM, Java/ART, PaNcl, RenderScript.
With the Material/Paper UI Google have given dev's a consistent, elegant unified surface. But Google should also be moving in the direction of an (elegant) unification under the hood. Java and JS are 20 years old - but are at the core of Google's platforms - Android and Chrome/OS. But what - Kotlin, Dart, ES6/7?
Imo Android needs a Swift because:
1. Java is too verbose/tedious. Developers are looking for something richer/more expressive.
2. Oracle. Java is non-open.
Ultimately, the language that will become the Swift on Android is the language that makes it a core goal. This alt-Java could even be blessed by Google. Google could eventually cut Java out of the picture: Swift4Java -> Dalvik/ART.
Xtend, Kotlin and Scala are possibilities.
Kotlin has the Jetbrains Android Studio relationship going for it. Also compiles down to JS so could target Chrome/ChromeOS as well. Not as heavy as Scala - less of a learning curve. Xtend is good, and compiling to Java source could be an advantage. But Google do seem to be leaning towards Jetbrains rather than Eclipse.
fun would have been better: - ML heritage for named functions (fn was anon) - muscle memory with the leading part of javascript function - the other abbreviations take the leading part of the word