3 ms·

The issue is we don't work alone. There are different people, teams and third-party code we have to deal with. And their preferred subset of a kitchen sink lang

by hu3 6y ago

The issue is we don't work alone. There are different people, teams and third-party code we have to deal with. And their preferred subset of a kitchen sink language can vary wildly. > The fact that you have a kitchen sink of language features lets you carve out the language of your choice and write code according to whichever paradigm suits you as a developer.

chmaynard 6y ago
Agreed. My only experience with someone else's Swift project was discouraging, to say the least. I thought I understood the basic language syntax and semantics, but the source code I reviewed was almost incomprehensible.
skohan 6y ago
Well then the responsibility would be on the team to agree on a subset of the language and a set of design patterns to use. This is a process which happens in every language (with the exception of Go to some extent since it's so small and strict) but with Swift you have a bit more freedom over where you will end up. With regard to 3rd party code, you're also free to chose libraries where you agree with the interface paradigm they've chosen. I find this concern to be a bit overblown. In practice I've never really run into a case where somebody is doing something really exotic and inscrutable in Swift, and it's generally easier to understand than, for instance, a really esoteric Scala code base or a Rust project making heavy use of metaprogramming.
- hu3 6y ago
  Let's agree to disagree because in my practice: - Teams: Less experienced developers will use fancy features trying to be smart. Every subset of the language finds it way on Pull Requests I review. - People change teams - People change companies - Third party code: It's not realistic to filter out libraries based on their use of the language. Who even has time to review that? Not to mention that high quality libraries are scarce enough that if you start to filtering out libraries you often end up with none. And the code doesn't have to be "exotic or inscrutable" to be a negative. It just needs to be unnecessarily of high cognitive load for it to impact use of the language. I've seen Swift developers squint at Pull Requests trying to gasp what certain part of the code was doing. It ended up being needless sugar and in turn a bit of everyone's time was wasted. That mindset of "just pick whatever part of the language suits you" is why C++ is what it is.

by hu3 6y ago

chmaynard 6y ago

Agreed. My only experience with someone else's Swift project was discouraging, to say the least. I thought I understood the basic language syntax and semantics, but the source code I reviewed was almost incomprehensible.

skohan 6y ago

Well then the responsibility would be on the team to agree on a subset of the language and a set of design patterns to use. This is a process which happens in every language (with the exception of Go to some extent since it's so small and strict) but with Swift you have a bit more freedom over where you will end up. With regard to 3rd party code, you're also free to chose libraries where you agree with the interface paradigm they've chosen. I find this concern to be a bit overblown. In practice I've never really run into a case where somebody is doing something really exotic and inscrutable in Swift, and it's generally easier to understand than, for instance, a really esoteric Scala code base or a Rust project making heavy use of metaprogramming.

hu3 6y ago
Let's agree to disagree because in my practice: - Teams: Less experienced developers will use fancy features trying to be smart. Every subset of the language finds it way on Pull Requests I review. - People change teams - People change companies - Third party code: It's not realistic to filter out libraries based on their use of the language. Who even has time to review that? Not to mention that high quality libraries are scarce enough that if you start to filtering out libraries you often end up with none. And the code doesn't have to be "exotic or inscrutable" to be a negative. It just needs to be unnecessarily of high cognitive load for it to impact use of the language. I've seen Swift developers squint at Pull Requests trying to gasp what certain part of the code was doing. It ended up being needless sugar and in turn a bit of everyone's time was wasted. That mindset of "just pick whatever part of the language suits you" is why C++ is what it is.