Swift certainly is a nice, impressive, modern language but it seems like Apple created a language they want themselves to rewrite OS frameworks with millions of lines of code. i could also see it as a rival to C++ in Game (engine) creation. i don't see it suited at all to the average app with less than 100kloc though.
points from the article:
> […] but I personally think it's harder to master Swift than to master Objective-C
absolutely. one can learn Objective-C in an afternoon if you know C - and master it in a few weeks. mastering Swift (like C++) could take decades. why is that the case? because it is a very complex language with many advanced features (like C++) that solve problems that you don't even have in simpler languages. some of these features also solve problems for extremely complex projects or some performance requirements but the simple truth is that most apps on both mobile and desktop are relatively simple (<50kloc) and are better suited by simpler languages with high productivity.
(and you can always drop down to C if you see performance issues with Obj-C...)
> I don't see how I'm sacrificing safety by continuing to write Objective-C.
me neither. yeah Objective-C is not memory safe but no seasoned programmer would ever make those mistakes that Swift aims to solve here - with a high price.
our flagship app is still written in Objective-C and i see nothing to gain by switching to Swift.
p.s. shameless plug, if you live and breathe Objective-C and want to work on a cool app (MacUpdater), drop me a line at jobs@corecode.io
Citation seriously needed. Like just look at the entire history of memory safety related bugs and security issues.
Objective-C is a high-level language and there usually is no memory manipulation. just because the possibility exists (via dropping down to the C part of it) doesn't mean it is done. ARC does memory management for you and there hasn't been the need for manual memory management in ages. even that was pretty hassle-free.
i can count the memory bugs i have seen our Objective-C projects in the past 10 years on one hand.
> entire history of memory safety related bugs and security issues
you are talking about C and C++, not Obj-C
¹And additionally for whether those project would eliminate such code if rewritten in Swift.
...See, that last part you toss off as if it's practically a given, but it's really not.
Sure, when I was (and probably you were) first going to CS classes, being taught C was pretty much the standard thing. But that's much less true now, from all I've seen.
And why not? 20 years ago, it was much, much more likely that if you were a programmer, you were going to be working with C code at some point. Nowadays, you can easily have full mastery in a dozen different languages, all of which are in widespread demand, and never touch C. (Or C++. Or C#. Or Objective-C.)
Personally, where I am at this point in my career? If I wanted to write a small utility program that runs natively on macOS, I'd pick Swift over C 10 times out of 10. I'm roughly equally familiar with both of them (which is "moderately"), and I know enough about the pitfalls of C to know that I don't want to deal with them, and Swift handles almost all of the frustration of memory management for me.
Plus, there's a single authoritative source for information about Swift for when I run into something I'm unfamiliar with, forgot, or got confused about. If I try the same in C there's literally thousands of different sources, of varying authority, across every major and minor platform that's ever existed, and every version of C. It's fantastic that there's all that information out there, don't get me wrong, but when I'm trying to write a small utility to solve a specific problem, every time I run into something that's talking about the wrong C version, or the wrong platform, or just plain has bad information, is going to add one more bit of frustration that's likely to make me quit trying.
Yes, Apple's documentation is imperfect—but I always know that it is there, acting as a single authority for the language.
Wow, that's a hell of an assertion!
> Verbosity. Wait, what?!? Yes, I prefer the verbosity of Objective-C method names.
I agree with a lot of what the author wrote, but this… this I cannot stand behind.
Not having header files has literally never been a problem for me. Xcode can auto generate a sort of pseudo-header definition file if you are pulling in someone else’s frameworks. And day to day app work mostly consist of writing code for the app, not writing a library or framework for others to use. You still have public and private methods. I guess not having separate header files makes it slightly easier to expose things you should probably keep private, but that really is just a thing that is solved by “just don’t do that.” Finally, a lot of times people will just have a private extension to a class that contains all the private methods anyway. So you basically just have everything combined in the same .swift file, where you have a “logical” header rather than a separate header file.
Regardless, verbosity's cost is heavier while reading than writing (as you say, due to autocomplete).
can you elaborate? the verbosity is good while reading, because you know what it does even if you don't know the API in your sleep. how could there be a verbosity cost while reading?
It’s fairly common in iOS dev forums to find people who only know Swift.
> Header files. Wait, what?!? Yes, I prefer having header files to not having header files.
I couldn't agree more. Header files are searchable, by arbitrary independent tools, and support discoverability. Generated Swift interface docs force you into Xcode, yield zero discoverability and can be searched only after you generate them and have them open in the editor. You're generally much more dependent on Apple's shitty incomplete documentation.
And to expand on this, I get docs for all the dependencies of the project generated at the same time, and can optionally generate docs for non-public interfaces.
From the user perspective I really dislike just being thrown a bunch of types with minimal to no actual docs. It seems more common with Cstyle headers to add docs.
With respect to the point about header files. Of course you can have an API in swift either by having your class conform to a protocol or using visibility modifiers.
Also the point about verbosity, the benefit is often in reading others code and being able to quickly grok it. Swift also has a number of functional methods (map, reduce, etc) that are really nice for this.
I agree stability and compile times were an issue, but I think they’re getting to a fairly good place now.
And lastly I like the additional protections swift offers when working in a large team with varied skill levels. Just because the author has been able to avoid crashes, it does not mean this will be the case for a junior dev on the team (and code reviews can miss some things).
writing functional extensions for base classes in ObjC takes like an hour and every seasoned ObjC programmer has those extensions in his toolkit/library anyway. so that doesn't sound like a killer argument for switching to Swift.
- Objective-C doesn't support generic value types for function arguments
- Objective-C can't optimize away method calls and therefore value boxing
What that means in practice is that you can't write a generic version of map/reduce/etc without it being very slow even for things that should be very fast. If you want one that works efficiently for value types like integers, you must write a specialized version for each type.
(I have written and sometimes use for convenience ObjC map/reduce/etc implementations.)
Maybe you're implicitly arguing that those developers are irrelevant to the conversation of Swift vs ObjC, and I would disagree there too. Languages need to strike a balance between catering only to the most highly experienced and specialized developers, and hobbling themselves to be "idiot proof".
One thing I never really grokked though is the practical implications of message-passing vs method-calling. I read plenty of material about how it's implemented, but never found a scenario where I thought about it. Everything was always still just method-calling to my forebrain. Do you have any resource that talks about the practical implications?
From the man himself, Alan Kay: https://news.ycombinator.com/item?id=1355977
> I feel that the crap store lockdown and race to the bottom have drained much of the enthusiasm out of our industry, and left us in a state where we think the programming language is the most exciting thing in the world.
A lot of the long hanging fruit has already been done since then, so it takes more effort to get kicks out of shipping an app that people use. Learning a new tool like a programming language is an easier way to get such kicks.
Had a golden chance to build a next generation language that could have been the next modern Java or Python, used everywhere, but instead we got the iOS version of 'Scala', a language that is just over-complicated for no reason at all.
If you took the Objective-C, modernized the syntax (which is the biggest turn off for many), and add few of the modern utilities that is missing in string/array manipulation, you would have had a much better language that what Swift has become.
As in many cases, the sequel is often worse than the original.
If I was in charge of the Swift development, i'd consider a complete re-thinking of the language, and just remove the unnecessary complexity that is in every step of the language that make it not fun and not productive to use.
I find it perplexing that the language never took off for open source Unix development. For example, I tried GTK 4 not that long ago and was surprised how similar its design was with Cocoa (it even had auto-layout!). Unfortunately, the GObject system felt like a poor man's Objective-C. I understand the appeal of C over C++, but Objective-C would have been a perfect fit here. Feels like a missed opportunity.
I can work with Swift and be productive with it, but at the same time, I feel like I still encounter new patterns, gotchas, property wrappers, language quirks, language changes, type-system oddities, etc, almost every day, and I have a hard time keeping track of it all.
"Header files. Wait, what?!? Yes, I prefer having header files to not having header files. A lot of programmers complain about maintaining header files, but header files represent your API, so you're complaining about maintaining an API, which is not a good look, to be honest."
totally agree. I wanna see in one place the "API" namely:
- the name scope it's in
- the return, in, and out params
- description with explicit language on what's defined and undefined behavior in calling it
- in isolation without being blown away by the impl on first glance that's interspersed with the API.
Quoting further:
"If there's no distinction between your interface and your implementation, then your architecture is likely not great.""
Not sure about architecture, but good lord, programmers have to remember code is written to solve use cases AND be understandable by others. I want to read something written to be understood. I'm not interested in reading somebody's diary moonlighting as commercial code.
If you don't see how you're "sacrificing safety by continuing to write Objective-C", then you are missing something, IMO.
I hated Objective-C when I had to deal with it, basically writing a wrapper around it for cross-platform compatibility of the framework I was using at the time (C++/OpenGL).
I spent a few hours looking at Swift and it seems simply worse in all dimensions that I am interested in.
Apple would benefit greatly by adopting standards instead of trying to push their own. Darwin was built on Unix/BSD foundations, it was a good move.
