4 ms·

Dalvik is all that is wrong with android. If they removed Dalvik, the app store for android would suddenly go from zero to hero. I don't understand why google

by openfly 16y ago

Dalvik is all that is wrong with android. If they removed Dalvik, the app store for android would suddenly go from zero to hero. I don't understand why google made such a horrendous and really obvious mistake in using dalvik. It doesn't make any sense at all.

glhaynes 16y ago
What's wrong with it? Are you saying that because if they had a more standard JVM they could run all those "great" J2ME apps? No thanks.
- noss 16y ago
  A problem with the JVM that is that handsets would need to license the JVM bytecode technology from Sun (Oracle), if I understood things correctly. So dalvik works around that licensing fee. Otherwise I am pretty sure that there will be a lot of "great" android apps to be ironic about as well.
andybak 16y ago
A bit more substance to your complaint would be great. What are you arguing for? A normal JVM? Native code? A WebOS style environment? There are trade-offs to all decisions. Dalvik performance has been tolerable and now it looks like it has progressed to being quite reasonable. I'm just waiting for a chance to use a nicer language to produce Dalvik byte-code. I don't think it's very friendly to dynamic languages but I'd settle for almost anything other than Java.
- tumult 16y ago
  It's not unfriendly to dynamic languages, but it's unfriendly to things which allocate and deallocate frequently. The JVM is actually pretty ok at this (Clojure for example), my understanding is that JVM can deal with short-lived heap objects decently, whereas Dalvik is very slow for anything other than the stack.
  - bad_user 16y ago
    In a dynamic language you allocate/deallocate stuff more frequently, especially considering how classes/functions can and are getting changed at runtime. Also if you want late binding you have to generate stuff on the fly (like having call-site caches) if you want a decent performance. From what I understand Dalvik is also slower for anything involving java.lang.reflect. So Dalvik is kind of unfriendly to dynamic languages for now. That's OK ... I wish there was some alternative to Java. Scala sucks IMHO.
    - tumult 16y ago
      You're wrong. I can write Lua, Python or Ruby code that does little allocation and would perform well (in a relative sense) on Dalvik. Those are all dynamic. I could not write Haskell or OCaml code that performs well on Dalvik, because of their allocation profiles. A language being dynamic does not have much to do with its allocation profile. Haskell and OCaml are not dynamic languages, but have allocation and deallocation profiles that grossly outstrip what you would see in typical Python or Ruby code. Scala allocates most things on the heap and is probably unsuitable for use on Dalvik. What is your complain about Scala as a language?
      - bad_user 16y ago
        > I can write Lua, Python or Ruby code that does little allocation and would perform well (in a relative sense) on Dalvik. Those are all dynamic. You MISS the point ... because everything can change, the semantics are different. A class can change ... first it needs to be garbage-collectible, with one way to do it being for every class to be loaded by a different class loader. Then the methods themselves can change, so in JRuby every method on a class has a corresponding method handler (another class at the VM level). Even if you write code that doesn't do much, you're programming in Python, not RPython, or in Ruby, not in Duby. You may use a subset of the language, but the interpreter has to be prepared for everything. I have been following the developments in the JRuby project, and I sincerely doubt that you can write efficient Ruby code on top of Dalvik ;) > A language being dynamic does not have much to do with its allocation profile. Again you miss the point ... it does have to do with its allocation profile if you're doing shit that doesn't match the JVM type system. And yeah ... Haskell and Ocaml both have type-systems much more different than those of Ruby/Python. > Scala allocates most things on the heap and is probably unsuitable for use on Dalvik So do JRuby or Jython ... AFAIK they don't do tracing compiling, and the JVM doesn't do custom stack-allocated values ... again, hard to match the JVM type system. On the other hand, Scala uses Java's call semantics, so the generated bytecode is efficient because for runtime-dispatch it follows Java's rules. In a language like Ruby or Python with its own rules about what to call, you need techniques like call-site caching implemented by the language author ... see http://en.wikipedia.org/wiki/Inline_caching http://en.wikipedia.org/wiki/Inline_caching ... one issue meant to be solved by InvokeDynamic (whenever Java7 ships). > What is your complain about Scala as a language? Too many features thrown in there, some non-orthogonal, just to please the JVM ... and I'm tired of languages with a complex syntax that don't provide a way for library authors to hook in the compiler's pipeline ... you get the worst of both worlds (unreadable code / not capable enough). I just want a syntax tree from some expression, which would enable me to work/use something like LINQ, or adding to it new syntax when you need it (have a look at Perl's MooseX to see what that can do). Is that so hard, especially for a language that comes with tons of other features, some of them improperly implemented? (IMHO, type-erased generics in a runtime-dispatch language are totally useless / thrown in there only to have local type inference ... and those manifests are just an ugly hack). But I already said, it's my opinion ;)
