Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^3: Make it good

by BrowserUk (Pope)
on Oct 18, 2004 at 20:19 UTC ( #400306=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Make it good
in thread Make it good

I said produce something. Not produce it and then promote it to the general public.

I did start to try and objectively try and consider whether anything had come out of Matt's script's that might be comsidered good. But then I realised that it would be pointless. Your question has nothing to do with what I said in the post to which you replied. Neither in isolation, nor in the context of the thread of which it is a part.

At this point, I am going to invoke Godwin's Law, as in my opinion, any reference to Matt's script's in the context of Perl programming is exactly equivalent.


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon


Comment on Re^3: Make it good
Re^4: Make it good
by ysth (Canon) on Oct 18, 2004 at 20:28 UTC
    Your question has nothing to do with what I said in the post to which you replied.
    Your post caused me to ask myself the question :)

    I wasn't trying to subtly argue against you; I think you could make a case either for or against. And the answer to my question applies to your argument taken to the exteme. So if you can decide that the script archive did overall lead to more good than bad, you have a very strong argument in favor of "make it work" over all else.

      It's a fair enough question of it's own right, but I don't see the the mistake was in his writing the scripts.

      The mistake was in his promoting their use to the general public, and continuing to promote them even after the flaws were well known and documented and had been brought to his attention.

      That's a different issue entirely to that which I was trying to address. My point was that it is better to have an attempt at a solution to a specified problem as quickly as possible. Correct or incorrect, having something to test is better than having a theoretical design and no code.

      It's essentially the Rapid Prototyping-Extreme Programming philosophy of starting simple and small and fast and then exercising the code to discover it's flaws, limitations and misassumptions. It's very hard, and usually counter-productive to try to design something for the first time. That is to say, without knowing the problems one will encounter, you can expend an aweful lot of energy catering for situations that will never arise in practice. And in doing so, it is easy to miss the those problems that will occur.

      Silly example. There were, in hindsight, some pretty silly design criteria and decisions made in the '50s by aerospace engineers trying to design a supersonic aircraft. The were a lot of scare stories about what would happen to an aircraft when it reached the sound barrier. And a lot of energy expended trying to counter them.

      The world now builds and flies supersonic aircraft routinely. What allows this to be so routine in large part was the work done on the X-1 and X-86. Prototypes that were dangerous and could never have been usable as production craft, but it was through them, the ground they covered, and the fud that they eliminated or raised to the status of real problems, that allowed the F105B, and all subsequent production supersonics to be built.

      Taking the philosophy that every program must be secure, user friendly, reusable is (IMO) untenable. It's somewhat akin to making every script you write totally portable for the off chance that one day you may want to port it. Better to wait until you need to port it, then make it portable.

      This doesn't mean that you leave a script that needs to be secure, unsecured. It means that you don't expend effort making scripts that don't need to be secured, secure.

      It doesn't mean that when writing a script, that if you see a simple way of making some part of it reusable that doesn't compromise the known application of it, that you don't take that route. It means that unless you know up front that a piece of code is likely to be reused, you don't expend additional effort to make it reusable.

      Doing so without cause

      1. can compromise the project in terms of budget, functionality or time.
      2. often as not, when the time comes to reused the code, the efforts made will not have been completely successful anyway, which means that the code will need to be modified for the new use.

        That, in turn often means modifying the original code in order to mainatain the common codebase anyway.

      So, it is better to leave all the modifications required to allow reuse until you a) know that it is going to be reused. b) know how it is going to be reused.

      Only then can the changes required be accessed in light of full knowledge of thr requirements. And the occasion may never arise anyway.

      I don't disagree with radiantmatrix that keeping security, reuse etc. "in mind" when designing or coding programs is a bad thing. Indeed, I would add efficiency (both memory and cycles) to the list.

      In the end, it all a case of emphasis and balance.


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://400306]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (13)
As of 2014-10-22 12:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (118 votes), past polls