The Black Liszt

Object-Oriented Software Languages: The Experts Speak

On the subject of Object-Oriented Programming (OOP), there are capital-E Experts, most of academia and the mainstream institutions, and there are small-e experts, which include people with amazing credentials and accomplishments. They give remarkably contrasting views on the subject of OOP. Follow the links for an overview, analysis and humor on the subject.

The Exalted Experts on OOP

Here is the start of the description of Brown's intro course to Computer Science, making it clear that "object-oriented design and programming" is the foundational programming method, and Java the best representation language:

Here's their description of OOP, making it clear that there are other ways to program, specifically the nearly-useless functional style, never used in serious production systems.

See below to see what Dr. Alan Kay has to say about Java.

Here is what the major recruiting agency Robert Half has to say on the subject:

Object-oriented programming is such a fundamental part of software development that it’s hard to remember a time when people used any other approach. However, when objected-oriented programming, or OOP, first appeared in the 1980s, it was a radical leap forward from the traditional top-down method.

These days, most major software development is performed using OOP. Thanks to the widespread use of languages like Java and C++, you can’t develop software for mobile unless you understand the object-oriented approach. The same goes for web development, given the popularity of OOP languages like Python, PHP and Ruby.

It's clear: OOP IS modern programming. Except maybe some people who like functional languages.

The mere experts on OOP

We get some wonderful little-e expert witness from here.

“Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse.” – John Ousterhout Scripting, IEEE Computer, March 1998

“Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function.” – John Carmack

OO is the “structured programming” snake oil of the 90' Useful at times, but hardly the “end all” programing paradigm some like to make out of it.

And, at least in it’s most popular forms, it’s can be extremely harmful and dramatically increase complexity.

Inheritance is more trouble than it’s worth. Under the doubtful disguise of the holy “code reuse” an insane amount of gratuitous complexity is added to our environment, which makes necessary industrial quantities of syntactical sugar to make the ensuing mess minimally manageable.

More little-e expert commentary from here.

Alan Kay (1997)
The Computer Revolution hasn’t happened yet
“I invented the term object-oriented, and I can tell you I did not have C++ in mind.” and “Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to happen to computing since MS-DOS.” (proof)

Paul Graham (2003)
The Hundred-Year Language
“Object-oriented programming offers a sustainable way to write spaghetti code.”

Richard Mansfield (2005)
Has OOP Failed?
“With OOP-inflected programming languages, computer software becomes more verbose, less readable, less descriptive, and harder to modify and maintain.”

Eric Raymond (2005)
The Art of UNIX Programming
“The OO design concept initially proved valuable in the design of graphics systems, graphical user interfaces, and certain kinds of simulation. To the surprise and gradual disillusionment of many, it has proven difficult to demonstrate significant benefits of OO outside those areas.”

Jeff Atwood (2007)
Your Code: OOP or POO?
“OO seems to bring at least as many problems to the table as it solves.”

Linus Torvalds (2007)
this email
“C++ is a horrible language. … C++ leads to really, really bad design choices. … In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don’t screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don’t screw things up with any idiotic “object model” crap.”

Oscar Nierstrasz (2010)
Ten Things I Hate About Object-Oriented Programming
“OOP is about taming complexity through modeling, but we have not mastered this yet, possibly because we have difficulty distinguishing real and accidental complexity.”

Rich Hickey (2010)
SE Radio, Episode 158
“I think that large objected-oriented programs struggle with increasing complexity as you build this large object graph of mutable objects. You know, trying to understand and keep in your mind what will happen when you call a method and what will the side effects be.”

Eric Allman (2011)
Programming Isn’t Fun Any More
“I used to be enamored of object-oriented programming. I’m now finding myself leaning toward believing that it is a plot designed to destroy joy. The methodology looks clean and elegant at first, but when you actually get into real programs they rapidly turn into horrid messes.”

Joe Armstrong (2011)
Why OO Sucks
“Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds.”

Rob Pike (2012)
here
“Object-oriented programming, whose essence is nothing more than programming using data with associated behaviors, is a powerful idea. It truly is. But it’s not always the best idea. … Sometimes data is just data and functions are just functions.”

John Barker (2013)
All evidence points to OOP being bullshit
“What OOP introduces are abstractions that attempt to improve code sharing and security. In many ways, it is still essentially procedural code.”

