The Aphorisms

A pre-condition for the William Annis quote above...

Before fixing a problem reported by a user, make sure that the problem is in the code and not in the user's chair.

PEBKAC errors are best debugged via Blunt Force Trauma.

Jack

Rick Cook, actually (not Rich). In his book "Wizard's Bane", I believe. Fun book, that. The series got rather silly, but it was still fun.

Just an assortment of quotes:

• With enough eyeballs, all bugs are shallow.
      -- Linus Torvalds
• Define "doesn't work". That phrase is the most unhelpful thing you can ever say about a piece of code. What does it do that you didn't expect, or what doesn't it do that you expected?.
      -- Jeff 'japhy' Pinyan
• When the code and the comments disagree, both are probably wrong.
      -- Norman Schryer
• Stuff is only hard when you dont know how to do it. It is one of the great ironies of life. It is always hard to apreciate your own knowledge, well because you know it.
      -- zigster
• The only thing that overrides a regexes natural greediness is it's desire to achieve a match. If it can, it will, and it can, so it does:).
      -- BrowserUk
• Says Chris2323: I am not a great fan of modules because I feel it is cheating when you are a beginner..
  
  Yeah, just like when you're first learning to build furniture, it's cheating to use a hammer. Everyone should spend some time pounding nails with their forehead for a while before they graduate to complicated stuff like hammers.
      -- Dominus
• For every complex problem, there is always a simple solution - that is wrong.
      -- H.L. Mencken
• Computer science is no more about computers than astronomy is about telescopes.
      -- Edsger W. Dijkstra
• You said it didn't work, but you didn't say what it would have done if it *had* worked.
      -- Dominus
• Now is the time in our program where you look at the manual..
      -- Dominus

Just because you can, doesn't mean you should.

This is a nod to the concept that TIMTOWTDI is not always a good idea. Sometimes, a person asks a question on Perlmonks, and some people post the most ridiculous answers "because no-one else has yet done it this way". Sometimes, there are sound reasons why that is the case. (update: oops, I just realised I wasn't supposed to explain this. Oh well, I still think the meaning is obvious).

In other words:

Strive for clarity

Actually i think those TIMTOWTDI posts are great. They remind me of the way children will play with words and vocabulary to the say things that adults understand but dont quite follow the rules. I think they represent part of the learning process of exploring the boundaries and interactions of the language and as such are part of the pathway to better programming. Realizing that there twenty ways to do something, of which 17 are fairly silly 2 are ok but cryptic and 1 is succinct, expressive and to the point requires knowing what all those ways are.

I agree with you on clarity, but i think i would add elegance and succint. Ive seem code that is perfectly clear but totally annoying because of its oververboseness and poor structure.

---
demerphq

I was going to write more, but I'll save that for a later release of this post.

Your wish is my command, sahib! I just added the section with the fine print about how I intended to compile the submissions. :>

I also updated the list with the submissions to date.

Languages you don't know are hard

Corollary: Failure to learn a language on your part does not imply suckage on the language's part

Object oriented programming is a lot like sex:

• Everyone agrees its a great thing
• Everyone thinks everyone else is doing it all the time.
• In reality, very few are doing it that often
• And, when they do it, at least one of the parties involved is less than satisfied with the results.

A good programmer looks both ways before crossing a one-way street
--Ovid

/J

A better programmer also looks up :D

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

"From beneath you, it devours."

Writing node text in your signature produces apparently empty posts for some people.

Is that a perlmonks aphorism? {grin}

"Write your nodes in the node box so that people can see them."

"Write your nodes in the node box or chromatic will pee on you."

• Have you ever stopped to consider that what is crashing your Perl is sitting between the keyboard and chair?
  Sherm Pendley in clpmisc, "Re: Perl IDE" (edited)
• No one can ever predict all of the possible error conditions, of course; as soon as we write idiot-proof code, along comes a better idiot. But it's still worth making the attempt.
  Sherm Pendley in clpmisc (edited)
• "a few lines of code" and "prevent it from being insecure" should not appear in the same sentence.
  Tad McClellan in clpmisc, "Re: free source for bbs"
• It's also amazing how much use Larry's getting out of his colon. (The character, obviously).
  "The Perl 6 Summarizer".
• And: Every book which has a title that promises you to learn something in x weeks, day or even hours is lying.
  Tore Aursand in clpmisc, "Re: wow...jackpot."
• Nevertheless, any resemblance between the Perl design process and bouncing down stairs is entirely coincidental. (I hope.)
  Larry Wall in p6l
• Larry's First Law of Language Redesign: Everyone wants the colon.
  Larry Wall, "Synopsis 1 draft 1"
• My assertion that we can do better with computer languages is a persistent belief and fond hope, but you'll note I don't actually claim to be either rational or right. Except when it's convenient. :-)
  Larry Wall in p6l, "Re: Containers vs Objects."
• Nope. I used to think RPN was completely unnatural. Then I started learning Japanese, and now I not so sure am. :-)
  Larry Wall in p6l.
