9 ms·

Thoughts on Swift and Objective-C (2022)

61 points by pketh 3y ago

lapcat 3y ago
(2022)
wwarner 3y ago
A devastating conclusion in the last sentence: > 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.
- nequo 3y ago
  The post compares it with the enthusiasm about the iPhone as a platform in 2007. 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.
- tempodox 3y ago
  I largely share that conclusion. Apple's iron grip has squeezed most of the fun out of their platforms, for me at least. The phrase “crap store lockdown” is an ingenious find and hits the nail on the head.
tambourine_man 3y ago
> Header files. Wait, what?!? Yes, I prefer having header files to not having header files. > 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.
- dinkblam 3y ago
  why would a verbose name (like stringByReplacingOccurrencesOfString:withString:) not be better than something short but completely meaningless and obscure like /strtol/? we have autocompletion these days...
  - happytoexplain 3y ago
    Why are you making such a large jump? The Swift version is 'replacingOccurrences(of:with:)', where all three types are strings. Regardless, verbosity's cost is heavier while reading than writing (as you say, due to autocomplete).
    - dinkblam 3y ago
      > 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?
    - catoc 3y ago
      Verbosity is in-place documentation. I personally like it. I have personal projects where, as the original creator and maintainer of the codebase, I should easily be able to understand what happens. But time and time again I find my current self being grateful to my former self for 'documenting' methods calls and variables by being verbose. [edit: removed typo]
  - tambourine_man 3y ago
    I like terseness while reading as well. I get angry and bored with verbosity.
- Pulcinella 3y ago
  Also a lot of the verbosity of the Obj-C methods names in Apple’s frameworks carried straight over to Swift. And you can make your own method names as verbose as you want. So I am not really sure what the complaint actually is. 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.
draw_down 3y ago
[dead]
hifromLA 3y ago
I agree with the author on choosing the right tool for the job, 100%. But I think that obj c is less and less the right tool. Just my 2 cents. 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).
- dinkblam 3y ago
  > Swift also has a number of functional methods (map, reduce, etc) that are really nice for this. 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.
  - happytoexplain 3y ago
    This is unrealistic. Tons of "seasoned" ObjC programmers will take one or two orders of magnitude longer than an hour to write home-grown replacements for all the functional methods, and they frequently turn out limited in some way, or at least less performant. 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".
  - KerrAvon 3y ago
    The problem with map/reduce/etc in ObjC is twofold: - 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.)
dinkblam 3y ago
could not agree more with the author here. 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
- Pulcinella 3y ago
  > 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. Citation seriously needed. Like just look at the entire history of memory safety related bugs and security issues.
  - dinkblam 3y ago
    have you ever had a look at any Objective-C codebase? 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
frou_dh 3y ago
There are new programmers coming of age every day, so the proportion that even thinks about Objective-C at all (never mind advocates it) is going down down down.
- tempodox 3y ago
  Yes, Fashion-Driven Development is going strong in software circles.
- m0llusk 3y ago
  Honestly, that seems doubtful. The C language has intense dominance and Objective-C puts a nice, minimal, object oriented wrapper on all of that while all the C developer tools remain effective.
  - frou_dh 3y ago
    You think teenagers getting into iOS development are pining for that?
    - Apocryphon 3y ago
      It’s a moot point. If they work at Meta, Google, Snapchat, Spotify, etc. they’re going to end up dealing with Objective-C
      - pjmlp 3y ago
        In legacy code bases mostly. The only modern macOS framework that is still written in Objective-C is Metal, and still almost everyone uses the Swift bindings instead.
        lapcat 3y ago
        > The only modern macOS framework that is still written in Objective-C is Metal This is inaccurate. Extremely inaccurate, nearly 100% mistaken. Almost every macOS framework is still written in Objective-C, including AppKit and Foundation. And the Swift rewrite of Foundation is only beginning: (from December 2022) https://www.swift.org/blog/future-of-foundation/ https://www.swift.org/blog/future-of-foundation/ See also: https://blog.timac.org/2022/0818-state-of-appkit-catalyst-swiftui-mac/ https://blog.timac.org/2022/0818-state-of-appkit-catalyst-sw... and https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/ https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-...
