5 ms·
> It Just Works Even if that's true, you're still locked into Apple's world—a privilege you paid for. If I'm snarky it's because calling this "revolutionary"
by gavinpc 10y ago
> It Just Works
Even if that's true, you're still locked into Apple's world—a privilege you paid for.
If I'm snarky it's because calling this "revolutionary" is a slap in the face to the people who've spent their careers working to understand early education through computers, without the ulterior motive of said platform lock-in.
- bluejekyll 10y agoI 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,....
- pjmlp 10y agoWhen I started getting around computers we had to pay for everything and most of the programming languages were specific to the machine one had, way before Apple mattered at all in the home market. Apple 8 bit computers weren't even relevant in Europe. Yet I managed to learn pretty well.
- 72deluxe 10y agoIt's tricky. Even if you write for Windows, you'll be using APIs that only work on there (eg if you write in C++ using MFC or COM, or write using .NET and eg. find that you can only do certain things with Invoke by calling into system DLLs, which you won't be able to do on other platforms, despite the open source nature of .NET these days). If you write for iPad, you are restricted to their iOS APIs. If you write for Mac OS, you'll be restricted to there, as you use Cocoa. If you write for Android, you'll be restricted to there, as you write using Android's APIs despite the existence of Java and some of its runtime. You could attempt C++ on here but the NDK is a bolt-on. The only true solution seems to be to write in a language that is available across all platforms (C++?) using a library that works across all of them (doesn't exist), but this is non-existent as the ways the systems behave (windowing, application process cycle) is different on each platform and it would be foolish to believe that they should be the same, or that they behave in the same way. I think we should just accept that each platform has its merits and disadvantages and stop aiming for this dream of easy cross-compatibility with little developer effort. On all platforms we have to buy the hardware, sometimes have to buy the tooling, and then have to submit our applications to the respective markets or distribution channels (even on Linux, we can't just chuck our stuff at repos, particularly if we want to sell it). Ultimately if we write for a platform, there will always be lock-in of some sort (eg why can't I run my EXE on Mac?).
- Angostura 10y agoUltimately, if those people with their years of understanding have done a better job of understanding the needs of teachers and pupils then Apple will fail. If Apple doesn't fail, then those people need to have a long hard look at their careers.