I've been surprised at how many people think concepts are objects (in the object-oriented sense). And I suspect that I'm largely to blame, for giving names to concepts that sound like objects—Post rather than Posting for example—and for not being forceful enough in explaining what's wrong with objects.

When I wrote my book, I underestimated how much object orientation has shaped how people think about software. I mistakenly thought I could mostly ignore objects and that it was better just to make the case for a new idea. And I didn't want to pick fights. So I relegated my explanations of why concepts aren't objects to two page-long end notes and left it at that. Perhaps I should have guessed that almost nobody would read the end notes, even though many of the key ideas of the book are there (including my favorite pasta recipe!).

As I've seen people use concept design over the last few years, in industry and in my classes at MIT, I've come to see how object orientation leads them astray. I came to realize it was time to be more blunt about why concept design isn't object oriented, to explain how concepts address some of the flaws of objects, and to show what goes wrong if you don't understand these things.

That’s what my latest post is about. It’s longer than I’d planned, but I decided to try and disentangle the many different things people mean by ‘object oriented.’ It’s really only one of these that causes problems.

Lots of exciting things are going on in concept land, especially related to AI and how LLMs can enhance concept design and make code generation from concepts a breeze. More about that soon.

But in the meantime, I'd love to hear your thoughts. What are you doing with concept design? What are your biggest challenges? How can I help? Let me know what you're up to, by email or by posting a message on the forum.

Happy new year to all,

Daniel