home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.lang.c:20135 comp.lang.c++:19820
- Path: sparky!uunet!cs.utexas.edu!asuvax!ncar!noao!amethyst!organpipe.uug.arizona.edu!news
- From: dave@cs.arizona.edu (Dave Schaumann)
- Newsgroups: comp.lang.c,comp.lang.c++
- Subject: Re: C/C++ Correctness (was: Re: C/C++ Speed)
- Message-ID: <1993Jan23.195329.230@organpipe.uug.arizona.edu>
- Date: 23 Jan 93 19:53:29 GMT
- References: <TMB.93Jan14143610@arolla.idiap.ch> <C19qw8.1z3@brunel.ac.uk>
- Sender: news@organpipe.uug.arizona.edu
- Reply-To: dave@cs.arizona.edu (Dave Schaumann)
- Followup-To: comp.lang.c
- Organization: University of Arizona
- Lines: 24
- In-Reply-To: cs89rdb@brunel.ac.uk (Roger D Binns)
-
- In article <C19qw8.1z3@brunel.ac.uk>, cs89rdb@brunel (Roger D Binns) writes:
- >[...]The question is what would you rather have:
- >
- >- A product early to market that is correct, and runs at a performance
- > 'penalty'
- >- A product early to market that is incorrect, and has no penalty
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- Excuse me? Seems like a buggy or wrong implementation is its own penalty...
-
- >- A product late to market that is correct and has no performance penalty
- >
- >I suspect the case is the first one. The second one seems to be common
- >practice. The last one will give you the warm fuzzy feeling you desire
- >when having no performance penalty.
-
- Producing software tends to be highly competative. Many times, having
- a product available is more important (at least, in the short term) than
- the quality of its implementation. Moreover, if a more robust update
- comes out reasonably quickly, the bugs of the initial version are quickly
- forgotten.
-
- --
- Caught an internal error--.brainrc restored
-