As much as I want this, it's not going to happen for the simple reason that Clojure adds a big runtime and a huge startup cost on Android, which is unacceptable. It's fine for servers, but a total deal-breaker for mobile apps.
Kotlin on the other hand has a tiny runtime (< 1 MB before dead-code elimination etc with Proguard) and negligible startup cost - in fact several popular Android libraries have a bigger startup cost impact than Kotlin.
> Kotlin compiles to Java bytecode, so you don't need to deal with JavaScript engines, serialization/deserialization, etc.
I don't think the GP meant replacing JS with Kotlin, rather they're referring to implementing React Native modules in Kotlin instead of Java, keeping the JS part untouched. (As you may know, React Native modules/components require native implementations before they can be used in JS).
I think you're reading too much into this. The only reason they adopted Kotlin was because Android devs were already using it. Jake Wharton, one of the most well-known Android developers, has also been a vocal supporter of the language for a long time, so much so that Google actually invited him to give a talk about it at I/O this year - I have never seen Google invite a community member like this before.
Source: I've been developing Android apps for 2 years and closely follow all developments in the community.
Moreover, if USCIS thought this would affect already-filed applications, I think they would've made a clear blog post stating it as opposed to dumping it in a hard-to-read memorandum. (I'm subscribed to their newsletter which I've observed sends out all pertinent news with no delays).
The way I think about this is: if not SpaceX, some govt or company will one day establish a base on another planet. Something like the stations we have in Antarctica. So SpaceX taking a shot at this isn't totally absurd - over-ambitious, sure, but not so ridiculous as to be out of the question. Maybe it won't happen for a few decades, or a century - but IMO it's very likely it will happen some time. And that's what ultimately matters. It doesn't have to be Elon Musk's company that does it.
Cities on Mars - it's not productive debating this at such an early stage, though it makes for an interesting discussion.
I think who gets there first is going to have a huge impact on what kind of society is established on Mars (the economy, the legal system, the culture, how infrastructure is managed, government, etc...). SpaceX may change its culture over time, but as things stand now I would rather live in a society established by SpaceX than one established by, say, Boeing.
You're ignoring the possibility that cars may emit only tiny amounts of sulphur and nitrogen oxides, compared to ships whose emissions are largely made up of those gases. That would be consistent with both sentences, although I don't know if it's true. EDIT: Looks like that is indeed true, see this thread: https://news.ycombinator.com/item?id=10716251
Not sure why you've been down-voted. Twitter is so different from Facebook in terms of what it's primary use is, that it doesn't make sense to compare them, and while I wouldn't quite word my response this way, I agree with the sentiment that Facebook usage data doesn't tell us enough to predict Twitter usage under higher character limits.
> It means that you should be able to re-use (compose) interface elements, so that even a junior developer could create a great interface (UX-wise) by assembling one from parts that are made to work well together.
I don't think "compose" == "reuse" as you suggest. Reusing well-designed interface elements gets you very little in terms of usability, because the important parts of UX design - like page structure and navigation - cannot be handed to developers in ready-made toolkits.
I do agree with the second half of your comment though. Mozilla's Ubiquity project [1] is the best example I know (see [2]) of on-the-fly composability in modern GUIs. Admittedly Ubiquity is somewhat underdeveloped, but the core idea is solid, in my view.
There's also things like IFTTT, Zapier, and Slack integrations, but:
1. They involve up-front configuration, and,
2. You need to redo this configuration for every pair of apps you want to compose together, which is obviously not scalable.
I'm late to this thread, but quite surprised to see nobody mentioned Mozilla's Ubiquity addon [1], which I think best demonstrates the idea of "composability" in a GUI you're trying to convey. I think adding a description/screenshot of Ubiquity or explaining one of its use-cases would explain your idea more clearly and actually put someone on the right path if they accept your call to action.
Incidentally, Aza Raskin, one of the main developers of Ubiquity is the son of Jef Raskin who led the work on Apple's Macintosh.
At one point in college I was fascinated enough with Ubiquity to try to continue the work on it (since the project was shelved), but my programming skills were just not up to it. Perhaps I'll get back to it sometime soon :)
Ubiquity (and it's related predecessor, Enso) was an excellent idea and I'd almost forgotten I'd used it for about 18 months before the project died out. Raskin took the idea from his father of course, and it's discussed in his book "The Humane Interface", one of the best books about software design ever to have been written.
Yep, The Humane Interface is already on my (apparently ever-growing) reading list! Should probably bump it up as I've seen it recommended so much. Thanks :)
I've been thinking, with all the huge advances in AI/ML in the last few years, now might be exactly the right time for an ambitious project like Ubiquity, since it relies heavily on natural-language processing. Thoughts?
I can see where that's coming from, but this is a one-sided view. It misses the obvious conclusion: interface agents (to use the article's terminology) are complementary to direct manipulation interfaces, not a replacement.
Direct manipulation is great at discoverability, when I'm exploring the choices available to me, but it sucks if I'm looking for something specific (for software with a minimum level of complexity, like Photoshop or Excel). Interface agents have the opposite characteristics, as the article explains. So, they're complementary techniques.
To provide a simpler example, not involving AI: if the user is a domain expert (say, a graphic designer), the ability to search for and perform a specific action quickly is far more important than discoverability. For example, the user may already know that GIMP provides a feature for drawing a path but have only used Photoshop in the past and now they just can't find that action.
Aside: it is telling that established design software like Photoshop / GIMP has such a bewildering maze of menus even today. But if you take Google Chrome, for instance, it provides a stellar searchable user interface [1].
On the surface, yes. But calling it a launcher does it a disservice - it was more ambitious [1] than any other launcher I've seen, although they unfortunately stopped developing it. Their ultimate goal seems to have been to build something like Unix pipes for the web, e.g., see use-cases like [2]: "insert a map for the selected location into the email I'm writing, without leaving my current tab", and this without any help from the developers of Gmail or Google Maps.
Moreover, this was way back in 2008 [3] vs I think Alfred in 2011 and the others are recent clones. I think Ubiquity was a few years ahead of its time - with today's AI advancements, they might actually be able to achieve a large part of their original mission. This has got me thinking...
Kotlin on the other hand has a tiny runtime (< 1 MB before dead-code elimination etc with Proguard) and negligible startup cost - in fact several popular Android libraries have a bigger startup cost impact than Kotlin.