4 ms·

Allow me to try and convince you of its importance :) https://svelte.dev/blog/write-less-code https://svelte.dev/blog/write-less-code

Vinnl 7y ago
I actually read that just before this comment :) Edit: Some more clarification about why the arguments don't hold for me. - More code = more bugs I think code that is harder to understand leads to more bugs, but more characters typed does not necessarily directly result in more bugs, as far as I know. - Writing code takes more time Again, it's not the typing that takes time, but thinking of which code to write. If I have to type more, but there's less for me to keep in mind while typing (i.e. lower cognitive load), I'll be faster at that. As said: yes, readability is important, but that's a different value than "write less code". I'm trying not to make a judgment about Svelte here specifically since I haven't worked with it yet, and the general concept (of being a compiler rather than working during run-time) appeals to me. That said, concepts like bindings do scare me - with e.g. `useState` I know that the only places that can change `a` are those that call `setA`, whereas it appears that with Svelte, it can also change e.g. in response to `bind:value` attributes? I'm (perhaps misguidedly) afraid that that's saving a few characters at the cost of readability.
- rich_harris 7y ago
  > 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.
  - Vinnl 7y ago
    > 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.
    - briantakita 7y ago
      > 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?
Improvotter 7y ago
What are your opinions of Go where it is the general idea to only have 1 way to do something, and make that way the best way?
- Vinnl 7y ago
  I have not used Go, or even looked at it, so I can't really give a well-reasoned comment about it. As for the general principle of having just one way to do something: I don't think that's a general rule that I'd prefer, because I don't believe there's always a clear best way. I think my problem with two-way data binding is not so much that it's an additional way to update a value, but that it doubles up as reading and writing a value, and with that makes code somewhat harder to read. However, as I noted in response to Rich, that might not be a problem if that is only limited to variables bound to forms, but I'd have to try it to get a better feeling for that. But I'm getting off-topic, so the answer is: I don't really have an opinion about Go, but the general principle you describe is not one that attracts me.
ryansolid 7y ago
Yeah I don't know. More noise sure but I fear Svelte just misses the point. I'd write a rebuttal but I sort of already have: https://medium.com/@ryansolid/what-every-javascript-framework-could-learn-from-react-1e2bbd9feb09 https://medium.com/@ryansolid/what-every-javascript-framewor...

Vinnl 7y ago

I actually read that just before this comment :) Edit: Some more clarification about why the arguments don't hold for me. - More code = more bugs I think code that is harder to understand leads to more bugs, but more characters typed does not necessarily directly result in more bugs, as far as I know. - Writing code takes more time Again, it's not the typing that takes time, but thinking of which code to write. If I have to type more, but there's less for me to keep in mind while typing (i.e. lower cognitive load), I'll be faster at that. As said: yes, readability is important, but that's a different value than "write less code". I'm trying not to make a judgment about Svelte here specifically since I haven't worked with it yet, and the general concept (of being a compiler rather than working during run-time) appeals to me. That said, concepts like bindings do scare me - with e.g. `useState` I know that the only places that can change `a` are those that call `setA`, whereas it appears that with Svelte, it can also change e.g. in response to `bind:value` attributes? I'm (perhaps misguidedly) afraid that that's saving a few characters at the cost of readability.

rich_harris 7y ago
> 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.
- Vinnl 7y ago
  > 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.
  - briantakita 7y ago
    > 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?

Improvotter 7y ago

What are your opinions of Go where it is the general idea to only have 1 way to do something, and make that way the best way?

Vinnl 7y ago
I have not used Go, or even looked at it, so I can't really give a well-reasoned comment about it. As for the general principle of having just one way to do something: I don't think that's a general rule that I'd prefer, because I don't believe there's always a clear best way. I think my problem with two-way data binding is not so much that it's an additional way to update a value, but that it doubles up as reading and writing a value, and with that makes code somewhat harder to read. However, as I noted in response to Rich, that might not be a problem if that is only limited to variables bound to forms, but I'd have to try it to get a better feeling for that. But I'm getting off-topic, so the answer is: I don't really have an opinion about Go, but the general principle you describe is not one that attracts me.

ryansolid 7y ago

Yeah I don't know. More noise sure but I fear Svelte just misses the point. I'd write a rebuttal but I sort of already have: https://medium.com/@ryansolid/what-every-javascript-framework-could-learn-from-react-1e2bbd9feb09 https://medium.com/@ryansolid/what-every-javascript-framewor...