Pretending OOP Never Happened - <AUTHOR> https://www.johndcook.com/blog/2020/05/15/pretending-oop-never-happened/ <comment><USER3> Usually when I see somebody arguing against object-oriented programming, I don't see them arguing for functional programming, but instead arguing for procedural (like Cobol, Basic, or Pascal) programming. What they usually miss is that there's a reason procedural programming was abandoned some time around the mid-90's, and for good reason: you can't realistically develop useful software in pure-procedural way without introducing a lot of global state. Even if you look at well-designed non-OO code like, say the Linux kernel, you'll see that there are object oriented concepts like information hiding and polymorphism all over the place; they just don't formalize them with the "class" or "private" keywords. Unfortunately, what I see most programmers do is give up on OO design (and never even consider FP) and instead create global state that they call "singletons" to pretend that they didn't just create a global variable. Because, as we all know, global variables are bad, but too few of us actually remember why.

<comment><USER4> _you can 't realistically develop useful software in pure-procedural way without introducing a lot of global state. Even if you look at well-designed non-OO code like, say the Linux kernel, you'll see that there are object oriented concepts like information hiding and polymorphism all over the place; they just don't formalize them with the "class" or "private" keywords._

You are misattributing that to OO programming.

The original edition of _Code Complete_ , written in 1993, makes absolutely no mention of OO programming or any OO principles. However it has a very good discussion of information hiding, and procedural code written in the various styles that it recommends do not create a lot of global state. (And yes, I have worked with such code.)

One of the best things about OO was that it pushed programmers who had not absorbed best practices towards that. However OO encourages combining the principle of information hiding with OO notions of inheritance. Many learned the hard way to prefer composition over inheritance. (Many, unfortunately, never learned that. Just as many procedural programmers never learned about information hiding.)

<comment><USER5> I feel like inheritance is the actual problem with OOP. Trees of types with increasing specialisations just don't describe many real world problems that well.

When you do build programs like this, code gets more and more rigid until it becomes a maintenance nightmare, and extremely expensive to pivot functionality. Sometimes having a complex object hierarchy literally stops you making some new feature.

A lot of mental effort is sucked up in mashing problem spaces into hierarchies, and once there the program is constrained by them.

<comment><USER6> It has little to do with subtyping per se and everything with the way that implementation inheritance, specifically, breaks modularity. The whole idea of inheritance _contra_ composition is that every call to a virtual method-- including calls _internal_ to the class-- goes through a dispatch step so that the _actual_ code that gets executed depends on whether the object is one of a "derived" class, where that method might have been changed in ways that might break any amount of expected invariants. This introduces brittleness both in base class code (which generally has to call methods that might get overridden in derived classes) and in the derived class itself (which has no way of knowing what invariants might be expected of it as part of base class code).

Implementation inheritance is often justified as a way of "reusing" code, but as it turns out, we've merely introduced undesired coupling instead of the seamless reuse we might have expected.

<comment><USER7> > where that method might have been changed in ways that might break any > amount of expected invariants

It's not supposed to, and if it does, the design is clearly broken. Now the (rhetorical) question is: does it happens often. The not so rhetorical question is: is it possible to make it happen rarely. The even more interesting question is: is it easy / more practical compared to alternative approaches, and if not then what is the point.

