Just thinking about using malloc/free/strcpy/strdup/etc. instead of std::string gives me the screaming heebie-jeebies. Same for std::vector vs. C arrays - aaargh!
There is no reason why you cannot have vectors and strings in C. There are good reasons to use C++, but it seems kind of silly to choose it just because of its richer standard library when one can easily include libraries to do the same in their C code.
That is because people come with experience from languages like C, Java, and PHP and try to write Ruby code in the same style. It is easy to write good code in Ruby once you take the time to learn how to design your code to fit Ruby's programming model.
If I'm in a waiting room, the first thing I do is whip out my cell phone, not go looking for a magazine. While you are right that dentists will not be providing iPads for their patients any time soon, people are already carrying these devices with them.
It is required. Interpreting code without the use of Apple's own libraries violates the SDK license agreement. Cocoa defines code as any type of serialized data. iPhone OS includes XML parsing libraries, but an optimized binary format would most certainly be proprietary to Wired and therefore is not legally loadable on iPhone OS.
they didn't even go through the trouble of having a single message to create and initialize a new object.
Actually, NeXT originally used the [Object new] convention for most objects, but found that alloc/init provided greater control for the developer. new does still work for most, if not all, Foundation classes.
Objective-C is a superset of C, so it needs symbols like @ to tell the compiler which parts of the code are C and which are Objective-C. Java and C++ are completely different languages, with only similarities to C. They are free to implement their syntax however they wish, without any dependencies on C implementations.
Objective-C is actually quite a fascinating language. It cleanly mixes an object oriented, dynamically typed, message passing language which is very similar to Ruby (both Objective-C and Ruby are based on the work of Scheme), with the statically typed procedural language that is C.
There is a strong argument, based on what is being seen in recent Xcode releases, that Apple is moving to a managed language, like.NET, for iPhone binaries. This would explain why Apple is requiring the use of Xcode-supported languages to ensure that everyone is able to move to the new intermediate language with just a recompile.
I personally have my doubts that Apple would base their work on.NET over their own implementation, but I suppose anything is possible. Say what you will about Steve Jobs, but one thing he is intent on is allowing access to content on all types of devices, not just Apple-branded ones. Cocoa (OpenStep) itself was originally designed to run on multiple platforms, not just NeXT systems. A move to.NET could open up some interesting doors.
While I'm not sure developing mac applications on windows makes much sense
Cocotron allows you to target Windows (and other platforms) with your Cocoa application, like OpenStep and YellowBox have done in the past. Cocoa seems to finally be realizing the dream of OpenStep and is becoming the de-facto standard for interface development on all platforms (web, mobile, desktop, etc.) It is the natural direction for Windows developers to head*. Having an application that runs on the Mac with just a recompile makes it that much more appealing.
* I have a hard time believing Microsoft would get behind the movement though.
Not quite. You cannot link against Apple's libraries from your Library, which means no Cocoa Touch, among others. As far as Flash translation is concerned, that is fine. Let the Application do the heavy lifting and interfacing with Apple's code. The Library only needs to respond to actions generated by the Application.
If I was to design the future of the web, HTML interpretation would be just one of the many applications the web browser would be able to process. The browser would provide a virtual machine environment, allowing applications to be executed (not unlike Javascript is today, but a richer environment). If you want to display HTML, you can write/link to an HTML rendering engine able to run within the environment.
HTML has its place, but it is seems incredibly silly to write applications using HTML and CSS.
There is absolutely no difference between this service and a cache that is shared among users. It is expected that content will be copied and distributed outside of the control of the originating server. It is a fundamental feature of HTTP.
I'm saying that web servers implicitly grant you the right to use the content as you see fit. If you do not want to grant access to everyone, change your configuration.
Using the theft analogy, it is like me coming to your home, asking you for your TV, you giving me your TV, and the going to the police claiming I stole your TV. If you didn't want me to have your TV in the first place, why did you give it to me? A simple "no" would have sufficed.
If someone walked by my house and the doors and windows flew open and started throwing out my items to the passer-by, like web servers do, then yes, it would be my fault for installing windows and doors.
If you want to protect your content, only give it to people whom you want to have it. Web servers do not have to grant access to everyone.
I believe copyright has merit. However, I believe that if a web server responds to a request, the web server has implicitly granted full rights to the data. If you want protection, ensure your web server responds accordingly. Require something like a X-Not-For-Redistirbution header to be set before responding to the client, if you are concerned about what is going to happen with the data later. That ensures that the client is aware that there is limitations to the data.
Blackberry and Android are both bigger in terms of sales.
If you want to talk about a specific market (the US cell phone market), then yes, Blackberry and Android operating systems are selling more than the iPhone. Likewise, if you look at the US consumer computer market, OS X is almost outselling Windows.
If you look at all of the iPhone OS devices in the wild, however, Blackberry and Android hold relatively little market share. Android might one day surpass iPhone OS in its install base, but it has a long, long way to go.
If you can get Apps that run on iPhone and Android then inter-platform price competition becomes an issue.
Keep in mind that Cocoa Touch is based on a long history of multi-platform development. While Apple no longer maintains cross-platform compatibility with Cocoa, projects like Cocotron have picked up the slack. There is no reason why someone cannot implement Cocoa Touch for Android.
And that is exactly what Apple wants. They are pushing for a standard, like they are pushing for HTML5 to be the standard for web development.
The thing is that the iPhone also requires that one use HTML5 for web development. I don't hear anybody complaining how they cannot build their web app in Erlang. In fact, many are happy to see Apple push towards a common standard. What is the difference?
Cocoa Touch is based on the work of OPENSTEP, which in many respects, had many of the same goals as HTML5.
You are right, actually. I have posted about this in the past. Apple wants to set Cocoa Touch as the standard for native mobile interface development much like they are pushing to set HTML5 as the standard for web development.
If every iPhone developer must use Cocoa Touch, those iPhone developers will quickly make Cocoa Touch available on other platforms like Cocotron (and to a lesser extent GNUStep) have done for Cocoa. The are attempting to finally realize the dream of OPENSTEP, only on mobile devices.
Says who? The SDK agreement allows you to write your supporting code in any language you want. Only the core application, i.e. the code that implements the interface and delegates actions out to the support libraries is required to be in Objective-C, C, or C++.
Price is another factor. I assume 2G chips are less expensive. They were gunning for a certain price point with the iPhone. A year later the 3G chips would have dropped in price, presumably enough to allow the iPhone 3G to hit the same target.
Slashdot Mirror
There is no reason why you cannot have vectors and strings in C. There are good reasons to use C++, but it seems kind of silly to choose it just because of its richer standard library when one can easily include libraries to do the same in their C code.
That is because people come with experience from languages like C, Java, and PHP and try to write Ruby code in the same style. It is easy to write good code in Ruby once you take the time to learn how to design your code to fit Ruby's programming model.
If I'm in a waiting room, the first thing I do is whip out my cell phone, not go looking for a magazine. While you are right that dentists will not be providing iPads for their patients any time soon, people are already carrying these devices with them.
It is required. Interpreting code without the use of Apple's own libraries violates the SDK license agreement. Cocoa defines code as any type of serialized data. iPhone OS includes XML parsing libraries, but an optimized binary format would most certainly be proprietary to Wired and therefore is not legally loadable on iPhone OS.
What is wrong with Cocotron?
Actually, NeXT originally used the [Object new] convention for most objects, but found that alloc/init provided greater control for the developer. new does still work for most, if not all, Foundation classes.
Objective-C is a superset of C, so it needs symbols like @ to tell the compiler which parts of the code are C and which are Objective-C. Java and C++ are completely different languages, with only similarities to C. They are free to implement their syntax however they wish, without any dependencies on C implementations.
Objective-C is actually quite a fascinating language. It cleanly mixes an object oriented, dynamically typed, message passing language which is very similar to Ruby (both Objective-C and Ruby are based on the work of Scheme), with the statically typed procedural language that is C.
There is a strong argument, based on what is being seen in recent Xcode releases, that Apple is moving to a managed language, like .NET, for iPhone binaries. This would explain why Apple is requiring the use of Xcode-supported languages to ensure that everyone is able to move to the new intermediate language with just a recompile.
I personally have my doubts that Apple would base their work on .NET over their own implementation, but I suppose anything is possible. Say what you will about Steve Jobs, but one thing he is intent on is allowing access to content on all types of devices, not just Apple-branded ones. Cocoa (OpenStep) itself was originally designed to run on multiple platforms, not just NeXT systems. A move to .NET could open up some interesting doors.
Cocotron allows you to target Windows (and other platforms) with your Cocoa application, like OpenStep and YellowBox have done in the past. Cocoa seems to finally be realizing the dream of OpenStep and is becoming the de-facto standard for interface development on all platforms (web, mobile, desktop, etc.) It is the natural direction for Windows developers to head*. Having an application that runs on the Mac with just a recompile makes it that much more appealing.
* I have a hard time believing Microsoft would get behind the movement though.
Not quite. You cannot link against Apple's libraries from your Library, which means no Cocoa Touch, among others. As far as Flash translation is concerned, that is fine. Let the Application do the heavy lifting and interfacing with Apple's code. The Library only needs to respond to actions generated by the Application.
If I was to design the future of the web, HTML interpretation would be just one of the many applications the web browser would be able to process. The browser would provide a virtual machine environment, allowing applications to be executed (not unlike Javascript is today, but a richer environment). If you want to display HTML, you can write/link to an HTML rendering engine able to run within the environment.
HTML has its place, but it is seems incredibly silly to write applications using HTML and CSS.
IE is already dead as far as developers should be concerned. Pages will work well enough that IE users can still limp along, if need be.
There is absolutely no difference between this service and a cache that is shared among users. It is expected that content will be copied and distributed outside of the control of the originating server. It is a fundamental feature of HTTP.
These guys will happily sell you a laptop without Windows.
I'm saying that web servers implicitly grant you the right to use the content as you see fit. If you do not want to grant access to everyone, change your configuration.
Using the theft analogy, it is like me coming to your home, asking you for your TV, you giving me your TV, and the going to the police claiming I stole your TV. If you didn't want me to have your TV in the first place, why did you give it to me? A simple "no" would have sufficed.
If someone walked by my house and the doors and windows flew open and started throwing out my items to the passer-by, like web servers do, then yes, it would be my fault for installing windows and doors.
If you want to protect your content, only give it to people whom you want to have it. Web servers do not have to grant access to everyone.
I believe copyright has merit. However, I believe that if a web server responds to a request, the web server has implicitly granted full rights to the data. If you want protection, ensure your web server responds accordingly. Require something like a X-Not-For-Redistirbution header to be set before responding to the client, if you are concerned about what is going to happen with the data later. That ensures that the client is aware that there is limitations to the data.
Libraries are not applications.
If you want to talk about a specific market (the US cell phone market), then yes, Blackberry and Android operating systems are selling more than the iPhone. Likewise, if you look at the US consumer computer market, OS X is almost outselling Windows.
If you look at all of the iPhone OS devices in the wild, however, Blackberry and Android hold relatively little market share. Android might one day surpass iPhone OS in its install base, but it has a long, long way to go.
Keep in mind that Cocoa Touch is based on a long history of multi-platform development. While Apple no longer maintains cross-platform compatibility with Cocoa, projects like Cocotron have picked up the slack. There is no reason why someone cannot implement Cocoa Touch for Android.
And that is exactly what Apple wants. They are pushing for a standard, like they are pushing for HTML5 to be the standard for web development.
The thing is that the iPhone also requires that one use HTML5 for web development. I don't hear anybody complaining how they cannot build their web app in Erlang. In fact, many are happy to see Apple push towards a common standard. What is the difference?
Cocoa Touch is based on the work of OPENSTEP, which in many respects, had many of the same goals as HTML5.
Or an Exchange account. Which can include the use of z-push, if Exchange is not your thing.
You are right, actually. I have posted about this in the past. Apple wants to set Cocoa Touch as the standard for native mobile interface development much like they are pushing to set HTML5 as the standard for web development.
If every iPhone developer must use Cocoa Touch, those iPhone developers will quickly make Cocoa Touch available on other platforms like Cocotron (and to a lesser extent GNUStep) have done for Cocoa. The are attempting to finally realize the dream of OPENSTEP, only on mobile devices.
Says who? The SDK agreement allows you to write your supporting code in any language you want. Only the core application, i.e. the code that implements the interface and delegates actions out to the support libraries is required to be in Objective-C, C, or C++.
Price is another factor. I assume 2G chips are less expensive. They were gunning for a certain price point with the iPhone. A year later the 3G chips would have dropped in price, presumably enough to allow the iPhone 3G to hit the same target.