Selected programming quotes

1. We toast the Lisp programmer who pens his thoughts within nests of parentheses.

2. I think it is inevitable that people program poorly. Training will not substantially help matters. We have to learn to live with it.

3. One man's constant is another man's variable.

4. Beware of bugs in the above code; I have only proved it correct, not tried it.

5. The psychological profiling [of a programmer] is mostly the ability to shift levels of abstraction, from low level to high level. To see something in the small and to see something in the large.

6. The most important thing in the programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language.

7. To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge.

8. You're on CNN. The show that leads into me is puppets making crank phone calls. What is wrong with you?

9. Perl programming is an *empirical* science!

10. Though I'll admit readability suffers slightly...

11. What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?

12. Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in.

13. Any false value is gonna be fairly boring in Perl, mathematicians notwithstanding.

14. Perl has a long tradition of working around compilers.

15. A 'goto' in Perl falls into the category of hard things that should be possible, not easy things that should be easy.

16. The choice of approaches could be made the responsibility of the programmer.

17. But the possibility of abuse may be a good reason for leaving capabilities out of other computer languages, it's not a good reason for leaving capabilities out of Perl.

18. Well, hey, let's just make everything into a closure, and then we'll have our general garbage collector, installed by 'use less memory'.

19. Almost nothing in Perl serves a single purpose.

20. Perl should remain fast and intuitive (to the extent that it is :-)

21. I'm reminded of the day my daughter came in, looked over my shoulder at some Perl 4 code, and said, 'What is that, swearing?

22. There's often more than one correct thing. There's often more than one right thing. There's often more than one obvious thing.

23. I'd make people say 'use Fork;' if I thought I could get away with it.

24. The court finds everyone to be in contempt (including himself :-), and orders everyone sentenced to five years hard labor. (Working on Perl, of course.)

25. I note that the Python folks still think they like JPython. I wonder how long that will last?

26. Accidental stacks considered harmful.

27. And in the limiting case where the optimizer is completely broken because it's not implemented yet, we get to work around that too. Optionally...

28. Even if you aren't in doubt, consider the mental welfare of the person who has to maintain the code after you, and who will probably put parens in the wrong place.

29. If you want your program to be readable, consider supplying the argument.

30. Perl is designed to give you several ways to do anything, so consider picking the most readable one.

31. The autodecrement is not magical.

32. Now, I'm not the only language designer with irrationalities. You can think of some languages to go with some of these things.

33. The three chief virtues of a programmer are: Laziness, Impatience and Hubris.

34. The problem with being consistent is that there are lots of ways to be consistent, and they're all inconsistent with each other.

35. Many computer scientists have fallen into the trap of trying to define languages like George Orwell's Newspeak, in which it is impossible to think bad thoughts. What they end up doing is killing the creativity of programming.

36. Talk is cheap. Show me the code.

37. I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

38. Given enough eyeballs, all bugs are shallow.

39. The 1973 Labour Conference will have before it the most radical programme the Party has prepared since 1945.

40. Although the Perl Slogan is There's More Than One Way to Do It, I hesitate to make 10 ways to do something. :-)

41. > (It's sorta like sed, but not. It's sorta like awk, but not. etc.) Guilty as charged. Perl is happily ugly, and happily derivative.

42. It was _such_ a relief to program in user mode for a change. Not having to care about the small stuff is wonderful.

43. A programming language is for thinking of programs, not for expressing programs you've already thought of.

44. ...this does not mean that some of us should not want, in a rather dispassionate sort of way, to put a bullet through csh's head.

45. Applicants must also have extensive knowledge of Unix, although they should have sufficiently good programming taste to not consider this an achievement

46. I had a running compiler and nobody would touch it. [:] they carefully told me, computers could only do arithmetic; they could not do programs.

47. I simultaneously believe that languages are wonderful and awful. You have to hold both of those. Ugly things can be beautiful. And beautiful can get ugly very fast. You know, take Lisp. You know, it's the most beautiful language in the world. At least up until Haskell came along. (laughter) But, you know, every program in Lisp is just ugly. I don't figure how that works.

48. Premature optimization is the root of all evil (or at least most of it) in programming.

49. On COBOL: 'But Grace, then anyone will be able to write programs!'

50. Turtle Geometry: The Computer as a Medium for Exploring Mathematics (1981)

51. Logo for the Macintosh: An Introduction through Object Logo (1992)

52. I dunno, I dream in Perl sometimes...

53. If you want to program in C, program in C. It's a nice language. I use it occasionally... :-)

54. There are probably better ways to do that, but it would make the parser more complex. I do, occasionally, struggle feebly against complexity... :-)

55. Besides, it's good to force C programmers to use the toolbox occasionally. :-)

