China's role in the U.S. fentanyl epidemic - <AUTHOR> https://news.yahoo.com/chinas-role-in-the-us-fentanyl-epidemic-152338423.html <comment><USER2> What I think is odd is that it is so outrageous and conspiratorial sounding to even consider malicious intent on the part of the Chinese government.

I'm not saying I have any idea what the real impactful decisions that fuel this problem even are, much less who is making them, triple much less what their intention is.

I'm not sure it is clear what is really fueling the opioid epidemic, many theories of causation are plausible.

But it seems hopelessly naive to discard outright the _possibility_ that aggressive intention by the Chinese Government is a factor here.

Countries have done much, much, worse to each other (and their own people) in pursuit of various strategic objectives throughout all of recorded history. Why should we flat out assume that has somehow fundamentally changed?

<comment><USER3> Possibly because of a lack of obvious advantage this would bring to China. I can not fathom what they could hope to gain by planning this.

<comment><USER4> You should read about the Opium Wars. Britain literally went to war with China so they could sell opium to the Chinese. Pretty clear parallels here.

<comment><USER5> The parallel would be US = Britain and China = China. US is running a trade deficit with china like britain was running a trade deficit with china in the 1800s.

If the US invaded china and forced china to buy opium to offset the trade imbalance, then the parallel would apply.

I don't remember china invading the US. And china isn't forcing drugs on the US, no more than mexico or south america is forcing drugs on the US. There is demand for drugs in the US. That is the problem.

And the slow but recent drug legalization around the country and the glamorization of drugs in the media isn't going to help.

</comment></comment></comment></comment><comment><USER6> Switzerland had a open heroin epidemic around 30 years ago.

