Back in July, I posted this to my microblog, which was cross-posted to Twitter for some additional discussion:
Not shocked that Swift classes won’t be subclassable by default. But it underscores Swift’s priorities. And for that reason, I’m out.
The “I’m out” was meant as a Shark Tank reference, and not to be taken too seriously. But I was serious about taking a break from Swift until version 4, when it would at least be more stable. Daniel and I followed up that week with a more in-depth discussion on Core Intuition 242.
A few days ago Craig Hockenberry posted about how the rapid pace of improvements to Swift can get in the way of learning the language and using example code:
It’s gotten to the point where every time I come across some information written in Swift, especially on Stack Overflow, I cringe. I know that I’m going to have to not only figure out the code, but also which version was used for the answer.
I have absolutely no regrets sticking to Objective-C. As Swift 3 was wrapping up, it seemed that the churn around syntax changes was even worse than I feared. From an Apple dev forums thread at the time:
For the expected quality of software in a third-generation project in late Beta, Swift 3 has become a trainwreck of Microsoftian proportions–at least in terms of process and expectation. Many of us devs are spending 90% of our time not developing our app, but babysitting Swift and trying to understand so many unvetted changes.
That settled down with the final Swift 3 release, but I expect many developers won’t upgrade from Swift 2.3 until Xcode forces them to. There’s even a whole book by Erica Sadun on migrating code.
I still consider Swift a beta language. I just hope that the Swift team and community recognize that this level of instability isn’t acceptable forever. A programming language is not an iOS or macOS release. There shouldn’t be a new major version of Swift every year.
Like many developers, I’ve spent the morning looking over the Swift open source release. I continue to be intrigued and look forward to working Swift into more of my routine.
On today’s Core Intuition, Daniel and I talked about Swift for about half of the 50-minute episode. We recorded the episode yesterday afternoon, before the open source announcement, so we’ll be following up next week on everything that has changed. I bet there will be some more progress in Swift web server frameworks by then, too.
On a previous episode of “Core Intuition”:http://www.coreint.org/, number 14, Daniel and I talked about open source. One LGPL tool I use in Wii Transfer is called FFmpeg, a very popular video conversion project that forms the base of many video web sites, as well as the Mac QuickTime component, Perian.
In the latest Wii Transfer I updated to a new version of FFmpeg, which it turns out had a major bug: “broken audio for 8-bit input sources”:https://roundup.mplayerhq.hu/roundup/ffmpeg/issue582. Of course I am including the fix in a bug fix update to Wii Transfer (still “beta in the forums”:http://www.riverfold.com/forums/), but not before many customers were hit by the problem.
Not to look a gift horse in the mouth, but it reminds me of one annoyance with FFmpeg: no releases. You basically just follow trunk, and if there’s a bug, sorry. This is understandable. It’s open source, after all, and the developers don’t owe you anything. But at the same time, it’s one of the reasons I’ve moved to Perian-only in my new app, and left the FFmpeg trunk and other similar open source command line tool projects behind. With Perian I can track specific major releases and know that someone has tested them. QTKit is good enough now on Leopard that I feel comfortable basing on app on it.
Daniel also mentioned in passing that violators of open source licenses are likely to get away with it. I think that’s largely true, but I found that the FFmpeg developer base has a pretty keen eye to this issue. If they notice that commercial software is using FFmpeg or MEncoder or other portions inappropriately, they will list the software in their “hall of shame”:http://www.ffmpeg.org/shame.html.
PHPeverywhere: “When things turn sour, Open Source is not about open minds, but naked egos and pride. That’s why the key to really successful Open Source projects is leadership, not merely technical skills. And this holds true in life too.”
Krzysztof Kowalczyk: “So remember, kids: source code is useless if you don’t have skilled people to work on it.”