If you think this whole thread is pointless, then why post in it? See Cas’ posts for examples of similar moves by both Apple and other companies.
Good for you. Sorry for not giving you the attention you think that you deserve.
This. Apple has no reason to get rid of OpenGL. Metal will filter down through third-party engines while SpriteKit and SceneKit, which basically compete with simpler third-party engines (like Cocos2d, Corona, JMonkey, etc) will continue to benefit from OpenGL’s continued existence. Large-scale developers creating graphically-intensive games may use Metal directly, but most game developers will use it with Unity, and other popular engines, as the interlocutor. Generally speaking, Apple just wants people to be able to make the best games possible on the devices, because games make a lot of money for Apple. If Apple wanted to gain OS market share, there would be far more effective ways to do it than “locking” people to a low-level graphics API (which most people would never use directly anyway).
This thread is almost literally wrung dry, however…
[quote]If Apple wanted to gain OS market share, there would be far more effective ways to do it than “locking” people to a low-level graphics API (which most people would never use directly anyway).
[/quote]
I’m curious, what would Apple have to do?
Make iOS available for use on third-party devices.
Not sure how that would go down.
I’d rather have Android on an iPhone than iOS on an Android Phone.
But I’m sure that it would get picked up at least on some basis. Better shot at increasing market share, anyway, than trying to lock the tiny subset of people who’d even use a low-level graphics API to the platform. I mean, seriously. How many small-time developers do you imagine that would apply to? Not many, in my estimation. Any development outfit with people experienced enough to use Metal directly (i.e. not through an engine like Unity) is likely too big to get “locked in” in the first place. They’d have teams working on iOS and Android releases already.
An idea that could never fly I think… Apple tried that in the 90s with the CHRP and Mac clones. I think the lesson they learned there was, “Don’t!”. They’ve got a lucrative hardware business, the most lucrative one in the world by all accounts, so there’s nothing needs changing in that respect. If we want to find answers to our speculations of the future we only have to look at the past to get a good idea of how things might turn out.
Cas 
I’ve re-skimmed. I’m not seeing any examples. He’s repeating “They’ve done it before and they’ll do it again.” like a mantra but isn’t giving any “bad” examples of what exactly “it” is. I’m translating this into: “I don’t feel like learning anything new”. And that’s fine. I’m sure a high percentage of Cobol programmers felt like that way too. And I’ve very glad I don’t need to program in Cobol on a monolithic OS using round-robin scheduling. Personally I think the big players don’t “shake things up” enough and we (as programmers) are stuck with antiquated tech. So it goes.
Support for OpenGL in it’s current form isn’t going going anywhere for quite awhile. Too much investment in too many sectors to kill it off. No margin in it. Microsoft hasn’t tried because it would be terrible idea. They just don’t pour much money into it either. No margin in that either (at least as long as nvidia and AMD don’t totally drop the ball.) Good business. Let someone else do your work (or the lion’s share) for you and spend your resources elsewhere. Oh yeah, I don’t think it’s been mentioned but iOS 8 now has WebGL support by default…oh and wasn’t Apple actually pushing HTML5? I’m not confused am I?
On metal. This isn’t even the same playground as OpenGL or DirectX so let’s not pretend like it is. The only impact on OpenGL should be it’s yet another example (in many coming out) that all isn’t hunky-dork in GPU land. Real “threats” to OpenGL are probably in the general purpose GPU techs that are being developed by pretty much everybody. Well actually OpenGL is OpenGL’s biggest enemy.
On swift: I can’t say if it’s a good idea or not…I don’t know enough about it. I can’t say why they even created it in the first place. It could exists for the exact same reason as why we have Java. Some Sun employees were bored and they hated C++ and its tooling. So rather than have them jumping ship, Sun tossed them a bone to chew on and out pops Java. Swift was created by the LLVM creator. Maybe he needed a bone. Whatever the reason, it’s about time they tried to killing of “industry standard” Objective-C thank you very much. Maybe it’s an awful idea. So what? Like I said: I like it when people try to shake the tree. Would C++ been an better idea? Or one of the dynamically typed languages?
LATE BREAKING NEWS!
Yeah yeah: examples would be good. Stuff that Apple did for awhile after kicking-out Jobs isn’t very interesting…they were just doing stupid shit right and left and didn’t have any reasonable direction. Pro-tip: Don’t choose marketing people clueless in tech to head-up a tech company. Insured fail.
I’m in the developer program now, so I’ve been able to use the Xcode 6 beta and work with Swift. It’s pretty excellent thus far, even if the IDE itself, in beta form, is still sort of buggy. Code completion in Playgrounds, for example, is not currently that helpful. But the Swift language itself is a major improvement in many ways over Objective-C. Inferred types are quite nice, and the way the language prefers that you use actual constants as much as possible (and not just for global data, for example) is refreshing. The syntactic sugar with ranges (instead of Objective-C’s clunky insistence on having to initialize an NSRange object, and then pass that object to a method as a parameter), and so on, is also great. Oh, and the fact that pointer arithmetic is not going to be a thing anymore, that’s great too. String interpolation, and generally getting rid of the whole mutable/immutable class thing is excellent.
Apple’s main motive in developing Swift and moving away from Objective-C was, I think, to make Mac development more welcoming for people who are used to working with more modern languages like Python, Ruby, and so on. The language gives you all the OO perks, but also embraces functional programming. Methods can take functions as parameters and return functions as well. Methods are actually denoted with the keyword “func” now.
A lot of people claim it will be easier for programmers to learn, but in a way, I think Objective-C was actually easier, if only because it had far fewer things to learn, like optionals, tuples, generics, and so on. Objective-C is, in many ways, a far more stripped-down language. But it’s also clunkier, and its dependence on its C underpinnings leads to inconsistencies that really start to gnaw away at you after a while if you ever end up using both in the same project.
Well… Java on OSX, for one. Deprecated, then moved to optional download, not even sure if it’s available at all from Apple in 10.9. It’s not like Java isn’t available any more, but it broke everyone’s Java stuff at around the time of 10.6 and we’re still suffering from that now which is irritating.
Microsoft and OpenGL is another example. Sidelined, Direct3D appears, investment ploughed into D3D.
Internet Explorer’s mid-term strategy appeared to be to try and dominate by effectively changing the framework that the whole web worked on. Fortunately didn’t prevail and they’ve embraced open standards.
Actually Microsoft zap tech far quicker than most. .net, WPF, GDI+, etc… all strange offshoots that lasted just a short time. Their current flavour of the month is the deadly shit trio of HTML5/CSS3/JS.
It’s not like I think that it’s weird or unusual or anything… just something that happens, and usually for entirely sensible pragmatic reasons. The way I see it right now is that OpenGL is up against a bit of a dead end because of limitations with the design of the API and so various OEMs are coming up with all sorts of closed proprietary APIs to deal with the shortcomings, which solves just two problems (easier programming on one particular platform, and performance on that platform) and creates loads of other problems (all centred around porting friction). As Riven says, a clean break OpenGL 5.0 that looks at these new APIs would get things back on track. Without such a new OpenGL API though we’re in an annoying wilderness of non-portable APIs and code and it’s more or less back to the dark ages.
For the record, I do hate learning new ways to do the same old fucking thing I’m only really interested in new ways to do new things. Right now where things are currently interesting to me are the areas of multithreaded design and the gradual elimination of runtime exceptions. I see many solutions sprouting off in all sorts of directions but many of them make fundamental mistakes in lexical design or syntactical design that almost look like “trying to be different for the sake of it”. One of Java’s best secret weapons was its sheer lexical simplicity and consistency, along with its superficial similarity to C++.
Cas
Scanning rather further back in the thread btw will elucidate what the thread was actually all about (go and read the linked article), which is why this whole discussion is taking place:
[quote]With Metal, Apple hopes to replace the industry-standard 3D-graphics API (application programming interface), called OpenGL, with its own development API
[/quote]
(emphasis mine)
Cas
(emphasis mine)
Cas
[/quote]
Well, those are the words of a CNET.com article, not a sourced quote from Apple. To be honest, a lot of the mainstream reporting on WWDC '14 has been riddled with misconceptions. At no point in the presentation did Apple ever say that Metal was meant to replace OpenGL. Nor does that CNET article provide any in-depth analysis to support the statement.
Here’s another amusing take on the subject:
http://www.alexstjohn.com/WP/2014/06/08/direct3d-opengl-metal-full-circle/
(some of the commentary is particularly interesting)
(and note that this is from someone who really knows what they’re talking about)
Cas
What he fails to mention in that article, or the previous article to which he refers in the first graf, is that Metal API is only shipping in the iOS8 SDK. It’s only designed for use with the A7 mobile chip. Unless Apple is suddenly going to start powering its laptops and desktops with A7 processors, Metal doesn’t really sound like a comprehensive solution to me.
Is Apple hoping to back-burner OpenGL as the API for heavy-duty graphics in iOS? I’m sure that’s the case. Developers have long complained that it’s an utter pain to work with. What you can see from the Metal API code example is that you’re working with objects in Objective-C, not a bunch of C structs masquerading as “objects.” I’m sure a lot of this also has to do with Apple’s overarching goal to step away from “the baggage of C,” as they put it.
But the reality is that powerful, useful, and recently-introduced APIs like SceneKit and SpriteKit already rely on OpenGL to work as of right now. I don’t see why OpenGL would have to go anywhere. Metal and OpenGL can coexist. But yeah, for sure, I think Metal is going to be the preferred route for graphics-intensive mobile development in iOS from now on.
@Cas: WRT “examples”. We pretty much agree then.
I ran across this by chance: http://codeflow.org/entries/2014/jun/08/some-issues-with-apples-ios-webgl-implementation/
I don’t like this too.