- davidw 16y ago
  Hecl works fine on Android.
  - andybak 16y ago
    Is it in active development? A quick google doesn't find anything newer than a few years old.
    - davidw 16y ago
      Yes, it is. I'm kind of hoping I can get a phone (Google guys: hint hint!) to really get into it though.
- indy 16y ago
  Duby (http://github.com/technomancy/ohai-android http://github.com/technomancy/ohai-android) seems to be showing a lot of promise
openfly 16y ago
Well what's wrong with it is it's a VM. This is an embedded device with limited resources. Using a VM is a fundamentally bad idea. You can try to convince yourself that this isn't the case, but it is. What's worse is this has led to google's team developing the SDK around Java. Which alienates most of the worlds best programmers. And I am not saying you can't use dlavik if you want. By all means if you want to use a VM that's fine. But if developers want to do awesome things with the android taking advantage of the device fully, the way to do that quickly, easily, and painlessly for the devs is to open up native development. As it is, the SDK is horrendous to work with. The eclipse integration sucks, the exposed pieces of the os and it's hardware resources while getting better is still pretty bad. Fixing things like media playback issues is impossible. I could add ogg support tomorrow with native code, and it would run faster eating less battery than what they currently have for mp3 playback. But now that can't happen unless I jailbreak. I can't push useful apps on the app store. I want to write apps for my android, but with the SDK the way it is now... it would be a waste of my time to do so. And that's the point.

by openfly 16y ago

glhaynes 16y ago

What's wrong with it? Are you saying that because if they had a more standard JVM they could run all those "great" J2ME apps? No thanks.

noss 16y ago
A problem with the JVM that is that handsets would need to license the JVM bytecode technology from Sun (Oracle), if I understood things correctly. So dalvik works around that licensing fee. Otherwise I am pretty sure that there will be a lot of "great" android apps to be ironic about as well.

andybak 16y ago

A bit more substance to your complaint would be great. What are you arguing for? A normal JVM? Native code? A WebOS style environment? There are trade-offs to all decisions. Dalvik performance has been tolerable and now it looks like it has progressed to being quite reasonable. I'm just waiting for a chance to use a nicer language to produce Dalvik byte-code. I don't think it's very friendly to dynamic languages but I'd settle for almost anything other than Java.

tumult 16y ago
It's not unfriendly to dynamic languages, but it's unfriendly to things which allocate and deallocate frequently. The JVM is actually pretty ok at this (Clojure for example), my understanding is that JVM can deal with short-lived heap objects decently, whereas Dalvik is very slow for anything other than the stack.
- bad_user 16y ago
  In a dynamic language you allocate/deallocate stuff more frequently, especially considering how classes/functions can and are getting changed at runtime. Also if you want late binding you have to generate stuff on the fly (like having call-site caches) if you want a decent performance. From what I understand Dalvik is also slower for anything involving java.lang.reflect. So Dalvik is kind of unfriendly to dynamic languages for now. That's OK ... I wish there was some alternative to Java. Scala sucks IMHO.
  - tumult 16y ago
    You're wrong. I can write Lua, Python or Ruby code that does little allocation and would perform well (in a relative sense) on Dalvik. Those are all dynamic. I could not write Haskell or OCaml code that performs well on Dalvik, because of their allocation profiles. A language being dynamic does not have much to do with its allocation profile. Haskell and OCaml are not dynamic languages, but have allocation and deallocation profiles that grossly outstrip what you would see in typical Python or Ruby code. Scala allocates most things on the heap and is probably unsuitable for use on Dalvik. What is your complain about Scala as a language?
    - bad_user 16y ago
      > I can write Lua, Python or Ruby code that does little allocation and would perform well (in a relative sense) on Dalvik. Those are all dynamic. You MISS the point ... because everything can change, the semantics are different. A class can change ... first it needs to be garbage-collectible, with one way to do it being for every class to be loaded by a different class loader. Then the methods themselves can change, so in JRuby every method on a class has a corresponding method handler (another class at the VM level). Even if you write code that doesn't do much, you're programming in Python, not RPython, or in Ruby, not in Duby. You may use a subset of the language, but the interpreter has to be prepared for everything. I have been following the developments in the JRuby project, and I sincerely doubt that you can write efficient Ruby code on top of Dalvik ;) > A language being dynamic does not have much to do with its allocation profile. Again you miss the point ... it does have to do with its allocation profile if you're doing shit that doesn't match the JVM type system. And yeah ... Haskell and Ocaml both have type-systems much more different than those of Ruby/Python. > Scala allocates most things on the heap and is probably unsuitable for use on Dalvik So do JRuby or Jython ... AFAIK they don't do tracing compiling, and the JVM doesn't do custom stack-allocated values ... again, hard to match the JVM type system. On the other hand, Scala uses Java's call semantics, so the generated bytecode is efficient because for runtime-dispatch it follows Java's rules. In a language like Ruby or Python with its own rules about what to call, you need techniques like call-site caching implemented by the language author ... see http://en.wikipedia.org/wiki/Inline_caching http://en.wikipedia.org/wiki/Inline_caching ... one issue meant to be solved by InvokeDynamic (whenever Java7 ships). > What is your complain about Scala as a language? Too many features thrown in there, some non-orthogonal, just to please the JVM ... and I'm tired of languages with a complex syntax that don't provide a way for library authors to hook in the compiler's pipeline ... you get the worst of both worlds (unreadable code / not capable enough). I just want a syntax tree from some expression, which would enable me to work/use something like LINQ, or adding to it new syntax when you need it (have a look at Perl's MooseX to see what that can do). Is that so hard, especially for a language that comes with tons of other features, some of them improperly implemented? (IMHO, type-erased generics in a runtime-dispatch language are totally useless / thrown in there only to have local type inference ... and those manifests are just an ugly hack). But I already said, it's my opinion ;)
