Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Good point and I'm hoping that apple lawyers are already working on a way to allow for the "good" (unity) and prevent the "bad" (flash). But worst case apple will stick with the total ban.

Apple will just have the reviewers let stuff pass, and keep the language as it is. Consistncy has never been a feature of the app review process.
 
MFC and Win32 need not apply. All I'm saying is if you want to be efficient on the Windows platform you stick with .Net and don't stray too far since it's their platform. The same thing with Apple, stick to Cocoa.

Hum... no. You can stick with vendor platforms, but you will be much less efficient and will have to reinvent the wheel a few times in the process. 3rd party frameworks, be they on OS X, Windows or even Unix provide RAD environnements that are easier to code to than the native toolkits and APIs. They also offer portability and nowadays, native look-and-feel.

You can argue that you will get the latest features ahead of everyone going the native route, but you will have to hand code everything yourself. A toolkit implementor may be a few weeks late, but all the work will usually be done for you and you will have fewer API calls to change to make it work.

QT is really an amazing platform. wxWidget is really good for GUI work. Some languages like Python and Ruby are better than C or even .NET managed languages to bang out a quick GUI to administer some service or daemon. Web developpement ? .NET is a nightmare. J2EE is where it's at.

OpenGL lacks many of the clear API's and performance found in Direct X on the Windows platform. So if you want to get performance you go with the Microsoft Direct X API vs OpenGL.

But that wasn't your question, you asked which was easier to code for. OpenGL is. OpenGL also offers the advantage that your game with work on any platform that supports OpenGL. It will also be easier to port to OpenGL ES for mobile devices such as the Nintendo DS or iPhone or Android. It will be easier to port to PS3.

Heck, about the only advantage of using DX is getting an almost free port to Xbox360...

You keep changing the subject when getting clear answers, it seems to me you are not qualified to have this discussion.
 
Maybe read the rest of the reply before you post, or maybe you have limited reading experience?

So mac not having photoshop64 for one generation is not a reason to switch to windows nor do I believe anyone actually did switch because of it.

I did read your post. You're still wrong. My entire former company switched to Windows for 64-bit Maya and 64-bit Photoshop. I don't have any more official numbers than that, but that's 20+ production artists who dumped the mac for 64-bit.
 
Hum... no. You can stick with vendor platforms, but you will be much less efficient and will have to reinvent the wheel a few times in the process. 3rd party frameworks, be they on OS X, Windows or even Unix provide RAD environnements that are easier to code to than the native toolkits and APIs. They also offer portability and nowadays, native look-and-feel.

You can argue that you will get the latest features ahead of everyone going the native route, but you will have to hand code everything yourself. A toolkit implementor may be a few weeks late, but all the work will usually be done for you and you will have fewer API calls to change to make it work.

QT is really an amazing platform. wxWidget is really good for GUI work. Some languages like Python and Ruby are better than C or even .NET managed languages to bang out a quick GUI to administer some service or daemon. Web developpement ? .NET is a nightmare. J2EE is where it's at.



But that wasn't your question, you asked which was easier to code for. OpenGL is. OpenGL also offers the advantage that your game with work on any platform that supports OpenGL. It will also be easier to port to OpenGL ES for mobile devices such as the Nintendo DS or iPhone or Android. It will be easier to port to PS3.

Heck, about the only advantage of using DX is getting an almost free port to Xbox360...

You keep changing the subject when getting clear answers, it seems to me you are not qualified to have this discussion.

Honestly, KDE doesnt do QT justice. It's a top notch example of QT though.
 
There is a solution for Unity and Adobe... a couple of years ago I and a couple of friends with an engineering background where implementing a code translator for Java and .NET

1. Unity already produces input that is to be run through XCode ( in c/c++/obj-c and javascript). That's not new.

2. The 3.3.1 section explicitly cites "intermediate translation" and "tools" (presumably tools that aid in this process) as an example of what the intent of these new clauses are to prohibit. So you haven't put yourself into compliance with the terms, just hoping not to get caught. That is a poor position to be in if going to invest substantial amount of resources into the app. ( get to approval process and Apple nukes you on grounds they somewhat clearly outlined in the contract).