[https://www.youtube.com/watch?v=3UYmaalotK0](https://www.youtube.com/watch?v=3UYmaalotK0)

Repression only made it worse and I can only imagine how much worse it would have been with the possibility that every shot may have something far more potent.

Maybe the important bit is also how it was resolved:

[https://www.thelocal.ch/20120531/3427](https://www.thelocal.ch/20120531/3427)

In short, save injection sites, controlled diaphin or other opioid replacement therapies made the life of addicts livable and reduced the harm that happened.

</comment><comment><USER7> I recommend this podcast if your interested in learning more:

"Puzzled by rising drug deaths at raves in the United States, author and investigative journalist Ben Westhoff set out to find answers. A Google search for "Buy fentanyl in China" took him down a rabbit hole that led to a face-to- face meeting with the CEO of a company selling fentanyl on Skype "all day long" and a drug lab in Shanghai. Ben tells Jordan the remarkable story."

[https://supchina.com/podcast/chasing-the-dragon-fentanyl- chi...](https://supchina.com/podcast/chasing-the-dragon-fentanyl-china-and- the-opioid-crisis/)

</comment><comment><USER8> "Tracing the US opioid crisis to its roots"

[https://www.nature.com/articles/d41586-019-02686-2](https://www.nature.com/articles/d41586-019-02686-2)

<comment><USER9> from you link, the key stand out paragraph for me was...

> Because many doctors are in private practice, they can benefit financially > by increasing the volume of patients that they see, as well as by ensuring > patient satisfaction, which can incentivize the overprescription of pain > medication.

</comment></comment><comment><USER10> Blaming China for our failed drug war and idiotic drug policies is like blaming gun companies for WWII. The only way to help opioid addicts is to help them improve their lives while providing low cost, safe opioids to them until they are ready to quit. If doctors in the US could prescribe appropriate opioids for addiction, if we had safe use sites, and if we helped people find jobs, community, and purpose, we wouldn't have this epidemic. Until we're ready to accept that and while this idiotic drug war continues, thinking that drugs can be stopped despite over a hundred years of evidence to the contrary, people will continue to die in masses. And the only people that deserve the blame are the police, DEA, and lawmakers who are murdering addicts in their crusade against something they are too stupid to understand. The drug war is a crime against humanity, one that will likely go unpunished like so many others.

<comment><USER11> I strongly agree with everything you just said, but is there possibly some benefit in also trying to control the huge flow of fentanyl from China? That's really all TFA is saying.

<comment><USER12> I think this is literally impossible because of costs to produce / distribute fentanyl compared to opioids. There will always be people who are skint enough to buy the cheapest thing they can find and there will always be bad apples greedy enough to stretch their produce with Fentanyl.

Then there are those that mean well and spike their produce successfully for a few runs, ... forgetting that it takes only 1 mistake and many will be dead as a result.

</comment></comment></comment><comment><USER13> What I find interesting is that there is so little discussion of the demand for fentanyl. I know it's convenient to blame doctors and drug companies, but why is there such a high demand for fentanyl as a drug of abuse/intoxication in the USA compared to other countries?

By the way, I have fentanyl patch prescriptions, and have done for years, due to medical issues. I use maybe 7-10 doses per year, with no real urge to take more. I can see how it can be appealing to people, but there has to be something in US society that makes fentanyl and other synthetic opioids so enticing.

</comment><comment><USER14> The author left out the necessary first step, which is the local government preventing Americans from straightforwardly buying opiates _in stores_ , where incentives are aligned for utility and purity. The grey/black market only exists as a direct result of criminalization, rather than treating addiction as a personal health problem.

<comment><USER15> Hi, can I please have a dose of fentanyl?

Sure, how will you be paying for it sir? [https://www.drugabuse.gov/drugs- abuse/fentanyl](https://www.drugabuse.gov/drugs-abuse/fentanyl)

</comment></comment><comment><USER16> Yep. China makes all that but they dont have an opioid crisis. USA doesn't make the stuff yet has an opioid crisis. Naturally we don't ask why the USA cannot police opioid use like the chinese...

Why doesnt say, singapore have an opiod crisis? China won't export to singapore?

Hmmmmmmmm

</comment><comment><USER17> A Friend got a swathe of opioids for a cut in her thumb (in a US hospital), "Why?" she asked, turns out the hospital is sponsored by the producers. Buy hey! Nothing to see here! It's them Chiners!!

</comment><comment><USER18> The ones truly at fault are the doctors. They follow "procedure", which says that a patient under pain is treated with opiates. And so, to avoid any mal practice, they prescribe. And the patient has been told that doctors are the smartest, most prestigious individuals in our society. What's not to trust? What do we do when societal structures built upon reputation and legitimacy fall victim to profit taking and legal threats? There's no failure mechanism when a reputed institution fails from the inside.

<comment><USER19> > which says that a patient under pain is treated with opiates

Do you have a better solution? For some people the pain can be unbearable.

<comment><USER20> _For some_ opiates are might very well be the right tool. Just as you said.

There are some questions to which I'm in no position to give an answer:

\- is a little temporary pain really problem?

\- are there less invasive measures?

\- what preventative measures do we have?

\- are opiates just an easy way to cover up symptoms that could/should be treated properly?

<comment><USER19> A "little" temporary pain is not a problem. A lot of temporary pain is a problem though, and it is even worse when doctors do not believe the patient and think that the patient is just looking for drugs, or when the doctors do not understand how big the pain is (after all, only the person who suffers can judge it).

This is why I believe it should be up to the patient to select whether to take opiates.

</comment></comment></comment></comment><comment><USER21> See also "Opium Wars".

[https://en.wikipedia.org/wiki/Opium_Wars](https://en.wikipedia.org/wiki/Opium_Wars)

Don't do drugs.

<comment><USER12> linking this to the Opium Wars might lead people to make incorrect links between cause and effect. This isn't some pay-back for the crimes the East- Indian Company and the West committed against China back then.

It's simply a few bad apples in an illegal market responding to the demand of the West and seriously why would anyone in China care as long as they don't sell this in China. It is bad-apples who want to get rich quickly but from a suppliers perspective it's short sighted because a dead addict isn't going to come back for more.

The real criminals to blame here are those that get people hooked on pharmaceuticals and then stop giving them the prescription for what they got them hooked on. No wonder they move from pain killers to heroin (or its substitutes).

edit: I highly recommend the excellent _" Louis Theroux: Dark States"_ (episode Heroin Town). He gives a very empathic non-judgemental look into the tragedy of addiction in the US.

<comment><USER21> > linking this to the Opium Wars smells like a conspiracy theoroy. This isn't > some pay-back for the crimes the East-Indian Company and the West committed > against China back then.

Sorry! I just wanted to point out some of the historical context. I don't have a particular fish to fry here.

> why would anyone in China care as long as they don't sell this in China.

That's a bit uncharitable, eh? There are a billion and a half people people in China, they can't _all_ be moral cretins, can they?

<comment><USER12> not suggesting nor calling anyone a moral cretin. My point is that if you don't have an extradition agreement in place then what are you gonna do? (-> e.g. "why would anyone in China care").

edit: @carapace fwiw, I'd never thought so, or meant to accuse you of subscribing to conspiracy theories. what I meant here is that it could be construed as an incorrect cause->effect relation between opium wars and the crimes of US BigPharma. If you follow what is happening right now with the US in Munich at the security conference, then China isn't the evil that the US paints them as. China is a threat to the West for sure but the real terrorist really is the US (who are preparing for war): [https://www.youtube.com/watch?v=YDRoY2PQsGg](https://www.youtube.com/watch?v=YDRoY2PQsGg) -> When I posted my reply my emotions were running a bit high on the hypocrisy that the US is pushing again in Munich. So I want to apologize for that. I also edited my above comment.

<comment><USER21> > not suggesting nor calling anyone a moral cretin. My point is that if you > don't have an extradition agreement in place then what are you gonna do? (-> > e.g. "why would anyone in China care").

Cheers, that makes more sense. Sorry.

> I'd never thought so, or meant to accuse you of subscribing to conspiracy > theories.

Oh but I _do._

Robert Anton Wilson pointed out that in the last century, of regime changes, more than half came about as the result of a coup, conspiracy.

Or, as Colonel Hunter Gathers said so memorably, "The moment God crapped out the third cave man a conspiracy was hatched against one of them."

The ability to hatch conspiracy is the evolutionary driver of intelligence. What differentiates us from the animals is not language, but rather the ability to lie.

Anyhoo, that's a big ol' tangent. You didn't offend me, FWIW. We're cool.

</comment></comment></comment></comment></comment><comment><USER22> Um, American drug companies created the opioid epidemic, and then fueled it with aggressive marketing, kickbacks, and bribery.

Fentanyl is a relatively recent addition to a crisis those companies started in the early 90s.

<comment><USER23> Could someone explain what is incorrect about parent's statement for it to deserve downvotes? It seems to be in line with the prevailing narrative of the past decade or so.

<comment><USER11> Maybe starting out a comment with "um..." as though everyone else is stupid, and then following up by merely restating the prevailing narrative, which has little to do with the assertions made in the article. Maybe that's a reason for some of the disagreement.</comment></comment></comment>


TANK: animated short film - <AUTHOR> https://prolost.com/blog/tank <comment><AUTHOR> Watch the short first, then watch the making of, then watch the short again with much greater appreciation.

At the end of the making of, he mentions an article that itself was previously submitted to and discussed on HN:

[https://news.ycombinator.com/item?id=13908458](https://news.ycombinator.com/item?id=13908458)</comment>


Class Hierarchies? Don't Do That - <AUTHOR> http://raganwald.com/2014/03/31/class-hierarchies-dont-do-that.html <comment><USER3> _" the real world doesn't work that way. It really doesn't work that way. In zoology, for example, we have penguins, birds that swim. And the bat, a mammal that flies. And monotremes like the platypus, an animal that lays eggs but nurses its young with milk."_

Former biologist here. Actually...most living things _do_ work that way. A human ISA primate. Genetically. Functionally.

If you merely focus on _outward behavior_ , you get to the same place that early biologists got to with what was called "morphological classification" \-- you find the weird examples of convergent evolution (e.g. _" OMG egg- laying mammal!"_), and you're tempted to throw out the whole classification system, even though it _mostly_ works, and the errors are merely distracting from the inherent truth of the idea (that we're all related by genetic phylogeny; we _literally share implementation_ ).

Anyway, programmers, learn from biology: when you see these kinds of errors it probably means that you're classifying things incorrectly, not that you should stop classifying altogether.

<comment><USER4> Thanks for the input - the more cross disciplinary knowledge flow the better. I like your take away in particular. The author is basically saying 'All this OOP stuff that most of the industry has been doing for 20 years? All wrong! Do it my way.' Hearing that biology still uses directed non-cyclic graphs for classification (eg, single inheritance) shows just how powerful single inheritance really is and that we maybe shouldn't be so fast in throwing it away because it doesn't match something.

I think sticking to the 'age old wisdom' of using direct inheritance for IS-A relationships and composition for HAS-A is still the right way to go. It's been tested, it works, and using HAS-A for everything makes for less understandable code imo. Often you can fix an IS-A by simply refactoring your graph with a better understanding of the problem space - as it turns out biologists have done as well.

<comment><USER5> In my personal experience, I've never found a true IS-A relationship in my code. I've found lots of _interfaces_ , though.

A lot of the time, you'll think you're defining a superclass when you start writing things like "Square IS-A Shape; Rectangle IS-A Shape". But Shape will turn out to not define any common behavior, just a category you want to restrict your inputs and outputs to; and you'll want to be able to assert that anything is, in addition to whatever else it is, a Shape. So shape is an interface.

A lot of the time, you'll think you're defining a superclass when you start writing things like "User IS-A Person; ProjectOwner IS-A User". But it'll turn out that you want to keep People around even when they stop being Users, and to keep Users around even when they stop being ProjectOwners. So you'll rearrange things and find that you're now asserting "User IS-A Role; ProjectOwner IS-A Role; Person HAS-MANY Roles." And Role turns out to be, again, an interface.

The only example I can think of that _does_ fit single-inheritance is when modelling objects that directly express a genealogy. For example, GithubForkOfProjectA IS-A ProjectA, or Ubuntu IS-A Debian. But these aren't typically things you'd express as _types_ ; they're just _instances_ (of, respectively, GithubProject and LinuxDistribution.) Each instance HAS-A clonal-parent-instance.

I guess there's one _possibly_ -practical use of inheritance which I've nearly implemented myself: if you force your database schema migrations to always follow the Open-Closed Principle, and you want to migrate the rows of a table as you encounter them to avoid taking the DB offline, then you _could_ have two separate models for a Foo table, FooV2 and FooV3, where "FooV3 IS-A FooV2". Each row has a version column, and is materialized as the model corresponding to that version. Your code that expected FooV2s would then be satisfied if it was passed a FooV3.

Does anyone actually do this, though? I don't just mean "row-by-row migrations", I mean the "with two models, one version inheriting from the other" part. And, if so, what do you do when you make a change to a model that _doesn 't_ obey the Open-Closed Principle: where FooV3s break the FooV2 contract?

<comment><USER6> The one case where languages without traditional OO inheritance are painful is where you want to do "like this other thing, except for this one particular thing that it does differently". And sure, maybe that's always bad design - but it comes up a lot in real-world business requirements. For all the people saying "you should use alternatives to traditional OO" I've never seen an actual example of how to do this better - you can patch those instances at runtime (urgh), you can create an object that implements the same interface and delegates to an instance of the base type (much less readable in every language I've seen, and effectively reimplementing inheritance without the syntactic sugar).

I think the right solution is simply to have firmer constraints about the relationships between parent and child classes - just like decoupling a class's implementation from its interface, it should be possible to separate out the interface it exposes to child classes as well. The one library/framework I've seen that does this really effectively is Wicket - <USER2> makes extensive use of final classes, final methods, and access modifiers to ensure that when you need to extend Wicket classes you can do so via a well- defined interface that won't break when you upgrade your Wicket dependency. It works astonishingly well.

<comment><USER5> You're correct in that special-case "like this other thing, except for this one particular thing that it does differently" objects happen all the time due to business rules.

But the Decorator pattern is _not_ "inheritance without the syntactic sugar." Decorated objects, unlike subclass instances, are allowed to break the contract of the object they decorate: they don't have to claim to obey any of its interfaces, they can hide its methods, they can answer with arbitrarily different types to the same messages, etc.

If a language made defining decorators simple, I think it'd remove a lot of what people think of as the use-case for inheritance. (I mean, you aren't _supposed_ to use inheritance for Decorator-pattern use-cases--it will likely break further and further as you try--but people will keep trying as long as the first steps are so much easier than the alternative.)

<comment><USER6> > If a language made defining decorators simple, I think it'd remove a lot of > what people think of as the use-case for inheritance. (I mean, you aren't > supposed to use inheritance for Decorator-pattern use-cases--it will likely > break further and further as you try--but people will keep trying as long as > the first steps are so much easier than the alternative.)

I actually agree with this, and I'd be interested to hear of language efforts in that direction. But until there's this easy way to do decorators, just telling people "don't use inheritance" isn't going to work.

</comment></comment></comment></comment></comment></comment><comment><USER7> Okay, having read the article, I think it goes too far.

Inheritance hierarchies have their issues, and raganwald touches on them, but there's a strawman argument here.

(Incidentally, raganwald, I've noticed this about all your OO articles. You seem to have a bias against class-based design. It's causing your essays to be less brilliant than they could be.)

Fundamentally, you can think of inheritance as a special case of composition. It's _composition_ combined with _automatic delegation_.

In other words, if you have A with method foo() and B with method bar(), "A extends B" is equivalent [1] to "A encapsulates an instance of B and exposes 'function bar() { return this._b.bar(); }'."

This is _very useful_ when you want polymorphism. Writing those delegators is a pain in the butt.

More importantly, it tells us how to use inheritance safely. Only use inheritance when 1) you want to automatically expose all superclass methods, and 2) don't access superclass variables.

Now, JavaScript does have the specific problem that you can accidentally overwrite your superclass's variables, and that's worth talking about. But I think that saying "inheritance is bad" goes too far. The article would be stronger if talked about _when inheritance is genuinely useful_ , _the problems it causes_ , and _how to avoid them_.

 _Edit:_ In particular, I want to see more about polymorphism. Polymorphism is OOP's secret superpower. _Edit 2:_ I'm not saying polymorphism requires inheritance.

[1] Not quite equivalent.

<comment><USER8> I think that part of the problem is that while JavaScript can _do_ OO somewhat, it is not fundamentally an OO language, and if OO is the first tool that you reach for, you are likely doing JavsScript poorly.

<comment><USER9> Javascript _is_ fundamentally an object-oriented language, it's just prototype-based rather than class-based.

<comment><USER8> It seems more like a functional language to me, but YMMV: [http://stackoverflow.com/a/501053/5599](http://stackoverflow.com/a/501053/5599)

<comment><USER10> You seem to be under the impression that those are somehow mutually exclusive.

<comment><USER8> I'm sorry if you though so. I am not under that impression.

However as mentioned elsewhere ( [https://news.ycombinator.com/item?id=7500280](https://news.ycombinator.com/item?id=7500280) ) if most of what you do to organise your code involves passing functions to functions and very little of it involves creating class hierarchies or prototype chains, it's a fair assessment that the language that you are using is more functional than OO.

The language that you are using may be a subset of the whole language, but with JavaScript that's given - you have to find the good parts or go mad trying. I was wrong about JavaScript as a whole, but maybe less so about JavaScript as it is successfully used.

</comment></comment></comment></comment></comment></comment><comment><USER11> Inheritance is easily overused, but that doesn't mean that we should just avoid it altogether.

The problem IMO is that we are stuck in a view that inheritance is really about ontology, when what we really mean, and want, is code reuse. It's very hard to make a 5 level deep ontology not break down. This is why we have this whole 'prefer composition over inheritance' business.

But while we are stuck with that kind of mindset in Java (at least pre java 8), we miss the capability of using inheritance as a way of adding mixins. There is much power in using mixins as a way to clarify composition, while we still keep the inheritance tree very shallow.

That's one thing we get with judicious use of the Scala cake pattern, which you could easily reproduce in javascript: Composition without really having to write a bunch of useless boilerplate. There's a nice talk out there about it. Cake Pattern: The Bakery from the Black Lagoon.

The trick, as with most other programming techniques, is to use it carefully.

<comment><USER12> "what we really mean, and want, is code reuse"

I'm not sure if you meant it this way, so I'll underscore this point. Code reuse is truly the worst "reason" to use inheritance, and in fact an anti- pattern.

Composition is the only proper way to reuse code because composition is explicitly stating you are using the composed code.

<comment><USER13> You're taking it too far. One should prefer delegation/composition in most cases, but if you're trying to direct users to a restricted reuse model (inheritance), then it works fine and is often a much clearer approach than "Joe's custom delegation model".

There are plenty of examples of this in practice - someone pointed out NeXT/Apple's UIKit for example elsewhere in this thread (which also uses composition where appropriate). The Java collections hierarchy is also a good one (LinkedHashSet < HashSet < AbstractSet).

</comment></comment></comment><comment><USER14> Good article, but I think the real message isn't to not use inheritance, but to use with great care.

Inheritance gives you a great characteristic -- isa relationships. And this is something you don't get with composition.

That said, the fragility with poorly constructed base classes is real. But a succinct base class can be very valuable and useful, and not that brittle. Just don't stuff cruft in it that is of questionable value. Ask yourself what's the least you can put in the base class and still provide value.

And this is where interfaces are also useful. You can get the isa relationship w/o much of the brittleness as there is no internal state associated with the interface. But you are still creating a hierarchy (just not of classes, but of interfaces).

It's a useful article, especially for those new to the idea. But the takeaway should be to use care. Not to avoid at all costs.

<comment><USER15> [edited because apparently I can't read; kenjackson did mention interfaces]

I think it's still a bad idea - as you note, isa is available without necessarily having inheritance; we know inheritance is dangerous, so why include that?

In languages like C++, C# and Java, it has long been expert advice to avoid inheritance where possible, and use interfaces. But the language and language culture is leading everyone astray. Defining interfaces is usually harder or stranger-looking, and is taught as an adjunct to inheritance.

Other languages get this more right. Haskell has what it calls typeclasses, but they are more similar to interfaces in the aforementioned languages.

We seem to be making _exactly_ the same mistake in the ECMAScript standard, except it's even worse; you can't define an interface even if you wanted to.

<comment><USER16> What would "defining an interface" even mean in a non-type checked language? I'd say: ECMAScript already has better interface support than Java has because it supports implicit interfaces. In Java two classes can only be interface- compatible if they have a shared dependency/are at least indirectly coupled. In a language with duck typing and without static typing interfaces are present implicitly.

<comment><USER15> You're correct that adding interfaces to JavaScript would also require adding optional type declarations. But there are lots of languages based on JavaScript, or which compile to JavaScript, which offer optional type declarations. It seems to me they could have gone down this path.

I don't agree that it's better to have an "interface" which exists purely in the head of every programmer working on the code. Languages can be doing more for us, and it doesn't have to be the kind of verbosity that Java offers.

<comment><USER16> Maybe that was a misunderstanding: I didn't mean to say that interfaces should exist purely in the head of the programmer. I did say that implicit interfaces/protocols (Go, Objective-C) are better than interfaces that need shared dependencies (Java/pure virtuals in C++). If I had to order it I'd say: duck typing better than explicit interfaces; implicit interfaces that are backed by static type checks "better than" duck typing. The "better than" in quotes for the latter because it really is more about how much static analysis the language supports and it's more a matter of opinion.

But I'm relatively convinced that interfaces/protocols that require coupling of implementations are clearly inferior to the ones that are implicit.

</comment></comment></comment></comment></comment><comment><USER17> There are some contradictions here. For example the author the following statement about encapsulation violations being permitted, but not followed as best practice:

"JavaScript does not enforce private state, but it's easy to write well- encapsulated programs: simply avoid having one object directly manipulate another object's properties. Forty years after Smalltalk was invented, this is a well-understood principle."

However, the author doesn't seem to really understand this as he makes the case that access to private state and behavior of a "superclass" violates encapsulation:

"In JavaScript (and other languages in the same family), classes and subclasses share access to the object's private properties. It is not possible to change an implementation detail for Account without carefully checking every single subclass and the code depending on those subclasses to see if our internal, "private" change will break them."

Well, yes they do allow access, but that doesn't mean you have to use it! This is considered bad practice when extending any class in other languages that I'm familiar with (C++, Ruby). Please take some of your own advice.

I do agree that hierarchies do not fit the real world as well the contrived examples from my first OOP classes and they should be used with extreme caution. Let's not throw out the baby with the bath water, however.

</comment><comment><USER18> I used to find these types of articles useful. But now I see them more as dogma. Great engineers don't struggle with things like JavaScript inheritance because they understand best practices and trade offs. So in general, I find it more useful to read about best practices and trade offs than "xyz considered harmful" articles that don't present viable alternatives to xyz.

That said whenever I see something on raganwald.com I'll still read it :)

<comment><USER19> [https://yourlogicalfallacyis.com/middle- ground](https://yourlogicalfallacyis.com/middle-ground)

The alternative he presented is not to share private state between class and superclass. This really isn't a "know the right tool for the right situation" kind of thing -- it's almost never a good thing.

You could accomplish this alternative, among other ways, by:

1\. Using composition and delegation. 2\. Using mixins, if your language supports them. 3\. Using inheritance, but depending only upon your superclass's public interface.

</comment></comment><comment><USER9> The substance of the article is spot on, but I have to take issue with the terminology it uses. The problem he's talking about isn't classes, it's inheritance.

This is an important distinction. Javascript doesn't have classes, but it _does have inheritance_. The problems raganwald points out with the Account example come not from the organization of the code into pseudo-classes, but from the fact that it uses Javascript's inheritance mechanism.

It would be perfectly possible to write a version of the example that exhibited the "fragile prototype problem," and conversely, one can easily write a version in Smalltalk that uses composition instead of inheritance and thus has no fragile base classes.

</comment><comment><USER20> It's just as true in other languages. More often than not, programmers thinking about code reuse attempt to solve it via inheritance, which is almost always the wrong answer. With some persistence, you can end up with a nice four or five level deep inheritance tree with 10 methods randomly overriden at various levels in the tree. Good luck figuring out how the damn thing actually works if you didn't write it.

<comment><USER21> Okay, but that kind of polymorphism is actually a replacement for conditional logic, e.g. switch on type antipattern.

People hate conditionals. People hate polymorphism.

Everybody is wrong about everything pretty much all of the time, it appears.

<comment><USER22> In JavaScript, like other duck typed languages, you have dynamic dispatch without inheritance.

For example:

        var objA = {doIt:function(){console.log('hello from a')}};
        var objB = {doIt:function(){console.log('hello from b')}};

        var doItDynamically = function(doitObj) {
            doitObj.doIt();
        };

        doItDynamically(objA);
        doItDynamically(objB);

a and b do not share a common class (since classes do not exist in JavaScript), but they implement the same interface. For this reason, they can be used polymorphically, as if they shared a common base class or interface in Java or C++.

</comment></comment></comment><comment><USER23> We want to use classes because we want to want to be able to invoke an operation and have the exact behavior determined by the type of the object or objects on which the operation was invoked.

Common Lisp philosophy of classes and OO fits the thicketness of the real world better. Generic functions, multimethods, mixings etc. Just embracing the notion that classes and encapsulation might be orthogonal issue opens up the way to use class system better ways.

</comment><comment><USER22> I am bit concerned that the standard committee is going to make the language worse while trying to fix it.

Yes it is inconvenient to do traditional OO programming with JavaScript, but I'm not convinced that is a bad thing. Encouraging subclassing, as pointed out by the author, could actually be detrimental.

<comment><USER24>
        I am bit concerned that the standard committee is going to make the language worse while trying to fix it.

AFAIK the goal is write what you mean and not "fake stuffs because the language lacks structure".

Dont want to use any ES6 new syntax, dont use it. And yes , the committee SHOULD meet developpers demands as much as possible. Javascript has no clear paradigm,everything should be on the table.

<comment><USER22> To clarify, what concerns me is that by adding syntax that is similar to Java, developers coming from other languages (namely Java), won't take the time to understand the differences between the two languages and continue to write applications as they would in Java.

Everyone has their biases, and my bias would be to embrace the dynamic and functional aspects of the languages that separate it from Java, rather than creating new syntax that pastes over the fact that the language is fundamentally different.

<comment><USER25> I'm a Java programmer and I think classes in JS would be awful. Tacking on the ES6 behaviour will not make JS a sane OO language, it'll make JS a bunch of new, inconsistent behaviours tacked onto the old, inconsistent behaviours.

FWIW I'm with you: I think that treating JS as a functional language is a cleaner fit that crowbar-ing OOP into it.

<comment> V-2 You don't like TypeScript?

<comment><USER25> I think it was a valid approach to the problem and I salute MS for it, but no - I don't like it. We considered it at work and felt we were fighting JS's natural tendencies too much.

Our decision is to deal with JS on it's own terms. Clojurescript would be appealing if it didn't involve an AOT compiler (and one that's not trivial to set up in Windows)

</comment></comment></comment></comment></comment></comment><comment><USER26> Class hierarchies are easily fragile, easily do not model things correctly over time.

The cruft, the lack of DRY as the mapping between what is being modeled and what is represented in the code -- accumulates with class hierarchies for sure.

But the idea of inheritance and tree structures _has_ been around and strong for the past 50 years -- not because people are inherently lazy -- but because it models something very primitive about programming: the evolutionary nature of development and thinking.

This is extremely non-mathematical, but extremely non-trivial.

Tree structures (and by extension 'hierarchies') are perhaps the most fundamental way to organize data. There is nothing more sophisticated than a tree search -- it is the basis of all exponential / efficient access times and all knowledge and organization of memory. It's why evolution proceeds in tree structures. We organize data in our mind in tree structures. Life over millennia organizes itself in tree structures.

I'm sad to report that the world will not quickly become clear and abstract and orthogonal a la Haskell or other pure languages. Knowledge, life, everything proceeds via evolution, not something a priori. The sooner one _really_ accepts that, the sooner one has new ways to interface with this reality more practically and effectively.

People sometimes make the point of use the right tool for the job - as a reason for still using OOP, etc. I'd not say that -- but that the right tool for the job where the _job_ is an evolving code base is actually something object-oriented with inheritance. Except where the domain is very precise and known ahead of time. Otherwise, the manner in which it models evolution is actually quite useful (despite the fragility of inheritance and the quick ability to spin out of any orthogonal clarity).

People who program purely in Clojure or Haskell put the burden of this evolution in their own development as a programmer (there is no extension, there is just clarity and then rewrite). That's ok. People who use Java or whatever in the enterprise because it's easier for other people to get on board with it -- put the burden in the code. But the cost of modeling a problem that evolves goes somewhere.

<comment><USER27> Are you saying that `nature uses is-a hierarchies, hence it's good for source too.' or that `source code that models real world concepts so it should follow the same concepts.'?

<comment><USER26> Good question, thanks. I think I was conflating both -- but I think both apply.

The benefit of is-a hierarchies -- perhaps the only big benefit (to be weighed against all the other alternatives available) -- is that it solves for making the next 'adaptation' as simple as possible. It optimizes for the very next extension step. It is slightly less conceptually complex to extend an object than to composite a new feature.

It does that at the cost of complexity and brittleness. But in both the real world and and in source maintenance this is occasionally useful.

Let's say I'm a startup practicing lean and experimentation as much as possible. What I want is a framework that allows me to tweak things with as few steps as possible. What I don't want is to refactor every time I want to do an experiment.

Anyway, code I think generally should model our understanding of the problem space and the real world concepts in play. Extension is not a bad way to begin modeling that understanding.. Because growing the first steps (even though they will clutter because there is nothing encouraging orthogonality in OOP besides one's own sense of cleanliness) is often good for the growth of our understanding.

</comment></comment></comment><comment><USER28> Huge fan of this article. Makes some really great points! Wish I could share and vote it up a thousand times. :)

I have been writing about exactly this topic, of why classes don't make sense (specifically for JS), in my second title of the "You Don't Know JS" book series, "this & Object Prototypes".

In particular, Chapter 6 makes the case for an alternate pattern to class- orientation design, which I call OLOO (objects-linked-to-other-objects) style code. OLOO implements the "behavior delegation" design pattern, and embraces simply peer objects linked together, instead of the awkwardness of parent- child abstract class semantics.

[https://github.com/getify/You-Dont-Know- JS/blob/master/this%...](https://github.com/getify/You-Dont-Know- JS/blob/master/this%20%26%20object%20prototypes/ch6.md)

<comment><USER29> Kyle, the figures (fig4.png, fig5.png) are missing from that page. Other pages too. I'm one of your kickstarter contributors, but I was unable to read & review some of the chapters because significant parts of the text refer to missing diagrams.

<comment><USER28> They're coming. It's an artifact of working with a book publisher and the art department and all that. Sorry for the confusion.

<comment><USER29> A rough, hand drawn sketch scanned to gif or png until the official artwork is ready would be 100x better than a broken link.

<comment><USER28> OK, draft figures posted now.

[https://github.com/getify/You-Dont-Know- JS/tree/master/this%...](https://github.com/getify/You-Dont-Know- JS/tree/master/this%20%26%20object%20prototypes)

</comment></comment></comment></comment></comment><comment> V-2 "Only, the real world doesn't work that way. It really doesn't work that way. In morphology, for example, we have penguins, birds that swim. And the bat, a mammal that flies."

Yes but we have Single Responsibility Principle and while an animal is one object in physical world, it doesn't mean it should be a single object in OOP. Start breaking it down...

public interface BodyType {}

public class TwoArmsTwoLegs implements BodyType {}

public class FourLegs implements BodyType {}

public interface Locomotion<B extends BodyType> { void walk(B body); }

public class BipedWalk implements Locomotion<TwoArmsTwoLegs> { public void walk(TwoArmsTwoLegs body) {} }

public class Slither implements Locomotion<NoLimbs> { public void walk(NoLimbs body) {} }

public class Animal { BodyType body; Locomotion locomotion; }

Animal human = new Animal(new TwoArmsTwoLegs(), new BipedWalk());

(Code sample from an article in Software Development Journal by Łukasz Baran)

</comment><comment><USER30> tl;dr: Superclasses make your code brittle. [https://en.wikipedia.org/wiki/Fragile_base_class](https://en.wikipedia.org/wiki/Fragile_base_class)

How many people still try to fit their software design into the class hierarchy model? I've been on the composition-not-inheritance side for so long I can't do "traditional OO" justice, but I'd love to hear the counter- arguments in case I'm wrong.

<comment><USER7> No, you're right. "Favor composition over inheritance" has been the go-to OOP design advice for years.

The distinguishing feature of OO is _modeling concepts_ by _encapsulating state and behavior_. For some reason, introductions tend to focus on complex inheritance structures instead. I think that's really unfortunate because it sends entirely the wrong message about OOP.

That said, I do occasionally use inheritance for polymorphism and limited code reuse (such as [1]), but I keep it limited in scope, and I don't think I've ever used a multi-level inheritance hierarchy.

[1] In my Let's Play TDD screencast series, I use inheritance when modeling a "Dollars" value object. There's a Dollars base class and then various specializations: ValidDollars, InvalidDollars, and UserEnteredDollars.

Source code: [https://github.com/jamesshore/lets_play_tdd/tree/master/src/...](https://github.com/jamesshore/lets_play_tdd/tree/master/src/com/jamesshore/finances/values)

The screencast: [http://www.jamesshore.com/Blog/Lets- Play/](http://www.jamesshore.com/Blog/Lets-Play/)

</comment></comment><comment><USER31> Ever since I've started writing Objective-C, a lot of Javascript's glaring issues have started to melt away. Yes, JS doesn't have an understanding of protocol, but that's just a matter of implementing convention and being disciplined. JS is remarkable in that it is so malleable that one can use myriad patterns with it.

I've found that the delegate pattern, for instance, can be incredibly powerful when used in conjunction with JS, especially when it comes to extending classes functionality that may not be inherent to its topology (think class Ant, to describe an Ant, and class FlyingAnimal -- wings, etc. --, to describe a queen ant).

</comment><comment><USER32> Although I'm very, very sympathetic to the idea that class hierarchies often cause more pain than they're worth, using JS to make that point is a bad idea.

In most actual OO languages, there _is_ a clearly defined interface between a base class and it's inheritors: eg in c# you have protected (to expose state), abstract to force implementation and virtual to optionally allow implementation. In no way are you forced to expose all internal state (even though people often do).

I think there's a case to be made against class hierarchies, and also against using OO in javascript. But I'm not sure Ragan made either of them well here.

</comment><comment><USER33> What is missing from the discussion here is that where domain knowledge is less important. For example, almost every widget system I have ever looked at uses class inheritance because it makes it relatively easy to manage consistent interfaces across classes. This is true of GTK, wxwidgets, and many more.

It is true that the natural world doesn't necessarily admit of perfect neat classifications generally, much less trees. However, when we are talking about purely engineered solutions, the same arguments don't apply in the same way.

Here's an example. In LedgerSMB 1.4, we use (shallow) class inheritance in a reporting framework. It works, and works well. Reports inherit an abstract class with lots of hooks for customization but a lot of defaults.

In future versions we will likely be moving away from an inheritance-based approach, not because of the arguments here or the maintenance issues (which will crop up any time you rely on external components) but because we think we can create clearer code by moving from a class/inheritance approach to a DSL approach.

I am not sure that class contracts and DSL syntax contracts are necessarily any different from a maintenance perspective other than the fact that the latter strikes me as resulting in clearer code.

</comment><comment><USER34> Anybody have an original source for "prefer composition over inheritance"? I've heard it for years, but never with an attribution.

FWIW, I noticed that in my old C++ book (Stroustrup '91) there's some _really_ bogus inheritance examples - window -> window_w_banner -> window_w_menu -> window_w_banner_and_menu etc etc etc.

<comment><USER35> The idea is presumably older, but I think the current usage can almost always be traced back to _Design Patterns_ (GoF, 1995). It's in the Introduction.

I don't think Stroustrup really gets OO. I have yet to read a book of his that doesn't have some absolute howlers.

</comment></comment><comment><USER36> "Hey, guys. Here's a really poorly considered hierarchy of classes, where I haven't really made any real effort to separate concerns or otherwise prepare for the problems which I am specifically creating.

Now, look at all these bad things that I've done! NEVER DO ANYTHING SIMILAR EVER."

That pretty much sums it up.

</comment><comment> V-2 Yet another post titled "don't do X", which actually reads as "do not exaggerate with X" or "did you know? X has some caveats".

Of course inheritance is not a solution for everything. Avoid using deep inheritance hierarchies, you'll paint yourself into a corner. It's advisable to prefer composition over inheritance. You should not be that guy who only has a hammer and everything looks like a nail to him. But it doesn't translate into: "hammer? don't do that!"

All the examples he's giving either demonstrate abusing the inheritance concept or just show that it has certain limitations. There are well known solutions and guidelines for dealing with problems such as fragile base class, other than throwing the whole paradigm out of the window

</comment><comment><USER37> It's difficult to argue with this article. I can count on one hand the number of times non-trivial class hierarchies (that is, more more than 2-3 classes) made my life easer and every time that was the case I writing a compiler or a code generator or something similar.

<comment><USER38> The Magnitude/Number hierarchy in Smalltalk is amazing.

</comment></comment><comment><USER39> > It turns out that our knowledge of the behaviour of non-trivial domains > (like zoology or banking) does not classify into a nice tree, it forms a > directed acyclic graph. Or if we are to stay in the metaphor, it's a > thicket.

That completely chimes with my experience. I wondered if I was doing OOP wrong, as any time the size/complexity of a project (or module) gets above a certain level, a Thicket results in my code.

> Classes are the wrong semantic model, and the wisdom of fifty years of > experience with them is that there are better ways to compose programs.

Where's your source/links? What? This needs expanding - if there are better ways, outline your evidence and show us where we're going wrong :)

<comment><USER40> That was sometime I want to ask too.

Probably is the go OO-model?

</comment></comment><comment><USER41> This is generally true. On the other hand, interfaces are a _good_ thing, especially in a language like Go where you can explicitly declare them and then pass in anything that happens to match that interface. (In JavaScript, this is unfortunately implicit, so it requires better documentation and sometimes runtime checks to ensure sanity.)

If you implement an interface using delegation, you get something quite like subclassing, except that the subclass-superclass interface is explicit and the superclass's type is entirely hidden. Sadly, few languages make this easy so it often requires some boilerplate or meta-programming.

<comment><USER42> Delegation can have a performance cost that inheritance doesn't have however, at least, depending on the compiler. Go's current compiler seems engineered for correctness, not performance, at least last time I checked, the JVM was beating it on several benchmarks.

<comment><USER41> Go seems to be headed towards pretty fast and predictable performance rather than the fastest possible performance at the expense of predictability. (For example, the work to replace segmented stacks with contiguous stacks improves performance in some cases but also makes function call performance more predictable.)

A JVM can have fast or slow performance depending on JVM flags, warmup time, and the phase of the moon.

<comment><USER42> Not really bashing Go, but I was was disappointed that for what is purportedly a 'systems programming language', performance was far behind C/C++/D/Mars/etc. I expect a little more from a statically ahead-of-time compiled language.

For 80% of apps, that's just fine, but would you write a mobile web browser in Go, or say, Call of Duty? Seems you'd be leaving 50% performance on the table in some scenarios.

I tend to give 'systems programming language' special status. They're how you achieve maximum system performance if not writing in assembly. You write kernels, device drivers, virtual machines, and games in them. If they are imposing severe performance or memory overhead, then they are application programming languages, not systems programming languages.

<comment><USER43> I think the messaging around Go has changed a bit since it was originally introduced. If you look at the front page of golang.org, it doesn't talk about Go as a systems programming language. I do remember the way it was pitched initially, but I agree with what you're saying and think that even the Go people themselves wouldn't lump Go in with C for things like kernels or leading edge games.

</comment></comment></comment></comment></comment><comment><USER44> I like these articles, but I think there are more than enough of them out there and not enough of those that show you how to use composition.

Everyone who has spent enough time with OO and classical inheritance knows the problems, but most have never seen how to convert a mess of classes and inheritance into a more functional approach with composition.

Don't get me wrong, there was good content here, but I was hoping that after the conclusion, the post was going to go into how to use composition as an alternative.

</comment><comment><USER45> This reminds me of a design question I recently faced when building a simple multi-player game. The idea was pretty standard; The server sent events (player dies, player moves to pos, etc.) to its clients over a TCP socket. When programming the client in Java (for Android) I wanted a clean way to update the world based on the event type. In Haskell I would have done something like

data Event = PlayerDied Player Reason | PlayerMove Player Coords | ...

and use pattern matching on the event type. In C I would have used a combination of unions and structs with an event type. But how to do that in Java? I ended up with

interface Event { public update(Game g); }

and used e.g.

class DeathEvent implements Event {

      DeathEvent(String player, String reason) { ... }

      update(Game g) {
        g.killPlayer(player, reason);
      }

}

Combined with a parsing function (public Event parse(String line) {...}) I could read from the socket and update the game in a convenient way, but to be fair I used that mostly because Java guys discourage you to use instanceof although it seemed clearer.

So is this the preferred way to do something like this? I think "they" (the OOP warriors) call this the Visitor pattern. However I really find the data- type encapsulation in Haskell and other languages (in Python a tuple (type, object) would do) superior. But maybe my Java just got rusty.

</comment><comment><USER46> In javascript*

I think this highlights a problem with javascript more than OOP: We're trying to fit it into uses cases that are simply too complex for its design. It wasn't made to build your goddamn bank accounting system, it was made so that "nonprofessional programmers" could animate things on websites.

But it also highlights a problem it doesn't take about: Language in computer science and how it affects how we think about things.

In this instance, public and private are terrible names. They had to tell us in programming classes that they're not related to security, which means that the privacy metaphor is a terrible idea because it's not instinctual.

This in turn causes us to shoehorn class design into things they perhaps shouldn't be. At this point, for complex programs we should be describing things in a much more complex way than "accessible from the outside or not". As the article points out, it doesn't _matter_ that the classes are external, because you can just as well break things from the inside.

This is a complex problem, but I think the beginning of a solution is to a) Depend on meta-information (or better implement a flexible, non-arbitrary "access" structure) and b) Use the right tool for the right job, in this case not JS.

</comment><comment><USER47> Class hierarchies are just mental tools, not how machines/programs/automatas actually work. If the mental tools implode due to exceptions and complexities, that's the problem of their uses, not tools by themselves. Before blaming hierarchies, you should blame yourself for using tools in wrong ways.

</comment><comment><USER48> Isn't he mostly complaining about lack of encapsulation? So what if you do encapsulate your data? That's totally possible in most programming languages, and it's even possible in javascript if you drop prototype inheritance. You can use closures to encapsulate your data.

</comment><comment><USER49> This is interesting, reading some of the linked documents, my naive generalization is that it pushes the entities into using things like maps and dictionaries instead of static properties. The "system manager" stuff just pulls things out of the maps and feeds them to functions to do work, so it is very much 'data-driven' and I must assume more work is put into "configuration" of the entities, just like a data-driven business process requires "configuration" of the order processing pipeline. [http://www.richardlord.net/blog/what-is-an-entity- framework](http://www.richardlord.net/blog/what-is-an-entity-framework)

<comment><USER49> Wonder if this implies you know what you are going to be doing in the future. As said by Sandi Metz, the true value good design is to reduce the risks of future change. I think it is a valid endeavor to study what reduces risk and what increases risk. This doesn't have to be about "design patterns".

</comment></comment><comment><USER43> Something I haven't seen mentioned in this discussion so far is the Data, Context, Interaction (DCI) pattern.

[https://en.wikipedia.org/wiki/Data,_Context,_and_Interaction](https://en.wikipedia.org/wiki/Data,_Context,_and_Interaction)

As mentioned at points in this thread, some objects need different behavior based on their context. DCI is a thought provoking way to represent that (though one that not in common use and that is often described as "being done wrong" on the object composition mailing list[1]).

[1]: [https://groups.google.com/forum/#!forum/object- composition](https://groups.google.com/forum/#!forum/object-composition)

</comment><comment><USER50> Cocoa is good because, among other things, is treads lightly on class hiearchies.

</comment><comment><USER51> Personally I believe that software design is a highly subjective art. People that are meant to maintain a piece of code are different. Some may be more creative and less pragmatic, others may be more structured and clean in their design.

The truth is that there's no silver bullet. You can build software based on hierarchy of classes because your mind works better with that structure, but others may find it completely inappropriate. We're human and our mind works differently from one another.

In that sense I truly believe software is much closer to art than engineering.

</comment><comment><USER52> This approach to discussing inheritance treats JavaScript as if you're a Java or C++ programmer, and completely lacks any clarity with how inheritance in JavaScript really works.

Best intro I've read on the topic I'm talking about is from Alex Sexton (just read the last example, it really hits the nail on the head):

[https://alexsexton.com/blog/2013/04/understanding- javascript...](https://alexsexton.com/blog/2013/04/understanding-javascript- inheritance/)

So you _might_ want a wee bit of hierarchy, if you're thinking like those "shared options" scenario, but not in the "OO type abstraction tree".

So, you might have something like a "Account.prototype.primeInterestRate" property that you can change in a running program, and then all the other types of account can calculate interest based on that shared property.

However, the more experienced jS developers I've met might take those "Account.prototype.balance" and "Account.prototype.deposit" methods, and push those into a "mixin" type (like "CurrentBalance") where those methods are __copied __(not inherited) onto the child class prototype, and those methods, might have initializer helpers to set up the "currentBalance" property they use. This mixin approach only gets gnarly if there's any feature envy. (Document your object properties clearly, folks. This is where javaScript's flexibility often becomes a crutch - lots of issues happen if mixin code uses "this.foo" for different things.)

Anyhow, what's interesting here is that Account carries the property that's shared, but CurrentBalance carries "behaviors", and is _not shared_ , and your "child classes" like VisaDebitAccount embed both in different ways. It is a very different way of thinking about object relationships, and often works smoothly.

But if you're using classes in JavaScript like you would Java, well, then, you're not really using JavaScript, right? And, this whole talk about biological-style ontology just becomes the wrong metaphor, because while "humans are a primate" we can't change aspects of primates to add behavior to people!

</comment><comment><USER53> That inheritance doesn't get encapsulated was the same way I felt about modules in ruby. You could include them into a class or other modules, but the interface was never well defined, and you could cause incompatibilities by relying on the implementation of the class you include into, unless you're disciplined enough to only use methods, and not attributes.

On the other hand, defining all the interfaces all the time, like in java was painstaking. I hope for some sort of middle ground.

</comment><comment><USER54> The most challenging aspect of inheritance modelling is to recognize it on its intrinsics - the deliberate creation of coupled properties and behaviors associated with the "isa" declaration - and not simply as a form of taxonomy.

Programmers are still inclined to use hierarchies. They are implicit to source code in a more general sense, with indentation, nested logic, etc. But we also need affordances to break up hierarchies and keep them limited.

</comment><comment><USER55>
      ChequingAccount.prototype.process = function (cheque) {
        this.setBalance(this.getBalance() - cheque.amount());
        return this;
      }

...

</comment><comment><USER56> From a practical point of view, mixing in behavior and implementing via encapsulation is usually easier to maintain and extend than inheritance.

</comment><comment><USER57> Another battle in the 60 year language wars based on criteria that are so obscure that have battles just over the darned criteria.

</comment><comment><USER58> My js style began with a heavy usage of classes. I then left that for prototype composition. Recently, I've arrived at a style influenced by Haskell's separation of functions and data - namespaced objects of functions that act on plain json-serializable data. Flexible, simple, and perfomant. I don't miss 'this' at all.

</comment><comment><USER59> > That kind of ontology is useful for writing requirements, use cases, tests, > and so on. But that doesn't mean that it's useful for writing code the code > that implements bank accounts.

Isn't good, easy readable code look very similar to requirements it was written upon?

</comment><comment><USER60> It's pretty much a promotion/defense for SmallTalk. Why everybody has grudges against JavaScript?

</comment><comment><USER61> Class hierarchies are OK when they have one level. It's essentially object oriented switch statatement with bells and whistles.

I can't remember one class hierarchy more than one level deep that was worth it.

They save a little code - true, but at the cost of coupling, making it harder to change, and forcing early debatable decisions on programmer (which classification is more important and goes first for example).

</comment><comment><USER62> "Object Oriented design is the Roman Numerals of Computing" \- Rob Pike

For more quotes see :

[http://harmful.cat-v.org/software/OO_programming/](http://harmful.cat-v.org/software/OO_programming/)

Another, seeing as it's PG :

"The phrase 'object-oriented' means a lot of things. Half are obvious, and the other half are mistakes." — Paul Graham

<comment><USER63> While I admire both Pike and Graham, I've never liked the use of zingers to articulate a programming point. Invariably, programming involves trade-offs, acceptance of limitations in one dimension to gain benefits in another. So, zinging the limitations is easy to do and doesn't advance understanding.

</comment></comment><comment><USER64> In idiomatic Python, the only reason for class inheritance is for code reuse.

In other languages, especially Java, class hierarchies are a matter of self- esteem.

Javascript programmers could do worse than emulate Python in this regard.

</comment><comment><USER65> Ow

</comment><comment><USER66> Please can yo make the type in your blog even less readable? I think knocking back the grey so that it matches the background should do it - you're almost there just needs a tad more.

<comment><USER67> This sort of sarcastic sniping is one thing we really don't want on Hacker News. We don't ban people for it, but it should be downvoted.

I don't mean to pick on vermooten here; lots of HNers post comments like this. Please don't post comments like this. Re-read what you post and, if it contains sarcastic sniping, edit it out.

I'll be pointing out examples of what's good and what's bad on HN, in the hope that the feedback will be helpful to the community. When I do that, I hope everyone understands that it's never personal, only about the content and only for trying to make HN better.</comment></comment>


Tell HN: We've Lost An Engineering Luminary - Bob Davis (IEEE) - <AUTHOR> Hi HN,
I'm admittedly not very good at this sort of thing, so please try to be patient, kind, and considerate.
Last week, engineering lost one of its most significant giants. You may not recognize his name, but at this moment, as you read this message on an electronic device over a network, you are standing on his shoulders.
His name was Bob Davis.
Bob spent most of his life as an active contributor and organizer for the IEEE. Whether it was the sticky politics of getting many competing interests to work together or solving the many supposedly unsolvable engineering challenges, Bob was truly amazing. The technology and networks you use every day are due, in part, to Bob's efforts at the IEEE. Bob is one of the people you ought to thank for the bottom most layers of networking (OSI Layer 1 & 2). The list of Bob's achievements is extensive, but more importantly, he truly understood the need for collaboration and concensus.
Most all efforts are group efforts. If you take a step back from the myth of the lone genius, you will see all the other people providing all the required supporting contributions necessary for every supposedly solitary success. Since there is no master list of all contributions and contributors, no one can name all of the nameless people they ought to thank. In this competitive world where a few receive fame and fortune, try to remember the efforts of those few will always be trivial compared to the combined contributions of the unnamed supporting masses.
To you, Bob is probably just one of the countless unnamed engineers who made your life a little better through his efforts. To me, Bob was a friend, an inspiration, and an all-round amazing person. I'll miss him.
Appreciation makes efforts more meaningful. It's too late for you to thank Bob, but to turn a loss into a gain, I hope you'll look at something you enjoy, find one of the unnamed people responsible for creating it, and just tell them, thank you. <comment><USER2> _In this competitive world where a few receive fame and fortune, try to remember the efforts of those few will always be trivial compared to the combined contributions of the unnamed supporting masses._

Well said and thank you for sharing. I've never met your friend, but I respect his contributions and life as as fellow human. My sincere condolences to you, his friends, and family.

</comment><comment><USER3> The same Bob Davis that was a technical director at NetApp? I am assuming so since I don't know any other IEEE Bob Davis' out there.

I knew his web site went down (scsi.com) where did you hear of his passing? Is there / was there a service?

<comment><USER4> Yes, Bob Davis was on the IEEE MSC, and was a TD at NetApp for a few years in there... I'm not aware of any others. If this is true, I'm really sad to hear this news.

</comment></comment><comment><USER5> I was a member of the IEEE-754 (2008) committee; Bob was our MSC liaison. I didn't know him well, but I was impressed by him. Considering that he wasn't a floating-point expert, but his enthusiasm and nearly boundless patience with the agonizingly slow standards process was truly impressive. He gave up an enormous amount of his time to standards work that most engineers assume is someone else's problem.

</comment><comment><USER6> > I'm admittedly not very good at this sort of thing, so please try to be > patient, kind, and considerate.

No one, except grieving professionals, really is.

Seriously, thank you for writing this piece the way you did, it is a good one. You are right: I never heard of him. You made sure that I read your words about the loss to the end and got to know what he did a little.

</comment><comment><USER7> Thank you for sharing. My condolences on the loss of your friend.

<comment><USER8> ^

</comment></comment><comment><USER9> Rest in peace</comment>


Group of scientists suggest that octopuses might actually be aliens - <AUTHOR> http://bgr.com/2018/05/17/octopus-aliens-cephalopods-research-study <comment><USER4> As much as I love the concept, I can only imagine what a professional with expertise in cephalopods and their DNA would think while reading this article.

If you've ever read a popular press story in your area of expertise, you immediately see how many things writers oversimplify to the point of absurdity, or just get plain wrong.

I'm guessing the authors of that journal article, were they to read this news story, would simultaneously hyperventilate and strain their necks from the excessive sighing and head shaking.

<comment><USER5> > If you've ever read a popular press story in your area of expertise, you > immediately see how many things writers oversimplify to the point of > absurdity, or just get plain wrong.

I could have sworn there was a named Effect/Rule given to an extension of this but my googling is coming up short. It was about how you'll read a mainstream article about something you know a great deal about and see how much the journalists got wrong but don't keep that in mind when reading about things outside your expertise. I believe I read about it in the comments here on HN. Does anyone know what it was?

<comment><USER6> Gell-Mann Amnesia Effect

[https://en.wikipedia.org/wiki/Gell- Mann_amnesia_effect](https://en.wikipedia.org/wiki/Gell-Mann_amnesia_effect)

</comment></comment></comment><comment><USER7> "[The authors] present a fantastic overview of the various hypotheses about the evolution of life on our planet and the contribution of extraterrestrial elements. The review includes many references, several different opinions and ranges all the way to the up-todate literature...The authors take, however, one more step. Their view differs from common scientific concepts and available evidence, claiming that the origin of viruses, microbes and even animals all the way to tardigradus - originate from space."

"There are several explanations why the Cambrian explosion occurred...but the notion that viruses from extraterrestrial space are the main drivers - <USER2> uniquely presented here in this article. The authors believe this and use strong expressions, describing it as evidence-based, yet without any of the necessary evidence. As an excuse they point out to other previous unconventional ideas during history of science which turned out to be true later - this is the argument the authors use. They even find their idea "plausible" - but it is hard to follow their thinking in this respect. So this article is useful, calling for attention, and it is worth thinking about - <USER3> the main statement about viruses, microbes and even animals which came to us from space, cannot be taken seriously."

Commentary to: Cause of Cambrian explosion - Terrestrial or cosmic? Steele, E.J. et al.

Karin Molling, Max Planck Institute Molecular Genetics, Berlin, Germany

[https://www.sciencedirect.com/science/article/pii/S007961071...](https://www.sciencedirect.com/science/article/pii/S0079610718300804?via%3Dihub)

<comment><USER8> They don't cite "any evidence?" C'mon man, they cite quite a bit of evidence. No-one can read the article and truthfully say this. Size of DNA, sophistication of adaptation, differential body symettry, off the top of my head. Is that weak evidence? Well then by the same token, it's evidence.

This seems to be one of the many, many times when contemporary scientists say "there is no evidence of X" when what they mean is that there is no _incontrovertible_ evidence (the other name for which, of course, is "proof.")

But proof and evidence are manifestly not the same thing and conflating them to confuse one's opponents does nobody any favors.

Evidence that is not defeasible remains evidence. Luckily so - because post- Popper, we know that all scientific evidence is defeasible and proof never actually arrives.

</comment></comment><comment><USER9> This strangely reminds me of a Wired article[0] from 2013 where it quotes a scientist in this way: "If you want to study an alien intelligence, Godfrey- Smith says, 'octopuses are the closest thing we have.'"

Though it doesn't make the claim that it's of alien origin, nor do I subscribe to the theory necessarily. There's just too much question-begging in the theories that life is somehow of extraterrestrial origin (where did that life come from?).

I think of just how genetically plastic dogs are within their own species, that it's not hard for me to imagine life developing into all sorts of directions without having to resort to the seed hypothesis.

Then again, me trying to speak with any kind of authority on evolution or DNA is akin to a dog discussing quantum physics, so my opinion only goes so far ;)

[0] [https://www.wired.com/2013/10/how-the-freaky-octopus-can- hel...](https://www.wired.com/2013/10/how-the-freaky-octopus-can-help-us- understand-the-human-brain/)

<comment><USER10> > question-begging in the theories that life is somehow of extraterrestrial > origin (where did that life come from?).

I really dislike this paper, but they do address that. The fact that life had to start somewhere doesn't make the question of extraterrestrial origin any less interesting.

<comment><USER9> Sorry for the late reply, but I agree the idea is interesting, but for me it comes off the same way intelligent design or creationism comes off, almost as a God of the gaps type mentality. Because if life is seeded from elsewhere, it's essentially placing it's origin into infinity, and kind of hand waving away the need to dig further. Not that I'm saying we should philosophically determine where we want the evidence to go, but usually the idea is based on so much conjecture and leads to the same result practically that it just seems like a secular way of dismissing the search based on the evidence we do have.

Granted, we have no idea what discoveries and scientific advancements are going to come in the near to distant future, but while I think the question is worth considering, it seems pretty weird for some scientists to accept this conjecture, but randomly eliminate others.

To each his own I guess, but this probably is more about my own distaste for the line of thinking (that, and the whole "we're in a simulation" hypothesis), where it kicks the question off into a place where we'll probably never be able to answer it. Though as far as fun discussion and speculating as entertainment, that is where I find the ideas most enjoyable, personally :)

</comment></comment></comment><comment><USER11> Here is what I would like to understand: If there is any truth to the theory that Octopuses indeed evolved in outer space and were delivered to our planet via a cosmic payload, how is it that they happened to have the same kind of protein-based, DNA-based genetics like we have? Isn't it too much of a stretch to imagine that an alien evolved under similar conditions with similar genetic foundation like life evolved in our planet?

<comment><USER12> Earth's abiogenesis could have started via a cosmic payload as well, which potentially answers your question regarding the shared biochemistry.

[0] [https://en.m.wikipedia.org/wiki/Panspermia](https://en.m.wikipedia.org/wiki/Panspermia)

</comment></comment><comment><USER13> > Its large brain and sophisticated nervous system, camera-like eyes, flexible > bodies, instantaneous camouflage via the ability to switch color and shape > are just a few of the striking features that appear suddenly on the > evolutionary scene

Argument from incredulity.

> The genome of the Octopus shows a staggering level of complexity with 33,000 > protein-coding genes more than is present in Homo sapiens.

Red herring.

> this "great leap forward" in complexity was due to "cryopreserved squid > and/or octopus eggs" crashing into the ocean on comets millions of years ago

No evidence provided to support this claim. In addition, Cephalopoda is a very well documented clade. Meaning we have fossilized evidence the octopuses originated and developed on this planet.

> crashing into the ocean on comets millions of years ago.

Probabilistic fallacy. Interstellar objects in our solar system are rare (only one ever documented). Comets seeded with _eggs_ have never been documented and should be considered exceedingly rare. The number of comets that ever make contact with Earth is very, very low.

</comment><comment><USER14> I'm not saying this idea is wrong, but it comes with a large grain of salt. Like everything else in the world, 90% of science is crap. If there is no proposed falsifiability criterion, there is no science here.

<comment><USER8> I share your discouragement with the present state of "science" (see the Replication Crisis) but the trouble with your comment that it applies to everything ever written, not this article in particular, not to mention that Theodore Sturgeon said it first, as a still more general rule.

<comment><USER14> I assumed the HN crowd was familiar with the fact that "90% of everything is crap" is someone else's idea. This was probably not a good assumption to make.

<comment><USER15> I don't know why people are giving you a hard time here. The quote is widely- known, and I appreciated your remark about the troubling lack of falsifiability criterion.

<comment><USER8> See elsewhere here, there's no shortage of experiments to be done that could be determinative in this case. Also, Karl Popper's rule is a great rule of thumb, it really is; but there's an immense bibliography in philosophy of science about whether it's a shoe that fits all circumstances.

</comment></comment></comment></comment></comment><comment><USER16> Which was it - virus-guided evolution or cryofrozen eggs? That piece is all over the map.

And it begs the question: why is alien life DNA-based at all? Without addressing that, its just a comedy piece.

<comment><USER17> Without trying to support the piece, the DNA question has a rich history of being explainable via the panspermia theory.

<comment><USER16> Ok, then the point of the piece, that the Octopus is special in being 'alien', becomes moot? Everything is 'alien'.

<comment><USER8> But in this case, the leap in complexity is so obvious we can tell it's alien (they say.)

<comment><USER18> That argument sounds awfully similar to that of Intelligent Design.

I imagine that Punctuated Equilibrium is a far simpler explanation: [https://en.wikipedia.org/wiki/Punctuated_equilibrium](https://en.wikipedia.org/wiki/Punctuated_equilibrium)

<comment><USER8> If you find a watch on a beach... was the old argument. The argument in the paper is that the Octopi change is so fast and so immense it leaves every known instance of PE, including human evolution, far behind along with every other known leap forward. I'm not endorsing that view, just retailing it.

<comment><USER16> I'm wondering if the fossil record supports the conclusion that octopuses actually got all the claimed features at once? How does a fossil (of a soft creature, notoriously rare to fossilize at all) indicate the presence of color change, large eye and so on.

Or is it a DNA argument. Then I'm back to why DNA at all unless everything is alien. In which case, why the article. Its like "there's this one alien guy in Idaho..." instead of "There's other intelligent life in the universe!!!"

<comment><USER8> Good point, re soft bodies fossilizing more rarely - because what may have happened is the squids just didn't show up in the fossil record for a very long time, nor the proto-squids. Ocean acidification at various periods (say due to CO2 variations at different periods, which were large) would be a factor.

I'm not saying the 33 scientists weren't well aware of these considerations, though.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> For constructive criticism on the content of this article, there's a quartz piece -

[https://qz.com/1281064/a-controversial-study-has-a-new- spin-...](https://qz.com/1281064/a-controversial-study-has-a-new-spin-on-the- otherworldliness-of-the-octopus/)

<comment><USER8> Not even criticism - it doesn't mention what the scientists take to be their evidence, much less discuss any of that. It then misunderstands the mention of "future" \- the point actually being made was that the alien octopi were so much more complex because they'd had far longer to evolve, not that someone owned a time-machine. I don't have a position on the question, but this article was mostly a waste of time.

</comment></comment><comment><USER20> "The Hawaiʻian creation myth relates that the present cosmos is only the last of a series, having arisen in stages from the wreck of the previous universe. In this account, the octopus is the lone survivor of the previous, alien universe."

( [https://archive.org/details/oceanicmytholog02dixogoog](https://archive.org/details/oceanicmytholog02dixogoog) )

</comment><comment><USER21> The Simpsons weren't too far off

</comment><comment><USER22> I find this notion to be completely ridiculous. There's some things that are common to all life. The genetic code for instance. There are of course different dialects [1], but they're all fairly similar, and all code for the same set of amino acids. Cephalopods use the same means of storing genetic information, DNA with the bases G, C, A, and T. They have the same machinery to translate the genetic code into proteins, ribosomes. Ribosomal structure is highly conserved among all life. The idea that all of these molecular machinery developed in parallel on a different planet with the exact same genetic code, means of storing genetic information, and means of converting genetic information in protein is beyond absurd.

[1] [https://www.ncbi.nlm.nih.gov/Taxonomy/Utils/wprintgc.cgi](https://www.ncbi.nlm.nih.gov/Taxonomy/Utils/wprintgc.cgi)

<comment><USER8> Which is why it wasn't asserted. See Panspermia.

</comment></comment><comment><USER8> Orbital decay means planets were more distant from the sun in the past. As well, solar luminosity was lower. It's also likely that water and has accumulated on, say, Venus. So although not a likely harbor for life now, perhaps Venus was the first batter up for the evolution of life.

Against this, there are definitely other heat sources, especially for large planets, and more water (from impacts carrying water, especially) is available at a greater distance from the sun.

</comment><comment><USER23> Complete sidebar: octopuses/squid are on my short list of "things in American diet I don't eat because they are too smart" (pigs being the other).

<comment><USER24> Due to the acidification of the ocean, there's an overpopulation of squid in the seas. It would actually be beneficial if people started eating more of them, because they're predators of other fish species that we ourselves are already overfishing. Note: I'm not an environmentalist, it is just something I noticed.

<comment><USER25> In fact, I have a modest proposal to share with you on that front.

[https://en.wikipedia.org/wiki/A_Modest_Proposal](https://en.wikipedia.org/wiki/A_Modest_Proposal)

</comment></comment></comment><comment><USER26> The eventual babelfish trained using unsupervised alignment may make things like bird->human or octopus->human possible(or mycellial mass, if it turns out to be intelligent).

I have a suspicion that in the future human-centric mono-species intelligence and consciousness assumptions will be tested, and the outcome may be similar to discovering other galaxies in terms of the impact on humanity's collective psyche.

<comment><USER27> At first I was confused by "babelfish trained using unsupervised alignment", but realized after re-reading your comment several times, that it's about translation/communication (with other species!) based on machine-learning. Dolphins and maybe whales..

I like the thought of humanity discovering other forms of consciousness, whole dimensions we never expected or imagined.

</comment></comment><comment><USER28> I too am awaiting the return of the old ones.

<comment><USER29> I would like to avoid meeting any shoggoths.

 _Tekeli-li_ _Tekeli-li_

</comment></comment><comment><USER30> I wouldn't trust anything from that website. That scientific journal sounds sketchy, too

<comment><USER31> It is at least, according to Elsevier, peer reviewed.

* [https://www.elsevier.com/journals/progress-in-biophysics-and...](https://www.elsevier.com/journals/progress-in-biophysics-and-molecular-biology/0079-6107/guide-for-authors#20910)

<comment><USER18> Every pseudo-scientific journal claims to be peer reviewed.

<comment><USER31> However, so too do the properly scientific ones, so that does not demonstrate anything at all. The thing to look at is the editors, who they are and whether they indeed edit the journal as claimed.

* [https://www.bioc.cam.ac.uk/research/uto/blundell](https://www.bioc.cam.ac.uk/research/uto/blundell)

* [https://www.dpag.ox.ac.uk/team/denis-noble](https://www.dpag.ox.ac.uk/team/denis-noble)

* [http://www.herzzentrum.de/englisch/departments-sections/inst...](http://www.herzzentrum.de/englisch/departments-sections/institute-for-experimental-cardiovascular-medicine/team/peter-kohl-prof-dr.html)

<comment><USER18> > so that does not demonstrate anything at all.

That's exactly my point!

</comment></comment></comment></comment></comment><comment><USER32> Before you jump to mock this, remember we should encourage well thought out discussion that acknowledges it's shortcomings.

</comment><comment><USER33> Octopuses?

Octopi, surely?

<comment><USER34> Both are fine. (Octopi is arguably wrong, since octopus comes from Greek, not Latin (where you'd find that style of pluralization), but is used so commonly that it has become part of the language)

<comment><USER33> It's interesting, though. When I was a child "octopi" was the classic pluralization exception.

There's even the joke, "if the plural of octopus is octopi, what's the plural of whatatwitamus?"

I have never seen "octopuses" until today.

</comment></comment></comment><comment><USER35> A few questions that pop into my head:

Why did land insects never rise to match the intelligence of the octopus?

If octopuses are so smart, why aren't they more social?

Why is it that the most social of animals, ants (which are considered eusocial actually), are not pressed with becoming smarter?

Why does sex cause octopuses to self-destruct?

Also, when it comes to weird theories, I have always thought that if we are in a simulation, it is most likely a simulation created by an insect intelligence. Or if we are being visited by aliens, that those aliens would in all likelihood be of an insect like nature, not some lame anal-probing grey dudes.

I claim this as vague support for my theory of alien insects[0].

[0]: [https://news.ycombinator.com/item?id=13620387](https://news.ycombinator.com/item?id=13620387)

<comment><USER36> > _If octopuses are so smart, why aren 't they more social?_

Because they are so smart.

<comment><USER37> "For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much—the wheel, New York, wars and so on—whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man—for precisely the same reasons."

</comment></comment></comment><comment><USER38> Just my own perspective: as one who believes God is responsible for the origin, complexity, and diversity of life, this article makes me chuckle. The theory of evolution as an explanation of the _origin_ of the major taxa of life really paints us into a corner from which it is difficult to wiggle out.

In my opinion, the panspermia/alien origin hypothesis (and its persistence as an explanation in some respected circles) illustrates how strictly limiting ourselves to natural explanations leaves not just a "gap" in our ability to explain origins, but a massive gaping hole. (Also, the insistence on a distinction between "alien" and "divine" has no rational basis.)

<comment><USER39> > The theory of evolution as an explanation of the origin of the major taxa of > life really paints us into a corner from which it is difficult to wiggle > out.

I'm really not sure what you mean by this.

> Also, the insistence on a distinction between "alien" and "divine" has no > rational basis

What?? You don't see a distinction between life on another planet and supernatural phenomena...?

<comment><USER38> > I'm really not sure what you mean by this.

If you assume the major groups of life evolved from common ancestors, the fossil record doesn't offer a lot of help to fill in the early details (i.e. transitional types). Also, you have the problem of the origin of the first single-cell organism.

> You don't see a distinction between life on another planet and supernatural > phenomena...?

My point is that insisting on it being an _alien life form_ that seeded life on earth (as opposed to the God hypothesis) is kind of begging the question. Philosophically, what is the difference between an unknown alien life form and God as the origin of life, other than different starting assumptions?

<comment><USER40> >> what is the difference between an unknown alien life form and God as the origin of life, other than different starting assumptions?

for one, we do know that there _are_ life forms.</comment></comment></comment></comment>


Minimum Requirements of Using Slack - <AUTHOR> https://get.slack.help/hc/en-us/articles/115002037526-Minimum-requirements-for-using-Slack <comment><AUTHOR> I find it quite smart of Slack to define the set of officially supported browsers (& encourage users to upgrade).

Reminds me of the graded browser list that Yahoo used to maintain.</comment>


Microsoft X-box and a family problem - <AUTHOR> https://medium.com/@jeremyhillman/microsoft-x-box-and-a-family-problem-8da1b57c7a74

<comment><USER2> My bank provides me virtual visa card for online payments that I transfer funds into. So there is cap on how much can be spent - and I determine it. I usually keep 100 EUR there and replenish (e-banking is great in Europe).

Solves a lot of problems that way - you cannot charge what you don't have.</comment>


I got kicked out of YC startup school - <AUTHOR> https://www.reddit.com/r/Entrepreneur/comments/67hgvi/i_got_kicked_out_from_yc_when_y_combinator_turned/?st=J1XRB1DQ&sh=1a5fc14c <comment><USER2> _Interesting_ use of doxxing the Startup School moderator by linking to their LinkedIn.

</comment><comment><USER3> So a guy explains in many many words how he let a third party in to a supposedly private call, gets an email that because of letting others in to a private conversation he is being kicked out, and still rambles on in many more words how he doesn't know, why he was kicked out, that it must have something to do with being "gross" and whatnot.

Drama. Flagged.

</comment><comment><AUTHOR> I am not op of the Reddit post, only thought it might be relevant.

<comment><USER4> also at [https://news.ycombinator.com/item?id=14194865](https://news.ycombinator.com/item?id=14194865)</comment></comment>


58% of high-performance employees say they need more quiet work spaces - <AUTHOR> http://www.cnbc.com/2017/03/15/58-of-high-performance-employees-say-they-need-more-quiet-work-spaces.html <comment><USER2> My summary: article is bogus clickbait.

This is a classic example of a biased survey leading to BOGUS results. If you click on the "anonymous survey" link in the article, you see that the author phrased the questions in a way that automatically confirms the hypothesis (as opposed to _testing_ it)!

Your current office environment: *

Is too noisy... Is too distracting... Is too open... Is too crowded... Does not have enough private quiet spaces... Is too quiet... Is too cold... Is too warm...

</comment><comment><USER3> As a HPE - this is spot on.</comment>


I just received a call from Apple - <AUTHOR> https://blog.creolabs.com/2018/06/26/creoplayer-no-longer-available/ <comment><USER2> And people wonder why this sort of garbage behavior is headed to the Supreme Court.</comment>


What are the lesser known but useful data structures? - <AUTHOR> http://stackoverflow.com/questions/500607/what-are-the-lesser-known-but-useful-data-structures

<comment><USER2> It really annoys me that questions like this aren't welcome on Stack Overflow anymore. This is a great example of a question which doesn't have "one right answer" but is still constructive and relevant.</comment>


Seemingly Impossible Turing Machines - <AUTHOR> https://www.playingwithpointers.com/blog/impossible-programs.html <comment><USER2> My intuition tells me that no Turing machine that terminates for all unbounded inputs can run "much longer than" a busy-beaver turing machine. However, the numbers that describe how long BBs can run are .. quite large. The numbers might as well be infinite in any practical sense.</comment>


Ask HN: I'm making web developer tees – what designs should I make? - <AUTHOR>

Hey guys, I recently built (www.shirtjs.com) - a way for web developers to show their passion for code with cool shirts (and posters) while supporting developer projects. I started it with a kickass designer friend of mine and its been a fun journey so far, but it's still a work in progress.
The response has been great so far from startups and dev teams (our shirts are at Google, Cloudflare, and TripAdvisor)! We've thought up all the designs for the shirts ourselves so far but our selection isn't well balanced. I figured what better way to get feedback and find out what devs want than to ask you guys (and gals).
The Problem: The designs are really JavaScript heavy so  far (AngularJS, NodeJS, BackboneJS, etc.) and I want them to better represent all of web dev's technologies. Eventually it'd be great if web developers using any framework or technology could find something they could relate to and felt proud to wear.
We've gotten requests for these languages but I'm not sure if there's enough interest: -Gulp -React -Knockout -Django -Laravel -Sproutcore
We're thinking of adding the following designs: -"There's an API for that" -"Git with it" -"There's no place like localhost" -Something related to Ruby on Rails?
Suggestions? I'd like to get more suggestions and feedback on what you guys think would be cool designs, quotes, or topics for shirts. What languages/frameworks would you like to see? What are some quotes/sayings you've always wanted on a dev shirt?
Cheers! <comment><USER2> You should most certainly work on an idea for Ruby on Rails.

I would recommend you google a little about the communities that surround each language, which will lead you to the conclusion that Ruby on Rails community would be an obvious first choice for expansion. (I would think NodeJS or AngularJS would be close -- but you already have those).

Hope that helps!

</comment><comment><USER3> Some great designs here, and I appreciate the fact that these are mostly in the "not campy" category. Your suggestions of "no place like localhost" are getting campy and have already been done before.

As a business suggestion, you should just try adding it and seeing how sales go... but as a likely customer, I like your current curation, mostly just logos deconstructed in a hot way.</comment>