Slashdot Mirror
Why Apple Should Open-Source Swift -- But Won't
snydeq writes: Faster innovation, better security, new markets — the case for opening Swift might be more compelling than Apple will admit, writes Peter Wayner. "In recent years, creators of programming languages have gone out of their way to get their code running on as many different computers as possible. This has meant open-sourcing their tools and doing everything they could to evangelize their work. Apple has never followed the same path as everyone else. The best course may be to open up Swift to everyone, but that doesn't mean Apple will. Nor should we assume that giving us something for free is in Apple's or (gasp) our best interests. The question of open-sourcing a language like Swift is trickier than it looks."
In this context it's a programming language for the Objective-C runtime developed by Apple.
Wrong. Open source does not mean chaos or loss of control.For example Mozilla Firefox is open source but Mozilla are still firmly in control of the project.
Its a question of good governance. Give it freedom but yet maintain direction. Not an easy balance to get right as companies like Oracle are slowly learning. How much control would Apple want to exert? My guess is a lot.
Applle didn't adopt Objective-C. Objective-C came with the package when Steve Jobs returned to Apple and brought NeXTSTEP/OpenStep with him from NeXT. Objective-C is an attempt to graft SmallTalk style object oriented programming onto standard C without breaking too many other things.
It was probably 5-10 years from the NeXT acquisition until Objective-C became mainstream in the Mac development community. It was all C++ and Carbon until then.
To be clear: Apple aren't just a contributor, they created Clang and employ one of the LLVM project's founders to work on LLVM, Clang, and Swift.
Bogtha Bogtha Bogtha
One thing Swift will address... There are currently 3 memory management models in use in Objective-C, and for some of those models, you don't get a retain count automatically (for example, this is the case for a number of collection objects when doing an insertion).
Swift has the opportunity to rationalize this, which is not something you could do with the Objective-C libraries themselves, since doing so would change historical APIs and thus break old code.
It wasn't really until Metrowerks basically became incompatible with the Intel switchover and the 64 bit support had to drop certain types of support from Finder due to 64 bit inode numbers, and while I happily would have made them new header files so that they would have continued to work with the UNIX Conformance work, where Ed Moy and I basically broke their local private copies of their header files, since Motorola sold off the Intel version of the Metrowerks C the week because Apple announced Intel, it was pretty much DOA at that point.
So it basically took an Act Of God to get some people to get the hell off some of the old APIs we had been dooming and glooming about for half a decade.
Swift is another opportunity for that type of intentional non-exposure obsolescence to clean up the crappy parts of the APIs and language bindings that haven't been cleaned up previously due to people hanging onto them with their cold, dead hands. Hopefully, they will advantage themselves of this opportunity.