Live data from Hacker News

Rob Pike: The Best Programming Advice I Ever Got.

informit.com

111–120 of 142 posts

Re: Rob Pike: The Best Programming Advice I Ever Got.

#111
post #105

Earlier quoted context omitted.

A Go implementation is likely more complicated than a C one. You don't think that GC is free, do you?

Actually, the go implementation is very simple, if a little arcane in the style of C used.

Simple compared to what? The Go implementation is very immature, I'll grant you that, but it is definitely more complex than an implementation of C at a similar point in its life. At the very least Go supports, fairly straight forwardly, a lot of C and it has a GC and multiplexing user land threads over multiple cores.

* Assume C90

Re: Rob Pike: The Best Programming Advice I Ever Got.

#112
Then again, how many times have you found a bug caused by a single line or function call or bit of syntax that didn't do exactly what you thought, that was easily overlooked? Particularly in someone else's code in a language that isn't your main one. I think line level interactive debugging is valuable precisely because it tells you what you really know for certain at the local level, and so lets you reason more effectively about the big picture.

Re: Rob Pike: The Best Programming Advice I Ever Got.

#113
post #105

Earlier quoted context omitted.

Actually, the go implementation is very simple, if a little arcane in the style of C used.

Simple compared to what? The Go implementation is very immature, I'll grant you that, but it is definitely more complex than an implementation of C at a similar point in its life. At the very least Go supports, fairly straight forwardly, a lot of C and it has a GC and multiplexing user land threads over multiple cores. * Assume C90

Ahh, if we are comparing equivalent implementations, you are definitely correct. GC and goroutines are much more complex than anything in C. In fact, off the top of my head, the only features truly missing in Go from C are unions (unfortunately) and the preprocessor (effectively a part of C).

Re: Rob Pike: The Best Programming Advice I Ever Got.

#114
post #103
post #102

One of the best programmers I have known was a CS theory guy. We were working on these tightly-coupled multiprocessor machine which was quite unstable, and would hard lockup if something went wrong in the program (requiring a walk over to the machine room, hitting the reset button, etc.). We would start hacking at our assignments quickly, and make innumerable trips to the machine room. This guy, on the other hand, wo…

The best advice I had (from a theoretician) was that I should not try to randomly fix my code but I should understand why it does not work. How to do that? Can you prove (in the mathematical sense) that it always does what you want?

Giving a full proof that takes language semantics into account is very difficult. I think it isn't a practical way to verify programmes but maybe it'll be in future.

Re: Rob Pike: The Best Programming Advice I Ever Got.

#115
This must be why my best bugfixes happen when I'm taking a shower. The number of times I'm showering and suddenly realize what is causing a particular programming problem is pretty surprising. Because of this phenomena, I've taken to going for a walk when something is stumping me.

Re: Rob Pike: The Best Programming Advice I Ever Got.

#116
post #114
post #103

Earlier quoted context omitted.

The best advice I had (from a theoretician) was that I should not try to randomly fix my code but I should understand why it does not work. How to do that? Can you prove (in the mathematical sense) that it always does what you want?

Giving a full proof that takes language semantics into account is very difficult. I think it isn't a practical way to verify programmes but maybe it'll be in future.

I don' think the advice is to do a proof, but rather to design and think about it in such a way that you could given enough time.

Re: Rob Pike: The Best Programming Advice I Ever Got.

#117
post #82
post #77

Earlier quoted context omitted.

Me too. I used to really get frustrated when others couldn't see what I thought were obvious answers looking at a situation. Now I've come to sincerely believe there's something strange in me that allows me to see these things because when I've tried to take the Socratic method to get others to see what I see in various situations, I realize there are a lot of people who actually can't. Some people can get it via exp…

It's sad to say, but the majority of people cannot follow a logical progression more than a two or three steps. It's not even an issue of "smart" vs "dumb", as many of my quite clever coworkers have this issue. It seems to me to be predicated on the ability to keep a lot of state in your head. If in order to reach an answer you need to synthesize the results of two logical conclusions and you can't keep the first res…

> It seems to me to be predicated on the ability to keep a lot of state in your head.

There's some research and discussion among educators and neuroscientists about how working memory may be more important than IQ. IANAE but my anecdotal experience also supports this.

http://duckduckgo.com/?q=working+memory+more+important

Re: Rob Pike: The Best Programming Advice I Ever Got.

#118
post #72

At what point in a neophyte programmer's life should he/she switch from the "immediate & non-stop coding" Khan Academy approach recently discussed here on HN to this Ken Thompson "take a moment and think first" approach? Isn't there the danger that they might not be able or motivated to make the switch?

As a recent neophyte, I will use my anecdotal data of size 1 to hazard an answer. I believe once syntax has become relatively understood is when a programmer should start mapping (mentally or on paper) the steps they need to successfully complete a program.

Re: Rob Pike: The Best Programming Advice I Ever Got.

#119

This reminds me an episode in "Surely You're Joking, Mr. Feynman!" where he fixes a noisy radio just by trying to understand how can the problem happen and comes to conclusion that the most likely cause is that amp's vacuum tubes heat first and generate a lot of noise before the rest of the circuit is ready. He swaps tubes, problem is gone and the owner of the radio (which was very sceptical at first) goes around tel…

The power of thought is strange. I happen to have this ability as well. That's mainly why I'm still employed. A couple of years ago, we originally had a 4 man team. 3 of those guys left, leaving me (the junior dev) to deal with the whole platform. I didn't have any time for error, but I didn't know a darn thing. I did, however, had the ability of the "hunch". Basically, when a problem happened, instead of opening the…

I amaze myself all the times with this. To me its just logic, but I'm sure its something more. I'll probably never figure it out, but that's not to my detriment.

I vaguely recall a story that my grandfather used to be very good at doing math in his head, and actually lost this skill when he tried to understand his own thought process well enough to explain it to others...

Re: Rob Pike: The Best Programming Advice I Ever Got.

#120

This reminds me an episode in "Surely You're Joking, Mr. Feynman!" where he fixes a noisy radio just by trying to understand how can the problem happen and comes to conclusion that the most likely cause is that amp's vacuum tubes heat first and generate a lot of noise before the rest of the circuit is ready. He swaps tubes, problem is gone and the owner of the radio (which was very sceptical at first) goes around tel…

The power of thought is strange. I happen to have this ability as well. That's mainly why I'm still employed. A couple of years ago, we originally had a 4 man team. 3 of those guys left, leaving me (the junior dev) to deal with the whole platform. I didn't have any time for error, but I didn't know a darn thing. I did, however, had the ability of the "hunch". Basically, when a problem happened, instead of opening the…

I think a lot of engineers get to this point through different methods.

For me when I was new engineer (no CS background) I'd never spend too much time on a bug before I got frustrated and would head over to a more senior engineer's cube for advice. Usually during the walk over while I tried to properly form the exact question to ask I'd figure out the answer. Dan (my go to guy for this) got used to seeing me head his way then just say hi, he'd ask "Figured it out?" and I'd say "Yep" and head back to my desk.

Post reply on HN