Why Are So Many Developers Hating on Object-Oriented Programming? - <AUTHOR> https://thenewstack.io/why-are-so-many-developers-hating-on-object-oriented-programming/ <comment><USER2> Have you seen bad OOP code? It's an unreadable mess of ObjectManagerFactory classes where everyone mutates everything.

Have you seen bad functional code? It's an unreadable mess of monads, flatmaps and partial composition where you're not really sure how many arguments a curried function is whitholding.

Have you seen bad procedural code? It's an unreadable mess of nested if-else statements where you're not really sure what state the world is in.

There are no silver bullets, only different solutions to different problems

<comment><USER3> I feel that it is in fact possible to learn from history, and what humans tend to be good at and bad at, and derive useful directions for the future. "Use the right tool for the job" and "no silver bullets" are certainly tautologically correct, but they seem to miss the point of these discussions: we have a _choice_ in what paradigms we teach, what frameworks we write, and what tools we use. _How_ do we choose the right tool? These platitudes often have the (unintended?) consequence of effectively serving as veiled gate- keeping: "silly novice, you thought learning X was sufficient? No no, you must learn all the possible paradigms, and at some point you will become aware of which one to precisely apply for any given problem. Me merely telling you the solution would be cheating!"

Practically speaking, in my opinion, beginning teaching programming with an OOP approach can be detrimental to students. When I see students work in procedural (not even functional!) environments, they seem to piece together "the puzzle" of the programming task, whereas in OOP environments they often seem to devolve into strange taxonomical metaphysical questions "Is a Car a Vehicle? Or does it implement Drivable? Is a Window a Widget itself, or does it only own Widgets? If it's a Widget itself, then could a Window contain sub- windows?" So at least for the very constrained question of introductory languages and techniques, I think there is nothing _wrong_ with specifically calling out certain approaches, vs. vaguely attesting to the truism that you can write bad code in any language. This feels similar to when people discover the concept of Turing Complete, and thus conclude all languages must thus be equivalent and any programming language discussion is thus moot. No. If that were the case, we should have never bothered going past assembly.

<comment> yoz-y What courses or universities actually start with OOP? In my uni we started with functional programming (Scheme) and then went to C, only then we learned Java, C++, Prolog and so on.

In another uni when I supervised some exercise classes all students started with Python but using only imperative paradigm.

