Rob Pike: The Best Programming Advice I Ever Got. • Hacker News Board

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

#131

Post by kragen » Fri, Aug 17, 2012, 12:24 AM UTC

duaneb wrote: post #113

sausagefeet wrote: post #111

Earlier quoted context omitted.

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

Have you ever implemented GC or fibers? They can be pretty simple to implement, really.

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

#132

Post by manaskarekar » Fri, Aug 17, 2012, 12:52 AM UTC

kragen wrote: post #129

manaskarekar wrote: post #59

Here's a link to the (incomplete) sample chapter on their website for 'The Practice of Programming' on Debugging. http://cm.bell-labs.com/cm/cs/tpop/debugging.html I had this in my wishlist for a while. This just made me buy it. Wonder how different it will be from Code Complete 2.

It's very similar to Code Complete, but much, much shorter. Also, Code Complete has a fair bit of dumb stuff mixed in with the gems of wisdom that comprise most of it; TPOP doesn't.

Thanks for that quick overview. :)

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

#133

Post by swift » Fri, Aug 17, 2012, 1:33 AM UTC

msg wrote: post #122

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

Use debugging to form a mental model. When I'm trying to understand foreign code in less than enough time, I instrument it (almost always at inputs/outputs) and try to treat functions as black boxes. In an ideal world the black boxes would be working. Data flows are as important as algorithms. See this thing from Guy Steele. http://dreamsongs.com/ObjectsHaveNotFailedNarr.html In particular: Fred Brooks, in Chapter 9…

"Smart data structures and dumb code works a lot better than the other way around."

An interesting assertion. In your link Guy Steele observes the duality between objects (where it's easy to add new data types but harder to add new operations that work on all of them) and abstract data types (where it's easy to add new operations but harder to add new data types).

Guy says that the former tradeoff is almost always the right one, but I've encountered many situations where the latter was much more convenient. It's far more preferable IMO to be able to choose which tradeoff you prefer based upon the constraints of your particular problem.

This usually is not so much a language-level problem as a cultural problem; many programmers are infatuated with OO (I know I was at one time) and unaware of the tradeoffs OO makes or when it's appropriate to use another approach. Hopefully over time multiparadigm languages like Python will help make "objects vs ADTs" more of an engineering question and less of a religious one.

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

#134

Post by duaneb » Fri, Aug 17, 2012, 4:28 AM UTC

kragen wrote: post #131

duaneb wrote: post #113

Earlier quoted context omitted.

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

Have you ever implemented GC or fibers? They can be pretty simple to implement, really.

They are conceptually more high level than anything in C - that's what I meant.

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

#135

Post by cr4zy » Fri, Aug 17, 2012, 4:32 AM UTC

I think this works because you're devoting more energy to the problem than to the sensory and mechanical parts of your brain that will be used to enact the fix. But it's not natural because socially it can look as if you're not 'working'.

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

#136

Post by svdad » Fri, Aug 17, 2012, 5:48 AM UTC

itmag wrote: post #24

This is relevant: http://esr.ibiblio.org/?p=316 Also, I'm curious about something. Those of you who are good at building mentals models: are you also visual thinkers?

Very. It's just how my mind puts things together, not something I can try to do or not do. I tend to see programs in blocks and patterns interacting rather than sequences of logical operations, probably why I tend to prefer the object-oriented paradigm over others. I get bogged down when I can't visualize the interactions. It isn't just programming, either -- working with derivative products in finance I formed very detailed visual mental models of how they operated.

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

#137

Post by svdad » Fri, Aug 17, 2012, 5:50 AM UTC

aangjie wrote: post #90

mseebach wrote: post #38

Earlier quoted context omitted.

That's one of the less obvious (to me, at least) benefits of test driven development: When you're writing out your unit test, you're forced to think about how the implementation is going to work.

It does help in some sense, but not always. I found that, if i wrote out test cases like i am preparing a test scenario document for someone in plain English it works. If i have to open vim and write test cases, i seem to the hack mode and write out the most trivial cases, causing painfully slow development. Test Document + thinking/visualization works better for me.

I've found this as well. Just blindly writing test cases doesn't work so well unless you've already understood the higher level operation of what you're trying to build, and obviously does tend to slow down development.

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

#138

Post by sausagefeet » Fri, Aug 17, 2012, 5:57 AM UTC

kragen wrote: post #131

duaneb wrote: post #113

Earlier quoted context omitted.

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

Have you ever implemented GC or fibers? They can be pretty simple to implement, really.

There is a big difference between implementing them for fun and implementing them for a production system. Regardless, even if they are simple to implement they are more than what C90 has so, by definition, more complex implementation.

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

#139

Post by alan-crowe » Fri, Aug 17, 2012, 12:31 PM UTC

gklitt wrote: post #21

A professor of mine who worked at Bell Labs once made the same point. "In the old days we had to think a lot about how our punch card program worked because we'd only find out if it worked the next day. Nowadays you guys just throw crap at the wall and see what sticks. Find the middle ground."

How do you find the middle ground? My hypothesis is that one can write the tests first and use them as a compass. If debugging proceeds monotonically, you have thought enough. If you fix the bug revealed by test r, but later when you fix the bug revealed by test s, test r starts failing again, that is a clue that you didn't think enough.

What the clue means will depend on the order of the tests. If the tests were written in order of increasing code coverage it is probably a clue that the algorithm needs more thought, but it could be a clue that one hasn't thought enough about test coverage and has ones tests in an unhelpful order.

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

#140

Post by gabriel » Fri, Aug 17, 2012, 1:04 PM UTC

duaneb wrote: post #25

jon6 wrote: post #8

You are only so smart. Once the complexity of the programming model reaches a certain point a debugger is necessary to validate and discover the true nature of a system. Often that point is quite low.

> Often that point is quite low. I've found that liberal logging and careful error management has almost replaced the debugger entirely. In the last three months, I've only fired up the debugger twice, and that was when I was working with untyped memory and peeking at memory through the debugger was the most efficient way to get things done.

I'm also one to use logging and error management to help my way through a program. I don't understand how anyone else does it any other way. But surely the debugger helps a lot when no other way to reason about your code exists.

I have a lot of problems explaining this to the people I work with. Most of the errors we make are in some way related to having imperfect information through the debugger.

At some point complexity gets so high the debugger isn't even capable of handling the system under inspection. What are the tools we use in these cases?