I don't love the single responsibility principle - <AUTHOR> http://sklivvz.com/posts/i-dont-love-the-single-responsibility-principle <comment><USER2> This obviously is mostly smoke and mirrors. Uncle Bob recycles Separation of concerns [1] and overshadows it in the process. You won't define what are good or bad boundaries in code anymore than you will define "5 easy rules to author a great piece of fiction". The computer doesn't give a damn about separated concerns, it's all about communication between humans. As such it is a matter of feeling, dare I say emotion, and not a matter of laws and rules. Ultimately our ability to break problems in sub-problems tends to be bounded by the words we have at our disposal.

The TCP/IP stack exemple in the Wikipedia article linked below hints at SoC pretty well in my opinion. One layer allow the layer above to disregard details about the physical link. The next layer makes cross-network addressing transparent. The next one allows apps to disregard packet ordering and loss, and so on. Each layer solves a problem for the one above. Yet one can have multiple responsibilities. This is all about cognitive load.

A system described in code is nothing more than a proposed consensus around tools, names, boundaries, paradigms to be used to talk and think about a solution to a problem. The ultimate measure of success is this: our ability to tame the binary beast. If "change" plays a role (it sure does) it's probably not the main or only metric. Well ... when you're not selling "ability to change" consulting and books to software companies, this goes without saying.

