The state of Clojure on Android

#1

Post by Kuytu » Sat, Apr 25, 2015, 7:04 AM UTC

The state of Clojure on Android
blog.ndk.io

Re: The state of Clojure on Android

#2

Post by th0br0 » Sat, Apr 25, 2015, 10:23 AM UTC

From a user perspective, I find the statement that "Lean Clojure" works based off these charts a bit daring. Why?

a) Without having access to the numbers, (Skummet) startup is ~5 times as slow as the Java version. That is a noticeable difference. Plus, even Java apps sometimes tend to take a second or more to start up if they're reasonably complex.

b) The "Lean Clojure works" statement is derived from comparing _only_ the startup times. The fact that the task time is around two times Java's for Skummet is a big thing. Ignoring startup time, and without further data/tests, one could argue that Clojure Android apps run twice as slow as Java ones... that's a big no-go given the high amount of sparkly UI features of most modern apps. Or at least a no-go for having a Clojure-only stack?

(Skummet's probably in its early stages and I'd expect improvements but ... from those graph I'd argue 'Lean Clojure' does not work (yet?))

Re: The state of Clojure on Android

#3

Post by robinricard » Sat, Apr 25, 2015, 11:07 AM UTC

This is a nice, complete and well-documented review of why Clojure is not made for Android.

I disagree with the conclusion though: yeah, the classic JVM-clojure seems doomed on Android. Why ? It's not made for that, it's made for servers, it's not even used for desktop GUI programming that much. Even if we beat the startup time, it's not likely that we'll get nice UI-bindings for Android before a long time (I like the Java-interop but writing serious Android apps with the interop alone seems awful to me) and yes, there are some libraries abstracting this a little bit such as neko [1] but it's still too close to the Java-development paradigms (it's not as clojure-ish as I wish, but that's my opinon!).

So, the conclusion: no we don't need a swift for Android, and clojure is not swift anyway.

iOS already has clojure support, it's not really stable but it has decent startup times and a nice API. It's not the JVM-clojure, it's clojurescript. The UI is managed by React Native and om. It works and you get a nice REPL running too. [2] No it's not finished and has lots of bugs and it's not even publishable on the AppStore for now but it's just a matter of weeks here before addressing those problems (you can follow the work of David Nolen & Mark Fikes on this particularly, they often communicate on what they're doing but there are other awesome people working on this too!)

So for Android ? ReactNative is coming too [3]. When it's there, the community will try the same thing as what they did on iOS, and it's likely to succeed too. The community behind cljs is growing and it's becoming the main clojure implementation for ui-related stuff. You can thank React and om for that but I think that core.async has a lot to do with it too.

Anyway, I don't want to stop believing in Clojure for mobile development.

[1]: https://github.com/clojure-android/neko [2]: https://github.com/omcljs/ambly/wiki/Driving-React-Native-wi... [3]: https://facebook.github.io/react/blog/#when-is-react-native-...

Re: The state of Clojure on Android

#4

Post by hoodunit » Sat, Apr 25, 2015, 12:32 PM UTC

th0br0 wrote: post #2

From a user perspective, I find the statement that "Lean Clojure" works based off these charts a bit daring. Why? a) Without having access to the numbers, (Skummet) startup is ~5 times as slow as the Java version. That is a noticeable difference. Plus, even Java apps sometimes tend to take a second or more to start up if they're reasonably complex. b) The "Lean Clojure works" statement is derived from comparing _only…

To clarify my statement: the idea of lean Clojure for making Clojure viable for Android development basically works. More static compilation of vars dramatically reduced startup times; I think further "lean Clojure" changes like dependency shaking would bring equally dramatic improvements. I'm handwaving a bit here at the challenges involved in making further changes, but the direction seems quite promising, at least for reducing startup times.

General performance is more difficult to speak for. If it is within a factor of two of Java that seems pretty similar to Clojure vs Java on the desktop and is a tradeoff many are willing to make. It's also true that Clojure relies heavily on Java libraries and Android app performance is highly dependent on underlying library and native performance. So basically for run time performance I don't think the performance of Clojure itself is the most significant factor.

Re: The state of Clojure on Android

#5

Post by cp9 » Sat, Apr 25, 2015, 2:43 PM UTC

At clojure/west Zachary Kim had a talk about the state of mobile app dev in clojure [0].

[0]: https://www.youtube.com/watch?v=AgjRo54ImUMa

Re: The state of Clojure on Android

#6

Post by zak_mc_kracken » Sat, Apr 25, 2015, 2:55 PM UTC

robinricard wrote: post #3

This is a nice, complete and well-documented review of why Clojure is not made for Android. I disagree with the conclusion though: yeah, the classic JVM-clojure seems doomed on Android. Why ? It's not made for that, it's made for servers, it's not even used for desktop GUI programming that much. Even if we beat the startup time, it's not likely that we'll get nice UI-bindings for Android before a long time (I like th…

> So, the conclusion: no we don't need a swift for Android,

I think we do, and to me, that language is Kotlin:

Analysis: http://goo.gl/wNjXoU

The language: http://kotlinlang.org

Re: The state of Clojure on Android

#7

Post by j_m_b » Sat, Apr 25, 2015, 3:19 PM UTC

robinricard wrote: post #3

This is a nice, complete and well-documented review of why Clojure is not made for Android. I disagree with the conclusion though: yeah, the classic JVM-clojure seems doomed on Android. Why ? It's not made for that, it's made for servers, it's not even used for desktop GUI programming that much. Even if we beat the startup time, it's not likely that we'll get nice UI-bindings for Android before a long time (I like th…

I've been using Phonegap with Clojurescript on iOS. Perhaps that would be a viable alternative for Android development as well.

Re: The state of Clojure on Android

#8

Post by pjmlp » Sat, Apr 25, 2015, 3:23 PM UTC

robinricard wrote: post #3

This is a nice, complete and well-documented review of why Clojure is not made for Android. I disagree with the conclusion though: yeah, the classic JVM-clojure seems doomed on Android. Why ? It's not made for that, it's made for servers, it's not even used for desktop GUI programming that much. Even if we beat the startup time, it's not likely that we'll get nice UI-bindings for Android before a long time (I like th…

> So, the conclusion: no we don't need a swift for Android, and clojure is not swift anyway.

At very minimum we need Java 8, but I am willing to bet Google IO will not bring any news on that front.

Currently I have been using Java/C++ for my mobile hobby programming as I also like to play around with WP (C++/CX).

Regarding Clojure, maybe a static Lisp with Clojure syntax but with type inference could be a way to tackle the problem.

It wouldn't be pure Clojure, but maybe good enough.

Re: The state of Clojure on Android

#9

Post by th0ma5 » Sat, Apr 25, 2015, 4:02 PM UTC

pjmlp wrote: post #8

robinricard wrote: post #3

This is a nice, complete and well-documented review of why Clojure is not made for Android. I disagree with the conclusion though: yeah, the classic JVM-clojure seems doomed on Android. Why ? It's not made for that, it's made for servers, it's not even used for desktop GUI programming that much. Even if we beat the startup time, it's not likely that we'll get nice UI-bindings for Android before a long time (I like th…

> So, the conclusion: no we don't need a swift for Android, and clojure is not swift anyway. At very minimum we need Java 8, but I am willing to bet Google IO will not bring any news on that front. Currently I have been using Java/C++ for my mobile hobby programming as I also like to play around with WP (C++/CX). Regarding Clojure, maybe a static Lisp with Clojure syntax but with type inference could be a way to tack…

Maybe Pixie-Lang with the NDK. You would have to wrap all the Java GUI calls through their C interface. This sort of messes with my head a little.

Re: The state of Clojure on Android

#10

Post by daniel_solano » Sat, Apr 25, 2015, 4:56 PM UTC

robinricard wrote: post #3

This is a nice, complete and well-documented review of why Clojure is not made for Android. I disagree with the conclusion though: yeah, the classic JVM-clojure seems doomed on Android. Why ? It's not made for that, it's made for servers, it's not even used for desktop GUI programming that much. Even if we beat the startup time, it's not likely that we'll get nice UI-bindings for Android before a long time (I like th…

Just a few thoughts:

1. Clojure is a general purpose programming language. Just because it isn't used much for desktop GUIs doesn't mean it's not usable for that. What percentage of Java/Scala development is used for GUIs?

2. Clojure in iOS isn't just available via ClojureScript. There is also RoboVM, though it doesn't support REPL-driven development, if I understand it correctly.

3. I am very interested in what React Native can do. For me, the key questions about using it are: Can you create applications that fit will into the UX idioms of the host platform? What happens when something goes wrong? Do the various levels of indirection make debugging much more difficult? Do you still have access to the full platform? If not, then only certain classes of applications can be implemented using React Native.