Re: interpretive vs. compiled

On 20 Jan., 21:23, Ed Prochak <edproc...@xxxxxxxxx> wrote:
On Jan 20, 8:21 am, thomas.mer...@xxxxxx wrote:

On 19 Jan., 22:31, p...@xxxxxxxxxxxxxxxxx (Pascal J. Bourguignon)
wrote:
[]

When writing complex applications it is very important to do a
careful program design. A heap of kludges does not help when the
problem is complex. Usually the development costs are tiny compared
to the maintenance costs which come later.

Please tell that to most management. If we all repeat it enough, maybe
it will sink in.

Managers have different objectives than developers. Some managers
even hope to be not in charge when the big maintenance costs come.
Managers think in deadlines and man-months, so they have some
excuse. But developers should know. I dont like when people pretend
to be developers and tell stories about throwing away all concepts
of good design and development.

For this reason it is important to have deliberate concepts before
you start to write code. It is a good idea when this concepts are
also documented as part of the program. A program consists of code
and data and the concepts of both should be documented. It is a big
mistake to omit the description of the data concepts. Although the
data structure is implicitly defined in the code it should still be
described explicit. This improves the readability considerably.

As I often say, self documenting code isn't.

Keep in mind that programs are much more often read than written.

This is the second time you claimed that, but I wonder how true it
really is. I have no evidence either way, do you?

Everything that helps to make a program readable is an advantage.

Agree

There are studies about the costs of errors in big programs.
In general:
- Errors which happen earlier are more expensive than errors
happening later. E.g. A design error is more expensive than
a coding error.

This sounds exactly backwards. Th cost to design a feature is X, the
cost to code that feature is Y. The total cost to the company at the
point code is complete is X+Y. Your statements are confusing here.

The phrase was misleading. I wanted to talk about bugs which show
of in production: The errors caused earlier in the development cycle
are usually more expensive to fix than later errors. In other words:
Errors which were longer undiscovered in the development cycle turn
out to be harder (and more expensive) to fix. When you find a fatal
design error during production a complete redesign and rewrite may
be necessary. An error introduced in the coding phase is probably
cheaper to fix (no redesign is necessary).

- The sooner an error is found and fixed the cheaper. E.g. A
syntax error found at compile time (or at startup time in an
interpreter) is cheaper than a runtime error (which probably
needs a debugging session).

So you recover somewhat here. Errors found in code unit tests require
more work (more $$$ & time) to correct than errors found at design
time (e.g. in a design review). At least once I heard it was something
like a factor of 10 at each stage (i.e., error found at design time
costs about $1, then finding it when coding costs about $10, and in
test about $100 and finally in production about $1000) on a relative
scale.

I heared also something about a factor of 10 at each stage.

Every method which helps to avoid bugs or to find bugs is good.

Only uninformed "developers" complain about nitpicking compilers
and nasty syntax or type errors. Such people have pipe dreams about
programming without errors. The interpreter will automatically
read the mind of the developer and decide perfectly at runtime...

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
.

Relevant Pages

  • Re: UL/ETL Choking the market
    ... As a lighting designer with a lot of experience outside the US market ... In most of the world, standards are written to require manufacturers, ... design freedom the least possible, with descriptive, performance based ... It costs construction clients enormously. ...
    (sci.engr.lighting)
  • Re: OOP/OOD Philosophy
    ... >> methodology could have avoided the headaches - all things being equal. ... System design methodologies generally do guarantee ... If it costs more than you have, ... >>>still need specific deliverables from the prototyping. ...
    (comp.object)
  • Re: ReaderWriterLockSlim + Dispose?
    ... This should be sufficiently close to the paradigm of "dispose straight away and let threads do their thing" that even the person for whom "that's just the way he thinks" could easily comprehend and use such a design. ... However, your proposed design can be implemented in a couple of ways: a single try/catch at the very top of the thread's call chain, or a try/catch around each and every possible use of a disposable object. ... These are clear code maintenance problems, ones that will necessarily and unavoidable result in higher maintenance costs for the code. ... On the other hand, the design I've proposed carries no hidden performance costs, is 100% predictable, and as a result of that can be easily shown to correctly deal with tearing down worker threads. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: interpretive vs. compiled
    ... Usually the development costs are tiny compared ...   happening later. ... A design error is more expensive than ... If a language is more permissive ...
    (comp.programming)
  • Re: Music publishing service?
    ... In my experience, if you want to make money from your music, there is ... I would suggest that you may be wrong in wanting to design the art ... unusual to find a professional set up that will accept artwork from ... jeans will not impress those managers ... ...
    (rec.music.makers.songwriting)