3 ms·
“I know of no widely-used language that solves The Expression Problem while satisfying the constraints of independent compilation and static typing” - kind of i
by joppy 6y ago
“I know of no widely-used language that solves The Expression Problem
while satisfying the constraints of independent compilation and static
typing” - kind of implies that the problem is different from whether or not the language is statically typed, doesn’t it?
I don’t think you should be writing off Clojure’s multimethods too quickly - they are quite nice, and I haven’t seen anything like them in other dynamic languages like Python.
- mumblemumble 6y agoYou've cherry-picked that sentence, though. Given the entire context of the article, I would argue that one should interpret that as a case of unclear writing, and not something that is intended to directly contradict the definition given in the second sentence: "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)." (emphasis mine)
- seepel 6y agoI’m not much of a clojure fan myself, but I think the observation is that by relaxing that last constraint of static typing (and given the other appropriate tools), that while you can’t solve The Expression Problem itself, it’s a bit easier to solve the real world problem that happened to manifest itself as the expression problem in your code. By the way, I was also enticed by multi-methods in this area, but I ultimately don’t think multiple dispatch is necessary.
- mumblemumble 6y agoYes, absolutely, but doing so would be moving the goalpost right out of the stadium. The expression problem isn't supposed to describe a challenge for people implementing line-of-business applications. It's a problem for programming language researchers.