Programming quotes(ronaldsvilcins.com)
ronaldsvilcins.com
Programming quotes
https://www.ronaldsvilcins.com/2020/12/10/programming-quotes/
58 comments
That's why PHB managers want bums in seats.
And the more the merrier, for their perceived status, too. As a consultant, I've literally come across project managers, at least in India, who measure their "prestige" by the number of devs "under" them.
And the more the merrier, for their perceived status, too. As a consultant, I've literally come across project managers, at least in India, who measure their "prestige" by the number of devs "under" them.
Oh this what I've been trying to explain my wife for years! And every time she rolls her eyes probably thinking that I'm slacking...
I'll show it to her and see if it helps
I'll show it to her and see if it helps
"Should array indexes begin at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration"
-- Stan Kelly-Bootle
-- Stan Kelly-Bootle
There is Compromise, a Python library supporting this
https://github.com/travisjungroth/Compromise
Introduced in this short 2016 talk https://youtu.be/yC9m2GInXqU?t=337
>>> l = HalfIndexList('abcde')
>>> l[0.5]
'a'
https://github.com/travisjungroth/Compromise
Introduced in this short 2016 talk https://youtu.be/yC9m2GInXqU?t=337
He's a fascinating guy too. I learned on hn recently he lived a parallel life as a mildly popular musician and football (soccer) manager.
> Java is to JavaScript what Car is to Carpet.
It's goes deeper than it should Cars usually ship with small patches of carpet. From Java 8 until 15, Java shipped with a JS interpreter. It was actually the only JSON parser I know of that shipped with Java.
It's goes deeper than it should Cars usually ship with small patches of carpet. From Java 8 until 15, Java shipped with a JS interpreter. It was actually the only JSON parser I know of that shipped with Java.
I've been running a Twitter account hoovering up and regurgitating such things for the past ten years as well: https://twitter.com/codewisdom
> "Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code." - Christopher Thompson
Liked your feed. Followed.
Liked your feed. Followed.
There was an account posting SICP quotes as well.
https://twitter.com/SICPQuotes
"Measuring programming progress by lines of code is like measuring aircraft building progress by weight." - yup!
Reminds me of another quote:
"Software ended up saving the Defense Aerospace industry. It was the only way of adding cost that didn't also add weight."
"Software ended up saving the Defense Aerospace industry. It was the only way of adding cost that didn't also add weight."
I don't see how this misses anything, weight as progress criteria isn't wrong because of assembly time but due to the effect of added weight
This misses something, though. The problem with lines of code isn't that it discounts assembly time, it's that it rewards complexity.
The point of the analogy is that both metrics are, fundamentally, useless. A 787 (unloaded) weighs about 175 tons. Does this mean that putting 175 tons of material at the end of the assembly line corresponds to the complete and proper assembly of a 787? Nope. There are other far more useful measures: does it look right, is it fitted correctly, does it pass QA (testing), is it composed of the correct pieces or just things that resemble them?
In software, LOC is, itself, a useless measure for progress for the same reason: It indicates nothing of value. I have inherited programs in the 10s and 100s of thousands of lines of code that I was able to reduce to less than 20% of their initial size without loss of capability, and generally with improved performance, stability, and maintainability. The right measures are around functionality and the other meaningful qualities (stability, security, testability, etc.).
In software, LOC is, itself, a useless measure for progress for the same reason: It indicates nothing of value. I have inherited programs in the 10s and 100s of thousands of lines of code that I was able to reduce to less than 20% of their initial size without loss of capability, and generally with improved performance, stability, and maintainability. The right measures are around functionality and the other meaningful qualities (stability, security, testability, etc.).
My interoperation was always that both lines of code and airplane weight was harmful to the end product.
I'm stealing this one.
I thought the Kernighan quote went more along the lines of "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
Anyone have a source on this one way or the other?
Anyone have a source on this one way or the other?
It seems yours is the more widely-known phrasing of it, which however was not the original. According to [1], it comes from "The Elements of Programming Style", where it was worded the way it's quoted in the article.
[1]: <https://github.com/dwmkerr/hacker-laws#kernighans-law>
[1]: <https://github.com/dwmkerr/hacker-laws#kernighans-law>
Hmm, I haven't read that book this millennium, but I had thought I first encountered the quote in The Practice of Programming. Which, I mean, I also haven't read this millennium, but when I did read it it was after The Elements of Programming Style. I guess I should check...
It turns out that it is in The Elements of Programming Style, on the second page of Chapter 2, "Expression", in the second edition:
Suppose that you were trying to teach a novice programmer how to count the blanks in a string. How would you do it? Surely not by this elegant but mystifying method [omitted] — instead you would say “Look at each character, and if it's a blank, count it.” Or, in PL/I,
I think this is, if anything, truer now than it was in 01978 when the book was published, even if not many of us have to deal with PL/I nowadays—thanks, in significant part, to Kernighan's efforts. And it's probably thanks in part to reading this book that today I would more likely write that as
Being too clever is what almost always trips me up in Forth. It's not so much the stack-effect bugs or the type errors themselves, although of course those require more care to avoid than in C; it's the constant temptation to bum the code down to something smaller and simpler by, for example, keeping more crap on the stack.
I think I did manage to use Forth effectively and avoid being so clever in, for example, https://dercuano.github.io/notes/forth-assembling.html#addto....
It turns out that it is in The Elements of Programming Style, on the second page of Chapter 2, "Expression", in the second edition:
Suppose that you were trying to teach a novice programmer how to count the blanks in a string. How would you do it? Surely not by this elegant but mystifying method [omitted] — instead you would say “Look at each character, and if it's a blank, count it.” Or, in PL/I,
DECLARE TEXT CHARACTER(200) VARYING;
GET LIST (TEXT);
N = 0;
DO I = 1 TO LENGTH(TEXT);
IF SUBSTR(TEXT, I, 1) = ’ ’ THEN
N = N + 1;
END;
PUT LIST (N);
I think this is, if anything, truer now than it was in 01978 when the book was published, even if not many of us have to deal with PL/I nowadays—thanks, in significant part, to Kernighan's efforts. And it's probably thanks in part to reading this book that today I would more likely write that as
sum(1 if c == ' ' else 0 for c in text)
sum(1 for c in text if c == ' ')
(loop for c across text if (eq c #\space) sum 1)
sum(c == ' ' for c in text)
Being too clever is what almost always trips me up in Forth. It's not so much the stack-effect bugs or the type errors themselves, although of course those require more care to avoid than in C; it's the constant temptation to bum the code down to something smaller and simpler by, for example, keeping more crap on the stack.
I think I did manage to use Forth effectively and avoid being so clever in, for example, https://dercuano.github.io/notes/forth-assembling.html#addto....
Ronalds Vilciņš did his homework. He also gives Stroustrup's original quote.
Kernighan probably never said the version with "by definition"; he tends to be pretty careful not to misuse logical terminology in order to add rhetorical punch to a point.
writing code as cleverly as possible doesn't imply it's at the developers limit of understanding--just that the code cannot be expressed more cleverly.
Asking the question, how will you ever debug it, causes the developer pause and hopefully realize there will be a learning curve when maintenance dues come.
I guess I disagree with the conclusion of your flavor of the quote.
Asking the question, how will you ever debug it, causes the developer pause and hopefully realize there will be a learning curve when maintenance dues come.
I guess I disagree with the conclusion of your flavor of the quote.
Clicked the link expecting to see something by Larry Wall, was not disappointed.
One of the things I loved about learning Perl was his many quips of humor and wisdom sprinkled throughout the “camel” books, particularly The Perl Cookbook, which is still on my bookshelf to this day.
One of the things I loved about learning Perl was his many quips of humor and wisdom sprinkled throughout the “camel” books, particularly The Perl Cookbook, which is still on my bookshelf to this day.
Same opinion here.
His humor was unbeatable in quality, quantity (sometimes multiple jokes per page) and sometimes even subtlety, not to mention unexpectedness (which is a key criterion of a joke being funny).
Sample: From a Perl FAQ, IIRC (there are many):
Q: Is Perl (ANSI) certified? Larry: A: I'll be certified before Perl is!
His humor was unbeatable in quality, quantity (sometimes multiple jokes per page) and sometimes even subtlety, not to mention unexpectedness (which is a key criterion of a joke being funny).
Sample: From a Perl FAQ, IIRC (there are many):
Q: Is Perl (ANSI) certified? Larry: A: I'll be certified before Perl is!
" Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.
Larry Wall"
You may be interested in the context, which is excerpted in Wiki: http://wiki.c2.com/?LazinessImpatienceHubris=
Laziness
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. (p.609)
Impatience
The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. (p.608)
Hubris
Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607)
⁂
So, if that describes you, you should be very proud indeed.
Laziness
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. (p.609)
Impatience
The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. (p.608)
Hubris
Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607)
⁂
So, if that describes you, you should be very proud indeed.
I know it's not in keeping with the definition provided, but I like to interpret hubris in that context as "Believing that they are capable of writing software that is compatible with the second virtue, and that they can write it in a manner compatible with the first."
Don't mock everything, by mocking everything, you are testing... nothing.
I love this. I can't count how many cases I've come across where at the end of the day, you assert that 1=1 because all that is happening is mocks being passed around and you assert that your mock is your mock.
Mocking everything is mocking testing?
See also quotes.cat-v.org: http://quotes.cat-v.org/programming/
And the obligatory Alan Perlis epigrams (usually one makes it on a list like this!): http://www.cs.yale.edu/homes/perlis-alan/quotes.html.
The great thing about computers is they do exactly what you tell them to do.
The awful thing about computers is they do exactly what you tell them to do.
Related:
twitter.com/iamdevloper (sometimes hilarious)
twitter.com/devops_borat (dead, but lots of good ones)
twitter.com/iamdevloper (sometimes hilarious)
twitter.com/devops_borat (dead, but lots of good ones)
This looks like it would be heaven for my software engineering professor. I swear he had smart Computer Science quotes on every second slide of his presentations.
[deleted]
Love this. That PHP one is a little unnecessarily harsh though.
Math is hard. Programming is hard.
I clicked on this thinking I'd find tips on programming quotes.
[deleted]
It would be an improvement to curate more diversity in this pantheon.
Do you have any entry proposal(s) or you are just complaining without a solution?
edit: typo
edit: typo
"They told me computers could only do arithmetic" is attributed to Grace Hopper.
I'm not the original commenter, but I have some:
"To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge." – Grace Hopper
"Beyond basic mathematical aptitude, the difference between good programmers and great programmers is verbal ability." – Marissa Mayer
"I’ve always objected to doing anything over again if I had already done it once." – Grace Hopper
"The best icons are more like traffic signs than graphic illustrations." – Susan Kare
"You haven't mastered a tool until you understand when it should not be used." – Kelsey Hightower
"Some problems solve themselves if you are patient enough." – Jaana Dogan
"If too many users are wrong, it's probably your fault [..] If a bunch of people trip over the same thing, maybe it's not them. Maybe it's your product, or maybe it's just you." – Rachel Kroll
“Falling in love with code means falling in love with problem solving and being a part of a forever ongoing conversation.” - Kathryn Barrett
"The best programs are the ones written when the programmer is supposed to be working on something else." - Melinda Varian
"Writing software as if we are the only person that ever has to comprehend it is one of the biggest mistakes and false assumptions that can be made." - Karolina Szczur
"Sometimes it's better to leave something alone, to pause, and that's very true of programming." - Joyce Wheeler
"The purpose of software engineering is to control complexity, not to create it." - Dr. Pamela Zave
"To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge." – Grace Hopper
"Beyond basic mathematical aptitude, the difference between good programmers and great programmers is verbal ability." – Marissa Mayer
"I’ve always objected to doing anything over again if I had already done it once." – Grace Hopper
"The best icons are more like traffic signs than graphic illustrations." – Susan Kare
"You haven't mastered a tool until you understand when it should not be used." – Kelsey Hightower
"Some problems solve themselves if you are patient enough." – Jaana Dogan
"If too many users are wrong, it's probably your fault [..] If a bunch of people trip over the same thing, maybe it's not them. Maybe it's your product, or maybe it's just you." – Rachel Kroll
“Falling in love with code means falling in love with problem solving and being a part of a forever ongoing conversation.” - Kathryn Barrett
"The best programs are the ones written when the programmer is supposed to be working on something else." - Melinda Varian
"Writing software as if we are the only person that ever has to comprehend it is one of the biggest mistakes and false assumptions that can be made." - Karolina Szczur
"Sometimes it's better to leave something alone, to pause, and that's very true of programming." - Joyce Wheeler
"The purpose of software engineering is to control complexity, not to create it." - Dr. Pamela Zave
>"The purpose of software engineering is to control complexity, not to create it." - Dr. Pamela Zave
That's a really good advice
That's a really good advice
http://www.pamelazave.com/
Her homepage and a lot of writings. Very good resource if you've not been there before.
Her homepage and a lot of writings. Very good resource if you've not been there before.
what does this even mean?
"Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they’re sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head."
-- Charles M Strauss