4 ms·

If Go isn't geared towards usability, I don't think it is same definition of usability most adhere to.

by Ygg2 12y ago

smt88 12y ago
Having to write a ton of boilerplate is not "usable". There are several things in Go that I've never seen written in a way that doesn't use a lot of boilerplate. In fact, if you search for criticism of Go, that's going to be near the top. Another is that the packages don't have version-matching. Edit: And, again, this is not to say Go is a bad language or that people shouldn't use it. I'm just pointing out one example of where the Go authors prioritized simplicity over usability. I'm not commenting on the whole language.
- burntsushi 12y ago
  You started off this comment thread by asking what kind of research was done to achieve something that is usable. I like that tact because it implies that "usability" isn't something you can reason about from first principles and come up with the right answer to, "Is this software usable?" Instead, it acknowledges the fact that usability should be data driven. What do people using it think? But your last few comments in this thread seem to have taken a different tact. You've projected some definition of usability that you hold instead of acknowledging that others may think differently. For examples, I can promise you that the Go authors don't think they "prioritized simplicity over usability." They would say that Go is very usable because it is simple. You disagree, and that's totally cool, but we should be careful to frame it as a difference in perspective. P.S. Rust and Go are very usable (to me). :-)
  - smt88 12y ago
    I can see where you're coming from, but I've posted a lot of comments on this topic, and I absolutely acknowledge that I don't feel certain about these things. For example, I'm not certain that I agree with Go authors that "simplicity = usability", but I really don't know. I plan to master Go, and then maybe I'll have a better idea. I've also acknowledged that even my definition of "simplicity" isn't the same as everyone else's. You seem to be reacting to my argument that boilerplate != usability, and I stand by that. Typing the same thing over and over is fragile, and it's antithetical to the concept of programming. If there's anything that I can say with absolute certainty is vital to usable programming, it's DRY. Other than that, I really am curious to know what usability really means. I've seen a lot of interesting studies on HN that contradict commonly held notions (e.g. refactor often). It'd be so cool and important for a language to base itself entirely off of such research, rather than a small group's experiences.
- Ygg2 12y ago
  Something being usable doesn't imply boilerplate being present or not. In fact I think most if not all languages have boilerplate. They might mitigate it with some macros, but the boilerplate is there. Usability just means ease of use and learnability. In context of computers languages, I think having a smaller set of idioms/stuff to learn is more vital to usability than to have less stuff to type.

If Go isn't geared towards usability, I don't think it is same definition of usability most adhere to.

by Ygg2 12y ago

If Go isn't geared towards usability, I don't think it is same definition of usability most adhere to.

smt88 12y ago

Having to write a ton of boilerplate is not "usable". There are several things in Go that I've never seen written in a way that doesn't use a lot of boilerplate. In fact, if you search for criticism of Go, that's going to be near the top. Another is that the packages don't have version-matching. Edit: And, again, this is not to say Go is a bad language or that people shouldn't use it. I'm just pointing out one example of where the Go authors prioritized simplicity over usability. I'm not commenting on the whole language.

burntsushi 12y ago
You started off this comment thread by asking what kind of research was done to achieve something that is usable. I like that tact because it implies that "usability" isn't something you can reason about from first principles and come up with the right answer to, "Is this software usable?" Instead, it acknowledges the fact that usability should be data driven. What do people using it think? But your last few comments in this thread seem to have taken a different tact. You've projected some definition of usability that you hold instead of acknowledging that others may think differently. For examples, I can promise you that the Go authors don't think they "prioritized simplicity over usability." They would say that Go is very usable because it is simple. You disagree, and that's totally cool, but we should be careful to frame it as a difference in perspective. P.S. Rust and Go are very usable (to me). :-)
- smt88 12y ago
  I can see where you're coming from, but I've posted a lot of comments on this topic, and I absolutely acknowledge that I don't feel certain about these things. For example, I'm not certain that I agree with Go authors that "simplicity = usability", but I really don't know. I plan to master Go, and then maybe I'll have a better idea. I've also acknowledged that even my definition of "simplicity" isn't the same as everyone else's. You seem to be reacting to my argument that boilerplate != usability, and I stand by that. Typing the same thing over and over is fragile, and it's antithetical to the concept of programming. If there's anything that I can say with absolute certainty is vital to usable programming, it's DRY. Other than that, I really am curious to know what usability really means. I've seen a lot of interesting studies on HN that contradict commonly held notions (e.g. refactor often). It'd be so cool and important for a language to base itself entirely off of such research, rather than a small group's experiences.
Ygg2 12y ago
Something being usable doesn't imply boilerplate being present or not. In fact I think most if not all languages have boilerplate. They might mitigate it with some macros, but the boilerplate is there. Usability just means ease of use and learnability. In context of computers languages, I think having a smaller set of idioms/stuff to learn is more vital to usability than to have less stuff to type.