3 ms·

> Go’s simplicity tends to be brought [...] mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even

by mcherm 6y ago

> Go’s simplicity tends to be brought [...] mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language. Actually, type safety can be quite useful in such a context: it allows the person who designed the types in use to enforce certain restrictions on the developer who is hurriedly adding code to an unfamiliar codebase, thus reducing the requirement for that developer to understand larger issues in the system.

smiths1999 6y ago
I don't disagree, but this goes both ways (and I typically only see one side of this argument put forward). They also allow the person who designed the types to make the types so complex that the average user cannot understand what is going on. You may argue "well that person has no business looking at the code" but sometimes you have to look into other people's code when you are debugging an issue. No doubt type systems can allow you to write safer, more robust code. But they can also allow you to introduce new risks to your codebase, one of which is difficult to read/understand code.
rob74 6y ago
On the other hand, more often than not the developer who is (more or less hurriedly) adding code is trying to do something that the original designer didn't think of beforehand, and because of that they now have to jump through additional hoops to make it work...
- q3k 6y ago
  This is a good observation. Some of the best codebases I’ve worked with are the ones whose authors insisted on keeping things easy to modify or remove (not by introducing unnecessary abstraction, but by simplifying things as much as possible). Some of the worst codebases are those where the author assumed that their elegant solution is ultimate and will never be read in circumstances other than to be admired.

by mcherm 6y ago

smiths1999 6y ago

I don't disagree, but this goes both ways (and I typically only see one side of this argument put forward). They also allow the person who designed the types to make the types so complex that the average user cannot understand what is going on. You may argue "well that person has no business looking at the code" but sometimes you have to look into other people's code when you are debugging an issue. No doubt type systems can allow you to write safer, more robust code. But they can also allow you to introduce new risks to your codebase, one of which is difficult to read/understand code.

rob74 6y ago

On the other hand, more often than not the developer who is (more or less hurriedly) adding code is trying to do something that the original designer didn't think of beforehand, and because of that they now have to jump through additional hoops to make it work...

q3k 6y ago
This is a good observation. Some of the best codebases I’ve worked with are the ones whose authors insisted on keeping things easy to modify or remove (not by introducing unnecessary abstraction, but by simplifying things as much as possible). Some of the worst codebases are those where the author assumed that their elegant solution is ultimate and will never be read in circumstances other than to be admired.