[1] [http://en.wikipedia.org/wiki/Separation_of_concerns](http://en.wikipedia.org/wiki/Separation_of_concerns)

<comment><USER3> Great post. I think this is the fundamental thesis proposed by Abelson and Sussman in SICP. You build a system in layers, each relying on the one below.

The reason you do this is to manage cognitive load in humans, not "coupling" in computers.

<comment><USER2> It is.

 _First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute. Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems._ [1]

[1] [http://mitpress.mit.edu/sicp/full-text/book/book- Z-H-7.html](http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-7.html)

</comment></comment></comment><comment><USER4> This article speaks about one of the many, many reasons I don't like Robert Martin's approach to programming. If some principle results in a handful of single-method classes that don't really do anything on their own, the principle is not a good basis for design.

I find the author's alternative much more useful in practice.

<comment><USER5> > If some principle results in a handful of single-method classes that don't > really do anything on their own, the principle is not a good basis for > design.

Absolutely agree. Proponents of approaches like this tend to only worry about intra-object complexity, and ignore the fact that a vast, complicated object graph is also hard to reason about.

<comment><USER6> _only worry about intra-object complexity_

That reminds me of this, not sure if it's satirical or not: [http://www.antiifcampaign.com/](http://www.antiifcampaign.com/)

Basically it's advocating removing if/switch statements and replacing them with polymorphic method calls. I understand that polymorphism has its value, but think that it's only valuable when, for lack of a better phrase, the thing that's being polymorphosed is "big and varied" enough that it makes sense to impose this extra level of indirection. I think that it being hard to explain when something is worth it, is enough justification that principles shouldn't be arbitrarily decided based on that.

<comment><USER7> I don't understand that page in the slightest, but a lot of if-cascades can be factored more cleanly using polymorphism.

[http://c2.com/cgi/wiki/wiki?PolymorphismVsSelectionIdiom](http://c2.com/cgi/wiki/wiki?PolymorphismVsSelectionIdiom)

(Disclaimer. I wrote the top of that wiki page in a former life.)

<comment><USER6> _However, if you already have a class type for each key_

I think that's precisely what I was trying to say - polymorphism makes sense when you already have a bunch of classes to do it with, and classes which already contain lots of other fields and methods; it doesn't make sense to create a bunch of classes just to use polymorphism.

<comment><USER8> Often, though, a series of complicated if statements is hinting at a type system for your objects that hasn't yet materialized in your code. I find it's a good idea to always look at cascading if statements and switch statements and ask, "Would this be cleaner if I reified these concepts as types?"

[http://en.wikipedia.org/wiki/Reification_(computer_science)](http://en.wikipedia.org/wiki/Reification_\(computer_science\))

<comment><USER9> This is the single most important trick for factoring out shitty code. I cannot believe how many times reification collapsed complexity in our code base, or how not using it was the source of bugs.

If you have cascading ifs, there is a good chance there is a huge set of ifs for _every place_ this type system is missing. Meaning, if you wanted to add another "case" to a feature, you are modifying cascading ifs in 5-10 places, not even just one.

Wrapping up all of this code into an implementation of an interface, that is "hooked in" at each contact point allows you to add a cohesive new use case by generating a new implementation of an interface, instead of "forgetting 2 places in the code" and causing massive bugs or issues because of it.

It of course, also makes it easier to test!

<comment><USER10> So to reify a type involves making an abstraction, which is odd because reify seems the inverse of making an abstraction...

<comment><USER11> The abstraction already existed in your mental model. You're reifying it by making it something the code can refer to/reflect on/pass around.

<comment><USER12> The only difficulty is naming the abstraction :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I like many of the author's points. Pragmatism, thinking instead of blindly following principles, pushing back against size as a metric for measuring responsibility. I think Robert Martin's work absolutely deserves examination and critique. However, I don't share the author's definitions of simple and complex.

 _Stating that "binding business rules to persistence is asking for trouble" is flatly wrong. Au contraire, It's the simplest thing to do, and in most cases any other solution is just adding complexity without justification._

I don't feel that increasing the class count necessarily increases complexity, nor do I feel that putting several things into one class reduces it. A dozen components with simple interactions is a simpler system than a single component with which clients have a complex relationship. My views align more closely with those expressed [1] by Rich Hickey in Simple Made Easy.

Classes as namespaces for pure functions can be structured in any way; they don't have any tangible affect on complexity. "Coupling" is irrelevant if the classes are all just namespaces for pure functions. I also find that most data can be plain old data objects with no hidden state and no attached behavior. If most of your code base is pure functions and plain data, the amount of complexity will be fairly small. As for the rest, I think that the author's example of maximizing cohesion and the SRP are functionally identical. They both recommend splitting up classes based on responsibility, spatial, temporal coupling, or whatever other metric you want to use. Personally I prefer reducing the mingling of state, but I think they're many roads to the same place. Gary Bernhardt's talk Boundaries[2] covers this pretty well.

[1]: [http://www.infoq.com/presentations/Simple-Made- Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

[2]: [https://www.destroyallsoftware.com/talks/boundaries](https://www.destroyallsoftware.com/talks/boundaries)

<comment><USER14> Unfortunately here, Rails encourages putting each class into a separate file, so you have 10 classes spread over 10 files, which does increase complexity.

I dislike having a class/module per file.

<comment><USER15> In Django (the closest thing Python has to Rails) the convention is to put all your models in one models.py file. I also prefer it this way.

<comment><USER16> Having worked with both, there's a trade-off. Given that in Django you're (mostly) explicitly importing classes and modules rather than autoloading, it's handy to have them all in one place. OTOH, when your project grows, you end up with enormous model files (especially if you follow the fat models/thin views pattern). So you then have to split them into different apps, so fragmentation slips in eventually anyway. (In a rails project, unless you're bolting on engines and such, all your models are at least in one _folder_ ).

Where I definitely do prefer Django in this regard is that models declare their data fields, rather than them being in a completely different part of the source as in AR (not Mongoid, I now realise). Do I remember the exact spelling I gave to every column when I migrated them months ago? No. It's good to be able to see it all in one place rather than having an extra tab to cycle through. I don't see any practical benefit from decoupling here.

<comment><USER15> Especially since the Rails way is not "decoupling" in any real sense. Splitting tightly coupled code into multiple files != decoupling.

I also like that in Django, you declare the fields on the models first and then create the db migrations from them, rather than writing a db migration first to determine what fields the models have.

<comment><USER16> Indeed, decoupling is probably the wrong word here: I haven't seen an ORM implementation that was not tightly coupled to the database layer, which in the end is surely the point of an ORM - to represent stuff from the database in application code. (I know some people consider this a bad abstraction, but whatever.)

South/1.7 migrations is definitely the best way of the two to manage that coupling. Rails's charms lie elsewhere.

<comment><USER15> Right, and the debate raging in the Rails community now is whether your business logic should be in your models at all, or whether it should be extracted into plain old ruby objects, separating your domain model from your data model. Reason being, the OOP purists see it as a violation of the Single Responsibility Principle--an object should only have one reason to change, and the models are tightly coupled to the database schema so they have to change if the schema changes, plus you need to start up a database just to test their business logic, if you put business logic in them.

Meanwhile a lot of the practically minded developers like DHH just accept that their objects will be tightly coupled to the database and just deal with it, claiming that anything else would be adding unnecessary layers of indirection.

I am pretty new to Django, but I get the impression that it's not so hard to just not put your business logic in models.py, and put it in separate classes of plain old python objects instead. Maybe that's why I haven't heard about this debate playing out in the Django community the way it is in the RoR community...

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> >> The future is pretty irrelevant, so asking to design based on future requirements is uncanny.

The future is irrelevant? That's exactly what design is for -- to protect you from the future. If you didn't care about the future there would be no need to design at all.

A good way to evaluate various candidate designs is to imagine future use cases and ask which design holds up better. A good design will respond really well (ie., require fewer modifications) to novel use cases. Many people think this means design starting with future use cases. But you really just need to design with good principles. Future use cases are useful however at objectively evaluating designs and resolving arguments, such as Which design is better for futures that we care about?

>> Stating that "binding business rules to persistence is asking for trouble" is flatly wrong. Au contraire, It's the simplest thing to do, and in most cases any other solution is just adding complexity without justification.

Everything is a tradeoff. It doesn't make sense for many cases (hacking, etc) to avoid the simplest thing. But if you are building a project that's longed- lived, I can give you countless examples of how coupling business rules to model objects resulted in pain and copious paper cuts.

For me, I'll always decouple them. Why? Because it costs me nothing extra to do it and I have internalized the value in this principle from experience.

>>> Not all applications are big enterprise-y behemoths that benefit from Perfect 100% Decoupling™

You're right. It depends on how much you care about your future. Do you want your codebase to respond with agility to the future. Or are you okay with increasing your technical debt?

>>> Therefore, classes should be: >> small enough to lower coupling, but >> large enough to maximize cohesion.

Not sure I understand. Author seems to suggest these two are in contention with each other.

>>> Coding is hard and principles should not take the place of thinking.

Absolutely. There are many cases where the rules are to be broken. Systems with too much flexibility are just as bad as monolithic ones. It's an art what we do.

<comment><USER18> I think that putting cohesion and coupling on a 1 dimensional axis is kind of disingenuous. There are an infinite number of design changes that could be made and some of them increase coupling, some of them increase cohesion and all number of variations between the two variables. The best designs will find cohesion and coupling at local maximums.

<comment><USER19> I'm not saying you are wrong, but most of the literature indicates that high cohesion is correlated with loose coupling. The entire industry treats them as an axis so I don't think it is disingenuous for the author to do so.

<comment><USER18> I was a bit unclear: my general point is just that you can decouple code in ways that doesn't necessarily increase cohesion and you can decrease cohesion in ways that doesn't necessarily increase coupling. If you are designing a system with some rational interfaces and layers of abstraction, then most of the time you will find these two variables have a very direct relationship.

</comment></comment></comment></comment><comment><USER20> I rarely ever use classes anymore. My life is complicated enough, I like my code to be simpler. I used to be proud of my complex classes hierarchy and clever designs.. now simple objects and mostly functions. I don't and won't argue with anyone who prefer to use class hierarchies, but it really annoys me when I need to spend 5mins wrapping my mind around all those class relationships where a simple imperative (or functional) code would have done the job perfectly.

Most of the big design philosophies are around "building for the future", but the truth is that we're almost always wrong about it. And thus, most of time, the code needs to be rewritten. And a simpler, straightforward code is much more easier to rewrite or refactor.

<comment><USER21> I rarely ever use functions anymore. My life is complicated enough, I like my code to be simpler. I used to be proud of my numerous functions and clever designs.. now simple objects and mostly classes. I don't and won't argue with anyone who prefer to use plain functions, but it really annoys me when I need to spend 5mins wrapping my mind around all those functional relationships where a simple OOP (or imperative) code would have done the job perfectly.

<comment><USER15> It sounds like you're trying too hard to reason about functions as if they were, well, objects. You don't need to wrap your mind around "functional relationships" because functions don't have relationships. They just take arguments and return values (which can be other functions). Functional programming is not more complicated, if anything it's less complicated. It's just different, so it requires un-learning a lot of the things you learned about procedural and object-oriented programming. And if you have a good compiler/typechecker it will do the job with much less potential for bugs.

</comment></comment></comment><comment><USER22> Typically I write something 3 times. The first is a proof of concept, I don't care much about how it works as long as it works. The second time I put a lot more care into the 'how' but I usually still get a few things wrong enough that they are out of place and feel awkward to maintain or extend. The third time I have a really good handle on the problem, where the tricky parts are and how to tackle them. That third version will then live for many years, sometimes decades. Some of stuff I wrote like that in the 80's is still alive and well today (or some descendant thereof).

I try very hard not to get attached to code too much, refactor agressively and will throw it out when I feel it needs redoing. For larger codebases I tend to rip out a chunk between a pair of interfaces and tackle that section indpendently. I'll change either the code _or_ the interfaces but never both in the same sitting.

</comment><comment><USER23> So Uncle Bob talks about SOLID. There is one S there and then we have O, L, I and D. Applying SOLID is a balance of all of these things. We are craftsmen applying knowledge and skill to code. Trying to figure out SRP in isolation is not practical. When you attempt to apply SRP in balance with the other principles, you get more of the give and take that matches reality. There are trade offs and deciding what those trade offs are is your responsibility as a developer.

What the blog post is about is more of a: "I do things this way". Now I'm on a team and my team mate wants to do things a different way. Instead of realizing I'm on a team and it is matter of balancing abilities to make a cohesive software product, I'm going to bicker about why my team mate is wrong. And I'm going to write a big blog post about it and look at SRP in isolation instead of applying the same cohesive viewpoint (that I claim my team mate is missing) to understanding SRP.

<comment><USER24> I'd love to see a pragmatic take on the open/closed principle. I've seen a colleague extend a class, override the method in question by copying in the code from the super-class, then modifying it in the sub-class. Afterward he then replaces all instantiations of the old class with the new class. 'Open for extension / closed for modification' seems like it would lead to a nightmare in a few years.

<comment><USER19> So that is a really dogmatic approach to open/closed that is from the original formulation like 25 years ago. I've never encountered someone who would follow that practice when every instance needed to be changed (I assume Meyer would have construed that as a bug and allowed modification in that case). Even the less dogmatic Meyer definition of open/closed most people have left behind as it relies on implementation inheritance which is decidedly out of favor (and I believe rightly so).

In the more modern reading of the open/closed principle if you have multiple different variants on the behavior of a thing, you compose those variants in via an abstract interface. Then as you need to add even more variants you needn't change the original code any more only introduce more concrete implementations of the abstract interface that you compose at instantiation time as necessary. This approach is especially useful as your variant behavior grows. That is, a single boolean switch is probably easier to reason about than 2 implementations on an arbitrary interface. But once you get to 3 it becomes less obvious which is better. Any more than that and I usually reach for an interface without too much thinking about it.

</comment></comment></comment><comment><USER25> SRP is very simple. If two different people want to change a class for two different reasons, then pull those reasons into two different classes.

That is the SRP.

Example: A class that analyzes a data stream and prints a report. The data analysis will interest one group of people. The format of the report will interest another, different, group. The first group will ask for changes to the algorithms. The second will ask for changes to the format. The principle says to separate those two concerns.

This goes all the way back to David Parnas and the separation of concerns. His papers that describe it are freely available on the web. I suggest that they be studied, because they are full of wisdom and insight.

<comment><USER26> Hi Bob,

>SRP is very simple...different people want to change a class for ... different reasons...

Back in October 2009, in [https://sites.google.com/site/unclebobconsultingllc/getting-...](https://sites.google.com/site/unclebobconsultingllc/getting- a-solid-start) I asked you a question on the SRP and you replied as follows:

"SRP says to keep together things that change for the same reason, and separate things that change for different reasons. Divergent change occurs when you group together things that change for different reasons. Shotgun surgery happens when you keep apart those things that change for the same reason. So, SRP is about both Divergent Change and Shotgun Surgery. Failure to follow SRP leads to both symptoms."

Has the avoidance of Shotgun Surgery taken a back seat?

Philip

<comment><USER25> Not at all. SRP is about enhancing the cohesion of things that change for the same reasons, and decreasing the coupling between things that change for different reasons.

</comment></comment></comment><comment><USER5> In an OOP design where objects already encapsulate both state and behavior, describing the ideal state of affairs as "single responsibility" seems kind of optimistic.

<comment><USER27> I think "state and behavior" is a bad way of thinking about it; in OOP design objects provide behavior. Its true that they encapsulate state, but the state (ideally) is simply that state necessary to provide the intended behavior. The behavior covers the area of responsibility, the state is part of the implementation of the behavior.

<comment><USER28> That's still a lot of state. How do you know an object is in the right state to perform its behavior? Well, acting as some other object you have to either read the first objdct's state or model it internally. And now we're coupled on state and behavior.

So what if the first object ensures that it's always in the right state to perform it's behavior? Well, now it's observationally equivalent to a state- free actor. Why did you involve state in the first place?

Because languages make it hard to not do so?

</comment></comment></comment><comment><USER29> This doesn't feel like a genuine analysis of SRP.

The OP asks "but why should a class have one single Reason To Change™?" Answer is in the text - "If a class has more than one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class' ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed."

The case the OP makes for mixing Business logic and Persistance is really ironic too. In thinking he's arguing \against\ SRP, the poor example he gives actually argues \for\ it. Yes, validation and persistance _usually_ conceptually go together as one responsibility - storing your data. Calculating payroll (see PDF), is a whole different responsibility, better suited for a separate abstraction. So the strawman argument is not really in the PDF.

The book mentions the "Unbalanced" counterpoint already. See: "If, on the other hand, the application is not changing in ways that cause the the two responsibilities to change at differen times, then there is no need to separate them. Indeed, separating them would smell of Needless Complexity. There is a corrolary here. An axis of change is only an axis of change if the changes actually occurr. It is not wise to apply the SRP, or any other principle for that matter, if there is no symptom."

Now for the amazing TLDR of the entire piece, it goes something like this: SRP is not a clear and fundamentally objective design principle, so let me offer another principle __huff ____huff __but dont worry its not clear cut (so dont follow it?!)!

This doesn't lead anywhere. Talking to the co-worker more might have been better than adopting a defensive attitude.

The big lesson here is, learn concepts like Cohesion vs Coupling, SRP, design patterns, to give you a common vocabulary, but keep your mind open and try to write code that is well organized and is free of code smells. If anybody has suggestions on how things can be improved, measure their suggestion on its merits. Software development is an excercise in balancing all kinds of different types of concerns - pun intended :). Sit down and list pros and cons between alternative approaches, and let the design that best addresses the problem/constraints at hand win.

And even better, next time, if you want to save yourself some trouble, ask others for their opinions and share your concerns with the code before you even write a line of code. Then nobody will get 'religious' in a code review and it will allow a team to focus on results.

</comment><comment><USER18> To me it makes sense to think about how much state is being mutated in a given class. If you have a class with 200 different properties that are changing somewhat orthogonally to each other, you probably need to think things through and separate concerns a bit. Still kind of an 'arbitrary principle' but another way of looking at things. You want to encapsulate the moving parts but you don't want to throw every moving part in a giant bag.

Designating a class as having a single responsibility is an easy way to ensure that there is a minimal amount of state per class, but if the abstractions you are creating with this principle aren't logical than you are still left with a lot of moving parts someone has to think about when making modifications.

All these principles mostly only work if the system is also being designed rationally. Applying principles arbitrarily to a messy codebase will not necessarily get you a good design (and probably not) but thinking about these principles when making design decisions can sometimes be useful.

<comment><USER30> More cynically: Trying to apply a set of principles (any set) instead of thinking will likely lead to trouble.

<comment><USER18> Haha yeah, I think you have a point there. Perhaps programming is so challenging it awes otherwise intelligent people and makes them reach out for simple rules to simplify their lives.

</comment></comment></comment><comment><USER6> I've found that if you approach OOP from a more pragmatic point of view, metrics like the sizes of classes mean very little: the point of classes is to encapsulate code+data so they can be reused to avoid duplication, so it feels obvious to me that if you see (non-trivial) functionality in a class that is likely to be reused in the future, then extract it into another one, but if you don't then there's no point in doing so, because it will only increase the overall complexity. Same for OOP in general - it's a tool, use it when it makes sense and simplifies the design. Sometimes you don't need a class, and sometimes a function doesn't belong in one because it does things across several, so all the "which class should this function go in" questions have a straightforward answer to me: if it's not immediately obvious which class it goes in, it probably doesn't belong in one. I mainly use Asm/C/C++ so I have the luxury of doing this, but I can see how some of the "more-constraining" languages make this more difficult.

 _All the examples I see are one-way towards simply creating a million single method classes._

That's a phenomenon that I've definitely seen a lot; often with the accompanying _obfuscation_ that the method bodies have only one or two statements in them, that just calls into some other methods. It may look like it's made the code simpler locally, but all it's done is spread the complexity out over a wider area and increased it. This isn't "well-designed" or "straightforward", it's almost intentional obfuscation. I've seen this effect most with programmers who were taught OO design principles very very early, possibly before they even had a good grasp of concepts like procedures, loops, and conditionals. "When all you have are classes, everything turns into an object."

</comment><comment><USER31> I agree that the SRP is certainly a subjective rather than objective principle, and possibly general guidance that can and should be broken in specific circumstance. This article points that out but rather than try to apply prescriptive guidance around making it more objective in specific scenarios, the author seems to believe that its subjective nature is too flawed to fix.

What's the issue?

> A good, valid principle must be clear and fundamentally objective. It should > be a way of sorting solutions, or to compare solutions.

Okay, I'm listening. What is your alternative?

> It's not a clear-cut principle: it does not tell you how to code. It is > purposefully not prescriptive. Coding is hard and principles should not take > the place of thinking.

And.... we're right back to subjective and general again. Set up a straw man only to knock it down with an identical straw man.

Of course, reducing coupling and raising cohesion makes the class responsible for less and less... So are we back at the authors interpretation of the SRP? Seems like it to me.

</comment><comment><USER19> First let me say, I completely agree that the definition of the SRP as it shows up in the Uncle Bob book is a little hard to understand. The wording is off.

That said this entire article is essentially arguing FOR the SRP. The whole point of the SRP (in conjunction with the rest of the SOLID principles) is to decrease coupling and increase cohesion. In his refactor of class C we have an example in the first case of a class that violates the SRP and an example in the second of 2 classes that follow it. Excellent, the author and Uncle Bob are both happy.

But what really bothers me about this article is the following: "Furthermore, there is no reason to separate "business" logic from "persistence" logic, in the general case. The large majority of Employee classes that people need to write are likely to only contain fields and maybe some validation -- in addition to persistence."

A) Please don't tell me what the large majority of things people need to write are. You cannot possibly actually prove that assertion. In my experience having a 1 to 1 relationship with a class and a database table is a sign of either a very simple problem space, or a very poor design.

B) If you do happen to work in a problem space and are finding yourself writing something that is a collection of fields, some validation and some persistence, that is not an example of a violation of the SRP, it is an example of you needing an EmployeeRecord and not an Employee. The difference is simple, an Employee has complicated business logic in it and a record does not.

This seems to be the central debate currently around Uncle Bob's tactics. Lots of people seem to be writing PVC (Persistence-View-Controller) applications and thinking they are writing MVC (Model-View-Controller) applications. It then seems to be overkill to split out the persistence layer from the "model" layer because there isn't much difference. If there isn't much difference you didn't violate the SRP! Your Single Responsibility is persisting some data! Your design is fine. Move on with your life. But on the other hand, if you find your self writing complicated business rules that are hard to test because of the wiring required for your persistence, maybe you've violated SRP and should split them up a bit.

</comment><comment><USER32> In the absence of finding the time to really tear it apart, it seems that there are a few false choices in the article. I don't think a class that fulfills SRP necessarily means a tiny single-method class. It could mean a collection of methods that each do one conceptual thing, at one abstract level of understanding, but where the class and collection of methods is still cohesive.

The example of the client needing to instantiate B to pass it to A's constructor seems like a poor example of tight coupling. The only reason to instantiate B is because A needs it. The client doesn't literally need to know about B, it simply needs to know how to construct/build A. This could be done through a factory or service locator, or it could be done by A having B autowired into it, which would free the client from having to instantiate B directly.

I do, however, agree that SRP is poorly defined in most of the resources you find, so if anyone has links of case studies of applying it properly, they'd be interesting to review.

</comment><comment><USER33> I'm not an expert but I think he is misinterpreting what is meant by 'change' entirely. My reading of it is as in the class only has one reason to change (state). Correct me if I'm wrong.

<comment><USER34> The SRP, as I was taught it, means that there must for each class only one kind of change in the requirements of the program that requires a change in the class. "Kinds of change" are quite vaguely defined, though.

</comment></comment><comment><USER35> From the linked article: "Fundamentally, the SRP principle is therefore a class sizing principle."

This is incorrect. The SRP is a dependency management principle. It has nothing to do with the size of classes (however that might be measured). The goal of this principle, like the rest of the SOLID principles, is to minimize the impact of changes.

</comment><comment><USER36> I think you are focusing on the wrong phrase in the definition of SRP. You are focusing on reason for change without the context of responsibility. The way I read that definition is: if a class has more than 1 responsibility then making a change affecting any one of those responsibilities will require the class to be recompiled where as if those responsibilities were broken up in different classes making a change affecting one responsibility would not affect the other classes.

Hence a bug fix does not constitute a "change" since it does not change the responsibility of the class, neither does a refactor for code clarity or performance improvements. The purpose/responsibility of "what" the class does, does not change when you do any of those things.

"sometimes a class with more reasons to change is the simplest thing" Could you give an example of this? I can't think of one instance.

"Stating that "binding business rules to persistence is asking for trouble" is flatly wrong. Au contraire, It's the simplest thing to do, and in most cases any other solution is just adding complexity without justification" Now this statement here is flatly wrong precisely for the reason specified in the Uncle Bob's example. Let's do a thought experiment. Consider that you have an Employee class that is a black box to you. Someone else wrote that code and didn't have any exception handling logic in their code. The Employee class did business logic and persistence control. When you tried to use the class there was an error. Now which part of the class was faulty? The business logic part or the persistence control part? Now consider that you needed to use the same Employee class in another project but it needed a different set of business rules but the same persistence control, you would not be able to use this Employee class you would have to create a new one and duplicate your persistence control code.

Design principles have been developed to make sure that code written is maintainable, extensible, clear, comprehensible. Sure me as a single developer who is working on a simple project, who knows what each of my class does and has a small enough code base such that I don't need to separate the application into layers (e.g. call my database directly from my view because I just need this one value and don't want to write a couple of classes to that) can indeed write classes that have more than 1 responsibility. There's nothing to stop you but it does violate the SRP which will make it tougher for someone else to come in and maintain your code or extend it.

</comment><comment><USER37> I didn't read the whole post since it starts by stating that bug fixes, performance tweaks and refactoring may be changes - which whilst true is being deliberately pedantic, and if an article starts out fussing about such pedantics for more than a paragraph without then owning up to this being a deliberate extreme case example for illustrative purposes causes me to devalue the whole article and thus not invest more time reading it.

A change, in the context of SRP is a change of responsibility / functional purpose.

Regarding the granularity to which you should go to with SRP, the idea is that it's not fixed; you change this as feels best for your code base. If you write code without much logic (e.g. a basic CRUD application with minimal validation) it's fine for the classes representing your tables' records to also hold their logic, since at this stage the single responsibility is, say, Employee. Once you start to get something more complex the separation of concerns becomes more important, so you need to break this apart into Employee Record and Employee Validation; perhaps more layers. That may seem contradictory as there are now two classes with two responsibilities where before there was only one class with one and a bit responsibilities - but the key is to be pragmatic. Don't write thousands of lines of code and multiple classes if that introduces complexity with no pay off. However, if you have one class that does too much it'll become hard to maintain; and being aware of the SRP principle will help you work out a sensible way to break that class down into more comfortably manageable chunks.

</comment><comment><USER12> The Single Responsibility Principle is like Body Mass Index for code: it's easy to measure (humans have an innate sense of what "reponsibility" means) but outside of extreme situations it is not precise enough to base serious decisions on: there is a huge grey area where people do not agree on what responsibilities are.

It's the same as EDD: it's fairly subjective, but it weeds out the extreme cases.

The benefits of SRP are usually a side-effect of applying more objective rules to the code.

DRY is the primary driving force. It pulls shared responsibilities out of modules and leaves no doubt that those responsibilities were shared. It detects recurring concepts and gives them a representation, thereby increasing coupling.

The second force is to reduce access to private code: out of 100 lines of code in your module, how many actually need to access that private concept on line 42 ? If the answer is "30", then what are those other 70 lines doing in this module ?

Apply both forces to a code base, and the SRP will appear out of nowhere.

</comment><comment><USER38> I always interpreted the SRP in terms of how well one can describe the responsibility of the class.

If one has to write "This class does x and y and sometimes z if w", it's got several responsibilities.

If one can write "This class does x", it's OK.

X can then be arbitrarily complex, so code size has nothing to do with it in my world.

</comment><comment><USER39> "The purpose of class is to minimize complexity" "The purpose of class is to organize code" "A class should have one, and only one, reason to change"

What?

What about: "The purpose of class is to encapsulate state".

If there is no inner fields in class, there is no reason for class. There is no state.

One or more fields in class means that they make sense when looking at all of them together, as a "state". If some method changes something, the all state encapsulated by class means something else.

It is possible to extrapolate all other guidelines from this basic starting point.

<comment><USER40> Do you see "having a state" as "being able to change state" ? Because classes may be used to represent concepts or objects from the real world. Some of them may not have a changeable state but inner fields certainly.

</comment></comment><comment><USER41> Likewise with many here, I agree with most of the author's points, especially that one should think for one's self, which sklivvz did very well.

However, the fear of many little objects smells strikes me as backwards. Unix systems are built with and used by many little utilities. As a result, a few simple commands can be strung together to make quick work of interacting with the system. Often, I find that the hardest utilities to master are the ones with the broadest scope. My experiences with large objects are similar.

<comment><USER40> You got a point. Let me add that little objects allow you change inheritance for composition more easily.

</comment></comment><comment><USER42> I think the "don't mix persistence with biz logic" idea came largely from the Rails world, where the ease of doing so led to a great deal of bloated code. Well, it's only slightly harder in Ruby to separate them, and it gives so many ancillary benefits to cutting ActiveRecord::Base out of your biz logic that you probably should. Other languages/platforms, they don't always make this kind of separation easy or idiomatic.

<comment><USER27> > I think the "don't mix persistence with bizlogic" idea came largely from the > Rails world

I'm pretty sure I encountered that particular example of things that shouldn't be coupled in OO design before Rails _existed_.

<comment><USER42> I guess I wasn't clear enough. Certainly the _idea_ predated Rails, but I think the heavy insistence you see pretty much everywhere on segregating them probably came from Rails.

<comment><USER43> "Multi-tier architectures are characterized by the separation of the user interface, business logic and data access logic. Many organizations are implementing multi-tier architectures for enterprise applications to realize the two key benefits."

1996, and I am pretty sure this marketing speak page reflects what had already been being talked about in the industry for quite some time.

[http://edn.embarcadero.com/article/10134](http://edn.embarcadero.com/article/10134)

</comment></comment></comment></comment><comment><USER44> In most OO languages like Java , classes the only large-scale structuring mechanism.An opposite example is OCaml which provides both classes as well as sophisticated module system.So classes in these(like Java) most languages tend to get tied with more and more features ( from lang perspective) to which implementers are forced to adapt!Hence most of these principles fail to see day-light in practice!

</comment><comment><USER45> I think SRP in terms of using classes with dependency injection. If you are injecting an instance of a class you only want it do do one thing and changing the class being injected you only want it to change one piece of behavior. If the class has more than one responsibility it would mean that injecting dependencies would become unmanageable.

</comment><comment><USER21> "If client code need to know class B in order to use class A, then A and B are said to be coupled. " \- still better than the common 'Service Locator' anti- pattern where you aren't even aware of dependency.

</comment><comment><USER46> I generally go by file size now, after 200 lines, we need to find an OOP excuse to split (interestingly, I almost never merge, but there might some thermodynamic reason for that).

<comment><USER47> I do it this way simply because I don't like having to scroll too much.

</comment></comment><comment><USER48> How else would you add N new persistence options to your class that implements persistance & data model?

<comment><USER49> I prefer to work on features rather than changing databases for the fun of it.

</comment></comment><comment><USER50> It seems like the best way to design a codebase is to redesign (rewrite) it several times and then go with the most succinct design. For any given problem, it's unlikely you'll design the codebase properly on the first try. Also:

 _when one writes code, there are only real, present requirements. The future is pretty irrelevant_

I'd disagree with this. The future of your codebase matters unless you're writing a throwaway prototype. And when you rewrite a codebase N times, you'll discover that there are ways of structuring it so that future tasks will become far easier. E.g. for Lisp you'd refactor common patterns into utility functions, and for C you'd carefully craft the interfaces between modules so that they're unlikely to be used improperly / unlikely to be surprising.

</comment><comment><USER49> Fuck SRP, just read the resulting code.

Whichever code is more concise & readable is generally the winner.

(Note: a lack of understanding of algebra / calculus does not make the code 'unreadable', it just means the developer is innumerate)

<comment><USER19> Unless it fails to meet the requirements or is written in such a way that will require more maintenance...

<comment><USER49> Well, I'm assuming we're comparing code that works.

Maintenance is generally a red herring, it's best to use statistical methods to determine the likelihood of maintenance.

Usually if you're doing lots of maintenance you have other problems in your code / workflow, such as mistaking your codebase for your database.

<comment><USER19> "Well, I'm assuming we're comparing code that works."

That is an interesting assumption given that in many problem domains proving that the code works as specified is the hardest problem.

"Maintenance is generally a red herring, it's best to use statistical methods to determine the likelihood of maintenance."

I really dislike anyone who makes general claims about the entirety of software development. I for one spend way more time changing existing code than writing new code. I know that there are problem domains where that is not the case so I don't recommend my methods for those spaces.

What are these statistical methods you are referring to?

"Usually if you're doing lots of maintenance you have other problems in your code / workflow, such as mistaking your codebase for your database."

Or you are working in a problem domain that shifts a lot, or where requirements specification is more expensive than deployment opportunity costs, or in a legacy system.

<comment><USER49> Proving your hand won't go through a wall is a difficult problem in quantum physics, for most people they just push against the wall. I don't care whether the code is provably correct, I care that it does what the user expects.

Actually 'change requests' are even easier when the requirements change frequently, just provide an estimate in excess of when you think the next change will be, then put your feet up and wait for the requirements to change again.

PS. Changing requirements isn't 'maintenance', it's a change request.

PPS. Having to add code to add fields to a form means you spec'd your solution around your forms instead of specing your solution around solving the problem of changing forms. (aka. you baked your problem domain into your code and now you're fucked) (eg. you mistook your codebase for your database)

</comment></comment></comment></comment></comment><comment><USER51> Size is, and has always been, at least in my opinion, a symptom of failing the single responsibility principle. Its not the cause. Its only useful as an indicator, you still have to look at the case, figure out if the function / class is doing more than one thing. And even then, a function / class can do more than one thing, to increase cohesion, and limit bloat / complexity.

General rule I use: does this block / section of code increase complexity of the overall purpose of the function or class. If it does, it should probably move, likewise if it isn't relevant to the overall functionality / behaviour it should also probably be moved.

Everything is a trade off in the tech world. You can't argue you are right or they are wrong, only that you are right in this instance or that.

</comment><comment><USER52> Reminds me of this: [http://bendyworks.com/geekville/articles/2014/2/single- respo...](http://bendyworks.com/geekville/articles/2014/2/single- responsibility-principle-ios)

Comments are the most interesting part :)</comment>


We've predicted and broken human population limits for centuries - <AUTHOR> http://nautil.us/issue/29/scaling/will-the-earth-ever-fill-up <comment><USER2> > Humans don't just extract from a fixed set of resources, but can create new > resources through invention.

Perhaps I am being pedantic, but that sounds like nonsense. Sure, humans invent stuff, but they don't invent the resources. They invent new ways to access previously inaccessible resources, or extract accessible resources more efficiently. But they don't magic more resources into being.

<comment><USER3> Nothing is intrinsically a 'resource'. Something becomes a resource when it can be used to further some human activity. Iron wasn't a resource until iron forging was invented. Without humans, no resources exist.

<comment><USER4> But the iron was already there before we declared it something useful. Ants use 'resources', so do bacteria so without humans resources definitely do exist and are being used actively, whether we declare something to be a resource to us or not does not change the fact that it was a resource _before_ our wandering eye fell on it.

Asteroids are a nice example. They're 'untapped resources', objects we one day may use as resources but which for now just sit there because we haven't found a way to make tapping that resource cost efficient.

<comment><USER3> Fine: nothing is intrinsically a resource. Nutrients weren't a resource before _some self replicating process_ started using it for some purpose, probably fairly directly related to replication.

And iron ore still wasn't a resource until humans came along and invented forging.

The term 'resource' does not describe the natural state of something. It describes a relationship between things: something is a resource for some goal(s), by some entity(ies). The relationship did not exist when the other party was not in that relationship, for instance because the other party did not exist. Thinking new resources cannot come into existence is making a category mistake, thinking whether something is a resource is absolute, intrinsic, independent of context.

</comment></comment></comment></comment><comment><USER5> There are also cultures that vanished after thousands of years, and crisises in which millions of people died. Human ingenuity and technological progress didn't solve every problem. We just forgot about the dead (classic survivor bias). Collapse by Jared Diamond has some examples of societies that failed - by comparison, our current civilization is very young and hasn't really "played out" yet.

Maybe the estimates of Malthus were wrong, but the underlying concern is still correct. Our current food production is not sustainable because it relies on non-renewable energy sources. I don't claim no solution can be found for that, but there is also no reason to believe there will be a solution.

Another way to look at it makes it very plain: the surface area of earth certainly is limited. So if population would grow forever, we would reach a point where every person would only have one square foot of ground to live on.

Even that might be doable - we could live in a stacked way (skyscrapers), or Matrix-Style in coffins with virtual environment. Nevertheless it doesn't seem like a very desirable future.

</comment><comment><USER6> My question is why do we need more people or want to encourage or allow it to occur?

My immodest proposal is to introduce a natural decline in human populations to more easily sustainable levels via the introduction of a reproductive "right": every individual when born is entitled to one child.

A couple, then, could have a family with two children. Those who aren't interested in having children could sell their "right" off on a market to people who want to have more than their one child individually, so a couple could buy the rights to more children and a larger family from those who don't want to have children. The market could even fractionalize/derivatize those rights so that individuals could sell "half" a childbirth right and two of those individuals could have a family with one child.

The best part is, at two children per two parents, it's lower than the replacement rate of "2.1" which means population levels would humanely decrease with no need for wars or murder.

Our current societies are predicated on larger youth populations than parent populations to support us in our old ages, but this strategy combined with robotic technology for the elderly and post-scarcity economics would free us from that pyramid scheme. This helps support a basic-income type scenario for those people who assume that everyone (or 'THOSE PEOPLE') living in our society will just have tons of kids due to boredom. Like the fears trotted out about "welfare queens" having tons of kids because they supposedly get "free stuff."

<comment><USER7> So the rich have large families, and the poor have forced sterilization?

<comment><USER6> It's voluntary. Perhaps you missed the part about the basic-income and right to a child.

</comment></comment></comment><comment><USER8> Population limits are certainly a well-documented phenomenon. Chinese history shows excellent conformance to a "punctuated equilibrium" model -- the population is stable nearly all the time, with two obvious sudden increases. (From memory, I believe the increases correspond to (1) the local development of a new, more productive strain of rice, and (2) the introduction of crops from the new world.)

The inference is painfully obvious: for most of history, China has been populated _at_ its own carrying capacity. The fact that the limit was broken (really, raised) a few times doesn't mean the limit isn't a worthy concept.

</comment><comment><USER9> Why is this issue getting so much attention? It is a problem that will solve itself, wherever the limit is. The only reason to worry about where the limit is, is if you want to avoid it with birth control so that some nicer forces than famines or resource wars keep the population stable. But even that seems unnecessary, at least in the developed world, because the population growth rates or even the populations are already declining. Which of course is a good thing, why would you prefer a more densely populated world over the status quo? Why would you want to raise child after child if two and a half are enough to sustain the population?

<comment><USER5> It will solve itself, but billions of people might die as part of the solution. Mankind will survive, but for the individual some worrying might make sense.

<comment><USER9> The people that can prevent overpopulation don't suffer from it, the people that suffer from it can't prevent it. So it's more of worrying for once children's children.

</comment></comment></comment><comment><USER10> Yikes. I didn't realize the population density in Mumbai was near 53k people per sq. mile. Apparently Manila is nearly twice that at 111k.[1]

Still, it surprises me overpopulation fears are so commonly expressed. Seems like a greatly overblown meme that will end up doing more harm than good. Much like Malthus opposing projects to feed the poor and hungry, I sometimes hear people going as far as saying we (meaning relatively wealthy, white Americans) should just "let them die" when it comes to impoverished people all over the world. Despite the fact that, if energy consumption and environmental damage is the fear, people in industrialized countries use as many resources as dozens, hundreds, maybe thousands of lives in the "developing" world.

The world could likely support orders of magnitude more people than we give it credit for. We haven't even started harnessing materials from space industry, space-based solar power, or using the oceans and seabed as living space. There's another 70% of the Earth's surface that hasn't even been touched yet, and that percentage grows even more when you consider the vertical spaces available within it. The overpopulation meme seems more dangerous to global welfare than actual overpopulation has ever been thus far.

Kevin Kelly's edge.org response is a good read on the entire overpopulation issue: [http://edge.org/response-detail/23722](http://edge.org/response- detail/23722)

[1] [https://en.wikipedia.org/wiki/List_of_cities_by_population_d...](https://en.wikipedia.org/wiki/List_of_cities_by_population_density)

<comment><USER11> The world probably could support lots more people than it has now. The question is, why? If we believe 30 billion people is possible, should it be a goal? What's better about 30 billion than 6?

<comment><USER10> 1) Reproduction is a natural right, and some people would consider having children to be a great fulfillment. The evolutionary basis of this desire would make it all the more powerful, and restricting it would only cause the drive to grow stronger over time (as traits evolved to promote the circumvention of the restrictions).

2) If there's no specific advantage to a lower or stable population, why is any particular number preferable to another?

3) There are lots of advantages of large population: larger communities for people with low-frequency deviations from social norms, a broader spectrum of human social and psychological possibilities represented, increased production and creative capacity, greater base of working-age citizens to support the non-working portion (retired, children), more people at the top of the bell curve to draw from for important positions (better leaders, more geniuses, etc)... This is not an exhaustive list.

4) Likely other advantages as well, which would seem to counter the disadvantages of larger population, judging from past human history (and assuming no weird non-linear relationships). If the world is better with fewer people, would you want to go back and live in a world with only 100,000? 1,000,000? Some other specific number?

<comment><USER9> 1\. Reproduction is not a natural right. If you reproduce beyond a sustainable level your offsprings will pay for that with reduced life expectation and being unable to reproduce in consequence. It's essentially the same thing that happens in predator prey cycles. And you don't have to cease reproducing altogether, just limit it to a sustainable level of about one child per human.

2\. There are of course advantages to stable population sizes, most importantly resources will last longer and allow sustaining human society for longer.

3.1. larger communities for people with low-frequency deviations from social norms

It is not obvious to me why that is a good thing.

3.2. a broader spectrum of human social and psychological possibilities represented, increased production and creative capacity

That seems to be the best argument for larger populations besides increased production capacity because that is countered by an increased consumption.

3.3. greater base of working-age citizens to support the non-working portion (retired, children)

That is not true for a larger population, the proportion is the same as for a smaller one. It is only true while the population is growing and that is either unsustainable or the effect is unimportant if the growth is marginal.

3.4. more people at the top of the bell curve to draw from for important positions (better leaders, more geniuses, etc)

That is essentially the same argument as 3.2.