• Of course *most* users aren't going to do that. *Most* users aren't trying to hack your site! You don't program securely for *most* users - you program securely for the few users who *are* trying to be malevolent.
  Paul Lalli in clpmisc, "Re: free source authentication script"
• He "steals". You "reuse". I "enhance the value of".
  "Alex" on comp.lang.perl.misc (slightly edited)

I was going to add this one:

Programming is like sex: it's fun and can create incredible things, but you need to use protection or you'll catch bugs.

But I decided that was cute and maybe amusing, but not really all that deep.

Whitehawke's contribution made me come up with this one:

Programming is like sex. Sure, it may give some practical results, but that's not why we do it.

(Based on a quote by Richard Feynman, where s/Programming/Physics/.)

That reminds me of my old sig, from the Computer Contradictionary (which I still haven't read, except from the few quotes available on the net):

downtime n. The period during which a system is error-free and immune from user input.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

I've heard basically the same one, but with a twist. I'm not sure who to attribute it to, but I think it was one of the various "Klingon Programmer" lists around the web.

The program isn't finished until the last user is dead.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

• RTFM.
• First rule of optimization: don't. Second rule of optimization: for experts only.
• Patches welcome!
• Go To Considered Harmful. -- E. W. Dijkstra (Well, to be pedantic, it was actually C. Hoare who came up with the title).
• "... in constant time". -- D. Conway.
• Beware, I've only proven the correctness of the program. -- D. E. Knuth.
• Be nice. -- L. Wall.
• You can't just make shit up and expect the computer to know what you mean, Retardo! -- M. J. Dominus.
• Premature optimization is the root of all evil. -- D. E. Knuth?
• What happened when you tried? -- c.l.p.m

I also like "It's just software" along those lines.

Another aphorism I've toyed with over the past week or two is something like Software that's difficult to maintain is a failure of your development process, not your maintainers nor your language. That's barely pithy though.

Well, to match the cliché office sign: A failure on the developer's part does^H^H^H^H^should not constitute a crisis on the maintainer's part.

It's not a bug, it's a feature!

I remember seeing an umpteenth Xerox generation of the Jargon Dictionary, which had an entry for "feecher" (as compared to "feature").

I seem to have thrown that out at some point, thinking the online version had it all covered. But now I can only find one link :(

Update: That link is no more, I found a PDF here, search for "feecher")

[feecher, feechur]
n. An unforeseen, arbitrary, or capricious attribute, which, once documented, is spelled feature (q.v.).

-QM
--
Quantum Mechanics: The dreams stuff is made of

I can't find that in the online Jargon file, but did find: "The "One-Question Geek Test". You say to someone "I saw a Volkswagen Beetle today with a vanity license plate that read FEATURE". If he/she laughs, he/she is a geek.
(Not Perl, but aphorism related...)

• "Always write less code (unless this would be less readable)"
• "If you are doing it three times you are probably doing it wrong"

If automobiles had advanced at the same pace software development has, today's cars would cost $1.98, get 1000 miles to the gallon, emit zero pollution, and occasionally explode for no reason, killing all the occupants.

All bug-free programs are obsolete.

Having a large data processing staff hovering around any computer is as profound a sign of overt design failure as is having several mechanics ride around with you in your car.

It's all about the *data*.

To iterate is human; to recurse, divine.

Programs must provide correct results in spite of the best efforts of the user.

Always solve the hardest part of the problem first. If you can't do that, the rest of the program is a waste of time.

If you can't explain the operation of your program to managment, you are probably on the right track.

Question: What are C, C++, and C#? Answer: They were grades.

To reiterate is human; to recurse, divine.

Because, obviously, humans may repeat themselves but never when cursing.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

- Martin Fowler, Refactoring: Improving the Design of Existing Code

Brevity == Clarity.

A shortcut makes for a long journey.

Is that sort of like "Never use a large word when a diminutive word will suffice"?