ramesh31 3y ago
I've used countless languages professionally, but I only ever fell in love with Objective-C. Protocol Oriented Programming is sorely underutilized outside of it. And the subtle difference between message passing and method calling is an abstraction that totally changes how you think about building things in an object oriented environment for the better. There's nothing else I've found which has that amount of low level power (with the ability to drop into C at any time), while still having a world class, well documented OOP framework (NS) on top of it. And ARC is the perfect middle ground between manual maloc and a traditional mark/sweep GC. The power and ergnomics of that language were probably almost single handedly responsible for the early success of the App Store.
- gmac 3y ago
  I haven’t used Swift enough to comment on the contrast, and I do sometimes wish for a bit more type inference in Objective-C (rather than having to keep clarifying that yes, -stringByReplacingOccurencesOfString:withString: is going to return [… drumroll …] a string). But I must admit that I too have a huge soft spot for Objective-C. Including those beautifully unambiguous selector names.
- happytoexplain 3y ago
  Agreed - though I prefer Swift, I loved my time with ObjC, and I can't say I even like any other language I've ever touched. There's no close 3rd place for me. And the gap widens when you take the ecosystems/frameworks into account. 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?
  - ramesh31 3y ago
    >Do you have any resource that talks about the practical implications? From the man himself, Alan Kay: https://news.ycombinator.com/item?id=1355977 https://news.ycombinator.com/item?id=1355977
deleted 3y ago
[deleted]
tempodox 3y ago
I'm with the author. Also, > 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.
- bluejekyll 3y ago
  Is this a tooling issue? For example, I absolutely love the rustdoc tool `cargo doc` which generates nice searchable docs. I find this has more value to me than header files. Does swift have something similar, or is it only Xcode that gives you a doc feature? 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.
  - KerrAvon 3y ago
    Yes, it's a tooling issue. Xcode is horrifically slow at generating the docs.
  - kzrdude 3y ago
    Nice obeservation, cargo doc is Rust's header files. When developing a library in Rust, I usually use cargo doc to "see the crate from the user's perspective".
    - elcritch 3y ago
      That explains why so many docs for Rust packages are just a spew of types and traits. 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.
      - kzrdude 3y ago
KerrAvon 3y ago
This may need an update. The compiler is more stable today, for example, even though the language continues to evolve rapidly.
turdprincess 3y ago
[flagged]
- deleted 3y ago
  [deleted]
- b3morales 3y ago
  Is it really necessary to defend your language preference by ridiculing the alternative and those who wish to use it?
  - deleted 3y ago
    [deleted]
- deleted 3y ago
  [deleted]
jonnycat 3y ago
I largely agree with this. I've been coding professionally a pretty long time and have worked with a wide variety of languages (including quite a lot of Objective C back in the day), and I've just never met a language with a larger surface area than Swift. 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.
ardit33 3y ago
Criss Latner made a huge disservice to the iOS community. While the intentions were good (build a modern language), it completely failed to the 'it is easy and fun to use'. 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.
- generalpf 3y ago
  *Chris Lattner
- deleted 3y ago
  [deleted]
- chunkyguy 3y ago
  What would you expect from a developer who only used C++ for most of their career. Maybe the entire Swift compiler team was solving the problems they had with C++
hgs3 3y ago
Yes, Objective-C deserves more love. 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.
- pjmlp 3y ago
  Mostly because GNUStep was always WIP, and GCC implementation never fully covered all NeXTSTEP and later OS X capabilities, specially after Objective-C 2.0 came to be.
bjornlouser 3y ago
[flagged]
stephc_int13 3y ago
The engineering culture at Apple is quite peculiar, and in my opinion, a bad fit for creating standards, especially programming languages. 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.
scrubs 3y ago
Quoting: "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.
sjm 3y ago
As someone who has spent their professional life writing Objective-C (first pre-ARC, then ARC), now mostly Swift, the biggest benefit of Swift over Obj-C is how much more difficult/explicit it is to write unsafe code. You can totally shoot yourself in the foot with Objective-C. Swift is much safer. That in itself has undoubtedly led to an industry-wide improvement in code. Not to mention, obviously, that async/await in Swift is a huge leap forward, especially from the ever-rightward-moving blocks-within-blocks in Objective-C. If you don't see how you're "sacrificing safety by continuing to write Objective-C", then you are missing something, IMO.
deleted 3y ago
[deleted]