4\. Smaller populations are not necessarily better, you benefit from decision of labor, scale effects, you are more resistant to disasters. The optimum is definitely somewhere in the middle, it is neither one human that can no longer reproduce and will easily go extinct, and it is also not ten to the hundred for obvious reasons. The question is therefore definitely not whether or not we should seek for a stable population, it is where the most desirable level is.

And here I argue we should first bring the entire world population to the levels of wealth, education and consumption of the middle class of leading developed countries and then we can have a look at how much resources are left, what happened to environment and climate, whether we need more smart people.

<comment><USER10> 3.1 - A good thing because people with unusual interests and personality traits will be able to form communities of people with similar interests. For example, in a town of a thousand people, you might be the only one who enjoys an odd hobby like underwater hockey (it's a real thing). In a city of ten million, there may be hundreds or thousands of people to form an entire league with. "Deviations" as used wasn't intended to have a pejorative connotation.

3.2. Contradicts the basic premise (no immediate resource limit) and the original article. The world has become richer despite growing population, because production has outrun consumption. No reason to think it will stop in the immediate future, any more than it did in Malthus' time.

3.3. You're simultaneously saying the economic problems arise when population stops growing and becomes stable, and supporting ending population growth in favor of a stable population. If there's a limit where quality of life decreases due to increasing population, we haven't hit it yet, given that quality of life and per capita wealth is still improving globally, so there's no reason to put the brakes on before we even know where it is.

> _it is also not ten to the hundred for obvious reasons._

We're assuming technology and productive capacity also improves to keep up. We're also nowhere near 10^100. Nor do we know where this hypothetical optimum is. Population controls should be a last resort to solving problems we are't facing yet, not done just because a theoretical optimum for quality of life may exist at some hypothetical large number.

<comment><USER9> 3.1. But that also means that all the bad minorities can form stronger groups and be potentially more impactful. If you can not play underwater hockey you might pick some other form of hockey instead. Maybe it makes you a bit less happy but what is the effect of a less fragmented society? I am not dismissing the idea that there might be a positive effect but I am not obviously convinced.

3.2. I would argue that the increase in wealth is mostly due to increased productivity and not due to population growth and therefore could continue even without further population growth. Population growth is certainly not totally irrelevant due to scale effects but I don't see that simply doubling the population would lead to significantly increased wealth.

3.3. That is not what I am saying. Having a pyramid shaped age structure is an easy way to have a lot of workforce available to support the elderly but that structure is not the result of a large population but of an growing population. And in order to be a significant effect you can not have just a tiny bit of growth but a substantial amount of growth is definitely unsustainable.

The limit definitely exists but I also think we will not hit it, we will not need any (large scale) birth control policies because the birth rate will drop enough with increasing wealth. Looking at developed nations it looks actually more like we will have to incentivize having more children in order not to go extinct.

</comment></comment></comment></comment></comment></comment><comment><USER12> I lived in Ireland and Greece. Many regions there had population peak centuries ago and now are in decline for several decades.

<comment><USER13> Most developed nations currently have declining populations. For now it seems like we can simply stop population growth by bringing the rest of the world to our level of wealth. Then again there's the question whether earth has enough resources to make that even possible.

<comment><USER14> > Then again there's the question whether earth has enough resources to make > that even possible.

In terms of energy: definitely. Nuclear or now solar suffices.

</comment></comment></comment><comment><USER15> According to Swedish professor Hans Rosling the fast population growth is coming to an end and the population size is expected to stabilize at 11 billion people by the end of this century. His statistics and predictions are based on data from the UN Population Division.

[http://www.gapminder.org/videos/dont-panic-the-facts- about-p...](http://www.gapminder.org/videos/dont-panic-the-facts-about- population/)

[http://www.gapminder.org/news/world-peak-number-of- children-...](http://www.gapminder.org/news/world-peak-number-of-children-is- now/)

</comment><comment><USER16> i think we need to define limits in terms of energy. there is a certain amount of energy that comes in from the sun that life then uses to decrease entropy. that energy can be used by any form of life to do work. we broke those limits by in part by displacing a lot of other life. so yes we can probably push the limits even more and displace yet much more life on the planet. at some point however that fact will effect us unpredictably.

<comment><USER17> > i think we need to define limits in terms of energy

Ok. Let's do that. The earth receives about 10,000 exajoule per day (3850000 per year) [1]. Daily human caloric intake is 2500 calories [2]. Let's say inefficiency and the fact that you actually need food, not pure energy, let's say that means 20% efficiency, so 12500 calories per human daily. 12500 calories is about 50k joules. Things like running a tv/computer/... would be peanuts on top of that so they "come free".

So divide one by the other. The earth, without space based power, can keep about 1e18 humans alive on this planet using just earth-based solar power.

Plus you have to keep into account what humans actually do : they convert chemical energy into heat. If we cover the planet in solar panels, why couldn't we recover most of that human-generated heat ? Let's say we can recover 99% of energy that we put into humans back out, that's another factor of 100 right there.

We could use nuclear to increase that number to 1e30 or so for a millenium and if you count fusion based power, the numbers become completely ridiculous.

To put that number in perspective, take it like this : when every human alive today breeds into a population the size of today's entire human population, then we'd be near the "pure solar" carrying capacity of just the planet itself. If we were to beam power from space to the planet, we wouldn't run into the next limit until 1e50 at least.

So we are very, very, very far away, even on an exponential population curve, from the carrying capacity of the planet. When fitting an exponential curve to some sample data (very inaccurate, but good enough for a ballpark figure), I get that if the growth since WWII (1.36% per year, starting at 2000 with 6 billion people), then we'd get to 1e18 a little after the year 3400.

> we broke those limits by displacing a lot of other life

Only for a few measurements. There are a lot of problematic measurements of life that are inaccurate and therefore full of noise, and can be outright deceptive. Some of those measurements look bad : number of species, for instance. But how relevant is that number ? Sure, if it keeps dropping our zoos will become boring, but what will actually happen ? The truth is nobody knows, and there doesn't seem to be a reason, aside from nostalgia, to assume it's bad. One "real metric" that is at least measurable and I believe is meaningful : the total amount of life is total biomass, and it is pretty well known that humans have increased that by a lot.

> at some point however that fact will effect us unpredictably

It seems to me to be pretty much a given that lots of things can affect the human race unpredictably, and given how many such factors there are, it seems a safe bet that a few are indeed going to affect us (though the vast majority won't). Malthusianism and global warming are such factors, malthusianism has been proven false 3-4 times at least, and many limits to growth theories both before and after have been (I like the economic "debt limit" ones, stating that we can never have an economy larger than the value of all gold, then we passed that, then money became "loaned gold", and the next theory was that there was some factor that limits how big the economy can be n * total_gold, n was to be 10, then 100, now it's at least 100 million, and they're still at it), I wonder what the fate of global warming will be.

If you believe in Darwin and evolution, this is a positive. We will adapt to whatever effect, predictable or unpredictable, starts affecting us.

[1] [https://en.wikipedia.org/wiki/Solar_energy](https://en.wikipedia.org/wiki/Solar_energy) [2] [http://www.webmd.com/diet/estimated-calorie- requirement](http://www.webmd.com/diet/estimated-calorie-requirement)

<comment><USER16> One question that I have if there is so much energy then why is life not using more of it? I guess there are a bunch of other constraints on life other than the sun's energy so my point is off.

<comment><USER4> Conversion inefficiency, maximum conversion limits (a black leaf would burn up in full sunlight), consumption of energy by other bits and pieces of the planet other than living creatures (the atmosphere, for instance is a huge consumer, as is the planet itself, just to keep it above freezing, see also: albedo).

</comment></comment></comment></comment><comment><USER18> Population growth is exclusively cultural. See how it's declining in Europe, still growing fast in Africa, etc.

Science could change that very fast: birth control isn't available to everyone on earth... yet. But religion could change that fast too.

So I guess estimates for the earth population will depend on both science and religion more than anything.

<comment><USER2> also helpful in reducing birth rates: education and the available economic opportunities for young women

</comment></comment><comment> daniel-cussen Same thinking as "housing never goes down." How did that one go?

<comment> daniel-cussen Edit: also, remember Easter Island, where the population dropped by over 99% after an ecological disaster last millennium.

</comment></comment><comment><USER19> I suspect that at 7 billion now, if the world population rose to even 100 billion, we'd find a way to survive. It would be a very different life experience, but it would still be life.

<comment><USER4> I highly doubt we'd be able to feed and house 100 billion people.

<comment><USER20> Able yes, but at very high risk of deadly instability through destroying most of nature and accordingly higher dependence on technology, and smoothly working social structures?

<comment><USER4> Unsustainable to me means 'unable'. If you can't sustain a model in the long term that means that sooner or later there will be a crash. Whether the number of people we can sustain long term is 10, 20 or 50 billion people is currently not known but most people that have spent significant time on this problem put the long-term sustainable number closer to 10 than to 20 billion. Now, as the article states we've consistently under-estimated these numbers but even very generous allowance for errors would cap the number that we could long term sustain in any form well below 100 billion.

<comment><USER21> Are you that good in predicting the future hundreds of years ahead?

World population is not going to reach 100 billion in the next 200 years.

New technologies may allow:

1) Grow food in cold climate (Russia, Canada and even Antarctica).

2) Grow food in the ocean.

3) Grow food under ground.

4) 10x+ increase in food output from the same amount of land.

5) Industrial food synthesizing.

