The problem arises when idiots^H^H^H^H^H^H users install some trojan and then expect Apple to fix it and then bad mouth the company when they refuse to deal with it or for having bad security. The problem with a design approach that dumbs things down as much as possible so that any fool can use it is that any fool will use it.
Honest question to which I don't knownthe answer: is this a significant problem for Android device manufacturers?
Anyway, if your API is C, it is obviously not object oriented.
Which means an even lower impedance mismatch when trying to use it with a language which has a different object model, as anyone who has mixed C++ and Obj-C can tell you.
LLVM features a hand-curated C binding for precisely this reason.
why the funk would I drive a Beatle when i can choose between a jaguar E-Type and a Porsche instead?
A VW Beetle gets twice the mileage of an E type, and probably costs a shitload less to insure and maintain, too. It can't go as fast but you're bound by speed limits most of the time anyway.
Software isn't the only business where people use more expensive solutions just because they look cooler.
Has Apple had any platform exclusive games in the last 2 decades?
On iOS, yes.
I figured they went with OpenGL because at least that way they would get in on the cross-platform games and only lose out on the DirectX games.
They supported OpenGL because that's what all the "workstation" applications wanted. They probably haven't rushed to support OpenGL 4 because Adobe and Autodesk and Avid don't strictly need it.
That's kind of my point. Objects are abstractions, designed to keep you separated from data. Most of the time, that aspect confuses more than it helps.
I think you may be misunderstanding the issue in Java's case.
Objects live on the heap, with no exceptions. If a field of an object is an object, you do not store an object there, you store a heap reference.
So any field which isn't a basic type is not plain old data. It is a heap reference, i.e. a pointer. You cannot directly serialise and deserialise pointers; you need to swizzle and unswizzle them.
It's not conceptually difficult, it's not magic, but it's not as simple as plain old data.
The whole point of Big Data is finding connections that humans wouldn't have noticed.
Finding connections to justify future scruitiny is one thing, but making a decision about someone's future based on connections alone is not.
The number of storks nesting on Danish houses is (famously) positively correlated with the number of children who live in those houses. You could imagine an algorithm which discovered this connection adjusting a family's health insurance risk by counting the number of storks on their roof. A moment's thought reveals that, despite what you've been told, storks don't cause children, but rather larger families tend to have bigger houses with more roof space.
Data is informative, but there is no substitute for human judgment when decisions must be made about people's lives.
When you persist an object all you are doing is writing its data to storage.
This is accurate if and only if the object is what C++ calls "plain old data" (which I assume, or at least hope, Java records will have statically-analysed support for).
Java to its credit does not think that everything is an object. Nonetheless, everything user-defined is an object. When yoir language thinks that most things are objects, then very few things are plain old data.
As soon as you have members that are themselves objects, It is no longer "an object" that you are serializing, it is multiple objects. And all objects are passed and stored by reference in Java so now you must deal with DAGs and cyclic references otherwise you might get in an infinite loop or break object identity semantics.
Consider a Java object with two strings in it. Java serialization needs to ensure that if they are the same string (in the sense of being the same object as opposed to different objects containing the same data) that information survives a round trip, otherwise Java's object identity semantics are broken.
I'm ignoring a bunch of complications about Java serialization such as versioning and its interaction with reflection (you can store object metadata in an object) because you can detect these cases easily and special-case or disallow them.
Slashdot Mirror
But when it comes to making good beer in _industrial_ quantities, the Germans own it.
Best backhanded compliment of the day.
I used to use Google Listen, and I'm not making that mistake again. I'm happy with DoggCatcher.
Oh, wait, I read that original claim completely backwards. Sorry, my bad.
Just for the record, I was specifically responding to the "why don't you write your own apps" complaint.
Not worldwide, they don't.
The problem arises when idiots^H^H^H^H^H^H users install some trojan and then expect Apple to fix it and then bad mouth the company when they refuse to deal with it or for having bad security. The problem with a design approach that dumbs things down as much as possible so that any fool can use it is that any fool will use it.
Honest question to which I don't knownthe answer: is this a significant problem for Android device manufacturers?
why don't they simply write their own apps?
Isn't part of the point of FOSS and open platforms that we can do precisely that without having to reinvent the wheel from scratch?
Besides, I'm theoretically adroit enough to know that checking a solution is probably in a lower complexity class than crafting a solution.
That would be the same place you get self-published console games, I presume?
True, although not all POTUSes survived either.
Only three people have been to the bottom of the Mariana Trench.
Just picking a nit here, we had steel and concrete 2000 years ago.
That was not the point, or was it?
That was my point. A C API is more reusable.
Anyway, if your API is C, it is obviously not object oriented.
Which means an even lower impedance mismatch when trying to use it with a language which has a different object model, as anyone who has mixed C++ and Obj-C can tell you.
LLVM features a hand-curated C binding for precisely this reason.
Find me a C++ library that can be called from Java directly without wrapping it in a layer of C.
Most languages with a foreign function interface can call C natively. Fewer can call C++ natively.
The car analogy was about speed, which was obvious.
And in this case: speed of development.
My response, in case it wasn't obvious, is that everything in this business is a tradeoff.
Yes, even C vs C++; a library with a C API is always more useful than one with a C++ API.
why the funk would I drive a Beatle when i can choose between a jaguar E-Type and a Porsche instead?
A VW Beetle gets twice the mileage of an E type, and probably costs a shitload less to insure and maintain, too. It can't go as fast but you're bound by speed limits most of the time anyway.
Software isn't the only business where people use more expensive solutions just because they look cooler.
In many ways pigs are flying.
Better than chairs I suppose.
What a bunch of wieners...
They're called "snags", mate.
Wait, what? iPhones are going to come with a USB port?
Nonsense! Solo will never be profitable because neither were most of the original trilogy.
Has Apple had any platform exclusive games in the last 2 decades?
On iOS, yes.
I figured they went with OpenGL because at least that way they would get in on the cross-platform games and only lose out on the DirectX games.
They supported OpenGL because that's what all the "workstation" applications wanted. They probably haven't rushed to support OpenGL 4 because Adobe and Autodesk and Avid don't strictly need it.
Well they tried Beta, but everyone hated it.
That's kind of my point. Objects are abstractions, designed to keep you separated from data. Most of the time, that aspect confuses more than it helps.
I think you may be misunderstanding the issue in Java's case.
Objects live on the heap, with no exceptions. If a field of an object is an object, you do not store an object there, you store a heap reference.
So any field which isn't a basic type is not plain old data. It is a heap reference, i.e. a pointer. You cannot directly serialise and deserialise pointers; you need to swizzle and unswizzle them.
It's not conceptually difficult, it's not magic, but it's not as simple as plain old data.
The whole point of Big Data is finding connections that humans wouldn't have noticed.
Finding connections to justify future scruitiny is one thing, but making a decision about someone's future based on connections alone is not.
The number of storks nesting on Danish houses is (famously) positively correlated with the number of children who live in those houses. You could imagine an algorithm which discovered this connection adjusting a family's health insurance risk by counting the number of storks on their roof. A moment's thought reveals that, despite what you've been told, storks don't cause children, but rather larger families tend to have bigger houses with more roof space.
Data is informative, but there is no substitute for human judgment when decisions must be made about people's lives.
When you persist an object all you are doing is writing its data to storage.
This is accurate if and only if the object is what C++ calls "plain old data" (which I assume, or at least hope, Java records will have statically-analysed support for).
Java to its credit does not think that everything is an object. Nonetheless, everything user-defined is an object. When yoir language thinks that most things are objects, then very few things are plain old data.
As soon as you have members that are themselves objects, It is no longer "an object" that you are serializing, it is multiple objects. And all objects are passed and stored by reference in Java so now you must deal with DAGs and cyclic references otherwise you might get in an infinite loop or break object identity semantics.
Consider a Java object with two strings in it. Java serialization needs to ensure that if they are the same string (in the sense of being the same object as opposed to different objects containing the same data) that information survives a round trip, otherwise Java's object identity semantics are broken.
I'm ignoring a bunch of complications about Java serialization such as versioning and its interaction with reflection (you can store object metadata in an object) because you can detect these cases easily and special-case or disallow them.