2 ms·

MVC (and other OOP patterns) work around the fact that the language does not solve the Expression Problem. You could say, the key to getting MVC correct is und

MVC (and other OOP patterns) work around the fact that the language does not solve the Expression Problem. You could say, the key to getting MVC correct is understanding the Expression Problem, and designing its solution into your programming language in the first place, so you don't need MVC, but if you want to do it, it becomes actually neat and clean and modular.

MalinGamer123 1y ago
Understanding the Expression Problem in MVC and OOP
tonyedgecombe 1y ago
In case anybody else wondered: https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem
brazukadev 1y ago
This makes no sense. MVC was created to use with SmallTalk and based on Alan Kay's OOP, of which late binding is one of 3 requirements, not static types.
- adityaathalye 1y ago
  Well, I tried to walk back from MVC, to the smallest possible generally composable abstraction for web app architecture, and I kept coming back to X/Y shaped tables. They're everywhere at all levels of composition; dependency injection, routing tables, joining any two modules arbitrarily, laying out source code on disk etc. etc. etc. So I built my own web app system (not a monolithic framework) to test out the opinion. And, I'd say it's working quite well---for me, at any rate. Have a gander: https://github.com/adityaathalye/clojure-multiproject-example https://github.com/adityaathalye/clojure-multiproject-exampl... See also, Polylith application architecture; a far more sophisticated and generalised form of what I'm doing in my system. https://polylith.gitbook.io/polylith/ https://polylith.gitbook.io/polylith/ --- The term "Expression Problem" was coined in context of statically typed languages, but the formulation has nothing to do with static typing per se. Its general form is polymorphic multiple dispatch (not Objects versus Functions, but Objects and Functions). See: Philip Wadler's explanation (where he coins the term): https://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt https://homepages.inf.ed.ac.uk/wadler/papers/expression/expr... > The Expression Problem is a new name for an old problem. The goal is > to define a datatype by cases, where one can add new cases to the > datatype and new functions over the datatype, without recompiling > existing code, and while retaining static type safety (e.g., no casts). i.e. He was trying to bring the solution from the dynamic / interpreted language space, to the difficult case of statically typed languages. --- Anyway, I picture it as an "X/Y" problem. Something like this: https://www.evalapply.org/posts/clojure-web-app-from-scratch/deck.html#slide-org9e24aa7 https://www.evalapply.org/posts/clojure-web-app-from-scratch... 7.2. Solve The Expression Problem Playtime: - What if we frame everything in terms of the Expression Problem? - Add a new Y, extend all Xs to it? Without cooperation of existing Xs? - Add new X, extend all Ys to it? Without cooperation of existing Ys? | X * Y | y1 | y2 | y3 | ... | |-------+----+----+----+-----| | x1 | | | | | | x2 | | | | | | x3 | | | | | | ... | | | | | (edit: formatting)

MalinGamer123 1y ago

Understanding the Expression Problem in MVC and OOP

tonyedgecombe 1y ago

In case anybody else wondered: https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem

brazukadev 1y ago

This makes no sense. MVC was created to use with SmallTalk and based on Alan Kay's OOP, of which late binding is one of 3 requirements, not static types.

adityaathalye 1y ago
Well, I tried to walk back from MVC, to the smallest possible generally composable abstraction for web app architecture, and I kept coming back to X/Y shaped tables. They're everywhere at all levels of composition; dependency injection, routing tables, joining any two modules arbitrarily, laying out source code on disk etc. etc. etc. So I built my own web app system (not a monolithic framework) to test out the opinion. And, I'd say it's working quite well---for me, at any rate. Have a gander: https://github.com/adityaathalye/clojure-multiproject-example https://github.com/adityaathalye/clojure-multiproject-exampl... See also, Polylith application architecture; a far more sophisticated and generalised form of what I'm doing in my system. https://polylith.gitbook.io/polylith/ https://polylith.gitbook.io/polylith/ --- The term "Expression Problem" was coined in context of statically typed languages, but the formulation has nothing to do with static typing per se. Its general form is polymorphic multiple dispatch (not Objects versus Functions, but Objects and Functions). See: Philip Wadler's explanation (where he coins the term): https://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt https://homepages.inf.ed.ac.uk/wadler/papers/expression/expr... > The Expression Problem is a new name for an old problem. The goal is > to define a datatype by cases, where one can add new cases to the > datatype and new functions over the datatype, without recompiling > existing code, and while retaining static type safety (e.g., no casts). i.e. He was trying to bring the solution from the dynamic / interpreted language space, to the difficult case of statically typed languages. --- Anyway, I picture it as an "X/Y" problem. Something like this: https://www.evalapply.org/posts/clojure-web-app-from-scratch/deck.html#slide-org9e24aa7 https://www.evalapply.org/posts/clojure-web-app-from-scratch... 7.2. Solve The Expression Problem Playtime: - What if we frame everything in terms of the Expression Problem? - Add a new Y, extend all Xs to it? Without cooperation of existing Xs? - Add new X, extend all Ys to it? Without cooperation of existing Ys? | X * Y | y1 | y2 | y3 | ... | |-------+----+----+----+-----| | x1 | | | | | | x2 | | | | | | x3 | | | | | | ... | | | | | (edit: formatting)