Lawrence Krubner (2014)
Object Oriented Programming is an expensive disaster which must end
“We now know that OOP is an experiment that failed. It is time to move on. It is time that we, as a community, admit that this idea has failed us, and we must give up on it.”

Asaf Shelly (2015)
Flaws of Object Oriented Modeling
“Reading an object oriented code you can’t see the big picture and it is often impossible to review all the small functions that call the one function that you modified.”

Here is Wiki's take on issues with OOP. It goes into detail.

Here is Linus Torvald's take on object-oriented C++. Linus is merely the creator and leader of the open-source software that fuels the vast majority of the web.

More details:

Essay by Joe Armstrong. "After its introduction OOP became very popular (I will explain why later) and criticising OOP was rather like “swearing in church”. OOness became something that every respectable language just had to have."

A talk given at an OOP conference by an OOP supporter who lists 10 things he hates.

A Stanford guy telling his evolution to OOP and then out of it. Lots of detail.

A professional who gradually realized there were issues with objects.

I have therefore been moving away from the object-oriented development principles that have made up the bulk of my 17 year career to date. More and more I am beginning to feel that objects have been a diversion away from building concise, well structured and reusable software.

As I pondered on this topic, I realised that this isn’t a sudden switch in my thinking. The benefits of objects have been gradually declining over a long period of time.

A detailed explanation of how the noun-centricity of OO languages perverts everything. Here is an extended quote from the start of this brilliant essay:

All Java people love "use cases", so let's begin with a use case: namely, taking out the garbage. As in, "Johnny, take out that garbage! It's overflowing!"

If you're a normal, everyday, garden-variety, English-speaking person, and you're asked to describe the act of taking out the garbage, you probably think about it roughly along these lines:

  get the garbage bag from under the sink
  carry it out to the garage
  dump it in the garbage can
  walk back inside
  wash your hands
  plop back down on the couch
  resume playing your video game (or whatever you were doing) 

Even if you don't think in English, you still probably still thought of a similar set of actions, except in your favorite language. Regardless of the language you chose, or the exact steps you took, taking out the garbage is a series of actions that terminates in the garbage being outside, and you being back inside, because of the actions you took.

Our thoughts are filled with brave, fierce, passionate actions: we live, we breathe, we walk, we talk, we laugh, we cry, we hope, we fear, we eat, we drink, we stop, we go, we take out the garbage. Above all else, we are free to do and to act. If we were all just rocks sitting in the sun, life might still be OK, but we wouldn't be free. Our freedom comes precisely from our ability to do things.

Of course our thoughts are also filled with nouns. We eat nouns, and buy nouns from the store, and we sit on nouns, and sleep on them. Nouns can fall on your head, creating a big noun on your noun. Nouns are things, and where would we be without things? But they're just things, that's all: the means to an end, or the ends themselves, or precious possessions, or names for the objects we observe around around us. There's a building. Here's a rock. Any child can point out the nouns. It's the changes happening to those nouns that make them interesting.

Change requires action. Action is what gives life its spice. Action even gives spices their spice! After all, they're not spicy until you eat them. Nouns may be everywhere, but life's constant change, and constant interest, is all in the verbs.

And of course in addition to verbs and nouns, we also have our adjectives, our prepositions, our pronouns, our articles, the inevitable conjunctions, the yummy expletives, and all the other lovely parts of speech that let us think and say interesting things. I think we can all agree that the parts of speech each play a role, and all of them are important. It would be a shame to lose any of them.

Wouldn't it be strange if we suddenly decided that we could no longer use verbs?

Let me tell you a story about a place that did exactly that...

The Kingdom of Nouns

In the Kingdom of Javaland, where King Java rules with a silicon fist, people aren't allowed to think the way you and I do. In Javaland, you see, nouns are very important, by order of the King himself. Nouns are the most important citizens in the Kingdom. They parade around looking distinguished in their showy finery, which is provided by the Adjectives, who are quite relieved at their lot in life. The Adjectives are nowhere near as high-class as the Nouns, but they consider themselves quite lucky that they weren't born Verbs.

Conclusion

No big surprise, the experts beat the Experts hands-down. But you'd never know if you go through typical Computer Science "education," absorb the way that object-orientation is the "dominant" paradigm of computing and read the job requirements that talk about how the hiring group is serious about their object-hood. Programmers who are serious about what they do and try to understand it soon see the lack of clothing on King Object and move on.

Data Humor Book by Rupa Mahanti

There's a new book out about Data Humor.

