The Case Against OOP Is Wildly Overstated - <AUTHOR> https://medium.com/young-coder/the-case-against-oop-is-wildly-overstated-572eae5ab495 <comment><USER2> This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.

<comment><USER3> So what is your preferred solution for programs that intrinsically need to deal with a lot of state ? Global variables ?

I used to see that type of approach in some complex Fortran simulation programs where every function referenced a huge common block. I really don't think that leads to easier to manage solutions.

<comment><USER2> Essentially, yes, but in a way that sounds more careful than what you saw in that Fortran program. If it absolutely has to be stateful, like with a db connection for example, then there's no getting around that, but what you _can_ do is (1) not bury it in a bunch of stateful objects that didn't have to be stateful, which can cause cascading errors when either one of them misbehaves and also makes it difficult to isolate any one stateful component for testing or re-use, and (2) use special wrappers around it that will make the statefulness easier to deal with. (For examples of (2), see Clojure atoms and the Clojure library mount: [https://github.com/tolitius/mount](https://github.com/tolitius/mount) )

<comment><USER4> More concretely, for every bit of state in the program I'm interested in two big questions, each with two subquestions:

1.) Who can _access_ this state, and which of those accesses allow writes vs. which are read-only?

2.) What is the _lifetime_ of that state, and what portion of that lifetime is mutable vs. read-only?

Java-style OOP can control #1, but makes no distinction between reads & writes. C++ const correctness and the val/var distinction in Kotlin/Ocaml/ES6/etc. can make that distinction, but only C++ forces you to think in terms of lifetimes. Rust borrowing probably comes closest to answering all 4.

I'm still waiting for a language feature that lets you say "This field of this struct is only mutable while this module is running, and once it completes it will never be changed", though. A lot of data structures are initialized in passes and then passed along as constant data: you construct the basic object structure with nothing but a few IDs, then you compute extra fields as necessary, then you're done and the object is never written to again. If you could keep the fields mutable during initialization (which may be a longer process than just constructor calls) and then seal them off once that's complete, you eliminate a whole class of bugs where a read-only client decides to mutate a field that should only be mutated from designated initializer.

<comment><USER5> That would be really cool, but I think enforcing that is undecidable. My gut tells me that having that language feature at compile time is the same as the Halting Problem.

<comment><USER4> In its full generality it's undecidable, but there are probably restrictions you can build into the type system to make it decidable. I was thinking something along these lines:

      class Symbol {
        @init(constructor) originalToken: Token
        @init(constructor) position: SourceLocation
        @init(Parser.parse) scope: SymbolTable
        @init(Parser.parse) declaredType: Type
        @init(TypeChecker.typecheck) inferredType: Type
        @init(DataFlowAnalyzer.computeLiveness) usages: List<Expr>
      }

And then the type system carries an extra bit of information around for whether a reference is fully-constructed or not, much like const-correctness. Fields marked with @init can only be written on a reference that's not fully- constructed. There's no compile-time enforcement for initialization order, though it'd be pretty easy to do this at runtime (convert them to null-checks or special not-initialized sentinel values). Newly-created references start out with the "initializing" bit set, but once they're returned from a function or passed into a function not in the list of legal accessors, they lose this bit unless explicitly declared.

It's basically the same way "mutable" works (in languages that support it), but with a separate state bit in the type system and extra access checks within the mutating functions to make sure they only touch the fields they're declared to touch. You can fake this now by passing mutable references into initialization functions and then only using const, but it's a bit less specific because many classes are designed to be long-term mutable through 1-2 specific public APIs but also need to be mutated internally for deferred initialization, and lumping these use-cases together means that deferred fields can be touched by the public API.

</comment></comment></comment></comment></comment></comment><comment><USER6> Since I accepted I was no Einstein I embraced the KISS principle.

My code became simpler, easier to understand.

Of course it wouldn't get the approval of any software architect or any design pattern fanatic, but I can take any code I wrote 3 years ago, understand it on the fly and edit it with confidence. There are few bugs and they're never a nightmare to find.

Now if I have to modify the code I was writing before my KISS revelation, when I was reading too much about OOP and design patterns then the headaches start. Often I'm left wondering why oh why I had to use so many levels of indirection to solve what is a simple problem.

<comment><USER7> Einstein himself would approve this philosophy. As he once said, "Everything should be made as simple as possible, but no simpler."

Still, finding the simplest-possible solution to complex problems is often challenging in itself, especially considering what is "simple" or "intuitive" can be highly subjective. Engineers are often uncomfortable thinking about these problems because the domain is shifted somewhat away from the realm of logic machines and towards psychology and UX, in which they have little to no education or experience.

<comment><USER8> An idea I carried over from mechanical engineering is the idea of degrees of freedom. If your solution has fewer degrees of freedom than the problem, it doesn't work. If it has too many it's unconstrained and requires hacks to keep it from doing something terrible.

</comment></comment></comment><comment><USER9> > The solution to the fragile base class problem and other inheritance > hangovers is surprisingly simple — don't use it

If OOP provides the footgun to shoot yourself, OOP is at fault. Overall the article reads as "OOP has no problems if is used correctly". Of course that's true. I have seen well designed OOP programs, but the majority was not. The author should ask the question, why OOP is applied the wrong way so often.

<comment><USER10> The term we like to use is "the pit of success". It shouldn't be hard to do it the right way.

<comment><USER11> "The pit of success" is a great guiding principle when it comes to the design of codebases. Forget about "design patterns" and just focus on _how do I allow developers to focus on creating things that are adding value, rather than faffing around with extraneous things_.

I can't tell you how many times I've seen a project go full onion-pattern with a web service that basically just recieves HTTP requests and makes a few itself and returns some data. Instead of a HTTP request handler that fetches data, perhaps does some mutation and returns it, there's a whole "service layer", a domain model, data fetching abstraction. To change something you have to navigate the winding dependency graph and fight off all the deamons. That's not the pit of success, they're the catacombs of failure.

We should design codebases so that future developers fall into the pit of success, even if it means we haven't been able to show off our knowledge of software architecture etc. The best pattern you can ever apply, is the one that makes change easiest. If you make change hard, the code becomes artificially stale -- I call it 'calcified'. Coupling makes code hard to change.

Thinking about problems through objects, in my experience, encourages people to make 'one model to rule them all', for example in a retail app, you might have a "Product" which ends up having product information, media assets, pricing, promotions, retail and stock keeping information etc which in a peice of software undergoing 'rapid development', multiplies the likelihood of coupling. Which is where Domain Driven Design steps in and tries to preach. Thinking about your problem in terms of data, or events can often help you find the right concepts to create your abstractions around. Another good heuristic is to think about caching, can you cache pricing for the same length of time you can cache product information, for example?

Bit of a ramble, but explains why I tend to shy away from objects, except for where I have a bonafide business problem that needs to be modelled -- with this, the models are only used to make the code make sense to developers and help arrive at the result they produce, rather than the models being the result themselves.

<comment><USER12> For large interwoven software systems this complexity seen in the form of service layers, directory services, distributed quorums, etc. is often necessary to achieve availability guarantees. I think that the problem is that engineers are over eager to design these sorts of things and implement them before they're actually necessary. And they do it badly and make life shitty in the process because they still don't fully understand the requirements for such a system. OOP just happens to be the language feature they use to make a mess. It would still be no fun even if they used a straight procedural language like C.

<comment><USER13> Adding on to this, there's an important distinction described by Parnas back in the 1970s as

> _Software can be considered "general" if it can be used, without change, in > a variety of situations. Software can be considered "flexible", if it is > easily changed to be used in a variety of situations._

We frequently forget that these are both valid paths to the same end. We tend to laser-focus in on generality, at the expense of flexibility.

And for small problems like the one described, it is usually much easier to go for flexibility at the expense of generality. _And I think we should._

</comment></comment></comment></comment></comment><comment><USER14> The author is right about ORMs. They are ridiculously over engineered solutions. (My experience is largely with Django and SQLAlchemy ORMs)

As soon as you want to do something that's not already perfectly built in, everything becomes a mess of impenetrable hacks. Autogenerated Django migrations are unstable and often need to be edited to to be correct or make any damn sense.

It also encourages to people to blur or just straight up stomp on the line between ORM objects - tightly coupled to your database - and business-logic objects (entities, usecases, whatever). It's the Django recommended approach, called "fat models" and it leads to ridiculous levels of coupling and impenetrable ball-of-mud code.

Just write SQL and marshal it into business objects. I'm actually quite fond of doing this with the SQLAlchemy Table & Query APIs, they do most of the marshaling for you.

In Go I just write the raw SQL.

More generally regarding OOP: I have never seen any good come from more than one layer of inheritance.

<comment><USER15> Always prescribing raw sql is dangerous: You typically want _something_ managing your sql queries if there's user input because scrubbing out SQL injections is hard and it's not something you should be 'rolling your own'

<comment><USER16> I presume that when somebody says raw sql they mean are using parameters and not just building strings.

<comment><USER17> and SPROCS

</comment></comment></comment></comment><comment><USER18> The problem I've always had with these back-and-forths between various programming philosophies is that the very nature of the argument exposes the reason the arguments don't work.

The most common (but not only) way each side argues its point is to take some contrived example and show how philosophy X does it well, and how philosophy Y does it terribly. These examples are often ranted about by the "Y" proponents because "it's a bad problem choice designed to make Y look bad".

Yes. It is. Because X and Y were not designed to solve the same problems. If you pick an example Y is good at, most of the time X will be bad at it. So if you're doing something like that, use Y. But if you're doing something X is good at, then pick X

