Think about this problem for a minute: modify google maps to add the user's choice of socio-metric data about the region shown: how many Andersen's live there? what's the average family size in the region? what's the school age population in the region, by grade?
Now think about how you thought about it.
If you're a manager you're likely to think about this in terms of breaking the job into manageable segments; thereby layering in your assumptions about process. Most programmers, in contrast, glob onto either the interface or the BI sides of the problem - and think in terms of actual operations within their preferred programming environment.
You get a similar effect when you take a simpler problem: imagine a program to add up all the integers from zero through n.
Did you think in terms of a loop or a formula? More interestingly, did you draw a mental distinction between trivial and non trivial values of N? did you think about non integer input representations?
Marc Rochkind's Advanced Unix Programming was written in 1984 and published in 1985 - by Prentice Hall, the same company subbing for Sun Microsystems Press on today's McDougall and Mauro Solaris Internals book. These two books have obvious points of comparability: they're both how-to books on Unix internals, they reflect the same core traditions, and both represent the state of the art at the time of publication -although the latter has some second edition confusion and occasionally struggles to bridge the gap between Solaris 2.9 and what should, I believe, be known as SunOS 3.0: Solaris 10.
Look a bit deeper, however, and there's also a more subtle commonality - the use of C to tie much of the discussion to the reality of actual OS programming practice and, more importantly, the influence C has had on the way the authors of both books think about Unix in general and each algorithm used in particular.
Like English, or any other spoken language of reasonable complexity. C influences how C users think about problems - affecting everything from the overall organization of these books to the specific examples selected. What that leads to is an interesting question: would Unix be Unix if it were written in something else?
(Interestingly -although it's irrelevant to this discussion- I noticed these unfortunately prophetic words: "Unix is rich enough so that two programmers are likely to come with vastly different solutions to the same problems" in Rochkind's introduction - suggesting that two programming teams who come up with the same solutions probably share something more than language and problem - a subject, I hope, for another day.)
I think the answer is No; the language fits the underlying OS design and has co-evolved with it. Thus examples from the 1984 Ritchie and Kernighan The C Programming Language work today - and the ideas, if not the details, in Rochkind's work generally do too - but even trying to think about this stuff in terms of a non C like language is like imagining yourself entering freeway traffic riding an elephant.
Language <--> OS conceptual consistency has been of benefit to Unix, and is a big issue for others: in fact, I've often thought that Apple's original MacOS should have been written on hardware built for LISP (dedicated LISP machines were built, but Apple ignored them) - and that designing the IBM 360 as an instruction set processor was probably the key decision dooming it to commercial success and scientific irrelevance from day one.
If in programming as in so much else, the medium really is the massage [not message], we could reasonably make an odd prediction: that stuff written in C++ should be less well organised, less general, and less efficient than stuff written in C - and that has an interesting corelary because it suggests that Java is an intellectual fit with Windows, but not Unix.