> If you defer to the type system then you're moving some, but not all, of the documentation into the type system, fragmenting the information. Is that fair to other developers? In reality, you're going to want to write the tests anyway for the sake of consistency and completeness. A programmer needs to deliver something that works, of course, but also something that does a good job of communicating to other developers what is going on. Programming is decidedly not a solo activity.
As for this, as I said I really like having the type system as my documentation, and I don't know what exactly you are saying with "is that fair to other developers", this is not only fair but very useful, in fact this is WHY people really like good typed libraries in TypeScript world, they make using the thing MUCH easier and more guided, to the point that you don't even need to read the real documentation written in text that much as just exploring in the code editor. As a very good example, I literally make for my teammates many useful libraries and they love using them, the convenience they provide, and I find joy when they find "oh, that's amazing, your library can do this exact thing I was needing to do because you thought about it before", this makes their life easier, this makes my life easier, and even when they use the library a bit wrong it will still work because I made everything flow well and have easier paths for gradual usage when you need. It is not only fair, it is good if you know how to do it well, and I rarely need to write tests for my own code more than I need to write for my libraries (if they are right, generally speaking the code that uses it has way less easy to make flaws, and thus I reduce the number of tests needed in the end of the day). As if programming is or not a "solo activity", this depends on many things, I certainly have hundreds of solo projects of mine and I love working on them, and I also have my projects that are developed along with other people, and I love them as well. Programming for me is at the same time a form of expression, and art and a job at the same time.
> Sure, in an ideal world you could document the entire program in the type system, but the languages people normally use simply don't have what it takes to enable that. They lean on testing instead. Worse is better, I suppose.
As I said before, Rust does have that, and many modern languages have more and more on that. I understand that the world mostly uses less powerful languages, but this is not their fault, most languages have dozens of legacy projects behind them and it is really hard to let go (I mean, there are important programs written in COBOL nowadays, and I assume the language is even worse than your "worse is better", but people still need to use it). I'm not advocating for abandomning those projects, nor that languages with worse type systems are terrible, but that you should simply not say "it is better" just because people need to use it because of reasons, nor glorify their mediocrity. Mediocrity should be enhanced (and that's why even Go, a "simple language" is still gaining features from time to time, even it is not a crystalized stone of specific directives that will never change, and some day it will have more and more features as time moves on; all languages are slowly evolving, even COBOL itself, so if being "worse" is a goal, I think most of them are not following that goal).
> We should probably talk about my fee structure first. I don't want you coming back crying that it was too much when I send you the bill for the work performed.
> That said, under my professional duty to act your interest, I expect you would far better served thinking about how you might go about avoiding testing the shape given a random useful test. You don't really need my services here.
Oh, sorry, I thought this was a discussion where people was really trying to reach the truth, not some sort of "pay me if you want to see my point" kind of thing. I'm more of a "talk is cheap, show me the code guy", and I will certainly not pay someone to justify their own onus probandi. If this is how things will be, I think a discussion with you furthermore would be pointless.
> It doesn't even have proper support for something basic like value constraints, let alone more advanced concepts. It has more features than Go, but I fail to see how that offers transcendence beyond half-assery. I'll grant you that it is less half-assed, just as I did earlier.
And this is obviously an extreme form of exaggeration. I literally coded a basic working numeric system in rust type system with mathematical operations just for fun (and there are crates that does that), if this don't imply the language has a very powerful one I don't think anything would.
Obviously, I'm not saying that Rust has THE MOST powerful type system, I never once implied that, but it is not "half-assery" in any way, it is also many times above what Go is able to do. It's not only "more features", it is fundamentally more open to changes and advancements than it is.
> I really like having the type system as my documentation, and I don't know what exactly you are saying with "is that fair to other developers"
Because you didn't bother to read what I wrote, again, that's why. I suggested it is not fair to fragment the information. If you want to duplicate the information, go nuts. But that rounds us back to the very beginning where we opened with the topic of growing tired of repeating yourself...
> I thought this was a discussion where people was really trying to reach the truth, not some sort of "pay me if you want to see my point" kind of thing.
Yes, it is a discussion, not a make work project. If you want to deliver a point in that discussion, just do it. No need for stupid games.
> I generally don't care that much about them, because I don't find the need for them most of the time
Exactly. Same reason why nobody uses them. [I know, I know, you think this needs to be proven. But it really doesn't. That is silly.]
However, this means that you also recognize that there is a line where more typing is not worth it. So, where, exactly is that line? You say "here", but then I'll say "but no, you also need this". You'll say "that is really not that important", but I'll say "no, it is!" We could go on like that forever.
Eventually a sane person will arrive and simply say: "It depends." And maybe someday you too will understand that statement.
> And this is obviously an extreme form of exaggeration.
It is not. I will grant you that it is the lowest hanging fruit for testing, so in practice it is probably not worth the effort, but it is a great indicator of how the type system is half-assed. If it truly believed in not half-assing it, it would be there, and is in languages with robust type systems.
> For starters, things like "is the shape of this data correct"
When would a test like that ever be necessary? If the shape of your data is wrong somehow, the "documentation" tests won't be able to succeed either, so you implicitly find out that the shape is wrong anyway. There is no need to repeat yourself here. Not only is there no need for repetition, worse, tests like that usually end up making the test suite brittle and hard to manage.
> First, I don't think this is true [at all].
I gathered. This seems to be the source of contention around the testing topic when we cannot even agree what testing is. From your vantage point I can understand how you are unable to recognize the overlap. But it remains that if you write useful tests, you implicitly also end up testing what the type system covers.
The type system is still incredibly beneficial for other reasons, of course. To a point. But, again, the returns are diminishing.
As for this, as I said I really like having the type system as my documentation, and I don't know what exactly you are saying with "is that fair to other developers", this is not only fair but very useful, in fact this is WHY people really like good typed libraries in TypeScript world, they make using the thing MUCH easier and more guided, to the point that you don't even need to read the real documentation written in text that much as just exploring in the code editor. As a very good example, I literally make for my teammates many useful libraries and they love using them, the convenience they provide, and I find joy when they find "oh, that's amazing, your library can do this exact thing I was needing to do because you thought about it before", this makes their life easier, this makes my life easier, and even when they use the library a bit wrong it will still work because I made everything flow well and have easier paths for gradual usage when you need. It is not only fair, it is good if you know how to do it well, and I rarely need to write tests for my own code more than I need to write for my libraries (if they are right, generally speaking the code that uses it has way less easy to make flaws, and thus I reduce the number of tests needed in the end of the day). As if programming is or not a "solo activity", this depends on many things, I certainly have hundreds of solo projects of mine and I love working on them, and I also have my projects that are developed along with other people, and I love them as well. Programming for me is at the same time a form of expression, and art and a job at the same time.
> Sure, in an ideal world you could document the entire program in the type system, but the languages people normally use simply don't have what it takes to enable that. They lean on testing instead. Worse is better, I suppose.
As I said before, Rust does have that, and many modern languages have more and more on that. I understand that the world mostly uses less powerful languages, but this is not their fault, most languages have dozens of legacy projects behind them and it is really hard to let go (I mean, there are important programs written in COBOL nowadays, and I assume the language is even worse than your "worse is better", but people still need to use it). I'm not advocating for abandomning those projects, nor that languages with worse type systems are terrible, but that you should simply not say "it is better" just because people need to use it because of reasons, nor glorify their mediocrity. Mediocrity should be enhanced (and that's why even Go, a "simple language" is still gaining features from time to time, even it is not a crystalized stone of specific directives that will never change, and some day it will have more and more features as time moves on; all languages are slowly evolving, even COBOL itself, so if being "worse" is a goal, I think most of them are not following that goal).
> We should probably talk about my fee structure first. I don't want you coming back crying that it was too much when I send you the bill for the work performed.
> That said, under my professional duty to act your interest, I expect you would far better served thinking about how you might go about avoiding testing the shape given a random useful test. You don't really need my services here.
Oh, sorry, I thought this was a discussion where people was really trying to reach the truth, not some sort of "pay me if you want to see my point" kind of thing. I'm more of a "talk is cheap, show me the code guy", and I will certainly not pay someone to justify their own onus probandi. If this is how things will be, I think a discussion with you furthermore would be pointless.
> It doesn't even have proper support for something basic like value constraints, let alone more advanced concepts. It has more features than Go, but I fail to see how that offers transcendence beyond half-assery. I'll grant you that it is less half-assed, just as I did earlier.
And this is obviously an extreme form of exaggeration. I literally coded a basic working numeric system in rust type system with mathematical operations just for fun (and there are crates that does that), if this don't imply the language has a very powerful one I don't think anything would. Obviously, I'm not saying that Rust has THE MOST powerful type system, I never once implied that, but it is not "half-assery" in any way, it is also many times above what Go is able to do. It's not only "more features", it is fundamentally more open to changes and advancements than it is.
--------------- (part 2)