3 ms·

> It makes some kinds of code nicer, but doesn't significantly affect the expressiveness or capability of the language. Sum types and exhaustive pattern matchi

> It makes some kinds of code nicer, but doesn't significantly affect the expressiveness or capability of the language. Sum types and exhaustive pattern matching aren't about expressiveness, they're tools for aiding code comprehension by increasing the locality of code that has no business being distributed into completely different classes, and decreasing the cost of making changes by heavily reducing the amount of test code that needs to be written to make sure a closed set of options is handled appropiately; in OOP languages you can get this by using interfaces but to make use of it you'd have to use huge classes with methods pertaining to every usage of this closed set. I would never willingly pick up another language that doesn't provide me with them after experiencing the productivity gains. I really like the direction Dart is moving towards and the steps taken demonstrate there's a team behind it that cares about correctness and productivity over being just a familiar Java-like, but this is the one hard blocker for me.

munificent 8y ago
> they're tools for aiding code comprehension by increasing the locality of code that has no business being distributed into completely different classes That's true for some kinds of code but not others. This is the classic Expression Problem [0]. For some things, it makes sense to keep all of the code for a single operation together. For others, it makes more sense to keep all of the code for a single datatype together. ML-style languages optimize for the former, and object-oriented languages optimize for the latter. In practice, for the kinds of code Dart is designed for, the latter is a better fit most of the time. There's a reason OO and UI have been married together for decades. Ideally, a language provides both styles so you can choose the one that fits your problem best. You see that now with languages like Scala. I hope we get there with Dart too. I don't think it's fair to say that subclassing and method dispatch is objectively wrong just because it's a bad fit for some kinds of code. (Though, naturally, if it's a bad fit for the kind of code you need to write, then an OO language might be an objectively bad choice for you.) Class-based method dispatch is annoying for some things (God knows I've written enough Visitor pattern implementations over object-oriented AST class hierarchies), but it's really beautiful for others. Being able to define a new widget class that bundles its rendering and interaction behavior together and can seamlessly extend a UI framework is something so natural that we take it for granted, but is very difficult to express in a language like SML. In fact, in order to do it, you'll probably end up doing a "design pattern" that reimplements something like v-tables at the application level. [0]: http://journal.stuffwithstuff.com/2010/10/01/solving-the-expression-problem/ http://journal.stuffwithstuff.com/2010/10/01/solving-the-exp...
- mixedCase 8y ago
  Not sure if I gave off the wrong impression, but I am not a proponent of having only sum types and discarding hierarchies; as you well mentioned each is well-suited to specific usecases. I do however disagree on subclassing being the best fit for UI code. "The Elm architecture" as well as the model presented by React functional components with hooks offer sets of tradeoffs that I at least have found are better for most of the development I find myself doing when writing (and particularly when maintaining) regular business frontends.
- xkapastel 8y ago
  > There's a reason OO and UI have been married together for decades. People repeat this a lot, that OO goes with UI, but I don't think it's actually true, and I think e.g. React Hooks and immediate mode GUI in general demonstrate that it's not true. OO has been coupled with UI out of inertia, not because OO has unique strengths when applied to UI. Sum types are a primitive language feature, akin to product types, which absolutely no one rejects the value of. The sum/product analogy to arithmetic is compelling to me: they are the building blocks of complex types and deserve recognition. I think that "zen koan" you mentioned earlier is being very generous to subclassing. You want ADTs most of the time!
  - munificent 8y ago
    > People repeat this a lot, that OO goes with UI, but I don't think it's actually true It is evidentially true. Thousands of successful applications and a billions of lines of UI code have been written in object oriented languages. It does work and it can't be that bad if that's continuing to happen even after the emergence of other alternatives. Whether there are better ways is a good question, but I think it's pretty clear that you can ship good apps using OOP for your UI. > React Hooks and immediate mode GUI in general demonstrate that it's not true. I'm far enough into my career now — I've been doing UI programming of one form or another since the 90s — to have seen that pendulum swing several times. If there is a silver bullet, we haven't found it. It's probably not immediate mode GUIs because if it was, I wouldn't have seen game teams tear them out to replace them with something more retained several times in the 2000s. What I think actually happens is that we forget the problems lurking in the solution we are not currently using. The grass over there gets greener and greener until we hop the fence and the cycle starts over. Incremental progress does happen. (I am not keen to revisit MFC any time soon.) But if a given concept (1) has been around a long time (2) has not already supplanted the alternatives, it's pretty unlikely that it is now an amazing solution today. The only time when that isn't true is when the surrounding technology context has changed since then. For example, neural nets weren't a good solution for AI problems in the 80s because compute was too expensive and we didn't have a lot of data. Now that CPUs are cheap and everyone puts their entire life on the Internet, machine learning is here. I haven't seen anything around UIs that to me looks like a significantly changed context, so I think we're still orbiting around retained-mode and immediate-mode as both having their own trade-offs and neither being a slam dunk. > I think that "zen koan" you mentioned earlier is being very generous to subclassing. You want ADTs most of the time! I really don't think that's true. Just look out there in the world. More code is written in languages doing subclassing every day than in languages with sum types. Despite the fact that sum types have been around since the 70s. You have to have a very uncharitable opinion of all of your fellow programmers to believe they've all been getting this wrong for decades. Heck, the software you are using right now to read this comment is sitting on a stack of several layers of subclass-based architectures! You've got JS running on top of the DOM inside a browser written in C++. Sum types are really nice. But open-ended subclassing is too.