61 points by pketh 3y ago

(2022)

A devastating conclusion in the last sentence: > 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.

nequo 3y ago
The post compares it with the enthusiasm about the iPhone as a platform in 2007. 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.
tempodox 3y ago
I largely share that conclusion. Apple's iron grip has squeezed most of the fun out of their platforms, for me at least. The phrase “crap store lockdown” is an ingenious find and hits the nail on the head.

tambourine_man 3y ago

> Header files. Wait, what?!? Yes, I prefer having header files to not having header files. > 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.

dinkblam 3y ago
why would a verbose name (like stringByReplacingOccurrencesOfString:withString:) not be better than something short but completely meaningless and obscure like /strtol/? we have autocompletion these days...
- happytoexplain 3y ago
  Why are you making such a large jump? The Swift version is 'replacingOccurrences(of:with:)', where all three types are strings. Regardless, verbosity's cost is heavier while reading than writing (as you say, due to autocomplete).
  - dinkblam 3y ago
    > 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?
  - catoc 3y ago
    Verbosity is in-place documentation. I personally like it. I have personal projects where, as the original creator and maintainer of the codebase, I should easily be able to understand what happens. But time and time again I find my current self being grateful to my former self for 'documenting' methods calls and variables by being verbose. [edit: removed typo]
- tambourine_man 3y ago
  I like terseness while reading as well. I get angry and bored with verbosity.
Pulcinella 3y ago
Also a lot of the verbosity of the Obj-C methods names in Apple’s frameworks carried straight over to Swift. And you can make your own method names as verbose as you want. So I am not really sure what the complaint actually is. 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.

draw_down 3y ago

[dead]

hifromLA 3y ago

I agree with the author on choosing the right tool for the job, 100%. But I think that obj c is less and less the right tool. Just my 2 cents. 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).

dinkblam 3y ago
> Swift also has a number of functional methods (map, reduce, etc) that are really nice for this. 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.
- happytoexplain 3y ago
  This is unrealistic. Tons of "seasoned" ObjC programmers will take one or two orders of magnitude longer than an hour to write home-grown replacements for all the functional methods, and they frequently turn out limited in some way, or at least less performant. 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".
- KerrAvon 3y ago
  The problem with map/reduce/etc in ObjC is twofold: - 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.)

dinkblam 3y ago

could not agree more with the author here. 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

Pulcinella 3y ago
> 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. Citation seriously needed. Like just look at the entire history of memory safety related bugs and security issues.
- dinkblam 3y ago
  have you ever had a look at any Objective-C codebase? 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

frou_dh 3y ago

There are new programmers coming of age every day, so the proportion that even thinks about Objective-C at all (never mind advocates it) is going down down down.

tempodox 3y ago
Yes, Fashion-Driven Development is going strong in software circles.
m0llusk 3y ago
Honestly, that seems doubtful. The C language has intense dominance and Objective-C puts a nice, minimal, object oriented wrapper on all of that while all the C developer tools remain effective.
- frou_dh 3y ago
  You think teenagers getting into iOS development are pining for that?
  - Apocryphon 3y ago
    It’s a moot point. If they work at Meta, Google, Snapchat, Spotify, etc. they’re going to end up dealing with Objective-C
    - pjmlp 3y ago
      In legacy code bases mostly. The only modern macOS framework that is still written in Objective-C is Metal, and still almost everyone uses the Swift bindings instead.
      - lapcat 3y ago
        > The only modern macOS framework that is still written in Objective-C is Metal This is inaccurate. Extremely inaccurate, nearly 100% mistaken. Almost every macOS framework is still written in Objective-C, including AppKit and Foundation. And the Swift rewrite of Foundation is only beginning: (from December 2022) https://www.swift.org/blog/future-of-foundation/ https://www.swift.org/blog/future-of-foundation/ See also: https://blog.timac.org/2022/0818-state-of-appkit-catalyst-swiftui-mac/ https://blog.timac.org/2022/0818-state-of-appkit-catalyst-sw... and https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-ios16/ https://blog.timac.org/2022/1005-state-of-swift-and-swiftui-...

ramesh31 3y ago