If you like data, you will be amused by this book. If you feel tortured by data, join the crowd -- and read this book, it will relieve some of the stress. If you were wondering what nerd humor was all about, read this book -- better to learn about nerd humor by getting the giggles.

The author searched far and wide for data humor. She stumbled upon a blog that had some bits she thought were funny -- this blog, yes, the one you're reading now!

She contacted me to ask permission to quote me. After thinking hard about whether I should grant permission -- for about a microsecond -- I gave it. She asked me to check out a draft of the book. I guess she liked what I said because my quote went on the back cover and was the first of the quotes on Amazon.

"This is a brilliant book. The title says it's humorous. It's hilarious! But even more valuable is the sad-but-true insights it conveys about humans, lost and wandering in uncharted forests of data, anxious to escape."—David B. Black, Technology Partner, Oak HC/FT Partners

It's quite amazing how widely she searched for quotes, from places I never would have thought to look:

... book containing a collection of more than 400 funny and quirky quotes, puns, and punchlines related to data, big data, statistics, and data science, from different sources and a wide array of cultural figures, thought leaders and key influencers across the world- William Edwards Deming, Charles Wheelan, Brené Brown, David B. Black, Tim O’Reilly, Jill Dyché, Evan Levy, Gwen Thomas, George Mount, David Shenk, James Gleick, Jim Barksdale, Vincent Granville, Cathy O’Neill, Dale Carnegie, Martyn Richard Jones, Timo Elliott, Mark Twain, Phil Simon, Lewis Carroll, Oscar Wilde, Thomas H. Davenport, DJ Patil, Damian Mingle, Thomas C. Redman, Cassie Korykorv, Brent Dykes, Guy Bradshaw, Scott Taylor, Susan Walsh, Winston Churchill, Ronald Reagan, Arthur Conan Doyle, and many more.

Here's just one:

Data isn't information, any more than fifty tons of cement is a skyscraper.
Clifford Stoll (Stoll 1996)

Don't you need some light in your life? I promise, it's lighter in every way than fifty tons of concrete...

Software NEVER needs to be “Maintained”

We maintain our cars, homes and devices. Heating and cooling systems need regular maintenance. So do our bodies! If we don’t care for our bodies properly, they break down! Software, by sharp contrast, never needs to be maintained. NEVER! Using the word “maintenance” to describe applying a “maintenance update” to software is beyond misleading. More accurate would be to say “a new version of the software that was crippled by a horrible design error that our perpetually broken quality processes failed to catch.” That’s not “maintenance.” It’s an urgent “factory recall” to fix a design error that infects every car (copy of the software) that was built using the flawed design.

Software is different than almost everything

Software is unlike nearly everything in our experience. It is literally invisible. Even “experts” have trouble understanding a given body of code, much less the vast continent of code it interacts with. Naturally, we apply real-world metaphors to give us a chance of understanding it. While sometimes helpful, the metaphors often prove to be seriously misleading, giving nearly everyone a deeply inaccurate view of the underlying invisible reality. The notion of “software maintenance” is a classic example. The flaw is similar to the words “software factory.”

Maintaining anything physical centers around either preventing or repairing things that break due to simple wear-and-tear or an adverse event. We change the oil in a car because it degrades with use. We change the filters in heating and cooling units because they get clogged up with the gunk from the air that passes through them. We sharpen knives that have dulled as a result of use. We maintain our homes and yards. It’s the physical world and things happen.

In the invisible, non-physical world of software, by contrast, a body of software is the same after years of use as it was the moment it was created. Nothing gets worn down. Nothing gets clogged. An inspection after years of heavy use would show that every single bit, every one and zero, was the same as it was when it was created. Of course there are memory crashes, hacker changes, etc. It’s not that software is impervious to being changed; it’s just that software is unchanged as a result of being used – unlike everything in the normal physical world, which one way or another, is changed by its environment – everything from clothes getting wrinkled or dirty from wear to seats being worn down by being sat upon.

The meaning of software maintenance

When a car is proven to have a design flaw, auto manufacturers are reluctant to ship everyone a new car in which the original design flaw has been corrected. Instead, they issue a recall notice to each affected owner, urging them to bring their car to the nearest dealership to have repair done to the car that corrects the design flaw. It’s inconvenient for the owner, but far less expensive for the manufacturer. With software, by contrast, all the software vendor has to do is make a corrected version of the software available for download and installation, the software equivalent of shipping everyone a new car! It’s no more expensive to “ship” hundreds of megabytes of “brand-new” code than it is a tiny bit. Such are the wonders of software.