Why would you intentionally shoot yourself in the foot to use a framework, language, philosophy, etc. that was never intended to be used for that thing when there's something that was? Stop arguing about who's better at what. X and Y are good at different things. That's why they're _different philosophies/languages/technologies_.

<comment><USER19> So let's say I've decided to sit down and write a digital audio workstation. I've got to pick at least one programming language and at least one general programming style. Let's say I pick C++ and (somewhat by implication) a generally OOP style.

Someone comes along and says "oh, you could do this much better with Haskell and functional programming".

How can you argue that the comparison involves an "X and Y" that are not designed to solve the same problem? Advocates for languages and programming styles are generally doing so on the basis that there is a broad class of software development problems/projects that will benefit from the use of their preferred "X and Y".

Sure, there are some DSLs that are clearly not intended to be compared with (say) C++. And there are some overall programming styles that clearly suite certain kinds of software much more than others (e.g. the absence of an event loop somewhat changes everything, as does high level distributed parallelism).

But OOP isn't an example of such a thing.

<comment><USER20> > How can you argue that the comparison involves an "X and Y" that are not > designed to solve the same problem?

Because Y is Haskell and your project has soft-realtime scheduling constraints.

But if Y were Rust, point taken.

</comment></comment></comment><comment><USER21> The author flatly says "do not use inheritance." Without inheritance and polymorphism, what is left in OOP? If you look at the author's 4 pillars, the only thing left is encapsulation (and "Oversimplified Hot Takes") It seems like the author himself has proven why OOP is bad. You can have encapsulation without OOP. People were doing it in C 40 years ago. And people are doing it in Go right now. No one would call Go an OO language, yet it has what the author admits is OOP's only good feature.

<comment><USER22> Yes, you could do encapsulation in C. You'd have a struct. But the problem is, any function in the whole program could modify the data in the struct, possibly placing it in an invalid state. When the struct wound up in an invalid state, you had to look at the entire program to find out who did it.

(C++ style) OOP encapsulation is different. Only member functions can modify the "struct" (object) data (unless you did something crazy like make your data members public). If the data is in an invalid state one of the member functions did it. Nobody else had the ability to do so. Your debugging got easier, because there's a much smaller set of places where the problem could be.

Now, true, you could do that in C, with the structure declared only in one C file (and no header file), and all functions declared file static except the "public interface". But C++ make that the normal way to work, not something that you had to go out of your way to do.

Inheritance: If you have a problem where it adds value, use it. It's a tool, not a religious dogma (either for or against). You could argue that most people, when they think they have a problem where inheritance adds value, are mistaken. You could even be right. But _never_ use it? It's _always_ the wrong choice? Get outta here. I'll use it when it helps - when the shape of the problem calls for it.

<comment><USER21> I never said encapsulation was easy or obvious in C, just that it's nothing new or inherently OOP-based. I also never said that you should never use inheritance, I was just quoting the author, who, in his "defence" of OOP admits that OOP's only unique feature should not be used at all.

</comment></comment></comment><comment><USER23> IMO, OOP just puts too many footguns at your disposal, the most dangerous one being mutability (how normal is it that our methods mutate instance variables?). The larger a system grows the more mutability will make it even harder to understand and control. It may be tolerable in small-scale embedded software, but outside of that we should make use of the better alternatives that modern hardware affords us.

<comment><USER24> I knew a professor who worked on Density Functional Theory which can be used to derive many of the properties of materials from first principles. (e.g. "Does Iron Conduct Electricity?")

This involved running FORTRAN programs on what was then considered a large supercomputer (256 nodes.) Asked what he thought about any programming technique that cost a factor of 2 in performance and he told me it was a non- starter when he ran jobs that took a month.

Back when Hadoop was popular, the "cutting edge" of the thing was the system that deserialized and serialized data and some of the major ways to improve performance are: eliminating copies, eliminating memory allocations, etc.

I told Rich Hickey the same thing I was told, that even though the performance difference isn't much in the grand scheme of things, people who have high performance needs are going to dismiss whatever he brings to the table if it costs them a factor of two.

Interestingly, Hickey responded the same way the professor did: just as the professor dismissed the value of the 2x slower but more maintainable system, Hickey just seemed to dismiss the value of "2x faster".

I see this a lot where people just don't communicate, even when they pretend they are.

<comment><USER25> HPC obviously prefers higher performing approaches, but how is this anecdote relevant to general programming community?

The position that x2 "isn't much in the grand scheme of things" is a reasonable position. Note the "grand scheme" qualifier. Also the implicit here is "we trade performance for ---". The professor was making a sensible statement about tradeoffs when considering 'general programming approaches'.

Your last line also reads like a potshot at Rich Hickey.

I think the _actual_ failure of OOP is that it did -not- result in the desired outcome of addressing the "software crisis" [1] and the significant imbalance between the scale of required (new) software and available human resources to write these systems. A subset of programmers can use OOP to build very effective systems; the rest shoot themselves in the foot. That is the failure of OOP.

But I am curious if any other software methodology prevents underskilled developers from shooting their own feet. AFAIK the answer is a definitive 'No'.

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

<comment><USER24> It's a potshot at everybody.

Years ago I thought "people are fundamentally good."

Now I listen to the fire and brimstone preachers on the radio and every so often it gets to me.

I wouldn't quite say "people are born in sin" but it does seem that people can't really handle computers or carbon-containing fuels or other technologies. So often I meet somebody who is said to have 'good social skills' or who 'cares about people'. Somebody will have a talk with them and tell you that they felt like they were 'listened to' but when I talk with the 'good social skills' guy an hour later about the conversation he had that left somebody impressed it is clear the 'good listener' dubbed over what he heard in his mind with what he wants.

He never gets challenged over this, but this is the problem I see. People talking past each other, not listening. I know one person who can listen to people argue for an hour and repeat back what they said in great detail, but a lot of "high performers" seem to make it through life because their bluff never gets called.

\---

The model where software development starts by "determining the requirements" may itself be a "bad smell".

On some level it is all about 'satisfying the requirements', but there is something to say for putting the integrity of the system first.

For instance, say you want to build an airplane that carries a huge radar, such as an AWACS plane. If you were going to build a plane from scratch you would be overwhelmed with "non-functional requirements" such as being able to take off and land, not crash because of ice, etc. You would be driven batty by the people who want to argue with reality about those requirements (e.g. Boeing executives that couldn't reconcile the asked-for-by-customer not retraining the pilot with the 'not crash' non-functional requirement.)

If you have any sense you buy an off-the-shelf plane and stick an antenna on top and you skip the psychoanalysis. You get this

[https://en.wikipedia.org/wiki/Embraer_R-99](https://en.wikipedia.org/wiki/Embraer_R-99)

By "design reuse" you reuse all sorts of validation, testing and experience. Many software projects go at it entirely wrong, getting into the "let's design a whole new airframe" approach.

</comment></comment></comment></comment><comment><USER26> Article doesn't even make an argument. If you're not modelling things with objects, and you're not using inheritance, in what sense are you doing OOP at all?

If you want to treat OOP as a tool to use when it's appropriate to the problem, good - but as you gain experience you'll find that that actually just means "never".

</comment><comment><USER27> Pretty good takes here in the comments (shout out to references to "pit of success")

There are two things worth mentioning, though.

1) the best pragmatic programming recommendation is "semantic compression" by Muratori [1]. Incidentally, I find it to be an effective "takedown" of the sort of dogmatic oop that anyone criticizing oop is criticizing

2) Muratori might disagree with this, but for me the whole point of a new class (type) is new invariants [2]. If you need a new invariant, you make a new type. Sticking to this principle has helped me keep classes small and focused without really thinking about other things like "single responsibility". There are a few exceptions (eg you might need a new type to work with a particularly clunky API, like some Map Reduce ones), but it's really that simple.

As a bit of an aside, the worst code I have written hasn't been purely OO nor purely functional. It's been when I've mistakenly tried to add new ideas to existing code that break the paradigm.

