by pketh on 5/12/23, 10:34 AM with 72 comments
by dinkblam on 5/13/23, 4:04 PM
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
by tempodox on 5/13/23, 4:33 PM
> 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.
by wwarner on 5/13/23, 3:41 PM
> 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.
by hifromLA on 5/13/23, 3:56 PM
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).
by ramesh31 on 5/13/23, 4:22 PM
by frou_dh on 5/13/23, 4:19 PM
by tambourine_man on 5/13/23, 3:55 PM
> 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.
by jonnycat on 5/13/23, 4:59 PM
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.
by scrubs on 5/13/23, 8:58 PM
"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.
by sjm on 5/13/23, 9:48 PM
If you don't see how you're "sacrificing safety by continuing to write Objective-C", then you are missing something, IMO.
by stephc_int13 on 5/13/23, 5:37 PM
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.
by hgs3 on 5/13/23, 5:26 PM
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.
by ardit33 on 5/13/23, 5:16 PM
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.
by lapcat on 5/12/23, 11:22 AM
by KerrAvon on 5/13/23, 4:52 PM