4 ms·
I've been exploring CLOS for the past couple of weeks. From what I can tell, it seems especially nice for a system that needs extreme flexibility. I like to p
by bcrosby95 4y ago
I've been exploring CLOS for the past couple of weeks.
From what I can tell, it seems especially nice for a system that needs extreme flexibility. I like to program MUDs and rougelikes as side projects, and after initial exploration, CLOS seems perfect for that - it can enable certain interactions that I would otherwise have to spend a lot of work and design achieving in other languages. It turns what feels like a chore in other languages into something fun.
I would imagine that how much this is a pro or con depends upon the work you do. Some might see such potential flexibility as error prone and overly complex because the domains they work in don't require such complexity. But others might see it as the building blocks for a domain with complex interactions that they have to build regardless of the language they use.
- infinite8s 4y agoI once made a rules engine for Magic the Gathering in python. As a design problem it is quite interesting since the key thing about MtG is that the pieces of the game can override the game rules. After reading about CLOS a few years later it seems I reinvented some of the main ideas (like cleanly re-entrant method combinators, cleanly overriding functionality of other objects in a way that can be reverted) using python's dynamiticity (especially descriptors which let you override what obj.[accesor] means).
- kaveh808 4y agoCLOS extends the Common Lisp philosophy of emphasizing developer flexibility, possibly at the expense of execution efficiency (not trying to open a can of worms here). For any application of substantial size, I can't imagine not using CLOS classes and generic dispatch. It may be overkill for small projects, but as the code complexity grows the abstractions of CLOS make their worth known. That's been my experience most recently with my 3D graphics system.