As value of news is diminishing with every day, I value now more random user comment which often prove to be insightful. That includes obviously blog posts too.
But since only a tiny fraction of people ever upgrade CPUs [...]
I know about at least one company which uses AMD CPUs in their workstations precisely for the reasons that few years later they can drop a new CPU (and more RAM) into it to accommodate advances (read "bloat") of the engineering software.
On Intel side of things, generally when you feel that you need to upgrade, you are forced to upgrade the PC completely: CPUs for the socket/slot you have are not produced anymore.
And since Intel is the largest CPU producer and most have Intel CPUs the stated "tiny fraction" is actually heavily biased and is the direct result of the Intel's strategy.
It would be different if AMD had better CPUs than Intel, but since Intel's are the fastest right now...
Who the hell nowadays cares how fast the CPU is? I thin the "fraction of people" is even tinier than that of people upgrading CPUs.
My 5yo Athlon 64 X2 4200 (2x2.2GHz) runs pretty much everything even today. I have money now but I can't even find a justification to upgrade.
Why does every argument with an Apple fanboy end up with some comment like this?
I'm very very far from being anything like an Apple fanboy.
Neither I'm a huge fan of ObjC. Strict typing of C++ is better suited for the types of applications I write (and kind of mistakes I usually make - love the compiler finding the errors for me).
I have simply tried to correct where you were wrong.
But it does seem you lack practical experience to even understand the problems ObjC was introduced to solve.
Any interface in the world is assigned a single unique unchanging number [...]
If you can ask an arbitrary object for "method 56 of interface 11", your problem is sorted.
Well, you really do lack experience to understand all the practical problems that causes (e.g. branching, collaboration), why in some scenarios it is not possible at all (e.g. plugins/dynamic linking) and why it is pretty much never used (waiting days for release to become compilable while people resolve the merge conflicts of the "unchanging number" lists).
And apparently I'm simply incapable of explaining that to you.
You should try to implement what you suggest in a commercial project with team 5+ people: you would understand the problems within few months down the development road.
You're either a troll or in the frame of mind which resulted in the "loose" typo right at the start of this thread...
What's a Selector object doing, behind the scenes?
Selector is essentially a pointer to a method. It doesn't serialize a damn thing. Unlike C++ method pointer, it is not bound to a class - you can apply a selector to any object. And you obviously always can find whether the object responds to a particular selector or not.
Eh? A static number for interface, a static number for function, a two-level lookup table.
Eh? "Static number for interface"?? "Static number for function"???
However "insane" you like to think it is, a method isn't a variable (although you can indicate a particular non-static method of an class in a variable using member function pointers).
Method pointers are bound to a class.
That means code need to know explicitly the interface to call a method.
You probably want to use an pointer of abstract base class type, i.e. interface.
When you get a pointer to the object of a base class, you can't upgrade it inside of the message dispatch - because that would require the message dispatch to know all the hundreds/thousands interfaces used all over the program. And that's simply impractical, most of the time impossible.
Why do you keep wanting to defeat static typing?
I'm not.
It was you who tried to indicate that the messaging is somehow implementable with polymorphism. And it is not. As you yourself point out between the lines: it is simply incompatible with static typing.
If you want to be able to queue random calls to/anything/, represented in some language-defined way as calls with all their parameters [...]
That what messaging often boils down to.
Constantly serializing/deserializing is way too expensive.
[...] you are probably looking for a completely dynamically typed language like Smalltalk.
... of which the Objective C is one of the descendants.
The End.
P.S. I have tried to implement messaging in C++ at least twice. Once by serializing the calls, second time by trying to have interfaces for all used methods. First failed due to miserable performance. Second failed when more people were assigned to the project and it became impossible to maintain -in any sane fashion- list of used interfaces and dispatch code was constantly broken due to changes to the other parts of the software.
As for "messaging", well, just because Objective C calls it a message and C++ calls it a polymorphic method call, it doesn't mean there's a relevant difference.
You apparently never tried to implement the message passing in general or in C++ in particular. I unfortunately did.
It all boils down to the trivial problem: given an object, one should be able to call a random method on it.
C++ forbids this due to strict typing and compile time binding. Nor you can't represent a method as a variable. Nor implementing hundred/thousands of abstract classes is practical or sane.
Objective-C has that as a feature. Selector is a basic data type.
You can queue up selector/object pairs in ObjC for later calling - you can't anything close to it in C++. Thus no native messaging in C++.
P.S. One can implement that also in C++ - see all the insanities TrollTech had to go into to do it in Qt. They use strings to identify methods during compile time, create class vs. method tables during link time and during run-time perform look-up on the table to identify the method's entry point.
P.P.S. loosing v. losing. Give me a break, man. It's Monday. I obviously meant "losing".
Objective-C is what C++ could have been if they had done it right.
ObjC and C++ have totally different design goals.
For some applications I would prefer C++, for others ObjC. They do not compete against each other, but rather complement.
Why in the end the Objective-C++ was actually born: to get the weak typing and messaging where it is needed it - without loosing compile time binding and strict typing where it counts.
Data plans, anyway you look at them, are still luxury. Time after time I check with my friends how much they pay for iPhone per month and for myself I simply can't justify the expenses.
And the laptop gaming is on rise. What is rather obvious as for few years now laptop shipments outnumber that of desktops. It is simple fact that more and more people own a laptop and have no desktop at all.
That means that "always on-line" DRM is screwed in long run.
There would be then more coverage of free and indie games. And that's good.
I can't help but think that consumerism took over the gaming and majority of people presume that only large corporations are capable of making interesting games. Sooner the myth gets busted, better.
Well, look into the very same history books and check how attempts to push a change from outside normally end. Wars, civil wars and puppet states are often bring more misery to the people in the long run.
And I personally find the slavery to be a good example in the case. Because in most states slavery was ended by the force of the slaves themselves. Even civil war in US was a civil war, purely internal affair.
So my mouse may cost $15 instead of $12 and the profit margin is only 40% instead of 50%.
Normally double production costs would mean double retail price. Because production costs are only fraction of the retail price. And more expensive the goods are, higher all other costs surrounding them get.
I think it's likely the Chinese will become the predominant power in the world because of their work ethic. While we sit in our comfy air conditioned offices and whine about every little thing--I tell you it gets tedious listening to co-workers complain that the coffee isn't free or they got "cheated" out of a sick day and so forth--there are people out there making great sacrifices to get ahead and build a stronger economy.
I second. But you would find little sympathy here.
P.S.
A civilization is built on what is required of men, not on that which is provided for them.
-- Antoine De Saint-Exupery
#3 is the retarded part. Xcode uses gcc as a compiler anyway. Why shouldn't I be able to use a third-party IDE, or even a third-party language that has Xcode support?
Compiler is only a part of the developer package. Lots of static resources are created using e.g. Interface Builder.
Additionally "application" on Mac OS X is actually a bundle, compiled program is only part of. Bundling of resources and external frameworks are pure Apple specific part having little to do with compiler or linker.
Also beside the point.
It's nice to be an illiterate on the technical topics: discussions becomes so much more interesting.
Let me put it this way: If I don't like some aspect of Javascript, I can always write a preprocessor for it.
If only you hadn't you ignored technical point in GP...
So you still haven't provided a single example of why it must be originally coded in Objective C.
Sorry to be unclear.
It has to be:
1. Coded in ObjC. Because this is the language Apple supports and provides all bells and whistles to be feature-complete as Mac OS X goes. It is precisely ObjC runtime which allows to allow to write Cocoa applications in multiple languages (for which Apple supplies bridges).
2. Coded in ObjC using Cocoa. Because this is a framework which is officially blessed by Apple and also maintained by Apple in a fashion to allow older applications to integrate with newer Cocoa versions.
3. Coded in ObjC using Cocoa from Xcode. Because this is official blessed way to create Cocoa projects, accompanying resources, etc which are guaranteed to run on Apple blessed platforms.
In other words, they're banning third-party preprocessors.
Honestly, I have never seen the Flash converted projects so I can't comment.
I understand what Apple means because I have shortly coded for Mac OS X and out of interest also dug a bit of more information on ObjC/Cocoa/Carbon.
But I can't compare that to what Adobe generates since I have never seen it.
If what others have said is true - Adobe simply wraps Flash run-time into ObjC wrapper - then it is only given that Apple would be pissed. If Adobe really translates Flash project into a ObjC/Cocoa one (what is very highly unlikely) then the Apple's wrath is really unjustified.
I don't see any technical reason for them to care what language you originally use to produce it.
There is a nice simple example right from Mac OS X itself: the application menu.
There are essentially two ways for applications to construct the menu: either by adding own items to whatever Cocoa creates automatically (that's official blessed way) or create one from scratch. If one goes with the official blessed way, then regardless of version of Mac OS X, application's menu would look integral to the rest of the OS. If one picks the latter option (many Carbon applications did it that way) then menu would look out of place for any Mac OS X version except the one application was created originally.
The nice thing about Cocoa framework is that it take over a lot of OS integration tasks. But the story doesn't end there. The way Cocoa takes over the tasks allows Apple to introduce the changes into it in a next Mac OS X versions and have all properly written applications still work, behave and look properly - in accordance with rest of the new OS.
Such practices are essentially taboo in Windows or Java. But Apple with Cocoa (and ObjC - it is the enabler of the magic) does them quite often.
Or you can just write a C/C++ app and run without flash or a browser.
And unlike desktop Macs, all user has to do is press few buttons to download and install the software under iPhone OS.
I'm not against Flash per se, but also understand Apple's thinking: neither Apple nor Flash developer themselves have control over the software distributed to the end user. Only Adobe does.
Considering that iPhone OS is a closed platform, Apple as a publisher would obviously not tolerate such schemes.
One can either blame Adobe or Apple. Or both. First could be blamed for the relatively low quality of their products. Second could be blamed for creating another proprietary, closed down platform.
Also I clearly remember Apple publicly declaring ~4-5 years ago that Carbon goes into deep maintenance mode and people should start porting their stuff to Cocoa finally.
Surely Adobe saw the writing on the wall?
That really depends on how deeply deluded their top-management it.
I do not know the C#, but at least in the Java one has to often downcast to the java.lang.Object.
Probably the C# is bit smarter and does additional check during compile time (in many cases possible), yet this is a *feature* of weak-typed languages: methods/objects are bound to each other as a rule during run-time, not during compile time like in the strict typed C++.
And the weak typing has to be a feature for the language to be message/event friendly. (Just look to what the Qt had to resort to implement the messaging in C++ - something one takes for granted in the Java and C#.)
But yeah, this is the Slashdot and last I touched Java (thanks God) was many years ago. It might have changed, but unlikely: the Sun kept Java consistently backward compatible.
Buffer overflows is the most common coding error in the most common applications - that's why they are targeted. But then it's only Windows (thanks to its monoculture) which is affected most by it. Linux or *NIX have too much variants to be an easy target for such elaborate exploit technique.
I'm pretty sure that if Java applications become so widespread as the C ones (on desktops, on servers facing directly Internet - not only in corporate data centers) then crackers would shift their effort to Java and I'm pretty sure that they would find enough logical holes to completely bypass the unexploitable buffer handling.
In the end, it all depends on a developer. "Secure" language is a myth. Developers simply do different mistakes in Java.
This is where I disagree, it doesn't all depend on the developer.
You are entitled to the opinion, but practice speaks otherwise.
The likes of C/C++ don't have these benefits, you have to manually make sure every single section of code is secure [...]
No, you really do not. One simply has to properly validate input (valid to any language) and use proper data type (with proper sizes) consistently across the application.
Not a big deal, if you ask me. And there are even tricks in C++ with strict typing/operator overload how to identify such non-compliant places already during compilation (or less elegant in C with struct pointers). Something weak typed languages like Java or C# simply do not support.
Slashdot Mirror
And on Linux I'm pretty sure one can run encryption over the imported NAS volume.
As the requirement relates only to the "PII" (Pentium 2?!), that's not a such huge amount of information in the end.
Even the integration of performance oriented SQL back end with data security oriented one is nothing new.
I personally do not mind.
As value of news is diminishing with every day, I value now more random user comment which often prove to be insightful. That includes obviously blog posts too.
But since only a tiny fraction of people ever upgrade CPUs [...]
I know about at least one company which uses AMD CPUs in their workstations precisely for the reasons that few years later they can drop a new CPU (and more RAM) into it to accommodate advances (read "bloat") of the engineering software.
On Intel side of things, generally when you feel that you need to upgrade, you are forced to upgrade the PC completely: CPUs for the socket/slot you have are not produced anymore.
And since Intel is the largest CPU producer and most have Intel CPUs the stated "tiny fraction" is actually heavily biased and is the direct result of the Intel's strategy.
It would be different if AMD had better CPUs than Intel, but since Intel's are the fastest right now ...
Who the hell nowadays cares how fast the CPU is? I thin the "fraction of people" is even tinier than that of people upgrading CPUs.
My 5yo Athlon 64 X2 4200 (2x2.2GHz) runs pretty much everything even today. I have money now but I can't even find a justification to upgrade.
Why does every argument with an Apple fanboy end up with some comment like this?
I'm very very far from being anything like an Apple fanboy.
Neither I'm a huge fan of ObjC. Strict typing of C++ is better suited for the types of applications I write (and kind of mistakes I usually make - love the compiler finding the errors for me).
I have simply tried to correct where you were wrong.
But it does seem you lack practical experience to even understand the problems ObjC was introduced to solve.
Any interface in the world is assigned a single unique unchanging number [...]
If you can ask an arbitrary object for "method 56 of interface 11", your problem is sorted.
Well, you really do lack experience to understand all the practical problems that causes (e.g. branching, collaboration), why in some scenarios it is not possible at all (e.g. plugins/dynamic linking) and why it is pretty much never used (waiting days for release to become compilable while people resolve the merge conflicts of the "unchanging number" lists).
And apparently I'm simply incapable of explaining that to you.
You should try to implement what you suggest in a commercial project with team 5+ people: you would understand the problems within few months down the development road.
You're either a troll or in the frame of mind which resulted in the "loose" typo right at the start of this thread...
Hehe. Payback for being a grammar nazi :D
What's a Selector object doing, behind the scenes?
Selector is essentially a pointer to a method. It doesn't serialize a damn thing. Unlike C++ method pointer, it is not bound to a class - you can apply a selector to any object. And you obviously always can find whether the object responds to a particular selector or not.
Eh? A static number for interface, a static number for function, a two-level lookup table.
Eh? "Static number for interface"?? "Static number for function"???
Go back to the kindergarten.
Thanks!
SigC++ looks interesting.
From the examples, it seems that Boost.Bind is something slightly different and more of STL's bind extension.
However "insane" you like to think it is, a method isn't a variable (although you can indicate a particular non-static method of an class in a variable using member function pointers).
Method pointers are bound to a class.
That means code need to know explicitly the interface to call a method.
You probably want to use an pointer of abstract base class type, i.e. interface.
When you get a pointer to the object of a base class, you can't upgrade it inside of the message dispatch - because that would require the message dispatch to know all the hundreds/thousands interfaces used all over the program. And that's simply impractical, most of the time impossible.
Why do you keep wanting to defeat static typing?
I'm not.
It was you who tried to indicate that the messaging is somehow implementable with polymorphism. And it is not. As you yourself point out between the lines: it is simply incompatible with static typing.
If you want to be able to queue random calls to /anything/, represented in some language-defined way as calls with all their parameters [...]
That what messaging often boils down to.
Constantly serializing/deserializing is way too expensive.
[...] you are probably looking for a completely dynamically typed language like Smalltalk.
The End.
P.S. I have tried to implement messaging in C++ at least twice. Once by serializing the calls, second time by trying to have interfaces for all used methods. First failed due to miserable performance. Second failed when more people were assigned to the project and it became impossible to maintain -in any sane fashion- list of used interfaces and dispatch code was constantly broken due to changes to the other parts of the software.
As for "messaging", well, just because Objective C calls it a message and C++ calls it a polymorphic method call, it doesn't mean there's a relevant difference.
You apparently never tried to implement the message passing in general or in C++ in particular. I unfortunately did.
It all boils down to the trivial problem: given an object, one should be able to call a random method on it.
C++ forbids this due to strict typing and compile time binding. Nor you can't represent a method as a variable. Nor implementing hundred/thousands of abstract classes is practical or sane.
Objective-C has that as a feature. Selector is a basic data type.
You can queue up selector/object pairs in ObjC for later calling - you can't anything close to it in C++. Thus no native messaging in C++.
P.S. One can implement that also in C++ - see all the insanities TrollTech had to go into to do it in Qt. They use strings to identify methods during compile time, create class vs. method tables during link time and during run-time perform look-up on the table to identify the method's entry point.
P.P.S. loosing v. losing. Give me a break, man. It's Monday. I obviously meant "losing".
Objective-C is what C++ could have been if they had done it right.
ObjC and C++ have totally different design goals.
For some applications I would prefer C++, for others ObjC. They do not compete against each other, but rather complement.
Why in the end the Objective-C++ was actually born: to get the weak typing and messaging where it is needed it - without loosing compile time binding and strict typing where it counts.
Data plans, anyway you look at them, are still luxury. Time after time I check with my friends how much they pay for iPhone per month and for myself I simply can't justify the expenses.
And the laptop gaming is on rise. What is rather obvious as for few years now laptop shipments outnumber that of desktops. It is simple fact that more and more people own a laptop and have no desktop at all.
That means that "always on-line" DRM is screwed in long run.
Let them stop porting the games.
There would be then more coverage of free and indie games. And that's good.
I can't help but think that consumerism took over the gaming and majority of people presume that only large corporations are capable of making interesting games. Sooner the myth gets busted, better.
Don't be f***ing moron.
So you propose for US/EU to invade the China?
Or how otherwise a country can tell another sovereign country how to deal with its internal affairs??
If background task would slow down a video playback, that would be a real problem.
Sanest, most constructive post I have seen in the whole thread.
That's an insane justification.
Well, look into the very same history books and check how attempts to push a change from outside normally end. Wars, civil wars and puppet states are often bring more misery to the people in the long run.
And I personally find the slavery to be a good example in the case. Because in most states slavery was ended by the force of the slaves themselves. Even civil war in US was a civil war, purely internal affair.
So my mouse may cost $15 instead of $12 and the profit margin is only 40% instead of 50%.
Normally double production costs would mean double retail price. Because production costs are only fraction of the retail price. And more expensive the goods are, higher all other costs surrounding them get.
I think it's likely the Chinese will become the predominant power in the world because of their work ethic. While we sit in our comfy air conditioned offices and whine about every little thing--I tell you it gets tedious listening to co-workers complain that the coffee isn't free or they got "cheated" out of a sick day and so forth--there are people out there making great sacrifices to get ahead and build a stronger economy.
I second. But you would find little sympathy here.
P.S.
A civilization is built on what is required of men, not on that which is provided for them.
-- Antoine De Saint-Exupery
#3 is the retarded part. Xcode uses gcc as a compiler anyway. Why shouldn't I be able to use a third-party IDE, or even a third-party language that has Xcode support?
Compiler is only a part of the developer package. Lots of static resources are created using e.g. Interface Builder.
Additionally "application" on Mac OS X is actually a bundle, compiled program is only part of. Bundling of resources and external frameworks are pure Apple specific part having little to do with compiler or linker.
Also beside the point.
It's nice to be an illiterate on the technical topics: discussions becomes so much more interesting.
Let me put it this way: If I don't like some aspect of Javascript, I can always write a preprocessor for it.
If only you hadn't you ignored technical point in GP...
So you still haven't provided a single example of why it must be originally coded in Objective C.
Sorry to be unclear.
It has to be:
1. Coded in ObjC. Because this is the language Apple supports and provides all bells and whistles to be feature-complete as Mac OS X goes. It is precisely ObjC runtime which allows to allow to write Cocoa applications in multiple languages (for which Apple supplies bridges).
2. Coded in ObjC using Cocoa. Because this is a framework which is officially blessed by Apple and also maintained by Apple in a fashion to allow older applications to integrate with newer Cocoa versions.
3. Coded in ObjC using Cocoa from Xcode. Because this is official blessed way to create Cocoa projects, accompanying resources, etc which are guaranteed to run on Apple blessed platforms.
In other words, they're banning third-party preprocessors.
Honestly, I have never seen the Flash converted projects so I can't comment.
I understand what Apple means because I have shortly coded for Mac OS X and out of interest also dug a bit of more information on ObjC/Cocoa/Carbon.
But I can't compare that to what Adobe generates since I have never seen it.
If what others have said is true - Adobe simply wraps Flash run-time into ObjC wrapper - then it is only given that Apple would be pissed. If Adobe really translates Flash project into a ObjC/Cocoa one (what is very highly unlikely) then the Apple's wrath is really unjustified.
I don't see any technical reason for them to care what language you originally use to produce it.
There is a nice simple example right from Mac OS X itself: the application menu.
There are essentially two ways for applications to construct the menu: either by adding own items to whatever Cocoa creates automatically (that's official blessed way) or create one from scratch. If one goes with the official blessed way, then regardless of version of Mac OS X, application's menu would look integral to the rest of the OS. If one picks the latter option (many Carbon applications did it that way) then menu would look out of place for any Mac OS X version except the one application was created originally.
The nice thing about Cocoa framework is that it take over a lot of OS integration tasks. But the story doesn't end there. The way Cocoa takes over the tasks allows Apple to introduce the changes into it in a next Mac OS X versions and have all properly written applications still work, behave and look properly - in accordance with rest of the new OS.
Such practices are essentially taboo in Windows or Java. But Apple with Cocoa (and ObjC - it is the enabler of the magic) does them quite often.
Or you can just write a C/C++ app and run without flash or a browser.
And unlike desktop Macs, all user has to do is press few buttons to download and install the software under iPhone OS.
I'm not against Flash per se, but also understand Apple's thinking: neither Apple nor Flash developer themselves have control over the software distributed to the end user. Only Adobe does.
Considering that iPhone OS is a closed platform, Apple as a publisher would obviously not tolerate such schemes.
One can either blame Adobe or Apple. Or both. First could be blamed for the relatively low quality of their products. Second could be blamed for creating another proprietary, closed down platform.
Also I clearly remember Apple publicly declaring ~4-5 years ago that Carbon goes into deep maintenance mode and people should start porting their stuff to Cocoa finally.
Surely Adobe saw the writing on the wall?
That really depends on how deeply deluded their top-management it.
I do not know the C#, but at least in the Java one has to often downcast to the java.lang.Object.
Probably the C# is bit smarter and does additional check during compile time (in many cases possible), yet this is a *feature* of weak-typed languages: methods/objects are bound to each other as a rule during run-time, not during compile time like in the strict typed C++.
And the weak typing has to be a feature for the language to be message/event friendly. (Just look to what the Qt had to resort to implement the messaging in C++ - something one takes for granted in the Java and C#.)
But yeah, this is the Slashdot and last I touched Java (thanks God) was many years ago. It might have changed, but unlikely: the Sun kept Java consistently backward compatible.
Buffer overflows is the most common coding error in the most common applications - that's why they are targeted. But then it's only Windows (thanks to its monoculture) which is affected most by it. Linux or *NIX have too much variants to be an easy target for such elaborate exploit technique.
I'm pretty sure that if Java applications become so widespread as the C ones (on desktops, on servers facing directly Internet - not only in corporate data centers) then crackers would shift their effort to Java and I'm pretty sure that they would find enough logical holes to completely bypass the unexploitable buffer handling.
In the end, it all depends on a developer. "Secure" language is a myth. Developers simply do different mistakes in Java.
This is where I disagree, it doesn't all depend on the developer.
You are entitled to the opinion, but practice speaks otherwise.
The likes of C/C++ don't have these benefits, you have to manually make sure every single section of code is secure [...]
No, you really do not. One simply has to properly validate input (valid to any language) and use proper data type (with proper sizes) consistently across the application.
Not a big deal, if you ask me. And there are even tricks in C++ with strict typing/operator overload how to identify such non-compliant places already during compilation (or less elegant in C with struct pointers). Something weak typed languages like Java or C# simply do not support.