Hacker News Reader

Comment by ReleaseCandidat | Hacker News Reader

This is meant as more of a general comment than to critisize this editor: I fail to see the selling point of an editor that "can't do much", but is performant - there is an abundance of these already. If you made an editor that does "everything" and is "fast", I may be interested.

Regarding Jai: the idea about a "language for good programmers" is just about the worst thing ever to say about a language and it's community in my opinion (and I'm being paid as a C and C++ programmer for 20 years now, so I guess I'm at least not totally bad at it).

View on HN

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.

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.

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.

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).

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

>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

I always interpreted Jon Blow “good programmer” = “cares about the craft”. Someone that knows deeply the tech stack and understands the tradeoffs made for each decision as opposed to those that just follow fashions and dogmas without evaluation (Object oriented, garbage collection, web framework du jour…). That’s my interpretation after following Jon for a while. could be wrong.

This looks at least untypical for a "small and fast" editor in that it is a UI application, not running in the terminal like vi or nano.

That's true. The modern day obsession with the terminál (emulátors) is something I don't get either. But I actually did use Unix back than (mostly Irix, which was the MacOS of it s day).

Reply on news.ycombinator.com