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

Groups > comp.lang.misc > #2178 > unrolled thread

A good subset of C

Back to article view | Back to comp.lang.misc

Contents

  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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#2231

On Sat, 10 May 2014 03:04:02 -0400, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> wrote:
> On Fri, 09 May 2014 16:45:41 -0400, Rod Pemberton wrote:

>> It seems this is about object-oriented languages, and it mentions
>> "information hiding".  As a programmer, information hiding is a
>> *bad* thing.
>
> No, it is a method of maintaining complexity and so of making collective
> software production possible (roles, separate design, testing,
> maintenance).
>
> It is not bad or good, it is the only way software engineering may
> function.

...

> Yes, proper engineering processes and techniques on small scale
> are considered unnecessary overhead, boring, and they certainly are. The
> problem is that programmes can only be taught on small things first. This
> is why C is so popular, and also so damaging to software developing in
> general.
>

Have you used tools like hammers, drills, knives in your life? e.g., at
home or work.  I'm assuming you have at some point in your life.

The reason I ask is that above you said information hiding "is [neither]
bad or good".  I suspect you would describe a hammer as neither good or
bad too.  We all know they are very useful for what they do.  But, we all
also know that misuse can injure a person, or even be used to kill.

It's from that which I find irony in your statements.  You claim C is
damaging in general, yet it is a tool just like a hammer, drill, or knife,
which can be used correctly to great effect by many people, and yet still
be misused by many others.

So, C's no different than information hiding as you perceive information
hiding.  You like one, but oppose the other.  Irony.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2232

On Sat, 10 May 2014 16:30:37 -0400, Rod Pemberton wrote:

> On Sat, 10 May 2014 03:04:02 -0400, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> wrote:
>> On Fri, 09 May 2014 16:45:41 -0400, Rod Pemberton wrote:
> 
>>> It seems this is about object-oriented languages, and it mentions
>>> "information hiding".  As a programmer, information hiding is a
>>> *bad* thing.
>>
>> No, it is a method of maintaining complexity and so of making collective
>> software production possible (roles, separate design, testing,
>> maintenance).
>>
>> It is not bad or good, it is the only way software engineering may
>> function.
> 
> ...
> 
>> Yes, proper engineering processes and techniques on small scale
>> are considered unnecessary overhead, boring, and they certainly are. The
>> problem is that programmes can only be taught on small things first. This
>> is why C is so popular, and also so damaging to software developing in
>> general.
> 
> Have you used tools like hammers, drills, knives in your life? e.g., at
> home or work.  I'm assuming you have at some point in your life.
> 
> The reason I ask is that above you said information hiding "is [neither]
> bad or good".  I suspect you would describe a hammer as neither good or
> bad too.  We all know they are very useful for what they do.  But, we all
> also know that misuse can injure a person, or even be used to kill.

The point was that regardless of your or my attitude to information hiding,
it is the only possible way to go with software engineering.

Likewise, you, a user of a hammer, need not to know anything about
metallurgy, solid-state physics, forestry etc to handle the hammer. That is
information hiding.

> It's from that which I find irony in your statements.  You claim C is
> damaging in general, yet it is a tool just like a hammer, drill, or knife,
> which can be used correctly to great effect by many people, and yet still
> be misused by many others.

> So, C's no different than information hiding as you perceive information
> hiding.  You like one, but oppose the other.  Irony.

There is no contradiction in that. Yes, you can use a brush cutter to trim
your nasal hair. Sarcasm.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2233

On Sun, 11 May 2014 05:59:30 -0400, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> wrote:

> The point was that regardless of your or my attitude to information  
> hiding, it is the only possible way to go with software engineering.
>

Why?

The largest application I ever worked on was over 5 million lines of
code.  It was coded in a version of PL/I.  Where was this supposed
information hiding you say is necessary for software engineering?

If it's not needed for a 5Mloc application, why is it ever needed?

A programmer skilled in the task at hand isn't going to use information
that is unnecessary.  The selective, decision making process of the
programmer effectively filters out what is unneeded, i.e., hides  
information.

Do engineers intentionally add inefficiency or waste to their designs?

Do programmers intentionally design code which is slow or redundant?

E.g., I'm not going to construct sine from tangent and cosine (or tables,
or Taylor series, etc) if sine is available.  I.e., my selection of
an implemented sine function hides the all the unnecessary information
about that implementation of sine from me, unless I look at the code.

