Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rob Pike: The Best Programming Advice I Ever Got.

informit.com

Post reply on HN
Print view View original

101–110 of 142 posts

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

#101

Post by dscrd »

sausagefeet wrote: post #98
dscrd wrote: post #87

Earlier quoted context omitted.

You forget the fact that Go is a young language while modern C implementation has to support several standards, countless extensions and probably decades of cruft in the codebase. Additionally, if you factor in that go includes a tool that replaces most of what autotools gdoes in the C world, we're talking about a huge blob of accidentally complex code. It's very reasonable to think that the Go implementation is simp…

I'm not forgetting. The make tools are not part if the language and irrelevant. Most C developers I know avoid extensions for portability reasons. The cruft part doesn't matter much for this discussion either, you can start from scratch if you want like TCC. The language definition of Go requires some things that C does not for any reasonable implementation. I think it is much more reasonable to think a C implementat…

Everything else you said I'll grant with "we have differing opinions" except

"The make tools are not part if[sic] the language and irrelevant"

No, they're quite a lot more than just make replacement. And definitely not irrelevant!

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

#102

Post by ajays »

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, would just sit and stare into space for a while; then jot down the entire program on paper. Then he would enter it into the editor, fix a couple of typos that the compiler caught, and run it. His program always worked on the first or second attempt.

Funny part? he hated to program, and was a theoretician.

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

#103

Post by myle »

ajays wrote: 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?

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

#104

Post by duaneb »

adestefan wrote: post #93
msluyter wrote: post #71

I wonder if building these mental models has become more difficult with the rise of multi-layered/full-featured programming frameworks. I'm thinking of things like Spring or Rails. A given webapp might involve a dozen layers or so: a database language (SQL), a database wrapper (Hibernate or ActiveRecord), a server side language, templating languages, client side languages (javascript), CSS, HTML, etc... etc... Unders…

One of the things it has led me to do is assume that the everything else is correct and I must be doing something wrong. We do that with compilers, interpreters, the OS, hardware, etc., too. It's usually a decent starting assumption, but it can lead to wasted hours when the problem really is outside of what you've done.

Yes - there was once a bug that took me three weeks to track down, and it ended up being in the compiler.

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

#105

Post by duaneb »

sausagefeet wrote: post #85
luriel wrote: post #81

Earlier quoted context omitted.

In many ways Plan 9 is simpler than Unix, and Go is simpler than C. Unix was also much simpler than Multics. Software doesn't need to always grow in complexity, but it takes lots of determination to accomplish this.

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.

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

#106

Post by hkarthik »

thebigshane wrote: post #94
hkarthik wrote: post #69

This is a really relevant article. These days there are legions of programmers who don't think about underlying issues and just throw clever hacks in to get things working and move on. Worse yet, some of these types end up in managerial roles where they expect others to work as quickly and sloppily as they used to.

It's worth noting that the "clever hacks in to get things working and move on" has proved to be a fairly decent business model for smaller projects or smaller companies. Creates ugly code, sure...

agreed. But there is a difference between knowingly doing something sloppy to get things done in the short term versus working like that on a regular basis and thinking it's just how programs are written.

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

#107

Post by wpietri »

msluyter wrote: post #71

I wonder if building these mental models has become more difficult with the rise of multi-layered/full-featured programming frameworks. I'm thinking of things like Spring or Rails. A given webapp might involve a dozen layers or so: a database language (SQL), a database wrapper (Hibernate or ActiveRecord), a server side language, templating languages, client side languages (javascript), CSS, HTML, etc... etc... Unders…

IOW, being a "full stack" generalist is getting harder, imho

But more valuable. Coding with people who started with Rails, they may not know that there are 1000x differences between things that seem equivalent to them. In ye olden dayes it was hard to be off by that much because the problems would surface sooner.

I know people who make incredibly good money cleaning up after teams that lack a single full-stack person.

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

#108

Post by sausagefeet »

dscrd wrote: post #101
sausagefeet wrote: post #98

Earlier quoted context omitted.

I'm not forgetting. The make tools are not part if the language and irrelevant. Most C developers I know avoid extensions for portability reasons. The cruft part doesn't matter much for this discussion either, you can start from scratch if you want like TCC. The language definition of Go requires some things that C does not for any reasonable implementation. I think it is much more reasonable to think a C implementat…

Everything else you said I'll grant with "we have differing opinions" except "The make tools are not part if[sic] the language and irrelevant" No, they're quite a lot more than just make replacement. And definitely not irrelevant!

They are irrelevant to discussing implementation details of the languages.

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

#109

Post by rje »

djtriptych wrote: post #41
rimantas wrote: post #28

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…

Thank you for re-re-re-reminding me to read that. link for anyone else who's been meaning to read this: http://amzn.com/0393316041

I recommend: http://www.amazon.com/Classic-Feynman-Adventures-Curious-Cha...

It has both "Surely You're Joking, Mr. Feynman!" and "What Do You Care What Other People Think?" in a nice hardcover.

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

#110

Post by sausagefeet »

cpeterso wrote: post #83
dinkumthinkum wrote: post #13

Earlier quoted context omitted.

I disagree, you'd be surprised how many people have the mental model of various large code bases (think Linux kernel) in their minds. It's not as if you are some savant memorizing all the lines of code and it helps to differentiate between "complexity" and "a mess." :)

Linus refused to merge the kernel debugger patches for a very long time because he felt that if a bug could not be solved by thinking (and logging), then the code was too complicated.

Did he state what changed his mind?
Post reply on HN