Your link is discussing the development of Unix, which was before Rob Pike came on the scene. Rob Pike is discussing an incident that happened a number of years later when Rob would have been significantly junior to Ken. There is no reason that both versions of history can't be true.
On top of that, things would have grown in complexity since the early days.
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.
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…
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 result in your head while you work on the second, you're going to get lost.
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.
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.
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.
I just want to point out that Rob designed much of the logging infrastructure at Google. Take from that what you will.
For people who do not work at Google, is there something unusual (positive or negative) about Google's logging infrastructure?
On top of that, things would have grown in complexity since the early days.
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?
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?
Sometimes visual but more often I imagine the code physically. It has weight, or friction, or rigidity, depending on what aspects of the code I'm trying to think about.
Yes, I recognize this. A piece of code may be ugly (visual) but it may also be solid (kinesthetic). Or beautiful/brittle.
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?
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 simpler.
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.
I had the opposite reaction: I wonder if tests make it easier for you to fix code without forcing you to develop a mental model of it, assuming you're working in an unfamiliar codebase. That seems like something of a hidden drawback.
That may be possible, but it isn't inevitable. I use tests to validate that my mental model is correct. When I'm doing something greenfield, you'll see my tests are full of rather stupid-looking assertions of really basic stuff, and the reason for that is that about 5% of the time, my really basic so-simple-it-couldn't-be-wrong is wrong.
If you're building something that's going to be used as a foundation by lots of other things, those 5% errors add up really fast.
That's why it's very hard to juggle multiple projects at the same time. Every time you switch projects, you have to flush the old mental models of the old project out and reload the mental models of the new project. Same thing with interruption, it takes a while to rebuild the mental model after being interrupted.
I am beginning to realize this recently at my new job. Due to a couple of people leaving and stuff like that, i got handed a reportedly(half-written) code base with no test cases. And a knowledge transfer document, that was mainly written by a poor guy who had gotten the code(before me) and left the project in 3 weeks. In any case, couple of months into the project i got handed a different requirement. Guess what, a total of 10 months after i took the job the second tool is done and is in testing while i am still working on the first one. But the main problem so far has been, lack of clear visualisation of the requirements beforehand. Documenting a project specifications (functional or technical) is unheard of here it seems. I swear taking the time to gather all the requirements would have halved the time i spent developing,demoing, getting feedback,correcting/fixing suggestions etc.. sigh
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."
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.