So, why does the information need to be _intentionally_ hidden?

> Likewise, you, a user of a hammer, need not to know anything about
> metallurgy, solid-state physics, forestry etc to handle the hammer.
> That is information hiding.

Those that created the hammer knew nothing about any of that either.
So, if no one knew the information in the first place, just when did
the information become hidden from them?  The information became
revealed at some point.  Can those using the hammer after that
information is revealed remain ignorant of that information?  Yes.
Is anything hidden now?  No.  Someone knows it.  Others can learn it.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2234

On 2014-05-11, Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Sun, 11 May 2014 05:59:30 -0400, Dmitry A. Kazakov  
><mailbox@dmitry-kazakov.de> wrote:
>
>> The point was that regardless of your or my attitude to information  
>> hiding, it is the only possible way to go with software engineering.
>>
>
> Why?
>
> The largest application I ever worked on was over 5 million lines of
> code.  It was coded in a version of PL/I.  Where was this supposed
> information hiding you say is necessary for software engineering?

Ah, the answer to that is: information hiding occurred when that project
was buried six feet under ground and forgotten.

Information hiding will get your ass one way or another.

[toc] | [prev] | [next] | [standalone]

#2237

On Sun, 11 May 2014 11:06:15 -0400, Rod Pemberton wrote:

> On Sun, 11 May 2014 05:59:30 -0400, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> wrote:
> 
>> The point was that regardless of your or my attitude to information  
>> hiding, it is the only possible way to go with software engineering.
> 
> Why?

In order to be able to handle information.
 
> If it's not needed for a 5Mloc application, why is it ever needed?

That reminds the me a reasoning why you will never die. That is because you
never died before.

> Do engineers intentionally add inefficiency or waste to their designs?

Sure. They trade efficiency for developing time, maintainability,
portability, quality whatever. Software design has certain priorities,
nothing has absolute value.
 
> Do programmers intentionally design code which is slow or redundant?

Yes, they do.

There is not even exist the most fast implementation of a given problem
(beyond trivial ones), because the program runs on different input sets
with input instances more and less important to the customer, which are
more and less likely to realize, with execution environment ever changing.
Thus it is not possible to measure, to even define, the speed of a program
in a numeric well-ordered form.

Time constraints are not absolute even when specified, in a real-time
system, for example. Note that especially in a real-time system you would
not fight for speed. On the contrary you would design the program to work
under the constraint for the worst case scenario. E.g. you would use
polling (slow) instead of even-controlled design (fast) because polling is
predictable. You would use a suboptimal algorithm which performance is more
even (again, predictable). You trade speed for predictability in order to
ensure the time constraint.

As for redundant code, it is one of the major tool of making fault-tolerant
mission-critical systems. In older times it was even required to develop
the same project twice by two independent teams.

> E.g., I'm not going to construct sine from tangent and cosine (or tables,
> or Taylor series, etc) if sine is available.

It is an absurd example because you named no obvious advantage of using tg
+ cos vs. sin. You would not jump out of the window either. But, if the
house were burning you would probably reconsider it.

> So, why does the information need to be _intentionally_ hidden?

Because there is too much of information to handle.

>> Likewise, you, a user of a hammer, need not to know anything about
>> metallurgy, solid-state physics, forestry etc to handle the hammer.
>> That is information hiding.
> 
> Those that created the hammer knew nothing about any of that either.

Yes, because hiding information is layered and deep rooted. Those who
produced steel don't care about forestry. This is how industrial society
functions.

The problem of software design is exactly that it has not reached the level
and expanse of information hiding normal for proper engineering.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2241

On Mon, 12 May 2014 03:54:45 -0400, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> wrote:
> On Sun, 11 May 2014 11:06:15 -0400, Rod Pemberton wrote:

>> [snip]
> [snip]
...

> Note that especially in a real-time system you would not
> fight for speed.

...

> As for redundant code, it is one of the major tool of making
> fault-tolerant mission-critical systems.

...

>> So, why does the information need to be _intentionally_ hidden?
>
> Because there is too much [...] information to handle.

...

I have to disagree with those three, but I see no point in continuing.


Maybe, I should've described the 5MLoc application in more detail ...