they need to do is produce a Objective C output which has to be compiled with Xcode...

Again the clause explicitly says " originally written". If that is the common meaning of 'originally' they are pointing to the origins. Note that you are producing output. You need to do some mental tap dancing if 'output' is an 'origin'. An 'origin' is an input. [ Different story if 'originally' is suppose to mean "novel" , but that doesn't line up with their example as well. ]

The Flash library is extremely likely already a massive C++/C pile of code. That's not the problem. The issue will be the actionscript that may/may readily objective C (or in C without burping in a runtime object evaluator) . If ActionScript was a strict subset of ECMAscript then good chance could pump it through the Javascript engine. However, most likely has calls to proprietary APIs so end up with compiling it down to binaries. There are parts of the scripts that may be too dynamic to statically determine what specifically trying to translate into (prototype based isn't quite like class based. There are definately some semantic gaps. )

What Adobe probably did was effectively run the JIT (just-in-time) compiler over all of the code (or likely bytecode) and produced binary. The compiler backend of the compiler could conceptually be tweaked to output C but that's probably not a trivial task given the intermediate representation passed to it. It would be easier to drive the translation off the front end or early intermediate format but I'd bet the front end isn't designed for that either. In short there isn't a "meta representation" of the actionscript other than the actionscript text itself.


Even if can going to need ActionScript global classes/methods. All they have to do is scan for those. Extra gratuitous stuff isn't going to make a difference to a specific scan looking for specific patterns.
 
I did read your post. You're still wrong. My entire former company switched to Windows for 64-bit Maya and 64-bit Photoshop. I don't have any more official numbers than that, but that's 20+ production artists who dumped the mac for 64-bit.

