[xkapastel]

First, I just want to say that I use Dart pretty regularly now and enjoy the language. I don't want to come across as overly negative; Dart is a solid language that's made web programming a lot more fun for me. So thank you, and everyone else on the Dart team for the hard work!

I just want to address these lines:

> Thousands of successful applications and a billions of lines of UI code have been written in object oriented languages.

> 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.

I agree that there's a huge amount of code out there using subclassing and not sum types. I'm not disputing the utility of subclassing; I just think the analogy to arithmetic is compelling, in that a closed sum type is a more primitive notion than open ended subclassing. It's easier to describe what a sum type is than what a subclass is; sum types have a smaller impact on a type system than subclassing. Pretty much any metric you can think of, sum types are just simpler, and more widely applicable. Any time you are describing a data structure, an ADT is immediately useful; subtyping may or may not be useful and is always more complicated. It's very difficult for me to understand how anyone could possibly say subtyping is on the same level as a basic operation like addition. Subclassing may or may not be nice but sum types are a primitive in a way that subclassing simply cannot be.

I don't know how to break it down more than this: we already have multiplication of types, and everyone accepts this as a primitive. Well, you can also do addition of types! Multiplication, addition, a neat little pair, just like algebra class[0]. Subclassing is way more complicated than this. That's it, that's a bullet proof argument as far as I'm concerned.

I suppose I do have an uncharitable opinion of mainstream programming languages, because I do think they've been getting this wrong for decades. It's nothing personal, it's just that industry has other concerns besides how clean their languages are. My browser being written in C++ is not an argument in favor of subclassing, though. You can build anything out of toothpicks if you're paid enough.

[0]: https://typedefs.com/introduction/

[munificent]

> I just think the analogy to arithmetic is compelling, in that a closed sum type is a more primitive notion than open ending subclassing.

I agree, sum types have a real beautiful elegance. But I often wonder if that's some sort of "appeal to mathematical aesthetics" fallacy. When I see, for example, painters deciding what brushes to use, I don't see them choosing brushes whose diameter follows the Fibonacci sequence or something.

Simplicity is a virtue because it lowers the cognitive load of a language. I don't know if mapping something to arithmetic tells us something actually profound about the productivity of a language feature, even if it gives me a little shiver of delight when I think about it.

> Any time you are describing a data structure, an ADT is immediately useful

For what it's worth, I often run into problems where I think I can map something to a nice set of ADTs but then it ends up still having ugly corners. As elegant as the language feels, when I use them in practice my code is still awkward sometimes.

> It's very difficult for me to understand how anyone could possibly say subtyping is on the same level as basic operation like addition, one of them is clearly a more basic idea.

Subtyping is set theory, and sets are obviously more fundamental than arithmetic! :D

> we already have multiplication of types, and everyone accepts this as a primitive.

Well, actually, lots of languages don't have tuples and records/structs aren't simple product types.

> I suppose I do have an uncharitable opinion of mainstream programming languages

I wasn't talking about languages I was talking about people. There are languages out there with all of the features you describe. Yet millions of people are choosing other languages. You must have an uncharitable view of those people if you presume that all of them are making a choice that goes against their own self-interest to be happy productive programmers.

[xkapastel]

> Subtyping is set theory, and sets are obviously more fundamental than arithmetic! :D

In case this wasn't clear, the "arithmetic" in question is being performed on sets (or types). For example, for sum types, the number of inhabitants of the type is the sum of the inhabitants of the components. All three of addition, multiplication and subtyping are operations on sets (types). So this was a strange thing to say.

> Simplicity is a virtue because it lowers the cognitive load of a language. I don't know if mapping something to arithmetic tells us something actually profound about the productivity of a language feature, even if it gives me a little shiver of delight when I think about it.

My real point is this: if you are deciding to build a language, as far as I'm concerned, it is very strange to add multiplication (why don't structs count as multiplication? I would say they do), then not add addition and instead add something much more complicated than addition. It just doesn't make any sense. It's not about the "productivity" (how do we measure this?) of the feature, it's about it not making any sense to do this! You add multiplication, you add addition, that's really all there is to it. I don't know, I guess I'm just repeating myself now and you won't find it convincing, but to me it's like trying to defend Roman numerals after being shown the Arabic system.

> You must have an uncharitable view of those people if you presume that all of them are making a choice that goes against their own self-interest to be happy productive programmers.

I don't think so at all. It's not really a fair choice; people choose languages in order to build things, and it's easier to build things in languages that other people are using. The full range of options is not obvious to every programmer (does the average webdev even know about ML?), and most of the time there are more important concerns than whether your language has a nice theory behind it.