6 ms·
I cry a little every time that I realize that Apple and Microsoft have traded positions. Development tools should be open, at least we should be able to target
by bluejekyll 10y ago
I cry a little every time that I realize that Apple and Microsoft have traded positions.
Development tools should be open, at least we should be able to target platforms generically.
- durandal1 10y agoSwift is both open and runs on multiple platforms.
- kyriakos 10y agoApple was never really open to other platforms though. I don't think they traded positions then, Microsoft evolved a bit while Apple continues with the same approach.
- davidw 10y agoYep. Apple has always wanted to control both the hardware and software, whereas Microsoft 'settled' for controlling the software on a fairly open hardware platform.
- Someone 10y agoNot always. Steve wanted to, but Steve disagreed. For the Apple 2, the net effect was that it shipped with hardware schematics (everything, including the power supply) and commented ROM listings. Even the original Mac still had fairly comprehensive documentation of parts of its hardware, if you bought the phone book edition of Inside Macintosh. And of course, IBM didn't 'settle' for opening up the platform. Compaq and Phoenix Technologies opened it for them.
- richardwhiuk 10y agoThat's Steve Wozniak and Steve Jobs respectively for those who struggled to parse that.
- bluejekyll 10y agoI feel like Apple was more open to alternate distribution options at the beginning of OSX, but I might be wrong in this. tvOS and watchOS have made their software distribution completely Apple lock-in, i.e. you can only do it with Apple tools, see bitcode requirements.
- pjmlp 10y agoThey had to, as they were about to close shop. Apple was the last surviving company of home computers, from the likes of Acorn, Atari, Commodore, MSX,..... All of them controlled the whole experience, both hardware and software. By the time Apple bought NeXT (which in practice was actually the other way around), they need to attract developers back to their platform, so they played nice. Nowadays they have plenty of money on the bank and can be back to being as they always were.
- Someone 10y agoMSX wasn't a company; it was a platform promoted by multiple companies, many of them Japanese. https://en.wikipedia.org/wiki/MSX#Manufacturers https://en.wikipedia.org/wiki/MSX#Manufacturers lists, for the original MSX: "Spectravideo, Philips, Al Alamiah, Sony, Sanyo, Mitsubishi, Toshiba, Hitachi, National, Panasonic, Canon, Casio, Pioneer, Fujitsu General, Yamaha, JVC, Yashica-Kyocera, GoldStar, Samsung/Fenner, Daewoo/Yeno, Gradiente, Sharp/Epcom, Talent, Frael." AGE Labs
- pjmlp 10y agoI know, but on the phone it is easier to write MSX than search and type that list you posted.
- DrJokepu 10y agohttps://github.com/apple/swift https://github.com/apple/swift
- bluejekyll 10y agoTry deploying a non-apple language to tvOS and/or watchOS. Then come back and tell me that they are "open". Bitcode sounded so good back when it came out, but is actually a way of guaranteeing that people only use Apple tools for shipping software.
- pjmlp 10y agoYou mean, like Java, C++, C#, F#? https://www.xamarin.com/platform https://www.xamarin.com/platform https://software.intel.com/en-us/multi-os-engine https://software.intel.com/en-us/multi-os-engine
- badlogic 10y agoNone of these do proper bitcode. And once they do, the managed runtimes will be slow as molasses.
- pjmlp 10y ago> None of these do proper bitcode. C++ surely does unless you don't use Apple's compiler, as for the others they are in the process of making it happen. > And once they do, the managed runtimes will be slow as molasses. I guess you mean as fast as the Objective-C and Swift managed runtimes.
- badlogic 10y agoOverlooked C++. My point stands for managed runtimes. ObjC/Swift don't have to deal with the following laundry list of things the managed runtimes need to implement: - Explicit instrumentation for null pointer checks (slow) - Explicit instrumentation for stack overflow checks (slow) - Explicit instrumentation for GC safe points (slow) - Exceptions and unwinding implemented on top of cxx_throw instead of signals and setjmp/lonjmp (slow and error prone) - Defensively generated trampolines for reflection for any thinkable parameter type permutation There are quite a few more details that make managed runtimes under bitcode suboptimal. Taking away things like read/write register access, signals and system APIs like setjmp/longjmp puts managed runtimes at a huge disadvatage. Neither Swift nor ObjC (and to a large degree C++) need to solve any of these problems.
- pjmlp 10y agoThey aren't much different from all the other home computer vendors, Atari, Comodore, Acorn,....