<comment><USER4> > Grow food in cold climate (Russia, Canada and even Antarctica).

Needs an energy source

> Grow food in the ocean.

We already do this and we call it fish. We're also _terribly_ bad at managing this very important resource.

> Grow food under ground.

Needs an energy source

> 10x+ increase in food output from the same amount of land.

Needs wildly fantastic breakthrough in practice, currently at odds with the theoretical maximum yield from acreage.

> Industrial food synthesizing.

We already do quite a bit of this but you'd have to come from an entirely different angle (such as synthesizing protein from non-biological sources, currently not a possibility).

So, with present technology and present knowledge about energy budgets and support capabilities of arable land it's as far as I can see right out.

If there is some totally out-of-the-blue breakthrough (such as atomic synthesis of arbitrary compounds combined with free energy) then sure, anything is possible. But that's the same kind of bet the cryonists (sp?) make, or even some religions, once you allow for miracles the future possibilities are limitless.

I'll be more than happy to concede that there will be improvements in yield but the amount of sunlight falling on an acre of land and the available minerals and precipitation are limiting factors, even when you factor in greenhouses, artificial lights, irrigation and so on. Hydroponics is probably eventually one of the most efficient ways of doing all this and even that has fairly hard limits in terms of energy required and amount of nutrients and water required.