It was a RT (real-time) OLTP (online transaction processing) application
with transaction protection which used with a 3rd party, fault-tolerant,
in-memory database/ramdisk, all executing on fault tolerant, redundant
hardware (Stratus Continuum 600 series).  The code was in PL/1.  PL/1 is
Stratus' standard compliant version of early PL/I.  It was an internal
company application which handled the brokerage's stock trading for NYSE
and NASDAQ securities.  It handled four T1's of continuous, incoming quote
feeds and other securities data in real-time.  This was circa year 2000.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2247

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xfpawpq36zenlw@localhost...
> On Sun, 11 May 2014 05:59:30 -0400, Dmitry A. Kazakov 
> <mailbox@dmitry-kazakov.de> wrote:
>
>> The point was that regardless of your or my attitude to information 
>> hiding, it is the only possible way to go with software engineering.
>>
>
> Why?
>
> The largest application I ever worked on was over 5 million lines of
> code.  It was coded in a version of PL/I.

Then you have suffered enough. :-|

> Where was this supposed
> information hiding you say is necessary for software engineering?
>
> If it's not needed for a 5Mloc application, why is it ever needed?

Most of those 5M lines would not have been code at all but comments 
explaining what the code was supposed to do and telling later programmers 
why someone had chosen to write the app in PL/I and what remedial action was 
taken to rehabilitate that person back into society. ;-)

Are you sure there was no information hiding? Did not the hiding of 
information that was there make maintenance of the code easier?

James

[toc] | [prev] | [next] | [standalone]

#2249

On Wed, 14 May 2014 12:45:18 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xfpawpq36zenlw@localhost...

>> If it's not needed for a 5Mloc application, why is it ever needed?
>
> Most of those 5M lines would not have been code at all but comments
> explaining what the code was supposed to do and telling later programmers
> why someone had chosen to write the app in PL/I and what remedial action
> was taken to rehabilitate that person back into society. ;-)

Well, I tried to get them to port the code to C (or C++) in order to:

1) ensure the code remained valuable, either for use or for sale
2) perhaps allow the code to be rewritten to operate faster
3) prevent the code from being "buried six feet under ground and
forgotten" as Kaz stated

But, one of the other key programmers wasn't interested in learning
C/C++ and the manager was definately not visionary, not a hard worker,
not a risk taker in regards to his job, nor forward thinking.  I.e.,
the _less_ anyone did to "break" the system, the better it was for
him politically.

Today, I think the code might've been "buried" some five years
later.  They eventually shut down that department.  But, it may
still be running somewhere, at some company, just with different
people.  That company went through additional acquisitions after
I was gone.

> Are you sure there was no information hiding? Did not the hiding of
> information that was there make maintenance of the code easier?

It hid information no more than C hides information.  I don't exactly
"see" how information is "hidden" in C.  Perhaps, I'm expecting an
explicit mechanism where there is none?  So, maybe, I'm not grasping
where the hiding is occurring? ...


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2250

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xfvelvyg6zenlw@localhost...
> On Wed, 14 May 2014 12:45:18 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>> news:op.xfpawpq36zenlw@localhost...
>
>>> If it's not needed for a 5Mloc application, why is it ever needed?

...

>> Are you sure there was no information hiding? Did not the hiding of
>> information that was there make maintenance of the code easier?
>
> It hid information no more than C hides information.  I don't exactly
> "see" how information is "hidden" in C.  Perhaps, I'm expecting an
> explicit mechanism where there is none?  So, maybe, I'm not grasping
> where the hiding is occurring? ...

I don't see the connection of C to this subthread. I know you discussed it 
with Dmitry. Unlike Dmitry I think that C can be an excellent language and 
environment for software development as long as it is used wisely.

Re. the 5Mloc app I would guess that it had to be divided up somehow - into 
modules or into functions etc. As a result of that, presumably programmers 
could work on parts of the app without having to examine or understand 
(perish the thought!) the rest of the 5M lines. Because a given part's 
internals were hidden a programmer could work on that part as long as he or 
she kept to the contracted interface. Anywhere close? Without the *hiding* 
of internals any work on a part of the app would have been 
impractical/impossible/terrifying/costly (delete as appropriate). :-)

Just on C's facilities for hiding information, though, I see your comment 
that you don't recognise a mechanism for it. Could it be that you naturally 
use information hiding in C without thinking of it as such?

