4 ms·

Sure, 'good' and 'bad' are inherently (too) simplistic descriptions. But imo, if we take the context in which J. Blow calls himself (and user of his language) "

by Xeamek 3y ago

Sure, 'good' and 'bad' are inherently (too) simplistic descriptions. But imo, if we take the context in which J. Blow calls himself (and user of his language) "good" programmers in good faith, then it would be natural to call those fresh googlers 'bad' (again, in the same context of meaning for 'good' and 'bad'). Not because they are inherently worse people and aren't talented - but simply because the reason you state yourself - they just don't have the experience to tread the fine line of using a super powerful language "properly" (YET).

ithkuil 3y ago
I disagree. The context that Jon uses is bad = careless, good = careful in the sense that I will make sure I deallocate my pointers. Pike's argument is not about new hires being careless or incapable of writing tests or understanding dangling pointers and all that stuff. The whole thing about memory safety is an external requirement to the whole discussion that Pike was starting. At the time it was already well understood that most security vulnerabilities at Google were caused by bugs around memory accesses and that even the most experienced engineers weren't immune to those. What Pike was talking about was: among the solution space of programming languages that can address those issues, some require a lot of training, whole others are simpler to pick up and yet "good enough". Rust is an example of a language that is solving the problem in a way that doesn't give up performance, but it does require a steeper learning curve. Pike argued that Google would benefit from a language that would require such a learning curve. The tradeoff will change with time. Now that rust exists an argument can be made that there is sufficient learning already spent
- Xeamek 3y ago
  >The context that Jon uses is bad = careless, good = careful in the sense that I will make sure I deallocate my pointers. Well I think this interpretation is reductive to say the least, and as such i don't agree with it. So that's that

by Xeamek 3y ago

ithkuil 3y ago

I disagree. The context that Jon uses is bad = careless, good = careful in the sense that I will make sure I deallocate my pointers. Pike's argument is not about new hires being careless or incapable of writing tests or understanding dangling pointers and all that stuff. The whole thing about memory safety is an external requirement to the whole discussion that Pike was starting. At the time it was already well understood that most security vulnerabilities at Google were caused by bugs around memory accesses and that even the most experienced engineers weren't immune to those. What Pike was talking about was: among the solution space of programming languages that can address those issues, some require a lot of training, whole others are simpler to pick up and yet "good enough". Rust is an example of a language that is solving the problem in a way that doesn't give up performance, but it does require a steeper learning curve. Pike argued that Google would benefit from a language that would require such a learning curve. The tradeoff will change with time. Now that rust exists an argument can be made that there is sufficient learning already spent

Xeamek 3y ago
>The context that Jon uses is bad = careless, good = careful in the sense that I will make sure I deallocate my pointers. Well I think this interpretation is reductive to say the least, and as such i don't agree with it. So that's that