Maybe there's a wait in some places but in Atlanta I was offered an iPhone 4 upgrade (wife has 3GS) with no wait (phone in stock in store) when I was buying my Galaxy S. No thanks... I was happy to find that AT&T hadn't buried the Captivate (their version of the Galaxy S) in AT&T crapware as well; although, you can't sideload apps (not a big deal as I am a registered Android dev anyhow...)
Sure, they could do it. But when they did it to Cocoa, it broke compatibility (as we've discussed in several posts). Sure, they could do it to Flash too, but it would end up either with broken compatibility (which would make Flash pointless) or have it suck as much as every other tablet produced in the past decade (maybe you don't think they suck, and of course you are entitled to your opinion).
Well, most of the complaints about broken compatibility is related to the method by which the implementation occurred, not the actual design. I don't think they' break the compatibility in Flash (especially since the spotlight would be glaring down on them), and I don't think they'd have to worry about it working differently than it does in Cocoa because they're the same messages generated by the same input from the same OS as Cocoa is getting. Then again, Adobe does make ridiculous mistakes on occasion. I think most tablets suck, but not because of multi-touch. Personally I'm looking forward to the Adam which is looking so impressive it cannot be anything other than a monumental failure to deliver.
reason Apple doesn't want Flash on the iPhone, or even that it's the main reason, but it is a valid point.
I'm not convinced (so we'll have to agree to disagree) that Apple's criticism of Flash is warranted when they won't let Flash run on the iPhone OS because it won't run properly on the iPhone OS (chicken and egg syndrome?)
I'm still going to go with my opinion that the iPhone dev environment is an improvement over BREW, J2ME, or WindowsCE
Well, it's better than most, and that's because it's sort of halfway between a real PC dev environment and a mobile device environment. The problem is, there's no legitimate reason to keep Java or Flash off the iPhone/iPad except greed.
If you mean Cocoa, say Cocoa. If you mean Objective-C, say Objective-C. Even Steve Jobs gets his terminology right (maybe his letter was looked over by a developer, I don't know). Clean up your speech. And while we're on the topic, no one ever calls it the Objective-C development environment. That wouldn't even make sense.
Yep, you've retreated to 'four year old' land. You now want to pretend we weren't discussing developing with flash or Objective-C (what you would now like to label 'Cocoa' apparently - or, much more likely you would like to divide the individual components up because then you can simply focus on the one you believe you can be the most effective apologist for...)
It is quite obvious, to any reading these posts, that we are discussing Flash versus Objective C development. If you want to label it the X-Code environment, well, that's inaccurate because you don't need XCode to produce binaries for the iPhone/iPad. If you want to label it the gcc iPhone/iPad development environment, well that's inaccurate as well because most people use X-Code on top of gcc. If you want to label it the 'Cocoa development environment', it's technically incorrect as well. BTW, I know quite a few iPhone devs and they ALL refer to it as an, and I quote, "Objective-C dev environment", probably because they all develop for other phones (yes, they exist) and Objective-C is anachronistic to them. So, maybe you can get back to the actual points now instead of throwing up straw man arguments about "Oh, well, I didn't realize you were talking about anything other than the Objective-C specification..."
Either way, even if you insist on your inane terminology, your original point is still wrong. Your original point was that the iPhone dev environment was designed for the PC, which invalidates Steve Jobs' point that Flash was written for the PC. But Apple rewrote their development environment specifically for the iPhone.
Great, you turn out to be just as disengenuous as Jobs now. I pointed out that Jobs stated, without any further specification, that "Flash was designed for PCs using mice" and that this was dishonest because all the underpinnings of the iPhone dev environment, including Cocoa, were designed for PCs using mice. Just because multi-touch events were added to the iPhone/iPad version of Cocoa doesn't mean by any stretch of the imagination, even yours that it would be anything other than trivial for Flash to handle these very same events. FFS, they're simply messages passed along to a view. This is the entire point - Steve Jobs is a dishonest, lying, sack of narcissistic arrogant monkey shit. He is trying to make Flash sound like antiquated technology because it existed before multi-touch, when his entire toolchain existed before multi-touch, including the API that has been 'extended' to handle multi-touch events.
So no, I'm not wrong. He's still a lying prick. Hell, I can't stand Flash as a development environment (I wouldn't touch it with a 10 meter cattle prod if I didn't have to), but that's a personal and subjective dislike, just like Jobs' objections to Flash.
I'm sure you think what he's doing is right though.
Ah, so now you are saying that when you say "Objective-C" you mean the entire Cocoa toolkit.
No, I mean developing for the iPhone/iPad with Objective-C and not Flash. I'm sorry, but if you're going to act like a four year old and try to claim that you were only referencing Objective-C the language specification then nobody can help you.
And you claim that Cocoa on the iPhone is somehow the same as the one on the desktop. The only way you could have come to this conclusion is if you had gotten your information from blogs (or slashdot) and never actually programmed in both.
Actually, I quite clearly point out that they are not the same between Mac OSX and the iPhone OS, in that they are the same API with problematic implementation differences. They're supposed to be the same but Apple screwed the pooch (so to speak.) This of course pokes giant holes in your theory of cross platform flexibility since you can't even even build the same Objective-C code for a Mac that you can for the iPhone (even though the API is supposed to be the same [I wonder if that's why they have the same name, they are referred to as the same in the developer docs, and are only documented differently at the API level... Hmmm... Interesting.])
Furthermore, Objective-C is separate from Cocoa, it has its own standard library. Saying Cocoa is the same as Objective-C is the same as saying QT is the same as C++.
Separate how? You mean it's not part of the Objective-C specification? Of course not. It is part of the Objective-C development environment for MacOSX, the iPhone, and the iPad? Of course it is. It's all one big mess of Objective-C code. Guess what Cocoa is written in?:)
Saying that Cocoa is not part of the Objective-C platform on Apple products is like saying that Win32 is not a part of the Visual C++ development platform.
Incidentally, I'd rather write in Objective-C any day over C++ (although that's not saying much; but it sure is a nice language. The programming world would be a better place if Objective-C had won out over C++)
I think it depends upon what languages you ran into first in University/College. They're all tools in the toolbox. I don't like some sanctimonious prick (Steve Jobs in case I didn't make that clear along the way) trying to bullshit the world about why he doesn't want Flash on the iPhone (or Java, or any other technology that would allow people to bypass his beloved App store.)
Actually, you're simply proving that you haven't the slightest clue what you're talking about. Let's take this most recent 'less than stellar' post of yours apart, shall we?:)
If you were a programmer, you would realize Objective-C is not the same as Flash, it's just a programming language. Flash is an entire UI system, it was designed for use with a mouse
First, you are correct in that I am not a 'programmer', I am a Software Engineer. There's a big difference, and someday you may manage to learn what that difference is - but I doubt it. Second, Objective-C is a language designed in the early 80's and licensed by NeXT, it is considered by most Software Engineers to be a bizarre abomination of C and Smalltalk. When anyone refers to Objective-C on the iPhone or iPad it is obviously in reference to the 'platform.' Perhaps you didn't understand that, ergo your insipid lack of understanding. This means all the Objective-C libraries that make up the Objective-C platform on a given architecture. As for Flash, Flash isn't a UI system, it is also platform. If you were a 'programmer' you would know that. Its manifestation on a mobile device is a runtime - not a 'UI system.' The UI portions of the runtime were designed for use with a mouse, but so were all of the Objective-C UI libraries ever created before the introduction of the iPhone.
If Apple had ported their UI toolkit directly to the iPhone, it would have been lame. Instead, they rewrote it. It is really not compatible with Cocoa on the desktop. Adobe could do similarly with Flash, but then it wouldn't be Flash anymore, it would be something different, even if they still called it Flash.
They did port their UI toolkit to the iPhone, and it is lame - ever heard of Cocoa? LOL. Read the dozens of blogs about why the iPhone API implemenation of Cocoa appears to have been written by some interns over a few weeks and why it should have been implemented differently. No, it is not compatible with Cocoa on the desktop because it's f***ed up.
"Adobe could do similarly..."? You appear to be confused. Flash has its own windowing system that is encapsulated in the runtime, including rasterization. Why would Adobe want an intentionally cross platform product to look and act differently on the iPhone/iPad? Stick to being a programmer, you'd be a terrible Software Engineer.
For now, when people write Flash apps, they expect the user to have a mouse. When people write iPhone Apps, they don't.
I think what you meant to say is that when people write Flash applications they expect users to have a single input device for pointing. This is mostly true since people are only just now targeting multi-touch devices with Flash applications. There are already Flash/Flex authoring solutions (APIs) which support multi-touch and gesture based computing.
As for platform flexibility, Flash doesn't even really support Linux on 64 bit architectures. Objective-C on the other hand, supports over 40 different architectures. There's no comparison in flexibility. When Brad Cox created Objective-C, the whole purpose was to bring the flexibility and modularity of Smalltalk to more common use.
Actually it does and has since 2008. Plus, there are open source flash players. You claim that Objective-C supports over 40 different architectures, which is funny because what is actually more accurate is that GCC supports many architectures and someone wrote a front end for Objective-C. I could spend a weekend and with lex/yacc or building my own front end for gcc to create a new language called 'phantomfive-C' and it would suddenly and miraculously support over 40 different architectures. It would then be, according to your criteria, just as flexible as Objective-C. Of course, that's a stupid way to look at things, but hey, you think the way you want. Objective-C used outside of the walled gardens of the iPhone/iPad? Nowhere, why? Try writing an Objecti
You appear to have difficulty reading, is English a second language for you? I quite clearly stated it was ported to the Macintosh.
We're still all waiting for you to explain how it is you managed to deduce (and I use that term very loosely) that Flash was not designed with platform flexibility in mind and Objective-C was.
I mean seriously, anyone reading this thread is just dying to hear your reasoning behind that...:)
Wow, you're really bad at this. You're now attempting to argue that Flash, which was built to run on multiple architectures and operating systems on the same architecture was not designed in a way to make it usable anywhere, but that Objective-C, which was designed to be run on a very specific hardware system and was then ported (warts and all) to run on Macintosh hardware and then, yet again, ported to run on Apple's iWhatever hardware was in fact designed to run on all types of devices. LOL!
No, he isn't, and this is why this is so important. You are aware, no doubt, that this great bruhaha recently blew up because you can no longer compile iPhone/iPad applications with non-Apple tools, right? Thus, barring Adobe's compiler for the iPhone.
You're obvious incapable of understanding anyone's point other than your own. Jobs bashes flash because it was designed for usage on PCs, not mobile devices. Jobs does so in the complete understanding that he's being totally disengenuous (look it up) because wants you to use Objective-C to develop with instead and Object-C was designed for usage on PCs. It doesn't matter that it's been ported retard.
I don't think you are a programmer, because I don't think you would have this misconception if you were.
I don't think you're very logical, I am obviously pointing out that one of the problems Jobs has with Flash applies to Objective-C in exactly the same fashion. Objective-C was designed for desktop computers.
Yet another example of Steve Jobs talking out his a** and only technical people realizing what a lying, dishonest, <ChevyChase>sack of monkey shit he is</ChevyChase>...
...between reducing user choice but improving reliability and efficiency myself.
Why do non technical people believe the words that pour out of Jobs' gob? The man, and Apple's advertising, is infamous for saying things he knows are not true. Hell, my favorite recent example of this was when he bashed Flash about being designed for PCs as one of the reasons not to use it on the iPhone/iPad when his company makes you use Objective-C! LOL. Guess what Objective-C was designed for?
I agree that maturity is certainly a major aspect of the problems relating to web application development; however, the primary reason is still the fact that the web browser is built around displaying HTML/XHTML and HTML was not intended to be used for applications. x86 frameworks are specifically designed for the purpose of building application (although I'm sure we could find some that would make us say 'well, maybe not this one...';))
"Web development may seem like a pain, but last I checked, it's the only truly cross platform development environment that has ever existed
It's not only 'not cross platform' its not even 'cross browser'. Java Applets (and I am no fan of Java) are far better at cross platform capability than HTML when it comes to applications (and Java has issues in this department as well.) ANSI C code with a dizzying number of #ifdefs would qualify as 'cross platform' by that measure.
I'm not saying things are hopeless and not fixable, I'm simply saying that the current environment for building web applications is not just poor, it's terrible.
Chromium is an example of an attempt to bring a app container to the web world, but its problem is that you still end up using HTML to try and develop applications. W3C needs to superset HTML and leave HTML as the typographical/layout aspect of the internet. It should simply be a media type. Hell, look how long and painful (and still pretty crappy) the process has been for Flash to go from simple media container to Flex/AS3 application environment. You can make amazing full on applications in Flash that work very well across OS/Hardware architectures, but it's still kind of hokey.
If you want to get picky, 'computer' were 'never designed' for media playback, using your criteria
Uhm, you're completely missing the point. Computers don't have to be 'designed' for media playback, media playback is simply an expression of the inherent capabilities available to a computer. A web browser is an application, not an operating system or hardware, that people are trying to force into being an application container. It is not meant for these types of things. People have found ways around these shortcomings; however, they generally tend to be poor, kludgy, and overly complex. This is, again, because HTML, XHTML, and such, are not intended to be used for application development.
Flash is another example of something that was not intended to be used for application development, yet it has grown to accomodate these type of possibilities and since the introduction of Flex, it's far less horrid than previously - but it still isn't a good development environment because of all its legacy baggagejust like web browsers.
The problem with web app development is that the environment was never intended for interactivity, it was designed for displaying information. Everything added since then to create 'apps' has been bolted on (sometimes cleverly, sometimes not so cleverly) and implemented differently between browsers and (relating to plugins/extensions) differently between operating systems. Developing for x86 machines running Windows and/or Linux isn't a "tightly controlled ecosystem" but you can certainly develop excellent applications, why? Because the environment was intended to run applications.
For the users, yes, web applications are great, and for some things, they are the way of the future
The idea of Web applications is great, web applications themselves that rely on HTML/XHMTL and JavaScript are awful. Personally, I think the way of the future is purely web services consumed by specialty applications, not what we consider a 'web browser' today, where the HTML aspect of the web (typography/layout) is not the primary medium of the internet - data is, and HTML is merely a subset of that. Think of it like Google maps except that the UI isn't some crappy hodgepodge of the limitations of HTML but a specialist client or client library that eats/breathes/sleeps Google Maps web API. That's a few years off though (at the very least) but certainly the way of the future.
Now, what I hope, but which is a pipe dream since fragmentation is so much more likely a scenario, is a single interpreted/JIT'd programming language that doesn't suck and/or isn't pushed by only one company (I'm looking at you Java, and you Flash, and to a lesser extent you.NET) that becomes a core of every 'web browser.' This would avoid all the disparate tools approach to consuming data which is where the internet (not the web) is most likely headed...
I would certainly love a Java/.NET capability in something akin to applets except with good UI code, good tools, and a safe but useful (as in access to some native hardware like the video card) sandbox (yeah, I know, Santa Claus is real too...)
It's 2010. Why would we be finding something so simple 'incredible' - oh, wait, it's because people are trying to use the browser to do everything and it's a horrifically bad idea.
Look, I like HTML5, just as I like HTML4, but the web is a terrible programming environment. Javascript is great, but to listen to all the web 2.0/3.0/x.x proponents blather on incessently about how web applications are great and the way of the future and... blah blah blah. It's ridiculous.
If you want applications to run through your browser and you want them to look good, work well, and offer lots of features commonly found in 'offline' applications, great - lobby the W3C to come up with something - but using the mess that is HTML (of any flavor when used for applications) and Javascript in order to offer the abilities found on any PC since the early 80's is ridiculous.
Now, all that being said. Yes, it looks very nice and is a nice indicator of possibilities with HTML5 and the canvas element.
...to play multi-player on XBox Live. What a bunch of greedy bastards. The only thing this type of behavior does is make me more selective about the games I play, for example, I'll never buy another Ubisoft game while they have that 'always online' DRM. I stopped playing Company of Heroes when they went this route until you could play with the disc installed again. Greedy bastards.
Most people on slashdot are aware of that; however, there's a difference between your e-mail passing through someone's server your e-mail being permanently kept on that server and all of your corporate documents being stored there as well. Sort of like the difference between your postcard passing through the postal system and your post cards all being stored at the Post Office and you can get a look at them if you wish.
Sigh... I had a very long, verbose, probably boring as sh** reply to your post when I closed the wrong Firefox window... Basically, I disagree on some points and agree on others, as was the case previously;).
would generally not recommend the product today to most businesses unless their needs were very minimal and/or cost was the overriding concern"
Then we are in agreement.
I only meant this insofar as your actual argument on/. goes, not that you are making an inappropriate decision for your environment.
But my position, as seen in the original post which you replied to, is that I am clearly referring to my own situation and the situation of the CTOs/CIOs I know. Not a generalist statement against Google apps.
In my experience and in the experience of many others, there is a high failure rate when actual restores are required -- particularly in smaller organizations that do not systematically test their backups
I can only go by my experiences in this area (not other CTOs/CIOs that I know) and state that we've have to restore from backups twice in the past 5 years and had absolutely zero difficulties doing so. Now, I can certainly imagine that in complex environments this can be quite problematic; however, all of this is academic and is entirely dependent upon process, policy,hardware, and software. It's like stating that it's less risky to let someone else drive than it is to drive your own car. In some cases yes, in my case, I would argue no, it all depends on the details - and again, I wasn't making generalizations, I was stating my opinion about why I don't use it and the opinion of those in similar positions to myself whose opinion I am aware of.
Most 50 person companies simply cannot afford to staff even one highly qualified sysadmin 24-7
But why would a 50 person company need 24-7 support for office applications and e-mail?
A company can easily share credentials with a number of reasonably intelligent people to allow them to fill this role quite easily because it's doesn't require much technical know-how or knowledge of the environment
I'm sorry but we're an ISV and we have some pretty sharp people here, but none of our 'non techies' would easily be able to fill the role of a squashed Google Apps admin or manage mail difficulties, or be able to convey those issues intelligently to whatever support mechanism Google has in place.
The situation gets very different when you get an even moderately complex in-house IT environment
But why do you keep suggesting there needs to be some 'complex in-house IT environment' just to allow employees to use office applications and e-mail? We don't have a complex IT environment by any means and we do this for about 50 people.
I would argue pretty much exactly the opposite (albeit not specific to Google Apps)
But this entire thread is about, specifically, Google Apps and Google Mail (I presume you meant both of them in this case, if not, I apologize) and their appropriateness in specific scenarios (namely my own and those of the CTOs/CIOs I mentioned.)
A private company likely has:
1) fewer resources to survive lost sales or opportunity b/c of downtime.
What downtime? Are you envisioning some scenario where there's a private company with an understaffed, overworked IT group and someone burns down a file server someplace right before a big sales presentation? While certainly what I would term 'uncommon' it is a very possible scenario; however, it is simple to argue that a small company could at least remedy the situation themselves whereas Google losing your mail (as has happened), or Google Apps not being reachable (happened several times that I'm aware of for long periods of time) is something you can do absolutely nothing about. That's ignoring the obvious problems with "Hey Bob, where's that spreadsh
Slashdot Mirror
Maybe there's a wait in some places but in Atlanta I was offered an iPhone 4 upgrade (wife has 3GS) with no wait (phone in stock in store) when I was buying my Galaxy S. No thanks... I was happy to find that AT&T hadn't buried the Captivate (their version of the Galaxy S) in AT&T crapware as well; although, you can't sideload apps (not a big deal as I am a registered Android dev anyhow...)
The indignity...
I thought the market was flooded with Aerons after 2000 and 2008...?
"Variously attributed to Lincoln, Elbert Hubbard, Mark Twain, Benjamin Franklin and Socrates"
Sure, they could do it. But when they did it to Cocoa, it broke compatibility (as we've discussed in several posts). Sure, they could do it to Flash too, but it would end up either with broken compatibility (which would make Flash pointless) or have it suck as much as every other tablet produced in the past decade (maybe you don't think they suck, and of course you are entitled to your opinion).
Well, most of the complaints about broken compatibility is related to the method by which the implementation occurred, not the actual design. I don't think they' break the compatibility in Flash (especially since the spotlight would be glaring down on them), and I don't think they'd have to worry about it working differently than it does in Cocoa because they're the same messages generated by the same input from the same OS as Cocoa is getting. Then again, Adobe does make ridiculous mistakes on occasion. I think most tablets suck, but not because of multi-touch. Personally I'm looking forward to the Adam which is looking so impressive it cannot be anything other than a monumental failure to deliver.
reason Apple doesn't want Flash on the iPhone, or even that it's the main reason, but it is a valid point .
I'm not convinced (so we'll have to agree to disagree) that Apple's criticism of Flash is warranted when they won't let Flash run on the iPhone OS because it won't run properly on the iPhone OS (chicken and egg syndrome?)
I'm still going to go with my opinion that the iPhone dev environment is an improvement over BREW, J2ME, or WindowsCE
Well, it's better than most, and that's because it's sort of halfway between a real PC dev environment and a mobile device environment. The problem is, there's no legitimate reason to keep Java or Flash off the iPhone/iPad except greed.
If you mean Cocoa, say Cocoa. If you mean Objective-C, say Objective-C. Even Steve Jobs gets his terminology right (maybe his letter was looked over by a developer, I don't know). Clean up your speech. And while we're on the topic, no one ever calls it the Objective-C development environment. That wouldn't even make sense .
Yep, you've retreated to 'four year old' land. You now want to pretend we weren't discussing developing with flash or Objective-C (what you would now like
to label 'Cocoa' apparently - or, much more likely you would like to divide the individual components up because then you can simply focus on the one you believe you can be the most effective apologist for...)
It is quite obvious, to any reading these posts, that we are discussing Flash versus Objective C development. If you want to label it the X-Code environment, well, that's inaccurate because you don't need XCode to produce binaries for the iPhone/iPad. If you want to label it the gcc iPhone/iPad development environment, well that's inaccurate as well because most people use X-Code on top of gcc. If you want to label it the 'Cocoa development environment', it's technically incorrect as well. BTW, I know quite a few iPhone devs and they ALL refer to it as an, and I quote, "Objective-C dev environment", probably because they all develop for other phones (yes, they exist) and Objective-C is anachronistic to them. So, maybe you can get back to the actual points now instead of throwing up straw man arguments about "Oh, well, I didn't realize you were talking about anything other than the Objective-C specification..."
Either way, even if you insist on your inane terminology, your original point is still wrong. Your original point was that the iPhone dev environment was designed for the PC, which invalidates Steve Jobs' point that Flash was written for the PC. But Apple rewrote their development environment specifically for the iPhone .
Great, you turn out to be just as disengenuous as Jobs now. I pointed out that Jobs stated, without any further specification, that "Flash was designed for PCs using mice" and that this was dishonest because all the underpinnings of the iPhone dev environment, including Cocoa, were designed for PCs using mice. Just because multi-touch events were added to the iPhone/iPad version of Cocoa doesn't mean by any stretch of the imagination, even yours that it would be anything other than trivial for Flash to handle these very same events. FFS, they're simply messages passed along to a view. This is the entire point - Steve Jobs is a dishonest, lying, sack of narcissistic arrogant monkey shit. He is trying to make Flash sound like antiquated technology because it existed before multi-touch, when his entire toolchain existed before multi-touch, including the API that has been 'extended' to handle multi-touch events.
So no, I'm not wrong. He's still a lying prick. Hell, I can't stand Flash as a development environment (I wouldn't touch it with a 10 meter cattle prod if I didn't have to), but that's a personal and subjective dislike, just like Jobs' objections to Flash.
I'm sure you think what he's doing is right though.
Ah, so now you are saying that when you say "Objective-C" you mean the entire Cocoa toolkit.
No, I mean developing for the iPhone/iPad with Objective-C and not Flash. I'm sorry, but if you're going to act like a four year old and try to claim that you were only referencing Objective-C the language specification then nobody can help you.
And you claim that Cocoa on the iPhone is somehow the same as the one on the desktop. The only way you could have come to this conclusion is if you had gotten your information from blogs (or slashdot) and never actually programmed in both.
Actually, I quite clearly point out that they are not the same between Mac OSX and the iPhone OS, in that they are the same API with problematic implementation differences. They're supposed to be the same but Apple screwed the pooch (so to speak.) This of course pokes giant holes in your theory of cross platform flexibility since you can't even even build the same Objective-C code for a Mac that you can for the iPhone (even though the API is supposed to be the same [I wonder if that's why they have the same name, they are referred to as the same in the developer docs, and are only documented differently at the API level... Hmmm... Interesting.])
Furthermore, Objective-C is separate from Cocoa, it has its own standard library. Saying Cocoa is the same as Objective-C is the same as saying QT is the same as C++.
Separate how? You mean it's not part of the Objective-C specification? Of course not. It is part of the Objective-C development environment for MacOSX, the iPhone, and the iPad? Of course it is. It's all one big mess of Objective-C code. Guess what Cocoa is written in? :)
Saying that Cocoa is not part of the Objective-C platform on Apple products is like saying that Win32 is not a part of the Visual C++ development platform.
Incidentally, I'd rather write in Objective-C any day over C++ (although that's not saying much; but it sure is a nice language. The programming world would be a better place if Objective-C had won out over C++)
I think it depends upon what languages you ran into first in University/College. They're all tools in the toolbox. I don't like some sanctimonious prick (Steve Jobs in case I didn't make that clear along the way) trying to bullshit the world about why he doesn't want Flash on the iPhone (or Java, or any other technology that would allow people to bypass his beloved App store.)
Actually, you're simply proving that you haven't the slightest clue what you're talking about. Let's take this most recent 'less than stellar' post of yours apart, shall we? :)
If you were a programmer, you would realize Objective-C is not the same as Flash, it's just a programming language. Flash is an entire UI system, it was designed for use with a mouse
First, you are correct in that I am not a 'programmer', I am a Software Engineer. There's a big difference, and someday you may manage to learn what that difference is - but I doubt it. Second, Objective-C is a language designed in the early 80's and licensed by NeXT, it is considered by most Software Engineers to be a bizarre abomination of C and Smalltalk. When anyone refers to Objective-C on the iPhone or iPad it is obviously in reference to the 'platform.' Perhaps you didn't understand that, ergo your insipid lack of understanding. This means all the Objective-C libraries that make up the Objective-C platform on a given architecture. As for Flash, Flash isn't a UI system, it is also platform. If you were a 'programmer' you would know that. Its manifestation on a mobile device is a runtime - not a 'UI system.' The UI portions of the runtime were designed for use with a mouse, but so were all of the Objective-C UI libraries ever created before the introduction of the iPhone.
If Apple had ported their UI toolkit directly to the iPhone, it would have been lame. Instead, they rewrote it. It is really not compatible with Cocoa on the desktop. Adobe could do similarly with Flash, but then it wouldn't be Flash anymore, it would be something different, even if they still called it Flash.
They did port their UI toolkit to the iPhone, and it is lame - ever heard of Cocoa? LOL. Read the dozens of blogs about why the iPhone API implemenation of Cocoa appears to have been written by some interns over a few weeks and why it should have been implemented differently. No, it is not compatible with Cocoa on the desktop because it's f***ed up.
"Adobe could do similarly..."? You appear to be confused. Flash has its own windowing system that is encapsulated in the runtime, including rasterization. Why would Adobe want an intentionally cross platform product to look and act differently on the iPhone/iPad? Stick to being a programmer, you'd be a terrible Software Engineer.
For now, when people write Flash apps, they expect the user to have a mouse. When people write iPhone Apps, they don't .
I think what you meant to say is that when people write Flash applications they expect users to have a single input device for pointing. This is mostly true since people are only just now targeting multi-touch devices with Flash applications. There are already Flash/Flex authoring solutions (APIs) which support multi-touch and gesture based computing.
As for platform flexibility, Flash doesn't even really support Linux on 64 bit architectures. Objective-C on the other hand, supports over 40 different architectures. There's no comparison in flexibility. When Brad Cox created Objective-C, the whole purpose was to bring the flexibility and modularity of Smalltalk to more common use.
Actually it does and has since 2008. Plus, there are open source flash players. You claim that Objective-C supports over 40 different architectures, which is funny because what is actually more accurate is that GCC supports many architectures and someone wrote a front end for Objective-C. I could spend a weekend and with lex/yacc or building my own front end for gcc to create a new language called 'phantomfive-C' and it would suddenly and miraculously support over 40 different architectures. It would then be, according to your criteria, just as flexible as Objective-C. Of course, that's a stupid way to look at things, but hey, you think the way you want. Objective-C used outside of the walled gardens of the iPhone/iPad? Nowhere, why? Try writing an Objecti
You appear to have difficulty reading, is English a second language for you? I quite clearly stated it was ported to the Macintosh.
We're still all waiting for you to explain how it is you managed to deduce (and I use that term very loosely) that Flash was not designed with platform flexibility in mind and Objective-C was.
I mean seriously, anyone reading this thread is just dying to hear your reasoning behind that... :)
Wow, you're really bad at this. You're now attempting to argue that Flash, which was built to run on multiple architectures and operating systems on the same architecture was not designed in a way to make it usable anywhere, but that Objective-C, which was designed to be run on a very specific hardware system and was then ported (warts and all) to run on Macintosh hardware and then, yet again, ported to run on Apple's iWhatever hardware was in fact designed to run on all types of devices. LOL!
with flash he's talking about the user interface
No, he isn't, and this is why this is so important. You are aware, no doubt, that this great bruhaha recently blew up because you can no longer compile iPhone/iPad applications with non-Apple tools, right? Thus, barring Adobe's compiler for the iPhone.
You're obvious incapable of understanding anyone's point other than your own. Jobs bashes flash because it was designed for usage on PCs, not mobile devices. Jobs does so in the complete understanding that he's being totally disengenuous (look it up) because wants you to use Objective-C to develop with instead and Object-C was designed for usage on PCs. It doesn't matter that it's been ported retard.
I don't think you are a programmer, because I don't think you would have this misconception if you were.
I don't think you're very logical, I am obviously pointing out that one of the problems Jobs has with Flash applies to Objective-C in exactly the same fashion. Objective-C was designed for desktop computers.
Yet another example of Steve Jobs talking out his a** and only technical people realizing what a lying, dishonest, <ChevyChase>sack of monkey shit he is</ChevyChase>...
Cheeky bugger! ;)
...between reducing user choice but improving reliability and efficiency myself.
Why do non technical people believe the words that pour out of Jobs' gob? The man, and Apple's advertising, is infamous for saying things he knows are not true. Hell, my favorite recent example of this was when he bashed Flash about being designed for PCs as one of the reasons not to use it on the iPhone/iPad when his company makes you use Objective-C! LOL. Guess what Objective-C was designed for?
I agree that maturity is certainly a major aspect of the problems relating to web application development; however, the primary reason is still the fact that the web browser is built around displaying HTML/XHTML and HTML was not intended to be used for applications. x86 frameworks are specifically designed for the purpose of building application (although I'm sure we could find some that would make us say 'well, maybe not this one...' ;))
"Web development may seem like a pain, but last I checked, it's the only truly cross platform development environment that has ever existed
It's not only 'not cross platform' its not even 'cross browser'. Java Applets (and I am no fan of Java) are far better at cross platform capability than HTML when it comes to applications (and Java has issues in this department as well.) ANSI C code with a dizzying number of #ifdefs would qualify as 'cross platform' by that measure.
I'm not saying things are hopeless and not fixable, I'm simply saying that the current environment for building web applications is not just poor, it's terrible.
Chromium is an example of an attempt to bring a app container to the web world, but its problem is that you still end up using HTML to try and develop applications. W3C needs to superset HTML and leave HTML as the typographical/layout aspect of the internet. It should simply be a media type. Hell, look how long and painful (and still pretty crappy) the process has been for Flash to go from simple media container to Flex/AS3 application environment. You can make amazing full on applications in Flash that work very well across OS/Hardware architectures, but it's still kind of hokey.
POST and DELETE
You're confusing HTTP with HTML.
If you want to get picky, 'computer' were 'never designed' for media playback, using your criteria
Uhm, you're completely missing the point. Computers don't have to be 'designed' for media playback, media playback is simply an expression of the inherent capabilities available to a computer. A web browser is an application, not an operating system or hardware, that people are trying to force into being an application container. It is not meant for these types of things. People have found ways around these shortcomings; however, they generally tend to be poor, kludgy, and overly complex. This is, again, because HTML, XHTML, and such, are not intended to be used for application development.
Flash is another example of something that was not intended to be used for application development, yet it has grown to accomodate these type of possibilities and since the introduction of Flex, it's far less horrid than previously - but it still isn't a good development environment because of all its legacy baggagejust like web browsers.
The problem with web app development is that the environment was never intended for interactivity, it was designed for displaying information. Everything added since then to create 'apps' has been bolted on (sometimes cleverly, sometimes not so cleverly) and implemented differently between browsers and (relating to plugins/extensions) differently between operating systems. Developing for x86 machines running Windows and/or Linux isn't a "tightly controlled ecosystem" but you can certainly develop excellent applications, why? Because the environment was intended to run applications.
For the users, yes, web applications are great, and for some things, they are the way of the future
The idea of Web applications is great, web applications themselves that rely on HTML/XHMTL and JavaScript are awful. Personally, I think the way of the future is purely web services consumed by specialty applications, not what we consider a 'web browser' today, where the HTML aspect of the web (typography/layout) is not the primary medium of the internet - data is, and HTML is merely a subset of that. Think of it like Google maps except that the UI isn't some crappy hodgepodge of the limitations of HTML but a specialist client or client library that eats/breathes/sleeps Google Maps web API. That's a few years off though (at the very least) but certainly the way of the future.
Now, what I hope, but which is a pipe dream since fragmentation is so much more likely a scenario, is a single interpreted/JIT'd programming language that doesn't suck and/or isn't pushed by only one company (I'm looking at you Java, and you Flash, and to a lesser extent you .NET) that becomes a core of every 'web browser.' This would avoid all the disparate tools approach to consuming data which is where the internet (not the web) is most likely headed...
I would certainly love a Java/.NET capability in something akin to applets except with good UI code, good tools, and a safe but useful (as in access to some native hardware like the video card) sandbox (yeah, I know, Santa Claus is real too...)
It's 2010. Why would we be finding something so simple 'incredible' - oh, wait, it's because people are trying to use the browser to do everything and it's a horrifically bad idea.
Look, I like HTML5, just as I like HTML4, but the web is a terrible programming environment. Javascript is great, but to listen to all the web 2.0/3.0/x.x proponents blather on incessently about how web applications are great and the way of the future and... blah blah blah. It's ridiculous.
If you want applications to run through your browser and you want them to look good, work well, and offer lots of features commonly found in 'offline' applications, great - lobby the W3C to come up with something - but using the mess that is HTML (of any flavor when used for applications) and Javascript in order to offer the abilities found on any PC since the early 80's is ridiculous.
Now, all that being said. Yes, it looks very nice and is a nice indicator of possibilities with HTML5 and the canvas element.
...to play multi-player on XBox Live. What a bunch of greedy bastards. The only thing this type of behavior does is make me more selective about the games I play, for example, I'll never buy another Ubisoft game while they have that 'always online' DRM. I stopped playing Company of Heroes when they went this route until you could play with the disc installed again. Greedy bastards.
I think for personal usage your suggestions are fine, but forcing our marketing/sales pukes into using encryption is a non-starter ;)...
Most people on slashdot are aware of that; however, there's a difference between your e-mail passing through someone's server your e-mail being permanently kept on that server and all of your corporate documents being stored there as well. Sort of like the difference between your postcard passing through the postal system and your post cards all being stored at the Post Office and you can get a look at them if you wish.
Sigh... I had a very long, verbose, probably boring as sh** reply to your post when I closed the wrong Firefox window... Basically, I disagree on some points and agree on others, as was the case previously ;).
Then we are in agreement.
But my position, as seen in the original post which you replied to, is that I am clearly referring to my own situation and the situation of the CTOs/CIOs I know. Not a generalist statement against Google apps.
I can only go by my experiences in this area (not other CTOs/CIOs that I know) and state that we've have to restore from backups twice in the past 5 years and had absolutely zero difficulties doing so. Now, I can certainly imagine that in complex environments this can be quite problematic; however, all of this is academic and is entirely dependent upon process, policy,hardware, and software. It's like stating that it's less risky to let someone else drive than it is to drive your own car. In some cases yes, in my case, I would argue no, it all depends on the details - and again, I wasn't making generalizations, I was stating my opinion about why I don't use it and the opinion of those in similar positions to myself whose opinion I am aware of.
But why would a 50 person company need 24-7 support for office applications and e-mail?
I'm sorry but we're an ISV and we have some pretty sharp people here, but none of our 'non techies' would easily be able to fill the role of a squashed Google Apps admin or manage mail difficulties, or be able to convey those issues intelligently to whatever support mechanism Google has in place.
But why do you keep suggesting there needs to be some 'complex in-house IT environment' just to allow employees to use office applications and e-mail? We don't have a complex IT environment by any means and we do this for about 50 people.
But this entire thread is about, specifically, Google Apps and Google Mail (I presume you meant both of them in this case, if not, I apologize) and their appropriateness in specific scenarios (namely my own and those of the CTOs/CIOs I mentioned.)
What downtime? Are you envisioning some scenario where there's a private company with an understaffed, overworked IT group and someone burns down a file server someplace right before a big sales presentation? While certainly what I would term 'uncommon' it is a very possible scenario; however, it is simple to argue that a small company could at least remedy the situation themselves whereas Google losing your mail (as has happened), or Google Apps not being reachable (happened several times that I'm aware of for long periods of time) is something you can do absolutely nothing about. That's ignoring the obvious problems with "Hey Bob, where's that spreadsh