<comment><USER21> > Needs an energy source

Sun. Fission. Fusion.

> you'd have to come from an entirely different angle

Not me personally, but tens of billions of new people who would be born in the next couple of hundred thousand years.

> If there is some totally out-of-the-blue breakthrough

If in 1900-2000 food production increased 5x then it is reasonable to expect that in the next 100 years food production may increase 5x again (or more if needed).

It looks like you want to have enough food now (in 2015) in order to be able to feed world's population in 2215.

Why do you need to have that food 200 years ahead of the actual demand?</comment></comment></comment></comment></comment></comment></comment>


What's the deal with Toptal? - <AUTHOR> Hi. I'm a JS developer located in Eastern Europe. I'm happy in my current job and I do pretty well (~23 usd/h). However, for quite some time now, I've been looking into Toptal.
From what I've gathered it's not that glamorous for US developers, but in my case, I could double my salary.
On the other hand, reading about them online brings lot of different views. Some say they're scam, some say they don't care, some say it's great. I've also seen lots of replies here on HN from people who just made an account to post a positive review.
So which one is it? Could anyone comment on them?
Thanks! <comment><USER2> It seems they're bad if the hourly rate you get is lower than what you expect/want. Otherwise, it seems like the sort of thing that you can look into if you're strongly interested (go through the process, see what it's like, see if there are any problems, etc), then back away from if it seems it's not working out.

What caught my attention when I heard about them was how heavy-handed they were in promoting/maintaining their brand (positive reviews magically appearing, BS/fake comments, etc). While it could just be tasteless marketing/PR and brand management, it could also be suggestive of slimy, untrustworthy, full of it, etc.</comment>


Here's what India's e-commerce war will boil down to - <AUTHOR> http://factordaily.com/alibaba-acquire-flipkart-merge-paytm/ <comment><USER2> Interesting prediction, glad that the author puts it upfront. Based on conversation with people in the loop, and latest trends, it is certainly plausible!</comment>


Why Facebook, Twitter, and 2,000 others haven't cracked social commerce yet - <AUTHOR> http://venturebeat.com/2013/12/05/5-reasons-why-facebook-twitter-and-2000-others-havent-cracked-social-commerce-yet/ There are over 2,000 startups on AngelList that are categorized as "social commerce."  That's equivalent to every Stanford MBA over the last 5 years starting a brand new social commerce company. <comment><USER2> I've argued on G+ that Google's biggest competitor online isn't Facebook but Amazon for pretty much just this reason: intentionality.

People on social network sites are largely involved ... in social networking. Discussion and conversation and sharing. Marketing is an intrusion. Facebook suffers in this regard. Sucking down ever greater amounts of personal data to this end starts getting creepier and creepier.

Google's benefited by the match of intentionality to search and capitalizing on the resulting advertising opportunity. Even if only a fraction of searches are associated with intention, Google can act on those.

Amazon cuts out the middle man. It doesn't have to advertise because it _is_ the marketplace. The company hasn't even focused on profitability, keying instead on simple cash flow. So long as it can support current operations, it's doing fine. And it is creating one of the largest marketplaces on the planet. Rather than advertising and its low conversion rates, _Amazon is the point of sale._

Disclaimers: I've used G+ for a couple of years, though I'm winding down my use due to privacy concerns. I've never trusted Facebook. I prefer shopping local to using Amazon where at all possible.</comment>


Microsoft Readies For Another Big Tech Battle - <AUTHOR> http://www.businessinsider.com/microsoft-to-rivals-take-your-open-cloud-manifesto-and-shove-it-2009-3

<comment><USER2> Why change the title from "Microsoft Readies For Another Big Tech Battle" to "Microsoft To Rivals: Take Your 'Open Cloud Manifesto' And Shove It". If you really want to get creative with titles and comments, start with Digg or Reddit. This is just plain depressing when people try to make up titles so that it sounds either interesting or religious.

<comment><USER3> Agreed. One of the things I like about this site is that most people avoid the inflammatory titles in favor of simple descriptive ones. That is not a trend I want to see fall out of favor.

</comment></comment><comment><USER4> I agree with trezor, this is the exact opposite of what I expected. MSFT's role in the actual story isn't very surprising considering the weak position they have in the Cloud industry.

No official word on who is behind the 'Open Cloud Manifesto', but I'm guessing that it will include some names like Google that will 'openwash' it, meaning to make it seem open by association rather than be open in fact.

<comment><USER5> Why do you think that Microsoft has a weak position in the cloud industry? If Microsoft really had a weak Cloud strategy, its competitors wouldn't be resorting to tricks like this.

I don't think anybody offers customers an easier self-hosted-to-cloud-hosted migration strategy than Microsoft. They are offering (or will be offering) all of their server-side products "in the cloud". Using Microsoft's stack, you develop your applications the same way, using the same libraries, and the same protocols, regardless of whether you are deploying to your own server or to Microsoft's. Most of Microsoft's competitors require you to rewrite applications to get them to work on the cloud.

Most of its competitors have very poor desktop integration, whereas Microsoft is integrating support for its cloud hosting directly into its its desktop software (including Windows and Office). For example, Windows 7 has a pretty sophisticated caching and synchronization infrastructure built into it so that desktop applications can work on documents/databases/email in the cloud with minimal latency. Microsoft Office already has built-in support for Sharepoint, which means that it has built-in support for Microsoft's cloud offerings (Office Live and Microsoft Online).

<comment><USER6> > Using Microsoft's stack, you develop your applications the same way, using > the same libraries, and the same protocols, regardless of whether you are > deploying to your own server or to Microsoft's. Most of Microsoft's > competitors require you to rewrite applications to get them to work on the > cloud.

The key phrase being "using microsoft's stack".

Open source versions of other cloud stacks are already somewhat functional. When they become usable, I can run them on my server.

<comment><USER5> "Open source versions of other cloud stacks are already somewhat functional."

That is the same with much (most) of Microsoft's stack.

<comment><USER7> I recall reading here that the project making an open version of Google's stack is being helped by google. If that is the case then it isn't quite the same.

<comment><USER6> > If that is the case then it isn't quite the same.

Why?

<comment><USER4> Because it helps adoption of their API. They will be the premium provider for their platform, and the bigger it gets, the more business they get. Plus many businesses won't consider a technology that has only one vendor, so having an open alternative opens doors.

<comment><USER6> > Because it helps adoption of their API.

So?

The original claim was that users benefitted from open alternatives. Is there any reason why users don't get those benefits if the "closed" source helps provide those alternatives?

I note that open alternatives to the Microsoft stack were seen as a good thing, yet alternatives to the Google stack are somehow second class because Google helped.

Is it fair to mention that some of the alternatives to the Microsoft stack were developed with some help from Microsoft?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Reuven Cohen just posted about an "Open Cloud Manifesto" on his blog- [http://www.elasticvapor.com/2009/03/introducing-open- cloud-m...](http://www.elasticvapor.com/2009/03/introducing-open-cloud- manifesto.html)

He provides links to a Google Groups discussion, as well as another discussion board. No real details on what the manifesto is supposed to say, though.

<comment><USER8> Reuven also posted a reply on the original Microsoft blog post (essentially the same as what he posted on his own blog.)

</comment></comment><comment><USER9> I have to agree with MS position here based on the the information that is available, which isn't much. Just that only is problematic!

Sam Johnston's approach seems to be so much simpler especially for a startup. <http://wiki.cloudcommunity.org/wiki/Main_Page>

</comment><comment><USER10> It's safe to assume Microsoft felt said manifesto would not help them leverage their many monopolies to secure another one in cloud computing.

If one could be certain of something about the manifesto, its foundations are perhaps "too interoperable" for MS to feel comfortable "collaborating" with anyone else. They have a strong preference to embrace, extend and extinguish whenever possible.

Each and every time Microsoft considered interoperability seriously was in markets they were not sure they would be able to dominate. Interoperability, for them, is usually just a plan-B.

<comment><USER5> In 2009, what does Microsoft have a monopoly on?

<comment><USER11> Desktop operating systems.

<comment><USER5> Do you really think so? Apple isn't enough of a competitor?

<comment><USER10> Not at all in the corporate market.

</comment></comment></comment></comment></comment><comment><USER12> The open cloud manifesto is full of hot air anyway so this is no surprise.

</comment><comment><USER13> _Microsoft flatly says "no" to the "manifesto" and throws down the gauntlet to its creators, demanding that the process to determine any open standard be debated openly, whether via wiki, conference, or some other method._

Even me, which works with and actually likes Microsoft's development tools and server platform, expected the complete opposite when reading that headline.

Not going to let bias or prejudice throw me off, all I'll say is that this could turn out to be interesting. I'd very much like to see the manifesto, and once published, Microsoft's reason for rejecting it.

<comment><USER14> It will probably not be as interesting as this cloud manifesto: <http://cloudappreciationsociety.org/manifesto/>

</comment></comment><comment><USER15> One of the things to realize about Microsoft is that it really is not a cohesive entity. It's like a bunch of different companies stuffed under the same name with a minimum of common shared business infrastructure. So it's entirely plausible that one group would believe in openness and transparency at the same time as another group is suing over software patents.</comment>


Lego Profit Jumps 60% on 'Star Wars,' 'Lego City' Toy Series - <AUTHOR> http://www.bloomberg.com/apps/news?pid=20601087&sid=acmDhbUFzMYA <comment><USER2> It's not just kids either. I'd love to get my hands on the 5000+ piece Millennium Falcon :)</comment>


Why Andreessen Horowitz Invested in Foursquare - <AUTHOR> http://bhorowitz.com/2010/06/29/why-andreessen-horowitz-invested-in-foursquare/ <comment><USER2> Foursquare is one of the few startups that I actively dislike (because they are responsible for much more noise than signal). At least in my mind, their brand represents some of the worst "Web 2.0"-era narcissism.

Their growth is certainly impressive, but I really wonder how useful Foursquare will be, outside tech enthusiasts living in big cities.

<comment><USER3> "Dislike" is a strong word. You may not find much use for it. But in ways, I agree. I especially hate all the "I'm here" status updates in my twitter feed. Maybe I'll change my mind when I finally get a smartphone, but until then it seems useless.

<comment><USER4> I have a smartphone now, and foursquare still has a terrible signal/noise ratio. What I wish is a service _like_ foursquare to come along that does the auto-checkin and broadcasting of location _to your selected list of private contacts_. I don't want to check in and see what people are up to, I want to be notified when people I like happen to be near me.

<comment><USER5> It still seems like a small feature to be added to a phone, rather than a complete startup company to me though.

<comment><USER4> Any android phone with location information has it -- it's called "google lattitude", but as far as I can tell it just broadcasts your location to EVERYONE.

</comment></comment></comment></comment></comment><comment><USER6> I was explaining Foursquare to my non-techie but multiple-restaurant-owning brother last week. The location based check in and social aspects made him think it was neat, maybe something he'd try.

When I explained mayorships and how 4SQ is really a universal customer loyalty rewards system, he got excited.

</comment><comment><USER7> Why do I feel that #2 is the most important thing on this list? I'd imagine that any VC firm would invest in a company that is "growing faster than Twitter did", no matter who the CEO was or what the specific market was.

From all of my experience with VCs, they are primarily driven by usage graphs that go up and to the right. Traction seems to cure all ills.

<comment><USER8> _I come from a state that raises corn and cotton and cockleburs and Democrats, and frothy eloquence neither convinces nor satisfies me. I am from Missouri. You have got to show me._

There's nothing wrong with expecting results.

</comment></comment><comment><USER9> I don't _get_ Foursquare from a users' perspective, but the possibilities of location-based marketing make it a no-brainer investment from a business standpoint. Their situation is the inverse of Twitter searching for a business model, if that makes sense. Foursquare just needs to figure out how to appeal to "normals" and they will be golden.

</comment><comment><USER10> I'm wondering why Foursquare as opposed to any of their other competitors? Other than numbers, how does a VC choose between Gowalla & Four Square (assuming they're give both as options)

</comment><comment><USER11> I think FourSquare has a unique concept. A lot of people find it attractive enough to use it regularly. Add to that a good team, and I think Andreessen Horowitz's investment is going to pay off quite well for them.</comment>


Face Masks: Much More Than You Wanted to Know - <AUTHOR> https://slatestarcodex.com/2020/03/23/face-masks-much-more-than-you-wanted-to-know/ <comment><USER2> Side notes: I was trying to figure out how I could "help" by developing an N95 respirator with some online communities. I was prepared to be humbled by what I didn't know, but holy smokes, now I realize I can't even begin to know what I don't know.

* 3d printed PLA? Deforms at autoclaving temperatures. chemical sterilization not recommended b/c there's not many good ways to "know" it's worked correctly.

* Sealing? Good luck. There are some people working on using TPU to help seal, but again, sterilization is a problem.

* Porosity? 3d printed materials can barely pass 2psi. This also creates a LOT of places for bacteria to hide.

* Filter media? DO NOT cut up a HEPA filter! They're made with micron-scale fiberglass. This keeps getting suggested, but people don't realize that HEPA filters are not made of paper.

I'm confident an open source design and process can eventually be made, but it's much harder problem than it looks. There's a lot of people are adding a lot of noise (I'm in "read-only" mode for now to cut down on the noise level) so if you're thinking of contributing, the best thing you can do is just read atm.

