Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Gene Wirchenko Newsgroups: comp.lang.java.programmer Subject: Re: Holy boop: goto for Java Date: Tue, 05 Jun 2012 20:06:02 -0700 Organization: A noiseless patient Spider Lines: 52 Message-ID: References: <6AVyr.1859$8l2.827@newsfe14.iad> <77a353f2-0933-413a-8e47-df577ba64976@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="wKah3EH8kutwAOV6+9FiEQ"; logging-data="8450"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+MFMQSBb+CMCGX1dX+O8nR25Y1M0atIgE=" X-Newsreader: Forte Agent 4.2/32.1118 Cancel-Lock: sha1:jDgkJ/mUacoZDQBuf92QLvZtJu4= Xref: csiph.com comp.lang.java.programmer:15082 On Tue, 05 Jun 2012 17:30:57 -0400, Eric Sosman wrote: >On 6/5/2012 5:24 PM, Robert Klemme wrote: >> On 05.06.2012 18:15, Gene Wirchenko wrote: >>> On Tue, 05 Jun 2012 07:31:44 +0200, Robert Klemme >>> wrote: >> >>> Which is often us so being nice to the maintenance programmer is >>> being nice to oneself. >> >> That's a nice side effect - and a motivating argument which helps the >> selfish. :-) Enlightened selfishness. >>> Besides the story paradigm, I also think in terms of program >>> usefulness. If a program is not very useful, one can write it pretty >>> much any way one wants as the program is going to get tossed anyway. >>> If it is useful, then it is going to stick around, and requirements >>> have a way of changing so the program had better be maintainable. It >>> can also be difficult to tell whether a program will be useful so why >>> not just write them all clearly? >> >> I suspect often the answer to that question is: because the author did >> not understand the problem or the program or programming itself clearly. I would go with the latter but not the former. One can still program clearly even if one is unsure of exactly what to do, but those who can not program are very good at messing up. >> The other big reason is carelessness, often increased by tight >> schedules. Deadlines seem to make people nervous and trying to take >> short circuits. But it will cost - sooner or later. Yup. > In my experience, it is often the case that shortcuts extract >their price sooner rather than later, in the form of more testing >and debugging time (and if you don't pay that price, you pay the >still higher price of more and nastier bugs, more support headaches, >and more patch releases). > > Not always, mind, but often. Not always, so those who want to justify shortcuts can do so. Try pointing out that the same arguments apply to playing Russian roulette, and invite them to play. Sincerely, Gene Wirchenko