Software factory recalls are part of everyday life. Software creators are maddeningly unable to create error-free software that is also cyber-secure. See this.

We’ve all become accustomed to the Three Stooges model of building software.

There are highly paid hordes of cossetted employees enjoying free lunches and lounging on bean bags on luxurious campuses, “hard at work” creating leading edge software whose only consistent feature is that it’s late, expensive and chock full of bugs and security flaws.

While the Three Stooges and their loyal armies of followers are busily at work creating standards, regulations and academic departments devoted to churning out well-indoctrinated new members of the Stooge brigades, rebels are quietly at work creating software that is needed to meet the needs of under-served customers, using tools and methods that … gasp! … actually work. What an idea!

The good news is that the rebels are often richly rewarded for their apostasy by customers who eagerly use the results of their work. It’s a good thing for the customers that the totalitarian masters of the Three Stooges software status quo are no better at enforcing their standards than they are at building software that, you know, works.

Cryptocurrency: Money, Trust and Regulation Book

A book has been published about cryptocurrency that stands out from the many books available on the market: it's written by a person with experience and true expertise in financial markets, institutions and regulation both in government and the private sector, Oonagh McDonald. Disclosure: I was her technical advisor for the book. We connected as a result of my article in Forbes on Central Bank Digital Currencies.

Dr. McDonald's prior books are impressive because of her amazing perspective and knowledge. Here's her background:

Dr. Oonagh McDonald CBE is an international expert in financial regulation, having advised regulatory authorities in a wide range of countries, including Indonesia, Sri Lanka and Ukraine. She was formerly a British Member of Parliament, then a board member of the Financial Services Authority, the Investors Compensation Scheme, the General Insurance Standards Council, the Board for Actuarial Standards and the Gibraltar Financial Services Commission. She was also a director of Scottish Provident and the international board of Skandia Insurance Company and the British Portfolio Trust. She is currently Senior Adviser to Crito Capital LLC. She was awarded a CBE in 1998 for services to financial regulation and business. Her books include Fannie Mae and Freddie Mac: Turning the American Dream into a Nightmare (2013), Lehman Brothers: A Crisis of Value (2015) and Holding Bankers to Account (2019). She now lives in Washington DC, having been granted permanent residence on the grounds of "exceptional ability".

Read the comments at the link about her books on Lehman Brothers, Fannie Mae, bankers and markets and others.

Here are examples of what others have said:

Oonagh McDonald has done it again. In this ambitious book, she helps the rest of the world catch up with her on the opportunities and risks associated with stable coins. Even if one may disagree with her about the future of stable coins (and I do a bit), this book is an invaluable resource, especially as a teaching tool, because of McDonald’s ability to synthesize and interpret a vast amount of information about complex and novel practices. -- Charles Calomiris, Henry Kaufman Professor of Financial Institutions, Columbia Business School

McDonald’s rigorously researched analysis of the development of cryptocurrencies is a must-read for anyone who has a stake in the future of money. It is an historical tour de force that painstakingly teases out of every corner of the cryptocurrency world the critical issues that governments, policy makers, and consumers must consider before abandoning government fiat money. -- Thomas P. Vartanian, executive director and professor of law, Program on Financial Regulation and Technology, George Mason University

Everyone fascinated by how the cryptocurrency phenomenon has created a whole sector of ventures to furnish ‘alternative currencies’, while the dollar price of a Bitcoin boomed from 8 cents to a high of more than $60,000, must wonder whether all this will really bring about a revolution in the nature of money. Will Bitcoin’s libertarian dream to displace central bank fiat currency be achieved? Or ironically, will central banks take over digital currencies and make themselves even more dominant monetary monopolies than before? Oonagh McDonald, always a voice of financial reason, provides a thorough consideration of these questions and of cryptocurrency ideas and reality in general, with the intertwined issues of technology, regulation, trust, and government monetary power. This is a very insightful and instructive guide for the intrigued. -- Alex J. Pollock, Distinguished Senior Fellow Emeritus, R Street Institute, and former Principal Deputy Director, Office of Financial Research, US Treasury

It's a different perspective from the many books on the subject of cryptocurrencies that have been published. Whether or not you agree with her conclusions, you will read facts and perspective here that are not available elsewhere.