8 ms·

> It shouldn't be time consuming to manually integrate a dependency either. Add it to your project and go. I’m not going to play the yes-no game with you on th

by alloy 12y ago

> It shouldn't be time consuming to manually integrate a dependency either. Add it to your project and go. I’m not going to play the yes-no game with you on this. > I further don't understand how it's a problem if you commit them to SCM and then decide to remove them. If you decide to remove them, then remove them, and you're back where you were. You will have to spend time to figure out which build-settings originate from which library. Or you do it properly upfront with a xcconfig, which also costs you time. > Perhaps this is the gulf in understanding: when you talk about transitive dependencies, my immediate reaction is that if you have so many different dependencies and dependencies-on-dependencies that it becomes difficult to manage by hand, you're doing something terribly wrong and setting yourself up for a world of pain. You’re simply making too many assumptions then. Also see: http://guides.cocoapods.org/using/faq.html#cocoapods-is-bad-for-the-community-because-it-makes-it-too-easy-for-users-to-add-many-dependencies http://guides.cocoapods.org/using/faq.html#cocoapods-is-bad-... I’m still planning to port that old blog post, by my then-colleague, to an iOS context and post it on our blog. This assumption you make is a common one and tends to leave sour tastes with everyone.

mikeash 12y ago
I don't understand your "build settings" comment. Why would there be any build settings originated from a library? As for "making too many assumptions", it sure would be nice if you could, say, explain yourself instead of just saying I'm wrong and that my wrongness upsets people. Your FAQ link doesn't explain anything. To explain my side: third-party code tends to be of low quality and interact with other third-party code in interesting ways. When things go wrong, and they always do even with the best programmers and the best code, the more bad third-party code you have, the more you have to dig through to find and fix the fault. This objection largely goes away if you only use dependencies of extremely high quality, but to be brutally honest, there aren't enough such projects out there to be able to make a mess from them.
- quesera 12y ago
  > third-party code tends to be of low quality and interact with other third-party code in interesting ways. Absolutely. There are less than a half dozen libraries I'll use without hesitation. The others get evaluated carefully on author, size, criticality, and my domain knowledge, with the default choice being: "no, don't want to deal". But that's a criticism of all package managers everywhere, and I think it's clear that popular ones promote higher quality libraries, over time. CocoaPods is young yet. Package management for compiled and linked executables might turn out to be too hard or wrongly marketed. But a strong ecosystem of third party Objective-C code is a laudable goal.
  - mikeash 12y ago
    I don't really see how CocoaPods helps the ecosystem of third-party code or promotes higher quality libraries over time. The cost of using third-party libraries is high, so they need to be worth the cost if I'm going to use them at all, and the vast majority of that cost is not in the stuff that CocoaPods helps with.
- alloy 12y ago
  > I don't understand your "build settings" comment. Why would there be any build settings originated from a library? Your project might need to link against frameworks/libraries that the dependency requires. Your project might need certain search path. There are more, but I hope you understand what I mean now. > As for "making too many assumptions", it sure would be nice if you could, say, explain yourself > […] > Your FAQ link doesn't explain anything You hear “transitive dependencies” and you assume somebody is “doing something terribly wrong”. I’m saying that that’s not necessarily the case and in the FAQ item that I linked to I state that I’m against the scenario that you assumed. The blog article that is linked to from that FAQ item goes into more detail about why it’s good to keep it to a bare minimum. (More on that below.) > and that my wrongness upsets people I wasn’t referring to you specifically, but rather to people on both sides (for/against) discussing this topic in general, which was the premise for me needing to ‘port’ that blog article. It was a side-node and I see how it could be taken the wrong way. > To explain my side: third-party code tends to be of low quality and interact with other third-party code in interesting ways. When things go wrong, and they always do even with the best programmers and the best code, the more bad third-party code you have, the more you have to dig through to find and fix the fault. This objection largely goes away if you only use dependencies of extremely high quality I already knew what you meant, this is not the first time I have this discussion :) But I should have been more explicit: When we talk about dependencies that were created by a third-party, so _not_ dependencies per se, you are completely right and we are in full agreement. To quote from the blog post: “Minimal dependency is not just about the number of libraries you use, but also about the total amount of code you pull into your project. Less code means less bugs.” > but to be brutally honest, there aren't enough such projects out there to be able to make a mess from them I doubt you checked all of them, but seeing as everyone makes mistakes in their own code, I think it’s fair to assume that there is a lot of code that could be improved. Where we seem to differ, but tell me if I’m wrong, is that you in principle choose to not deal with any of them, probably because it wastes time (?). Whereas I prefer to choose a small one that does (almost) exactly what I need and (almost) is where I want it to be code-wise and then contribute to that project, instead of starting over. To facilitate the mentality that I and many others have, it helps to have a tool and ecosystem that makes libs discoverable and ‘simple’ to build upon/together.
  - 12y ago

