Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #2263

Re: A good subset of C

Show all headers | View raw

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xf0siais6zenlw@localhost...

...

>> Put another way, if there are N users of a common piece of code, X, and
>> any or all of the N could have been written with access to the internals
>> of X, then changes to X could break the other N pieces of code. By
>> contrast, if the N modules have been written without knowledge of X's
>> internals then each of the N would have to interact with X via its narrow
>> and documented interface. Then maintaining X becomes easier and safer: as
>> long as the interface conditions are maintained the N modules will still
>> work with it.
>
> I tend to look at programming in terms of the "work" which must be done.
> "work" is an arbitrary, unspecified, mental concept, which I use.  It's
> not defined to be anything specific.  It can mean how much actual work
> is done by the code, or how efficiently the code gets the job done, or
> any other issue where I recognize a restraint or constraint or bottleneck
> or inefficiency might shift or increase the amount of actual work, etc.
> Perhaps, it can be thought of as entropy or complexity or inefficiency
> of the issue, and the programmer is attempting to minimize complexity,
> increase efficiency, or decrease entropy (i.e., increase order).
> "Throughput" is another related term that comes to mind.
>
> From that sense, when you say there are "changes to X [which] could break
> the other N pieces of code" and you've chosen not to make that change,
> I see you preserving the inefficiency, constraints, restraints, or 
> bottlenecks
> etc inherent to X.  At the same time, due to preserving those problems 
> within
> X, you're also shifting "work", outside of X.  This "work" might've been
> implemented most efficiently within X, not outside of X.  This "work" is
> shifted into the, perhaps numerous, "other N" code pieces.  This could
> possibly increase the complexity, inefficiency, etc of the N code pieces.
> This could possibly increase the overall "work" that must be done by the
> entire process too.  By that, I mean the work that the N's and X do 
> together.

Ah, I think I see where you are coming from - basically that you would know 
how X and the other N pieces of code interoperate and, from that, can know 
what effect a change to any of them will have on the others. Am I right?

I was thinking more of *not* knowing or needing to know or even being able 
to know all the details. One of the problems that Parnas' principles were, I 
believe, designed to address was the ever increasing size of software 
projects and the fact that problems being solved by computer programs were 
becoming much larger than any one person could keep in his head. Dividing 
the problem into smaller pieces helped to make large tasks more manageable.

Going back to that millons-of-lines program you mentioned, if the module 
being changed was X and there were 100 other modules which used it then 
rather than a programmer having to understand 101 modules he would have only 
to know about 1 module and its interface contracts. Does that help make 
sense of the principles?

> Perhaps, it might be best to view this using the overlapping circles
> used in set theory?  I.e., the intersection of the circles represents
> the efficiency or throughput or constraint or "richness" etc of the
> code interface.  What you're saying to me is that it's best to restrain
> the size of X's circle (code base) allowing N's circle (code base) to
> get bigger, and/or to restrain the size of X and N intersection (limit
> the efficiency or throughput of the interface).

No, I didn't mean that but I would try to

1. maximise the info X has about itself
2. *minimise* the knowledge other modules have about X
3. make as narrow as possible the interface between X and other modules.

I suppose it is a form of collecting related info together and making the 
world outside as independent as possible of that info.

A good example is the memory allocators malloc, realloc, calloc and free. 
They "know" a lot about each other in that they share data structures and 
records. They offer to the rest of the world, however, a very small 
interface and few insights into their internals. That's a good thing as it 
isolates them from user programs and isolates user programs from them. A 
system programmer could change various allocation internals such as the data 
structures used to divide up memory or the OS call used in order to request 
more. Or he could change from first-fit to next-fit or best-fit etc. None of 
those changes should prevent programs which call malloc and free from 
functioning. If an applications programmer had looked at a particular 
implementation of malloc and found that it used a certain data strucure and 
then written his application to depend on that then the app would be 
vulnerable to changes in the malloc implementation. Would you agree that 
keeping malloc's internals hidden is generally a good thing?

Or how about they way a C library represents a FILE structure? There may be 
some advantages in certain situations to telling programmers what the 
structure contains. But then if that structure were ever to change imagine 
the work that would be involved in checking ALL programs that made file open 
and close calls. It is not just the ones which we know make special use of 
the knowledge of the internals. We would not know which programs used that 
privileged information so would have to check all of them!!! Obviously that 
would be impractical so it is better to keep that information *hidden* and 
thus apply the data hiding principle.

