Re: Infinite Loops and Explicit Exits

From: Robert Wagner (spamblocker-robert_at_wagner.net)
Date: 11/16/04 

Date: Tue, 16 Nov 2004 06:05:39 GMT

On 15 Nov 2004 10:53:35 -0800, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <spamblocker-robert@wagner.net> wrote
>
>> >a) Other languages started with a top-down design derived from a
>> >mathematical formula (in C all procedures are functions returning a
>> >value) pushing to think of algorithms as transformation functions;
>> >while COBOL started with a bottom-up approach lifting assembler
>> >programming to an machine-independent form, plus some automation
>> >features (e.g. the underutilized REPORT WRITER);
>
>> It is widely believed that C is 'machine-independent assembly
>> language'
>
>Who by, Robert ? C is a low-level, value-orientated language that can
>be used _instead_ of assembler as a portable language for systems
>programming.
>
>What basis do you have for your belief that your nonsense is 'widely
>believed'. Actually it just suits you to make this up.

"C is a relatively minimalist programming language that operates close
to the hardware, and is more similar to assembly language than most
other programming languages. Indeed, C is sometimes referred to as
"portable assembly,""

http://en.wikipedia.org/wiki/C_programming_language

"Although it is a high-level language, C is much closer to assembly
language than are most other high-level languages. This closeness to
the underlying machine language allows C programmers to write very
efficient code. The low-level nature of C, however, can make the
language difficult to use for some types of applications. "

http://www.webopedia.com/TERM/C/C.html

>> or 'close to the metal'. That's not true. C is no more or
>> less close to the machine than Cobol or other 3GL,
>
>Yes it is. C's built in types are no more nor less than the machine's
>types, there is a direct correspondence on each machine.

>Cobol, especially, has little direct relationship between the data
>types and those of the machine.

COMP-n and POINTER extensions did the same for Cobol.

>In other words, C turned out the way it is because it was changed, as
>required, in order to write Unix, its own compiler, and other system
>software, in C.

Cobol (85) didn't have to be changed to write its own compiler --
Realia.

>> I tend to agree with your point about top-down design, but in the
>> context of programmers rather than the language itself. C became
>> available to the public in the early '70s, about the same time that
>> structured programming was introduced to computer science undergrad
>> curricula. Both had been born in the late '60s, but were not widely
>> known then.
>
>Nonsense. Algol had been around for years in comp.sci. showing how
>structured programming should be done. I have Daniel McCracken's 1962
>book 'A Guide to Algol Programming' right here. It may be that you
>only noticed structured programming around the time that C became
>available.

True. I stand corrected. I didn't pay much attention to academia in
the '60s. I first heard of structured programming from CS graduates in
the '70s.

>> As a result, C programmers had known nothing but structured
>> programming. They did not have to unlearn bad habits developed in the
>> '60s, nor change an existing body of work.
>
>Actually the 'bad habits' developed in the 50s and the programmers
>carried them forward into the new languages which had catered for
>their use.
>
>The 'bad habits' originated in the need for efficiency because the
>machines were so slow and resource limited. Techniques that saved
>cycles and words were more important than those that saved programmer
>time.
>
>'Structured Programming' (and many other mechanisms) was developed in
>the 50s and 60s, as shown by Algol and others, but it was only in the
>70s that machines were large and powerful enough to make it worthwhile
>to apply them to production software.
>
>The balance is the cost of the machine versus the cost of the
>programmer time. In the 50s nearly all the cost was in the hardware so
>programmers had to hand optimise programs to reduce run-times by every
>method available. In the 60s these techniques carried over because
>the workload could only increase by running existing program faster or
>spending millions on a new machine.
>
>In the 70s the cost of machines was coming down and programmer costs
>were increasing so it was necessary to get systems written faster and
>more reliably to save programmer costs. Hence techniques such as
>structured programming which had been around in ivory towers for many
>years were brought into commercial sites.
>
>It is all about balancing the costs.

Well said. I agree with all that except .. past an early point in
hardware evolution, roughly 1965, structured programs ran faster than
unstructured. Bad habits persisted well past their economic
justification. Some are still with us today.

>> I think a more subtle reason lies in PERFORM being the primary
>> dispatch to out-of-line code, rather than CALL. With CALL, it's
>> obvious that the procedure/function is a 'program' worthy of formal
>> parameter checking and its own local variables. That organization
>> lends itself to hierarchy charts, either formal or mental. A PERFORMed
>> paragraph is more easily abused, more easily seen as a fist-full of
>> code thrown out-of-line for convenience.
>
>You seem to research your keyboard for all of this. CALL wasn't
>originally part of the language at all, in fact the interprogram
>communication module, with LINKAGE SECTION, did not become part of the
>standard until '74. ENTER was available to put in-line alien code (ie
>assembler) into the source code, or to incorporate named library
>routines in the linking (called consolidation where I started). In
>the 50s and 60s programs were written as complete units.

CALL and LINKAGE SECTION was in nearly all '68 Cobol compilers. Static
linkers were available since the late '50s (on IBM 70xx), and widely
used for assembly lanaguage and Fortran. Even on punched-card machines
such as IBM 1401, I recall inserting decks of library code, for
instance a file system, into the executable.

>> But other Pascal programmers did not apologize for it by saying
>> 'matter of style' or 'personal preference'. They called it Bad Code.
>
>Did they ? Show actual examples. You just make stuff up.

Does your library include Dr. Dobb's from the early '80s?

Relevant Pages

  • Re: object system...
    ... for that you need machine language. ... isn't even as fast as other systems programming languages. ... Stroustrup's stated design goal was to enable ... all manner of elegance or abstraction can be sacrificed for speed, ...
    (comp.object)
  • Re: DirectX in HLA
    ... I guess that you have a great knowledge of DirectX ... > understanding by looking at them in assembly language... ... > actually represents, really, is a means to "undo" the OOP so ... > is NOT an "OOPL" (object-orientated programming language), ...
    (comp.lang.asm.x86)
  • Re: DirectX in HLA
    ... I guess that you have a great knowledge of DirectX ... > understanding by looking at them in assembly language... ... > actually represents, really, is a means to "undo" the OOP so ... > is NOT an "OOPL" (object-orientated programming language), ...
    (alt.lang.asm)
  • Re: LSP and subtype
    ... What is the class of problems solvable using UML? ... the language of physics cannot describe. ... whatever paradigm equivalent to 2GL/3GL ... there is still a great need for reuse and generic programming. ...
    (comp.object)
  • Re: Why C Is Not My Favourite Programming Language
    ... If you decide afterall that C programming is just not your thing you ... > C has no string type. ... > compiler take care of the rest. ... Why does any normal language ...
    (comp.lang.c)