Producing Face Shields has some interesting and unexpected requirements (head back leakage among other things), but is a much simpler problem to solve and there are some good designs (Google Prusa 3d Face Shield)

</comment><comment><USER3> As usual, a great write up. I think one nuance that is important is:

> Does letting a single influenza virus through mean you will get infected? If > so, any reduction short of 100% is useless. I have a vague sense that this > isn't true; your immune system can fight off most viruses, and the fewer you > get, the better the chance it will win. Also, even respirators don't claim > to reduce particle load by more than 99% or so, and those work, so it can't > be that literally a single virus will get you

I was speaking with an ER doctor yesterday who said that aside from comorbities and age, the single biggest predictor of how severe a case may be is the viral load exposure. The reasons that N95 respirators are so important in a hospital setting is that when a dr or nurse are continuously exposed to the virus, those deltas in performance might mean they pstill get sick, but it's mild and back to work in two weeks vs ending up in the hospital for a month.

<comment><USER4> This is exactly the reason the anti-mask people in the US or so frustrating. Yes, you might still get sick but the initial viral load is likely to be greatly reduced and the speed and intensity at which you get sick is likely to be milder.

</comment></comment><comment><USER5> I'm trying to decide if I should wear the mask or not, but whatever I read the only question is if a mask can protect me from getting the virus. But the question that interests me is if the mask protects people around me if I have the virus (and I don't have the symptoms yet). If it does, then everybody should wear a mask.

