4 ms·

How to write good OO code: write it like it's supposed to be Haskell. Avoid state, favor composiblity, prefer static functions, treat classes like types, throw

by c3534l 7y ago

How to write good OO code: write it like it's supposed to be Haskell. Avoid state, favor composiblity, prefer static functions, treat classes like types, throw errors to enforce type safety. All the fancy OOP design patterns and SOLID stuff just enforce or implement the principles which are provided by the semantics of strongly typed functional code. It's easier to be a bad programmer in Python or Java than Haskell, but being a good Haskell or Rust programmer is no more easy or difficult than being an equally good Python or Java coder, IMHO.

derefr 7y ago
I've always been a fan of thinking of systems as strictly-delineated combinations of two components: • protocol glue (which is OOP/actor modelled) • business logic (which is best served by being strongly-typed and statically verified.) I'm a big fan of writing most of your code as libraries and "engines" in a language like Haskell or an ML (or Rust, if your algorithms are best specified on a pointer or RAM-word machine); and then taking those components and hooking them up to the outside world using an actor language like Erlang. IMHO, this uses each language for its strengths. You've given the argument for why business logic is suited to languages like Haskell, so I'll give the other half: Languages like Erlang, or Smalltalk, or other "true" OOP languages (i.e. languages where actors control not just their own state, but their own executing code) are good at reacting to arbitrary untyped messages, doing clever things after only partially parsing them, without needing a complete understanding of what they mean. This allows for components like proxies or brokers to react to metadata on RPC requests without needing to constantly be told about the typings of new messages. This also allows rolling upgrades of distributed systems that don't require a preliminary "teach the system that the new message-type exists and it should ignore it" upgrade.
- OJFord 7y ago
  This sounds really interesting - can you point to any articles/talks/projects for more info or examples? (If not... Hint, hint, nerd-snipe, nerd-snipe?)
  - derefr 7y ago
    Oh, don’t worry, I’ve been beyond nerd-sniped on this; I’m working on a little language-design just to better elucidate the concept. :) (The goal won’t be to get anyone to use this language; just to get the concept understood in a way where other language maintainers might then choose to bring in a spin on it in their own designs.)
    - OJFord 7y ago
      (Well, you know Linux is also just that toy OS that won't be big like GNU or anything... ;))

by c3534l 7y ago

derefr 7y ago

I've always been a fan of thinking of systems as strictly-delineated combinations of two components: • protocol glue (which is OOP/actor modelled) • business logic (which is best served by being strongly-typed and statically verified.) I'm a big fan of writing most of your code as libraries and "engines" in a language like Haskell or an ML (or Rust, if your algorithms are best specified on a pointer or RAM-word machine); and then taking those components and hooking them up to the outside world using an actor language like Erlang. IMHO, this uses each language for its strengths. You've given the argument for why business logic is suited to languages like Haskell, so I'll give the other half: Languages like Erlang, or Smalltalk, or other "true" OOP languages (i.e. languages where actors control not just their own state, but their own executing code) are good at reacting to arbitrary untyped messages, doing clever things after only partially parsing them, without needing a complete understanding of what they mean. This allows for components like proxies or brokers to react to metadata on RPC requests without needing to constantly be told about the typings of new messages. This also allows rolling upgrades of distributed systems that don't require a preliminary "teach the system that the new message-type exists and it should ignore it" upgrade.

OJFord 7y ago
This sounds really interesting - can you point to any articles/talks/projects for more info or examples? (If not... Hint, hint, nerd-snipe, nerd-snipe?)
- derefr 7y ago
  Oh, don’t worry, I’ve been beyond nerd-sniped on this; I’m working on a little language-design just to better elucidate the concept. :) (The goal won’t be to get anyone to use this language; just to get the concept understood in a way where other language maintainers might then choose to bring in a spin on it in their own designs.)
  - OJFord 7y ago
    (Well, you know Linux is also just that toy OS that won't be big like GNU or anything... ;))