Hacker News Reader

Comment by zkmon | Hacker News Reader

> CSCI 2100: Unlearning Object-Oriented Programming??

People in tech industry, seem to have no idea how the systems in the wild work. Enterprise Java runs the backbone of operations for all of large business organisations such as banks. It is just as grounded as MS Office is. It is object-oriented software that is running the bulk of production environments of the world. Who is going to maintain these systems for the next few decades?

And in reality, there is nothing wrong with Java or object orientation. It has the best battle-tested and rich ecosystem to build enterprise systems. It mirrors the business entities and a natural hierarchy and evolution of things. It has vast pool of skilled resources and easy to maintain. Python is still a baby when it comes operational readiness and integrations. You might get excited about Jupyter cells and REPL, but that is all a dev-play, not production.

View on HN

Unlearning OOP does not necessarily involve forgetting abstraction and the concept of an object. "Unlearning OOP" involves freeing yourself from the notion that all programming should be designed as an object hierarchy. There is/was a tendency in object-oriented programming to consider that it is the only way Real Software™ is made. You tend to focus more on the architecture of your system than its actual features.

Notice the prerequisite to unlearning something is learning it first. I don't think anyone proposes that the concept of an object is useless.

I don’t necessarily agree with a somewhat childish “unlearn OOP” idea, but… a lot of that enterprise software is of bad quality. Whether it’s OOP or something else’s fault, simply stating that a lot of backbone is written in Java does not prove Java is a good choice, nor does it prove that there is nothing wrong with Java.

If you think programmers should defer to bank managers on what the best way to design software is, do you also think that bank managers should defer to plumbers on what the best way to manage liquidity is?

Its not bank managers but IT managers choosing somewhat the tech stack, rest is inertia and things working. Bank managers dont give a fuck in same way they couldnt care less what plumbing material is used in their buildings. They care about long term stability, as they should. Same is true for almost any business outside SV.

Parent is correct, been doing this my entire (profitable to the absolute limit) career and will most probably retire doing same. You clearly seem to lack any expertise in field discussed.

Maybe it should be "really learn about object-oriented programming (at a low level)".

Methods are functions, with an implicit argument usually called "self". Unless they are static, in which case, they are just regular functions. Classes are data structures, abstract methods are function pointers, inheritance adding data at the end of an existing data structure. In fact, inheritance is like a special case of composition.

Those who oppose object-oriented programming the most are typically the functional programming guys. But what is a function variable if not an object with a single abstract method, add attributes and you have a closure.

It will all end up as machine code in the end, and understanding how all these fancy features end up on the bare metal help understanding how seemingly different concepts relate.

From https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/... (the koan below is a bit worn out but the email thread is also enlightening)

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

People get passionate about how to move around a bunch of 1s and 0s.

Sometimes lives depend on it. Usually they don't.

Thanks for the reminder of this thread!

For those who don't know, Guy L. Steele (Anton's interlocutor here) is the original designer of the Scheme programming language, the author of the "Lambda: The Ultimate Zozo" series of papers, and the second biggest contributor to the design of Java.

> It mirrors the business entities and a natural hierarchy and evolution of things

I've seen the entities you're describing from the inside and they resemble nothing natural besides perhaps a tumor. Hopefully we can just dispense with them rather than shackle the next generation with the burden of maintaining them.

It will vary by domains. I work in games, so unlearning OOP and understanding data oriented paradigms helped immensely understanding how to optimize.

But I'm not a data oriented evangelist. Part of that paradigm is understanding the size and predictability of data, and not everything in games meets this. Input is the most obvious example. But knowing when and where to use such techniques is arguably what separates an engineer from a programmer. But schools can go a tad overboard focusing on one technique.

Unlearning can also help you appreciate OOP more as well. I wouldn't have dug too much onto c++ vtables without a goal to understand why Polymorphism can be so slow. But I can also appreciate how clever the implementation is to get that far to begin with.

"CSCI 2100: Unlearning Object-Oriented Programming" immediately caused me to disagree this one.

When I code in C, in the end, I usually miss the syntax for defining "objects/classes" (structs with functions and access controls), the syntax/notation that encapsulates/binds/groups the related state and its functions/API to define some specific concept/model == custom data type.

Of course OOP can be taken to extreme complexity and then lose its usefulness.

> Of course OOP can be taken to extreme complexity and then lose its usefulness.

The type bike shedding that seems to inevitably occur in typescript discussions has completely turned me off of it.

Now that I'm self-employed, I just use JSDoc comments and an IDE that warns me when I break the definitions.

Much faster iteration, much easier to debug, and no wasted meetings moralizing over the use of `any`.

That happened not by choice, but by chance and due to "OOP consultants" running rampant in the 2000s. Source: i have to maintain Java slop in a bank, and used to maintain Java slop in manufacturing.

> Enterprise Java runs the backbone of operations for all of large business organisations such as banks.

This is rather anti-recommendation. At this point I'm expecting from a bank only to reliably login, preview balance and transaction history, receive and send bank transfers... and they oftentimes fail at this basic feature set. I don't even need credit or interest rates from them.

Banks as an example of "getting things done" is laughable. Real industry gets things done: manufacturing, construction, healthcare etc. We could do without the massive leech that is the finance sector.

I still get my monthly salary via wire transfers, no issues… banks do get things done.

A lot of wire transfer code and other foundational banking code is written in COBOL.

Not thanks to Java or OOP, but despite it. You can thank my colleagues fighting Java in the bank each day.

With so many issues and costs that people buy stablecoins to exchange money with smart-contracts that have no substantial guarantee other than the issuer's right to block funds...

And that needs skyscrapers and entire financial districts to achieve? This is a tiny fraction of the "work" done by the financial sector. Most of what they do is pointless trading between themselves and sapping the output of the real economy.

The banks' real "product" is trust. You will work an entire month for a "bank transfer" (something you can't even hold, let alone eat or burn) because you believe your landlord will similarly accept a "bank transfer" in exchange for you rent (or, if you have a mortgage, you work an entire month because you believe this means you will be able to continue living in your house unchallenged). This has absolutely nothing to do with what programming languages or paradigms they have in place.

"Real industry" also has quite a hard time getting things done these days. If you look around at the software landscape, you'll notice that "getting things done" is much easier for companies whose software interfaces less with the real world. Banking, government, defense, healthcare etc. are all places where real-life regulation has a trickle-down effect on the actual speed of producing software. The rise of big tech companies as the dominant economic powerhouses of our time is only further evidence that it's easier to just do a lot of things over the internet and even preferred, because the market rewards it. We would do well to figure out how to get stuff done in the real world again.

Now do UML.

Reply on news.ycombinator.com