<comment><USER3> In high school AP Computer Science uses Java (20 years ago when I was in high school, they were just transitioning off of C++). You can see what the earliest programmers are being taught here: [https://apcentral.collegeboard.org/pdf/ap-computer- science-a...](https://apcentral.collegeboard.org/pdf/ap-computer-science-a- course-a-glance.pdf?course=ap-computer-science-a)

Edit: When I was in HS, the AP CS courses (now there is only on since the second one was discontinued) used the "Marin Biology Case Study" ( [https://en.wikipedia.org/wiki/AP_Computer_Science_A#Marine_B...](https://en.wikipedia.org/wiki/AP_Computer_Science_A#Marine_Biology_case_study_\(2000-2007\)) ). It has apparently been replaced with the "GridWorld" similar case study. I think it highlights one of the issues of OOP: a fascination with modeling, or perhaps over-modeling, the real world. Throughout the course you are expected to develop deep knowledge of a myriad of Fish and Fish Tank-related classes, which while perhaps an accurate preview into what working in an environment like Java is like, is not something that in my opinion succeeds in either exciting most students nor teaching them the "fundamentals" of algorithms and such. I think it can very much feel like a very complex and convoluted exercise in meeting the abstract goals of "categorizing" the world. Ironically, the insistence on modeling the world makes it feel frivolous and disconnected from any practical use -- which is incredibly sad since IMO CS could be the _most_ practical math/science course you take. In my experience when you show kids the cool things that they can get computers to do _for them_ , it can be more inspiring -- such problems do not lend themselves well to formalized class hierarchy drawing though.

<comment><USER4> They are back to two, and the new one appears much further down the "not only OOP" path. It's more about the grand ideas of CS and less about programming. [https://en.m.wikipedia.org/wiki/AP_Computer_Science_Principl...](https://en.m.wikipedia.org/wiki/AP_Computer_Science_Principles)

</comment></comment></comment></comment></comment><comment><USER5> > "OOP is prevalent because cheap OOP developers are readily available, while > functional programmers are typically more smart, and more expensive…"

The reason I prefer functional programming over OOP is that I'm just _not smart enough_ to understand all the OOP abstractions and how to build reliable systems with it. Functional programming is just easier to grasp mentally, as it takes away a lot of the foot-guns (mutable state, inheritance, etc).

<comment><USER6> I grasped the concept of OOP pretty easily. Can't say the same about FP.

<comment><USER7> People say this, and I'm not sure it's actually true. People grasp some basic use of structs with methods on them pretty quickly and using that to do polymorphism. Most programmers I know haven't grasped how to use a system of message passing objects to make the semantics of the underlying language programmable at runtime.

<comment><USER6> To me OOP is about using "templates" to create "objects", which map nicely to real world entities/concepts. So a class is like a function, but unlike a function it can do more than define an input to output mapping. It groups together multiple related functions and variables, and allows "objects" to exist and be interacted with. These "templates" can be hierarchical and/or have more than one "base template", combining all their "features". This type of thinking feels natural to model real world objects and tasks.

The above is my "layman's" understanding of OOP (I've never taken programming classes, but I have been using OOP extensively in the code I write to do my machine learning research).

Can someone describe FP in a similar manner to someone like me? Because every couple of years I stumble upon another "intro to FP", and it just does not click for me. When exactly should I use it? How "monads" or "functors", or whatever else is important in FP, map to the real world, and real tasks? Maybe I just don't write the type of code that would benefit from it.

<comment><USER8> I feel the same way. As hobbies I like to work with my hands on things like carpentry and metalworking. OOP maps pretty well to how I think about accomplishing step by step tasks on physical objects:

Step 1: Use this tool (instance of a class) to perform that modification (call a mutating method) to affect this workpiece (another class instance). Step 2: Now use that tool...

So if I'm building a cabinet, my mind plans out something like:

      saw.cut(wood1);
      saw.cut(wood2);
      wood3 = glue_bottle.apply(wood1,wood2);
      sander.sand(wood3);

Etc.

I've always thought of a program as just a more elaborate series of step by step commands. Computer do this to this thing, now do that to that thing (which may, through a subroutine, mean doing other nested tasks). I can't wrap my mind around accomplishing a step by step process with functional programming. Just haven't made that mental leap yet, probably because I'm so used to thinking the other way.

<comment><USER9> For a simple case like this with no diamond-shaped dependencies, the direct functional expression is inside-out rather than top-to-bottom:

      sand(
        sander,
        glue(bottle,
          cut(saw, wood1),
          cut(saw, wood2)))

<comment><USER10> Now write that code with tools having durability. In OOP that is trivial and require no code changes elsewhere.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I've come to loathe inheritance in OOP, favoring composition instead.

The idea of creating abstract base classes makes sense in theory, but this eventually leads to problems regarding inherited behavior (i.e. debugging unexpected behavior of a "duck typed" interface up the inheritance chain)

<comment><USER12> I disagree. OOP and inheritance is fine, and so is just about every feature/paradigm/language/anything in programming, when used thoughtfully by an experienced developer. For instance, inheritance can often be used nicely at a framework or engine level.

Most people are just inexperienced and bad at programming, and bad at managing large projects, and if a lot of bad programmers and managers happen to be using some paradigm or feature or language, it is often the paradigm that takes the blame for their shoddy work because nobody is willing to admit that _they_ are the ones at fault.

Functional programming feels nice to everyone right now, because lots of experienced developers are enjoying themselves with it, and writing decent code. But mark my words: that good feeling will end once it gets too popular and adopted by new developers. And then people will blame Functional Programming for all the awful work people do in it. If you think I'm wrong, you are way underestimating how bad new software developers can be.

We don't throw away all our hammers just because some bad construction workers use hammers on the wrong things.

<comment><USER13> I wish I could talk to you 5 or 10 years down the road when you have discovered and internalized the reality that a) there are no good programmers b) the programmers you're complaining about will never go away c) you're one of them

My contention against OOP is that it is a pattern that encourages critical mistakes that composition-based systems does not encourage.

My contention against FP is that it discourages small amounts of state (e.g. that doesn't leave the scope of the current function) and instead encourages many mental leaps to wrap your head around the transducer or whatever.

But if I had to pick one, FP tends to produce higher quality code.

<comment><USER12> I've been programming for 20+ years now, nearly fulltime, and worked with many other programmers for the entire time. There are plenty of good programmers, and they all have a lot of experience. I've learned to tell the difference. It took a long time. Your blanket statement that developers are all bad is simply wrong, there are vast differences between them. Maybe to put it in terms you seem to prefer: some are "less bad" than others. And not everyone is bad in the same way, either.

But you're right, the programmers I'm complaining about will never go away, because there will always be new programmers, and old ones will retire or die.

My only point was that everyone's impression that FP tends to produce higher quality code is largely based on a selection bias from the code you've read, or based on your own attempt to learn the paradigm after already having had some amount of experience.

I witnessed firsthand the rise and fall of many paradigms in programming. I've witnessed it with NoSQL. And Agile. The same thing is likely to happen to Functional Programming, if it becomes too popular too quickly. When you see companies starting to post jobs with "Functional Programming experience required", that's when you're reaching peak, and a bunch of new (bad) developers will come in and ruin everyone's impression of the paradigm.

<comment><USER13> The industry is very new. The rise and fall is natural (lolwat data mining?). But the function is not uniform. MongoDB might be one of the worst tools on the planet for relational data, but data that's only accessed by id and is dominated by variable length data? There's no better db on the market. Agile? Well, nobody's figured any of that stuff out yet, to say the least. We can't even estimate basic tasks still, so planning is strictly fucked until we can.

Additionally, there are so many things to learn, especially for up and coming developers that it's nearly impossible to select good tooling to learn in the first place. So you'll have them randomly spread across the tooling which, again, is indistinguishable from each other from the perspective of a new developer.

I guess my point is that you're complecting two orthogonal concerns: the process of figuring out this software thing (still in it's infancy), and the process of bringing up juniors. Consequently, what juniors do before they gain sufficient training shouldn't have much impact on the value of tooling. That is, unless the tooling in question causes the juniors to make unnecessary critical mistakes because the tooling encourages it. QED I suppose.

</comment></comment></comment></comment></comment><comment><USER14> It is like JavaScript: I don't hate JS itself, I hate spaghetti-code people write with it (but I do hate automatic type casting).

I don't hate C, I hate dangling pointers and buffer overruns.

I don't hate OOP, I hate over-engineered class hierarchies, state hiding and leaky abstractions.

I don't hate FP, I hate when people write a new undocumented DSL for each project just because "it is so easy in an expressive language like X".

</comment><comment><USER15> I've been programming for a quarter of a century.

It has taken me a long time to realize that "dumb code" is the best.

Dumb code is easy to read.

Dumb code is concise and to the point, not attempting to address theoretical problems (necessarily).

Dumb code does not overthink the problem.

Dumb code helps you sympathize with the machine.

Dumb code has no weird blackbox behavior.

etc...

<comment><USER16> A corollary to that-- less code written the better.

<comment><USER17> Not always. eg, simpler code is sometimes turning a line into two or more lines, just to make variables named in a way that describes what's going on.

</comment></comment></comment><comment><USER18> I don't think OOP itself is bad. Bad abstractions are bad, no matter the language, and that is the main problem. Abstractions and domain models are created based on our understanding of a given problem as well as what is possible within a certain programming language/paradigm. Most of the time, we initially do not have a good understanding of the domain we are working in, and because we are conditioned to keep code "organized", we tend to fall back to established "patterns" (which OOP has an abundance of...), but these almost always end up being the wrong abstraction. By the time we figure this out though, it's already too late to change it.

A functional language such as Haskell tend to make us think a little bit more about what abstractions we use, because they are such an integral part of the language you can hardly do anything without them. We can "converse" with the compiler to come to a better understanding of how our code should be structured. You usually end up with a better domain model. However, this can also be very limiting. Lack of control of execution and no control of memory layout is a problem in my domain (video games). It's also slower to develop for because you can't take "shortcuts", which can be helpful to get something up and running without having to understand the problem domain.

I still use OOP daily (C++), but I never start out with abstractions when writing new code. I tend to create C-style structs and pure functions. Eventually, I will have a better understanding of how this new module should be organized, and will make an API that is RAII-compliant and whatnot. I think you can easily write clean code in OOP as long as the abstraction makes sense.

<comment><USER19> Out of all the comments here this one resonated with me by far the most.

You're totally correct: The goal is to find the right abstractions. Bad abstractions keep getting in your way either by leaking too much or by being based on invariants that turn out to be not actually be all that invariant, whereas good abstractions have no need to be touched again later.

For me, the additional layer of "how hard is it to change the abstraction if it turns out to be wrong" is also quite important. In my environment (algorithmic R&D) you never quite know which invariant your next idea will break. And this is where OOP can really bite you - untangling code from a class hierarchy or twisting interfaces to bend to your new ideas is anywhere between infeasible and a complete mess. Composition over inheritance can help save a lot of frustration here. But sometimes interface/abstract base class + a single implementation also provides a very clean abstraction to separate the core model/algorithm from the fiddly details. Just don't fall for deep hierarchies or large interfaces would be my takeaway so far.

Maybe we just need to get better at giving up on abstractions when they fail? I think that's very tough because they tend to still dictate how we think about problems (plus the usual cost of rewriting code). Your approach of delaying the abstraction choice sounds very interesting (somewhat akin to Extreme Programming?), I will try to keep that in mind for the future. In thinking about this I'm mostly afraid of code sort of remaining at this "makeshift"/provisional level and never actually settling into something more organized (due to lack of incentive/time to improve it). I think that can be kept under control, but do you have any suggestions on that front?

<comment><USER18> > Your approach of delaying the abstraction choice sounds very interesting > (somewhat akin to Extreme Programming?), I will try to keep that in mind for > the future. In thinking about this I'm mostly afraid of code sort of > remaining at this "makeshift"/provisional level and never actually settling > into something more organized (due to lack of incentive/time to improve it). > I think that can be kept under control, but do you have any suggestions on > that front?

Actually, I find that more often than not, code written in this manner is actually easier to maintain, because there are no layers and concepts to untangle - just the raw functionality and data transformations. You don't need to put yourself in the mindset of the person who wrote the code, who might not have had the right concepts in their head at the time. Instead, you just parse the code like a computer - This makes it easier to figure out what the code actually does rather than being distracted by the intent of the author.

The main purpose of abstraction is to intentionally hide implementation details so other people can use your code without requiring a full understanding of all the details. However, when maintaining code, obfuscation is the exact opposite of what you want - You want to fully understand what the code is actually doing. Internally, I forgo most abstractions. For public interfaces, I expose highly specific functions and datatypes rather than "generic" interfaces, and only the bare minimum. Variants should favor duplication over generalization when uncertain. It's up to the consumer of those APIs (which is often myself!) to choose whether or not to implement abstractions on top of those. In my experience, it's either super-obvious when it's needed or unnecessary if unsure - So you can usually push back abstraction up to that point.

</comment></comment></comment><comment><USER20> Using python, I tend to write much more procedural code than anything else - packages / modules / namespaces are much better for code organization and pure functions that don't hold state are just easier to reason about. Classes are used sparingly - really only when you actually should encapsulate some data or state, but generally they're not needed at all.

I've seen oop used as code organization too many times, and it's always a laughable mess.

<comment><USER21> Python functions are objects, instances of the function class, as this little snippet shows.

        def afunc():
            pass

        print(afunc.__class__)
        print(dir(afunc))

<comment><USER22> While technically a function is a class instance, it doesn't _act_ like one in pretty much any common use-case.

</comment></comment></comment><comment><USER23> I do agree that O-O design was fetishized starting in the 1990s and the results have been terrible. But this is strange to me:

> In fact, his essay ends by touting functional programming as the superior > alternative — a competing paradigm in which problems are modeled not with > objects but with pure mathematical functions and an emphasis on avoiding > changes in state.

O-O is a way of encapsulating abstraction. That's it. It could mean actors, message passing generic functions composition and/or inheritance. There's no reason you couldn't program in a purely functional O-O way.

I build hardware that uses a variety of different kinds of fasteners, and circuits with different kinds of components. I _could_ build all my logic circuits with only resistors and diodes (people used to do so, after all) but the fact that that's no longer a good idea doesn't mean I should try not to use resistors or diodes at all.

</comment><comment><USER24> Having been around this block (procedural->OOP->FP->...) a couple of times over the past 20 years, I've ended up at place where I always start with no classes and mostly pure functions, but don't shy away from adding small handful of classes when it becomes obvious that they solve a real problem. Sometimes objects really are the cleanest solutions, but they should never be your first solution.

</comment><comment><USER25> > In non-OOP languages, like JavaScript, functions can exist separately from > objects. It was such a relief to no longer have to invent weird concepts > (SomethingManager) just to contain the functions.

This is one of the things CLOS (Common Lisp Object System) got right: It's object-oriented but functions are not "owned" by classes; they're separate and first-class and generic and can dispatch on multiple arguments. In CLOS, classes are truly just user-defined types, and classes don't impede your ability to write functional code.

<comment><USER26> Is he seriously using Javascript as an example of non-OOP language?

<comment><USER27> Having the idea of objects does not make a language "object oriented."

Compartmentalization and encapsulation are fundamental concepts of objects and those concepts existed long before "OOP" did

<comment><USER21> That was called modular programming.

SELF, which JavaScript takes its model from, is definitely OOP.

</comment></comment></comment></comment><comment> Const-me OOP is the only way invented so far to deal with complex mutable state. Many practical problems have a lot of that.

OS kernels is one example. Right now, Windows task manager says there're about 100k opened handles in my system. The state of an opened file handle is huge: user mode buffers, kernel mode structures, encryption, compression, effective permissions, file systems B-trees, flash memory state, and more. Without hiding all that state behind an API, the amount of complexity required to write a byte to a file would be overwhelming. On Linux it's usually object_do_something(struct tObject *), on Windows it's DoSomethingWithObject(HOBJECT), it's 100% OOP, where objects are hiding their state behind methods.

GUI is another example. Whether it's a web page, a rich text document in an editor, or a videogame, the state is very complicated. GUI frameworks don't compute functions, they respond to events: from user, from OS, and from other parts of the program. All GUI frameworks are OOP, including web frontent ones, e.g. reactjs.org says "Build encapsulated components that manage their own state", it's a textbook definition of OOP.

</comment><comment><USER28> I feel like there are two effects here: Most code you will encounter in the workforce is poorly written or is now used in ways the author didn't intend. Because of it's popularity, most code you will encounter there is also object oriented.

The second effect is, pay and hire-ability is often linked to years of experience in languages and tools for developers who don't have large projects or exits on their resume. That means that you are incentivized to learn new up and coming tools and paradigms, where your years of experience can quickly become competitive vs more established technologies, where people have years of experience on you.

Now, I happen to also prefer functional programming because it seems to more closely match the way I think, and I find it easier to responsibly manage state in that style. But I believe that these two potential causes have a larger effect than my personal preferences. I don't know how to measure this though.

<comment><USER29> > most code you will encounter is object oriented.

Well - most code you encounter was written in a language that was designed for object oriented programming, like Java or C# (and, really, Python and Javascript). That doesn't mean it's actually object oriented or particularly well designed. I've been working mostly with Java for the past 20 years and every single Java-based system I've inherited has been the same big-ball-of- mud as the others, with almost every function declared static and classes declared because Java doesn't work if you don't type "class" somewhere. It's never reusable, never unit-testable, and never modularized.

</comment></comment><comment><USER21> Because it is fashionable to hate OOP and many don't understand that neither OOP == Java, nor none of the multi-paradigm languages eschews OOP rather embrace a mix of OOP and FP features.

Just like apparently, any FP language that has come before Haskell stop being FP, for whatever definition of what FP is supposed to be.

<comment><USER7> I don't think anyone is arguing that, say, Standard ML isn't a functional language, and if anyone did, they would probably be laughed out of the room.

<comment><USER21> Well, even on this thread FP is being discussed as a set of Haskell features, starting with the idea that all FP languages use immutable data only.

Which would make Standard ML not a FP language. :)

<comment><USER7> Then I guess we can start laughing at some people, yes?

<comment><USER21> It seems like so, but I rather prefer the quixotic way that some education is still possible.

</comment></comment></comment></comment></comment><comment><USER30> > 'Right tool for the right job' 'No silver bullet' 'Bad programmer write bad > code'

Those are all good tools to stop thinking/progressing and being comfortable ever after. But no, everyone knows those and they're not the answer to the question. 'No silver bullet' could only be true when accidental complexities are very small compared to core complexities, but it's far from the truth for nowadays industry.

OOP is bad because it's a foot gun. It forces people making strong assumptions by default. It's only a tool modeling static and mid-sized scale problem.

When the assumption is very strong it means behaviors in a class are strongly coupled, its relation to other classes are static and specific. And that's why people feel OOP is more understandable and readable - because OOP toys are very specific, thus readable.

And it's very vulnerable to change. To deal with that, people have to make less assumption, but every technique doing that have serious trade-offs - people have to choose. And those techniques are where all those obscure 'AbstractFactoryBuilder' came from. For the same problem, 10 people tend to have 10 different trade-offs, using different obscure solution, and 8 get burned in the next release.

For example, to modeling the concept Payment, in a mediocre functional programming language, it might be an algebra data type:

      type Payment = FreeCoupon | Cash Amount | CreditCard Number CVV

Every time you want to process a payment, just handle the three possibilities concretely, if there's duplication just extract it. If there are 100 functions operates the Payment type, it's perfectly fine just like Alan Perlis described. The type is perfectly natural - just what it should be. There is a very high chance people yielding the same result independently.

In so-called OOP, this probably be:

      class Payment
        getFoo()
        getBar()
        doBaz()
      class FreeCoupon extends Payment
      class Cash extends Payment
      class CreditCard extends Payment

In order to accept Payment type, you have to bend three sub-classes into the Payment interface. And there probably 100 methods for Payment, and the refactoring result would be totally opinionated, everyone has their own idea but none of them solve it without introducing new problems.

</comment><comment> yoz-y So much bashing on mutability. Yeah, I get it most of the time it's bad. But there are a whole lot of problem classes which are either unsolvable or painfully slow without mutable data.

</comment><comment><USER31> Rich Hickey: "By default, an object-oriented program is a graph of mutable objects. That's a very, very difficult thing to think about, debug and keep running." Basically OO is exactly the worst to deal with increasing complexity.

<comment><USER32> Every programmer should at least get some familiarity with Clojure. It maintains extremely good balance between simplicity, pragmatism and safety.

</comment></comment><comment><USER33> Done right - a focus on composition, message passing, little to no inheritance - I find OOP a joy to work with.

It's almost never done that way...

</comment><comment><USER34> In my anecdotal experience, attempting / allowing "true OO" programming turns quickly into an unreadable, unmaintainable, unreliable ball of mud. After leading a team of ~30 developers in a monorepo for the past 5 years, I have been relatively successful in avoiding complete software entropy by enforcing the following "code commandments":

\- Modular, layered codebase (for ex: interfaces -> service layer -> DAO layer)

\- Business Logic resides in Service Layer

\- Service Layer made up of collection of Transaction Scripts ([https://martinfowler.com/eaaCatalog/transactionScript.html](https://martinfowler.com/eaaCatalog/transactionScript.html))

\- Simple, immutable domain model, with distinct set of immutable objects for each layer. Unapologetically, this is an "Anemic Domain Model", but with separation and no re-use between layers. This allows for immutable objects at each layer.

\- Services are decoupled and composed around the data / logic, thereby "owning" their own data. Services can communicate with each other to get data, DAOs are never to be shared among other services. This is in a sense, "microservices without the network".

\- Testing at every layer, while respecting the "test pyramid" ([https://martinfowler.com/articles/practical-test- pyramid.htm...](https://martinfowler.com/articles/practical-test- pyramid.html)). Bang for buck is important here.

\- Last, but certainly not least: _Composition Over Inheritance_.

</comment><comment><USER35> > What happened in most of the world starting in the 70s was abstract data > types which was really staying with an assignment centered way of thinking > about programming and I believe that... in fact when I made this slide C++ > was just sort of a spec on the horizon. It's one of those things like MS-DOS > that nobody ever took seriously because who would ever fall for a joke like > that.

\- Alan K

I don't hate on object oriented programming, but when I come across videos like this [https://www.youtube.com/watch?v=oKg1hTOQXoY&feature=youtu.be...](https://www.youtube.com/watch?v=oKg1hTOQXoY&feature=youtu.be&t=3315) it is good enough reason for me to question OOP and explore alternatives.

I will say though... in my limited sample size of coworkers, it is more fun to work with people who attack OOP than those who defend it. But the best people to work with are those who don't get emotional about programming ideologies.

</comment><comment><USER36> OOP's strengths are coupled-but-separately-evolving components. An app, the platform it runs on, plugins it uses, etc. all needing to talk to each other. This forces you to think hard about the interfaces between components, and how those interfaces themselves can evolve. OOP is good at expressing this sort of thing.

If you assume you have all of the code, then interfaces and their evolution don't matter so much. You can just refactor at will. OOP can't bring its strengths to bear.

The web has shifted things to the "all of the code" assumption. Servers are routinely self-contained. The browser's APIs are anemic and so are supplanted by third party JS frameworks like React. These frameworks are version-pinned by each site and bundled together into a single file. And when upgrading, it's just accepted that there will be pain and incompatibilities.

</comment><comment><USER37> Managing state is hard. OOP expects state. OOP can make things harder than necessary.

Languages with both first class functions and class semantics are nice, because they allow you to choose the right tool for the job.

Inheritance is way overrated as a tool though. Great for the bouncer ball sprite exercise, otherwise a bother.

</comment><comment><USER38> To me, the pain I've always had with OOP is the amount of things I need to keep in mind at a time when making a change, and also tracking side effects. That mental overhead takes me away from thinking about what my customer really wants with this feature, and slows me down.

<comment><USER29> > the amount of things I need to keep in mind

Minimizing the number of things you have to keep track of when you make a change was specifically what OOP was designed for... what's the alternative? Procedural/structured programming is _way_ worse. I think FP is better, but it's so hard to do that I've never worked with anybody who hadn't given up on it before I had a chance to really tell.

<comment><USER39> Out of curiosity, what did you find hard about it?

<comment><USER29> Functional programming? I haven't honestly had a chance to use it long enough to find it hard: every time I've worked in a group that was even willing to give it a chance, everybody else gave up before I had a chance to make up my mind whether it was harder/easier than OOP. I personally kind of like the functional aspects of Java, Javascript and Python (although I still don't have the first clue what a "Monad" is).

I've been working primarily in Java for the past 20 years, across four different companies, and as far as I can tell, most everybody gives up even on OOP, too: every system I've ever worked on that was written by somebody else was 90% static functions & static data, with a few "dumb object" data types just because that's what you get from JAXB.

<comment><USER7> > I still don't have the first clue what a "Monad" is

This is the simplest way I have yet found to think about them: [http://madhadron.com/posts/2013-12-05-email- about_monads.htm...](http://madhadron.com/posts/2013-12-05-email- about_monads.html)

</comment></comment></comment></comment></comment><comment><USER40> When I lived in Solana Beach California, one of my two tech guru neighbors used to (25 years ago) pontificate on how OOP was the 'last programming paradigm.' He thought there would never be anything better. It was the only thing, ever, that I thought he was wrong about. (My other tech neighbor was Stash Lev. He sold the 68030 replacement boards, with good gloating point performance, for the original Macintosh, a wonderful thing indeed! Apparently Stash was never wrong about anything.)

I don't hate OOP, I just dislike it. I currently use three programming languages, Common Lisp, Haskell, and Python. I don't generally use Python classes or CLOS unless I am working with someone else's code.

Purely functional code, when possible, and also immutable variables avoid many problems.

</comment><comment><USER41> An OOP approach is fairly straightforward to understand when you've got state and need to control how it's modified.

A functional approach is fairly straightforward to understand when you need to describe how state (maybe yours, maybe someone else's) is modified.

A place for everything.

</comment><comment><USER42> As a person heavily invested in OOP, is there any good reference (book preferably) about Functional Programming?

I know there must be lots of resources, but finding a good one can be difficult when you are new to a field.

<comment><USER43> Programming Elixir is a good one - [https://pragprog.com/book/elixir/programming- elixir](https://pragprog.com/book/elixir/programming-elixir).

It's (obviously) about the Elixir programming language, but was a pretty good introduction to functional programming for me, as well. As was working through problems on [https://exercism.io/](https://exercism.io/) in Elixir and Clojure.

<comment><USER44> This was my introduction to functional programming. The nice things about Elixir for learning functional programming is that it's not nearly as complicated as haskell, feels more familiar, and dynamically typed.

I'd recommend this book as it teaches how to think about solving things by writing recursive functions (Elixir/erlang has tail call optimization), pattern matching, etc. No need to learn the OTP concepts (genserver, supervisors, etc).

</comment></comment></comment><comment><USER27> The further we abstract ourselves from understanding of the platforms our code runs on, the worse off we are going to be.

Our job as developers is to write software that transforms data from one form to another. Any code that does not go directly to solving the transformation problem you have for the data you have is wasted time and wasted effort today, and will cost you additional time in performance and maintenance so long as that software is in service. The best code, the most big-free code, the most stable code, is the code that doesn't exist because it didn't need to be written in the first place. Browse an Enterprise Java application and tell me that there is no code there that couldn't have been written much more succinctly and run much faster in another language.

Software development is not an art. It is a science - everything about programming and software execution can be measured and therefore measurable improvements can be observed. Almost no one does this -- why? Because of the "CPUs are cheap" and "RAM is cheap" excuses I have heard throughout my entire career.

I have never even heard of a study of OOP that found OOP to be a superior methodology in any meaningful way whatsoever, and I don't think I ever will. I don't think that result could ever be observed without a very strong bias in the study.

<comment><USER45> Just to tackle your first two paragraphs: I hate to say this, but this impression may just be a lack of experience on your part. It's not wrong exactly, just a very narrow view of the range of work that gets done with software.

To bastardize a better quote: All abstractions are leaky some are useful.

Even assembly is an abstraction. And if you're working on tuning to nanos maybe that's the problematic abstraction. But I'd say enough worthwhile work gets done on top that it is a successful abstraction.

I think that's fair to claim all the way up your stack. An OS is worth it, even if you do have to fight it once in a while. Same with processes. Or the JVM. Or even _gasp_ OOP classes.

They don't need to be sacred to be valuable.

<comment><USER27> Ok, so add as many abstractions as possible?

I didn't say they were bad, I said we add far too many.

</comment></comment></comment><comment><USER46> I have tried out functional programming various times over the years. Over one span of some months I used OCaml to create something interesting. Maybe an OWL parser. That convinced me that something like ML was far superior for parsers.

And I have experimented a few other times, such as with LiveScript.

The last time I tried to stick with a functional design was maybe a year or two ago. I ended up repeatedly passing around a lot of parameters so that many functions had several parameters. For example, in order to make a decision, I had to analyze something in several ways, collect that analysis, and make a decision based on all of the variables in the end. So the parameters just started building up until the last function had like a dozen of them.

Then I grouped some of them into structures, but the functions that operated on those structures had a few names parameters which were named in the decision function. So even though I had fewer inputs to the decision, the function body was complex with numerous parameters.

This led me to use classes to encapsulate the state so that parameters did not always need to be passed at the end since they could refer to internal state.

</comment><comment><USER47> The issue is that we don't _need_ OOP anymore--people forget that OOP had its heyday when memory and performance were much smaller.

Passing a big list around, doing something to it, and passing back the entire list is no big deal today.

It's a much bigger deal if you have to do some weird decompression/insert because your main memory isn't large enough to hold the whole thing uncompressed. You need a "gatekeeper" to the single thing--and you may need coordination between the "gatekeepers" so they don't decompress simultaneously.

Or, you build a huge hierarchy of objects into a GUI because you don't have the memory to store the rendering state of each one so you want to be able to look it up from it's parent.

Oh, and you only have one thread.

In an era of gigantic memory and dozens of threads, the "advantages" of OOP simply don't make sense.

<comment><USER48> This argument does not make sense.

The more data you have, the more structure you need to help organize it.

</comment></comment><comment><USER49> I'm not sure what point the first comparison example in the original article by Ilya Suzdalnitski is trying to make. If you're going to cherry-pick an example that demonstrates complex and abstract OOP paradigms ( factory/repository patterns, serialisation, etc ) then the author should demonstrate how to address the same requirements that these patterns address in FP. It's also quite rich that they're using Javascript to illustrate their point. Javascript does not require the same OOP 'cruft' that languages like C# and Java _might_ require in _some_ situations. So crafting the most complex OOP-esque spaghetti you can think of in a multi-paradigm language is a disingenuous comparison at best.

</comment><comment><USER39> The problem with OOP isn't the concept itself. IMHO, the problem seems to stem the fact that people use a "Class" as both a means of organizing code and as a state machine. When you confuse the two, problems just get exponentially worse.

<comment><USER50> That _is_ the concept of OOP - that you package together the data (state) and the functions that can operate on that data.

<comment><USER7> Users of multiple dispatch OOP languages (Common Lisp, Dylan, CLOS, C++ STL) would disagree vehemently with this characterization.

<comment><USER50> Well, I'm a C++ STL user, and _I_ agree with me...

Could you be more specific about 1) in what sense you call C++ STL multiple dispatch, and 2) why you think it disagrees with what I said?

<comment><USER7> If you bundle functions and data, you end up implementing M functions each on N types, or M*N. If you can separate your functions and your data, you implement M functions and N types, or M+N. This is an explicit design goal of the STL and Stepanov's research that led to it.

Similarly, Stepanov was explicitly trying to be able to write a polymorphic max function `T max(T a, T b)`. That is, the instance of the max function actually used is chosen based on all the arguments, not solely on the first, which is the definition of multiple dispatch.

C++ also has a single dispatch object system, and the STL even mixes them, putting things like vector::push on the class with the single dispatch system and the STL algorithms in the multiple dispatch system.

</comment></comment></comment></comment></comment><comment><USER48> > Why Are So Many Developers Hating on Object-Oriented Programming?

Fetishism, pure and simple.

Every language provides some apparatus to help organize programs. Some have more, some less. With less, you have to build your own, because everybody needs help keeping things organized.

Bad code fails to use what is there, or misuses it and makes things worse. There is lots of bad code, because too few love simplicity, so everything gets in the way of everything else.

Blaming OO should remind us of the old adage, "A poor craftsman blames his tools".

People hating OO seem to be Lispers bitter that Lisp does not occupy the place OO languages do. There are not as many as might seem around here, just because most of them are around here.

<comment><USER32> What? Lispers don't hate OOP. Take Clojure for example: it is a FP lang, but deals with OO stuff better than OOP langs. Also: good craftsman knows how to choose a right tool for the job. And bloated OOP languages are often not the right tool.

</comment></comment><comment><USER51> Functional programming combines the power of abstract mathematics with the ease of understanding of abstract mathematics.

Now if you'll excuse me once I complete my Ph.D. dissertation I might be able to finish my text editor I'm programming in Haskell.

<comment><USER32> Haskell is not the only FP lang. Clojure, Elm and Elixir do not require understanding of abstract mathematics.

Beside that, basics of category theory is far easier to grok than OOP Design patterns.

<comment><USER51> > Beside that, basics of category theory is far easier to grok than OOP Design > patterns.

I know high-school dropouts and graduates from DeVry University who understand design patterns. Category theory--even basic category theory--isn't taught to undergraduate math majors (except maybe at MIT to honors students).

I mean, I appreciate functional programmers who want to do it because it is hardcore... but that's why they do it: because it's hardcore.

<comment><USER32> > I appreciate functional programmers who want to do it because it is hardcore

That's a misconception. Functional programming makes so many things so much simpler. I know, Haskell can be seen as an impractical exercise for the sake of tickling your prefrontal cortex. But again: there are other functional languages, e.g.: Clojure - it is simple and allows you to get things done in a pragmatic, reasonable and relatively quick fashion.

<comment><USER51> Recursion is the worst way to do iteration because it requires cleverness (= harder to debug) and it's ridiculously easy to cause a stack overflow. A for- loop is not going to cause an integer overflow on a 64bit architecture.

Closures are basically global variables and inherit all of the problems with global variables.

Continuations are basically goto's or memcpy and inherit all of the problems with goto's and memcpy.

Functional programming is ALL of the bad programming practices of the '80s. But because it's more abstract and mathematical it gets a free pass. Nevermind the fact that computer science is not mathematics. And the benefits of mathematical abstraction DO NOT TRANSFER if they inherently violate the commandments of bad ideas like global variables and goto's.

There are solutions to ALL OF the object oriented problems--including the diamond problem, circle-ellipse problem, and overuse of type hierarchies. There are no solutions to the functional programming problems because they inherently incorporate bad ideas described in paragraphs 1, 2, & 3.

<comment><USER9> > Recursion is the worst way to do iteration because it requires cleverness

No, it doesn't; in fact, recursion is usually much easier to reason about, particularly in terms of termination.

> and it's ridiculously easy to cause a stack overflow.

It's ridiculously easy not to, just assure your recursive calls are in tail position and you are using a language that supports tail call optimization (which essentially every dedicated FP language and a number of others do.)

> Closures are basically global variables

No, they aren't even similar.

> Continuations are basically goto's

Not really. They are similar in that they are a more powerful (and, therefore, dangerous if used incorrectly) flow control concept than simple function calls, but they aren't equivalent to gotos.

> Functional programming is ALL of the bad programming practices of the '80s.

No, that's unstructured imperative programming (though some structured languages preserved some of them.)

<comment><USER51> Closures are as hard to reason about as global variables are. Anywhere the function with the closed variable is called, that is the same thing as invoking a global variable, because that function could be called anywhere in the entire program. The difference is that the garbage collector deletes it when no function is calling it any longer.

Continuations are equivalent to memcpy... which should almost never be used. And tail-optimized recursive functions are still difficult to reason about.

And tail-call optimization (making stack calls constant) is... kind of self- defeating... because the only advantage of recursion is that it has a stack built into the function call/return operations. Anything a recursive algorithm can do is equivalent just a for loop and a stack data structure. And if you're tail-call optimizing it so that it has a stack parameter... then you're just using a clever way to write a for-loop :D Except functional doesn't allow for you to mutate a preexisting stack so you're also wasting space recreating a new stack each function call.

Yeah. Abstract math almost rarely transfers directly to the computer world. There's a reason why the pure functional & concurrent language Erlang was only used in telecoms and languished in obscurity: because that was the only domain it worked well in.

</comment></comment></comment></comment></comment></comment></comment><comment><USER52> I found this video by Brian Will was interesting when I was trying to learn about OOP[1]. It begins with some arguments, and there is a series of videos that follow where he attempts to illustrate the point. One of his newest videos is about an alternative form of OOP that he thinks works better.

[1] [https://www.youtube.com/watch?v=QM1iUe6IofM](https://www.youtube.com/watch?v=QM1iUe6IofM)

I assume that OOP is only meant for very large programs, and he unfortunately only demonstrates his ideas in smaller programs.

edit: added video author's name

</comment><comment><USER53> Sorry that this is a bit meta, but I don't think links from thenewstack.io are good to post because of their Yelp-like tactics. They have a history of shaking companies down for cash. Years ago I worked at a company that was paying them tens of thousands per year, and when we stopped that because we saw absolutely no measurable return, they retaliated by writing an unfriendly article.

They are scummy, and I hope you don't learn this the hard way!

</comment><comment><USER54> My take on why OO - as usually taught and practiced - is problematic: [https://link.medium.com/GEgk2vjLpZ](https://link.medium.com/GEgk2vjLpZ) In short: it requires a lot of up front design and abstract thinking, plus the idea to architecture a program around state distributed over a large number of objects is fundamentally flawed.

</comment><comment><USER55> These discussions are a bit tiresome. The major reason is of course "because its popular." There's plenty of merit to OOP and there are certainly pitfalls. OOP dominates the popular languages so you see the pitfalls most frequently. The grass is always greener, etc.

It's not like any of these discussions about time to deliver or complexity are based on statistical analysis.

</comment><comment><USER56> I've grown so weary of dogmatism. Absolute answers are pretty much never universally correct.

OOP is good for some things. FP is good for some things. Usually a project has both kinds of things. If you ask me, pick a language like Rust, JS, Scala, or Python that's competent in both and use the pattern that's right for what you're trying to express in any given piece of code.

</comment><comment><USER57> Because it's a constant mental struggle to keep everything in mind when doing "classic OOP". Inheritance, mutability, weak type systems with nulls. All that adds to the mental overhead.

It _is_ possible to program in a classical OO language without so much struggle but it requires a level of discipline that takes 10 years or more to aquire.

<comment><USER7> I like the old metaphor of languages that are "programmer amplifiers" (usually applied to Lisp, Forth, Smalltalk...). But the amplifier increases the noise and problems as well as the good parts.

</comment></comment><comment><USER58> For me, it's:

1\. Because OOP lends itself more towards bloat with lots of boilerplate to obscure what happens.

2\. Often stuck with what somebody else thought were the best abstractions - while they weren't, or they were for them but aren't for what I'm working on.

<comment><USER48> You seem to be describing Java. Very often people complaining about OO are really complaining about Java.

Java code is necessarily bad code, or at best mediocre code.

<comment><USER58> Also a bunch of object-oriented C++. To be fair - I've never written C# or SmallTalk, so I don't know what those are like.

</comment></comment></comment><comment><USER59> People are less complaining about OOP itself and complaining about inheritance and polymorphism. If you've spent any time trying to figure out which method is called by a python object then you'd generally agree.

</comment><comment><USER60> Dead end career "architects" going OO crazy with inheritance, factories, unessicary interfaces, ... instead of helping write more performance code or deleting code.

</comment><comment><USER61> Another day, another entry in that one _decades_ old flamewar.

Each paradigm has its place.

</comment><comment><USER62> If you wish to learn French, Rust, Chinese or Java you can pick up a rule book in your native language and get a grasp of the language.

If you wish to study code, what most people don't realize is that it's a new language. It doesn't matter if it's written in a language you're familiar with. You need to understand the domain, you need to understand the structure of the code, the naming of the variables. That's a whole other language. Most developers have to infer this new language by reading code. Imagine learning a new language by reading a book written in that language. That's why Domain Driven Design is popular in the OOP camp, talks about Ubiquitous languages and bounded context. That's why DSL is popular in the functional camp, why Lisp fans are crazy about Macros. It doesn't matter what the language is, if you want to make your code a joy to work with. You need adequate documentation of the code structure before folks dive into the code.

Imagine a student with no experience trying to learn about the Linux kernel strictly by reading the source code compared to a student who first reads a book on the Linux kernel then dives into the code.

This is what APL was hoping to solve and was pushing by "notation as a tool of thought", but then it brought it own set of problem. APL is like Chinese, Chinese notation is a tool of thought. You can read one Kanji and gain so much from it, but you have to learn the damn notation first.

The only language that comes close is Declarative logical languages like Prolog, but yet they suffer from some of the other faults and only holds logically in closed-world assumption. Written by humans, so improper naming can misleading too.

What's the solution for all? NOTHING! Some Developers will always hate on whatever you use if you make them work harder than they want to.

With that said, the article was spurned by Ilya Suzdalnitski, who only seems to care about medium claps. He wrote an article [1] about how OOP is a trillion dollar disaster, then in about 2 weeks about [2] functional programming sucks and is a toy and his solution was OOP. This is someone who's happy to straddle the fence so long as he gets views.

1 [https://medium.com/better-programming/object-oriented- progra...](https://medium.com/better-programming/object-oriented-programming- the-trillion-dollar-disaster-92a4b666c7c7)

2 [https://medium.com/better-programming/fp- toy-7f52ea0a947e?so...](https://medium.com/better-programming/fp- toy-7f52ea0a947e?source=post_recirc</comment><comment>---2</comment><comment></comment><comment></comment><comment>)

<comment><USER63> > then in about 2 weeks about [2] functional programming sucks and is a toy > and his solution was OOP.

which is clearly satire:

"PS> As most of you have guessed, the post is a satire. To all of the new developers out there — don't take this seriously, FP is great!"

</comment></comment><comment><USER64> Classes work well as interfaces to data. Thinking of a class as a mini database makes a lot of sense.

Putting in anything complex that isn't directly related to managing the data contained is where things start to fall apart.

Data formats are great. Simple data formats don't have to have dependencies, just an interface to take out the details of accessing it. This is how software communicates. Don't forget that the most used interprocess communication is the file system.

Classes are not modular just because they can be wrapped up between two braces. Dependencies destroy modularity and this definitely includes inheritance. Complex data transformations that communicate using data formats they both understand are how programs are made modular. Classes are a very useful way of dealing with data formats.

</comment><comment><USER65> It's an excuse to over-engineer. OOP encourages developers to over-think object hierarchies and build baroque code that is prematurely generalized.

There is nothing intrinsically wrong with OOP and it maps well to certain problem domains. The problem is the tendency of sophomore programmers to over- engineer everything.

<comment><USER66> > OOP encourages developers to over-think object hierarchies and build baroque > code that is prematurely generalized.

How does it encourage exactly? In my experience sophomoric programmers are just as capable of over-engineering in a functional environment. Seems more a function of cargo-cult behavior than anything else.

<comment><USER67> How does one "over-engineer" a functional environment? By breaking functions down into even smaller pieces? By minimizing side-effects even further than before? These are all good things to do no matter what.

My one and only issue that I have with the "design"-side of FP is that it can be tough to organize multiple functions in an intuitive way. (The "soup of functions" effect, essentially).

It makes coming on to a new codebase tedious to trace, but I'd still rather than dealing with spaghetti OOP.

<comment><USER68> You can over-engineer point free style to create an uncomprehensible code base. Point free style with more than 1 unapplied parameter is basically a nightmare.

[https://wiki.haskell.org/Pointfree#Tool_support](https://wiki.haskell.org/Pointfree#Tool_support)</comment></comment></comment></comment>


Show HN: Covid-19 interactive map for each US county/state based on NYT dataset - <AUTHOR> https://www.covid19usmap.com <comment><USER2> Nicely done, you have normalized population data! Would you mind defaulting to displaying your cases normalized by population though for the choropleth? Counties aren't uniform, and so you get wildly confusing results from showing absolute data ([1] has a great set of examples).

[1] [https://www.esri.com/arcgis- blog/products/product/mapping/ma...](https://www.esri.com/arcgis- blog/products/product/mapping/mapping-coronavirus-responsibly/)

<comment><AUTHOR> For sure! Often times the COVID19 choropleths often look like population maps due to lack of normalization. We added the normalization map to try and address this. Will change the default then. Thanks for the feedback.

<comment><USER3> The data available for Colorado also includes the number of tests performed, and number of cases requiring hospitalization. If that information is uniformly available, you might consider incorporating it.

[https://drive.google.com/drive/folders/11ulhC5FwnRhiKqxDl6_9...](https://drive.google.com/drive/folders/11ulhC5FwnRhiKqxDl6_9PnSMOjCWnLPB?usp=sharing)

<comment><AUTHOR> This is great. Thanks for sharing. Will look into finding a uniform dataset with testing and hospitalization data.

<comment><USER3> Also, take a look at the graphic on case doubling time here:

[https://www.nzz.ch/panorama/die-wichtigsten-grafiken-zum- cor...](https://www.nzz.ch/panorama/die-wichtigsten-grafiken-zum-coronavirus- ld.1542774)

It could be helpful to see that with state level data.

</comment></comment></comment></comment></comment><comment><USER4> Someone should make a map of all the COVID-19 maps that bored devs have made.

</comment><comment><USER5> Very cool!

The open source bioinformatics community is having a massive hackathon this week (400+ participants). Might you be able to join the effort and post a link to this project on the wiki [1] or in our Slack discussion?

You may find many other folks interested in collaborating!

[1] [https://github.com/virtual- biohackathons/covid-19-bh20/wiki](https://github.com/virtual- biohackathons/covid-19-bh20/wiki)

</comment><comment><USER6> Your site is giving me an SSL cert error. You might want to check your config and/or update your certificate.

<comment><USER7> Certificate is perfectly valid for me. I'm not the OP but curious: what error are you getting?

<comment><AUTHOR> It is valid for me as well, but I have heard of certification errors from people I have sent it to. We have the SSL certificate and we are using https. Any suggestions on how we would go about fixing this?

<comment><USER6> I have no idea what, if anything you did, but it works for me now.

</comment></comment></comment></comment><comment> 100-xyz Nice job. I was looking for something like this. Bookmarked.

<comment><AUTHOR> Happy to help! Thanks.

</comment></comment><comment><USER8> Nice! Which visualization tool has been used here?

<comment><AUTHOR> Thanks! We are using Mapbox GL JS and Chart.js</comment></comment>


Show HN: Task.js – Isomorphic work distribution across all cores - <AUTHOR> https://github.com/icodeforlove/task.js?hn <comment><AUTHOR> I found this later [https://github.com/adambom/parallel.js](https://github.com/adambom/parallel.js)

But I was happy to benchmark the work processing/handling speed.

node.js results

# 1000 messages

\- 88.362ms - task.js (warm) - 144x faster

\- 227.758ms - task.js (cold) - 56x faster

\- 12785.515ms - <USER2>

clientside results were similar

# 1000 messages

\- 361.251ms - task.js (warm) - 83x faster

\- 473.897ms - task.js (cold) - 63x faster

\- 29999.335ms - parallelize</comment>


Back to the future (rethinking interactive programming) - <AUTHOR> http://dynamicaspects.org/blog/2012/05/15/back-to-the-future/

<comment><USER2> Before anybody gets confused, dynamic programming is <http://en.wikipedia.org/wiki/Dynamic_programming>. This page is _not_ talking about dynamic programming, but rather interactive programming.

<comment><AUTHOR> You're right, I thought that it might be a problem but since the name of the blog is "dynamic aspect" I decided to go with "dynamic" rather than "interactive" (in the sense of dynamic language not dynamic programming). But since you brought it up, I fixed the link title.

</comment></comment><comment><USER3> Also on Reddit: [http://www.reddit.com/r/haskell/comments/tokmh/interactive_p...](http://www.reddit.com/r/haskell/comments/tokmh/interactive_programming_with_lambdacalc/)

</comment><comment> sasha-dv _I know not of these "end users" of whom you speak. There is only programming._ \- Unknown programmer of the future

 _Sometimes, I wonder if we live on the same planet_ \- me

I'm not trying to be a dick, but that "quote" at the beginning of the article is just absurd. The "end users" would form an angry mob, drag that programmer out of his Ivory Tower, and kick his ass.

I think you seriously overestimate the interest of the end users in programming. End users want that the damn thing do what it is supposed to do, and go home to their lives. They don't want an interactive programming environment - they want a button to push and be done with it.

<comment><USER3> _End users want that the damn thing do what it is supposed to do_

Which often requires programming, in some form or another. The need for end- user extensibility is documented¹, and remember that VisiCalc was one of the reasons for the uptake of the PC.

¹ <http://ccs.mit.edu/papers/CCSWP181/>

<comment> sasha-dv I think that the end users you're referring to are just a minor subset of the end users I had in mind.

Let me give you an example of an average end user.

This guy calls the customer support (via skype) and complains that he has no internet. He says that skype is working, uTorrent is working, but he has no internet. Obviously, his network connection is OK, but he's not stopping with "there's no internet!"

Can you guess what's the problem?

The guy who sold him the computer also explained to him how to use skype and how to pirate movies (that was what he cited as his reason for buying it in the first place). So far so good. One thing he also did was to setup yahoo.com as the homepage for this guy.

Searching for porn and free goodies, our customer installed some malware that hijacked his browser and change his homepage from yahoo.com to something else. And suddenly, "my internet is not working". This guy is asking us what button he needs to click on to get his internet back. For him, internet is having yahoo.com as the homepage.

I'm not making fun of this guy. I've met a ton of similar cases. What I've learned is that people are not interested in how it works, they just want it to work so that they can use it for pirating movies or any other thing they use their computers for. They want you to hide a complex functionality behind a simple button they need to click on.

Same disinterest I've encountered while developing custom software. The customers simply don't want to mess around with the software. They want to enter some data and click on the button. For anything else they prefer to call you so that you can make that button do something else. This may be anecdotal evidence, but I'm yet to encounter a customer who wants me to build the kind of software you're describing.

</comment></comment></comment><comment><USER4> I find toy examples not very convincing.

<comment><USER3> You have to start small to do big things.

Check out this paper for more - I find it highly interesting:

<http://dynamicaspects.org/papers/PADL2010Final.pdf>

<comment><USER4> I fear that it does not scale to anything that can be used to develop actual software with.

The level of 'equal' is not convincing.

<comment><USER3> I find this funny coming from someone whose handle is "lispm". You probably would have found McCarthy's original Lisp demo¹ unconvincing, too. Think about it.

¹ <http://www.paulgraham.com/mcilroy.html>

<comment><USER4> 'Symbolic Integration'? Sounds a bit more interesting than 'equal'.

Lisp was quickly used to program complex stuff, even on tiny machines. McCarthy's group worked on AI stuff like game playing, theorem proving, language understanding, ...

In the early 60s the first self-hosting compiler was a Lisp compiler written in Lisp.

Or see the work on symbolic integration by Joel Moses: [http://www.softwarepreservation.org/projects/LISP/MIT/MIT- LC...](http://www.softwarepreservation.org/projects/LISP/MIT/MIT-LCS- TR-047-corrected-ocr.pdf)</comment></comment></comment></comment></comment>


Ask HN: Where can I buy real software companies? - <AUTHOR> So I have a software company that is generating a good amount of cash. I'd like to buy another small software company and (ideally) optimize it and make some more money.<p>Problem - most of the sites, like flippa, have crap businesses for sale.  Is there a real place that one can find $50k - $500k software businesses for sale?  Side projects that people make money from but don't have the time for? <comment><USER2> I sold Bingo Card Creator through FEI ([http://feinternational.com](http://feinternational.com)) and have nothing but good things to say about them. Something like 20% of their listings are SaaS businesses. The going rate for a SaaS business is roughly 3X yearly SDC ("seller discretionary cashflow" \-- revenue minus costs _required_ to run the business as opposed to e.g. the owner's salary, distributions, interest expense, etc). It is closer to 2X for software businesses where the revenue is not by-nature recurring. (Naturally, these are guidelines -- businesses are, like all things, priced at where a buyer and a seller can mutually agree, and certain factors can make buyers very agreeable.)

<comment><USER3> Could just be me but it feels like feinternational always show a very inflated price. 3x seems too much specially for companies that are barely 1 year old.

Also, it is extremely difficult to sign an NDA just to inquire more about a sale as feinternational does not give any details upfront. Totally understandable that the company in question wants to maintain its privacy, secrets etc but this is a difficult situation. How do we move forward without knowing more about a company but they want you to sign NDA even without giving _any_ details.

<comment><USER4> 3x doesn't seem bad at all. It's like an investment that generates 33.3% annually. After 3 years it's all free money.

<comment><USER5> It's counting the founder's salary as profit. In these small businesses? founders usually have to do a good bit of work. what do they say? you are buying yourself a job?

if you're making 33.3% of $50k-$500K per year... the very top end of that is close to what you'd get working for someone else, and usually you don't have to put down a half million to get those jobs.

So, while I don't think I'd sell you my company for 3x SDC, I completely don't blame you for wanting to pay less than that. It'd really only make sense if you were sure that I had things setup to the point where I didn't have to do any work (which is something I can deceive _myself_ about... I don't see how you could get a solid answer out of someone who had an interest in deceiving you.)

<comment><USER6> "you are buying yourself a job?" Bingo. And the prospect of growing the business to a point where it can sustain a team and be less reliant on you.

If the business can run without any input from the founder a) why would they sell it? and b) if they did they would sell at a much greater multiple.

<comment><USER7> People might need to sell companies because of:

1) sudden financial hardship like hospital bills

2) a divorce court judge ordered it

3) a non-founding owner has no emotional attachment and wants to switch to another investment.

Online companies that produce passive or near-passive income are bound to become obsolete quickly. The internet moves quickly in a lot of niches. The potential lifespan of the business affects the multiple.

<comment><USER5> Your fourth option, I think, is the most important one to understand here. Just about any business, assuming you have a competent employee or two, can kick along without your input for a while. But without you, the owner, actively putting in work? it's going to do worse this year than it did last year. It's gonna fade pretty fast. And yes, if you do need to ignore it for a while, selling it to someone who won't ignore it is a good option, too.

But it's just plain wrong to think that you can look at the current numbers and assume they will go forward without more input from the owner.

I would argue that the whole idea of 'passive income' when combined with the idea of a 'small business' is a little flawed, or really, a lot flawed. Owning a small business is not like owning stock in google. You are an active participant in the business. A small business owner is fundamentally different from someone who owns shares in a large corporation.

I kind of like using marxist terminology for it. We are bourgeois[1]. We are not full members of the capitalist class; we still need to combine our labor with that capital, or else it's all gonna go to shit pretty fast.

But the real takaway you need to understand is that owning a small business is not at all like owning stock in a large business. It's a completely different thing, and your return on investment capital should be very different (and in my opinion, much higher.)

[1]no, not necessarily in the 'poor taste in lawn furniture' sense. I don't even have a lawn.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Like Patrick, I also sold my company through FEI ([http://feinternational.com/](http://feinternational.com/)) last Fall. Once we got all our information in place, the process went very quickly. We had several interested parties and due diligence calls almost immediately. After that, we had 3 offers. There were a few unexpected hiccups (I think there always are with acquisitions) but overall the process was very smooth and I'd use them again. I'd recommend registering with them and getting to know one of the brokers. They'll start sending you deals as they come in.

A few recommendations based on my experience (YMMV):

\- Cash is king. While you should definitely structure the deal with a transition period, an all-cash offer carries more weight than a deal where you are financing some/all of the price. You'll need to show proof of funds too, so make sure you can do that easily.

\- Get your attorney on standby. You'll probably need help with offer letters and purchase agreements. Plan on going through a couple rounds of revisions for both.

Feel free to email me if you have more questions.

</comment><comment><USER9> You will probably want to work with a business broker. These are two that I know of that have a listing of businesses for sale:

[http://feinternational.com/buy-a-website/](http://feinternational.com/buy-a- website/)

[http://empireflippers.com/marketplace/](http://empireflippers.com/marketplace/)

It seems like the best deals come through old fashioned networking. Maybe look at several businesses that would compliment your existing product and get in touch with the owners?

</comment><comment><USER10> I work at Axial ([http://www.axial.net](http://www.axial.net)) and this is what we do. Check us out and if it seems interesting, submit the form and someone will get back to you.

(Caveat: the size of the business you're looking for is on the lower end of the deals on Axial)

</comment><comment><USER11> Most businesses are for sale if the price is right.

I've sold an app before where I just got a phone call from an interested party (without it being listed for sale anywhere), agreed on a price and just a few weeks later the transfer was complete.

If anyone wants to buy candyjapan.com for 4x profit, feel free to contact.

<comment><USER12> I'd love to buy Candy Japan! But it doesn't make much sense for me, and I don't have the money to pay for it - but I would honestly put in an offer if the contacts/network for supplying the candy and such was well set up and going from your blog posts about your journey so far, that probably _is_ the case.

Keep up the excellent work Bemmu! :-)

</comment></comment><comment><USER13> I would like to sell my business. You'll need to know C++ and care about the Windows desktop market. I get about 8K downloads every month. I want $225K which is 5x revenue.

I don't know if I'm entirely serious. It just makes money and I don't work it properly. It should make $90K-$110K if someone cared about it.

<comment><USER14> I know C++ and care about the Windows desktop market but don't have that money. Out of interest, what software is it? What sort of market? Do you need assistance or another developer?

<comment><USER13> email me, look at my profile.

</comment></comment></comment><comment><USER15> (slightly OT) I don't understand Flippa; I've search several times for a regular web site making a bit of money and all of them look like scams, even the ones that are sold, with no PageRank since all the incoming links are spam.

<comment> trimble-alum Any decent marketplace for one-app or brand companies needs to prominently display _intedependently-verifiable, evidence-based_ due-diligence metrics than can be dug into by your legal and forensic/tax accountant folks _before_ a transaction. Saves lots of time. BTW: on apps, it is usually more profitable to _license_ source code to games and similarly common apps (say for gyms, restaurants, etc.). If it's a FNAC app that you're bored of _try to sell it, first_ , don't just throw out your work (or at least salvage the best parts business of assets/staff/knowlege)! Reduce, reuse, recycle.

(Some, but not all, due-diligence is worry alleviation through hazing ritual business theatre.).

<comment><USER16> Google search did't help, so I have to ask: What is a "FNAC app"? Thank you.

<comment><USER17> Fart Noise Amplification Chamber: [http://www.urbandictionary.com/define.php?term=FNAC](http://www.urbandictionary.com/define.php?term=FNAC)

<comment><USER18> I did not expect that!

</comment></comment></comment></comment></comment><comment><USER19> [http://sideprojectsforsale.com](http://sideprojectsforsale.com) \- I had the same thought last year and made this working prototype for these types of businesses. It's pretty straightforward and mostly for the purpose of putting people in touch.

<comment><USER20> It's a two-sided market, and seeing only 1 side project listed there (from August 2014) makes me think the marketplace is dead.

Two thoughts:

1\. If there are prior successful sales, show those!

2\. If possible, try to show more (even if this means linking out to projects for sale on different sites until you get some traction).

</comment></comment><comment><USER21> I just want to say this thread is awesome. I have a side project that makes real, substantial revenue that I've been wanting to offload for a while. I don't think it's quite in condition to be listed with a broker yet, but it's great to hear about these resources and read about other hacker-entrepreneurs experiences offloading their own side projects.

</comment><comment><USER22> Why are the answers here so coy?

"Send me an email, we'll talk"

Is it a secret to be shopping your website/product to a new management? Why?

<comment><USER23> Advertising your business is for sale may bring unwanted attention too.

<comment><USER24> Could you give an example of such unwanted attention?

<comment><USER25> Customers/users abandoning a product when they learn it is for sale.

<comment><USER23> Bargain hunters, brokers of ill repute, press and so on, it may also put a serious dent in your ability to do business development until the situation around the (potential) sale has stabilized which in turn will hamper your ability to negotiate.

</comment></comment></comment></comment></comment><comment><USER26> I own Peaceofcode.com a PAAS with a focus on remote software development. Think Freelancer/Elance but with project manager/project owner/developer roles and business process flow to reduce risk (scrum/git/unit testing). In the past we focused on creating features that greatly reduce the risk of loss for the customer and development people. This last year we moved toward scrum and extreme programming features throughout the platform. We want to create a API and integrate 50+ 3rd party tools such as (codio.com Online IDE). A big feature-set we want to complete is based around opening the platform so the members can actively steer the features we release. Another endeavor we want to move forward is a "non-profit foundation" that focuses on Online Remote Software Development and identifying a "standard".

We want to give away up to 50% of the company in exchange for working capital and business expertise.

We do not want to sell the company but we dont mind giving up majority ownership so long as we can stay on as key executives. I currently own the company 50/50 with another American.

Any ideas how we might find such partners?

Sorry if I am way off topic.....

</comment><comment><USER27> I think this is going to be important now and in the future. Systems are getting so complex nobody can build something complete from scratch. I see people making high quality components and then merging or being acquired to create a whole end user product. Prior to that point, you'd have something that's not very profitable unless lots of companies license your component and do integration themselves.

<comment><USER28> So, an interesting thing I observed while building a SaaS company was that you _can_ actually get off the ground with a very simple solution, you'll just end up serving smaller customers with relatively simple needs (say $50-100/mo.) These initial folks will pepper you with feature requests while still paying you money for what you've got, which _can_ give you feedback about which complexities you're missing that you really need to implement. If you choose which things to implement carefully, you end up making your product more useful to larger customers and you'll start closing some larger deals. (E.g. $500/mo.) Rinse and repeat and before too long you've got a product with all the bells and whistles and you're closing enterprise deals. (E.g. $2,500+/mo.) The numbers here are all relative, but the point is that the smaller customers end up subsidizing the development of what becomes an enterprise product.

(I think the advantage this approach has over the one you've suggested is that the product is always capable of making money even from the very beginning, just on a smaller scale at first. I think this is a critical feedback mechanism so that folks know whether what they're developing is actually useful to folks.)

<comment><USER29> Great comment. In a way, it's like what Geoffrey Moore talks about in his book "Crossing the Chasm", about the difference between early adopters and mainstream users.

</comment></comment></comment><comment><USER30> I (had) a good ecommerce inventory management company going - if you want to buy it, drop me a note. I'm on to bigger / better things.

<comment><USER31> you don't have any contact info on your profile

<comment><USER30> fixed ;)

</comment></comment></comment><comment><USER32> A $500k business would mean you'll end paying on average between $3-5 million for it. May I ask your rationale behind chasing these deals?

Why not split the $3-5 million into risk-based chunks and invest in startups instead? You only need 1 of them to hit 50x.

<comment><AUTHOR> I don't think that multiple is right - for a $500k rev software company, I wouldn't pay any more than 3x.

<comment><USER33> This 3x yearly earnings is mentioned quite often. But I can't believe anybody is selling for this. Maybe for 5x if you are in need of money. And in times of zero interest rates this 3x thing sounds even more unbelievable.

<comment><USER34> 3x revenue, not 3x earnings. Revenue and earnings are two different beasts.

<comment><USER35> In a one man software company, there's often not a great of outgoings.

</comment></comment></comment></comment></comment><comment><USER36> I run www.hearthstoneplayers.com

It's a profitable site (making enough profit the equivalent of a 2nd job), minimal upkeep - just managing/scheduling content/writers. If anyone is interested in taking it and scaling it or even automating it (it's about 2 years in and I don't mind letting it go and moving on to bigger stuff), I'm open to contact!

</comment><comment><USER37> I'm selling Zilyo [https://zilyo.com/](https://zilyo.com/) for around 200k USD, which is a meta search for vacation rentals, big competiton in this space and it's currently the inudustry leader in terms of product quality and # of features and data. Many of its competition has raised millions and today it's running on it's own with a monthly burn rate of 30$. It does around 12,000$ a year. You can reach me at firstname.lastname@example.com

It also hosts one of the most active and fastest growing APIs in mashape, to leverage vacation rental data for developers and other businesses. Currently it hosts around 250 API consumers (most of them are businsess leeching it for free, so great oppurtunity in the B2B side of things) [https://www.mashape.com/zilyo/zilyo/](https://www.mashape.com/zilyo/zilyo/)

</comment><comment><USER38> ExitRound ([http://exitround.com/](http://exitround.com/))

</comment><comment><USER39> Love this thread. I've been looking to find answer to this question. I used to get more quality results from Flippa when I wanted to buy sites, back when they were Sitepoint. Now it's more or less for newbies to drop their money.

For sales, Flippa offers a brokerage service as well. They don't charge, unless the site is sold. I've got an extension for a CMS that stably makes 6-figures profit for past 3 years. Last year I wanted to experience the process and test the market, but didn't find the right buyer. This year might try again. If interested, reach me on Twitter: @ugurkaner

<comment><USER40> I'd be super interested to hear the story behind said extension. Sounds really impressive.

<comment><USER39> Hah, never considered it would be considered as "impressive" :)

</comment></comment></comment><comment><USER24> Why buy another company (as opposing to focusing on your existing business)?

<comment><USER41> It depends on what skills you bring to the table. (Personally) I know I can execute and grow. But I can't for the life of me find an idea to get started with.

Also, if you already have an existing business (such as the OP), then you may be able to bring some cost savings (therefore more profit) than someone coming in cold.

Or if you already have an existing client base, adding another business to the mix means you may be able to sell to them

<comment><USER24> Buying your own customers is a very expensive way to increase sales...

</comment></comment></comment><comment><USER42> Find apps you like then do some research and see if you can get a general idea of the revenue they are making. If it looks like you could afford to acquire them then email them and see what happens.

</comment><comment><USER43> I'm planning to refocus my mobile app business, and while I had planned on just continuing on cashing the checks from my other apps, lately I've considered the idea of selling them and really concentrating 100% on the main one.

A few questions: 1\. What kind of cost do the popular escrow services charge? I assume it's percentage based, only on successful sale?

2\. Do places like FEI sell apps, or just websites?

3\. If not, any recommendations on places to sell an app or bundle of apps?

<comment><USER44> Here's a company that focuses on buying/selling apps specifically: [http://www.appbusinessbrokers.com/](http://www.appbusinessbrokers.com/)

<comment><USER43> hadn't seen them before, looks pretty good. thanks a lot.

</comment></comment></comment><comment><USER45> We've got a profitable Bitcoin casino for sale... [https://bitcoinvideocasino.com](https://bitcoinvideocasino.com)

</comment><comment> trimble-alum Again, if a side hobby/business is getting too time-sink, boring or unsure how to scale it, selling off the value, happiness of customers, employees, vendors, etc. created, is a rational act. Shutting down is only advisable if the business model cannot ever have hope of being monetized AND folks running it lack ideas (and asked around to advisors and such) how to adjust the consumer/producer relationship.

</comment><comment><USER46> On this thread, services like the reinteractive Operations as a Service ([https://reinteractive.net/service/sentinel](https://reinteractive.net/service/sentinel)) can help with a SaaS sale. Getting operations and deployment outsourced means one less thing for the buyer to worry about and one big less thing for the seller to handle.

Disclaimer: I work for reinteractive

</comment><comment><USER47> Have you considered hiring a software developer? Some one extremely technical most likely can deliver on any business model you conceive of.

<comment><AUTHOR> It's the opposite situation here - I have the technical and business skills but am looking to buy the idea.

</comment></comment><comment><USER48> To be honest, you'd be better off starting from scratch. Buying something already existing will take a while to make back the revenue.

</comment><comment><USER49> I have no interest in selling in the near future, but I'm curious whether anyone in this thread has a sense of what kind of multiple an ad- and affiliate-supported site like www.autotempest.com would bring. It's not recurring revenue in terms of recurring billing like a SaaS, but revenue and user base are very highly correlated.

</comment><comment><USER50> There are many startups with 1 or 2-person teams who fail to raise funding since investors are looking for companies that can become worth $20M+. They might be interested in a cheap sale to someone who would be happy with a solid long-term revenue stream.

</comment><comment><USER51> If you are (or any other investor/buyer) interested in WordPress/Advertising and looking either to buy or invest, email me and maybe we can have a short- talk to exchange information, knowledge and who-knows.

</comment><comment><USER52> We're selling one called Flutter - [http://flutter-app.com](http://flutter- app.com)

We're about to close it down, its got customers and MRR

<comment><USER53> Also FYI to anyone trying this out -- this app gives you no warning or prompt before following hundreds of accounts on your behalf. I went through the FTUE and the first thing I saw was "You followed <rapidly increasing number> of Tweeter's [sic] today".

<comment><USER52> Wrong - every action has to be initiated by the user. Nothing is automatic.

</comment></comment></comment><comment><USER54> Would you like to purchase yipgo.com? Feel free to email me.

<comment><USER55> needs more demo... the bubble screen shots should be clickable to see the whole thing.

<comment><USER56> Agreed... let someone try it out by themselves. A screencast of someone using it would also be useful (think laracasts style screencast or similar). Being a user of this product really appeals to me (aligns with some stuff I already do), but the marketing is a bit light to convert me.

</comment></comment></comment><comment><USER57> I've thought about selling my side business, but I want to sell it to the right person.

I'm in Austin. Lemme know if you want to meet. My email is HN username + gmail.

<comment><USER58> What is your side business?

<comment><USER57> Send me an email.

<comment><USER58> What is your email address? (I don't see it in your profile)

<comment><USER59> Read his first comment :)

</comment></comment></comment></comment></comment><comment><USER60> Drop me a note (email is in my profile) if you'd like to look at a SaaS business at the higher end of your revenue target.

<comment><USER61> Note: While HN's profile indeed shows an email field, that's not made public to people looking at your profile. You will need to put it (obfuscated) in your "About" section if you want other users to be able to see it.

</comment></comment><comment><USER62> We've just decided to sell our company. Squire.io give us a shout if it's something you're interested in.

<comment><USER63> no email address in your profile :(

</comment></comment><comment><USER64> Take a look at [http://exitround.com](http://exitround.com)

</comment><comment><USER65> I am selling my fashion e-commerce website and app. Check my app at leposha.com

</comment><comment><USER66> Need to sell my chrome extension, 130k users.

<comment><USER67> where are the 130k from? which countries?

</comment></comment><comment><USER68> send me an email (address is in my profile). we have something that might fit what you're looking for...

</comment><comment><USER69> www.greenfossil.com <= crazy about engineering good software

</comment><comment><USER70> Can you send me a note - firstname.lastname@example.com. I'd like to run something by you.

</comment><comment><USER71> Ask Patrick McKenzie!

<comment><USER72> You do see he already responded, right? (patio11, first comment above) :)

</comment></comment><comment><USER73> This strikes me as one of those 'if you have to ask, you shouldn't do it' situations.

<comment><USER74> Care to explain? The OP's question was not whether it was a good idea, but the specifics of how, where, and why a particular website marketplace.

<comment> trimble-alum I was confused as well. A market place is basically lead-gen into the funnel of deciding whom is worth further diligence (interviews, tours, IP review, finances, customer surveys, etc.)</comment></comment></comment>


Show HN: Visualizing US Covid Trends by State/County - <AUTHOR> https://nbviewer.jupyter.org/github/amurthy1/coviz/blob/master/main.ipynb <comment><AUTHOR> Author here: I couldn't find any sources that show the number of cases over time broken down by US state / county, so I decided to build one myself.

Github source: [https://github.com/amurthy1/coviz](https://github.com/amurthy1/coviz)

Let me know down below if you have any questions/comments.</comment>


Mike Pompeo Said the US Is Considering Banning TikTok - <AUTHOR> https://www.buzzfeednews.com/article/pranavdixit/us-considering-banning-tiktok-according-to-mike-pompeo <comment><USER2> [https://news.ycombinator.com/item?id=23755863](https://news.ycombinator.com/item?id=23755863)

</comment><comment><USER3> If you thought Russian influence and fake news were worth getting upset over then it seems that TikTok and CCP disinformation are of equal importance.

<comment><USER4> I don't use TikTok so please excuse my ignorance. Is the platform (allegedly) a national security threat because it's a major vector for foreign state disinformation (similar to Facebook, Twitter and Reddit) or because it's a vector of foreign state information gathering/spying?

<comment><USER5> A vector of foreign state information gathering/spying

</comment></comment></comment><comment><USER6> This probably has broad political support. Not only is their a strong anti- China sentiment but this can be justified by saying they are equaling the playing field because China doesn't let our apps compete. I also think big tech companies privately would like this especially Facebook and likely others. I personally wouldn't have a problem with it even in the face of this specific app but I'm against it because it is a very dangerous precedent.

<comment><USER7> I think the precedent this would set is the most concerning. Is it done via "trade" sanctions, there is no other way that I can think of...?

</comment></comment><comment><USER8> Can the executive branch just unilaterally ban tiktok or do they need congress? If they dont need congress that's a surprising amount of power in the hands of the executive.

What does banning even mean here? Forbidden to be distributed on the app store? Or is it more than that?

</comment><comment><USER9> What does it mean for the US to "ban" an app? Does that mean the app is pulled from app stores? What mechanism can the government use to make that demand?

Have other apps been banned?</comment>