Programming can be a very frustrating thing to do at any level.
There are a few things that have kept me going:
Please extend this list - George Peter Staplin.
MSW: In fact I love 500+ pages technical books :)
DKF - It's books that are over a thousand pages that are intimidating. Especially when used on cow-orkers... ;^)
D. McC: Keep it down to about 800 pages, like Eric Foster-Johnson's commendably unintimidating Graphical Applications with Tcl & Tk, and you should be OK.
As for the "cow-orkers": I used to think the fad of omitting properly placed hyphens in words such as "co-workers" was harmless, but no more.
"I've had it with this company! He accused me of orking cows! I've never orked a cow in my life!"
"Oh yeah, tell me about it--you probably sneak out to the Cow Palace and ork cows all night long, or until they come home, whichever comes last!"
"Hey, stop that! Break it up! Somebody call the police, quick!" :o)
[Economic absurdities ...]
The most dangerous moment is when you have a vision and say to yourself, "Hey, I could code that!" The next thing you know, no one has seen you for a week and you've perpetrated yet another Tcl object system. -- WHD
LOL! So true... so true --ro
Perhaps related to this are books like The Nudist on the Late Shift [L1 ] [L2 ].
I seem to remember a book by Robert L. Glass called Hot Dogs and Mixed Nuts: Tales of the Computing Profession, but I cannot find any reference to it. It must have been written in the late 70s.
David S. Cargo ([email protected])
This seems to be the book: Glass, Robert L. 1978. Tales of Computing Folk: Hot Dogs and Mixed Nuts, Computing Trends
but it is out of print.
Keith Vetter I've always liked best the explanation that Fred Brooks gave in the book The Mythical Man-Month on why programmers spend endless hours sitting in front of a small screen.
Why is programming fun? What delights may its practitioner expect as his reward?
First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.
Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's fist clay pencil holder "for Daddy's office."
Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.
Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.
Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.
Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.
Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.
DKF - I like that quote very much indeed.
Borrowing a major concept from Peter Naur's "Programming as Theory Building" (Peter is the N in BNF): Programming isn't about creating the text of a program any more than science is about creating the text of a report. Much as science is about building theories about the universe around us, programming is about building theories about what's supposed to happen in the computer.
LV When you reach the point of learning to find out what a user/requestor really wants, rather than what they say they want, and move to fulfill that, you reach a new milestone in developing programs as well.
Oh - and someone - I forget who right now, in a teleconference on developing and programming, gave these as four keys to a successful team regardless of whether it was of programmers or someone else. Why, they even help the Tcl community.
SYStems I like that quote
We the unwilling, led by the unknowing are doing the impossible for the ungrateful. We've done so much for so long with so little we are now capable of doing anything with nothing.
and for some reason most people would agree that it's pretty relevant to the practice of software systems development
IL [L3 ] is a great summary for the Unix Programming Philosophy. It consoles me greatly at this point in my career. There is a better way!
SYStems I have to disagree with Pike's Rule No 5
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. (See Brooks p. 102.)
A program is collection of Inputs, processes, ouputs
Input = Data, process= Algorithm, Output= Data
A program code complexity, depends on all 3, if you have more complex data types, you can have less complex algorithm, and vice versa, if you have very simple data type you will have very complex algorithm
Taking any point to the extreme will be harmful, complexity should be fairly disptributed on the algorithm and the data, I know you can't target for a 50-50 balance, and maybe Pike is arguing fro 65-35 in favor of data
But my point is, program with complex data types, will have simple algorithm, but ... they will have complex data types, so it will still be hard to understand it's code, i.e. the code that describe the data
I am thinking most people who argue against OOP at actually saying, if you make the data structure too complex, you didn't solve anything
So no don't let your data dominates, both algorithms and data are equally important
Lars H: I suspect you're missing the point, SYStems. Yes, one sometimes has to choose data structures so that they are suitable for a particular algorithm, but much more often the algorithm should be chosen so that it is suitable for the data structures at hand. Data exist not only as input or output, but almost always also throughout the process. Data must often be operated upon by a number of different algorithms to get the job done, and then it is often not reasonable that it should be restructured for every new algorithm that gets invoked.
As a particular example of how data dominates, consider sorting. If the data to sort is stored as a linked list, then one should most likely use mergesort for the task, even if one's pet sorting algorithm happens to be quicksort. (Quicksort is unsuitable because it requires random access to the data.)
For a higher level example, one may consider Linear Programming. If all constraints are explicit, then Karmarkar's algorithm is (AFAIK) the state of the art. If on the other hand constraints are generated dynamically by an oracle (often because the full set of constraints is too large to make explicit), then the ellipsoid method can be superior.
So, indeed data dominates. There is a certain feedback in that an unsuitable choice of data structure can make some operation very expensive and therefore call for a different data structure, but an experienced programmer generally discovers this before anything has been coded and can revise the data structure accordingly. Once a data structure has been settled upon, coding may commence. The cost of changing algorithm in the coding phase is generally small compared to the cost of changing data structure; even economically data dominates.
Stu (2005/12/29)
Jonny looks around, confused, his train of thought disrupted. He
collects himself, and stares at the teacher with a steady eye. "I want
to code demos," he says, his words becoming stronger and more confidant
as he speaks. "I want to write something that will change people's
perception of reality. I want them to walk away from the computer dazed,
unsure of their footing and eyesight. I want to write something that
will reach out of the screen and grab them, making heartbeats and
breathing slow to almost a halt. I want to write something that, when it
is finished, they are reluctant to leave, knowing that nothing they
experience that day will be quite as real, as insightful, as good. I
want to write demos."
Silence. The class and the teacher stare at Jonny, stunned. It
is the teachers turn to be confused. Jonny blushes, feeling that
something more is required. "Either that or I want to be a fireman."
- Grant Smith,
14:32,
11/21/93It seems like the field of programming becomes less and less an area of passion about programming and more and more a method of obtaining a paycheck.
uniquename 2013aug17 - I believe it has been said that it takes about 10,000 hours to get good at anything --- sports, music, etc. In mid-2013, after about 15+ years of Tcl-Tk programming at an average of probably less than 2 hours per day over those years, I am finally near that 10,000 hour level. It feels good. I can now do a lot of good stuff. But I still feel like I know no more than about 3% of what there is to know about Tcl-Tk.