My opinion on SOLID is that there is precisely one hard "principle", and it is worthwhile: the LSP (it derives directly from logic, that's why). I believe that Open-close is even borderline insane, and that if there is a crazy way to make it not insane, this way is probably applied by so few people that it may well be irrelevant -- most people will try to apply it in ways that will quickly put them at risk for LSP violation, but LSP is far more important (or they will try to apply it in bad places, but that is another story). Plus programs designed with complex hierarchies are often missing the point of execution contexts, and then understanding them is absolute hell -- their original authors sometimes do not understand them themselves. (The rest of SOLID are soft attempts at fixing self-inflicted wounds, _sometimes_ even reasonable if you insist on doing Javaesque / old-C++-esque OOO, but I digress.)

I'm not sure why anybody thought that kind of OOO was a good idea, or that the main characteristic in interesting big programs was the usage of "classes". I even find the suggestion of causation instead of mere correlation dubious; they were already quite a good number of big programs before, and what permitted the explosion of program size was more the ever growing capabilities of computers, that happened, in affordable versions, during the Java-like OOO hype. Besides the simplistic reductionism (we can start with: which classes model entities, which classes model values, which classes are controllers, etc.) which is not too much a big deal in practice, modeling with class diagrams is often missing the river in the middle of the forest for some groups of intertwined trees.

<comment><USER8> What does "OOO" stand for? Usually it means "out-of-order [execution]" but that doesn't make sense here.

The Smalltalk-80 container hierarchy demonstrates that you can get a lot of mileage out of simple single-dispatch virtual methods with inheritance. The Smalltalk-78 system, which you can try at [https://lively- web.org/users/bert/Smalltalk-78.html](https://lively- web.org/users/bert/Smalltalk-78.html) (although it's not working for me at the moment), got a multiwindow GUI with an IDE running usably on an Intel 8086 with 256KiB of RAM, in only about 100 classes and 2000 methods totaling 200 KiB of code. This is not what I would describe as a "big program", but it is a fairly impressive program nonetheless. Seeing that kind of thing is what led people to adopt object-oriented programming.

<comment><USER9> alternative version: [http://www.cdglabs.org/thinglab/](http://www.cdglabs.org/thinglab/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> "OOP" is one of those terms (like most terms) that have a narrow meaning and a broad meaning, and either proponents or detractors can use one of them in arguments:

• OOP, narrow sense (emphasis on "object"): data-with-associated-functions, encapsulation, etc.

• OOP, broad sense (emphasis on "oriented"): organizing your program around objects that model the nouns in the problem domain, "everything is an object".

A (satirical) illustration of the latter is in the first few paragraphs of [https://caseymuratori.com/blog_0015](https://caseymuratori.com/blog_0015) (from 2014), which gives an example where, to write a payroll system, you first start by designing classes for "Employee", "Manager", etc.

A (non-satirical) illustration is in the infamous "TDD Sudoku" series of blog posts (follow the links from [http://ravimohan.blogspot.com/2007/04/learning- from-sudoku-s...](http://ravimohan.blogspot.com/2007/04/learning-from-sudoku- solvers.html) or [https://news.ycombinator.com/item?id=3033446](https://news.ycombinator.com/item?id=3033446)) where (in contrast to Norvig's program which just solves the problem) the TDD/OOP proponent ends up with a "class Game", "class Grid", "class Cell", "class CellGroup" (with derived classes "Row", "Column", and "Square"), but ends up nowhere. (From Seibel's post: "…got fixated on the problem of how to represent a Sudoku board. […] basically wandered around for the rest of his five blog postings fiddling with the representation, making it more "object oriented" and then fixing up the tests to work with the new representation and so on until eventually, it seems, he just got bored and gave up, having made only one minor stab at the problem".)

I think we can agree that this sort of object _oriented_ programming can hurt a lot (thinking about objects is not a substitute for solving your problems, though it is tempting), while _objects_ themselves are useful.

<comment><USER11> > I'm sorry that I long ago coined the term "objects" for this topic because > it gets many people to focus on the lesser idea.

> The big idea is "messaging" \- that is what the kernal of Smalltalk/Squeak > is all about (and it's something that was never quite completed in our Xerox > PARC phase). The Japanese have a small word - ma - for "that which is in > between" \- perhaps the nearest English equivalent is "interstitial". The > key in making great and growable systems is much more to design how its > modules communicate rather than what their internal properties and behaviors > should be.

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

<comment><USER10> Well, regarding that quote (interesting no doubt), see some important caveats at [https://www.hillelwayne.com/post/alan- kay/](https://www.hillelwayne.com/post/alan-kay/) which goes into some detail on evolving views about OOP (including that quote). It turns out that Alan Kay did _not_ coin the term "objects", though he did coin "object-oriented programming", but even in Smalltalk, messages were only one idea of three: the post concludes that "OOP consisted of three major ideas: classes that defined protocol and implementation, objects as instances of classes, and messages as the means of communication."

</comment></comment></comment><comment><USER12> I don't find this article well thought out. One, the writer presents OOP and FP as opposing paradigma's. While object oriented programming is orthogonal to functional programming. You can have a purely functional programming language with objects.

Two:

        100% pure functional programing doesn't work. Even 98%
        pure functional programming doesn't work

Doesn't work for what?

I think pure functional programming has its place, it is not just for everything you want to do. But object oriented programming is also not meant for every domain. It is like saying scalpels are stupid, because you can't build a house with them.

<comment><USER13> The objects would be fully public structs only though, yes?

>Doesn't work for what?

Doesn't work for performance, too much copying of immutable state.

If 100% pure means zero mutation, you can't even fit the definition of a program and write output /s

<comment><USER14> Immutable data structures and algorithms don't copy immutable state nearly as much as one might assume, and the vast majority of our field doesn't write software that is affected by the tiny performance differences between the underlying implementations of OOP Java versus functional Clojure, or perfectly optimized OOP JS versus naive functional Elm.

<comment><USER13> Sometimes its fine and sometimes its not but that is why 100% pure isn't feasible. I personally try take functional ideas into my OOP language as much as possible.

</comment></comment></comment></comment><comment><USER15> I think if we called it "binding functions to data", instead of "objects" we would have a much different view of how important OOP is. There are certainly times that binding functions to data can be useful, but I think if you tried to tell someone "im making a language where all functions must be bound to data" they would think you're crazy. (Even though that's basically what Java is)

There are so many times you don't want to bind functions to the data they operate on, and languages that force OOP always make it painful

The other thing OOP gives you is type taxonomies, but frequently those are an anti-feature. Almost every experienced developer I know thinks inheritance is usually a bad idea.

<comment><USER16> I'd change "binding functions to data" to "binding functions to types." The "data" is an object of a particular type. The binding to the actual data (object) can take place at compile time or run time, depending on need. IMO that makes it a bit less weird and more just shifting the position of a parameter.

<comment><USER15> Well, the reason I say binding to data instead of binding to type is that runtime polymorphism on instances is one of the selling points of OOP. I think its a little overrated but that is a good reason to use OO if you need that functionality. If you're only attaching functions to a type there isn't much difference between "thing.fn(x)" vs "fn(thing, x)"

</comment></comment></comment><comment><USER17> The author seems to be implying that we have a hard choice ahead of us with no middleground: We can either accept object oriented programming, or we can turn to pure FP.

The OCaml community presents a pretty compelling third option:

OCaml is billed as a 'functional language,' but it doesn't do anything to prevent you from performing mutations or executing side effects anywhere you want. It even has builtin syntax for "for" and "while" loops.

Interestingly, OCaml does afford classes and objects but hardly anyone seems to use them. It's not that OCaml objects are weird or difficult or bad in some way. People just choose to write records and functions. Some of those records have functions in them. Some of the functions mutate state.

In the OCaml world, at least, pretending OOP never happened seems to have worked out just fine.

<comment><USER18> > "The author seems to be implying that we have a hard choice ahead of us with > no middleground: We can either accept object oriented programming, or we can > turn to pure FP."

I disagree. I dont think that is what the author was saying at all, not even a little bit: "100% pure functional programing doesn't work. Even 98% pure functional programming doesn't work. But if the slider between functional purity and 1980s BASIC-style imperative messiness is kicked down a few notches — say to 85% — then it really does work. ... It's possible, and a good idea, to develop large parts of a system in purely functional code. But someone has to write the messy parts that interact with the outside world."

<comment><USER17> The problem is the way the author instantly jumps from "98% pure functional programming doesn't work" to "you should use OOP."

In order to bridge the gap, you have to make some pretty terrible assumptions:

If your code is not OO, it must be FP.

If your code is FP, it must be pure. Therefore,

If your code cannot be pure, it must be OO.

</comment></comment></comment><comment><USER19> > 100% pure functional programing doesn't work. Even 98% pure functional > programming doesn't work. But if the slider between functional purity and > 1980s BASIC-style imperative messiness is kicked down a few notches — say to > 85% — then it really does work. You get all the advantages of functional > programming, but without the extreme mental effort and unmaintainability > that increases as you get closer and closer to perfectly pure.

This is how we (try to) write code where I work. Pure algorithms, immutable data types, single point of change. D is pretty good for this, but could be better; ranges allow you to be pretty expressive when composing operations, but immutable types have a lot of problems still.

It actually combines well with OOP. We tend to mostly use classes to group methods and express domain dependency, rather than manage a tiny state subset. So in maybe half to two thirds of our classes, all the fields are set once on startup and then never changed again.

</comment><comment><USER20> "Object oriented programming, for all its later excesses, was a big step forward in software engineering. It made it possible to develop much larger programs than before, maybe 10x larger[...]OOP made it possible to write programs that could not have been written before"

Teams were writing million-lines-of-code Fortran programs in the 1980s to simulate the atmosphere, nuclear weapons, etc. Somehow I think these remarks need some qualification.

<comment><USER21> Yeah, the author seems to rewrite history quite heavily. There is even arguments here that the Linux kernel is OOP, in case we need to have a clear definition of what OOP is, because right now this HN-discussion is quite "fluffy".

</comment></comment><comment><USER22> > That has been my experience. I hardly ever write classes anymore; I write > functions. But I don't write functions quite the way I did before I spent > years writing classes.

> And while I don't often write classes, I do often use classes that come from > libraries. Sometimes these objects seem like they'd be better off as bare > functions, but I imagine the same libraries would be harder to use if no > functions were wrapped in objects.

I noticed this soon after I got involved with Java. Programmers were using classes where I would use methods. They would have objects which did things where I would have passive objects which have things done to them by methods. A specific example might a Parser class with a parse method, where I would define an entirely passive Grammar object with a parse method, and of course a Tokenizer object where I would use a tokenize method, calling an InputStreamReader class (instead of just InputStream) with a read method. I concluded that any class name ending in "er" was almost invariably unnecessary overhead.

I wondered where this came from. All I could think was in object orientation's roots in simulation, where it's entirely appropriate to have objects which do things, and it was copied from there.

<comment><USER23> This is why currently I am so happy with ES6+/Typescript. The ability to define strongly typed classes but also have methods really improves the OOP workflow to me. Classes should rarely be used for things that are unique, especially a "parse" method or etc. I recently had to make two modules- one to format a message and one to parse the message. Instead of classes, I can just use functions, outside the scope of any Class objects.

<comment><USER24> Sometimes the best function for the job is a free-standing function, e.g. parse(Grammar, Input). I was leaning this way when I read some quotes from Bjarne Stroustrup which touched on the subject. Here is a link to his personal FAQ which sums it up.

[http://www.stroustrup.com/bs_faq.html#oop](http://www.stroustrup.com/bs_faq.html#oop)

</comment></comment></comment><comment><USER25> This is just functional core, imperative shell. Which is to say, keep generic, immutable things generic and immutable. Build libraries to implement ideas and concepts in your domain. And then when it comes time to implement the high- level business logic, use an imperative shell to harness the power of all of those concepts you created. Keep it logical, straightforward, easy to follow, and well organized.

Like the author says, OOP is an organization tool more than anything and like "strategy," "adapter," "Command," "builder," etc signal specific things to your colleagues that IMPROVE understanding and time-to-grok.

<comment><USER26> Thanks for identifying the paradigm.

I've been working on refactoring some code, and I really like the functional style so originally wrote most of the logic in discrete functions. Multiple functions rely on some similar dependencies so there are some unique parameters for the function and then a handful of parameters that are the same for all functions (stuff like a database connection). It seems good that each of these functions can accept those dependencies in the signature, but it's likely that each of those functions is going to need that same dependency for the whole pipeline. At some point it looks to me like a small object that can handle the initial setup and management of those dependencies is helpful. Functional core imperative shell seems kind of like what I'm doing? Others mentioned there is some merit to being able to reduce the state from global to local in some form and OOP may be a useful for that case. Recommendations for other ways to handle these situations would be helpful as it's possible I'm only reaching for an OOP wrapper because that's what I know.

</comment></comment><comment><USER27> It would have been better if OOP actually never happened. OOP is just reaaaaly bad. One of this ideas that looks appealing, but doesn't work in practice.

Inheritance is often a space-goat, but it's not even such a big of a problem with OOP. Core ideas behind OOP are misguided:

        Abstraction
        Encapsulation
        Inheritance
        Polymorphism

Encapsulation on a such a fine-grained level as each object/class is like a person putting padlocks on each pocket, so that right hand can't grab thing from the left pocket. The granularity of encapsulation in OOP is just sooo impractical. The right granularity for data-hiding are data-stores, layers, APIs, (micro-)services, modules, not each single little bit of data.

Abstractions are costly. They can't be a goal in itself. Abstractions should be applied only where they are needed and beneficial, where benefit of adding them outweighs the cost. Similar with Inheritance and Polymorphism - they are abstractions that have a cost. Sometimes worth-it, sometimes not really.

Object itself is a bad idea. Passing around references to objects (data with attached behavior, instead of POD - plain-old-data) forces you to scatter your data across many tiny bits, which makes everything way more complex and slow (poor cache locality, layers and layers of indirection). Instead of passing an Id or bunch of fields, now you're passing data plus some abstractions to manipulate it everywhere. You generally get a graph, and graphs are the most general and thus most difficult to use data-structure out there. Coordination becomes a nightmare really quickly.

OOP is just a busy-work, and trying to pretend that you can just play with abstraction and taxonomies and ignore the fact that effectively your software is supposed to manipulate data to give an expected result, and not be a little god-game of modeling the world. Ignoring that there are some ways to structure your data that supports well what you're trying to do, and a graph of abstract object is very rarely the best choice.

And so on... [https://dpc.pw/the-faster-you-unlearn-oop-the-better-for- you...](https://dpc.pw/the-faster-you-unlearn-oop-the-better-for-you-and-your- software)

</comment><comment><USER28> It seems like there's something deficient in the way we tell the story of the history of software architecture (to the extent we tell a story at all) in terms of the name-brand techniques and technologies involved, rather than in the actual layout and organization of actual codebases.

For a while I've assumed that OOP as in C++/Java essentially formalized modular programming in C. In other words, that people were already writing programs whose state was divided into functional areas, with some functions serving as the interfaces between the modules. With a class-based system you can rigidly formalize this; and then OOP as we use the term essentially just reinterprets this formalization as actually creating the architectural paradigm that had already evolved as programs grew.

(This is NOT meant as the one way to sum up the whole world of things identified as or related to "object-oriented programming".)

But I wasn't around at the time...

<comment><USER29> This is my thinking too. It's really silly to have wars around programming paradigms. There are only a few principles around which we're all arguing:

* How do we make programs that are easy for the machine to execute efficiently? * How do we make programs that are easy for humans to read and understand? * How do we ensure, given the maintenance requirements of our programs, that another human who doesn't have the benefit of our experience can safely make changes to our programs without unitended consequences?

Discussions around OO versus Functional versus Procedural miss the point. You can write perfectly maintainable procedural, functional, or object-oriented code. If you're authoring something brand new you have to approach it with a complete understanding of all the moving parts. If you're not there, make a prototype, wait a few days, then go through and re-read it. Anything you don't understand is something nobody else will the first time they approach your code base. Come up with ways to be explicit and to communicate clearly what the intent is. Try to anticipate what things people will be changing often and make those easy things to change. Remember that it's about conveying a representation, not a deep understanding. You want to represent your understanding of the problem space to someone who doesn't have the same level of understanding as you.

<comment><USER3> > It's really silly to have wars around programming paradigms. There are only > a few principles

Well, you say we're having wars around the programming paradigms, I say we're having "spirited debate" around the principles :). I've been working mostly in Java for the past 20 years or so, and I can't help but observe that most people, when they try to put together a Java application, default to a sort of design that looks an awful lot like old Cobol programs did: they have a "datatype" generator (usually automated from XML schemas) and a slew of "utility" classes with mostly static functions that have mostly static data that operate on these datatypes, and as little class instantiation as they can possibly get away with. I've seen this same basic architecture repeated many times across four different employers in two decades. It's always a lurching, monolithic, untestable behemoth that never works reliably and resists any attempt to change. In talking with the original designers, it's clear that there were no principles behind the design besides "it still doesn't work, how do I get this thing to work". If there were clear and adhered to principles like automated testability, you'd end up naturally with an OO (or even better, FP) type design.

<comment><USER30> Interesting. I guess I've been more fortunate. Most of the Java code I've worked with has involved reasonably well thought out classes. For me that mostly means I can read and understand parts of the codebase in isolation. There are usually a few piles of sometimes ugly utility classes and the occasional mess of deeply nested inheritance that nobody wants to touch. When the latter becomes painful enough, someone usually decides to refactor it, which is often not as hard to do as everyone fears.

It seems to be improving in the last 5-10 years, as most practitioners have found that both of these eyesores can be reduced. DI (sometimes messy itself, but it can be done cleanly) tends to make people rethink those utility classes, and shallow inheritance is now favored, with a focus more on interfaces and composition.

</comment></comment></comment></comment><comment><USER31> I've been recently writing a lot of code in the ECS style [https://en.wikipedia.org/wiki/Entity_component_system](https://en.wikipedia.org/wiki/Entity_component_system) and I'm a fan. It allows me to concentrate on shit without getting distracted. Code tends to be clustered together with other related things as opposed to having to jump between files and classes and trying to figure out what's getting called.

The only downside is that it's not as popular in main stream and there aren't like ECS first languages.

However I believe that there is a reason ECS has been dominating in the game industry for the last 20 years. It's very flexible, fast and works nicely with the GPUs.

<comment><USER32> My impression of ECS from a distance is that it is antithetical to data- hiding.

That there are good reasons in terms of memory layout to locate all of those values which would have been member variables in large arrays so that external functions can iterate over them efficiently, but that in so doing, private members become impossible.

What am I missing?

<comment><USER33> You aren't missing anything. But you also aren't asking yourself the meta- question "what is the point of data hiding?"

The answer to that meta-question is "to preserve assumed relationships between data." `std::vector` stores a capacity, and that capacity damn well better correspond to the length of the last array it allocated or you will get a segmentation fault. So you hide it.

The OO thing that ECS is pushing back against is a tendency to group things together solely because they are in one-to-one correspondence, when they are otherwise unrelated. In a game, there is no constraint that needs to satisfied between a player's HP and their position on the map. So why "hide" this data together in an aggregation?

If you want to permit only a few functions to operate on your big array 'o stuff, you can always do something like

        class sensitive {
          static allowed_operation(sensitive& s, context& c);
        private:
          double here[N];
          int be;
          bool dragons;
        };

Similarly, if you need to do some really complicated computation on everything about a player, you can define Objects as aggregations of indices into the arrays 'o stuff (where typically people think of an Object as a big-ass struct of structs, often implicitly due to Inheritance), where the data you care about hiding is not the stuff from the array, but the indices:

        class Player {
          GetComponent() { return arrComponent[index]; }
        private:
          size_t index;
        };

<comment><USER32> Thanks for the examples shoehorning data hiding into ECS! They are revealing even if only appropriate in esoteric circumstances.

> _But you also aren 't asking yourself the meta-question "what is the point > of data hiding?"_

My answer to that question has always been that data hiding is necessary for the sake of modular independence in large systems. This is a principle which applies across all of engineering, not just software — see the "starter motor" example elsethread.

Implementation details need to stay hidden so that you need only concern yourself with local effects when making changes — instead of needing to keep the entire system in your head because any change might impact any tiny detail anywhere at all.

Nevertheless, I agree that in some circumstances it makes sense to expose the data structure as an API, and that ECS offers a compelling approach and set of conventions as to how you would go about that.

<comment><USER27> > My answer to that question has always been that data hiding is necessary for > the sake of modular independence in large systems.

Yes. But not on a granularity of every object. Just like you don't put a padlock on every pocket, to protect your left hand from grabbing stuff from a right pocket.

Hiding data has a real cost, just like inventing abstractions and interfaces for every tiny thing. That's the core reason why OOP-software is so bloated and always feels so "heavy".

The right granularity is much coarse: modules, API layers, data-stores. Much closer to service in "micro-service", than "object".

</comment></comment></comment></comment></comment><comment><USER34> Interesting stuff, but I really miss explanations:

> It (OOP) made it possible to develop much larger programs than before, maybe > 10x larger.

Why?

This contradicts my intuition, because the biggest problem is that OOP focuses on state changes (of objects). State change means complexity, so formally, you need to understand the set of all possible states to reason that the program is correct. This is an exponential problem in the number of pieces of state, unfortunately. So how would this enable larger programs? What's the reasoning here? It would mean some even more potent mechanism of OOP makes more state more manageable. The structuring of data does not strike me as that potent -- nice, yes, but, well -- please explain!

> OOP provides a way for programmers to organize their code.

I think it is primarily about organizing data. The organising of the corresponding code follows. When Java emerged, it did not even have functions -- every piece of code had to be attached to data. In SmallTalk, you could change the definition of the global 'true' or even extend bool to have three values -- definitely data centric, and introducing unmanageable state...

> 100% pure functional programing doesn't work. Even 98% pure functional > programming doesn't work.

I believe this. Well, intuitively, I'd say no paradigm works well when applied 100% pure. It would still be nice to see examinations of this or reasoning or proof or at least examples.

<comment><USER35> > the biggest problem is that OOP focuses on state changes (of objects). State > change means complexity, so formally, you need to understand the set of all > possible states to reason that the program is correct.

This is just not true. In fact that's the whole point - you encapsulate state. It becomes easier to reason about.

When I write a webserver, do I need to know or care about the internal state of the classes dealing with the TLS protocol? Or do I encapsulate consistency and correct behavioir at that level and then use the interface elsewhere?

I don't need to know everything at all layers.

</comment></comment><comment><USER36> > I hardly ever write classes anymore; I write functions.

I've never understood why so many people insist on this false dichotomy.

I do both.

These past years, I feel that I've been writing much better functions as my understanding of more advanced concepts has ramped up, thanks to functional programming and the emergence of things like Rx and coroutines, but once I have these functions, I am extremely happy to be able to organize them in classes and modules and leverage various forms of polymorphism to make my code base flexible and easy to maintain.

<comment><USER37> > I've never understood why so many people insist on this false dichotomy.

> I do both.

Are you talking about methods attached to your classes or functions that are at the root/module level? If it's on a class I would argue it's not a function since it takes input that's not just the parameters to the function. If it doesn't access properties of the class, then whey does it need to be attached to the class?

For example, let's say there is a function that takes instances of two different classes and returns an instance of another class. If you want to move that function to a class, where does it go?

> once I have these functions, I am extremely happy to be able to organize > them in classes and modules

I understand the organizing into modules and being able to create interfaces/types, but why classes?

</comment></comment><comment><USER38> > Object oriented programming, for all its later excesses, was a big step > forward in software engineering. It made it possible to develop much larger > programs than before, maybe 10x larger.

If that statement is true then OOP was surely the most important advance in software development since the original higher-level languages, such as Fortran, were developed.

My experience agrees with the author's stance that OOP provides significant leverage in developing complex software. What I don't understand is why he then falls into the current fad of seeking to abandon it.

Surely if OOP has been as successful as the author claims then what's needed is not to replace it with another paradigm that rejects all the core principles of OOP but rather an approach that combines the good aspects of OOP with other paradigms allowing the programmer to use the tools best adapted to the problem at hand.

<comment><USER39> No one ever seems to as if an ever larger program is a good idea, the fact that the tools enable it, and that its the way thats taught currently still does not answer the question of 'goodness'.

</comment></comment><comment><USER40> I don't understand the modern hate for OOP. Perhaps a bad mentor or inheritance nazi. Inheritance can be thrown in the trash but otherwise OOP is just a collection of related functions where you can have shared data to work with while not polluting global scope. I don't see how it's so oppressive unless if you're trapped in Java land where OOP is inescapable as opposed to dynamic languages where you can sprinkle in your OOP with other coding styles as needed.

<comment><USER41> A relevant quote from Joe Armstrong, creator of Erlang:

"the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

In a nice procedural or functional program, when I need to do something I just write a function that takes the relevant arguments. From the function signature, I can reason about the function, that it only depends on and interacts with those things I passed in. It also means I can reuse that function anywhere else in the code I happen to have some of those things that are the function args.

In the OO approach, even if a function only needs to access a few member variables, I still pass in the whole object every time I declare a member function. This makes the function harder to reason about, as the body of the function could touch any member of the class, and if it has other classes as members then it could rely on any of them too. It also makes the function much harder to use, as even if it only needs X, Y and Z, calling it requires creating a whole instance of that class of which the function is a member, which may require a bunch of other stuff.

In that sense, the OO approach introduces unnecessary coupling, between the logic in the body of a member function and the class members not used in that function. Because I can't use that function's logic without creating instances of the members not used in that function.

</comment></comment><comment><USER42> There's nothing wrong with objects. Hierarchies of objects, though, ran into the "is-a" problem. Multiple inheritance has even worse problems, especially around order of initialization.

Now that people are mostly over inheritance for the sake of inheritance, it's not so bad. Often, you want to have one class be a member of another, rather than a child of it.

This brings up a common problem. If A is a member of B, B sometimes wants a back-reference to A. This is hard to set up in some languages. It should be made easy, because it removes much of the need for inheritance. For Rust, especially, it's a special case of Rust's back-pointer problem, the one that makes doubly linked lists and trees with backpointers hard. Not having this encourages the creation of structures with too many data elements.

</comment><comment><USER43> "Pretending X never happened" might make an interesting series. Things that we no longer adhere to (visibly at least) but changed us in ways we can still appreciate

<comment><USER44> A natural question that arises in this context is: "do those who join the field _after the consensus to forget X ever happened_ behave any differently than they would have _if X really hadn't happened_?"

</comment></comment><comment><USER45> The author seems to equate OOP with "writing classes". So I have to suggest that OOP never happened for them in the first place, at least not in the sense I understand it viz. messaging, encapsulation, and late binding. The design discipline that falls out of this is, for me, domain modelling, not "writing classes", and the value I've obtained being thereby a better fit between the structure of code, and the purpose of that code, with all the opportunities for validation and comprehension by domain experts that follows.

That said, I do agree with the sentiment that multi-paradigm languages offer higher developer productivity than purist languages. I'd still have procedural style in fourth place, behind OO, FP, and Logic.

</comment><comment><USER46> Maybe its because I write small software or customize existing mature Enterprise apps. I just dont care about the dogma so much. I think there is a lot to like about OOP. There is a lot to like about functional code. I use both quite a bit with C#. Dont get me wrong though, Im glad people do think about this and try to make software paradigms better. I just dont find that I am overly hampered with current tool sets to worry about this stuff.

Most importantly, I think this is just all talk. This is John D. Cook just spitballing with a contemporary and debating things. I bet the other person in the conversation is probably not all that convicted of his argument and is throwing an exasperated take out there...

</comment><comment><USER47> I was hoping this post would be about what the world (and our programs) would look like if OOP never happened. But an interesting and quick read nonetheless.

</comment><comment><USER48> OOP never had one definition anyway, besides maybe "your language has a 'class' keyword" (although some don't!).

<comment><USER49> and Haskell has a "class" keyword, so I guess there goes that option too

</comment></comment><comment><USER20> Reading some of the comments here reminds me of an extremely popular language that was designed from the start to encourage the use of a kind of class inheritance. People built complex things with this language, using deep layers of nested inheritance, as was intended. Then they began to discover that, when your project reached a certain level of complexity, it was excruciating to try to figure out what was going on, and impossible to change anything without breaking eight other things far away. New, powerful features are added to this language every year, and are embraced by developers, but they have learned to tame it by avoiding its inheritance abilities, or using them very sparingly. They have even developed novel ways to use its power while largely avoiding inheritance—systems that have their own conventions and terminologies invented by end developers and not envisioned by the language designers.

I'm talking about CSS, where class inheritance is called the "cascade."

</comment><comment><USER50> To make my point, let's go back to the very beginning of programming: plugboards.

To create a program you used cables on a plugboard. You had a general purpose computer that can run multiple programs, but in other to switch programs you had to spend significant time setting up cables. A small change in the program may also result in the same thing.

So then we moved to stored program computers, so that we don't have to do that anymore, and the global consensus is that it was a good idea, because it saves time.

Then, we had programs in bare machine language. But that poses various challenges:

1) Having to keep track the state of memory and registers is difficult. So programming languages were created to create an abstraction over them in the form of variables.

2) Programs were full of jumps that became hard to track and maintain at scale. Structured programming was created to create an abstraction over jumps in the form of control structures (sequence/selection/iteration/recursion). Procedural programming was created to group statements into reusable procedures and functions.

3) Then, having variables around became hard to maintain as well. So then structures were created as a way to group variables that are used together.

But then, people understood that some procedures and functions are coupled with structures, and that some structures are supersets of other structures. And that's how OOP was born.

In this mindset, I do not think OOP is a bad idea. I also do not think that the natural consequence of OOP is bad software. The problem is how the paradigm is used, not the paradigm itself.

The problem people are facing now is shared mutable state, which is not only a maintainability problem, but is also problematic in multithreaded software. Functional programming is a viable solution to address that problem.

NOTE: edited based on suggestion, since apparently I got some concepts mixed up.

<comment><USER51> Just a note, structured programming wasn't about structures in the data sense, but in the logic sense. Organizing program _logic_ in a way that was more structured. Using a pseudocode:

      function unstructured_summation (int lower, int upper):
        int sum := 0;
        label loop:
        sum := sum + lower;
        lower := lower + 1;
        branch_neq lower, upper, loop;
        return sum; // this is assuming there's even a return concept

This is short and simple, so that goto or branch is fine here for reasoning about. But it doesn't scale very well [0]. Structured programming discouraged these ("discourage" being a scale from: don't use unless it makes sense to don't use at all) in favor of other constructs that were more clear in their intent and easier to reason about (particularly in the days when you couldn't write a piece of code and test in in 10 seconds or less).

[0] I once inherited a Fortran codebase that was essentially written in an unstructured style, many gotos and computed gotos. The guy who wrote it (yes, singular) over a 20 year period knew exactly what it did. But that didn't help me, because he was 70 and retired with a nice pension. The whole thing had to be rewritten using the original as a reference for testing because it was unmaintainable.

</comment></comment><comment><USER52> This is all awfully vague. Accordingly, all the comments are just talking past each other.

What does "85% functional" mean? How exactly do you measure that?

For that matter, what does "OOP" mean? PG published a note from Jonathan Rees [1] which lists 9 possible (pieces of) definitions.

"Because OO is a moving target, OO zealots will choose some subset of this menu by whim and then use it to try to convince you that you are a loser."

That's roughly what I'm seeing here, yes.

[1]: [http://www.paulgraham.com/reesoo.html](http://www.paulgraham.com/reesoo.html)

</comment><comment><USER53> Funnily, ever since I decided to follow the solid principles and striving for clean architectures in general, I've been writing _more_ classes. Not that I can in my current job, being go, but I make do.

Why can't people let paradigms be paradigms instead of trying to turn them into religions? They're approaches that might or might not be well suited to different problems; yet so many people try to make the problem fit the paradigm they prefer instead of the other way around.

This article is thankfully more nuanced than most on this subject, though.

</comment><comment><USER54> Before I ever dabbled in what was called "object-oriented" languages, I was happy enough to

<include stdio.h> ... FILE myfile;

Isn't myfile really an object?

</comment><comment><USER55> I've actually run into a couple of people with six-digit SO scores that profess to not know about such concepts as polymorphism.

My jaw dropped. Maybe they were being a smartass, but that's just crazy talk.

Like all dogmatic stances, people just take a "My Way or the Wrong Way" approach.

Most of my engineering is a hybrid of classic ( _read: "old"_) techniques, and new, "cutting-edge" techniques.

I write about my outlook on that here: [https://medium.com/chrismarshallny/concrete- galoshes-a5798a5...](https://medium.com/chrismarshallny/concrete- galoshes-a5798a55af2a)

(Scroll down to "It's Not An 'Either/Or' Choice").

One day, AIs might replace us poor coding schlubs. At that point, we can assume that everything will revert to Machine Code.

Until then, OO is a great way for humans to grok the complexity of software development.

I will always keep refering to this classic joke, when I encounter inflexible, dogmatic thinking: [http://www.solipsys.co.uk/new/TheParableOfTheToaster.html](http://www.solipsys.co.uk/new/TheParableOfTheToaster.html)

<comment><USER56> I'd say all programmers of any significant experience know the concept of polymorphism, but it's quite possible to know the concept without knowing the word.

They might be using discriminated unions, or type-distinguishing enums on rows or structs with a superset of attributes, but the concept is hard to avoid when trying to generalize behaviour over heterogeneous data.

<comment><USER12> Good point, you see this so often in C code bases. Didn't even think about that.

</comment></comment></comment><comment><USER57> One take, from Robin Popplestone, long ago in comp.lang.functional: "… it does seem to me that … OOP represents the discovery by the mainstream community that it is a good idea to associate code with data, but, since they still don't know how to do closures, they have bodged it."

</comment><comment><USER58> I don't know much, but I think:

modularity is VERY good

(I think most of the shortcomings of C are a lack of modularity)

functional programming is good (eliminate side effects and people and compilers can assume without making an a * * of u and me. Should not be required)

classes are good

(frequently it's the same, but slightly different)

multiple inheritance is bad

(there are other ways to do it)

</comment><comment><USER59> > I hardly ever write classes anymore; I write functions.

This speaks to me so much.

</comment><comment><USER60> I wish the author defined the term OOP somewhat. It really means different things to different people.

FWIW I like Bob Martin's definition (encapsulation, inheritance, polymorphism).

</comment><comment><USER61> This article and the associated comments reminded me of 'Object-Oriented Programming and Essential State'[1] which was posted on here about half a year ago. I'm just going to copy from a thread that I felt got to the crux of the matter with OOP.

\----

One thing I hate though, in a language like Java, is when I see "utility" classes with static methods which take objects as parameters, then perform some calculation based entirely on the state of the passed in object. In my opinion, if the object can reason about its own state and return an answer based on that reasoning, that method/logic should be in the object, not elsewhere.

Another one that bothers me are these transformation static methods which take type A and return type B based on nothing but the state of type A. The languages were talking about, C#/Java already provide a facility for this called a constructor.

If the development approach is going to completely remove operational methods from data types then I'd think long and hard about using a language which supports this instead of a language, like Clojure, which does not.

\----

> that method/logic should be in the object, not elsewhere

Only if it's involved in preserving some object invariants, or accessing parts of its state that are abstracted away in the public interface. Otherwise, you're breaking encapsulation by putting some logic in the object that doesn't belong there, and making it hard to change the implementation later.

> The languages were talking about, C#/Java already provide a facility for > this called a constructor.

There are sensible reasons to avoid using constructors for this, at least in the general case.

\----

> Only if it's involved in preserving some object invariants, or accessing > parts of its state that are abstracted away in the public interface. > Otherwise, you're breaking encapsulation by putting some logic in the object > that doesn't belong there, and making it hard to change the implementation > later.

I've been pondering this thread all day, and I think this is the crux of the issue. Ideally, classes would only encapsulate state and you'd use namespaces/modules to encapsulate functionality. But most Java/C# OOP examples use classes to encapsulate both state and functionality, which gets you stuck in the morass that the article discusses.

\----

[1] [https://news.ycombinator.com/item?id=21238802](https://news.ycombinator.com/item?id=21238802)

</comment><comment><USER62> 85% FP + 15% BASIC = JavaScript

<comment><USER63> haha. JavaScript bad

</comment></comment><comment><USER64> libc has stood for quite a while without OOP. I think a mix of fp and imperative is magnitudes easier to mull about than oop. imo fp and imperative semantics are much clearer than oop.

</comment><comment><USER65> OOP in the sense of encapsulation, inheritance, polymorphism is an academic exercise for students to think about organization of data and functions into hierarchies. Objects in this case were mistaken for modules. This is only usable by students and librarians.

OOP in sense of message passing is just a programming language implementatiin technique used in Smalltalk which lets you handle functions of multiple arguments with ease. You basically 'pass' each argument as a message to the receiving object.

That is obviously just a hack to make that feature of nontrivial function call work. Real message passing obviously has to be asynchronous to even resemble concept of real life message passing. Erlang and Actor model in that case are pure models of message passing based OOP.

Somehow all of these OOP systems are just distractions from solving problems using computers because you can represent your problem using pure 'data' such as numbers or strings and composing them to bigger structures with well defined operations - such as lists, dicts and tables and so on. Objects can be purely abstract thing in your mind or documented in code comments.

Imperative programming obviously doesn't scale beyond one machine because of von Neumann bottleneck and suffers from unmanageable global state. That doesn't mean OOP is the solution.

Functional programming is of two kinds - statically typed with powerful type systems - which are systems with very limited field of use and high development cost. Unfortunately unusable for real life problems because of lack of intuition.

Other less strict functional languages fare better, but used naively suffer from von Neumann bottleneck too. Unless they are used in a language oriented programming paradigm, whereby you use your language only to construct a higher level language DSL) which can abstract over more than just a single machine.

Good examples are Lisps and their ability to define other languages such as Prolog or SQL or Linq.

The only way to make parallel computing possible is to use data parallelism instead of task parallelism so data oriented languages such as sql or datalog are the future since Moore's law reached its end. This poses a strong constraint on design od programming languages.

SQL, while not suffering from single processor bottleneck, unfortunately sucks as a language because it is not programmable and nondeterministic in generating physical plans.

Which offers a great opportunity for programming language enthusiasts - <USER2> a programmable sql or datalog like language because other paradigms reached some fundamental constraints and hit a dead end.

Or come up with a new paradigm.

</comment><comment><USER66> Program = Data Structures + Algorithms

Most OO code is poorly designed, slow, error prone and a memory hog. Every object you initialise wastes so much memory. OOP is not going to be there forever. It is a failed paradigm. Hopefully it will be replaced with something more efficient, faster to develop and something with more provable correctness.

Is an object a data structure, an actor, a module, a knowledge frame ?

A state machine can rightfully be called state + behavior. Sadly no programming language has made hierarchical state machines a first class feature to support with syntax despite it being software engineering unlike what OO bros claim.

<comment><USER35> For a failed paradigm, there sure is a lot of perfectly successful software written using it.

<comment><USER66> Successful as in slow to use, poorly designed, difficult to extend and a memory hog. You can't even reuse code between rails1 and rail2. OO is a joke. Pure OO languages like Java and SmallTalk are already failures. C++, Scala, Kotlin are not OO languages. Design patterns are not engineering, let alone architecture.

The only success for OO has been UI development. It's a failure everywhere else. OO databases are a failure. ORM is a failure. OO based distributed computing has failed, we use REST. OO based design is a failure, no one uses UML.

OO based architects are a waste of time and money. You can replace all OO based architecture nonsense and patterns with code written in Go.

<comment><USER35> Java is not pure OO, neither is it objectively any sort of failure, being one of the most widely used languages out there.

As such I don't think the rest of your post is worth consideration.

<comment><USER66> Java Web Start is such a big success.

</comment></comment></comment></comment></comment><comment><USER67> Avoiding OOP is hard: even those using "non-OOP" languages like C often end up doing some sort of bad OOP where the first parameter is some sort of explicit this pointer. I would tend to agree with the author's conclusion: it's often not worth trying to remove all instances of a paradigm from your code, especially if you're working in a multiparadigm language. If you try to stay away from some of the more problematic aspects (inheritance) while retaining the strengths (encapsulation) I think you've done a good job.

<comment><USER68> I agree with you that the biggest strength of OOP is encapsulation that is easily accessible. As for inheritance, I think it is also a good abstraction, but in an very limited number of circumstances. In 10 years as a professional developer I have only ever implemented something using inheritance once. I think the problem with inheritance is that it is far too encouraged, and people fit it into problems which it is unsuitable.

EDIT: typo

<comment><USER69> > In 10 years as a professional developer I have only ever implemented > something using inheritance once.

If you build a library or framework, you'll use it more. There are often plenty of literal "is-a" relationships that don't exist as often in application code. So you probably benefit from inheritance in OOP quite a bit even if you aren't building those relationships yourself.

<comment><USER68> And now that I think of it, what I was building was a data visualization framework that users could create "plugins" for to handle many disparate types of data. So yeah, frameworks are a great example of cases where inheritance shines, but is rather niche and not many people work on them day to day.

</comment></comment></comment></comment><comment><USER6> I'm not sure I agree on this. OOP is really about implementation inheritance and ad-hoc polymorphism based on the same, and it's pretty clear by now that these are not good ideas because of e.g. the fragile-base-class problem, that basically involves violations of modularity.

Simpler object-based paradigms and languages, which feature "classes" and "objects" for encapsulation and data abstraction, plus maybe some interface- only subtyping, are used all the time and work quite well with functional programming concepts.

<comment><USER70> The main lesson I've drawn is that the real problem is dogma: OOP works fine if you aren't trying to follow some One True Way™ rather than adjusting based on your needs, problem domain, and resources. The same is true of most other styles: FP is prone to getting a certain brand of immutability fanatic who will cause problems until they learn more about computer architecture and get a more nuanced position.

In every case, focusing on dogma avoidance and having reasonable technical debt levels seems to be far more important than the specific language and paradigm.

<comment><USER71> People think that with FP you end up just copying a bunch of stuff constantly. But in my experience, that's rarely true: structural sharing minimizes copying so that the performance is usually on par with in place mutation. In fact, in some situations, the immutability guarantees make the program faster than the mutable version.

Moreover, advanced compilers (like GHC and the OCaml compiler), can often turn functional code that allocates and copies into in-place, GC-free code.

<comment><USER70> Remember, I was talking about dogmatic silliness - the kind of thing where someone thinks it's some kind of moral failing to use Haskell's mutable structures, even though they're there for a reason.

My point was that this seems like the same mindset even in two fairly different domains, and that we're prone to talking about it as a technical problem when it's really more of social one.</comment></comment></comment></comment>


Inside One of America's Last Pencil Factories - <AUTHOR> https://mobile.nytimes.com/2018/01/12/magazine/inside-one-of-americas-last-pencil-factories.html?hp&action=click&pgtype=Homepage&clickSource=story-heading&module=second-column-region&region=top-news&WT.nav=top-news&_r=1&referer=http://www.loopinsight.com/ <comment><USER2> Fascinating article. I went out looking for General pencils, but the best I could find where the Ticonderoga. An art store perhaps?

<comment><USER3> This reminds me of the last American Clothespin factory[1]. There have been a few small batch wooden clothespin makers popping up, but not a bug one like National Clothespin.

By the by, CWPencil[2] does carry General Pencil products

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

[2][https://cwpencils.com/collections/vendors?q=General%20Pencil...](https://cwpencils.com/collections/vendors?q=General%20Pencil%20Company)</comment></comment>


Most interesting datasets/APIs? - <AUTHOR> What do you find to be the most interesting datasets/APIs to work with? Which datasets/APIs are you really interested in checking out but haven't yet? <comment><USER2> This is more a "spend the rest of the afternoon/evening/early morning getting horribly distracted" list of lists of lists, but I found a lot of it quite interesting, and I definitely have more ideas now than I had before I'd skimmed it:

[http://reddit.com/r/datasets/top?t=all](http://reddit.com/r/datasets/top?t=all)

</comment><comment><USER3> The first 10M items (comments and stories) on HN: [https://news.ycombinator.com/item?id=10002791](https://news.ycombinator.com/item?id=10002791)

</comment><comment><USER4> [http://basekb.com/](http://basekb.com/)</comment>


Are Humans Fit for Space? A 'Herculean' Study - <AUTHOR> https://www.wired.com/story/are-humans-fit-for-space-a-herculean-study-says-maybe-not/ <comment><USER2> Interesting how our understanding of risks change. I have that Soviet illustrated pop science book about space travel. Published in 1955 - two years before Sputnik - the main concern it had was the harm of microgravity. Huge unknown at the time, there were fears that humans would not able to function properly in weightlessness, so all the designs of orbital stations were with centrifugal gravity.

DNA at that point was barely discovered and genetics remained a pariah science under CPSU for years.

(The book also refers to space pilots as astronauts, not cosmonauts, and describes polar caps and channels on Mars. Wild.)

<comment><USER3> Which one? Is it online anywhere?

<comment><USER4> >Is it online anywhere?

[http://www.flibustahezeous3.onion/b/167460](http://www.flibustahezeous3.onion/b/167460)

</comment></comment></comment><comment><USER5> At some point we're going to have rotating, shielded space stations that are much safer than living in 0g aluminum tubes.

The real question is whether the effects of subnormal gravity are safe. If not, Mars isn't likely to work out and we'll instead have to build rotating habitats.

<comment><USER6> We need to figure out how to live together before we live together in space. Imagine how easy it would be to damage or destroy a relatively flimsy man-made habitat that everyone literally depends on to survive.

<comment><USER7> That isn't going to happen tho. People will be living in space way before they figure out how to get along because getting along is something that humans will never do: maybe what ever species we evolve in to might but that is surely thousands of years in the future.

<comment><USER8> The drive to compete is what causes progress, and not getting along is an inevitable side effect of that.

Any species that gets along perfectly either has telepathy (or some sort of unfakeable hormonal equivalent), is some kind of hive/single individual, or is stagnant.

<comment><USER9> For these purposes, all we need is to get rid of (or at the very least properly control) violent tendencies. We don't need to make it so everyone's singing religious rock songs around a fake camp fire to celebrate everyone getting a participation medal in cooperative soccer.

<comment><USER8> But violence is the same as disagreement plus enforcing your opinion.

You obviously can't get rid of disagreement. And enforcing your opinion is the bedrock of change.

So I don't believe it's possible to get rid of the desire for violence without stagnation.

You can certainly get rid of it in action, but the desire is still there, just suppressed.

<comment><USER9> My bosses have never needed violence to enforce their opinions, and I have never needed to resort to violence against them when working relationships have turned sour.

And ridding the action is all that is necessary for us to not die from civil disorder in a space settlement.

<comment><USER10> This is only because the (threat of) violence has been outsourced to the state. Imagine that there is no state monopoly on violence [1] and your boss pays you directly in food, which you need to survive. Suddenly he refuses to pay you and you face starvation. Now you're pretty likely to resort to violence.

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

<comment><USER9> I've mostly avoided needing to involve the state, too. My personality is more of "compete by being better" and I regard violence (and regulatory capture) as cheating.

Don't get me wrong, I'm not an anarchist — I agree that state monopoly on violence would be spontaneously recreated if it was removed. I'm also a lot more dubious about the political future than about the technological future.

But, that's beside the point: I'm saying that we could, plausibly, have social and political structures that suppress our violent tendencies and in so doing make it not ridiculously unsafe to live in a fragile space habitat.

This is not without precedent, as we are less violent now than we were a mere few hundred years ago, and have managed this with little in the way of actual evolution.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> This reminds me of the discussion from 5 years ago after the Virgin Galactic crash.

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

What I said then still stands:

" Someone dying is devastating. Trying to conquer space a handful of people at a time is the slow and dangerous way of accomplishing this task. We should be building machines to explore the solar system. This can be done for a fraction of the cost, time, and it will allow him to allow us to iterate quickly. In 100 years, more humans will live off earth if we iterate with machines, etc now than if we move slowly trying to reduce the risk in order to keep humans safe."

<comment><USER12> That is what SpaceX is doing. Their manned and unmanned spacecraft systems are similar now (Falcon 9 + Dragon/Crew Dragon) and will be the same with the next system (Super Heavy + Starship). Hopefully the Starship will begin unmanned launches in 2020 as planned and get a good number of launches under its belt so that manned launches can start soon. With Starship SpaceX won't be constrained by NASA safety requirements. They will have the NASA approved Crew Dragon to launch NASA astronauts while they can use the Starship to launch anyone who decides that the Starship is safe enough for them. There is even a low probability that Starship will be launching people before Crew Dragon starts launching people, which would be a real blow for NASA, but would really point out the problems of a safety first attitude for technological progress.

<comment><USER13> Safety first attitude? The space shuttle exploded with all crew lost, twice. Crew dragon exploded on one of its tests. Boeing test went tits up.

Rarely does a year go by without a rocket crashing or blowing up. If you want to blow up metal fine, but when it comes to people I find your attitude unhelpful.

<comment><USER14> >Safety first attitude? The space shuttle exploded with all crew lost, twice

2 lost out of 135 missions. That's what, a 1.48% failure rate? In a spacecraft that was kinda wonky given things like the fact each shuttle had nearly 3,000 FRCI tiles (each one present a possible failure point).

Launching into space with rockets will always be dangerous, you're strapping your cargo (human or otherwise) to one or more bombs and saying "please blow up in the way we want and not all at once".

Even if someone develops magical anti-gravity, there would always be the chance that it would fail and you'd drop out of the sky with no means of propulsion or that something would go wonky and part of the craft would suddenly implode. Even a space elevator would have risks.

<comment><USER13> Everyone knew the vehicle was wonky and that makes it even more egregious, it's not an excuse. It should have never stayed in service for as long as it did.

You seem to think 1.5% is an acceptable failure rate? Then what is too high in your mind, 50%?

Imagine we did have large scale space infrastructure/ spacestations / lunar colony, astronauts would have to fly that vehicle several hundred times in their career. No-one would survive till pension. We've had rockets for like 70 years now, it should not be a gamble whether you will survive.

</comment></comment></comment></comment></comment><comment><USER15> A more interesting question is how can humans be modified to be fit for space and other planets?

You and I will never leave earth, let alone the solar system. But a colony ship with a 1000 year nuclear battery, a huge computer, a massive sample of biological samples and some raw materials could go to another star system. Once there it could build something that would thrive locally (their gravity, their o2 levels, their radiation and temperatures). Something with a similar enough brain to humans...

<comment><USER16> Not realistically, no. For example

> 40 percent of the astronauts who lived on the International Space Station > suffered some sort of damage to their eyes, including optic disc edema, > globe flattening, and folds in the choroid, the blood-filled layer between > the retina and the white sclera.

In order to modify humans not to experience these effects in space, you would need to take those 60 percent of astronauts who did not suffer these effects, have them reproduce, check that their children inherited the right genes (i.e. the genes that insulate them from these effects), wait for those children to grow, train them as astronauts, send them into space, check for any other health effects, bring them back to Earth, make those people who do not experience adverse optical effects have children of their own who are immune to other health effects of exposure to microgravity, check that these children have all the right genes, etc. Rinse and repeat over generations. Forced evolution, basically.

Gene therapy would dramatically expedite the process, but you need to first identify which genes protect astronauts from xyz health effects of long-term exposure to microgravity, and then modify the genes of your astronaut candidates to fit the right genetic profile. You must also avoid nasty side effects. If the procedure you used to tweak the genes of your astronaut to prevent bone density loss, for example, results in the astronaut having a higher likelihood of developing a cancer, you must find another way to protect the astronaut from bone density loss without increasing his likelihood of developing a cancer.

A more "brute force" approach would be to send a large cohort of randomly selected humans into space, say 10,000, have them spend a few months in orbit, monitor them for any adverse health effects, and select those few (if any) who did not experience any side effects to be the parents of a future, genetically enhanced, astronaut corps. While everyone else is crippled to various degrees by their stay in space.

<comment><USER17> > In order to modify humans not to experience these effects in space, you > would need to take those 60 percent of astronauts who did not suffer these > effects, have them reproduce

That assumes that the 60/40 split had anything at all to do with genetics.

<comment><USER18> Definitely. It would be surprising if genetics affected almost any of these problems tbh. Much more likely is that the damage arises in a poisson ransom process or whatever and we have little recourse

<comment><USER19> Also, IMHO it's a bit arrogant to believe we know the best traits. Humans are complicated systems. Maybe halfblind, motion sick and paranoid people are better at surviving out there than happy contempt people never bothered when the centrifuge breaks down. Or whatever. I agree that the best brute force test is to just put a lot of people up there and see what happens. The best survivors might not be the obvious candidates.

</comment></comment></comment></comment></comment><comment><USER20> Beltalowda sabe what inyalowda sa-sa, que si?

In all seriousness, the bit about "a new species of spacefaring hominins" is more-or-less what The Expanse posits. Belters are not Inners, beyond culture.

</comment><comment><USER21> Longest continuous period in space is just 1.2 years. Almost all human testing is yet to be done before we know if the Mars mission is possible without rotational gravity and heavy and expensive radiation shielding. Nobody knows how much gravity on Mars surface (0.38 g) or on the Moon surface (0.17g) helps with the problems and recovery.

Simulated Mission where astronauts spends 9 months on ISS, few months in moon (or short visit on earth) then another 9 months on ISS would tell something. Radiation is not as bad as in the Mars trip, so it would be safer than the eventual Mars mission.

<comment><USER22> Which is why we should be doing tests in earth orbit at mars gravity (using rotational/tethered structures).

<comment><USER21> Not in the budget I'm afraid.

If you start building rotational structures and getting experience, the price is similar to a spaceship with rotational gravity.

<comment><USER22> Two capsules and a rope.

<comment><USER21> Plus completely new procedures for operating in artificial gravity, safety measures, prototypes, startup, tests, exercises, docking procedures, ... Soon we are talking about big money. If you want to move inside capsules you need to balance and deal with vibrations etc.

<comment><USER22> Gemini did tether experiments.

</comment></comment></comment></comment></comment></comment><comment><USER23> It'd be far more efficient if we could abstract human consciousness from the meat machinery.

<comment><USER9> We don't know how much we don't know about consciousness works yet.

<comment><USER23> True.

But then, that's pretty much the same for building starships.

</comment></comment></comment><comment><USER24> These guys are heroes for putting their bodies throug this much testing for mankind.

</comment><comment><USER25> Homo sapiens are not suitable for the purpose of life in space, homo sapiens may someday create an intelligent life form which will be adapted for a long life in a zero gravity vacuum and radiation filled environment.

</comment><comment><USER26> tldr no

</comment><comment><USER27> I doubt humans will ever live beyond earth. I can't see how it's possible. Lack of gravity, lack of pressure, excessive radiation. We'd literally need antigravity and magical force fields to sustain what we consider "human".

A few generations off Earth and humans won't even be humans anymore. We will become aliens ourselves IF we manage to survive.

<comment><USER28> Antigravity is provided by rotating a cylinder along it's longitudinal axis. It's very simple stuff.

Not sure why we need force fields. If you meant radiation shielding, liquid hydrogren or even water is a fine radiation shield. Life evolved on earth in shallow seas before there was an ozone layer.

All of the things you mentioned are possible, but very expensive today. The reason we wouldn't live beyond earth is because people just accept that it's too hard and too magical.

<comment><USER27> Forget costs. Where are you even going to get the materials for that at scale?

Sounds good for a space ship or small space station. How do you make that work for thousands of people?

<comment><USER29> Moon is close by, has plenty of sunlight, aluminum and apparently iron ores, some water. It all is at a reasonable gravity that allows to safety operate on the surface, but cheaply launch a lot into earth orbit, even using electromagnetic catapults that don't require a propellant.</comment></comment></comment></comment>


Ask HN: Printing as a service, has anyone tried doing something like this? - <AUTHOR> If anyone has where could I read more? In my imagination it would work like this. I upload some documents I need to print. I go to a convenience store where there is a printer. With my smartphone I scan a QR code on the printer, I print what I want to print, I pay over the Internet. I get going to where I am supposed to be. If the printer is occupied I go to the next convenience store a few block away. I did a quick Google search but I didn't find much info.<p>https://encrypted.google.com/search?q=printing+as+a+service <comment><USER2> How is this different than existing commercial printing locations? AFAIK they already offer printing of documents via web/mobile apps.

</comment><comment><USER3> FedEx online printing does this.

CostCo does this.

Other companies do it as a mail-your-printed-goods services.</comment>


If a VC fund reaches out to you and asks for your company deck what do you do? - <AUTHOR> https://www.quora.com/If-a-VC-fund-reaches-out-to-you-and-asks-for-your-company-deck-what-do-you-do?share=1 <comment><USER2> Ask for their fund deck first.</comment>


Redefining the Mole - <AUTHOR> https://www.nist.gov/si-redefinition/redefining-mole <comment><USER2> > _In practical terms, the mole helps chemists measure stuff. It helps express > the amounts of atoms or molecules in a chemical reaction. Cause a half-mole > of oxygen molecules (O2) to react with a mole of hydrogen molecules (H2) and > you get a mole of water (H2O)—equal to about 18 grams of substance._

Every example I find describing the utility of the mole could just as plausibly substitute "dozen" or "googol" for "mole". I'm not clear on what would be lost to science by instead declaring a new number that is untethered from Avogadro's historical dependence on mass or length. Perhaps the deeper issue is that I'm not clear on why the dimensionless mole is a base unit at all.

<comment><USER3> It's an arbitrary number, but it's nice because one mole of atoms with atomic mass number X will weigh approximately X grams. This is exactly true for carbon-12 (and is what defines a mole).

<comment><USER4> > one mole of atoms with atomic mass number X will weigh _approximately_ X > grams

Speaking as someone who has had to deal with rounding errors in floating-point graphics, data structure layouts, and real estate cartography, that sounds horrifying and insane.

<comment><USER5> There is no other way. The problem is atoms combine in integer ratio amounts to form molecules. To mix things for chemistry one needs to be able to mix things in proper proportions. So having a number that trades number of atoms to something plausibly measurable, like mass, is needed.

The reason it cannot be exact for all atoms is forced on us by nature: atoms come in isotopes, each weighing slightly differently, and most common elements come in a mix of isotopes.

So picking one isotope of one element (carbon-12) as the definition for a mole that is decently representative of how chemists will use the number is a perfectly fine and useful number.

Any chemist that needs to worry about the fuzz will understand this and act accordingly. For example, carbon 22 has a mass slightly larger than 22/12 that of carbon 12 (but has short half-life). Carbon 13, which is stable, has mass slightly over 13/12 that of carbon 12, and when using it, one adjusts accordingly. And these "slightly over" phrases are also known to many digits of precision.

But nailing down the number precisely is extremely useful.

</comment></comment></comment></comment><comment><USER6> The definition of a mole provided in this article is no doubt correct, but it's not how it was taught in my high school chemistry class.

For others with the same nagging thought, the explanations of Avagadro's Law feel more familiar: [https://www.britannica.com/science/Avogadros- law](https://www.britannica.com/science/Avogadros-law)

In particular:

 _The specific number of molecules in one gram-mole of a substance, defined as the molecular weight in grams, is 6.022140857 × 10^23, a quantity called Avogadro's number, or the Avogadro constant. For example, the molecular weight of oxygen is 32.00, so that one gram-mole of oxygen has a mass of 32.00 grams and contains 6.022140857 × 10^23 molecules._

<comment><USER7> The article does briefly discuss a slightly more accurate version of that definition, and why it's bad (it's convoluted and relies on the poorly-defined kilogram).

<comment><USER8> The kilogram will get a better definition this year if nothing holds it up (atleast, redefining it based on the planck's constant is planned for the 2018 meeting according to WP).

<comment><USER9> Right, that's a main point of the article.

</comment></comment></comment></comment><comment><USER10> While the article makes an excellent effort at making the material accessible to the general public, I find it kind of sad that they automatically assume that any sort of math is "cryptic" or "complicated"–i.e. something to be avoided.

</comment><comment><USER11> Re the educational aspect -- when I ask students in my university class whether they remember Avogadro's number from high school, they all respond in the affirmative. When I ask them for the mantissa, the whole class sings out "6.02". Great!

But, when I ask for the exponent, they are really quite uncertain. For many, the rote learning has cut off after the "times ten to the" in the sentence. This is disappointing, but at least it provides me an opportunity to talk about what digits actually _mean_.

If I were a psychologist (shudder) interested in how learning works, I'd be inclined to see whether the students who get exponents wrong are the same as those who have no idea how to handle significant units. My guess is that they _are_. I think the problem is that the core ideas of decimal notation are lost on many learners, because all digits are equal on a calculator, so getting the "2" wrong in Avogadro's number seems to be the same as getting the "6" wrong.

If I had a magic wand to wave, I'd use it to bring back slide rules. (Oh, and I'd bring back low grades for weak work, but that also would not fly with school boards.)

<comment><USER12> 6E23! It rhymes. If they can remember "6E" and that it rhymes, then the first number after 3 they come to that rhymes is 23.

        Atoms in 1g
        Of 12C?
        It's 6E 23.

<comment><USER9> ...in 12g, surely?

</comment></comment></comment><comment><USER13> _On November 16, 2018, representatives from more than 50 countries are expected to make history when they gather in Versailles, France, to vote on redefining the SI, including the mole. The vote will close the book on this chapter of Vocke and Rabb's work, but will open a new chapter in chemistry as the fundamental unit, for that branch of science will no longer be tied to a physical object but a constant of nature._

Interesting to find out that the concept every chemistry student is taught is about to be redefined. Odd that they couldn't schedule it on mole day...

I remember struggling with the concept of the mole in high school.

After working many problems I was able to see what the big deal was about:

The mole links the macroscopic world we can directly experience with our senses to the atomic world which we cannot.

Think of the mole as a monetary exchange rate between these two worlds. It converts mass of a pure sample (which we can measure directly on the bench top) to number of particles (which we can't). Chemistry and accounting have a lot in common. If you're good with money, you should be good at chemistry.

Anyone can pick up an ingot of silver, place it on a balance, and read the number to get the mass. Use of the mole (and the atomic weight of silver) allows this measurement to be converted into the number of silver atoms in the sample. This process is identical to the one you'd use to figure out how much your hotel in Paris will cost you in dollars.

<comment><USER14> >If you're good with money, you should be good at chemistry.

I don't think it's quite that simple, but I can see where you're coming from.

<comment><USER13> I should have qualified that with "General Chemistry." You can solve the majority of General Chemistry problems by looking at them from an accounting perspective.

Neither units of money nor atoms can be created or destroyed. We use math to figure out what happened in a transaction or reaction.

Still, I'm curious - where do you see a fundamental divergence between the two?

</comment></comment></comment><comment><USER15> The important redefinition of year is of _the kilogram_. Heck, IPK no longer weighs one kilogram :)

</comment><comment><USER16> My daughter was asking me about moles recently. Glad to see NIST has something I can point her to.

<comment><USER17> So does XKCD: [https://what-if.xkcd.com/4/](https://what-if.xkcd.com/4/)</comment></comment>


Using an App Analytics service? You are violating Apple's developer agreement - <AUTHOR> http://code-ninja.org/blog/2012/10/25/using-an-app-analytics-service-you-are-violating-apples-developer-agreement/

<comment><USER2> Shhh, maybe no one will notice that we've been using these services for months (years?)!</comment>


Is the Internet melting our brains? - <AUTHOR> http://www.salon.com/books/int/2009/09/19/better_pencil/index.html

<comment><USER2> The problem here is he's misquoting history which is a big issue when your stated goal is to put things into historical context. I honestly don't have the time to critique this guy to the extent he deserves but I picked out a few points just to illustrate what I mean...

Quote #1: "I start with Plato's critique of writing where he says that if we depend on writing, we will lose the ability to remember things. Our memory will become weak. And he also criticizes writing because the written text is not interactive in the way spoken communication is. He also says that written words are essentially shadows of the things they represent. They're not the thing itself. Of course we remember all this because Plato wrote it down -- the ultimate irony."

I encourage you to read Plato's actual words here: <http://www.platonicrelationship.com/blogger.php/?p=411> Plato wasn't against writing (as the author says Plato used it himself) he was against thoughtful debate via writing. He's saying that people who learn by reading rather than by interacting tend to parrot what they learn rather than actually understand the concepts behind it (and he's right in many ways). So Plato wasn't against writing he was just trying to get people to realize where it should and should not be used.

\</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>

Quote #2: "Thoreau objecting to the telegraph, because even though it speeds things up, people won't have anything to say to one another. "

Thoreau wasn't objecting to the Telegraph at all. Read the quote: [http://www.allsoulscommunity.org/sermons/2003/BetweenWaldenP...](http://www.allsoulscommunity.org/sermons/2003/BetweenWaldenPondandLakeMichigan.htm) Then go here and read Martin Luther King's take on it (Search for "Improved means to an Unimproved End"): <http://www.geocities.com/thoreaulogy/07sep.html>

Thoreau was commenting on the illusion that technology improves the content of our communication not coming out against the technology itself.

\</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>

Quote #3: "Then we have Samuel Morse, who invents the telegraph, objecting to the telephone because nothing important is ever going to be done over the telephone because there's no way to preserve or record a phone conversation. "

I can't even find this quote by Samuel Morse but I suspect what he was saying is that the Telegraph records communication between two people where as the Telephone can't so the telegraph isn't made useless by the telephone. Not that the telephone is itself useless.

\</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>

Hopefully I've made my overall point. All these people were simply trying to help society decide how to use these inventions not saying the inventions were bad. That's exactly what people are doing now with Twitter, Facebook, etc... and it's a good instinct. This author's aim seems to be embarrassing people with that instinct into silence with false quotes and that's just wrong.

<comment><USER3> From Plato:

 _"You know, Phaedrus, writing shares a strange feature with painting. The offsprings of painting stand there as if they are alive, but if anyone asks them anything, they remain most solemnly silent. The same is true of written words. You'd think they were speaking as if they had some understanding, but if you question anything that has been said because you want to learn more, it continues to signify just that very same thing forever._

What's great about this quote is that it suggests that Plato might have liked the web very much. The web steadfastly refuses to say the same thing forever. (Indeed, it is absolutely terrible at archiving things.) But it supports updates, and revisions, and back-and-forth much better than print does. The two media compliment each other.

<comment><USER4> It is a disservice to Plato to assume he lacks the ability to make a distinction between a (written) correspondence and text.

Plato's statement here is likely more subtle than superficially apparent. Specifically, note that he refers comparatively to painting, which (certainly in his day) required a subject (whether mental or natural).

"[W]riting shares a strange feature with painting", in that dimensions are collapsed; the subject is 'framed'; and viewer perspective (e.g. "if anyone asks them anything") is rendered irrelevant and "continues to signify just that very same thing forever".

</comment></comment></comment><comment><USER5> _"Far from heralding in a "2001: Space Odyssey" dystopia, Baron believes that social networking sites, blogs and the Internet are actually making us better writers and improving our ability to reach out to our fellow man."_

That's an odd movie reference. Maybe the writer is referring to the scene where the astronaut is watching a video from his family and reacts very distant and aloof. I thought that was more of a comment on the vast physical distance and isolation involved in space travel, not necessarily by an evolution in attitude caused by technology - his family seems like they are having a good enough time at least.

So it doesn't matter how efficient our social networking sites get or how lovely Facebook chat is, there will still be an 18-minute lag getting the signal on a ship heading to Jupiter.

Maybe I missed the point, but I really like that flick :)

<comment><USER6> Also, HAL 9000 was "born" in Urbana, Illinois. I doubt that sheds any light on why the author included the reference, but it definitely overlaps. (EDIT: Dennis Baron, the author of the book discussed in the article, teaches at Urbana-Champaign).

I think you might be onto something with the way 2001 depicts communication. I think the film is so ingenious in its presentation of "future technologies" in a mundane context. The movie has aged so well; I think that's a pretty accurate representation of some video chatting I've done, even though it took more than 40 years to materialize.

It's pretty hyperbolic to call 2001 a dystopia, especially if they're referring to the apparent lack of enthusiasm that accompanied communication.

Yes, HAL went on a murdering spree, but if that's all the Rossmeier (the article's author) is talking about, then he's missing the point of 2001.

Anyway, I agree: it's an odd reference. I think 2001 is one of the best movies I've seen (no joke), so I have a few thoughts on the matter...

</comment></comment><comment><USER7> The internet empowers many with an opportunity to be part of the conversation - to the extent that they're able and willing. It brings together collaborators and ideas that might otherwise never have met. It opens opportunities to explore facts and ideas, and for self-expression, that have never existed.

"Destroying the English language"? I think not. More likely, there are those who are afraid of the empowerment of the many. So, as they so often do, they throw up FUD. The times, they continue to be changing, Mr. Jones.

<comment><USER8> And it improves the conversation by adding metrics and filtering. In my personal experience it has induced me to improve my writing and become a more reasonable, less ideological, person.

</comment></comment><comment><USER9> A very thoughtful analysis, however IMHO the comment that "we have all this apparatus to find the data we're looking for" is only partially correct and an opportunity for hackers to develop applications to adequately filter the increasing noise of the web.

<comment> onreact-com This is not an analysis, just a polemic full of words and expressions like "hysterical", "luddites", "hogwash".

</comment></comment><comment><USER10> print version [http://www.salon.com/books/int/2009/09/19/better_pencil/prin...](http://www.salon.com/books/int/2009/09/19/better_pencil/print.html)

</comment><comment> onreact-com No, it isn't. On the other hand there is no reason to blindly believe that the Web will make us communicate better than in real life. This guy hasn't been in flame war yet I guess.</comment>