Hacker News Reader

Comment by thesz | Hacker News Reader

Please, define "reasonably".

Because these people who created hilariously Finnish ThingDoerFactoryFacadeFactoryInstaniatorService also thought they do a reasonably reasonable job.

Per your comment on "use classes for data modeling" I would like to provide you with two historical facts: it took more than 25 years to get Simula (and OO) types right [1] and it took not more than 8 years for Per Martin-Loef to have intuitionistic type theory right [2].

[1] http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%...

[2] https://en.wikipedia.org/wiki/Intuitionistic_type_theory

Classes are much harder to reason about than other type systems.

View on HN

Definition of a reasonable paradigm: millions of developers can successfully use it to build software systems used by billions.

Windows, iOS, Android, Photoshop, Excel, Chrome - these are complex products that use object-oriented programming. They exist and work well. They have shipped many new features over the years.

Those products don't need to be complex, at their heart they are actually rather simple. They are just written in such a way that they become unnecessarily complex, because they are poorly understood.

I would argue that the examples you give don't work well (Windows, Android, Chrome, later versions of iOS). They get worse and worse over time. Even if they start out with a good design, it turns to crap eventually.

Just because a piece of software is used by billions doesn't mean that it is well written.

If by successful you mean slow to develop, slow to run, bug ridden software we have to deal with today, you have built a great definition.

This kind of thinking got us Teams and Slack.

Millions of developers also use functional programming, for decades now. Even bigger order of magnitude of developers use relational languages to build systems of various scale. Indirectly, even more millions of developers use constraint programming of various sorts (compilers, databases and user interfaces).

Given that, the definition of yours does not provide much to discern between paradigms.

But we can compare complexity of logic of different systems and I provided two examples of that. We can even discuss some ordering between different systems.

For example, contemporary type system that is powerful enough (not even dependently typed) can model class hierarchy, it is a no big deal [1] from, at least, 2005. So classes are, in some sense, less general than System F that is used above. They also more specific, whether it is good or not.

[1] https://www.cs.tufts.edu/comp/150FP/archive/oleg-kiselyov/ov...

But in System F in [1] you can have several parallel class hierarchies, without requiring anything else from the system.

The same goes to other things like "escape hatches".

System with dynamic types cannot prevent (runtime) errors that can be prevented by a system with static types. It is just not possible to have reasonable description of a system without certain kinds of (runtime) errors without reimplementing many things from system with static type checking. On the other side, in system with static types it is quite possible to have over-encompassing type that represents all dynamic values one needs.

So, systems with static type checking are, in some sense, more general than systems with dynamic type systems. And, of course, systems with dynamic types are more specific, whether it is good or not.

> Given that, the definition of yours does not provide much to discern between paradigms.

That's the whole point. "Reasonable" is not synonymous with "optimal", so we ought to expect that there would be multiple reasonable paradigms to choose between. Which programming paradigm you choose is very rarely the largest factor in the success or failure of your product.

Exactly.

You can solve any problem by throwing more money (millions of developers). The money is the largest factor in the success or failure of the product of... yours?

When something is constantly true for all objects in the scope of the domain, it is considered tautology and should be dropped from the discussion as it adds nothing.

If reasonableness is equally meaaningless, we can drop it.

Instead, we can look at other properties of programming paradigms.

Reasonable in this context I'd understand as:

1. ThingDoerFactoryFacadeFactoryInstaniatorService trying to represent the reality of an abstraction meant to represent a reality (an indirection that isolates the domain in that level of abstraction of an abstraction).

2. ThingCreator. An abstraction named in a way that is closer to direct reality (and that can perfectly hide its own inner complexities using composition and they could be as many or more than the ridiculous example in 1).

Note that people that, conscious or unconsciously, exclude the inverted pyramid principle fall into creating 1 and people that, conscious or unconsciously, embrace it, tend to create 2 in "a reasonable" way.

“Because these people who created hilariously Finnish ThingDoerFactoryFacadeFactoryInstaniatorService also thought they do a reasonably reasonable job.”

The people who did this will mess up FP or any other paradigm too. I think OOP was a huge step forward but like with everything in software design, you have to have good taste and recognize when something you do is going off the rails. There is no paradigm that will save you from clueless people or ideologues.

>The people who did this will mess up FP or any other paradigm too.

The people who did this will not mess up FP or any other paradigm.

I have an example of that somewhere in my career, with Haskell.

But it is "he said she said" here and it is not me who started that.

>you have to have good taste and recognize when something you do is going off the rails

