The Codeless Code
July 3, 2012 7:46 AM Subscribe
The Codeless Code. An illustrated collection of (sometimes violent) fables,
concerning the Art and Philosophy of software development
via reddit
via reddit
Also, if someone could explain this one I'd be grateful:
posted by Deathalicious at 8:07 AM on July 3, 2012
That evening four students came to his door, seeking help with a truculent program. Its log files were overflowing with ArrayIndexOutOfBounds exceptions which the students insisted were impossible: the array in question was declared to hold a thousand elements, and the index — a one-byte integer — could never exceed 255 by definition.Under what circumstances could an out of bound error occur in this fashion?
posted by Deathalicious at 8:07 AM on July 3, 2012
Under what circumstances could an out of bound error occur in this fashion?
Index is signed byte?
posted by Western Infidels at 8:08 AM on July 3, 2012 [2 favorites]
Index is signed byte?
posted by Western Infidels at 8:08 AM on July 3, 2012 [2 favorites]
An *unsigned* int goes from -127 to +127.
posted by originalname37 at 8:09 AM on July 3, 2012 [1 favorite]
posted by originalname37 at 8:09 AM on July 3, 2012 [1 favorite]
Of course I mean, an *unsigned* int goes to 255, the other kind from negative to positive.
posted by originalname37 at 8:10 AM on July 3, 2012 [3 favorites]
posted by originalname37 at 8:10 AM on July 3, 2012 [3 favorites]
An *unsigned* int goes from -127 to +127.
What?
posted by kmz at 8:10 AM on July 3, 2012 [3 favorites]
What?
posted by kmz at 8:10 AM on July 3, 2012 [3 favorites]
Only read one but it is exactly right. Only some of the holes should be in the monk's head to let out a little of the ignorance.
posted by DU at 8:11 AM on July 3, 2012
posted by DU at 8:11 AM on July 3, 2012
I think the lesson is you shouldn't count on the size of a variable to protect the value it can expand to.
Does Java have the ability to define the bit width of an integer?
Just because you think its a broom doesn't mean it can't be used to beat you.
posted by ibfrog at 8:18 AM on July 3, 2012
Does Java have the ability to define the bit width of an integer?
Just because you think its a broom doesn't mean it can't be used to beat you.
posted by ibfrog at 8:18 AM on July 3, 2012
I really, really like this. On one hand, I thank you for posting it. On the other, I shake my fist weakly in your direction, as I had things I'd planned to do this morning.
posted by Mooski at 8:19 AM on July 3, 2012
posted by Mooski at 8:19 AM on July 3, 2012
omg
Yeah, I have only gotten to that one but I had to stop to share it here. Fantastic.
I'm reading these slowly because they were written by a Java coder.
posted by yerfatma at 8:20 AM on July 3, 2012 [5 favorites]
Yeah, I have only gotten to that one but I had to stop to share it here. Fantastic.
I'm reading these slowly because they were written by a Java coder.
posted by yerfatma at 8:20 AM on July 3, 2012 [5 favorites]
I think the lesson is you shouldn't count on the size of a variable to protect the value it can expand to.
I think it's actually a signed/unsigned problem. The first line can't be referring to much else:
posted by BungaDunga at 8:23 AM on July 3, 2012 [3 favorites]
I think it's actually a signed/unsigned problem. The first line can't be referring to much else:
Java master Bawan said: “The beggar in the marketplace owns nothing but empty cups. Fill all but one with tea and he will praise you; yet spill a drop into the last and he must instantly die of thirst. Explain.”011111... is positive, 100000... is negative.
posted by BungaDunga at 8:23 AM on July 3, 2012 [3 favorites]
I know, kmz. Fyi, I wasn't trying to correct the previous answer. I was just trying to answer the question but wrote "unsigned" when I meant "signed" and then a correct answer snuck just in front of me compounding my shame. I wish I knew how to delete my own comments.
posted by originalname37 at 8:24 AM on July 3, 2012
posted by originalname37 at 8:24 AM on July 3, 2012
"Garbage" is bad-ass. I know just who I'm going to send it to...
posted by originalname37 at 8:25 AM on July 3, 2012 [2 favorites]
posted by originalname37 at 8:25 AM on July 3, 2012 [2 favorites]
#13
Too true; one of the down sides of working in the same place for a while is I am consistently humbled by having to view my own code, sometimes years after writing it.
posted by Mooski at 8:32 AM on July 3, 2012 [1 favorite]
Too true; one of the down sides of working in the same place for a while is I am consistently humbled by having to view my own code, sometimes years after writing it.
posted by Mooski at 8:32 AM on July 3, 2012 [1 favorite]
#26 is of a piece with #13. It took me a while to realize new coworkers were unsettled by me saying, "If I ever catch the asshole who wrote this . . . " because they didn't know the code was mine.
posted by yerfatma at 8:38 AM on July 3, 2012 [4 favorites]
posted by yerfatma at 8:38 AM on July 3, 2012 [4 favorites]
I was just asked to make some changes to a system I designed in 1997, and last looked at in 2000 to migrate it from Windows 3.1 to NT. IT has been working flawlessly for 15 years but it is a vast swamp of laboriously hand-coded event handlers and magic numbers and I just had to explain to a salesman that it would be cheaper to rewrite it from scratch with the tools and libraries I've built since then than to try to figure out how it works well enough to safely change it.
posted by localroger at 8:49 AM on July 3, 2012 [3 favorites]
posted by localroger at 8:49 AM on July 3, 2012 [3 favorites]
This is such a common phenomenon that there is a term for it: "Legacy code".
posted by WalkingAround at 8:51 AM on July 3, 2012 [2 favorites]
posted by WalkingAround at 8:51 AM on July 3, 2012 [2 favorites]
These are wonderful. Be sure to read the About page. Empty is my favourite so far.
posted by oulipian at 9:03 AM on July 3, 2012
posted by oulipian at 9:03 AM on July 3, 2012
Do the monks' names mean anything? I suspect so but I haven't been able to say why.
posted by cotterpin at 9:05 AM on July 3, 2012
posted by cotterpin at 9:05 AM on July 3, 2012
What are the three dots for? I haven't been able to suss a meaning out yet.
posted by Earthtopus at 9:13 AM on July 3, 2012
posted by Earthtopus at 9:13 AM on July 3, 2012
Index is signed byte?
Note they're talking to the Java master Bawan.
The byte is a Java primitive datatype, and it is defined as a signed two's complement integer.
NOT A BROOM! NOT A BROOM!
posted by eriko at 9:23 AM on July 3, 2012
Note they're talking to the Java master Bawan.
The byte is a Java primitive datatype, and it is defined as a signed two's complement integer.
NOT A BROOM! NOT A BROOM!
posted by eriko at 9:23 AM on July 3, 2012
The byte is a Java primitive datatype, and it is defined as a signed two's complement integer.
Dammit, didn't finish!
The byte is a Java primitive datatype, and it is defined as a signed two's complement 8-bit integer.
And it's still NOT A BROOM
posted by eriko at 9:25 AM on July 3, 2012
Dammit, didn't finish!
The byte is a Java primitive datatype, and it is defined as a signed two's complement 8-bit integer.
And it's still NOT A BROOM
posted by eriko at 9:25 AM on July 3, 2012
These are delightful. Thanks!
posted by spitefulcrow at 9:30 AM on July 3, 2012
posted by spitefulcrow at 9:30 AM on July 3, 2012
Do the monks' names mean anything? I suspect so but I haven't been able to say why.
Banzen means 'perfection' in Japanese. He appears in 26, 32 and 38. I suspect the other names have meanings in Japanese or some dialects of Chinese but I speak none of those.
posted by axiom at 9:40 AM on July 3, 2012 [1 favorite]
Banzen means 'perfection' in Japanese. He appears in 26, 32 and 38. I suspect the other names have meanings in Japanese or some dialects of Chinese but I speak none of those.
posted by axiom at 9:40 AM on July 3, 2012 [1 favorite]
This should be a book!
posted by lubujackson at 9:48 AM on July 3, 2012 [1 favorite]
posted by lubujackson at 9:48 AM on July 3, 2012 [1 favorite]
This should be a book!
I agree, and I sent Qi an email saying I'd buy many copies if he would print them. I think a hardback about the size of a Moleskine notebook, with one koan per page, would be awesome sauce.
posted by Mooski at 9:55 AM on July 3, 2012
I agree, and I sent Qi an email saying I'd buy many copies if he would print them. I think a hardback about the size of a Moleskine notebook, with one koan per page, would be awesome sauce.
posted by Mooski at 9:55 AM on July 3, 2012
A monk asked Jōshū, "Has an AI program that passeth the Turing Test Buddha-nature or not?" Jōshū answered, "\u7121!".
posted by ubiquity at 10:06 AM on July 3, 2012 [4 favorites]
posted by ubiquity at 10:06 AM on July 3, 2012 [4 favorites]
ubiquity:Indeed. It's a long standing tradition. Still, these are the first I've seen focused on Java.PS: This has been done before.
posted by ob1quixote at 10:14 AM on July 3, 2012 [2 favorites]
I am not a java guy (I just fat-fingered that as gui, hah!) but these are still great.
posted by phearlez at 11:03 AM on July 3, 2012
posted by phearlez at 11:03 AM on July 3, 2012
There are also some Unix-related ones by ESR, but unfortunately they aren't all that good.
posted by whir at 11:54 AM on July 3, 2012
posted by whir at 11:54 AM on July 3, 2012
It's the names of the various clans that I love most about this. "Charitable Temple of the Bristling Yak" is how I shall refer to GNU software from now on.
posted by ook at 12:29 PM on July 3, 2012 [2 favorites]
posted by ook at 12:29 PM on July 3, 2012 [2 favorites]
ibfrog: I think the lesson is you shouldn't count on the size of a variable to protect the value it can expand to.Leave me out of this.
Does Java have the ability to define the bit width of an integer?
Just because you think its a broom doesn't mean it can't be used to beat you.
posted by IAmBroom at 12:41 PM on July 3, 2012 [6 favorites]
Approaching coding as a series of koans is fun but hardly practical. There are always well understood reasons for conventions and rules. If you don't have an understanding of the methods you employ they can have a tendency to bite you on the ass. Not that I haven't made my share of duh mistakes but once you find them they becomes obvious. My nightmares involve race conditions that are hard to reproduce in the lab but inevitably arise in production environments.
posted by pdxpogo at 1:37 PM on July 3, 2012
posted by pdxpogo at 1:37 PM on July 3, 2012
There are always well understood reasons for conventions and rules.
Where do you live and are there homes for sale there?
posted by yerfatma at 1:40 PM on July 3, 2012 [2 favorites]
Where do you live and are there homes for sale there?
posted by yerfatma at 1:40 PM on July 3, 2012 [2 favorites]
pdxpogo approached plinth and said, "my multithreaded task manager is ready for production." Plinth set two mice, a gray one and a white one in adjacent tunnels that converged at the end to a single piece of cheese. The white one always got the cheese. Then Plinth took the tracks outside and started the race again, but held down the white mouse's tail.
posted by plinth at 1:45 PM on July 3, 2012
posted by plinth at 1:45 PM on July 3, 2012
When a novice joins the temple and claims to seek wisdom, they are advised to find Java master Bawan and ask him: “How did wily old Madame Jinyu become Abbess Over All Clans And Concerns?”
Master Bawan will then hit the novice on the backside with a shovel, and instruct them to return the following night and ask again. The following night the answer will be the same, and will conclude with the same order to return, until the novice is enlightened.
posted by Sebmojo at 2:31 PM on July 3, 2012 [1 favorite]
Master Bawan will then hit the novice on the backside with a shovel, and instruct them to return the following night and ask again. The following night the answer will be the same, and will conclude with the same order to return, until the novice is enlightened.
posted by Sebmojo at 2:31 PM on July 3, 2012 [1 favorite]
Drat, someone beat me to posting The Tao of the Programmer.
posted by Canageek at 4:10 PM on July 3, 2012
posted by Canageek at 4:10 PM on July 3, 2012
ook: "It's the names of the various clans that I love most about this. "Charitable Temple of the Bristling Yak" is how I shall refer to GNU software from now on"
But who are the Spider and the Sparrow and the Laughing Monkey and the Elephant's Footprint?
posted by d. z. wang at 5:51 PM on July 3, 2012
But who are the Spider and the Sparrow and the Laughing Monkey and the Elephant's Footprint?
posted by d. z. wang at 5:51 PM on July 3, 2012
When the Java master speaks of elegance, the Lisp disciple raises a single eyebrow. When the Java master concludes, the Lisp disciple lowers the eyebrow and says nothing.
posted by mhoye at 6:51 PM on July 3, 2012 [4 favorites]
posted by mhoye at 6:51 PM on July 3, 2012 [4 favorites]
When the Java master speaks of elegance, the Lisp disciple raises a single eyebrow. When the Java master concludes, the Lisp disciple lowers the eyebrow and says nothing.
When the Java master struggles to correct compile errors, the LISP disciple closes parentheses.
posted by the cydonian at 7:17 PM on July 3, 2012
When the Java master struggles to correct compile errors, the LISP disciple closes parentheses.
posted by the cydonian at 7:17 PM on July 3, 2012
How unfortunate that its not written so that the word Java can easily be replaced.
posted by Twang at 7:19 PM on July 3, 2012
posted by Twang at 7:19 PM on July 3, 2012
Spider are web developers, I believe. And the Elephant's Footprint is working on a huge legacy app.
posted by egypturnash at 7:38 PM on July 3, 2012
posted by egypturnash at 7:38 PM on July 3, 2012
I read the first one and stopped because of all the implied bullshit about TDD. I guess this person doesn't like, or understand, TDD.
The design and illustrations are decent, too bad the content is crap.
posted by dubitable at 5:50 AM on July 4, 2012
The design and illustrations are decent, too bad the content is crap.
posted by dubitable at 5:50 AM on July 4, 2012
Okay, so I kept reading because I'm a sucker. This one about immutability really pissed me off. The author really knows crap about software engineering apparently, but couching these little philosophical statements makes it seem as though this is somehow authoritative knowledge.
Seriously, there are people far smarter and more experienced than this doofus, with actually meaningful stuff to say about software engineering. Try Rich Hickey for example, or Martin Fowler, just to name two.
posted by dubitable at 6:00 AM on July 4, 2012
Seriously, there are people far smarter and more experienced than this doofus, with actually meaningful stuff to say about software engineering. Try Rich Hickey for example, or Martin Fowler, just to name two.
posted by dubitable at 6:00 AM on July 4, 2012
What pissed you off about the immutability one? It seemed pretty innocuous: immutability is useful in some circumstances, but that doesn't mean you should use it all the time. Hard to argue with that.
The test-driven development one, OK, he's opinionated and I dont necessarily agree with all of his opinions. But 'the author knows crap about software engineering?'. Sheesh. Clan of the High Horse needs to watch out for low-hanging branches.
posted by ook at 6:46 AM on July 4, 2012 [1 favorite]
The test-driven development one, OK, he's opinionated and I dont necessarily agree with all of his opinions. But 'the author knows crap about software engineering?'. Sheesh. Clan of the High Horse needs to watch out for low-hanging branches.
posted by ook at 6:46 AM on July 4, 2012 [1 favorite]
Knowing That You Know Nothing
The Java master instructed his young student: "Describe to me how you would write a letter."
The student confidently replied:
"First, obtain a pen.
Second, obtain a piece of paper.
Third, place the paper on a desk.
Finally, use the pen to write the letter."
The master scolded him: "And what would have happened if you did not find any paper? You will have written your message upon the desk!"
The student considered this for a while, and then nodded his head. The master continued: "Now, tell me how you would prepare a bowl of rice."
The student, remembering the master's lesson, began:
"First, obtain some rice.
Second, check that you have some rice.
Third, obtain a pot.
Fourth, check that you have a pot.
Fifth, place the rice in the pot.
Sixth, prepare a fire.
Seventh, check that you have a fire.
Eighth, place the pot on the fire.
Ninth, check that the fire has a pot on it.
Tenth, check that there is rice in the pot on the fire..."
The master waited patiently as this continued. When the student had finished, the master scolded him again: "Fool! You place a pot on a fire, and believe yourself wise for proving that there is a pot on the fire? You wasted your time checking things you already know, and so failed to realize you had forgotten to place water in with the rice."
The student bowed his head, ashamed. The master angrily asked him: "Do you have a stick, that I may beat you with it?"
The student was relieved to say that he did not.
The master replied: "Very well." He walked to the garden and retrieved the largest stick he could find. He then walked back to the terrified student and struck him over the head.
And as the world went dark, the student was enlightened.
posted by Riki tiki at 8:39 AM on July 4, 2012
The Java master instructed his young student: "Describe to me how you would write a letter."
The student confidently replied:
"First, obtain a pen.
Second, obtain a piece of paper.
Third, place the paper on a desk.
Finally, use the pen to write the letter."
The master scolded him: "And what would have happened if you did not find any paper? You will have written your message upon the desk!"
The student considered this for a while, and then nodded his head. The master continued: "Now, tell me how you would prepare a bowl of rice."
The student, remembering the master's lesson, began:
"First, obtain some rice.
Second, check that you have some rice.
Third, obtain a pot.
Fourth, check that you have a pot.
Fifth, place the rice in the pot.
Sixth, prepare a fire.
Seventh, check that you have a fire.
Eighth, place the pot on the fire.
Ninth, check that the fire has a pot on it.
Tenth, check that there is rice in the pot on the fire..."
The master waited patiently as this continued. When the student had finished, the master scolded him again: "Fool! You place a pot on a fire, and believe yourself wise for proving that there is a pot on the fire? You wasted your time checking things you already know, and so failed to realize you had forgotten to place water in with the rice."
The student bowed his head, ashamed. The master angrily asked him: "Do you have a stick, that I may beat you with it?"
The student was relieved to say that he did not.
The master replied: "Very well." He walked to the garden and retrieved the largest stick he could find. He then walked back to the terrified student and struck him over the head.
And as the world went dark, the student was enlightened.
posted by Riki tiki at 8:39 AM on July 4, 2012
A monk tasked two servants with the cleaning of the monastery, leaving them a bucket of water, a bar of soap, and two mops.
The servants both walked to the bucket, and as each tried to grab it for himself they knocked it over, spilling the water upon the ground.
They returned to the monk and confessed their failure. He chastised them: "Fools, you cannot both grab the same object. You must try again tomorrow."
The next day, the servants arrived in the monastery. They agreed that they would synchronize their actions to make sure they did not both try to take the same object at once. They each took a mop, and first servant picked up the bucket while the second took the soap.
"Please go ahead and begin, friend." said the first servant, as he searched for the soap.
"And you the same, sir." replied the second, for he was still searching for the bucket.
They continued in this fashion throughout the day. When they did not return to the monk, he sought them out.
"Fools!" he said, "did you not realize that your companion was holding the object you needed?"
The servants each protested, "But it was not my job to know what the other servant wants, and I could not waste time understanding his job when there was so much searching to be done for my own!"
The monk considered this and was humbled. "Surely it is I who was foolish, for I did not properly instruct you in the ways of cooperation."
The servants relaxed, knowing that the failure was not theirs. Suddenly, the monk took a blade from under his cloak and slit the throat of the first servant.
"If I had just given this task to a single person in the beginning, all this trouble could have been avoided."
Riki's Poem
A rope cannot be made from tangled threads,
nor from those improperly bound.
Those who do not know how to make rope
should stick to a single strong cord.
posted by Riki tiki at 9:44 AM on July 4, 2012 [2 favorites]
The servants both walked to the bucket, and as each tried to grab it for himself they knocked it over, spilling the water upon the ground.
They returned to the monk and confessed their failure. He chastised them: "Fools, you cannot both grab the same object. You must try again tomorrow."
The next day, the servants arrived in the monastery. They agreed that they would synchronize their actions to make sure they did not both try to take the same object at once. They each took a mop, and first servant picked up the bucket while the second took the soap.
"Please go ahead and begin, friend." said the first servant, as he searched for the soap.
"And you the same, sir." replied the second, for he was still searching for the bucket.
They continued in this fashion throughout the day. When they did not return to the monk, he sought them out.
"Fools!" he said, "did you not realize that your companion was holding the object you needed?"
The servants each protested, "But it was not my job to know what the other servant wants, and I could not waste time understanding his job when there was so much searching to be done for my own!"
The monk considered this and was humbled. "Surely it is I who was foolish, for I did not properly instruct you in the ways of cooperation."
The servants relaxed, knowing that the failure was not theirs. Suddenly, the monk took a blade from under his cloak and slit the throat of the first servant.
"If I had just given this task to a single person in the beginning, all this trouble could have been avoided."
Riki's Poem
A rope cannot be made from tangled threads,
nor from those improperly bound.
Those who do not know how to make rope
should stick to a single strong cord.
posted by Riki tiki at 9:44 AM on July 4, 2012 [2 favorites]
(in case it's not clear, I love this)
posted by Riki tiki at 9:49 AM on July 4, 2012 [1 favorite]
posted by Riki tiki at 9:49 AM on July 4, 2012 [1 favorite]
Three novices were training in the woods. One day, the master came down and announced: "There will be rains in one week's time. You must each build yourself a shelter."
The first novice built for himself a large, comfortable thatch hut.
The second novice began to build a thatch hut, but in the middle of the week decided to reinforce it with some branches.
The third novice began to collect stones, so that he could make the sturdiest hut of all.
The rains came, and the master came down to check on the novices. The first novice had weathered the storm comfortably, although his thatchwork had developed some gaps and tears. The second novice had been uncomfortable in his smaller hut, but both he and it looked well enough. The third novice had not yet been able to finish the walls of his shelter, and had died of exposure.
The master informed the two remaining novices that more rains were coming, far more severe than the ones they had already experienced. The novices returned to their huts to prepare for the encroaching storms.
The first novice found some branches, but he was unable to bind them to the large, weakened thatch walls. The second novice, however, was able to easily reinforce his existing structure.
The storms came and went, and the master returned once again. The first novice was dead among the shredded ruins of his hut. The second had survived, but barely.
The master said to him: "If you know nothing else, know this. There is not always time for greatness, but simple adequacy will not protect you from the winds of change."
The second novice nodded his head, and his training was complete.
posted by Riki tiki at 10:29 AM on July 4, 2012 [2 favorites]
The first novice built for himself a large, comfortable thatch hut.
The second novice began to build a thatch hut, but in the middle of the week decided to reinforce it with some branches.
The third novice began to collect stones, so that he could make the sturdiest hut of all.
The rains came, and the master came down to check on the novices. The first novice had weathered the storm comfortably, although his thatchwork had developed some gaps and tears. The second novice had been uncomfortable in his smaller hut, but both he and it looked well enough. The third novice had not yet been able to finish the walls of his shelter, and had died of exposure.
The master informed the two remaining novices that more rains were coming, far more severe than the ones they had already experienced. The novices returned to their huts to prepare for the encroaching storms.
The first novice found some branches, but he was unable to bind them to the large, weakened thatch walls. The second novice, however, was able to easily reinforce his existing structure.
The storms came and went, and the master returned once again. The first novice was dead among the shredded ruins of his hut. The second had survived, but barely.
The master said to him: "If you know nothing else, know this. There is not always time for greatness, but simple adequacy will not protect you from the winds of change."
The second novice nodded his head, and his training was complete.
posted by Riki tiki at 10:29 AM on July 4, 2012 [2 favorites]
dubitable: I guess this person doesn't like, or understand, TDD.
Really? I took the conclusion:
“Surely,” said the master, “you can solve that problem when you reach the bottom.”
as a pretty clear rebuke to the monks who hadn't been testing first, for rushing to get through things without taking the time to make sure they were right.
He does seem to imply that the Backwards Monk is writing ALL the tests and then writing ALL the code, which I'll grant is an unfortunate misunderstanding. But, heck, still no worse than Rich Hickey has done on occasion.
posted by moss at 10:45 AM on July 4, 2012 [1 favorite]
Really? I took the conclusion:
“Surely,” said the master, “you can solve that problem when you reach the bottom.”
as a pretty clear rebuke to the monks who hadn't been testing first, for rushing to get through things without taking the time to make sure they were right.
He does seem to imply that the Backwards Monk is writing ALL the tests and then writing ALL the code, which I'll grant is an unfortunate misunderstanding. But, heck, still no worse than Rich Hickey has done on occasion.
posted by moss at 10:45 AM on July 4, 2012 [1 favorite]
He does seem to imply that the Backwards Monk is writing ALL the tests and then writing ALL the code, which I'll grant is an unfortunate misunderstanding.
I have done exactly this on two systems in the last few months, in situations where writing the simulation / test suite was a lot easier and faster than writing the actual application, and in situations where live or physical testing would have involved travel and days of labor by several people. Coding the tests first is especially useful if you code bottom up, testing modules as they are completed and using them as blocks to assemble the larger application. In a lot of cases you can't test those modules at all on real data unless the whole thing is complete, and then you're chasing every bug at once.
posted by localroger at 1:01 PM on July 4, 2012
I have done exactly this on two systems in the last few months, in situations where writing the simulation / test suite was a lot easier and faster than writing the actual application, and in situations where live or physical testing would have involved travel and days of labor by several people. Coding the tests first is especially useful if you code bottom up, testing modules as they are completed and using them as blocks to assemble the larger application. In a lot of cases you can't test those modules at all on real data unless the whole thing is complete, and then you're chasing every bug at once.
posted by localroger at 1:01 PM on July 4, 2012
What pissed you off about the immutability one? It seemed pretty innocuous: immutability is useful in some circumstances, but that doesn't mean you should use it all the time. Hard to argue with that.
Perhaps it's hard to argue with that if you are programming exclusively in Java. But Immutability is a core feature of functional programming languages, and is a different paradigm. Simplifying things to a choice of two binaries, mutable and immutable, doesn't begin to approach how Immutability works as a core idiom of a programming paradigm.
The test-driven development one, OK, he's opinionated and I dont necessarily agree with all of his opinions. But 'the author knows crap about software engineering?'. Sheesh. Clan of the High Horse needs to watch out for low-hanging branches.
I'm sincerely not trying to talk down to anyone. I just feel very strongly, the longer I'm in the business, that software engineering should be approached as a professional discipline requiring careful, considered approaches to difficult problems. In fact, after more than ten years I'm only just starting to feel like I understand professionalism in software engineering.
Glib anecdotes can be fun, but these "koans" make things seem simple when they aren't. I dislike them because the lessons taken from these kinds of glib statements are exactly the things that can get lodged in programmers' heads, and trotted out as some kind of truth later on. As someone who had similar misconceptions lodged in my head for a long time, perhaps I'm particularly sensitive to the falsehoods embedded in these parables.
Really? I took the conclusion:
“Surely,” said the master, “you can solve that problem when you reach the bottom.”
as a pretty clear rebuke to the monks who hadn't been testing first, for rushing to get through things without taking the time to make sure they were right.
Hmm...well, first he suggested that this particular monk wrote half the amount of code "after a long delay"--I'm not sure if this is a good thing or a bad thing, since writing less code is good as far as I'm concerned. Then the master challenged him to solve the problem of the empty pool while diving down. Which is a total distortion of how TDD works.
For example, wouldn't a real human diving into a pool be analogous to a "production environment?" Whereas, before using a diving pool, you'd have a testing and development environment with a dummy, perhaps? This suggests to me that the master was an idiot.
posted by dubitable at 8:38 PM on July 4, 2012
Perhaps it's hard to argue with that if you are programming exclusively in Java. But Immutability is a core feature of functional programming languages, and is a different paradigm. Simplifying things to a choice of two binaries, mutable and immutable, doesn't begin to approach how Immutability works as a core idiom of a programming paradigm.
The test-driven development one, OK, he's opinionated and I dont necessarily agree with all of his opinions. But 'the author knows crap about software engineering?'. Sheesh. Clan of the High Horse needs to watch out for low-hanging branches.
I'm sincerely not trying to talk down to anyone. I just feel very strongly, the longer I'm in the business, that software engineering should be approached as a professional discipline requiring careful, considered approaches to difficult problems. In fact, after more than ten years I'm only just starting to feel like I understand professionalism in software engineering.
Glib anecdotes can be fun, but these "koans" make things seem simple when they aren't. I dislike them because the lessons taken from these kinds of glib statements are exactly the things that can get lodged in programmers' heads, and trotted out as some kind of truth later on. As someone who had similar misconceptions lodged in my head for a long time, perhaps I'm particularly sensitive to the falsehoods embedded in these parables.
Really? I took the conclusion:
“Surely,” said the master, “you can solve that problem when you reach the bottom.”
as a pretty clear rebuke to the monks who hadn't been testing first, for rushing to get through things without taking the time to make sure they were right.
Hmm...well, first he suggested that this particular monk wrote half the amount of code "after a long delay"--I'm not sure if this is a good thing or a bad thing, since writing less code is good as far as I'm concerned. Then the master challenged him to solve the problem of the empty pool while diving down. Which is a total distortion of how TDD works.
For example, wouldn't a real human diving into a pool be analogous to a "production environment?" Whereas, before using a diving pool, you'd have a testing and development environment with a dummy, perhaps? This suggests to me that the master was an idiot.
posted by dubitable at 8:38 PM on July 4, 2012
« Older Andy Griffith Dies at 86. | Going to school in fifties' Britain Newer »
This thread has been archived and is closed to new comments
posted by Deathalicious at 7:56 AM on July 3, 2012 [1 favorite]