Skip to content

Comment on Classes often aren't the simplest tool for the jobparent

Comments

Kay's ideas are about building complex systems from isolated components ("cells") which may evolve independently. The web is an example: there's a server and a page and a browser and the user's extensions, all changing without reference to each other. How can they all work together?

Answer: keep them isolated (no direct function calls), defer most choices to runtime, make it easy to interrogate each others' interfaces. I think that sums up OO. "Call this function if it exists at runtime" is trivial in JS, but a crisis in Haskell.

You may not need that stuff. If you're statically compiling your code and all dependencies, it seems pointless. But if you're building a system which talks to code not under your control, code you cannot just refactor at will, then I don't know of any better techniques than OO.

Really depends upon what you're talking about. Examplle you can have a `Maybe (IO ())` data which would indicate "call this for side effects if it is present, otherwise do not". You could also model this as e.g.

   foo :: [(Text, IO ())]
so thsi would be a list of capabilities, each with a name.

Ofc this is a bit tricky, you would have to do a lot of heavy lifting in C to pull this off; but it wouldn't be hard to do in e.g. JS at the FFI layer before Haskell.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.