davidw 16y ago
Hecl works fine on Android.
- andybak 16y ago
  Is it in active development? A quick google doesn't find anything newer than a few years old.
  - davidw 16y ago
    Yes, it is. I'm kind of hoping I can get a phone (Google guys: hint hint!) to really get into it though.
indy 16y ago
Duby (http://github.com/technomancy/ohai-android http://github.com/technomancy/ohai-android) seems to be showing a lot of promise

openfly 16y ago

Well what's wrong with it is it's a VM. This is an embedded device with limited resources. Using a VM is a fundamentally bad idea. You can try to convince yourself that this isn't the case, but it is. What's worse is this has led to google's team developing the SDK around Java. Which alienates most of the worlds best programmers. And I am not saying you can't use dlavik if you want. By all means if you want to use a VM that's fine. But if developers want to do awesome things with the android taking advantage of the device fully, the way to do that quickly, easily, and painlessly for the devs is to open up native development. As it is, the SDK is horrendous to work with. The eclipse integration sucks, the exposed pieces of the os and it's hardware resources while getting better is still pretty bad. Fixing things like media playback issues is impossible. I could add ogg support tomorrow with native code, and it would run faster eating less battery than what they currently have for mp3 playback. But now that can't happen unless I jailbreak. I can't push useful apps on the app store. I want to write apps for my android, but with the SDK the way it is now... it would be a waste of my time to do so. And that's the point.