| |||||||||||||
|
| |||||||||||||
Welte: Android Mythbusters (Matt Porter)Welte: Android Mythbusters (Matt Porter)Posted Nov 4, 2009 20:25 UTC (Wed) by ncm (subscriber, #165)Parent article: Welte: Android Mythbusters (Matt Porter)
The Linux user space is no great shakes. Glibc is enormously overcomplicated, and often substituted in embedded ports. Posix Threads are several crossbred abominations, and we'd be better off with simple futures (as indeed we will have, along with the posixy threads, in C++0xA). SysV IPC, I can happily live without, likewise SysV startup scripts. It would be no great error to toss X and start over knowing more than we did then.
The great failure of Android is that it is programmed in Java, a language that never had any objectively defensible reason to exist. Sure, you could say the same about BASIC, or indeed most languages, but none of those justify actually using it.
(Log in to post comments)
Compiled Java Posted Nov 5, 2009 0:12 UTC (Thu) by man_ls (subscriber, #15091) [Link] I'm no expert but I respectfully disagree; Java is a great language -- it's raison d'être was to have "C++ without the warts", and I think it was accomplished beautifully. For example, pointer arithmetics is automatic, garbage collection is automatic too, and buffer overflows are unheard of. (Actually the official motto was "write once, run everywhere", but this other goal failed miserably.)The JVM is a different beast; it is bloated and weird. But Google is not using it; actually they have created a better JVM (register-oriented and less memory-hungry) and target that from their Java code. They could have gone the extra mile and compiled Java, as GCC can do, but interpreted runtimes are still fashionable, apparently. And then there are the runtime libraries, which are sometimes very well done and suck big time others, and are bloated all the time. But most of them can luckily be ignored. Anybody knows if they are using these?
Compiled Java Posted Nov 5, 2009 12:47 UTC (Thu) by jengelh (subscriber, #33263) [Link]
>it's raison d'être was to have "C++ without the warts",
One's warts are another's trademark. In C and C++ you can take the address (or reference, whatever) of an object and pass it around. In Java instead you have to create an extra Integer() class for the same job. So you have done away with the pointer wart in exchange for an overhead wart.
Compiled Java Posted Nov 5, 2009 13:44 UTC (Thu) by skitching (subscriber, #36856) [Link]
Compilers for statically-typed languages can play many tricks; code performance can be very tricky to estimate.
For example, in Java the Integer class is final, ie cannot be subclassed.
Therefore, all method calls made via a reference of type Integer can be inlined.
In addition, if the compiler can determine that the integer's lifetime does not extend beyond the function in which it is created (ie in which "new" is called), then the data can be allocated on the stack.
And if the compiler can determine that an Integer is never cast to a parent type (Number or Object), then no Object instance needs to be created, ie just 4 bytes for the data are needed, like in c.
So it can be possible for a good java compiler to create identical code for java or c++ in many cases.
As always,
There are many things about the Java syntax that annoy me, but the fact that java code can never overwrite memory it does not own is a very powerful thing.
Compiled Java Posted Nov 6, 2009 22:48 UTC (Fri) by bcopeland (subscriber, #51750) [Link] So it can be possible for a good java compiler to create identical code for java or c++ in many cases.Unfortunately even Sun can't make a good java compiler :)
Compiled Java Posted Nov 5, 2009 18:21 UTC (Thu) by khc (subscriber, #45209) [Link]
usually you want to pass primitive types by reference because your function needs to modify it. In Java, Integer is immutable so you can't use Integer to substitute for int in that case anyway.
Compiled Java Posted Nov 5, 2009 20:59 UTC (Thu) by man_ls (subscriber, #15091) [Link] As another commenter already said, creating an Integer() would not work. The reason you cannot pass a reference to an int so that it is modified by the function is that you are not expected to do that. And the solution is not to create a class with just an integer attribute and pass that -- the real solution is to not pass integers, but objects with behaviors. Integers are best kept as attributes of objects and handled within those objects. If you really have to change just an int it's best to have the method return a new int. Keeps your code simpler and reduces side effects -- and performance is just as good.This kind of policy may force you to make things a different way, but it is a perfectly valid way -- it's idiomatic Java if you wish. Now, there are some idiotic policies in Java (like getters and setters, what a waste of time) but keeping methods from modifying their (primitive) parameters seems like a good design choice to me.
Compiled Java Posted Nov 6, 2009 1:13 UTC (Fri) by alankila (subscriber, #47141) [Link]
In fairness, in many cases an inner class, anonymous or not, can be used. The inner class has access to the containing class's scope, and can thus be passed to wherever you want and the methods in that interface will then be able to modify the members of the containing class. This is pretty nice technique as it gets you something that feels like closures.
In a rare occasion someone might use a kludge like pass a new int[1] { value } so that the array's first element can be adjusted by the called code. Tricks like 1-element arrays are also sometimes used in Python, to circumvent Python's way of determining the scope of a variable from a first assignment in a block.
Welte: Android Mythbusters (Matt Porter) Posted Nov 5, 2009 0:23 UTC (Thu) by dvdeug (subscriber, #10998) [Link]
You can't objectively defend creating BASIC as an alternative to JOSS, LISP, FORTRAN II (not IV, not 77, II) or Algol 60?
Welte: Android Mythbusters (Matt Porter) Posted Nov 5, 2009 12:42 UTC (Thu) by pboddie (guest, #50784) [Link]
I didn't think that glibc was the only choice for Embedded Linux - indeed, I thought that there was a range of fairly mature options at that level. All this reinvention on Google's part suggests that they either want to own as much of the technology stack as possible, that they indulge various internal developers too much, or that they're needlessly scared of the licensing of code where even the FSF will tell you that there are few if any licensing obligations when linking to such libraries:
Welte: Android Mythbusters (Matt Porter) Posted Nov 5, 2009 23:52 UTC (Thu) by jgg (guest, #55211) [Link]
IMHO, android's libc is probably the best next option to glibc. The other choices leave alot to be desired, and are fairly disused these days.
Indulging internal developers is quite an interesting point.. Who ever created some of this stuff is really good. There are not many people in the world who could sit down and write a new ELF dynamic loader, libc and related toolchain goop - let alone start out that way and not be afraid of failing. This is arcane stuff.
I'd be quite interested to know how long it took to make, IMHO, a super expert, done this before, kind of thing, could probably knock it out in a month. You'd probably burn more time than that just fussing with glibc to make it smaller.
Welte: Android Mythbusters (Matt Porter) Posted Nov 6, 2009 13:35 UTC (Fri) by nix (subscriber, #2304) [Link]
uClibc is 'fairly disused'? Not in my embedded world :)
(oh, and most of this stuff is dull and fiddly but not *hard*. At least
Welte: Android Mythbusters (Matt Porter) Posted Nov 6, 2009 13:40 UTC (Fri) by pboddie (guest, #50784) [Link]
Can you comment on dietlibc, newlib and uClibc? I wasn't aware that these were particularly deficient, although I'm sure that there are good reasons for not choosing them in certain situations.
Welte: Android Mythbusters (Matt Porter) Posted Nov 6, 2009 17:04 UTC (Fri) by trasz (guest, #45786) [Link]
For some reason you assume that FSF lawyers know GPL better than Google lawyers. This is obviously wrong (Google simply can pay their lawyers better and get better ones), so your conclusion about Google's assumptions about effects and consequences of GPL is wrong.
Welte: Android Mythbusters (Matt Porter) Posted Nov 6, 2009 17:28 UTC (Fri) by pboddie (guest, #50784) [Link]
I might have known you'd have something to "add" to this discussion, but my point was that if some project has released code under the GPL (or even the LGPL), then there are several limitations in place, widely accepted even by Google (who have released proprietary software for GNU/Linux), that prevent any effect on the licensing of programs which interact with such code. Even the FSF acknowledge these limitations, which is what the link I provided refers to.
Given that your analysis of my conclusion is based on peripheral matters and not on any reasonable attempt to understand either the licence texts or the clarifications written by the people who wrote the licence texts (and that, in any case, the lawyers of various other corporations are presumably better paid than those working for the FSF, yet those lawyers have had to comply with the GPL when challenged), I'd be more careful liberally pointing the finger and using the word "wrong" if I were you.
Welte: Android Mythbusters (Matt Porter) Posted Nov 6, 2009 22:10 UTC (Fri) by trasz (guest, #45786) [Link]
I was replying to the claim that Google is _needlessly_ scared about the GPL license. There is no reason to assume their knowledge of the GPL license is in any way worse than the FSFs.
Welte: Android Mythbusters (Matt Porter) Posted Nov 9, 2009 12:51 UTC (Mon) by pboddie (guest, #50784) [Link]
Well, they can be "needlessly scared" on behalf of their telecoms partners, who tend to be needlessly scared about a bunch of stuff, albeit stuff which is often of their own making.
Google's "LGPL violation fly-by" involving ffmpeg and the redistribution of works under exclusive patent agreements might sit well within Google (and show that their lawyers think they know where the loopholes might be, albeit ones that have been closed in later versions of the licences concerned), but their partners might back off at the prospect of doing similar things with products that have their name on it.
|
|
||||||||||||