56. If I allowed 'next $label' then I'd also have to allow 'goto $label', and I don't think you really want that... :-)

57. In general, if you think something isn't in Perl, try it out, because it usually is. :-)

58. last|perl -pe '$_ x=/(..:..)...(.*)/&&$1ge$1&&$1lt$2' That's gonna be tough for Randal to beat... :-)

59. Perl itself is usually pretty good about telling you what you shouldn't do. :-)

60. There are many times when you want it to ignore the rest of the string just like atof() does. Oddly enough, Perl calls atof(). How convenient. :-)

61. Well, enough clowning around. Perl is, in intent, a cleaned up and summarized version of that wonderful semi-natural language known as 'Unix'.

62. They can always run stderr through uniq. :-)

63. Of course, I reserve the right to make wholly stupid changes to Perl if I think they improve the language. :-)

64. I think $[ is more like a coelacanth than a mastadon.

65. That could certainly be done, but I don't want to fall into the Forth trap, where every running Forth implementation is really a different language.

66. Randal can write one-liners again. Everyone is happy, and peace spreads over the whole Earth.

67. P.S. Perl's master plan (or what passes for one) is to take over the world like English did. Er, *as* English did...

68. I think you didn't get a reply because you used the terms 'correct' and 'proper', neither of which has much meaning in Perl culture. :-)

69. True, it returns ' ' for false, but ' ' is an even more interesting number than 0.

70. Of course, this being Perl, we could always take both approaches. :-)

71. Well, that's more-or-less what I was saying, though obviously addition is a little more cosmic than the bitwise operators.

72. Magically turning people's old scalar contexts into list contexts is a recipe for several kinds of disaster.

73. I surely do hope that's a syntax error.

74. Anyway, my money is still on use strict vars . . .

75. Just don't make the '9' format pack/unpack numbers... :-)

76. That gets us out of deciding how to spell Reg[eE]xp?|RE . . . Of course, then we have to decide what ref $re returns... :-)

77. 'Course, that doesn't work when 'a' contains parentheses.

78. (To the extent that anyone but a Prolog programmer can understand X totally. (And to the extent that a Prolog programmer can understand 'cut'. :-))

79. The code also assumes that it's difficult to misspell 'a' or 'b'. :-)

80. Boss: You forgot to assign the result of your map! Hacker: Dang, I'm always forgetting my assignations... Boss: And what's that 'goto' doing there?!? Hacker: Er, I guess my finger slipped when I was typing 'getservbyport'... Boss: Ah well, accidents will happen. Maybe we should have picked APL.

81. And other operators aren't so special syntactically, but weird in other ways, like 'scalar', and 'goto'.

82. Perl will always provide the null.

83. Just put in another goto, and then it'll be readable. :-)

84. : I could understand principles of Perl source in 2-3 days [. . .] Gee, it took me about eleven years. :-)

85. Perl did not get where it is by ignoring psychological factors.

86. If this were Ada, we'd simply doc it as 'erroneous'.

87. OOPS! You naughty creature! You didn't run Configure with sh! I will attempt to remedy the situation by running sh for you...

88. Does the same as the system call of that name. If you don't know what it does, don't worry about it.

89. Remember though that THERE IS NO GENERAL RULE FOR CONVERTING A LIST INTO A SCALAR.

90. If there's a particular problem that Perl is trying to solve, it's the basic fact that all programming languages suck. Sort of the concept of original sin, applied to programming languages.

91. There are a lotta computer languages out there doing drugs.

92. Q. Why is this so clumsy? A. The trick is to use Perl's strengths rather than its weaknesses.

93. I already have too much problem with people thinking the efficiency of a perl construct is related to its length. On the other hand, I'm perfectly capable of changing my mind next week... :-)

94. I might be able to shoehorn a reference count in on top of the numeric value by disallowing multiple references on scalars with a numeric value, but it wouldn't be as clean. I do occasionally worry about that.

95. Interestingly enough, since subroutine declarations can come anywhere, you wouldn't have to put BEGIN {} at the beginning, nor END {} at the end. Interesting, no? I wonder if Henry would like it. :-)

96. > This made me wonder, suddenly: can telnet be written in perl? Of course it can be written in Perl. Now if you'd said nroff, that would be more challenging...

97. I knew I'd hate COBOL the moment I saw they'd used 'perform' instead of 'do'.

98. Do you pine for the days when men were men and wrote their own device drivers?

99. If you try to solve a hard problem, the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one.

100. I've seen occasional articles about how to manage programmers. Really there should be two articles: one about what to do if you are yourself a programmer, and one about what to do if you're not. And the second could probably be condensed into two words: give up.