Extract variable length numbers (tab delimitered) from a string?
in [Perl]
|
Prev: FAQ 9.11 How do I redirect to another page?
Next: FAQ 7.18 How can I access a dynamic variable while a similarly named lexical is in scope?
From: Ted Zlatanov on 4 Aug 2010 15:23 On Wed, 04 Aug 2010 13:53:36 -0400 Sherm Pendley <sherm.pendley(a)gmail.com> wrote: SP> Also keep in mind that "fancy" solutions are rarely the best. I've heard SP> it said that debugging is twice as difficult as writing code, and that SP> being the case, code that's written to the limit of one's abilities is SP> by definition impossible to debug. In all but the most extreme cases, SP> clarity and ease of maintenance are *far* more valuable over the long SP> run than clever tricks. OTOH a programmer that doesn't explore new techniques is not growing (I mean technically; physically they grow with or without new techniques). So there's value in exploration and cleverness. Ted
From: Sherm Pendley on 4 Aug 2010 16:10 "Uri Guttman" <uri(a)StemSystems.com> writes: >>>>>> "TM" == Tad McClellan <tadmc(a)seesig.invalid> writes: > > TM> Sherm Pendley <sherm.pendley(a)gmail.com> wrote: > >> I've heard > >> it said that debugging is twice as difficult as writing code, and that > >> being the case, code that's written to the limit of one's abilities is > >> by definition impossible to debug. > > TM> Everyone knows that debugging is twice as hard as writing a program in > TM> the first place. So if you are as clever as you can be when you write > TM> it, how will you ever debug it? ~Brian Kernighan > > TM> That Kernighan guy has a bit of a reputation amongst programmer types. :-) > > is twice as hard the same as twice the duration? i find i have a very > different ratio of development time to debug time than many coders. i > break it up into three periods and mine are roughly 40% design (much in > my head), 40% coding and 20% debugging. and much of the debugging is > very easy stuff (at least to me). I'd estimate roughly the same. If debugging turns out to be exceptionally difficult, I take it as evidence of a design flaw, and refactor until the (re)design either eliminates the bug or makes it obvious. Of course, the ability to refactor stems from having a sane and modular initial design - that's where the up-front investment pays off big. > i don't use a debugger, IDE or anything > but print and i get working code without pain. brains over typing! :) Agreed - I *very* rarely need to resort to single-stepping, breakpoints, and the like. It's nice to know that they're available though, for those rare occasions when I do need them. sherm-- -- Sherm Pendley <www.shermpendley.com> <www.camelbones.org> Cocoa Developer
From: Sherm Pendley on 4 Aug 2010 16:13 Ted Zlatanov <tzz(a)lifelogs.com> writes: > On Wed, 04 Aug 2010 13:53:36 -0400 Sherm Pendley <sherm.pendley(a)gmail.com> wrote: > > SP> Also keep in mind that "fancy" solutions are rarely the best. I've heard > SP> it said that debugging is twice as difficult as writing code, and that > SP> being the case, code that's written to the limit of one's abilities is > SP> by definition impossible to debug. In all but the most extreme cases, > SP> clarity and ease of maintenance are *far* more valuable over the long > SP> run than clever tricks. > > OTOH a programmer that doesn't explore new techniques is not growing (I > mean technically; physically they grow with or without new techniques). Sedentary desk jobs do tend to have that effect... :-) > So there's value in exploration and cleverness. Certainly, exploring edge cases is part of the learning process. When it comes to production code, though, I find more value in simplicity. sherm-- -- Sherm Pendley <www.shermpendley.com> <www.camelbones.org> Cocoa Developer
From: Ted Zlatanov on 5 Aug 2010 09:07 On Wed, 04 Aug 2010 16:13:38 -0400 Sherm Pendley <sherm.pendley(a)gmail.com> wrote: SP> Ted Zlatanov <tzz(a)lifelogs.com> writes: >> So there's value in exploration and cleverness. SP> Certainly, exploring edge cases is part of the learning process. When SP> it comes to production code, though, I find more value in simplicity. I mean in production too. Today's clever code is tomorrow's standard. For example the Guttman Rossler transform at first was clever and confusing (I've had to explain it to beginners more than once); gradually it became established and today Perl 6 does it internally by default. The threshold IMO is not "is it clever" but "will the maintainer 5 years from now hunt me down and kill me if he goes crazy." I thus tend to avoid Quantum::Superpositions, on-the-fly parser generators, and "ha ha" comments in production code :) Ted
From: Uri Guttman on 6 Aug 2010 04:09
>>>>> "ML" == Martijn Lievaart <m(a)rtij.nl.invlalid> writes: ML> - Perl is so much more powerful, you have to write a lot less code ML> to achieve the same goal. Less LOC, less bugs. that is also a good reason to promote perl. i mention it when i can. fewer lines is always fewer bugs. some metrics have shown there is usually 1 bug per hundred lines of code regardless of the language. so a good perl hacker will have fewer bugs. and well designed perl has even less. :) uri -- Uri Guttman ------ uri(a)stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- |