>  In reality, it may
> be best to allow X's circle (code base) to become larger.  It may also
> be best to allow the interface to be or become "richer" in terms of
> features or capabilities.

That's a valid argument but it seems to be a different issue than the one 
that Parnas and others like him were trying to address. Also, here's an 
interesting addition: you could let X become larger and "richer" and then 
even decide to decompose X into subcomponents that interacted with each 
other. Some of those components could themselves be decomposed further. 
Programs which use X should not have to know how it was decomposed 
internally. At the end of the day the interfaces are most important. 
Implementations can change with little cost. But changing interfaces can 
become very expensive.

By the way, as you mentioned efficiency. Of course, people don't usually 
rewrite code to make it slower. More often code gets rewritten to improve 
its efficiency. But time guarantees can be included as part of an interface 
if appropriate.

James

Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 08:47 +0100
  Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 10:56 +0100
    Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 19:41 +0100
      Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 21:08 +0100
        Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 21:58 +0100
          Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 22:55 +0100
            Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-06 00:01 +0100
              Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-06 00:44 +0100
          Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-06 09:45 +0100
  Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 07:33 -0400
    Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 19:14 +0100
    Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 20:12 +0100
      Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 18:57 -0400
        Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-07 11:55 +0100
          Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-07 19:04 -0400
            Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-08 10:14 +0100
              Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-08 07:35 -0400
                Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-08 16:22 +0100
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-09 16:45 -0400
                Re: A good subset of C "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-10 09:04 +0200
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-10 16:30 -0400
                Re: A good subset of C "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-11 11:59 +0200
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-11 11:06 -0400
                Re: A good subset of C Kaz Kylheku <kaz@kylheku.com> - 2014-05-12 00:26 +0000
                Re: A good subset of C "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-12 09:54 +0200
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-12 20:01 -0400
                Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-14 17:45 +0100
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 18:11 -0400
                Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-14 23:54 +0100
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 19:43 -0400
                Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-17 18:00 +0100
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 16:00 -0400
                Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-17 22:17 +0100
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 19:58 -0400
                Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-18 07:59 +0100
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-18 13:10 -0400
                Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-19 00:54 +0100
                Re: A good subset of C Andy Walker <news@cuboid.co.uk> - 2014-05-15 01:31 +0100
                Re: A good subset of C BGB <cr88192@hotmail.com> - 2014-05-14 23:43 -0500
                Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-17 18:38 +0100
                Re: A good subset of C Ian Collins <ian-news@hotmail.com> - 2014-05-25 11:04 +1200
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-24 20:36 -0400
                Re: A good subset of C Ian Collins <ian-news@hotmail.com> - 2014-05-25 12:53 +1200
                Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-24 21:34 -0400
                Re: A good subset of C Ian Collins <ian-news@hotmail.com> - 2014-05-25 14:11 +1200
                Re: A good subset of C Kaz Kylheku <kaz@kylheku.com> - 2014-05-25 06:47 +0000
                Re: A good subset of C Kaz Kylheku <kaz@kylheku.com> - 2014-05-25 06:43 +0000
  Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-05 20:59 +0100
    Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-05 22:28 +0100
      Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 18:57 -0400
        Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-06 00:26 +0100
      Re: A good subset of C George Neuner <gneuner2@comcast.net> - 2014-05-06 14:21 -0400
        Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-07 15:43 +0100
          Re: A good subset of C George Neuner <gneuner2@comcast.net> - 2014-05-07 16:03 -0400
            Re: A good subset of C "BartC" <bc@freeuk.com> - 2014-05-07 21:31 +0100
          Re: A good subset of C BGB <cr88192@hotmail.com> - 2014-05-07 15:41 -0500
    Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 18:46 -0400
      Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-06 00:42 +0100
        Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-06 06:48 -0400
          Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-07 15:40 +0100
            Re: A good subset of C "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-08 06:50 -0400
              Re: A good subset of C "James Harris" <james.harris.1@gmail.com> - 2014-05-08 15:43 +0100
                Re: A good subset of C George Neuner <gneuner2@comcast.net> - 2014-05-08 14:41 -0400
  Re: A good subset of C BGB <cr88192@hotmail.com> - 2014-05-05 19:08 -0500

csiph-web