4 ms·

I think the original point was misunderstood/twisted over time. TL;DR Inexperienced != Bad "The key point here is our programmers are Googlers, they’re not re

I think the original point was misunderstood/twisted over time. TL;DR Inexperienced != Bad "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." What Pike meant is that a company (e.g. google) cannot hire only people who have deep understanding in subtleties of advanced programming language theory and had the time to go through a long learning curve to actually reap the benefits of these advanced programming languages. These young engineers are not bad, quite the opposite they are usually bright and brilliant young engineers The problem with that kind of people is that they will use their cleverness to build complicated and beautiful stuff, but when combined with a lack of true and deep experience due to them being still young, this can become counterproductive.

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

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