Quite apart from discussing the benefits or liabilities of information 
hiding it might be worth discussing C's support for info hiding.

James

[toc] | [prev] | [next] | [standalone]

#2252

On Wed, 14 May 2014 18:54:26 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

> Re. the 5Mloc app I would guess that it had to be divided up somehow
> - into modules or into functions etc. As a result of that, presumably
> programmers could work on parts of the app without having to examine
> or understand (perish the thought!) the rest of the 5M lines.

A diagram of the hardware used for this mess was like a giant,
multi-headed, octopus ...  The trading application would be
single-headed.

Yes, the application was divided into "components" and other code.
Only about 1MLoc was "active" code.  The rest was for support,
debugging, obsolete, or reports, etc.  There was one portion which
handled incoming data on stocks (quote feeds).  We ran four instances
of that to provide balanced processing.  There were many apps for
outgoing data (line handlers) which sent out trade data to the
appropriate exchange or reporting agency.  Each exchange had a
different line handler, as did the back office system for the
customer accounts which was a different department.  They used AS400s.
Then, there was the user application portion of the main application.
There were two versions of that.  A single pointer changed the function
calls which were used for terminal support allowing user terminals and
our development terminals.  However, all the code was available to
the maintenance programmers and all of the code operated against the
same database of stock quote/trade information.  Reports and other
reporting applications were run against the database at the end of day.

> Because a given part's internals were hidden a programmer could
> work on that part as long as he or she kept to the contracted
> interface. Anywhere close? Without the *hiding* of internals any
> work on a part of the app would have been
> impractical/impossible/terrifying/costly (delete as appropriate). :-)

Everything operated against a single, shared database.  The database
was setup as a large file, on a fault-tolerant, ramdisk.  It was saved
to disk at the end of day, and loaded into the ramdisk's memory at the
start of the day.  During the day, the line handlers, quote feeds, main
user app for stock traders, all operated against the in-memory file.
At the end of day, reports and other processing, e.g., daylight saving
time, etc, was done against the file on disk.

> Just on C's facilities for hiding information, though, I see your
> comment that you don't recognise a mechanism for it. Could it be
> that you naturally use information hiding in C without thinking
> of it as such?

If the code isn't hidden from me, then I know not only the interface,
but I can read, understand, modify the code too.  I.e., as a maintenance
programmer, or the original author of code, the "no other information"
contraint aspect has been violated for Parnas' Principles.  AISI, his
rules could only apply for a non-programmer user, or a programmer
interfacing with a closed-source module or "black-box".


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2258

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

...

>> Just on C's facilities for hiding information, though, I see your
>> comment that you don't recognise a mechanism for it. Could it be
>> that you naturally use information hiding in C without thinking
>> of it as such?
>
> If the code isn't hidden from me, then I know not only the interface,
> but I can read, understand, modify the code too.  I.e., as a maintenance
> programmer, or the original author of code, the "no other information"
> contraint aspect has been violated for Parnas' Principles.  AISI, his
> rules could only apply for a non-programmer user, or a programmer
> interfacing with a closed-source module or "black-box".

Difficult to know how to respond to that! In no particular order:

I don't see how that answers the question.

I'm no authority but I do not believe the principles are intended to apply 
to users (people) of programs.

You may be looking at the ideas from the wrong end. Rather than considering 
how you can use a program module consider later having to change that same 
module. Explanation follows.... As a potential user (by "user" here I mean 
programmer using the module, not user of a computer) for sure you *could* 
look at its internals and adapt accordingly. In fact, you or others could 
write N modules which used the first based on how it worked internally. But 
then if someone wanted to change the first he would have to examine all N 
programs using the common module to make sure his changes didn't stop those 
other modules working. That could be a great deal of work.

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.

To me, that's what makes the aspect of Parnas' principles that you mentioned 
very important. The "no other information" clause is essential in 
facilitating maintenance. For the record, an expression of the principles is 
copied below.

    The developer of a software component must provide the intended user 
with all the information needed to make effective use of the services 
provided by the component, and should provide no other information.

    The implementor of a software component must be provided with all the 
information necessary to carry out the given responsibilities assigned to 
the component, and should be provided with no other information.

James

[toc] | [prev] | [next] | [standalone]

#2261

On Sat, 17 May 2014 13:00:05 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xfviucge6zenlw@localhost...
>> James wrote:

>>> Just on C's facilities for hiding information, though, I see your
>>> comment that you don't recognise a mechanism for it. Could it be
>>> that you naturally use information hiding in C without thinking
>>> of it as such?
>>
>> If the code isn't hidden from me, then I know not only the interface,
>> but I can read, understand, modify the code too.  I.e., as a maintenance
>> programmer, or the original author of code, the "no other information"
>> contraint aspect has been violated for Parnas' Principles.  AISI, his
>> rules could only apply for a non-programmer user, or a programmer
>> interfacing with a closed-source module or "black-box".
>
> Difficult to know how to respond to that! In no particular order:
>
> I don't see how that answers the question.
>
> I'm no authority but I do not believe the principles are intended to  
> apply to users (people) of programs.

Ok.

> You may be looking at the ideas from the wrong end.

...

> Rather than considering how you can use a program module consider later
> having to change that same module.

If I'm the original author or a maintenance programmer with complete access
to the code and the authority to change it, perhaps dependent upon a code
review, I don't see where having to change a module is a relevant issue.
Changing things is the job of the original author or maintenance  
programmer.

> 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.

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).  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.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2263

"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

[toc] | [prev] | [next] | [standalone]

#2264

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.  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.

> 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.

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.
>

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?

> 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.

But, I'd definately question the sanity of someone breaking apart a
sort routine or search algorithm across multiple modules.

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?
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.

The concept of "information hiding" keep me thinking about what a
coworker said about C++ being layers upon layers of unnecessary
abstractions.

> 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?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2265

"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

[toc] | [prev] | [next] | [standalone]

#2266

On Sun, 18 May 2014 02:59:49 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xf03jult6zenlw@localhost...

>> 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.
>

Lol.  I only posed one question.

The other should've been one of confusion:

JH Q: "WTF does any of this have to do with information hiding? ..."
RP A: "No idea..."

:-)

>> 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.
>

Ok, so, you really see Parnas Principles as being applied after an
efficient or workable solution, and not interfering with one.  Or,
you see them being set aside, temporarily, if they interfere with
changes.

>> [...]
>
> To me that's not information hiding but potentially excessive
> problem subdivision.

This would go to how or when Parnas Principles are applied.
Are they applied during design, during implementation, or only
after the fact?  Basically, I was seeing the X and N modules
as what I believe you're calling "excessive problem subdivision".
I.e., I was viewing them from the perspective that something like
a sort routine was distributed across multiple modules, or maybe
something high throughput, say video, had a very restrictive interface.

> Isn't information hiding more about keeping *data* separate?

I wouldn't know.  I'm only going on what you introduced from the link
and within this conversation.  E.g., you introduced the "interface"
and "module".

> Parnas' Principles and others related to software system construction
> are about helping rather than hindering.

But, there are clearly too many unknowns.  (Or, at least, I don't know  
them.)

When are they applied?  Who is best to apply them?  Are they applied
throughout the design process or only at the end?  Can they be set
aside to make changes?  etc.

> Changing the internals of a module has a cost and some benefits.

Yes.

> Changing an interface has a cost and some benefits.

Yes.

> If the benefits of changing an interface outweigh the cost
> then it's worth doing.

I'm presuming that if the maintenance programmer or original author(s)
decide to change such things, they should know the benefits and have
decided those benefits are worth the change, or they wouldn't bother.

> 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?

Maybe I'm being a bit of a pessimist here ...  This reminds me of both
factoring and bottom-up coding.  I don't like bottom-up coding.  It's
like having all the pieces to a puzzle, but the puzzle isn't solved.
I.e., this attempts to apply rules which I perceive as encapsulating or
capturing all the details without necessarily grasping the big picture,
how the parts interact or connect.  I get the impression that the
principles don't allow things to interact or be modified as needed or
when needed.  As I said before, I tend to believe that strict application
of Parnas Principles, or perhaps mis-application of them, will lead to
overly restrictive interfaces or overly sub-divided modules.

So, I think you have to get to the nature of *why* the information is
being controlled.  E.g., in malloc(), is it being controlled because
the user has no need for it?  Or, was it hidden because they expected
an operating system to provide the functionality most of the time?
I.e., outside the scope of C's domain most of the time.  If it can't
be guaranteed that the internals of malloc() are available on some
platforms, that would be a good reason to hide or restrict them.  If
it can't be guaranteed the internals will be the same for all platforms,
ditto. A function like strtok() is going to be implemented in C everywhere.
So, there is no point to restrict access to it's internals, unless
it's some sort of safety issue or issue with global access, neither
of which I recognize currently.

Personally, I'd think that these would be better principles:
1) do what needs to be done, but no more
2) do it as efficiently as you can


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2267

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xf2fbp056zenlw@localhost...
> On Sun, 18 May 2014 02:59:49 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>> news:op.xf03jult6zenlw@localhost...

...

>>> 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.
>>
>
> Ok, so, you really see Parnas Principles as being applied after an
> efficient or workable solution, and not interfering with one.  Or,
> you see them being set aside, temporarily, if they interfere with
> changes.

Umm, yes and no. Parnas' Principles speak about a "software component" and 
the hiding of information either side of that component's interface. They do 
not suggest how the component should be chosen. A designer is free to divide 
the system up into modules as appropriate so the principles, if applied, do 
not restrict that choice per se. That said, a designer might use them to 
restrict interface sizes as with the malloc example, below.

>>> [...]
>>
>> To me that's not information hiding but potentially excessive
>> problem subdivision.
>
> This would go to how or when Parnas Principles are applied.
> Are they applied during design, during implementation, or only
> after the fact?  Basically, I was seeing the X and N modules
> as what I believe you're calling "excessive problem subdivision".

I'm not sure why you thought that way. I don't think I even suggested it. My 
comment was that the Forth example you gave was excessively subdivided (as 
you yourself said).

The X and the N modules were just algebraic references to a typical 
client-server-type system: one server and N clients. Such schemes are widely 
used.

...

>> 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?
>
> Maybe I'm being a bit of a pessimist here ...  This reminds me of both
> factoring and bottom-up coding.  I don't like bottom-up coding.  It's
> like having all the pieces to a puzzle, but the puzzle isn't solved.
> I.e., this attempts to apply rules which I perceive as encapsulating or
> capturing all the details without necessarily grasping the big picture,
> how the parts interact or connect.  I get the impression that the
> principles don't allow things to interact or be modified as needed or
> when needed.  As I said before, I tend to believe that strict application
> of Parnas Principles, or perhaps mis-application of them, will lead to
> overly restrictive interfaces or overly sub-divided modules.
>
> So, I think you have to get to the nature of *why* the information is
> being controlled.  E.g., in malloc(), is it being controlled because
> the user has no need for it?  Or, was it hidden because they expected
> an operating system to provide the functionality most of the time?
> I.e., outside the scope of C's domain most of the time.  If it can't
> be guaranteed that the internals of malloc() are available on some
> platforms, that would be a good reason to hide or restrict them.  If
> it can't be guaranteed the internals will be the same for all platforms,
> ditto.

Regardless of the reason why, making C programs ignorant of malloc's 
internals and having a narrow interface between app and malloc results in a 
lot of flexibility for both sides. Apps don't have to depend on malloc 
working in a specific way and malloc implementations are not required to 
have to deal with specific app patterns. So the design of malloc is a good 
example of Parnas' Principles being applied. IMO it is a good design. Of 
course, YMMV.

James

[toc] | [prev] | [next] | [standalone]

#2253

On 14/05/14 23:54, James Harris wrote:
> Re. the 5Mloc app I would guess that it had to be divided up somehow - into
> modules or into functions etc. As a result of that, presumably programmers
> could work on parts of the app without having to examine or understand
> (perish the thought!) the rest of the 5M lines.

	5M lines is ~83K sides of A4 printed at 60 lines per side, which
would be a stack some 8m high, or "only" 4m if printed double-sided, the
equivalent of around five shelves of books.  As a matter of practicality,
it's not possible for one person to read, let alone understand, all that
within the context of a live [and presumably evolving] project.  You could
think of it as information "hiding" simply by overwhelming volume!  It
doesn't then matter what facilities the language provides;  the project
*must* divide itself, somehow, into bits that the programmers can pick at
separately.  That may work well or badly, but probably badly, witness the
fact that most large projects are failures [I make no claim that Rod's
particular project is one of these].

	Thus "information hiding" is largely a misnomer.  In a really big
project, the hiding can be in plain sight.  In a tiny project, it doesn't
matter -- one person can easily comprehend the whole thing.  It's in the
in-between levels that it's important;  and the importance then is not
keeping things secret, but facilitating a division of labour.  That may
mean enabling several people to work smoothly together, or it may mean
one person dealing with one aspect today, a different aspect tomorrow,
and not having to remember all the nitty-gritty all the time.

-- 
Andy Walker,
Nottingham.

[toc] | [prev] | [next] | [standalone]

#2254

On 5/14/2014 7:31 PM, Andy Walker wrote:
> On 14/05/14 23:54, James Harris wrote:
>> Re. the 5Mloc app I would guess that it had to be divided up somehow -
>> into
>> modules or into functions etc. As a result of that, presumably
>> programmers
>> could work on parts of the app without having to examine or understand
>> (perish the thought!) the rest of the 5M lines.
>
>      5M lines is ~83K sides of A4 printed at 60 lines per side, which
> would be a stack some 8m high, or "only" 4m if printed double-sided, the
> equivalent of around five shelves of books.  As a matter of practicality,
> it's not possible for one person to read, let alone understand, all that
> within the context of a live [and presumably evolving] project.  You could
> think of it as information "hiding" simply by overwhelming volume!  It
> doesn't then matter what facilities the language provides;  the project
> *must* divide itself, somehow, into bits that the programmers can pick at
> separately.  That may work well or badly, but probably badly, witness the
> fact that most large projects are failures [I make no claim that Rod's
> particular project is one of these].
>
>      Thus "information hiding" is largely a misnomer.  In a really big
> project, the hiding can be in plain sight.  In a tiny project, it doesn't
> matter -- one person can easily comprehend the whole thing.  It's in the
> in-between levels that it's important;  and the importance then is not
> keeping things secret, but facilitating a division of labour.  That may
> mean enabling several people to work smoothly together, or it may mean
> one person dealing with one aspect today, a different aspect tomorrow,
> and not having to remember all the nitty-gritty all the time.
>

I personally prefer the term "abstraction" for this.
as-in, the code is "abstracted" by putting an API over it, then working 
against the behaviors as described for the API calls.

then there is "breaking abstraction" for cases where code either 
sidesteps the API, or does things which rely on behaviors which aren't 
defined as part of the API.


although I believe that mechanism underlies existence (a thing doesn't 
truely exist unless there are working implementations), I rather dislike 
the whole "the code is the specification" approach taken by some 
projects (most often FOSS).

like, seriously, is it *that* hard to both implement something AND 
document its structure and behavior?...

though, to some extent, I suspect the whole "the code is the 
documentation" thing is basically often shorthand for "we copy/pasted 
most of this code from other projects anyways and have little how a lot 
of it actually works".

[toc] | [prev] | [next] | [standalone]

#2260

"James Harris" <james.harris.1@gmail.com> wrote in message 
news:ll0s6v$1mu$1@dont-email.me...

...

> Quite apart from discussing the benefits or liabilities of information 
> hiding it might be worth discussing C's support for info hiding.

Here are some areas where C allows programmers to hide info:

* Functions can (and usually do) have local variables that are inaccessible 
outside the function. (As per another recent reply, this allows someone to 
change the names, values and types of those variables without breaking 
functions that interact with the one being changed. That is a great benefit 
which is not available in other cases such as Python (at least for Python2) 
classes where all named components of a class are always visible and cannot 
be hidden.)

* Blocks can have local variables - similar benefits to functions and also 
the potential for space saving.

* Compilation units (source files) can have local variables when declared 
with "static" keyword. Ditto local functions. Any functions declared that 
way are usable internally but inaccessible to other compilation units.

* Compilation units can have local constants declared (in the same file) 
with #define or enum, while at the same time making other constants public 
by placing them in header files.

* Separate compilation allows object modules to be created once with hidden 
internals and then included in other programs an arbitrary number of times. 
Similar applies to associated mechanisms such as static and dynamic 
libraries.

* Arbitrarily complex structs can be passed around by pointer. As a pointer 
to one struct is always the same size as a pointer to another struct an 
opaque struct can be changed without affecting users of the managing module.

* The ability to convert any pointer to a void * and back again to the same 
type without losing information allows generic pointers to be passed around 
while the type of the pointer remains opaque.

Any others?

James

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.misc

csiph-web