comp.lang.ada
 help / color / mirror / Atom feed
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: Types with physical dimension
Date: 4 Oct 1994 10:56:44 -0400
Date: 1994-10-04T10:56:44-04:00	[thread overview]
Message-ID: <36rqfc$km7@gnat.cs.nyu.edu> (raw)
In-Reply-To: SAL714.94Oct3133110@rs710.gsfc.nasa.gov

strong typing is like anything else, fine in moderation, but dangerous to
health if overdoses are encountered.

there is a common tendency in Ada programming to assume that since strong
typing is a GOOD THING, it must make sense to use it as much as possible.
This leads to programs which thousands of different integer types and
conversions all over the place. For my taste that actually decreases
reliability, since 

(a) it makes the code less readable

(b) once you get in the habit of freely breaking type barriers by writing
conversions, then the value of the type barriers is diminished.

I much prefer a style in which different integer types are used only when
it is very rare that the need for conversions will arise, or when the
necessary conversions can be nicely abstracted.

Similarly, if setting up an abstraction requires writing a huge amount of
code, which might itself have errors, then the mere fact that you can use
the abstraction neatly when you are done may not leave you ahead (this is
an instance of the common behavior of spending your time building tools
to increase your productivity, spending all your time on this is NOT
a good idea :-)

Obviously everyone knows that strong typing is helpful (says he after
spending a frstrating half hour finding a bug in an idiotic little C
program -- left the & off in a call to sscanf, resulting in unimaginable
and hard to debug chaos). But that doesn't mean "the more strong typing
tne better".

Good software engineering is the art of choosing the right abstractions,
and structures, and it is not the case that it is always preferable to
raise the level of abstraction as far as possible -- it needs to be at
just the right level. 

The units case is an interesting one. Sure there are are programming
situations where providing some automatically type checked units checking
makes sense, but there are also situations where the attempt to provide
such checking is precisely abstraction overkill. It's a nice example that
way, because it lies somewhere near the borderline, and you need the skill
to make the right cut on this border.




  parent reply	other threads:[~1994-10-04 14:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1994-09-27 22:18 Types with physical dimension Paul Graham
1994-09-28 13:59 ` Robert Dewar
1994-09-30  2:06   ` R_Tim_Coslet
1994-10-03 17:31 ` Stephen A. Leake
1994-10-04 11:51   ` Robert I. Eachus
1994-10-04 19:45     ` Mark A Biggar
     [not found]       ` <CxBBx8.7L@irvine.com>
1994-10-13 22:15         ` gamache
1994-10-12  3:43     ` Matt Kennel
1994-10-04 14:56   ` Robert Dewar [this message]
1994-10-05 14:53     ` Bob Gilbert
1994-10-05  8:38   ` Jean-Pierre Rosen
1994-10-05 10:35     ` Stephen J Bevan
1994-10-05 13:17       ` Jean-Pierre Rosen
1994-10-05 15:48     ` Norman H. Cohen
  -- strict thread matches above, loose matches on Subject: below --
1994-09-28 10:55 Simtel20 Transfer
1994-09-28 18:56 ` Mark A Biggar
1994-10-04  2:06 ` lmiller
1994-09-28 19:28 Paul Pukite
     [not found] <GRAHAM.94Sep27181841@canopus.clsi.com>
1994-09-28 17:36 ` William Brennan
1994-09-28 21:41 ` Tucker Taft
1994-09-29  4:11   ` Robert Dewar
1994-09-29 11:19     ` Peter Hermann
1994-09-30 10:17       ` Dr John Stockton
1994-10-03  4:37       ` Robert Dewar
1994-09-29 13:37     ` Tucker Taft
1994-10-03  4:40       ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox