Hacker News new | ask | show | jobs
by tskj 32 days ago
You might like Casey Muratori's "The Big OOPs" talk about this, if you haven't seen it yet: https://www.youtube.com/watch?v=wo84LFzx5nI

It's my favorite deep dive into the subject, it's super thoughtful and well structured.

1 comments

This comment was dead for some reason; I vouched for it. Casey Muratori is a well-known developer with a GUI/game engine background, which gives him a valuable perspective on OOP. In both domains, OOP is both popular and problematic, and his experience suggests that he might know what he's talking about. I didn't watch the whole video, but from the description and intro, it seems to fit the discussion we're having here.
Too late to edit, I watched the talk. Really well-researched and entertainingly told story.

I'd say games are a bit special, though. Smalltalk works pretty well in interactive applications - while it's true that encapsulation is an important part of the language, it also provides all the tools to pry objects open when needed. Out of the box, it's much better at that than C++. The problem is that video games demand very high performance, and Smalltalk is even slower than normal when you use reflection. If not for that, it's perfectly doable (if not very convenient) to treat a Smalltalk image as a soup of data with behavior attached. Casey also mentioned the focus on education in Alan Kay's projects: it's probably one of the reasons Smalltalk is largely devoid of modules, namespaces, packages, and even files with source code - things that are very useful when collaborating in teams, consuming external dependencies, etc. There are Smalltalk implementations that provide those, but they're either very niche or very niche and extremely expensive... And still slow.

Still, interactive software that doesn't have the performance requirements of games is definitely more convenient to write in Smalltalk than in C++! I have high hopes for GToolkit, I just need to port a few ideas from VisualWorks and figure out how to actually set up a project structure friendly to external agents (the GT agent harness is very nice, but it forces you to use an API, which is way too expensive for the results you get...)