Re: non-consecutive ranges

[Ehud Lamm <mslamm@mscc.huji.ac.il>]

On Sat, 1 May 1999 bglbv@my-dejanews.com wrote:

> > We can connect this to the idea of abstraction in general. Great
> > scientists are usually regarded to be those that aside from using various
> > scientific abstractions (like differntial equations, newtonianmechanics,
> > thermodynamics etc.), grasp the inner details - thus knowing when things
> > are applicable and when they are not and the theory etc. needs to be
> > modified.
> 
> No, that's just the definition of a _competent_ scientist. To qualify
> as great, a scientist must also have had at least two good original ideas
> in his/her career. [Bad ideas don't count, as one tends not to keep track
> of their originality.]

I tend to agree, though it isn't all that clear cut. But really
off-topic... 

> 
> Back to programming: a competent programmer also needs some understanding
> of the underlying details. In order to successfully use floating point
> arithmetic, you need to know about rounding and about the fact that
> not all real numbers are representable. If you want to write efficient
> code, you need to know both about the properties of the algorithms
> that apply to your problem and about existing constraints on how
> various features of your programming language are implemented.
> The role of abstraction isn't to let us permanently forget the
> details, but rather to help us keep the interdependencies between the
> various parts of a large program at a manageable level.
> 

You mean that if someone sells you and ADT, let's say with some complexity
attributes of the code, you must know the implementation? Surely not.

"Abstraction" is too general a word here. You can program a computer, and
even do it reasonably good without knowing how recursion (an abstraction)
is done on each type of machine your code compiles on. 
However I agree, that in many cases understanding the abstraction means
understanding what's under it.

Consider how many programming books, give "urban legends" as explanations
of how various language abstractions are really handled. 
In many cases it is good enough.

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il