by alloy 12y ago

mikeash 12y ago

I don't understand your "build settings" comment. Why would there be any build settings originated from a library? As for "making too many assumptions", it sure would be nice if you could, say, explain yourself instead of just saying I'm wrong and that my wrongness upsets people. Your FAQ link doesn't explain anything. To explain my side: third-party code tends to be of low quality and interact with other third-party code in interesting ways. When things go wrong, and they always do even with the best programmers and the best code, the more bad third-party code you have, the more you have to dig through to find and fix the fault. This objection largely goes away if you only use dependencies of extremely high quality, but to be brutally honest, there aren't enough such projects out there to be able to make a mess from them.

quesera 12y ago
> third-party code tends to be of low quality and interact with other third-party code in interesting ways. Absolutely. There are less than a half dozen libraries I'll use without hesitation. The others get evaluated carefully on author, size, criticality, and my domain knowledge, with the default choice being: "no, don't want to deal". But that's a criticism of all package managers everywhere, and I think it's clear that popular ones promote higher quality libraries, over time. CocoaPods is young yet. Package management for compiled and linked executables might turn out to be too hard or wrongly marketed. But a strong ecosystem of third party Objective-C code is a laudable goal.
- mikeash 12y ago
  I don't really see how CocoaPods helps the ecosystem of third-party code or promotes higher quality libraries over time. The cost of using third-party libraries is high, so they need to be worth the cost if I'm going to use them at all, and the vast majority of that cost is not in the stuff that CocoaPods helps with.
alloy 12y ago
> I don't understand your "build settings" comment. Why would there be any build settings originated from a library? Your project might need to link against frameworks/libraries that the dependency requires. Your project might need certain search path. There are more, but I hope you understand what I mean now. > As for "making too many assumptions", it sure would be nice if you could, say, explain yourself > […] > Your FAQ link doesn't explain anything You hear “transitive dependencies” and you assume somebody is “doing something terribly wrong”. I’m saying that that’s not necessarily the case and in the FAQ item that I linked to I state that I’m against the scenario that you assumed. The blog article that is linked to from that FAQ item goes into more detail about why it’s good to keep it to a bare minimum. (More on that below.) > and that my wrongness upsets people I wasn’t referring to you specifically, but rather to people on both sides (for/against) discussing this topic in general, which was the premise for me needing to ‘port’ that blog article. It was a side-node and I see how it could be taken the wrong way. > To explain my side: third-party code tends to be of low quality and interact with other third-party code in interesting ways. When things go wrong, and they always do even with the best programmers and the best code, the more bad third-party code you have, the more you have to dig through to find and fix the fault. This objection largely goes away if you only use dependencies of extremely high quality I already knew what you meant, this is not the first time I have this discussion :) But I should have been more explicit: When we talk about dependencies that were created by a third-party, so _not_ dependencies per se, you are completely right and we are in full agreement. To quote from the blog post: “Minimal dependency is not just about the number of libraries you use, but also about the total amount of code you pull into your project. Less code means less bugs.” > but to be brutally honest, there aren't enough such projects out there to be able to make a mess from them I doubt you checked all of them, but seeing as everyone makes mistakes in their own code, I think it’s fair to assume that there is a lot of code that could be improved. Where we seem to differ, but tell me if I’m wrong, is that you in principle choose to not deal with any of them, probably because it wastes time (?). Whereas I prefer to choose a small one that does (almost) exactly what I need and (almost) is where I want it to be code-wise and then contribute to that project, instead of starting over. To facilitate the mentality that I and many others have, it helps to have a tool and ecosystem that makes libs discoverable and ‘simple’ to build upon/together.
- 12y ago