> more characters typed does not necessarily directly result in more bugs, as far as I know
Most of the discussions I could find on the topic before writing that post suggested that the error rate per thousand lines of code is surprisingly constant across languages, which suggests that more characters typed does result in more bugs. I learned that from the internet though, so take it with a grain of salt!
It's true that `bind:value={foo}` offers another way to change the value of `foo` besides `foo += 1`, since at that point you're explicitly opting in to two-way binding. If you prefer, you certainly can do the `on:change={handler}` thing instead, but as I argue in the post I think that's less effective at capturing the intent of your code (and gives bugs more places to hide). This is definitely a subjective area though.
> Most of the discussions I could find on the topic before writing that post suggested that the error rate per thousand lines of code is surprisingly constant across languages, which suggests that more characters typed does result in more bugs. I learned that from the internet though, so take it with a grain of salt!
It's an interesting subject, but I'd like a causal explanation rather than just the correlation. For example, this would imply that TypeScript code would be more buggy than its Javascript equivalent, since it's the same code I'd write otherwise, with additional annotations. (Then again, there is some code, like null checks, that I don't have to write with TypeScript, so perhaps that evens out.)
> I think that's less effective at capturing the intent of your code
It's been a while since I've worked with Angular.js, the last framework I used with two-way databinding, but now having this conversation I think I recall the main reason it was confusing. A pattern that would sometimes arise is e.g. for a component to receive data through a two-way databinding from its parent, and then likewise passing that on to a child. That could make it very hard to trace where a change was coming from.
It might well be the case that it is far less problematic when e.g. only used to bind form values. Again, I'd have to try it to get a proper feel for it, so I'm looking forward to doing that.
> It's an interesting subject, but I'd like a causal explanation rather than just the correlation.
A large benefit with less code is about the signal/noise ratio. If you need plenty of boiler plate logic, you will have less signal that you can physically read & mentally process at a given time. We naturally ignore the noise, but the noise takes screen space & miscategorizing noise leads to bugs.
Less code leads to less bugs, especially high-level bugs, because the programmer can see more signal at a given time, thus being exposed to a larger system.
The study that Rich mentioned could be interpreted as relating to the comprehension of the code, where more code inherently means the system has more information & is more difficult to comprehend.
Re: two-way binding, the data flow is inherently confusing whether you use imperative or declarative logic. Do you want a clear concise representation or do you want to spread out the implementation over more code/files?
Absolutely, and "higher signal-to-noise-ratio" is something I'd count as a selling point. However, I don't believe fewer characters necessarily result in a higher ratio.
So in the case of two-way data binding, if I'm trying to trace how a certain value was be modified, data flow in the opposite direction might count as "noise", in terms of extra cognitive load.
Again, this might not be something that is the case for Svelte, but it's what I observed in Angular.js.
Most of the discussions I could find on the topic before writing that post suggested that the error rate per thousand lines of code is surprisingly constant across languages, which suggests that more characters typed does result in more bugs. I learned that from the internet though, so take it with a grain of salt!
It's true that `bind:value={foo}` offers another way to change the value of `foo` besides `foo += 1`, since at that point you're explicitly opting in to two-way binding. If you prefer, you certainly can do the `on:change={handler}` thing instead, but as I argue in the post I think that's less effective at capturing the intent of your code (and gives bugs more places to hide). This is definitely a subjective area though.