That's different. You say they made the switch for 64 bit photoshop AND 64 bit Maya. Since Maya won't be going 64 bit on Mac for a long long time, if you are a company that uses Maya, it makes sense to go Windows anyway. (Why would they using Maya on Mac in the first place, it's not even comparable to the windows counterpart)

For only Photoshop, everyone knew that CS5 would be 64 bit in the first place. So switching doesn't make sense, you can just wait 1.5 years instead of forcing people to get acquainted to a new platform.
 
That's different. You say they made the switch for 64 bit photoshop AND 64 bit Maya. Since Maya won't be going 64 bit on Mac for a long long time, if you are a company that uses Maya, it makes sense to go Windows anyway. (Why would they using Maya on Mac in the first place, it's not even comparable to the windows counterpart)

For only Photoshop, everyone knew that CS5 would be 64 bit in the first place. So switching doesn't make sense, you can just wait 1.5 years instead of forcing people to get acquainted to a new platform.

Because switching from OS X to Windows is a big pain ? Really... Switching OSes nowadays is not like it was 10 years ago. Vendors offer cross-grade licenses, very few software packages are exclusive (and when they are, Windows is it).

If the guys were running into issues where 32 bit Photoshop was slowing them down, and I knew I had to wait 1.5 years for it to be fixed or simply cross-grade to Windows, I know what choice I'd make in something bigger than a 2 person shop.

And the fact is, you're still arguing this isn't so, when in fact, there are examples out there. Let me remind you of the original point : "Apple didn't hurt any users when it dropped Carbon64". None. Nada. That point has been proven wrong. The fact you're trying to insist that people didn't move just goes to show your delusion in the matter, not actual real world experience.
 
Wait, there's nothing here about breaking backwards compatibility. In fact, they are forcing people to use backward languages (C, C++, Objective-C) and preventing them from using newer languages with better features.

Seriously? You must have no experience as a programmer at all and likely no real training either. A web hack statement if I ever saw one.

C/C++ are the bedrock of the industry. Most real (not web) game development is done in C++. C/C++ are practically the ONLY choice for system work (OS/Network/telecommunications).

When performance really matters, developers turn to C/C++. It might not be fashionable but it is the right choice.
 
Seriously? You must have no experience as a programmer at all and likely no real training either. A web hack statement if I ever saw one.

C/C++ are the bedrock of the industry. Most real (not web) game development is done in C++. C/C++ are practically the ONLY choice for system work (OS/Network/telecommunications).

When performance really matters, developers turn to C/C++. It might not be fashionable but it is the right choice.

You could probably chuck in C# & Objective-C anyway and that statement would stay reasonably true.
 
Thanks Mr. Jobs for keeping the standards high and for the awesome 4.0 update. No one but Apple really knows what is best for Apple. Sometimes excellence involves having to courage to make tough and unpopular decisions.

It's really more like Mr. Jobs thinks he knows what is best for us as individuals, not just Apple. That is what is scary. And if their standards were as high for their IDE (XCode) as they are for their non-developer users, the developer community wouldn't be taking this quite as hard. The fact is that XCode and the tools that surround it LOOKS very nice, but in terms of a modern IDE, it is HORRIFIC! Third party tools like Unity, Torque, Adobe Air, PhoneGap and others allow the developer to leverage their expertise on other platforms into creating apps for the iPhone. In fact, there have been quite a few apps that Apple has demoed in their commercials on TV and online that were developed with some of these 3rd part tools.
This is purely a power play by Apple. I think it will hurt them in the long term. It certainly has me reconsidering my iPhone developer renewal coming up in June. If I had already bought one of these third party tools as many others have, I would be even more unhappy.
 
Because switching from OS X to Windows is a big pain ? Really... Switching OSes nowadays is not like it was 10 years ago. Vendors offer cross-grade licenses, very few software packages are exclusive (and when they are, Windows is it).

If the guys were running into issues where 32 bit Photoshop was slowing them down, and I knew I had to wait 1.5 years for it to be fixed or simply cross-grade to Windows, I know what choice I'd make in something bigger than a 2 person shop.

And the fact is, you're still arguing this isn't so, when in fact, there are examples out there. Let me remind you of the original point : "Apple didn't hurt any users when it dropped Carbon64". None. Nada. That point has been proven wrong. The fact you're trying to insist that people didn't move just goes to show your delusion in the matter, not actual real world experience.


No. You still haven't given a single example of an end user who migrated to windows ONLY for photoshop64. A company who uses Maya should have migrated to windows even if CS4 for mac was 64bit. So photoshop has nothing to do with it.

And the issues people would have with photoshop32 bit are NOT bad enough to make someone migrate platforms for 1.5 years. If photoshop64 had a considerable speed difference compared to photoshop32, which showed itself on everyday tasks, then it would make sense. To migrate for a 10% speed increase on "certain" tasks instead of waiting 1.5 years doesn't make sense at all financially.

This is not a render farm where a 10% difference means 10% more frames rendered per day, hence 10% less time spent on rendering the whole project.
 
I think everyone is missing the point here, Apple is being Anti-Competitive with this one.

This would be like saying anything written fro the Mac can only use these langauges. (Or anything written for Windows can only use these languages), even if other compatible languages are developed.

I still maintain that forcing everyone to buy through the App store is illegal as well.
 
I think everyone is missing the point here, Apple is being Anti-Competitive with this one.

This would be like saying anything written fro the Mac can only use these langauges. (Or anything written for Windows can only use these languages), even if other compatible languages are developed.

I still maintain that forcing everyone to buy through the App store is illegal as well.

What law is being broken?
 
No. You still haven't given a single example of an end user who migrated to windows ONLY for photoshop64. ....

The bottom line is, if Adobe stopped developing CS for the Mac, the Mac will die in the corporate/design environment.

As soon as ONE of your larger clients moves to the next version of CS, you have to move to it, too. I know my company would switch in a flash (pun intended).

Apple has been fairly unsuccessful with its Pro apps, so it cannot sustain sales based on those.

Methinks Jobs is playing a dangerous game with the company. I have been an Apple fan for well over a decade and a half, but this iPhone/iPad thing is turning my stomach.

It's the first time Apple has been the provider of a truly successful ecosystem, and it is showing that it can be more evil than MS and Quark put together.
 
Methinks Jobs is playing a dangerous game with the company. I have been an Apple fan for well over a decade and a half, but this iPhone/iPad thing is turning my stomach.

It's the first time Apple has been the provider of a truly successful ecosystem, and it is showing that it can be more evil than MS and Quark put together.
Exactly.
I interpret evil to mean not enticing customers to buy their products on merit, but rather exert control via terms, restrictions, threats to force consumers and partners to conform to their wishes.

Its a risk on the iPhone now that Android is a real competitor. You can only try this stuff when you have a far superior position. Most analysts believe Android in aggregate, will overtake iPhone in market share this year. Apple may well be encouraging developers and some consumers to move to Android.
 
The bottom line is, if Adobe stopped developing CS for the Mac, the Mac will die in the corporate/design environment.

Sure great. So what does Adobe do when Microsoft bans Flash-to-App from the new WinPhone7 Appstore(modeled on iPhone Appstore and promoting Silverlight, so not out of the question)?

Step 1: Stop developing for Apple
Step 2: Stop developing for Microsoft.
Step 3: ??
Step 4: Profit

Seriously folks. Any suggestion that Adobe kill a chunk of their own business because Apple is maintaining control of their own platform is utterly moronic.

It is not a reasonable management reaction, it is a pouty 12 year old tantrum reaction.
 
Since Maya won't be going 64 bit on Mac for a long long time,

Nope. It's 64-bit this month on the mac. Too late for many, though.

A company who uses Maya should have migrated to windows even if CS4 for mac was 64bit. So photoshop has nothing to do with it.

Photoshop has everything to do with it. There was a 10 person 2d department at my company, and those users needed Photoshop 64-bit. The TD's, modelers, and animators (different dept.) needed Maya 64-bit. Hell, if Photoshop was 64-bit on the mac a while ago, they would have stayed Mac. The finished files don't matter so much.

if you are a company that uses Maya, it makes sense to go Windows anyway. (Why would they using Maya on Mac in the first place, it's not even comparable to the windows counterpart)

You don't seem to be aware of the Autodesk releases or the need for 64-bit applications, so I'll trust my own council, co-workers, and experience on this one.

You are thinking in terms of budget based on your experience, which seems to be very different from mine.

No. You still haven't given a single example of an end user who migrated to windows ONLY for photoshop64

Very few people ONLY use photoshop as their app, that's why. So how about this: the 2d/painting/texture dept needed 64-bit, the animators, modelers, and TDs needed Maya 64-bit. You don't have to believe it, though.

For only Photoshop, everyone knew that CS5 would be 64 bit in the first place. So switching doesn't make sense, you can just wait 1.5 years instead of forcing people to get acquainted to a new platform.

Wrong, yet again. Being forced to waiting 1.5 years is exactly why people who need it would switch. On top of that, people didn't know how long the wait would actually be. In production, you can only weigh tools on what they can do now, not the promises to come.

Production artists spend most of their time in the application, not the OS. A few fumbles in Windows explorer or learning new hotkeys is not something to worry about.

Regardless though, this is all off topic.
 
So, all I have to do is "think" that I have something better, and I'm free to violate any and all user interface guidelines for a platform?

Ah, very interesting comment. I'd love to explore this with you. I understand user interfaces and I *hate* when applications don't adhere to the guidelines or rules. They should be rules, but that's another conversation.

In my mind and experience (both Windows and Mac), there is one system where applications play by the rules, and there is one system where applications appear to have been written for another operating system, or set of guidelines.

Windows is the operating system where applications are free to choose the way they interact with the user. The one at the top, Microsoft, is one of the worst offenders. They write the guidelines and then break them in their own apps.

I'd love to talk more about user interfaces and user experience, and to get your perspective on Windows vs. Mac, and what you think about that f*****g ribbon in Office. ;-)
 
Sure great. So what does Adobe do when Microsoft bans Flash-to-App from the new WinPhone7 Appstore(modeled on iPhone Appstore and promoting Silverlight, so not out of the question)?...

Right.... Even better, what happens when 2012 comes around and the world ends?

MS has stated that it is working with Adobe to make the user experience better on WP7. Google is working with Adobe to make the user experience better on Android.

Apple is not. Apple wants it all, every penny, regardless if it hurts the user experience (web lite only on the iPad), or if it hurts its developers. That's what I mean by "evil."

What's moronic is, that the lemmings think it's good for them.
 
The bottom line

At the moment it isn't exactly clear what effect the change in policy will have (or even what the change actually is). Developers would prefer as few restrictions as possible. It has nothing to do with developers being lazy but simply choosing the right tool for the job. If the right tool for the job is not available because of restrictions from Apple, the cost of developing applications for the iPhone will go up, which means that the risk of developing for the platform will go up as well. Whether the risk is still acceptable is dependent on the probabilty of turning a profit.

If it is difficult for the end user to separate the good from the bad in the App Store then that is an issue that Apple need to address.

Whether iPhone or Android (or some other platform) will win in the end is impossible to say at the moment but the differences in ideology seem to go in opposite directions. In other words, the next five years will be interesting.
 
Right.... Even better, what happens when 2012 comes around and the world ends?

MS has stated that it is working with Adobe to make the user experience better on WP7. Google is working with Adobe to make the user experience better on Android.

You are mixing issues.

Flash in the Browser and Flash in the Appstore are different things.

Microsoft is competing directly against Flash with Silverlight. They may have a flash plugin for the WP7 browser, but flash in the Appstore is counter to Microsofts interests just as much as it is against Apples, if not more so. But it will likely be 2012 before Adobe bothers targeting the platform, so we won't know for a while.
 
The ending kind of ruins it, but it's pretty funny up until then.

Hitler's iPhone app is rejected by Apple

http://www.youtube.com/watch?v=sVkqbycvuKw




Aaaaaand just to lighten things further:

page_3.jpg




Hee hee:

jobs_big_brother.jpg
 
Seriously? You must have no experience as a programmer at all and likely no real training either. A web hack statement if I ever saw one.

C/C++ are the bedrock of the industry. Most real (not web) game development is done in C++. C/C++ are practically the ONLY choice for system work (OS/Network/telecommunications).

When performance really matters, developers turn to C/C++. It might not be fashionable but it is the right choice.

It's still backwards for things like iPhone apps. While you wrote this post, was your right hand over your heart and your left over K&R. I have a college education in computer science and have been doing different projects over the years from Web to system developement to scripting. I'm actually more at ease writing C than anything else.

Yet I realise having to malloc() and free() everything and bounds check every array, keep track of pointers is a pain. Modern language abstract this. Sure it might remove some performance and power from the programmer, but it accelerates time to production, which is an important metric, unless you're a basement coder.

From your comment, you seem very much like a basement coder. In the real world, about the only place where performance still matters to the point of using low-level languages with no garbage collection or automatic memory management is high performance 3D games.

Heck, most Web and smaller 2D games on things like the iPhone are written with abstraction layers and they run just fine.

More than anything, your failure to realise this shows me you have absolutely 0 experience in the field of software beyond either your code monkey job at EA or your basement.

For better or for worse, managed languages and VMs are here to stay. If you want to remain a low-level programmer, get a job writing such VMs in the first place or go to OS level coding.
 
From your comment, you seem very much like a basement coder. In the real world, about the only place where performance still matters to the point of using low-level languages with no garbage collection or automatic memory management is high performance 3D games.

Said by someone who has probably never done any professional embedded development for any extremely low cost high volume industrial or consumer product, nor any DSP development, nor any OS kernel development (linux, BSD, et.al.), nor any OpenCL for non-game supercomputing applications, and etc.

Managed languages have their place for certain applications, such as where time-to-market and verifiability are more important than product performance and unit costs. But, because of the latter, there are many professional positions for which I would not (and have not) hired people because of their lack of understanding of either low-level coding, or the low-level implications of trying to solve the problem at only a high level.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.