I've used countless languages professionally, but I only ever fell in love with Objective-C. Protocol Oriented Programming is sorely underutilized outside of it. And the subtle difference between message passing and method calling is an abstraction that totally changes how you think about building things in an object oriented environment for the better. There's nothing else I've found which has that amount of low level power (with the ability to drop into C at any time), while still having a world class, well documented OOP framework (NS) on top of it. And ARC is the perfect middle ground between manual maloc and a traditional mark/sweep GC. The power and ergnomics of that language were probably almost single handedly responsible for the early success of the App Store.

gmac 3y ago
I haven’t used Swift enough to comment on the contrast, and I do sometimes wish for a bit more type inference in Objective-C (rather than having to keep clarifying that yes, -stringByReplacingOccurencesOfString:withString: is going to return [… drumroll …] a string). But I must admit that I too have a huge soft spot for Objective-C. Including those beautifully unambiguous selector names.
happytoexplain 3y ago
Agreed - though I prefer Swift, I loved my time with ObjC, and I can't say I even like any other language I've ever touched. There's no close 3rd place for me. And the gap widens when you take the ecosystems/frameworks into account. 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?
- ramesh31 3y ago
  >Do you have any resource that talks about the practical implications? From the man himself, Alan Kay: https://news.ycombinator.com/item?id=1355977 https://news.ycombinator.com/item?id=1355977

deleted 3y ago

[deleted]

tempodox 3y ago

I'm with the author. Also, > 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.

bluejekyll 3y ago
Is this a tooling issue? For example, I absolutely love the rustdoc tool `cargo doc` which generates nice searchable docs. I find this has more value to me than header files. Does swift have something similar, or is it only Xcode that gives you a doc feature? 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.
- KerrAvon 3y ago
  Yes, it's a tooling issue. Xcode is horrifically slow at generating the docs.
- kzrdude 3y ago
  Nice obeservation, cargo doc is Rust's header files. When developing a library in Rust, I usually use cargo doc to "see the crate from the user's perspective".
  - elcritch 3y ago
    That explains why so many docs for Rust packages are just a spew of types and traits. 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.
    - kzrdude 3y ago

KerrAvon 3y ago

This may need an update. The compiler is more stable today, for example, even though the language continues to evolve rapidly.

turdprincess 3y ago

[flagged]

deleted 3y ago
[deleted]
b3morales 3y ago
Is it really necessary to defend your language preference by ridiculing the alternative and those who wish to use it?
- deleted 3y ago
  [deleted]
deleted 3y ago
[deleted]

jonnycat 3y ago

I largely agree with this. I've been coding professionally a pretty long time and have worked with a wide variety of languages (including quite a lot of Objective C back in the day), and I've just never met a language with a larger surface area than Swift. 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.

ardit33 3y ago

Criss Latner made a huge disservice to the iOS community. While the intentions were good (build a modern language), it completely failed to the 'it is easy and fun to use'. 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.

generalpf 3y ago
*Chris Lattner
deleted 3y ago
[deleted]
chunkyguy 3y ago
What would you expect from a developer who only used C++ for most of their career. Maybe the entire Swift compiler team was solving the problems they had with C++

hgs3 3y ago

Yes, Objective-C deserves more love. 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.

pjmlp 3y ago
Mostly because GNUStep was always WIP, and GCC implementation never fully covered all NeXTSTEP and later OS X capabilities, specially after Objective-C 2.0 came to be.

bjornlouser 3y ago

[flagged]

stephc_int13 3y ago

The engineering culture at Apple is quite peculiar, and in my opinion, a bad fit for creating standards, especially programming languages. 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.

scrubs 3y ago

Quoting: "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.

sjm 3y ago

As someone who has spent their professional life writing Objective-C (first pre-ARC, then ARC), now mostly Swift, the biggest benefit of Swift over Obj-C is how much more difficult/explicit it is to write unsafe code. You can totally shoot yourself in the foot with Objective-C. Swift is much safer. That in itself has undoubtedly led to an industry-wide improvement in code. Not to mention, obviously, that async/await in Swift is a huge leap forward, especially from the ever-rightward-moving blocks-within-blocks in Objective-C. If you don't see how you're "sacrificing safety by continuing to write Objective-C", then you are missing something, IMO.

deleted 3y ago

[deleted]