Hacker News Reader

Comment by tempodox | Hacker News Reader

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

View on HN

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

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

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

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

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

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

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

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

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

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

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

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

It's a potshot at everybody.

Years ago I thought "people are fundamentally good."

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

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

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

---

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

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

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

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

https://en.wikipedia.org/wiki/Embraer_R-99

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

Yes, HPC is certainly a separate domain as much as embedded is. You cannot transfer (what I would call) conventional wisdom and expect a reasonable outcome or a working system at all.

Part of the communication problem is that “high”, “performance”, and “needs” are all relative, which makes the combined phrase super-ambiguous. If you reach for a thing that’s advertised as “2x faster” because it means you’ll get your answer in one month instead of two, I think reasonable people would agree that’s a reasonable optimization in that specific case. If you reach for it simply because it’s advertised (perhaps not reliably) as “2x faster”, that’s more of a premature optimization if you don’t know along what axes, or under what conditions, that speedup obtains.

Having said that, “2x improvement” can also be read as “an order of magnitude improvement (base 2)”, which does become more meaningful in general as x gets large.

Clojure isn't supposed to be everything for everyone. Did Hickey really dismiss the value that 2x faster had for the professor, or was he just not interested in that particular use case for himself?

If that's his attitude then Hickey is right not to bother. Suppose Hickey puts in months of efforts and gets it so that you can apply the same technique with only a 1.2x performance cost. The professor is still going to dismiss it for the same reason.

What’s hadoops equivalent now then?

Calling mutability an OOP issue doesn't make sense to me. You could certainly have immutable objects. You can event have immutable object inheritance. Maybe you just want a language where fields are immutable by default.

If you're just passing around raw structs or arrays, it's way harder to manage blocks of data.

> Calling mutability an OOP issue doesn't make sense to me. You could certainly have immutable objects. You can event have immutable object inheritance.

When they're immutable they're not objects, they're just data. There's no need for encapsulation because if you can't mutate something then you can't break its invariants. There's no need for identity or references, there's no message-passing...

Obviously mutability is not an issue in OOP alone. Note, however, how I said, “how normal is it that our methods mutate instance variables?”. A well-skilled programmer can always choose to not use the footgun a language hands them. But those are not the only people to consider.

As for structs, you could qualify the pointee of a pointer argument as `const` but this is as rare in C as the equivalent is in OOP languages.

> If you're just passing around raw structs or arrays, it's way harder to manage blocks of data.

This isn't an OOP issue either.

This might be because almost all languages that support OOP are mutable, which goes all the way back to Smalltalk and CLOS, and becomes popularized with C++ and Java and then the dynamic languages like JS, Ruby and Python.

The software I write is provably correct because it never changes the state of anything.

Reply on news.ycombinator.com