The academics in computer science have gotten into the "_____" rut over the past several years. They claim that programs are more easily understood if the programmer uses some special language constructs and techniques. They don't all agree on exactly which constructs, of course, and the example they use to show their particular point of view invariably fit on a single page of some obscure journal or another-- clearly not enough of an example to convince anyone. When I got out of school, I thought I was the best programmer in the world. I could write an unbeatable tic-tac-toe program, use five different computer languages, and create 1000 line programs that WORKED (Really!). Then I got out into the Real World. My first task in the Real World was to read and understand a 200,000 line program, then speed it up by a factor of two. Any Real Programmer will tell you that all the _____ in the world won't help you solve a problem like that-- it takes actual talent.
This paragraph still holds, and it does so for any quiche-eating,effete value of _____.
Funny how often Real Programmers deride ______ while using _____ - 1. The Real Programmer's objection to ______ is always that it isn't performant or practical or available on the right platforms. In other words, Real Programmers stick to mature, widely-deployed technologies and become prodigiously adept at dealing with their (well-known) shortcomings while the idealistic Quiche-Eaters fight against the shortcomings of immature, incomplete systems that have unknown and often show-stopping flaws. It doesn't sound to me like Quiche-Eating programmers (distinct from Quiche-Eating pundits/academics) have it any easier than the Real Programmers. They may even be a little bit braver. (You might not want them working for you, though. Let some other company or project bear the burden of polishing immature technologies.)
While what you say is interesting, I consider it orthogonal to the statement given, namely that understanding _____ without real-world programming experience is not helpful when facing a real-world program for the first time.
I disagree. I think a programmer would be much worse off facing his first real-world programming problem armed only with an instruction set and a hex editor than if he had a C compiler and knowledge of C. Just knowing how structs and functions work gives you some mental tools for solving the problem. "Any Real Programmer will tell you that all the _____ in the world won't help you solve a problem like that" just doesn't make sense if read literally -- is he claiming that no set of ideas for structuring programs actually enhances your abilities at all? "It takes actual talent" is just an empty truism (like "______ is never a silver bullet.") So the statement falls apart when taken seriously, which calls the attitude it expresses into doubt.
And that's the dual thrust of the article. It doesn't just make fun of Quiche-Eaters. It also makes fun of Real Programmers. The humor is based on the difficulty of drawing a line between progressivism and trendiness. Or, to turn it around, the difficulty of drawing a line between pragmatism and fatalism. The article is written from the point of view of someone who errs on the side of fatalism (believing that no new ideas will ever prove useful) and who makes fun of people who err on the side of trendy prissiness (turning up their noses at anything mature enough to actually work.) The Real Programmer speaking in the article manages, quite ironically, to make just much fun of Real Programmers as Quiche-Eaters. Consider the paragraph you quoted. Of course the most appropriate ideas for finding your way around a legacy system are the ideas that were used to create that system! That illustrates how the (caricature) Real Programmer's perception of technical superiority is skewed by a lack of historical perspective (quite funny given his relish for history.) Quiche-eating, effete values of _____ have a way of turning into Real Programmer stuff when they became widespread and uncool. That means a lot of today's Real Programmer stuff consists of yesterday's quiche. Structured programming? That's C! The present-day Real Programmer sees himself as the inheritor of the guy who scorned present-day tools as effete, not as the inheritor of the Quiche-Eaters who pushed the development of present-day tools. (Likewise, one might parody Quiche-Eaters as not wanting their ideas to suffer the indignity of becoming mature and practical.)
1983? It's obvious this guy is just a kid. The stuff he talks about is new stuff. OS/370, 029 keypunches, Fortran 66, Quiche, for god's sake? I started programming in college in Fortran II on a 7094 running UMES (University of Michigan Executive System). The 360 let alone the 370 was yet to appear. Quiche had yet to make it across the Atlantic. My roommate told tales of his summer job in high school, programming an IBM 650 for NASA. The 650 didn't even have core memory, just a drum.
It wasn't "Real Programmers". It was "Real Men" programmed in Assembly Language. "Boys" programmed in Fortran. We had our testosterone unadulterated. Except an old coot told me, "Real Men do it in binary."
None of this Pac-Man stuff. We played baseball using the index register lights on the 7094 console and Space War on the PDP-1. We didnt use terminals or even the newfangled terminals, just the trusty 026 keypunch.
Honestly, I sat down to read this with the preconceived notion that it would be part of an ancient language war, but instead discovered one of the most cleverly written pieces of satire I can remember.
I especially like how the things he derides as belonging to "quiche eaters" (notably Unix, Emacs, and Vi), are what we consider 'hardcore tools for real programmers' today.
If there is not enough schedule pressure on the Real Programmer, he tends to make things more challenging by working on some small but interesting part of the problem for the first nine weeks, then finishing the rest in the last week, in two or three 50-hour marathons. This not only impresses the hell out of his manager, who was despairing of ever getting the project done on time, but creates a convenient excuse for not doing the documentation.
If you can't do it in Fortran, do it in assembly language. If you can't do it in assembly language, it isn't worth doing.
Physics department guys in my university had this printed out and stapled to the wall. Pretty much all math modeling libraries they wrote were in Fortran with some bottlenecks redone in assembly. It was more than 20 years ago though :)
It hasn't changed that much, at least not at the University where I got my Computational Physics degree in 2006. Instead of FORTRAN70 everyone was using Fortran 90 (using F70-era libraries) and I don't think anyone was doing any assembly language programming as the modern compilers even do autovectorisation.
There had been a Pascal era, but C and especially C++ are still alive and very much current.
Even then, those two sets of languages aren't really comparable. Where it does hold true is how lot of the C and C++ programmers feel about Java and C#.
I didn't mean to imply that C and C++ were from a bygone era. Even Fortran is still used today, (though of course C and C++ are still in very wide use).
I just meant to draw a parallel about those who learned to program after the era of mainframes and terminals, on operating systems like Unix, Windows, and Mac OS but before the Web really became a true platform and how they would feel about web programmers. I included Pascal because it was discussed in the article extensively.
"Nicklaus Wirth, the designer of Pascal, gave a talk once at which he was asked, "How do you pronounce your name?". He replied, "You can either call me by name, pronouncing it 'Veert', or call me by value, 'Worth'.""
This paragraph still holds, and it does so for any quiche-eating,effete value of _____.