3 ms·

This thread confuses and saddens me. What is with the absolutist compulsion that every API and framework has to be cross-platform? Cross-platform APIs and frame

This thread confuses and saddens me. What is with the absolutist compulsion that every API and framework has to be cross-platform? Cross-platform APIs and frameworks must, by necessity, paper over differences, exclude the possibility of leveraging a particular platform's strengths, and target the lowest (i.e., worst) common denominator. Sometimes that's a good tradeoff! But all the time? To the point where we have to attack OS vendors for having the nerve to, oh gosh, add a feature? Taken to the extreme, this makes no sense. What's the point of even having different operating systems if there's only one acceptable API? Do you guys think operating systems can never be allowed to introduce a feature and corresponding API call?

ben509 8y ago
I think it's inexperience speaking, which is also why it's very dogmatic. If you've seen how standards develop, they're usually taking many ideas like this that have become popular and tweaking the specs to smooth out the differences. The POSIX API is often called Berkley Sockets because a vendor, BSD, released their API and it was widely adopted. ANSI C cobbled together existing C compilers into a standard, and POSIX itself was trying to tame a huge mess of Unices. And even if the standards don't fully converge, you have standard libraries to plaster over the differences. Everyone has to contend with weird Windows path conventions and such, to the point where it's hardly even notable.
MrTonyD 8y ago
I'm old enough to remember the POSIX meetings (I was sitting a few feet away from one of the conference rooms while the executives were meeting - and had some input into the spec.) One of the goals was to figure out what functionality was stable and mature - and that would be part of the standard. In contrast, some functionality was expected to evolve and become a differentiator between vendors. Those functions, even if we had an existing implementation, would not be part of the spec. We could really use an equivalent standard right now - it has become too hard to practice our skills. (Also reminds me about when I decided to learn UNIX and C - I was tired of being in the "assembly language of the week" club. Relearning and reimplementing gets old.)
Yoric 8y ago
Well, I for one have lived a time when all platforms were radically different, and it was really really hard to share any code between Linux, Windows and System (for youngsters: that's the name of the previous OS for Macs). We now live in a time where it's much easier to share code, thanks to technologies such as Qt, Java, .Net + Xamarin, game engines, web applications, etc. Any sign that we could be returning to the bad old days is, well, not a good sign. Now, I agree with you that the real bad sign here is not Network.framework, it's the deprecation of OpenGL/OpenCL, apparently without any attempt to go towards the open standard Vulkan. Now, Apple introduces a new technology designed to replace an existing API, and people's built-in pattern-matching (including mine) see it as a sign that Apple might be testing the water before removing a well-known, cross-platform API. That's the kind of behavior that the previous King of the Hill kept using during the bad old days, and Apple seems to have borrowed more than one page from that time's Microsoft, so why not this one?

ben509 8y ago

I think it's inexperience speaking, which is also why it's very dogmatic. If you've seen how standards develop, they're usually taking many ideas like this that have become popular and tweaking the specs to smooth out the differences. The POSIX API is often called Berkley Sockets because a vendor, BSD, released their API and it was widely adopted. ANSI C cobbled together existing C compilers into a standard, and POSIX itself was trying to tame a huge mess of Unices. And even if the standards don't fully converge, you have standard libraries to plaster over the differences. Everyone has to contend with weird Windows path conventions and such, to the point where it's hardly even notable.

MrTonyD 8y ago

I'm old enough to remember the POSIX meetings (I was sitting a few feet away from one of the conference rooms while the executives were meeting - and had some input into the spec.) One of the goals was to figure out what functionality was stable and mature - and that would be part of the standard. In contrast, some functionality was expected to evolve and become a differentiator between vendors. Those functions, even if we had an existing implementation, would not be part of the spec. We could really use an equivalent standard right now - it has become too hard to practice our skills. (Also reminds me about when I decided to learn UNIX and C - I was tired of being in the "assembly language of the week" club. Relearning and reimplementing gets old.)

Yoric 8y ago

Well, I for one have lived a time when all platforms were radically different, and it was really really hard to share any code between Linux, Windows and System (for youngsters: that's the name of the previous OS for Macs). We now live in a time where it's much easier to share code, thanks to technologies such as Qt, Java, .Net + Xamarin, game engines, web applications, etc. Any sign that we could be returning to the bad old days is, well, not a good sign. Now, I agree with you that the real bad sign here is not Network.framework, it's the deprecation of OpenGL/OpenCL, apparently without any attempt to go towards the open standard Vulkan. Now, Apple introduces a new technology designed to replace an existing API, and people's built-in pattern-matching (including mine) see it as a sign that Apple might be testing the water before removing a well-known, cross-platform API. That's the kind of behavior that the previous King of the Hill kept using during the bad old days, and Apple seems to have borrowed more than one page from that time's Microsoft, so why not this one?