3 ms·

It's surprising to me to see how few discussions of Functional and/or Object Oriented programming end up even mentioning the Expression Problem: http://wiki.c2.

It's surprising to me to see how few discussions of Functional and/or Object Oriented programming end up even mentioning the Expression Problem: http://wiki.c2.com/?ExpressionProblem http://wiki.c2.com/?ExpressionProblem 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). FP and OOP are two axes in a space of problems around building and extending programs. To be "purely functional" or "strictly OO" is basically painting yourself into a corner that you will eventually learn to regret. Eli Bendersky wrote an excellent piece on it: http://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions/ http://eli.thegreenplace.net/2016/the-expression-problem-and...

anaphor 9y ago
I was planning on mentioning it as soon as I saw this post as well. I think most people who try using a functional programming language that encourages you to use sum types (at least when you're beginning) run into this in some way, but most people probably aren't aware that it has an actual name. Here's a post on solving it using type classes in Haskell, if people are curious! http://koerbitz.me/posts/Solving-the-Expression-Problem-in-Haskell-and-Java.html http://koerbitz.me/posts/Solving-the-Expression-Problem-in-H...
- jfoutz 9y ago
  I was going to link the same article! I think the interesting part is the similarity between haskell and clojure. Essetially programming to very small classes/protocols. The linked article is cool, because i think the java approach would generalize to the OP's C++ solution, and be able to eliminate that gross dynamic cast.
deleted 9y ago
[deleted]
BoiledCabbage 9y ago
Yes it's a sample problem but the natural conciseness of the Haskell compared to that C++ is almost comical. You can count non-whitespace lines or lexical constructs and get a 3x reduction. But conceptually, the ability to have that much code so concise is way more than a 3x productivity gain.
charlysl 9y ago
Yes, the Bendersky link explains it very well. The c2 wiki Shape example is in fact an instance of the Interpreter pattern (although it doesn't mention this I believe), which is the closest thing to pattern matching in Java (Visitor would be the other way of sort of doing pattern matching in Java, and closer to FP, with the same drawbacks and advantages). There is another good explanation in this PDF: https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec15.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu...

anaphor 9y ago

I was planning on mentioning it as soon as I saw this post as well. I think most people who try using a functional programming language that encourages you to use sum types (at least when you're beginning) run into this in some way, but most people probably aren't aware that it has an actual name. Here's a post on solving it using type classes in Haskell, if people are curious! http://koerbitz.me/posts/Solving-the-Expression-Problem-in-Haskell-and-Java.html http://koerbitz.me/posts/Solving-the-Expression-Problem-in-H...

jfoutz 9y ago
I was going to link the same article! I think the interesting part is the similarity between haskell and clojure. Essetially programming to very small classes/protocols. The linked article is cool, because i think the java approach would generalize to the OP's C++ solution, and be able to eliminate that gross dynamic cast.

deleted 9y ago

[deleted]

BoiledCabbage 9y ago

Yes it's a sample problem but the natural conciseness of the Haskell compared to that C++ is almost comical. You can count non-whitespace lines or lexical constructs and get a 3x reduction. But conceptually, the ability to have that much code so concise is way more than a 3x productivity gain.

charlysl 9y ago

Yes, the Bendersky link explains it very well. The c2 wiki Shape example is in fact an instance of the Interpreter pattern (although it doesn't mention this I believe), which is the closest thing to pattern matching in Java (Visitor would be the other way of sort of doing pattern matching in Java, and closer to FP, with the same drawbacks and advantages). There is another good explanation in this PDF: https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec15.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu...