Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.misc > #2265
| From | "James Harris" <james.harris.1@gmail.com> |
|---|---|
| Newsgroups | comp.lang.misc |
| Subject | Re: A good subset of C |
| Date | 2014-05-18 07:59 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <ll9lp4$9gl$1@dont-email.me> (permalink) |
| References | (16 earlier) <op.xfviucge6zenlw@localhost> <ll84id$b6a$1@dont-email.me> <op.xf0siais6zenlw@localhost> <ll8jnp$qea$1@dont-email.me> <op.xf03jult6zenlw@localhost> |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
news:op.xf03jult6zenlw@localhost...
> On Sat, 17 May 2014 17:17:19 -0400, James Harris
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>> news:op.xf0siais6zenlw@localhost...
>
> ...
>
>> 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.
>
> Those who code Forth have a similar principle. They call it "factoring".
>
> Basically, they break the problem down into the absolute smallest
> testable unit.
That's very different. If that is what you had in mind I'm not surprised
that you didn't like the principles but that's not what they are about.
The Forther approach does sound interesting from the viewpoint of software
quality assurance and testing though. But let's not go there just now.
> It's excellent for creating compact code, which was
> a noble goal in the 1970's and 80's on 8-bit home computers.
>
> The problem with factoring today is that it creates a huge amount of
> nesting of Forth words. The call overhead of all the nesting slows
> down both interpreted Forth and compiled Forth. It's somewhat like
> excessive use of procedures in C:
>
> /* untested */
>
> int add(int a, int b)
> {
> return(a+b);
> }
>
> void store(int *a,int b)
> {
> *a=b;
> }
>
> int fetch(int *a)
> {
> return(*a);
> }
>
> void emit(char *s)
> {
> printf("%s\n",s);
> }
>
> ...
> store(&c,add(1,2)); /* c=1+2; */
> if(fetch(&c)==3)
> emit("sum is 3");
> ...
>
>
> Clearly, it's better to not have that extra overhead, if the code
> can be written directly. That means some tasks shouldn't always
> be divided into the smallest possible units.
Yes. Different issue.
>> 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?
>
> We had a situation where we had to change a structure used in our
> database.
> The amount of information we needed to record increased.
>
> Fortunately, the original authors provided a field at the start of the
> structure for a version number. Our options to fix the problem were:
>
> 1) change the version number, add code everywhere to check the version
> number and use the appropriate overlay (structure)
>
> 2) change the version number, rewrite the code to use a pointer to an
> overlay, set the pointer to the correct overlay based on the version
> number
>
> 3) read in all records in the old format, write out all records in the
> new format, and recompile the application to use the new format
>
> Which one did we choose?
>
> The answer to one of your questions is: "No idea ..."
>
> The answer to the other is #3.
:-( I've lost track of which question needs to be put with which answer.
> The record size, which was fixed, had to increase to support the larger
> records anyway. So, all records had to be read in and written out with
> more space, whether they were reformatted to the new layout or not.
>
> "Path of least resistance" comes to mind.
>
>>> 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.
(To be clearer, there is an implicit "and" between those three, not an
"or".)
> There are numerous programming examples where increased complexity and an
> increase of the information flow between modules results in a more
> efficiency.
> That's why I have a problem with accepting #3. It may be the minimal
> result,
> but not necessarily the most efficient. So, if you're preferencing the
> minimal
> result, are you harming efficiency?
I cannot see the connection with efficiency or lack thereof unless you are
thinking of the microdivision of Forth that you mentioned above (which would
certainly be inefficient). Module X would not be minimal in size like a
Forth word. It would be whatever size is appropriate for the problem being
solved.
Keeping X's interface small does not necessarily mean keeping X small. In
the malloc example, the allocator may have singificant data structures
internally but programs communicate with the allocator by very narrow
interfaces. For example, malloc expects nothing more than a single size and
returns a single pointer. That may not be a perfect design but it is
certainly a good example of modularity. The implementations of malloc have
changed over the years and such changes have been made possible because
programs which call it do not know the internal structures. They are hidden
and that hiding makes changes safe. That's got to be a good thing, right?
>> 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
>> [structure]
>> 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?
>
> In general, yes, I would agree, but that's only because I can't think
> of a decent counter example where someone would need access to malloc's
> internals. But, if I had some decent use for direct access to the
> information of malloc(), I'd have to disagree.
Interesting. Don't forget that if you wanted something like the block length
you don't have to get it from malloc's own data. You could store your own
copy in the returned block and thus retain the modularity and independence
from a particular malloc's implementation. Isn't that a benefit of data
hiding?
> But, I'd definately question the sanity of someone breaking apart a
> sort routine or search algorithm across multiple modules.
Sure. If parts of a routine work in conjunction with each other, operate on
the same data and use the same structures then keep them together.
A sort routine is a good example of a module especially where it can be
reused in many situations. Few of the users of that sort module would want
to know the details of its internals. If they did then they probably need
their own customised sort functions.
> I recall thinking a few years ago that some problem would only take a
> few lines of code to solve if I had access to the internal buffer of
> the function. I'm guessing this was strtok() ...
>
> So, where exactly should the boundary be drawn between information I'd
> like to use as a programmer and information the module provides to me?
There may be some science to it but as far as I am aware knowing how to
modularise is part of the art of developing software.
> Who should draw the boundary? The user? He knows what he needs, but
> probably only when he needs it. The original coder? He only has
> expectations of what the users may need and clearly can't expect to
> know every intended use. So, that boundary could be too restrictive
> or too open, but I suspect "information hiding" will encourage too
> restrictive designs, at least in regards to efficiency.
I don't see why that would make programs inefficient unless, again, you are
thinking of the Forth example that you mentioned earlier. To me that's not
information hiding but potentially excessive problem subdivision.
Isn't information hiding more about keeping *data* separate?
> The concept of "information hiding" keep me thinking about what a
> coworker said about C++ being layers upon layers of unnecessary
> abstractions.
OK.
>> Implementations can change with little cost. But changing interfaces
>> can become very expensive.
>
> Well, that depends on the implementation. If they implemented version
> numbers as a part of the interface or as part of structs etc, then
> the code can work with changing structures and/or interface.
>
>> By the way, as you mentioned efficiency. Of course, people don't
>> usually rewrite code to make it slower.
>
> Um, let's not argue that one ... simpler code may be desired, a smaller
> memory footprint may be required, life has unintended consequences,
> experience and intellect affects results, people aren't actually
> replaceable in the workplace, and other such stuff.
>
>> More often code gets rewritten to improve its efficiency. But time
>> guarantees can be included as part of an interface if appropriate.
>
> Yes, but what if the efficiency can only improve by changing the
> "expensive" interface? Do you preserve the interface? Has doing
> so become "taboo" because of Parnas Principles?
I don't believe anything becomes prohibited. Parnas' Principles and others
related to software system construction are about helping rather than
hindering. Changing the internals of a module has a cost and some benefits.
Changing an interface has a cost and some benefits. If the benefits of
changing an interface outweigh the cost then it's worth doing.
How about you? If the modularity of a system is well designed do you think
that modular systems would be less costly to write and to maintain? If a
monolithic system better choice, perhaps up to a certain point?
James
Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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