4 ms·

GO was named a language for bad (not experienced) programmers by its creator. I don't see why doing the reverse of that automatically egregious I mean sure, p

by Xeamek 3y ago

GO was named a language for bad (not experienced) programmers by its creator. I don't see why doing the reverse of that automatically egregious I mean sure, people are in general hesitant when someone calls himself good, and for a decent reason. But pushing it to extreme and defaulting to reverse JUST BECAUSE someone dared to call himself good is also a pretty childish reaction. At the end of the day it is a fact that there are differences in skill between programmers and different languages expect from you different levels of understanding. Pretending it's only valid to acknowledge these differences in others but not in oneself is irrational.

ReleaseCandidat 3y ago
Ok, so let me be a bit more concrete: I do _not_ want to work with or have to maintain or use the software of people who claim of themself to be "good programmers" who are "able to handle manual memory management" (and similar) any more. Yes, of course there are exceptions and I'm not saying that John Blow isn't one of them and I also don't know if the formulation is his or of somebody else (as I don't know anything about him or his games). But the problem is that now people are drawn to the language to "proof" that they are "good programmers". > Pretending it's only valid to acknowledge these differences in others but not in oneself is irrational. I do hope that we can agree that people are way better at assessing others than themselves - in both ways, under- and overestimation of their own capabilities.
ithkuil 3y ago
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

by Xeamek 3y ago

ReleaseCandidat 3y ago

Ok, so let me be a bit more concrete: I do _not_ want to work with or have to maintain or use the software of people who claim of themself to be "good programmers" who are "able to handle manual memory management" (and similar) any more. Yes, of course there are exceptions and I'm not saying that John Blow isn't one of them and I also don't know if the formulation is his or of somebody else (as I don't know anything about him or his games). But the problem is that now people are drawn to the language to "proof" that they are "good programmers". > Pretending it's only valid to acknowledge these differences in others but not in oneself is irrational. I do hope that we can agree that people are way better at assessing others than themselves - in both ways, under- and overestimation of their own capabilities.

ithkuil 3y ago

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