munificent 8y ago

> they're tools for aiding code comprehension by increasing the locality of code that has no business being distributed into completely different classes That's true for some kinds of code but not others. This is the classic Expression Problem [0]. For some things, it makes sense to keep all of the code for a single operation together. For others, it makes more sense to keep all of the code for a single datatype together. ML-style languages optimize for the former, and object-oriented languages optimize for the latter. In practice, for the kinds of code Dart is designed for, the latter is a better fit most of the time. There's a reason OO and UI have been married together for decades. Ideally, a language provides both styles so you can choose the one that fits your problem best. You see that now with languages like Scala. I hope we get there with Dart too. I don't think it's fair to say that subclassing and method dispatch is objectively wrong just because it's a bad fit for some kinds of code. (Though, naturally, if it's a bad fit for the kind of code you need to write, then an OO language might be an objectively bad choice for you.) Class-based method dispatch is annoying for some things (God knows I've written enough Visitor pattern implementations over object-oriented AST class hierarchies), but it's really beautiful for others. Being able to define a new widget class that bundles its rendering and interaction behavior together and can seamlessly extend a UI framework is something so natural that we take it for granted, but is very difficult to express in a language like SML. In fact, in order to do it, you'll probably end up doing a "design pattern" that reimplements something like v-tables at the application level. [0]: http://journal.stuffwithstuff.com/2010/10/01/solving-the-expression-problem/ http://journal.stuffwithstuff.com/2010/10/01/solving-the-exp...

mixedCase 8y ago
Not sure if I gave off the wrong impression, but I am not a proponent of having only sum types and discarding hierarchies; as you well mentioned each is well-suited to specific usecases. I do however disagree on subclassing being the best fit for UI code. "The Elm architecture" as well as the model presented by React functional components with hooks offer sets of tradeoffs that I at least have found are better for most of the development I find myself doing when writing (and particularly when maintaining) regular business frontends.
xkapastel 8y ago
> There's a reason OO and UI have been married together for decades. People repeat this a lot, that OO goes with UI, but I don't think it's actually true, and I think e.g. React Hooks and immediate mode GUI in general demonstrate that it's not true. OO has been coupled with UI out of inertia, not because OO has unique strengths when applied to UI. Sum types are a primitive language feature, akin to product types, which absolutely no one rejects the value of. The sum/product analogy to arithmetic is compelling to me: they are the building blocks of complex types and deserve recognition. I think that "zen koan" you mentioned earlier is being very generous to subclassing. You want ADTs most of the time!
- munificent 8y ago
  > People repeat this a lot, that OO goes with UI, but I don't think it's actually true It is evidentially true. Thousands of successful applications and a billions of lines of UI code have been written in object oriented languages. It does work and it can't be that bad if that's continuing to happen even after the emergence of other alternatives. Whether there are better ways is a good question, but I think it's pretty clear that you can ship good apps using OOP for your UI. > React Hooks and immediate mode GUI in general demonstrate that it's not true. I'm far enough into my career now — I've been doing UI programming of one form or another since the 90s — to have seen that pendulum swing several times. If there is a silver bullet, we haven't found it. It's probably not immediate mode GUIs because if it was, I wouldn't have seen game teams tear them out to replace them with something more retained several times in the 2000s. What I think actually happens is that we forget the problems lurking in the solution we are not currently using. The grass over there gets greener and greener until we hop the fence and the cycle starts over. Incremental progress does happen. (I am not keen to revisit MFC any time soon.) But if a given concept (1) has been around a long time (2) has not already supplanted the alternatives, it's pretty unlikely that it is now an amazing solution today. The only time when that isn't true is when the surrounding technology context has changed since then. For example, neural nets weren't a good solution for AI problems in the 80s because compute was too expensive and we didn't have a lot of data. Now that CPUs are cheap and everyone puts their entire life on the Internet, machine learning is here. I haven't seen anything around UIs that to me looks like a significantly changed context, so I think we're still orbiting around retained-mode and immediate-mode as both having their own trade-offs and neither being a slam dunk. > I think that "zen koan" you mentioned earlier is being very generous to subclassing. You want ADTs most of the time! I really don't think that's true. Just look out there in the world. More code is written in languages doing subclassing every day than in languages with sum types. Despite the fact that sum types have been around since the 70s. You have to have a very uncharitable opinion of all of your fellow programmers to believe they've all been getting this wrong for decades. Heck, the software you are using right now to read this comment is sitting on a stack of several layers of subclass-based architectures! You've got JS running on top of the DOM inside a browser written in C++. Sum types are really nice. But open-ended subclassing is too.