The Liskov substitution principle is not precisely defined, see the "shapes" problem (class Rectangle : Square or vice versa?). Thus, you have to have "a good taste," or, to be more reality grounded, you have to weigh your design choices against current use cases and possible future changes.

When you deal with constraints on a type, you don't need hierarchy at all. If you add two values of some variable type in a function, assure function's type to have Num constraints for the type of these two values. Then pass there anything that has Num implemented and be fine.

The inheritance in typical OOP program fixes solutions of historical use cases in place and prevents finding more general solutions when new use cases arise. The solutions for new uses cases most often get bolted on instead of being organically implanted.

Basically, it is OOP that provokes such concatenative names. When you step outside, you find yourself in no need of these.

Who said that you have to use inheritance for shapes? I do know that it is an often used example, but similarly to Animal/Bird it has no real world relevance.

I would even argue that inheritance is not the most important feature of OOP, but objects are. Inheritance is useful, for example GUI Nodes are famously good fit for it, but object encapsulation is the essential feature, missing that would pretty much disallow large swathes of programs from existing.

"Classes are much harder to reason about than other type systems."

Strange, I find classes intuitive. Objects lend themselves to physical system analogues; making objects easier to reason about in complex systems. The paradigm specifically helps me build light mental models which in turn helps me retain the associated codebase.

Anyone else have a similar experience?

I find classes extremely intuitive.

I find classes extremely unintuitive.

I find type classes and (generalized) algebraic data types to be extremely intuitive.

I have met a few people like you, and I wish you all well in your programming careers.

I find both intuitive and one is better for these kinds of jobs, the other for other kinds.

There are countless articles showing how OOP fails to model the physical world.

Straw man.

The point of contention regards ease of reasoning not completeness or ability to model the physical world.

Define "ease of reasoning," then you can accuse others of "straw man" attack.

OOP does not even consider effects in it's reasoning. You can do anything with the state of an object and whatever that object can reach through references. The changes are not atomic, they are allowed to be (temporarily) inconsistent.

In my book, this is opposite of ease of reasoning.

You can change something that will shoot the user of your program much down the line and do that without any hiccup.

"Define "ease of reasoning," then you can accuse others of "straw man" attack."

Capable of being retained both as individual components and aggregate system.

My reply which the other user is replying to specifically quotes ease of reasoning from the parent comment. You're also conflating implementation with conceptualization.

I was only noting that OOP is easy for me. It fits my system and worldview. I did not generalize that experience to a larger population.

"Capable of being retained both..." is not a definition, it is a property, at best.

wtf?

> Anyone else have a similar experience?

Exactly contrary. I find modelling in objects classes counter-intuitive and thus not good to reason about.

When I paint a wall I apply a function (paint) to the object (wall), not the object is painting itself. I can apply the same function to a different type (aka class) of object e.g. I can paint my chair. Stays the same function.

So in my cognitive model of the world the objects are objects manipulated by me, not subjects executing "methods", but OOP is treating them as subjects.

You can do the same thing with objects though.

I have "utilities" which can be used with objects. Per your example, if object(wall) and object(chair) both share the attribute(color) then they both can utilize function(paint). The only prerequisite would that they are paintable.

What you describe there is use of interfaces and properties.

These things are much easier to reason about and to compose than classes with inheritance.

For example, it is easy to solve Expression Problem [1] with interfaces and properties and it is hard to solve it with only classes and inheritance.

[1] https://en.wikipedia.org/wiki/Expression_problem

"These things are much easier to reason about and to compose than classes with inheritance."

Fair. Personally, that looks like an argument for objects rather than against.

Do these concepts oppose or complement OOP? Is inheritance somehow a hidden requirement?

I did not say that it is not possible to do it. I said it is counterintuitive for me to express or model it in that way.

And as you can see in the discussion arising, even this simple example is becoming a complex modelling problem in OOP.

Ok, let’s represent a double-ended stack then, as a circular buffer. It will be in the end a fixed sized array with a start and end variables pointing to one-one element of it.

Doesn’t it inherently makes sense that I want to have a public API on top of it denoting how can it be used from the outside, while a private one, that encapsulates the implementation details, and makes them only callable by other methods of this object? This is the major point of OOP, in my opinion.

To get an API I just define a type for double-ended-stacks functions manipulating it. Or if you prefer to define it with immutable variables the functions accept an double-ended-stack and return a new copied and modified stack as result.

The set of functions will be a moduls resembling what you call an API.

I am not argue this can not be done on OOP, but I find it counter-intuitive and overly complex to do so.

Reply on news.ycombinator.com