<comment><USER6> > But the question that interests me is if the mask protects people around me > if I have the virus (and I don't have the symptoms yet).

Possibly, for the same reason you should cough or sneeze into your elbow. It reduces the number of droplets you spread into and around the environment around you, and before they aerosolize.

</comment></comment><comment><USER7> Once testing is widely available, I hope to see wearing masks in public as a precondition for ending lock-downs/quarantines and returning to normal life. This might be something most state governments of all stripes could sign onto.

<comment><USER8> Why? And for how long?

As long as the curve has been "flattened" and the health care system is under capacity, what are you hoping to achieve?

<comment><USER9> "As long as the health care system is under capacity" is about a week or so at best, in much of the U.S., and not much longer (or already past) in many other places. And it's going to stay that way for awhile - outside China and Korea, the best news we have so far is the rate of new cases in some places has stopped increasing _exponentially._

</comment></comment></comment><comment><USER10> Old-school cotton masks help a lot too. We don't know exactly how much, but they do. They reduce viral loads by at least 30% and more likely by something like 70%.

Cover your mouths.

<comment><USER8> Citation please?

In response to a long article full of links to scientific papers and nuanced analysis, saying a blanket statement like this isn't helpful at all unless it's backed up.

<comment><USER11> [https://smartairfilters.com/en/blog/best-materials-make- diy-...](https://smartairfilters.com/en/blog/best-materials-make-diy-face- mask-virus/)

not direct citation, but relevant</comment></comment></comment>