🚀 go-pugleaf

  The same old arguments are always dragged out to justify bad workmanship, 
  whether in software, hardware, or carpentry.  This time around, we're 
  hearing them from Morgan Schweers.  Nothing personal, but they set of 
  some major BS alarms.

In article <1991Apr8.080931.23209@netcom.COM> mrs@netcom.COM (Morgan Schweers) writes:
# In article <p79Gyx1j1@cs.psu.edu> schwartz@groucho.cs.psu.edu (Scott Schwartz) writes:

# >It worries me.  It also worries me that you aren't worried.
# >
#     This is because you see everything in terms of 'theory' and not
# 'practice'.  (Inferred from your various comments.)  I'm not a theory person
# either, so it doesn't really worry me either.  The point is that if I can get
# somethine to *WORK* then to hell with all the theory in the world.

  I routinely get the same argument when I show someone a design violation 
  in a circuit design:  "Hey, it works!  Who cares about some theoretical 
  problem?"

  Of course, I can't *prove* that a transient error was due to substrate 
  injection resulting from pin overdrive.  Since I can't prove it, let's 
  forget the whole thing, right?

#     I don't need a language to be formally accepted, or formally tested, to
# write code in it.  I do the testing on my program.  If the compiler breaks it,
# I'll worry about it.  If the compiler doesn't break my code, whassamatter with
# it?

  Translation: "It worked; ship it!"

#      I'm a systems programmer, so decide before you respond, if your language
# (probably supposedly universal across all implementations, if I know you theory
# weenies) will do the job for what I consider real work.

  Is this one-downmanship?  I'm one step down from a systems programmer: I
  design the stinking HARDWARE your stuff runs on.  Why don't you REALLY
  get down and dink with the *voltages* like I do?  Bits are for wimps. 

  The same arguments are used universally to justify spending a lot of time 
  on the easy problems of micro-optimizing the 5% instead of making sure 
  the 95% works reliably.

# >| At some point, you have to stop assuring and start doing.
# >
# >Sure.  That's the argument in favor of dynamic typing that has been so
# >well received here recently.  What I'm suggesting is that providing a
# >formal specification of a language is the software engineering analog
# >of using things like parser generators and static type checking.  Yes,
# >no system is perfect, but gee, why make it harder on everyone?
# 
#     YOU are the one looking to make things harder.  Software Engineering?  Get
# real.  Perhaps it's the bad associations I've had with people calling
# themselves Software Engineers (they worked in Ada, Modula-2 and COBOL), but
# Software Engineering For Better Programs is nonsense.  If you have a language
# that makes it possible to 'prove' the program correct, then you have a language
# which is probably putting too many restrictions on the programmer.

  We used to hear this argument from radio hobbyists who would grab the old 
  breadboard, a handful of tubes, and a soldering iron and DISCOVER a 
  circuit.  I trust it as much as I trust a bridge which was built by 
  sticking together available beams however the designer thought they fit 
  well.

#     Also, to me, a formal specification consists of a grammar, and a
# description of the basic keywords.  Period.  At that point, the language is
# defined in terms of what I can use it for.  What do you mean by a 'formal
# specification'?  Don't give me math crap.  I'm a programmer, not a math
# junkie.

  I'm glad you know from the grammer and keywords what would happen if you 
  executed 

    c = f( c, c = g( c ) );

  but frankly, I'd like to know that the results wouldn't change with the 
  compiler version.

#     *IF* you can make me more productive, I'd look at what you were talking
# about.  The important point here is that *I KNOW WHAT I'M DOING*

  That's funny; so did the carpenter who cut before he measured.  I'm glad 
  that there are at least two infallible humans in the world.  As for the 
  rest of us, we make occaisional mistakes and some even appreciate having 
  those mistakes caught early in the cycle rather than late.

#                                                                  and I don't
# want a language that told me I didn't.  I could program in Pascal or some other
# psuedo-useless language if I wanted that.  (I have a friend who is forced to
# program in Pascal.  You should hear him scream for type-casting!)

#      The point is that there are tradeoffs involved, and that there is *NO WAY*
# you are going to design a language that will be both completely useful and
# completely 'safe'.  The two are incompatible, in my (admittedly limited)
# experience.  Prove me wrong.  Feel free.
#                                                            --  Morgan Schweers

  Sounds like Goedel's Theorem.  But I forgot; that's for math weenies.
-- 
| The above opinions may not be original, but they are mine and mine alone. |
|            "While it may not be for you to complete the task,             |
|                 neither are you free to refrain from it."                 |
+-=-=-    (I wish this _was_ original!)        D. C. Sessions          -=-=-+