6 ms·
In the long run, having a more modern language should benefit Android because it means the barrier of entry is lower for programmers. In the meantime it does s
by bluerobotcat 13y ago
In the long run, having a more modern language should benefit Android because it means the barrier of entry is lower for programmers.
In the meantime it does seem likely that Java has a non-negligible performance cost. My personal worry is that fast Garbage Collectors usually assume that twice the memory is available than is used. That might put the fact that Android phones typically have more memory than Apple devices in an interesting light.
- rsynnott 13y ago_Is_ Java significantly more 'modern', than Objective C, though? How? It's not like it's much newer; development started in 1991, vs early 80s for ObjC.
- pjmlp 13y ago- GC - namespaces - memory safe - you don't have to type @ and [] everywhere to switch between dynamic and static worlds As for the vm thing, there are also commercial native compilers, even though the general HNer tend not to be aware of them.
- rsynnott 13y ago> GC Thus giving Android developers all the fun of dealing with GC pauses. There's a lot to be said for ARC, really; I'm quit glad Apple ditched their brief experiment with ObjC GC. > namespaces I'll give you that one; lack of namespaces it the worst thing about ObjC. > ... Dynamic and static worlds... I'm not sure what you mean here; Java is a statically typed language, and does not have a 'dynamic world'. ObjC has a fo of optional dynamic typing, which is arguably modern, though also only arguably a good thing.
- pjmlp 13y ago> I'm quit glad Apple ditched their brief experiment with ObjC GC. Because they failed to implement a GC that didn't crash all the time, as the Apple forums used to testify before ARC was touted as the best thing since sliced bread. The wonders of mixing Objective-C libraries compiled in mixed mode. > I'm not sure what you mean here; The mixed nature of Objective-C. With @ and [] one is in Smalltalk land. Without them, one is in C world. > Java is a statically typed language, and does not have a 'dynamic world'. Yes it has, via reflection, annotations and dynamic bytecode generation.
- msbarnett 13y ago> With @ and [] one is in Smalltalk land. Without them, one is in C world. This is an odd and not particularly true way of looking at things. [] (for message sending), is merely some syntactic sugar for the objc_msgsnd function call.
- pjmlp 13y agoWhich could have been implemented in a better way, e.g. Dylan does dynamic dispatch with multi-methods without requiring me to type [] everywhere. A real pain in non US keyboards.
- rat87 13y agoAlso Dynamic casts(w/exceptions) and virtual methods/Dynamic dispatch which do provide some dynamicity not easy/natural in c.
- mikeash 13y agoYour first three points are good, but are you seriously suggesting that Java is "more modern" because its method call syntax uses a dot instead of brackets?
- pjmlp 13y agoYes, because [] was a pre-processor hack back when Objective-C was invented and the compiler was actually a translator to C. A means of gathering the code, dump it into a series of objc_msgsnd, without doing much of real compiler work. There are languages with Smalltalk semantics without forcing me to type @ and [] multiple times per line, a pain in non US keyboards.
- antimagic 13y agoSeriously? And all of those {} that you type in Java-land, they're magically easy to type? Which is of course a red-herring, because neither is enough of a drama to be taken seriously. You deal with it for a day or two and then forget about it.
- mikeash 13y agoWhat kind of code are you writing where you have to type @ multiple times per line?
- pjmlp 13y agoid map = @{ @"my key": @123};
- mikeash 13y agoSurely you're not doing that anywhere close to every line.
- rsynnott 13y agoOf course, in Java, this would look like (at best, using a third party thing): ImmutableMap.builder().put("my key", 123).build(); Which hardly seems neater (especially in a more realistic case where you have more than one entry).
- pkolaczk 13y agoI found two problems with your reasoning: First, the overhead of GC depends not only on the heap size, but also on the allocation rate and allocation profile. For reasonable allocation rates found in typical GUI apps, most Java GCs do extremely well having very little additional memory, like only 20% more than the live set size. There is no "twice as much" assumption anywhere in their design. Second, manual memory managers do have their own overhead too, in form of bookkeeping (e.g. free lists) and internal fragmentation. Fragmentation can be sometimes much worse than GC memory overhead for long running applications, because GC memory overhead is typically bounded, while fragmentation is either unbounded or has extremely high upper bounds (like 10x in "fast" allocators).
- munificent 13y ago> There is no "twice as much" assumption anywhere in their design. There is in that the nursery collector is often a simple Cheney-style copying collector that wants two semispaces. But that's only one of the generations. There's definitely no requirement that total GC memory is double the used space.
- pjmlp 13y agoThe main issue is the quality of Google's implementation, don't generalize the language vs implementation. Apparently they haven't done any changes since JIT was introduced in 2.3 version. Additionally we have ART without any information whatsoever about future plans.