I disagree. If money is no concern, Fendt offers a more advanced tractor in the same price range as a Deere. If you are budget consious a CIH/New Holland or Massey will get you more tractor for your buck.
IP connections will eventually timeout. If you want to be able to receive push notifications, you have to send a heartbeat message every once in a while to ensure that the connection is still alive. You can turn off push notifications if you prefer not to send anything to Apple.
Voice service is only a side effect of iPhone ownership because the carriers do not offer data-only plans. I'm not sure anyone buys an iPhone because they want a phone.
Sounds like my bank. They require that passwords be limited to 0-9. Except the passwords are only validated client-side. Disabling the check allows one to set a more secure password with any character you wish. Given that it is not a limitation of the system, I cannot figure out why they would impose the restriction on anyone, especially in a context where security is essential.
If you actually have a truck that only gets 10MPG it either very, very old, or puts out an incredible amount of power. The 5.3L pickup we had around the farm almost 20 years ago managed 25MPG with ease. For someone to be still using a truck that achieves only 10MPG today, I see two cases:
It is old, but rarely used. 10MPG doesn't mean much in terms of fuel consumption much when you only go a few miles each year.
It is powerful and it is unlikely that a more efficient engine will fit your requirements given what is available on the market today.
The 10MPG vehicle, for the average person, will burn $4,000 in a year. The 20MPG vehicle, for the average person, will burn $2,000 in a year. The $2,000 difference makes justifying the upgrade difficult for the sake of fuel milage alone.
It didn't claim it was overloading, only that it achieves the same effect. My question still stands: How can you implement overloading when the compiler can never truely know what type of object is being passed? Moving my switch statement to objc_msgSend doesn't gain you much.
Argue that the syntax sucks all you want, but the functionality is still there. If it looks like a duck and it quacks like a duck, it must be a duck.
I am actually quite curious how you propose one might cleanly implement true operator overloading and duck typing at the same time. What if my object is a cow, but I want to pass it to the chicken overload?
all the calls to methods as well as accesses to class properties are interpreted
That is the feature, along with dynamic typing, that makes Objective-C a perfect match for interface programming. Being able to load classes and call methods from string identifiers reduces the amount of code needed considerably when compared to languages that use early binding. Have fun re-implementing something like KVC/KVO in C++.
Objective-C's problems stem from the fact that it must be able to compile all valid C code. This severely limits the syntax available. Ruby is essentially Objective-C without the C syntax, if you are curious about the difference syntax makes.
There is work underway to replace Javascript with a byte-code interpreter within the browser. Meaning you can write your code that is executed by the browser in any language that can compile to the byte-code language.
After that, you remove the HTML and CSS components from the browser and you are left with a virtual machine capable of executing the aforementioned executables over the network, like how Javascript is executed today.
If you need to render HTML and CSS, you can link to someone's HTML renderer provided in a browser executable format which is then downloaded over the network at runtime. No longer are you restricted to using the renderer of your browser. If your application is better suited to run without HTML dependance, you can do that too.
Cocoa is also available virtually everywhere, including the web browser itself. While not all implementations of Cocoa are open source, it is based on an open standard (OpenStep) meaning that anyone can write their own implementation.
I do agree with your underlying sentiment. The web browser should provide a virtual machine enabling developers to write their software in any language and framework they see fit. An HTML renderer could be just one of the many applications available to the browser.
I once visited a brewpub that had a 16% beer on tap, among others. The 16% beer was, to my taste buds, the most enjoyable drink of them all. To be honest, was I was actually quite surprised that it could taste so good. Strong alcohol content beers can taste horrible, but they do not have to taste horrible.
Sure, the iPhone is capable of routing like any other computer, but the iPhone doesn't route tethered IP transmissions. It opens a tunnel to the provider's network, which then facilitates any necessary routing. Interestingly, at least with my provider, tethered computers do not even end up on the same network as the phone.
All of the iPhone OS devices, except the first gen. iPod touch, have microphone inputs. If you want to get technical, even the first gen. iPod touch supported microphone input through a third party extension. iPhone OS devices without a camera still allow in-app access to photograph data through the Library. The lack of certain hardware only limits what the user can do, it does not prevent the user from using the application outright unless the developer also chooses to limit who can use the app.
I have never made an argument about Android fragmentation. If I can write a general information-centric application that will run on all Android-based smartphones, tablets, in-car computers, etc. there is no fragmentation and all of the devices should be counted towards Android sales.
With that said, from what I understand, you often cannot guarantee that your Android app will be able to use even basic system features. That does sound like a real problem.
Because it proves (again) that Adobe can bring Flash to the iPhone/iPad without breaking agreements with Apple. It shows that Adobe would rather cry about the situation instead of actually supporting the product they claim to stand behind.
That is really all OOP is at its basic level. OOP languages add syntax sugar to make accessing objects more convenient, but you most certainly can write object oriented C. You can even implement inheritance and all those other cool OOP features in plain old C. C++ was originally written as a preprocessor that converted C++ code to C before compilation.
Slashdot Mirror
I disagree. If money is no concern, Fendt offers a more advanced tractor in the same price range as a Deere. If you are budget consious a CIH/New Holland or Massey will get you more tractor for your buck.
IP connections will eventually timeout. If you want to be able to receive push notifications, you have to send a heartbeat message every once in a while to ensure that the connection is still alive. You can turn off push notifications if you prefer not to send anything to Apple.
Voice service is only a side effect of iPhone ownership because the carriers do not offer data-only plans. I'm not sure anyone buys an iPhone because they want a phone.
Sounds like my bank. They require that passwords be limited to 0-9. Except the passwords are only validated client-side. Disabling the check allows one to set a more secure password with any character you wish. Given that it is not a limitation of the system, I cannot figure out why they would impose the restriction on anyone, especially in a context where security is essential.
The funny thing is that Twitter did exactly what the parent suggested. They prototyped it in Ruby and then rewrote it in Java (Scala).
Apple uses the work of the project extensively in Xcode for OS X/iOS development. You might not have heard of it, but a lot of people have used it.
If you actually have a truck that only gets 10MPG it either very, very old, or puts out an incredible amount of power. The 5.3L pickup we had around the farm almost 20 years ago managed 25MPG with ease. For someone to be still using a truck that achieves only 10MPG today, I see two cases:
The 10MPG vehicle, for the average person, will burn $4,000 in a year. The 20MPG vehicle, for the average person, will burn $2,000 in a year. The $2,000 difference makes justifying the upgrade difficult for the sake of fuel milage alone.
Speaking of Google, I estimate that they own me similar amounts of money for providing links to my copyrighted material based on user searches.
I mean really, what's the difference between providing a search service and browser for music vs. providing a search service and browser for websites?
It didn't claim it was overloading, only that it achieves the same effect. My question still stands: How can you implement overloading when the compiler can never truely know what type of object is being passed? Moving my switch statement to objc_msgSend doesn't gain you much.
- (NSString *)methodWhichAcceptsAnyTypeOfObject:(id)object
{
if ([object isKindOfClass:[NSString class]]) {
return object;
} else if ([object isKindOfClass:[NSArray class]]) {
return [object componentsJoinedByString:@" "];
} else {
return nil;
}
}
Argue that the syntax sucks all you want, but the functionality is still there. If it looks like a duck and it quacks like a duck, it must be a duck.
I am actually quite curious how you propose one might cleanly implement true operator overloading and duck typing at the same time. What if my object is a cow, but I want to pass it to the chicken overload?
That is the feature, along with dynamic typing, that makes Objective-C a perfect match for interface programming. Being able to load classes and call methods from string identifiers reduces the amount of code needed considerably when compared to languages that use early binding. Have fun re-implementing something like KVC/KVO in C++.
Objective-C's problems stem from the fact that it must be able to compile all valid C code. This severely limits the syntax available. Ruby is essentially Objective-C without the C syntax, if you are curious about the difference syntax makes.
You (well, at least most people) are already running Javascript on their machine. There is absolutely no difference. The same sand boxing would apply.
Flash consistently tells users that their version of Flash is out of date. Please upgrade. Why can't HTML5 sites do the same?
There is work underway to replace Javascript with a byte-code interpreter within the browser. Meaning you can write your code that is executed by the browser in any language that can compile to the byte-code language.
After that, you remove the HTML and CSS components from the browser and you are left with a virtual machine capable of executing the aforementioned executables over the network, like how Javascript is executed today.
If you need to render HTML and CSS, you can link to someone's HTML renderer provided in a browser executable format which is then downloaded over the network at runtime. No longer are you restricted to using the renderer of your browser. If your application is better suited to run without HTML dependance, you can do that too.
Cocoa is also available virtually everywhere, including the web browser itself. While not all implementations of Cocoa are open source, it is based on an open standard (OpenStep) meaning that anyone can write their own implementation.
I do agree with your underlying sentiment. The web browser should provide a virtual machine enabling developers to write their software in any language and framework they see fit. An HTML renderer could be just one of the many applications available to the browser.
Why recreate when you can just play it in HTML5 natively? http://apple.slashdot.org/story/10/06/01/1748200
I once visited a brewpub that had a 16% beer on tap, among others. The 16% beer was, to my taste buds, the most enjoyable drink of them all. To be honest, was I was actually quite surprised that it could taste so good. Strong alcohol content beers can taste horrible, but they do not have to taste horrible.
Sure, the iPhone is capable of routing like any other computer, but the iPhone doesn't route tethered IP transmissions. It opens a tunnel to the provider's network, which then facilitates any necessary routing. Interestingly, at least with my provider, tethered computers do not even end up on the same network as the phone.
All of the iPhone OS devices, except the first gen. iPod touch, have microphone inputs. If you want to get technical, even the first gen. iPod touch supported microphone input through a third party extension. iPhone OS devices without a camera still allow in-app access to photograph data through the Library. The lack of certain hardware only limits what the user can do, it does not prevent the user from using the application outright unless the developer also chooses to limit who can use the app.
I have never made an argument about Android fragmentation. If I can write a general information-centric application that will run on all Android-based smartphones, tablets, in-car computers, etc. there is no fragmentation and all of the devices should be counted towards Android sales.
With that said, from what I understand, you often cannot guarantee that your Android app will be able to use even basic system features. That does sound like a real problem.
That statement doesn't mean a whole lot in the grand scheme of things. Apple sells more iPod touches than iPhones, and iPad sales have been phenomenal.
I think Android is a great platform with a bright future, but it isn't anywhere near catching up to iPhone OS numbers yet.
Because it proves (again) that Adobe can bring Flash to the iPhone/iPad without breaking agreements with Apple. It shows that Adobe would rather cry about the situation instead of actually supporting the product they claim to stand behind.
Who says it has anything to do with Adobe or Flash?
Of course. Consider the following:
typedef struct Foo
{
char *name;
};
Foo * foo_new()
{
Foo *foo = malloc(sizeof(Foo));
foo->name = NULL;
return foo;
}
void foo_free(Foo *foo)
{
free(foo->name);
free(foo);
}
void foo_set_name(Foo *foo, const char *name)
{
free(foo->name);
foo->name = strdup(name);
}
int main(int argc, char **argv)
{
Foo *foo = foo_new();
foo_set_name(foo, "John Smith");
foo_free(foo);
return 0;
}
That is really all OOP is at its basic level. OOP languages add syntax sugar to make accessing objects more convenient, but you most certainly can write object oriented C. You can even implement inheritance and all those other cool OOP features in plain old C. C++ was originally written as a preprocessor that converted C++ code to C before compilation.
While C++ shares many of the same characteristics as C, it is its own language. You can write valid C code that will not compile under a C++ compiler.
Perhaps you were thinking of Objective-C, which is a strict superset of C? Any valid C code can be compiled with an Objective-C compiler.