Why is all Metal documentation written in only Obj-C?

The documentation on Metal is all written in Objective-C, as well as the sample code given. Changing the language to "Swift" does nothing. Why is this? Isn't the point of Swift to replace Obj-C? Also, this creates an even steeper learning curve for an already complicated subject for somebody who isn't familiar with Obj-C.

Post not yet marked as solved Up vote post of jo5sh Down vote post of jo5sh
2.5k views

Replies

When I talked to the Metal team at WWDC all of them were very well versed in Objective-c and not swift. This sorta makes sense because Metal is likely developed in a c based language so they are coding in something more similar to objective-c every day (if not objective-c itself).


The funny thing is that you can REALLY tell that the Metal team at Apple doesn't do swift often when you read their few Swift sample codes. They are terribly messy and unorganized mostly due to them wanting to write the Swift code in a c way rather than a Swift way. There are some very memorable lines written by them that always make me chuckle at how roundabout they are because of their c bias (No offense meant you guys are still brilliant). I really think they ought to take on someone to be writing and refining their example swift code (pick me!).


Swift, unfortunately, has some issues that need to be ironed out before it can become the language used for widespread Apple projects.


If there is a specific project you need to see in Swift please let me know. I am very good at translating Objective-C and older Swift versions since I can develop in those older languages. If it is a small project like most of their example code I should be able to do it rather quickly and for free. Feel free to contact me at caleb.kierum@gmail.com


Also would highly recommend you start learning Objective-c as well. I still code in Swift mostly but there are occasions where Objective-c is a more effective or the only way to do things.

You could write an objective C to Swift translator but this would hasten the day when C/Objective C developers are forced into half-baked Swift with its half-baked and reportedly very buggy implementation in XCode.


Also as you note, somethings are better in C. For example it may be required for high-performance computing.

Also another bad thing about Apple's inventing Swift: The already incomplete and out-of-date documentation is now even more compromised and will require a huge amount of time to add Swift versions.

The good news is that Swift is now targeting Source Compatibility so Swift 3 and Swift 4 code should no longer ever go out of date! I know they have a massive example code base but it really wouldnt be that massive of a workload to do. I can generally convert most not too involved projects in 1-5 hours so if each team just made a plan to update all their example code by ___ date then it wouldnt be that difficult to do.

There are a couple of online objc to swift converters, that are ok for simple stuff that gives you an idea of how much hacking you need to do.


learn how to hack c/c++, you can easily write gpu code without ever touching objc and you'll be able to write cuda code as well.


iswift.org

objectivec2swift.com

Apples and oranges - One is matured, as indicated by an ABI (amongst other factors), where the other does not yet _have_ an ABI.


Best to calibrate expectations accordingly, and give Apple credit for otherwise keeping commitments in check. You can't fault a railroad for not erecting depots where there are no tracks... You can't expect them to come if it hasn't been built.


Swift 5 next year will be the foundation...after that, it will be worth writing docs and references that mean something, but it will take non-trivial time to accrue critical mass. Until then, either avoid the bleeding edge, or make sure your local blood bank knows your type, because there will be bandages.

I spent some time on this forum (around two years I think). My feeling (just a feeling, I haven't counted or anything like that) is that one of most frequent problems people have with Metal is laying out data in buffers. And I'd say that people having this kind of problems are much more likely to use Swift.


Now (and pray remember English is not my primary language) I don't want to say that Swift is a bad language or that Swift programmers are "worse". Technically, due to rapidly increasing popularity of Swift it may be that more beginners start with learning Swift so we have what statisticans call selection bias here. But this is also not what I want to say.


What I want to say is that ObjC and C family languages in general are a bit "lower level" than Swift is. This in turn (more often than not) forces programmer to learn things like type sizes and alignment, structure layout as seen/created by compiler, pointer arithmetics and the problem it can cause and so on. It is easier to learn this using C program running on the CPU, where you have stepping, stack traces, cores, debugger and so on than learn this when writing Metal shaders, where error may even snow crash your system (I know I brought my Mac to a cold reboot a few times just by shader/kernel bugs).


Bottom line: it may be that right now Metal makes a bit more sense in ObjC "environment", than in a Swift one. Just my $.02