[1] [https://caseymuratori.com/blog_0015](https://caseymuratori.com/blog_0015)

[2] [https://en.m.wikipedia.org/wiki/Class_invariant](https://en.m.wikipedia.org/wiki/Class_invariant)

<comment><USER28> I enjoyed reading Muratori's blog post you linked to - it's interesting to read the thought processes of a dev who writes so well.

But I don't get how "semantic compression" is any different from the more commonly termed DRY (Don't Repeat Yourself)?

<comment><USER27> I think DRY is a goal for the code and semantic compression (as described in the post) is a path towards that goal.

In Muratori's world they're following best practices like YAGNI and DRY and that allows you to refactor code at the right time

</comment></comment></comment><comment><USER16> It seems to me that the definition of OOP is so unclear as to make the term useless. It seems to me that lots of really bad ideas were spread under the guise of OOP. But now OOP advocates are shifting the definition so that OOP either excludes are doesn't explicitly advocate those bad ideas. I have to wonder: what exactly does OOP still advocate?

</comment><comment><USER29> There's this "bastard OOP" where "ellipse isa circle" going around which completely doesn't work in practice. But there's "true OOP" that follows SOLID principles (particularly LSP) that actually makes a lot of sense.

Unfortunately, this "bastard OOP" is the more popular variant, with many "bastard OOP" examples from the late 90s and early 00s running around textbooks, polluting the minds of student programmers at the time. This article does a good job poking fun at it, with "class Dog extends Animal", which is complete nonsense.

Actually learning SOLID principles, as well as the historical 80s style of OOP, goes a long way towards fixing problems.

</comment><comment><USER30> Might I suggest, when posting Medium premium stories to Hacker News it would be best to use the "Share Friend Link" link so people can avoid the pay wall (it doesn't affect author earnings). That seems to be what it is for: promotion outside of Medium itself. (This only works for the author so doesn't help others, but I wanted to mention it to raise awareness)

</comment><comment><USER31> IMHO if a programming philosophy leaves so much room for interpretation and misunderstanding, rants and counter-rants, needs evangelizing to the "dumb masses" what it "actually" means, and all of that hasn't been settled after more than half a century, then it has turned from a philosophy into a religion (or rather, a cult).

Just let it rest and move on. It's just a waste of time for everyone involved.

<comment><USER18> I think it's telling that I'm not able to tell whether you're talking about OOP or FP in this comment.

<comment><USER32> Is there controversy about what FP "actually means"?

<comment><USER33> The only real contention seems to be whether "functional programming language" should describe languages that merely facilitate functional programming (e.g. lisp), or only to those that enforce it (Haskell.)

Otherwise, whether or not a procedure is a function is about as clear cut as you can get. It either is or it isn't, it's not subjective.

<comment><AUTHOR> > whether or not a procedure is a function is about as clear cut as you can > get

Definitely.

If it returns a single value then it's a function. If it does not return a value, it's a procedure. (Pascal)

All procedures are functions (C)

All procedures and methods are functions (Swift)

A Function procedure is a series of Visual Basic statements enclosed by the Function and End Function statements. (Visual Basic)

...

<comment><USER33> I'm not sure if you mean this comment to be a joke, or....

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

</comment></comment></comment></comment></comment></comment><comment><USER34> After working in the Scala, which blurs the line between FP and OOP, daily for years, I feel like the choice to use OOP or not tends to boil down to how you'd prefer to solve the Expression Problem [1] for your domain. (if you follow the paradigm of "Functional Core, Imperative Shell")

If you're following this paradigm, for all your core objects they:

-Will be immutable, meaning calling methods on them will not change their state. (except for potentially some transparent optimizations, eg in-memory caching)

-Should not have methods that have side effects (i.e. purely functional)

If this is the case, then choosing whether your classes are objects or simple data structs is only a matter of code organization. ie do you want objects to carry around their methods with them, or have those functions live separately.

If you want to share method implementations among objects, you have the option of using inherited methods/types for a more OOP solution, or the typeclass pattern for a more FP solution. (Though the typeclass pattern has significant syntactical baggage in Scala)

[1] [https://wiki.c2.com/?ExpressionProblem](https://wiki.c2.com/?ExpressionProblem)

</comment><comment><USER35> In summary, "Object Oriented Programming is good when you don't orient your program around objects."

<comment><USER36> That sounds snarky. Not sure if that was intended or not, but regardless I read your comment as:

"OOP is good when you use the object oriented structure as a tool to organize your code and data to solve a problem, but not when you try to wrap your solution or your conception of the problem itself around OOP."

It's 2020, and after 50+ years of programming language research I think it's safe to say that there is no "one language to rule them all" or "one programming paradigm to rule them all." Different approaches seem to excel in different areas.

OOP seems to excel when the problem involves modeling systems with discrete parts and/or where there is a lot of state to manage. In other words I'd consider OOP for a "state-rich" problem domain. I am not saying this can only be done with OOP, just that it's a viable choice. There are multiple approaches to most problems.

I'd also say that bad code tends to develop different forms of badness under different paradigms. Bad OOP code is massively over-engineered, verbose, and slow. Bad procedural code is spaghetti. Bad functional code is impenetrable "write-only code" that can only be understood by its author (maybe). Bad code in multi-paradigm languages tends to have all these forms of badness.

<comment><USER35> I program video games; I would consider running a real-time simulation as a "state-rich" problem domain. And the constraints of running real-time simulations mean that some implementations are not acceptable. Things are not generally allowed to be slow if they can be done in a way that is fast.

Because of this, many game engines are built in a way that allows high throughput for processing the state of hundreds, perhaps thousands of entities in the world. Our guiding paradigm could be described as an entity-component system; another word used to describe it has been "data-oriented design." Here's a talk about it by the guy who was our engine director at the time[0]. It is not object oriented, and it seeks to unshackle itself from many of the issues with OOP as a guiding principal.

[0] [https://www.youtube.com/watch?v=rX0ItVEVjHc](https://www.youtube.com/watch?v=rX0ItVEVjHc)

<comment><USER37> Absolutely. And the kinds of data structures you get in an entity-component system are probably easier and more natural to use in a language such as Haskell than a typical OOP object-graph-of-mutating-objects would be. Not that anyone's programming their ECS in Haskell.

</comment></comment></comment></comment><comment><USER38> If there is anything in CS which should be renamed simply because people have completely incorrect assumptions from the name, it's OOP. Everyone has someone different they think about it, and almost none of it has anything to do with late-binding, encapsulation, or message passing.

</comment><comment><USER39> I believe OOP was successful largely because of Conway's law. OOP itself is a hierarchical (inheritance) type system that mirrors hierarchical social systems in business. It's very "top down" in its orientation, and also allows teams to tightly control the information they are dealing with.

Also, I didn't even read TFA. However, I think it's only fair since it's a medium post that requires login.

<comment><USER40> Also because of UIs.

</comment></comment><comment><USER41> I find the premise of this kind of article is flawed. Not because some of what the article says is incorrect, but because there is no such thing as OOP. OOPs as practised in Java, say, is very different from that in Rust (which the article mentions as having a "slimmer set of object-oriented features"). As a result trying to make generic statements about OOP doesn't really give much value IMO. You need to discuss specific well-defined programming practices to make progress.

I also don't think trying to define OOP is fruitful. One can resort to textualism, going back to Alan Kay's definition for example, but this is as bad in programming (how does this definition relate to current practice?) as it is in law.

<comment><USER15> Ruby implements the Kay concepts under the hood, and erlang is arguably a rather faithful implementation of Kay objects (though the code one writes doesn't semantically reflect that and it was developed independently for a completely different set of reasons - fault tolerance)

</comment></comment><comment><USER42> So you fix OOP by taking away the things that make OOP, OOP? That just sounds like procedural programming with extra steps.

Also, as an aside, I wouldn't call DRY a 'rock solid foundation' of programming. People do some weird contortions to make code DRY that end up causing my harm then good. Separations of Concerns is far more important. DRY is fine when applied within the scope of a feature, but not cross features. Otherwise you end up playing wack-a-mole when you fix a bug in one place only to make a new one somewhere else.

<comment><USER43> I knew a programmer who was all in on DRY and it was the heart of many stupid debates. Not only did result in a crazy inheritance and dependency tree, there were tons of many useless functions. Like having "logger.log(obj.read_stream())" in a few places would be "WET" the API got cluttered clutter with crap like obj.read_and_log_stream()

</comment></comment><comment><USER44> I wish I could read this but it's hosted in Medium and no, I won't create an account.

Seriously why does anyone even publishes there?

In fact I'm already biased against the author just because of his choice. If he can't even bother not using Medium can I really trust he spent the time to think through what he wrote?

<comment><USER45> I think we should publish these articles on github as readme. Then people can even add stuff and fix typos.

</comment></comment><comment><USER46> OOP is a crazy academic-esque idea that happened to stick because it works at scale. When you have hundreds of programmers working on a codebase, it's useful to constrain people with UML diagrams and rigid hierarchy. Otherwise, cowboy coders hack up something the other 90% of coders can't understand. This is why languages like Scala and Haskell haven't taken off outside of a few small-team-focused niches, like data science.

<comment><USER47> > OOP is a crazy academic-esque idea that happened to stick because it works > at scale.

I suppose it's weird to be young enough that you're first exposure to OOP is it being taught in an academic environment. It must make it seem like it was dreamed up like some kind of formalism and spewed into your brain.

But before OOP languages and everything that you describe, people using plain old procedural languages were already coding in an OOP style because it's obviously beneficial. Languages later came along to formalize patterns that people had used for years. For a more modern example you just have to look at the Linux kernel which includes a lot of OOP principles even though it's all just C.

<comment><USER46> True, a lot of OOP is stuff that you might develop on your own, if you were writing a lot of code back in the procedural days. But computer science has been with us since the beginning of computers, and certainly OOP as we have it today, with all of it's formalism, probably started back then in computer research institutions like MIT and Stanford.

</comment></comment></comment><comment><USER48> Usually when I see people rant against OOP, they're not ranting in favor of FP (or even better, in favor of something like Scala that combines OOP and FP) but rather in favor of a return to procedural/top-down programming. There are very good reasons that procedural programming was abandoned a long time ago and the need for global variables to make it work is one of the big ones.

<comment><USER49> > There are very good reasons that procedural programming was abandoned a long > time ago and the need for global variables to make it work is one of the big > ones.

Procedural programming does not, at all, require global variables to make it work.

I'm not a big fan of procedural programming at scale because it almost always seems to assume mutability (by default) and shared state when dealing with concurrency, but let's set those aside.

You use structures to contain what a naive programmer (or a prototype) would use global state for. Instead of:

      player_t current_turn; // a global

You do:

      struct game_state {
        player_t current_turn;
      }

And pass that _game_state_ value or reference around. The global state can easily be minimized or eliminated from most procedural programs. I've done this quite often as part of improving older programs.

<comment><USER50> That's basically a hand-rolled implementation of a state monad that supports real mutability. The Haskell equivalent is the ST monad.

While it's possible to do this kind of thing, it's busywork that properly designed programming languages are perfectly capable of handling well on our behalf.

<comment><USER48> I had the same thought: he's doing OOP without using the "class" keyword. Well-written C code is actually very object-oriented this way, it just doesn't take advantage of the syntactic sugar of C++.

<comment><USER51> This is a common misunderstanding. Structural programming like this is clearly similar to what we think of as OO. But it existed before OO and is still heavily practiced in non-OO languages such as C.

The main feature that OO added to this was dynamic function dispatch via inheritance. The specific function that gets called at runtime depends on the type of the struct.

Inheritance has proven powerful but often results in confusing code. The development of interface-based (non-inheritance) dynamic dispatch in COM and Java, and later embraced by Go and Rust, shows that we can get what is arguably the primary benefit of OO with a flat structural approach.

<comment><USER48> ... and this inevitable pedantry is why I thought twice about replying to OP.

<comment><USER51> It's not pedantic. If you're not doing dynamic dispatch, you aren't doing OO.

[https://blog.cleancoder.com/uncle- bob/2018/04/13/FPvsOO.html](https://blog.cleancoder.com/uncle- bob/2018/04/13/FPvsOO.html)

</comment></comment></comment></comment></comment></comment></comment><comment><USER52> OOP has served me well. It is a powerful concept. Problem is that people can misuse and abuse things.

<comment><USER47> It's the most successful programming paradigm in history. I feel like being anti-OOP is like being anti-vax. It's so successful and ubiquitous that it's success becomes invisible and so people only focus on the failures or misuse.

Complaining about OOP requires an entire object-oriented software stack to post your argument.

<comment><USER53> That doesn't make any sense. Being an anti-vaxxer is simply stupid, proven by real numbers and repeated experiments. Meanwhile, there are a lot of fair criticisms to OOP. Of course, a lot of them arise due to the fact that the skill floor for software development is quite low nowadays, but then again if we were all that smart, we'd just write C and C++ at the speed of light for everything. P.S: Rewriting hackernews in a functional stack is trivial

<comment><USER47> There are plenty of potential side-effects for vaccines as well. The last time I had one, I had a relatively unpleasant reaction.

So I'm not saying that there aren't fair criticisms of object-oriented programming. But "the case against OOP" is not proven by real numbers and repeated experiments. It's the most successful programming paradigm in history. The evidence for the success of OOP is more overwhelming than for any vaccine. Yet we're stilling debating boogeyman like mercury in vaccines and inheritance in OOP.

Re-writing hackernews in a functional stack might be trivial. But what about the web browser, the GUI environment, the OS kernel? OOP based software stacks are everywhere. And there is no need to re-write anything because it all works fine.

<comment><USER54> That it's successful doesn't mean it's also a good idea. To quote Dennis Ritchy: "C is quirky, flawed, and an enormous success". I feel this could probably be paraphrased to OOP as well.

OOP isn't super terrible, but it does mix some good ideas with bad ones. Newer languages tend to not be fully "OOP" but do include some of the better ideas from it. OOP isn't the end-goal of programming, it's a stepping stone.

Same applies to functional programming by the way; a lot of non-functional languages include various features pioneered in functional programming languages.

<comment><USER47> > That it's successful doesn't mean it's also a good idea.

No, but success brings out nothing but contrarians. You don't get an article on hacker news saying everything is fine and working well even if that is the reality.

You can't make money selling alternative medicine by claiming that medicine works. Newer languages, in my opinion, are going backwards in a lot of ways out of fear of ideas that shouldn't be feared.

<comment><USER55> Obviously being against the common trend is always going to get more attention, but it makes no sense to assume that those people are wrong strictly because of that.

The fact that vaccines are widely used doesn't make anti-vax stupid. Anti-vax is stupid, because a lot of real research has gone into vaccines, and they really do work. The arguments anti-vaxers use are not based on reality, and can easily be proven wrong. The same can NOT be said about programming paradigms.

There is no proof that OOP produces more elegant, simpler, higher quality software with smaller programming effort than other paradigms. OOP isn't proven to work; it's proven to be an attractive choise

<comment><USER47> Isn't there proof? I mean there are _plenty_ of alternative programming paradigms -- some that have been around since the 60's and still promoted as alternatives today. Where is that success to compare?

Show me that an alternative to OOP is statically more successful and I'll switch tomorrow.

It seems like you really want it out to be merely popularity rather than being simply successful. That's not a rational position.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER56> There is no 'case' to be made against any paradigm. Different hats for different jobs.

<comment> yobi-ponti It has become popular to hate OOP so now people find every opportunity to discredit it. But yeah, every tool has a purpose. Don't like it in your workplace? Make a fact based case against it and do something about it.

</comment></comment><comment><USER57> PSA: If you want people to read your tech posts, don't write them on Medium. Medium requires logging in to view their content now, so like Pinterest, Quora, etc they are dead to me. And I know I'm not alone.

<comment><USER58> Given that the post is ranked relatively highly on Hacker News at the moment, it would appear that there are people who are still reading their tech post even though it is on Medium :)

<comment><USER59> I paid for Medium because I was reading so much good tech content there.

</comment></comment></comment><comment><USER60> The best thing I can say about OOP is that it allows for private state that only certain logic is allowed to know about. In some cases, you just really need that.

But I think the biggest problem with OOP is that it encourages a spirit of "eager complication". Take getters/setters as a classic example. Occasionally that pattern can be useful, but standard practice in Java is to _never ever_ create a simple public field. You _always_ create a private field, with a getter and setter, under the assumption that later you'll need to put some special logic in there.

We can't just create some plain functions, we need a Helper Class™. We can't just pass in a function's dependencies as arguments, we need Dependency Injection™. We can't just use a union type, we need a Visitor Pattern™.

I think some of these habits were built in a world before certain simplifying language features were widely available (union types in particular are only recently entering the mainstream). Programmers were traumatized by the limitations of Java and the ensuing complexity of their projects, causing them to enter future projects already bracing for the worst. Simplicity is assumed to be impossible, so you just go ahead and barricade the windows with some up- front complexity in hopes of flattening the exponential complexity curve down the line.

But the world has changed since then. There's a reason multi-paradigm languages are becoming so popular: because implementing real projects without creating out-of-control complexity requires having a wide range of tools at your disposal. In this new world, I think it's really important that some of these patterns get unlearned.

I'll leave you with this Paul Graham post from 2002 about OOP Design Patterns: [http://www.paulgraham.com/icad.html](http://www.paulgraham.com/icad.html)

> When I see patterns in my programs, I consider it a sign of trouble. The > shape of a program should reflect only the problem it needs to solve. Any > other regularity in the code is a sign, to me at least, that I'm using > abstractions that aren't powerful enough-- often that I'm generating by hand > the expansions of some macro that I need to write.

<comment><USER61> > The best thing I can say about OOP is that it allows for private state that > only certain logic is allowed to know about.

Local variables in methods are private and encapsulated. Languages had this before and after OO. Plus modules/namespaces/headers/etc.

OO languages added classes with fields, which are variables _shared among methods_ (whether they are declared with the private keyword or not.) The opposite of private/encapsulated.

If the 'private' keyword made a class's state sufficiently private I wouldn't need to worry about the difference between StringBuilder and StringBuffer, and I could pass java.util.Date without fear.

<comment><USER60> > OO languages added classes with fields, which are variables shared among > methods

That's not true. Structs and other mutable, structured data objects existed long before OOP. The differentiating factor was that no functions/methods were able to have varying levels of access to those fields; everything was public all the time.

> The opposite of private/encapsulated.

I don't think that's fair. OOP added "private variables that survive past the end of a function", if you want to get pedantic, but I think there's plenty of added value to having this functionality in your toolbox. And yes, technically closures can accomplish the same thing, but most mainstream languages did not have them yet when OOP was on the rise and even then, using them to achieve "lasting, private, mutable state" is, IMO, one of the few cases where the OOP way of doing things is actually more ergonomic and expressive of intent than the functional way. OOP is fundamentally about state, so when you really have to manage some state, it is often the right way to do things. The problem comes when you assume preemptively that you need state in the first place.

<comment><USER61> I'm saying you can have private mutable state if you stick to method variables. If you take a method variable and promote it to a field (private or not), or return it via a public method, you have made it more public - that's what I meant by "The opposite of private/encapsulated".

</comment></comment></comment></comment><comment><USER62> OOP is basically a blank canvas. It is always up to the artist to bring structure and reason to it. There is never one perfect answer for every case.

That said, there are some general policies that seem to make sense, namely the alignment of your object models with the shape of the business problem you are trying to solve. Perhaps your problem domain has the idea of a Customer, but there are really 3 flavors of customer. Many developers would automatically do base/derived here, but in some cases it makes sense to have these as entirely distinct types. Making this determination one way or another is at the very core of the art of software engineering. These decisions have higher order impacts that are impossible to anticipate or understand until you personally go through hell a few times.

Proper management of state is another major concern. In context of OOP, I find it best to centralize state along independent verticals of business functionality. Models like CustomerCheckoutState, UserSignupState, etc. When you centralize all of the state you wish to mutate as part of one business activity into one object instance, it becomes really easy to manage. E.g. serialize your state to database and back every time the user takes an action. You can also leverage the scoped injection functionality available in many DI frameworks to pass a per-user-action state instance into all relevant business services and UI components.

If you can keep your business fact modeling & stateful domains under control, the rest will likely fall into place.

</comment><comment><USER63> People love to hate on inheritance and suggest that there are no cases where its use is warranted. But inheritance absolutely is used, and successfully, in many frameworks. For example GUI frameworks [1] [2] or server-side web frameworks [3]. People have been writing code in frameworks like this for ages and as far as I can see they worked well.

Including key use cases such as being able to use the provided components "out of the box" and also being able to customize them, i.e. "like this component, but with these differences".

[1] [https://docs.oracle.com/javase/8/javafx/api/javafx/scene/con...](https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/Button.html)

[2] [https://developer.apple.com/documentation/appkit/nsbutton](https://developer.apple.com/documentation/appkit/nsbutton)

[3] [https://ci.apache.org/projects/wicket/apidocs/org/apache/wic...](https://ci.apache.org/projects/wicket/apidocs/org/apache/wicket/markup/html/form/Button.html)

<comment><USER64> Just because there's examples of successful usages doesn't necessarily mean that it's "good" or even a model for how we do things moving forward. Picking that specific example [NS|UI]Button, they're dreadful to work with. Honestly. Customizing them is difficult to impossible. It's often easier to just _compose_ them into a different container because the extension points couldn't possibly be designed in a way that gives you all the flexibility you need.

Yes, it works, and yes, there are great systems built with OOP patterns. The same can be said of C++. That doesn't mean they're good, or we should choose it as our tool moving forward.

</comment></comment><comment><USER65> One point I've made occasionally is that few languages support backpointers well. When B is a member of A, B often needs a back reference to A. Rust does that badly, because it doesn't fit well with the ownership semantics. C++ with move semantics does that badly, for much the same reason The same thing applies when A allocates and owns B. It's hard to get a clean, safe, reference back to A that cannot result in a dangling pointer, especially during deallocation.

Object inheritance does that well. Finding the parent is easy and is done in a consistent way. The deletion process is done in a consistent, if not ideal, way. That's useful.

If we had proper syntax and semantics for getting a reference back to the owning object, one of the use cases for inheritance would go away. Languages have "this" or "self", for accessing the current object, but lack "owner", for accessing the owning object. If a language offers single ownership, you should be able to find the owner easily.

(Multiple inheritance is just a mess. Most, if not all, of the use cases for that are better done in other ways.)

</comment><comment><USER66> There is a lot that is problematic with OO, especially if it is adhered to with dogma. The worst idea and the one I've experienced most issue with, is the `extends` keyword in Java, and more generally, the concept of inheritance.

Inheritance is terribly overused, and tends to lead to code spaghetti and testing nightmares. Hierarchy is a mental trick we pull on ourselves to make sense of the world, but it rarely works out nicely in systems.

</comment><comment><USER67> I think React's decision, when faced with a desire to track state alongside code, to partially reimplement objects inside of functions rather than just saying "know what, this new feature requires class syntax, deal with it" (and in fact excluding class-style syntax from the new features) is the perfect sign of where the functions-vs-OO pendulum is.

</comment><comment><USER68> It's been forever that I have used Inheritance in OOP. Perhaps Python has spoilt me, but 99% of my thought process automatically pivots to composition when thinking in terms of OOP.

And more towards how to name libraries, what functionality to put functions into and how to name my files.

OOP is just a tool to organize code. People give it too much thought sometimes. I did too.

</comment><comment><USER69> I have difficulty maintaining a stance in the OOP vs. FP debate. Like, all I see in my day-to-day is OOP, so I know what good, production-ready OOP looks like, but I've never an equivalent for FP. Would be nice to see a before/after article, i.e. an OOP app refactored into FP, talking about why the latter is better.

</comment><comment><USER70> I respectfully disagree that frameworks and stdlibs for languages like Java and .Net are better due to use of Inheritance. In fact I struggle to come up with a single occasion where use of Inheritance was not an Antipattern. The exception I suppose is when you have no other way to do polymorphic interfaces.

<comment><USER47> Lots of things in software development have an is-a relationship. The only time inheritance is an antipattern is when it's used for code-reuse and it isn't modeling an is-a relationship.

Once you get to application code there aren't a lot of is-a relationships but inside operating systems, libraries, and frameworks it does come up legitimately.

<comment><USER70> Is-a relationships are best handled by interfaces. If you don't have those and only have inheritance then that is the exception I mentioned above. In those cases I would argue that the base class should be composed entirely of abstract methods and the depth of the inheritance hierarchy should be no greater than 1.

<comment><USER47> If you have something that _is_ something else in almost every way except for one or twos details inheritance is far superior than interfaces.

The other benefit of inheritance, that often goes unmentioned, is the ability to fix bugs in other products. I've had to inherit from some library/framework class to fix a bug in that technology -- it might be a rare situation but it's absolutely invaluable to have that option.

<comment><USER70> I'll have to take your word for it that such things exist but experience so far has taught me that:

1\. When I have something that is something else with minor modifications that my and everyone else's lives will almost always be better when if I solve the reuse issues with some composition and the is-a problem with an interface.

2\. That when I inherit from a class I don't control to fix a bug in that class the fix is both _very_ fragile and usually _very_ short lived. Either way I created a problem for myself later on down the line.

I don't disagree that sometimes the framework or library you are using give you no other choice than inheritance. In those cases using inheritance is your only and therefore best option. However I don't consider the framework to be better for it. I consider the framework to worse off for it.

<comment><USER47> > if I solve the reuse issues with some composition and the is-a problem with > an interface.

I'm not sure how that's better -- you're just implementing inheritance with more steps.

> is both very fragile and usually very short lived.

It is and I know you'd make that point but it's better to be fragile and short lived than completely impossible. I have a least one of these hacks that was completely necessary that has been in place for years.

</comment></comment></comment></comment></comment></comment><comment><USER71> OOP is perhaps not the best abstraction for distributed computing where you want maximize data flow and minimize distributed state. The slowdown of Moores Law for a single core/node means performance improvements will distribute computing among a large number of such units.

</comment><comment><USER72> I've never really gotten the hate towards OOP. It's always logically made sense to me. It follows along the path of abstraction and encapsulation computers had been moving steadily towards. It just takes the concept of a function, packages it together with some kind of data, keeps the internal workings separate from the rest of the program and allows one to reuse or extend those small pieces.

It may not be the best way of abstracting above procedural programming, it's not suitable for everything, it's easy to use poorly, but it's there and it does have benefits and can exist peacefully along side other paradigms.

</comment><comment><USER73> A little off-topic, but when thinking about the reasoning behind OOP, in particular how it shows up in C++ and the C++-influences in other languages, I think it is worth looking at how large-scale C projects (OpenSSL, Gnome, etc.) organize their code: long prefixes in front of function names complex structs with lots of function pointers complicated macros for code generation

These directly relate to some of the core features of C++ like namespaces, virtual functions, and templates.

I think this perspective makes the differences between C++ style object orientation and Smalltalk style object orientation understandable.

</comment><comment><USER74> I still think procedural and OOP code requires 10-15 IQ points (for some theoretical "good" measurement of IQ) than FP.

Vocal proponents of languages will be on the more intelligent end of the spectrum to begin with, so this economic / structural "advantage" of OOP isn't as apparent, especially since such advocacies revolve around idealism and the hidden biases of it paying their bills.

<comment><USER75> IQ points less or more? I assume you mean OOP requires 10-15 IQ points less, but it is very hard to do OOP correctly so I don't think that's true.

<comment><USER74> Most OOP programmers aren't doing complex hierarchies or other modelling / design.

They're doing singleton service patterns in Spring Boot.

</comment></comment></comment><comment><USER76> OOP is so nebulous that there's no reason to critique it.

</comment><comment><USER77> Apart from Rich Hickey's "Simple Made Easy" I think Joe Armstrong summed-up best the inherent problems with OOP as it exists in the most popular languages: "The problem with object-oriented languages is they've got all this implicit environment they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

</comment><comment><USER28> Something I'd really love to see is a GitHub repo containing different projects written in both an OOP style (e.g. with C# or Java) and an FP style (e.g. with F#, Scala or Python).

F# and Scala also have both OOP and FP features - something else nice to see would be the same project written in both OOP and FP styles in the same language.

Anyone have any links to repos or blog posts along these lines?

</comment><comment><USER78> If this article is to be taken at face value, the case against OOP is understated...

The author is in desperate need of an actual understanding of OOP, an understand of what OOP looks like in practice, and the most basic understanding of other programming paradigms (or at least a rudimentary understanding of what's meant by procedural, structural and functional programming.)

</comment><comment><USER79> FWIW I've been a python and javascript dev for a long time. I've spent this year learning Rust and I'm kind of in love with the whole "it's just a struct and here are some associated functions" thing. It feels so simple and clear.

I also really liked C#'s "single inheritance plus interfaces". That was also an eye opening moment.

</comment><comment><USER80> I recently wrote an article bashing OOP, seems like I have to rethink it now :P [https://collectednotes.com/francobatta/a-case-against- java-o...](https://collectednotes.com/francobatta/a-case-against-java-or-bad- oop)

</comment><comment><USER81> Object-Oriented Programming is Bad (2016)

[https://news.ycombinator.com/item?id=19407599](https://news.ycombinator.com/item?id=19407599) (2019)

<comment><USER82> Just to mention, Brian Will also has a video called OO programming is good* [0]. I don't think we should take these literally, he presents what he things are some bad traits and good traits of OOP.

[0] [https://www.youtube.com/watch?v=0iyB0_qPvWk](https://www.youtube.com/watch?v=0iyB0_qPvWk)

</comment></comment><comment><USER83> As usual. People have criticism. Counter critics say get smarter. The problem is that we are dealing with largely unproven concepts. We have no facts, not even meaningful empiric insights. It is a battle of religions but it should be an academic challenge.

</comment><comment><USER84> Person, Woman, Man, Camera, TV: The Class Hierarchy

[https://www.youtube.com/watch?v=LhZyHIZpzoM](https://www.youtube.com/watch?v=LhZyHIZpzoM)</comment>


Toxins That Threaten Our Brains - <AUTHOR> http://www.theatlantic.com/features/archive/2014/03/the-toxins-that-threaten-our-brains/284466/ <comment><USER2> The problem with many of these is that, as in everything else, the dose makes the poison. Fluoride is a perfect example: too little and your bones are weak & tooth decay sets in easily, too much and you get fluoridosis. Just the right amount (which is a reasonably large range) and you're healthy.

Maganese is the same, it's an essential trace nutrient for pretty much all living things, and you'll die without it, but too much will kill you.

The most dangerous agricultural pesticides are the neonicotinoids, and they're used in organic farming. They tend to decay quickly, so if the food is properly managed and they're not applied too late they won't be found in the food.

Now, not everything that is dangerous is necessary. There's no benefit from eating mercury, for example, but there are always safe exposure levels. Some compounds bio-accumulate, so the safe exposure levels have to be set for a lifetime. Most organic mercury compounds are of this sort, and due to their extreme toxicity the safe exposure levels are very low.

<comment><USER3> Do you think the Chinese toxic waste, aka "manufactured sodium fluoride and byproducts" that is put in public water supplies resembles anything like the calcium fluoride that the body needs?

<comment><USER4> As groundwater courses over rocks, it picks up the compound Calcium Fluoride from those rocks. Once in the water, CaF releases a certain amount of fluoride ions into the water. These F ions are to what is commonly referred as being "naturally occurring fluoride".

The compound most frequently utilized to fluoridate water systems is hydrofluorosilic acid (HFA). HFA is derived from naturally occurring phosphorite rock as a co-product of the process from which the other co- product, phosphoric acid, is derived.

Once HFA is added to water, the pH of that water (~7) causes the immediate and complete hydrolysis (dissociation) of the HFA. The products of this hydrolysis are fluoride ions, identical to those which already exist in water as a result of release from CaF, and trace contaminants in barely detectable, minuscule amounts that fall far below EPA mandated maximum levels of safety. After this point HFA no longer exists in that water. It does not reach the tap. It is not ingested. It is therefore of no concern, whatsoever.

EPA drinking water quality standards begin at the tap, as this is the water which is ingested and/or otherwise utilized. Water from the tap must meet the stringent Standard 60 certification requirements of the National Sanitary Foundation, as mandated by the EPA, or it is not allowed. Thus, whether additives come from the US, Mexico, China, or the moon, is irrelevant. If water in which these additives are incorporated does not meet NSF certification requirements at the tap, it is not allowed. It's as simple as that.

A fluoride ion is a fluoride ion, regardless of whether the source compound is CaF, NaF, HFA, or any other. Elementary chemistry.

Fluoridated water easily meets all EPA mandated NSF certification requirements. A complete listing of the minuscule trace contaminants in fluoridated water, in their precise amounts is readily available to anyone, on the NSF website:

[http://www.nsf.org/newsroom/nsf-fact-sheet-on- fluoridation-c...](http://www.nsf.org/newsroom/nsf-fact-sheet-on-fluoridation- chemicals)

A complete listing of the contents of any local public water system are readily available to anyone from the annual water quality report of the utilities departments of the respective localities.

Steven D. Slott, DDS

<comment><USER3> From the PDF:

"NSF certifies three basic products in the fluoridation category: 1\. Fluorosilicic Acid (aka Fluosilicic Acid or Hydrofluosilicic Acid) 2\. Sodium Fluorosilicate (aka Sodium Silicofluoride) 3\. Sodium Fluoride All three product types dissociate in water to form sodium, fluoride, and in the case of the first two, silicate ions."

"The NSF toxicology review for a water treatment product considers all chemical ingredients in the product, as well as the manufacturing process, processing aids, and other factors that have an impact on the chemicals attributable to the products present in the finished drinking water. The identified chemicals of interest are subsequently evaluated during testing of the product.... These tanker trucks, transfer terminals and rail cars are potential sources of contamination. Therefore, NSF also inspects, samples, tests, and certifies products at rail transfer and storage depots...... In summary, the majority of fluoridation products as a class, based on NSF test results, do not contribute measurable amounts of arsenic, lead, other heavy metals, or radionuclides to the drinking water."

"The identified chemicals of interest are subsequently evaluated during testing of the product. For example, fluosilicic acid is produced by adding sulfuric acid to phosphate ore."

In the table presented, the current chemicals tested for are: Antimony, Arsenic, Barium, Beryllium, Cadmium, Chromium, Copper, Lead, Mercury, Radionuclides – alpha pCi/L, Radionuclides – beta mrem/yr, Selenium, Thallium.

What else is going to be in the phosphate ore that could come into the water? To me that test range looks too small. How pure is the sulfuric acid used to dissolve the phosphate? Also, what sort of byproducts are going to occur as the fluoride additives and sulfuric acid corrode their containers?

I don't live in the USA but these are the sort of questions I'd be asking, and as mentioned elsewhere, I'd want to see realtime and comprehensive information on the additives used - and alerts if something strange or unwanted is found. I think it's going to be more difficult to test tap water itself for such additives, so I'd suggest testing and displaying the actual additives before placed in the water - and from there it's going to be straightforward to determine concentrations. Personally, I wouldn't be accepting the NSF/ANSI Standard 60 as it currently stands... from how I perceive it. It was devised in 1988. This sort of extra testing would have to come on top of it, likely on a small scale by individual plants interested.

Finally, I would start thinking about testing air quality... not final air quality... but the actual additives used in chemtrails in a realtime manner, just like with water additives. You can argue about if chemtrails are real or not, I am just asking... "whatever is coming out the back of those planes... I want to know what it contains, because I am inhaling it."

<comment><USER4> Again, water at the tap is that which is ingested and otherwise utilized, thus the only water of relevance. This is why NSF Standard 60 certification requirements begin with water at the tap. It makes no difference what additives are used, the process by which these additives are produced, or the location from where they are obtained. If the water at the tap does not meet Standard 60 certification requirements, it is not allowed.

If you want to argue with the US EPA about its standards and procedures, feel free. I, personally, have survived just fine with them for 61 years.

Steven D. Slott, DDS

<comment><USER3> tl;dr - the bottleneck to alleviating brain toxins right now is informational

To me standard 60 is insufficient. I would be happy to pay for extra testing to my water, or rather the additives used. I think many people would.

While we're on the topic of toxins for brain, I would also be happy to know more about the emf generated by smart meters, cell phone towers, and wireless equipment. But mainly smart meters. If I had one installed, I'd want very accurate readings of what is being emitted and when. Also vaccines.

The message is simple: "government/corporation: feel free to do whatever you want to my air, food, water, emf spectrum and blood that you believe or purport to be in my best interests (you already do).... but I want to know precisely and accurately what it is you're doing, changing and adding to it. I can be driven to do this for no reason, any reason, false reasons or accurate reasons. And whatever reason that may be, you'll have to accept it because you are the one tampering with long-standing internal and external ecosytems to which mine (and others') body and mind have adapted over millenia."

From there, I would either want the choice to opt-out, and if I cannot or it is not possible, then I can look for legal, political or economic (boycott) routes to address the problems I find, which could include the need for even greater informational transparency than the ones being offered.

<comment><USER4> By all means, have your water tested right down to the subatomic level if you so desire.

Obsessive demands to search for problems in the absence of valid evidence that any exist, are an integral aspect of antifluoridationist tactics. However, it is not justification to deny entire populations the benefits of a valuable public health initiative such as water fluoridation.

You have just exemplified the true root of antifluoridationist objections dating back 69 years to the very beginning of the initiative. It is not based in science, but in ideological distrust of government and authority. Thus, no matter how much valid science is presented to antifluoridationists, as long as it does not agree with this ideology, as it never will, it will be rejected by them.

Steven D. Slott, DDS

<comment><USER3> Who comes to HN and starts signing their name and credentials? Steven does.

<comment><USER5> That is a mean thing to say to a newcomer who wouldn't necessarily know that signing comments isn't customary here. Please don't be mean.

<comment><USER4> It is of no concern to me whether it is customary to post one's name, or not. I do not hide behind pseudonyms. Neither do I care whether people view my DDS as a positive, negative, or nothing. I post it as a matter of full disclosure of my perspective.

It is simply a matter of accountability. Antifluoridations flood the internet with patently false, misleading information, and an endless barrage of unsubstantiated claims, all while hiding behind pseudonyms. I make no claims of being an expert, and don't ask people to trust me on this issue. I simply urge them to trust the peer-reviewed science obtained from legitimate, authoritative sources, instead of junk found on antifluoridationist websites. I can provide evidence to support my claims and do not fear being held accountable to do so. Contrast this to antifluoridationists posting blatant misinformation for which they can provide no valid evidence, while hiding behind pseudonyms and insidiously attempting to steer readers to the filtered and edited nonsense on their biased little websites.

Steven D. Slott, DDS

<comment><USER6> The HN guidelines [0] ask you not to sign your comments. Your username is already on your comment, and people can click your username to see any further information you include. If it's directly relevant to the discussion at hand, you might say it once in the form "source: I'm a [whatever]", but please don't repeat it. Otherwise, it's just clutter.

[0] [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER4> If HN does not approve of my comments, it is certainly free not to post them. However, I do not hide behind pseudonyms.

Steven D. Slott, DDS

<comment><USER7> Good comments.

You can edit your profile to put information there that you would normally put in your signature. For example, [https://news.ycombinator.com/user?id=wglb](https://news.ycombinator.com/user?id=wglb) for mine.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> A long but very shallow article. \- interviewed authors of paper that used the phrase, "silent pandemic" when claiming widespread behavioural and cognitive problems as a result of 12 compounds. Evidence presented in the article itself? "Rates of diagnosis of [autism] and ADHD are increasing..." [diagnosis is not necessarily preponderance], an increase in "subclinical decrements in brain function" [as measured how?] , and "genetic factors account for no more than 30-40% of brain development disorders" [based on what exactly?] From this thin stuff the authors then get plenty of column space to expound on their opinions. Re: the IQ experiments. If Bellinger's own lead-IQ model is correct [from the linked Environ Health Perspect. Jul 2005; 113(7): 894–89] , a decrease in blood lead concentration from >10 ug/kg [1970's] to 1.8 ug/kg [2009] should have resulted in 3 point increase in IQ scores. Where's any discussion of this? \- FMRI reveals effects of methyl mercury in 3 [?] adolescents. How can you possibly determine loss of IQ points due to methyl mercury exposure on this set while controlling for other factors? Talk about small sample size. -The article asks, "Impressive as all this research investment is, the larger question remains: Why are we looking at these hazards now—instead of before we introduced these chemicals into the world?" 80k chemicals mentioned as being on "the market" although what this means isn't specified. "It would cost $5 million and 5 years per chemical to run the full battery of tests" according to quoted researcher. 400 billion dollars if done on the full set. 1) Who pays? 2) Why would any chemical company have a research presence in the USA if their product had a several year lead time for rollout due to testing requirements?

<comment><USER9> _If Bellinger 's own lead-IQ model is correct...decrease in blood lead concentration..should have resulted in a 3 point increase in IQ scores_

This is an interesting point. I haven't seen an explanation for the Flynn Effect continuing as blood lead levels rose through the 20th century. If IQ levels would have risen _faster_ without lead then the increases should have been even more substantial since lead levels dropped.

</comment></comment><comment><USER10> Could be safe in agricultural use even if it wasn't safe enough in household use. Best not to throw the baby out with the bathwater.

Cheap food with /almost no/ risk of developing a condition or losing functions of the body is better than expensive food with a marginal reduction in risk.

Even if we were "missing out on" 41,000,000 IQ points(this alone sounds arbitrary and unprovable) in the U.S., that would be 0.2 IQ points roughly per person... I'm not even sure that's statistically significant by any definition.

Then again, maybe I'm just dead wrong about that and I need to shut up and hop on the hysteria bandwagon.

I certainly don't like that Dow conspired to suppress completed research, although it is also abhorrible that people gave in to that pressure, probably through paltry bribes.

<comment><USER11> > Could be safe in agricultural use

Didn't we find that some pesticide(s) is/are (partially) responsible for bee colony collapse disorder?

<comment><USER12> I don't think so, since many of the pesticides being blamed have been in use long before CCD appeared.

<comment><USER13> Neonicotinoids, the class of chemical pesticides most commonly blamed for CCD, were introduced into widespread use around the time CCD appeared. I don't think anybody has definitely proven causation (and see the various posts, even today, about problems in deriving causation from correlation). But there appears to be neurobiological evidence for _some_ link between the way the pesticides work and the way bees behave. As far as likely suspects for the cause of CCD go, it's high on the list.

</comment></comment></comment></comment><comment><USER14> _Frty-one million IQ points. That's what Dr. David Bellinger determined Americans have collectively forfeited as a result of exposure to lead, mercury, and organophosphate pesticides. "_

Okay, I bailed. It's rare that a lede is so bad that I'll bail -- usually I just don't click on stuff that looks like crap. But this looked interesting.

Why did I bail? First, IQ points are not cumulative. It's not like you can add them all up and get anything at all useful. It's not even like we could come to a reasonable agreement that IQ points are a useful metric, but I'll just let that go.

More to the point, the question isn't society overall, it's individual choice. Would you trade the loss of 2 or 3 IQ points for better food, a modern world, access to transportation, and so on? I would -- in a heartbeat. It wouldn't even be a tough decision to make. Live to 80 in a modern world full of modern conveniences while being a tiny bit less bright? Count me in.

So I went into scan mode for the rest of the article. For all I know, it looked good. But I'm left believing what I already believe: Yes, there probably are some statistical clusters that warrant societal intervention. Perhaps poor people living in a lead-infested housing project next to a chemical factory. But to use terms like "Silent Pandemic" is to be terribly irresponsible. Alarmist even. It does not describe the problem in enough detail for the reader to know what to do about it, and it's just a cry for attention.

Sorry. No so much.

</comment><comment><USER15> Hm. I'm only going to talk about fluoride, because it's the easiest to pick on: yes, China does have dangerously high levels of fluoride in groundwater in some areas. Those levels are much higher than the levels added to water in Western countries, and, in fact, Western countries already implement policies to _limit_ the concentration of fluoride that makes it into drinking water (so in, e.g., Colorado Springs, fluoride is removed):

[http://ehp.niehs.nih.gov/1104912/](http://ehp.niehs.nih.gov/1104912/)

>Opportunities for epidemiological studies depend on the existence of comparable population groups exposed to different levels of fluoride from drinking water. Such circumstances are difficult to find in many industrialized countries, because fluoride concentrations in community water are usually no higher than 1 mg/L, _even when fluoride is added to water supplies as a public health measure to reduce tooth decay._ [emphasis added]

Additionally, as even this week's Chicken Little proclaims:

> "Not at all," Landrigan said. "I think it's very good to have in > toothpaste."

\--- of course! Do you really think that nobody studied the addition of fluoride to toothpaste when it was first adopted?

[http://onlinelibrary.wiley.com/doi/10.1002/14651858.CD002278...](http://onlinelibrary.wiley.com/doi/10.1002/14651858.CD002278/abstract)

> "Seventy-four studies were included."

The end. Fluoride is not a routine risk to neural health in developed countries.

<comment><USER16> Not saying that fluoride is necessarily bad, but brushing and spitting toothpaste is different from _drinking_ gallons of fluoridated water each week.

<comment><USER17> That statement is meaningless unless you know how much fluoride is in the water

</comment></comment></comment><comment><USER18> This article rambled and jumped around and was too sensationalistic for my taste.

Not that it didn't contain some good points but it was unduly alarmist in tone and kept lumping all chemicals in one class. Lead is a different case from fluoride is a different case from agricultural pesticides (themselves many different classes of compounds...some more harmful than others).

Certainly there are toxins in our environment and this is an issue. Well known toxins like lead have no place in our biological system. But this is not a new realization. Measures have been taken to address lead, maybe more are needed, I don't know, but people can't freely disperse lead in the environment anymore. (Except NRA members of course).

The article contained a dash of conspiracy for good measure and appeared about as scientific as a 1980's anti-recreational drug commercial...."This is your brain on fluoride!". Exactly the same type of hysteria (albeit from a different political spectrum) as well.

Here is reality...we can't live this lifestyle without chemicals so there will be some trade offs. That's the bottom line. Want to use plastic and drive a car and buy raspberry pi's? Then there are going to be some toxins. Maybe things have been too lax and more research and regulation should occur. No argument. But all chemicals and all pesticides are not evil and we are going to need some for the foreseeable future.

</comment><comment><USER19> Thanks for sharing, this reminded me of an article[1] in a similar vein.

Excerpt: "Today, a novel class of illnesses is on the rise, and neither theory sufficiently explains it. TILT shows how a person can have a toxic exposure and never recover. Exposures trigger a bewildering array of symptoms that many people never trace back to synthetic chemicals in their daily life. They may experience cardiac and neurological abnormalities, headaches, flu-like symptoms, bladder dysfunction, asthma, depression, anxiety, pain, cognitive dysfunction, and sleep disorders"

[1]: [http://nautil.us/issue/15/turbulence/is-the-world-making- you...](http://nautil.us/issue/15/turbulence/is-the-world-making-you-sick)

<comment><USER20> You don't actually believe that pseudo science bullshit, do you? Please tell me you jest / troll. That article / interview is just full of half-assed science and made up bullshit.

<comment><USER19> From the nautilus article: She calls her theory "TILT," short for Toxicant Induced Loss of Tolerance.

TILT posits that a surprising range of today's most common chronic conditions are linked to daily exposure to very low doses of synthetic chemicals that have been in mass production since World War II. These include organophosphate pesticides, flame-retardants, formaldehyde, benzene, and tens of thousands of other chemicals."

Given this is HN, I would like to believe that you understand what a 'theory' is. I found that it was an interesting theory and nicely parallels with the article from the OP. Whether I believe the theory or not is irrelevant. I'm sharing knowledge cause it's fascinating.

<comment><USER20> It's not sharing knowledge it's spreading "theories" that are well known to be incorrect. Spreading pseudo science, regardless of how much you believe in it, is not a good thing.

These people are great at constructing a narrative that everyone would love to believe. Wouldn't it be great if this single thing was the cause of ALL of these aliments? Unfortunately life doesn't work that way but our minds are great at drawing invalid correlations.

<comment><USER19> take your pick:

knowl·edge ˈnälij ; noun 1.facts, information, and skills acquired by a person through experience or education; the theoretical or practical understanding of a subject.

2\. awareness or familiarity gained by experience of a fact or situation. "the program had been developed without his knowledge" synonyms: awareness, consciousness, realization, cognition, apprehension, perception, appreciation

Prove the article wrong if you are so compelled to do so. Part of the reason I share things on HN is for the discussion it creates, which expands my knowledge so I can form educated opinions. I appreciate this aspect of HN, it's why I keep coming back so please, inform me with some links, resources, or research and relieve my of my pseudo-scientific ignorance or stop telling me I'm wrong.

</comment></comment></comment></comment></comment><comment><USER21> Dow knowingly spreads poison, pays a fine, withdraws a product from household use, and that product continues to be used in farming? I had to stop reading.

<comment><USER22> ...And greenwash them away by grandiose ad campaigns such as "human element" where they portray themselves as a part of the (humanitarian) solution to potable water.

If they really cared a tiddly bit about devastating human costs caused by their wholly owned subsidiaries, they would have at least spent a miniscule fraction of what they spend on such ad campaigns to actually clean up their mess.

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

The particular example I have in mind is the Bhopal disaster, and contamination of Bhopal's groundwater caused by the same company but prior to the disaster. Notably they dont shy away from claiming any of the assets of their wholly owned subsidiary Union Carbide, but none of their liabilities. 20,000 have died because of these causes, more have been disabled beyond the capacity to earn livelihood wages, but they do zilch about it. Well, not quite correct, they spend billions in ad campaigns, sponsor olympics and get a free pass. While Chernobyl rules the roost in western media as a prominent example of an industrial disaster (fits the narrative of "look how bad Russian technology is" very nicely) few if at all recall Bhopal although it is a tragedy of as epic proportions, I would argue that its (official) human cost was more.

I have not started on Nemagon or dioxins.

<comment><USER23> According to the Wikipedia article you linked to, 3787 deaths are confirmed as resulting from the incident and 16000 deaths are claimed in total. The page does not support the assertion that the disaster was responsible for 20000 deaths.

From the same page: "In 1994, UCC sold its stake in UCIL to Eveready Industries India Limited... Eveready Industries India, Limited, ended cleanup on the site in 1998, when it terminated its 99-year lease and turned over control of the site to the state government of Madhya Pradesh. Dow Chemical Company Purchased UCC in 2001, seventeen years after the disaster."

Dow Chemical did not own Union Carbide at the time of the incident. Additionally, EIIL had assumed, and shed, liability for the cleanup prior to Dow Chemical's acquisition of UCC. Dow Chemical is absolutely responsible for damaging the environment in various ways; however, constructing narratives to implicate the company in the Bhopal Disaster is disingenuous.

<comment><USER22> The death toll numbers vary with which source you cite. I was being conservative with 20,000. The ~4K number is of course those who dies immediately after the leak, many have perished due to long term effects and still continue to do so. It hasnt stopped.

It is irrelevant that Dow did not own UCC then, it owns it now, and not in part, wholly, that comes with liabilities too. Liability does not disappear in the thin air just because some other company buys it out. To vindicate this point, Dow has paid millions for UCC liabilities in US. Dow did not own UCC at that time either.

UCC has ceased to exist and Dow owns all of the assets, and I argue that includes UC all its liabilities liabilities. The gold standard has been that the polluter pays, the polluter was UCC, which is now owned by Dow (which means all property physical and intellectual). EIIL never assumed liabilities, it obtained the lease of the land that had been lent out to UCC by the govt, it did not buy UCC.

If you want to know the facts I would say dig around, if you want to push an predetermined opinion, continue what you are doing. As the owner of UCC, Dow has been summoned by the Indian courts which it has refused to do, so as per Indian law its a fugitive from justice.

[http://www.goodreads.com/book/show/183715.Five_Past_Midnight...](http://www.goodreads.com/book/show/183715.Five_Past_Midnight_in_Bhopal) does a good job, but from your tone it seems you wont be interested much.

> constructing narratives to implicate the company in the Bhopal Disaster is > disingenuous.

Thats really cute, what name would you give to profiteering from human disaster by using US sovereignty to shield it from criminal and tort proceedings.

</comment></comment></comment></comment><comment><USER24> The Atlantic has great brand capital, which for some reason doesn't erode much when they regularly print sensational clickbait like this, or do things like print PR stories for the Church of Scientology ([http://archive.today/vca4i](http://archive.today/vca4i)). I'd take this article and most of what they print with a grain of salt.

</comment><comment><USER20> Oh good an article about complete bullshit. I haven't read enough bullshit lately.

Edit: Oh good the pseudo science crew is here to downvote me. Good lord people read the article; you can tell by the opening paragraph it's complete bullshit. Look at the studies they reference and how shitty their controls are. Good god people try being skeptical for once.

Edit2: Today I learned Hacker News is a great venue for spreading pseudo science and quackery. That kinda makes me sad.

<comment><USER25> > Today I learned Hacker News is a great venue for spreading pseudo science > and quackery.

On non-programming topics that's always been the case. HN is full of programmers who are not knowledgeable in science, and tend to trust their personal political or cultural beliefs on other subjects where science might be applied. Today's frontpage is actually great because it contains an example of that with both political valences. There's a "left-ish" pseudoscientific story about toxins, and "right-ish" pseudoscientific story about evolutionary psychology. Amazing. We're only missing a thread on weightlifting or nutritional fads to complete the bingo card.

<comment><USER26> Do you know the difference between pseudoscience and a soft science? I don't think you do.

Hard sciences like physics and chemistry are able to describe processes in minute detail because the systems being studied are relatively simple. As you scale the systems up, the level of detail that science produces is diminished, because there's a higher level of uncontrolled variables. This is why people make the difference between hard science and soft science, you can still try to follow scientific principles without getting a high level of conclusivity.

What soft sciences rely on is a body of observational evidence. Here's a classic example from the article... "For decades, chlorpyrifos, marketed by Dow Chemical beginning in 1965, was the most widely used insect killer in American homes. Then, in 1995, Dow was fined $732,000 by the EPA for concealing more than 200 reports of poisoning related to chlorpyrifos. It paid the fine and, in 2000, withdrew chlorpyrifos from household products. Today, chlorpyrifos is classified as "very highly toxic" to birds and freshwater fish, and "moderately toxic" to mammals, but it is still used widely in agriculture on food and non-food crops, in greenhouses and plant nurseries, on wood products and golf courses."

<comment><USER20> > Do you know the difference between pseudoscience and a soft science? I don't > think you do.

Science follows a well known process. There are no hard or soft sciences. There is one that follows evidence and another that's pseudo science bullshit. With great claims comes great evidence and your soft science example not only lacks proper, vetted scientific evidence but is actually complete bullshit that simply fits with your cultural belief.

<comment><USER27> You won't make a lot of friends here with this kind of reasoning. Please refute the article in a way that is at least somewhat open to scrutiny from the wider audience. That should at least include concrete examples and preferably sourced rebuttal of said claims.

Calling something "pseudo science bullshit" because of "science"... is a lot more similar to pseudoscience than having an actual sourced debate based on concrete examples.

</comment></comment></comment></comment></comment><comment><USER28> What threatens personal health is mostly stress and sugar. So start exercising, lower your pace every now and then and stop drinking soft-drinks.

And even this isn't entirely correct since people get older and older nowadays. Why is there so much fear about personal health when the situation actually keeps getting better?

<comment><USER29> I'd imagine it's due to us actually being able to discover what effect things have on our bodies in ways we've never been able to before.

</comment></comment><comment><USER30> Regardless of these 'toxins' \- I'm sure if you evaluated the toxicity and exposure to chemicals in an average household it would be probably exceed that of industrial labs in the past. Think deodorants, washing-up liquid, detergents, hand-washes, shampoos riddled with obscure-and-difficult-to- pronounce ingredients, cleaning liquids such as bleach. Forget the risk of being exposed to manganese within a steel can - we are already actively polluting our households and probably breathing in higher amounts of nasty chemicals hidden in household products than the examples mentioned in the article.

<comment><USER31> I think you severely underestimate the fatality and occupational exposure rate in old industrial labs.

Here's a classic pre-OSHA example of producing tetraethyl lead with no containment whatsoever (1924): [http://blogs.plos.org/speakeasyscience/2011/08/24/at-the- doo...](http://blogs.plos.org/speakeasyscience/2011/08/24/at-the-door-of-the- loony-gas-building/)

Madam Curie's papers are still radioactive due to lack of containment (early 1900s): [http://www.csmonitor.com/Innovation/Horizons/2011/1107/Marie...](http://www.csmonitor.com/Innovation/Horizons/2011/1107/Marie- Curie-Why-her-papers-are-still-radioactive)

Herea re the "Radium Girls" who would lick radium-laced paintbrushes to make watches (1917): [http://en.wikipedia.org/wiki/Radium_Girls](http://en.wikipedia.org/wiki/Radium_Girls)

And don't forget that nearly all heat-related surfaces in old labs were insulated with asbestos: [http://en.wikipedia.org/wiki/Asbestos#Industrial_era](http://en.wikipedia.org/wiki/Asbestos#Industrial_era)

Don't forget the countless people who played with mercury as pranks (!) in old labs, nevermind the fact that old lab thermometers used to be made of the stuff and that it was used in countless experiments of yore (today, a broken mercury thermometer will evacuate a school or lab): [http://en.wikipedia.org/wiki/Mercury_(element)#Historic_uses](http://en.wikipedia.org/wiki/Mercury_\(element\)#Historic_uses)

Etc. Unless you've got a small lead factory, asbestos, some radioactive liquids, and a bottle of mercury laying around your house, I'm quite certain that it is quite a bit safer than "industrial labs in the past."</comment></comment>


Our security auditor is an idiot. How do I give him the information he wants? - <AUTHOR> http://serverfault.com/questions/293217/our-security-auditor-is-an-idiot-how-do-i-give-him-the-information-he-wants <comment><USER2> This is seriously fucked up. I'm assuming the OP (in that thread) is trolling though. You _can 't_ possibly be that ignorant.</comment>


Some professional news - <AUTHOR> https://medium.com/@sippey/some-professional-news-b58ef35b222c <comment><USER2> Their _Head of Product_ couldn't come up with a more explanatory or relevant title for his introduction? Or, at least, use a more expansive title for the HN submission?

<comment><AUTHOR> Hi, just saw this. I'm loathe to go against the submission guidelines. I didn't expect this to do "well" but thought it was a significant enough move.</comment></comment>