Home > Archive > Cobol > February 2006 > Structured Coding
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| apple.time@yahoo.com 2006-02-02, 6:55 pm |
| I am working on a system that has really ancient code (15 years). This
was before the time of sturctured code. Can someone tell me the
reasons why structured coding is BETTER?
| |
| Frederico Fonseca 2006-02-02, 6:55 pm |
| On 2 Feb 2006 14:35:50 -0800, "apple.time@yahoo.com"
<apple.time@yahoo.com> wrote:
>I am working on a system that has really ancient code (15 years). This
>was before the time of sturctured code. Can someone tell me the
>reasons why structured coding is BETTER?
humm...
looks like homework, and smells like homework.
as such.... please do your homework and search before asking
questions.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
| apple.time@yahoo.com 2006-02-02, 6:55 pm |
| I have tried to find this out! But when I get the the real answer, I
have to pay to get it! This is not for school, but for my employer...
| |
| Ian Dalziel 2006-02-02, 6:55 pm |
| On Thu, 02 Feb 2006 22:47:59 +0000, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:
>On 2 Feb 2006 14:35:50 -0800, "apple.time@yahoo.com"
><apple.time@yahoo.com> wrote:
>
>humm...
>looks like homework, and smells like homework.
>as such.... please do your homework and search before asking
>questions.
>
15 years ago was before the time of structured code...
I can see at least one mark being lost before we start here.
--
Ian
| |
| Michael Mattias 2006-02-02, 6:55 pm |
| <apple.time@yahoo.com> wrote in message
news:1138919750.009976.189420@f14g2000cwb.googlegroups.com...
> I am working on a system that has really ancient code (15 years). This
> was before the time of sturctured code. Can someone tell me the
> reasons why structured coding is BETTER?
You have to do something with this code, don't you?
And this spaghetti looks like a real pain in the butt to work with, right?
And it's going to take you many, many hours, which may be translated to
many, many dollars, right?
Now do you understand why structured is better?
MCM
| |
| The Grue - James T. Sprinkle 2006-02-02, 6:55 pm |
|
<apple.time@yahoo.com> wrote in message
news:1138919750.009976.189420@f14g2000cwb.googlegroups.com...
> I am working on a system that has really ancient code (15 years). This
> was before the time of sturctured code. Can someone tell me the
> reasons why structured coding is BETTER?
>
You have 20 years of cobol experience (see cobol code assessment post) and
you call 15 year old code ancient? And you don't know the answer to this
elementary question? Shocking!
The Grue
| |
| apple.time@yahoo.com 2006-02-02, 6:55 pm |
| My head is full of stuff... but I cannot find a bulleted list of why
structured code is better. I personally believe it is better, but I
want to document the many ways for my code assessment, to have evidence
on why the 15 year old code is needing to be retired. Any help would
be appreciated! (two heads are ALWAYS better than one! aren't they?)
| |
| Peter Lacey 2006-02-02, 6:55 pm |
| "apple.time@yahoo.com" wrote:
>
> I am working on a system that has really ancient code (15 years). This
> was before the time of sturctured code. Can someone tell me the
> reasons why structured coding is BETTER?
The least controversial answer is that "structured" coding was done in
accordance with a well-defined set of principles to analyze the problem
before any coding was done. If the principles were followed then it was
possible to write the program in logical chunks, going from the topmost,
least specific level - in essence the driver loop - through increasingly
detailed decision-making parts, right down to the lowest level where
things were actually done. All the issues were (in principle) resolved
before any coding was done so the actual coding was a breeze, and
testing turned up fee surprises. If such principles weren't followed,
the usual result was that the programmer kept remembering or discovering
things that needed to be done as s/he went along, and plugged them in
anywhere in the program. Thus the logical flow & the relationship
between the various levels was obscured. Thus there were lots of things
to resolve before the progam went into production, and likely lots of
ongoing error-correction would be needed.
What this really amounts to is that if the program is properly planned
it'll be easy to write and to follow for TPB (the maintenance
programmer). There were a number of approaches to this: structured
analysis, top down, functional decomposition if you really want to be
posh.
(Now a bit of controversy).
There has been an enormous amount of blather since structured
programming was first written about concerning the GOTO statement. It's
been blamed for all the ills that programming is heir to. There are
people, in fact, who define "Structured" programming as "GOTO-less"
programming. That's nonsense. Poor program design is the fault in all
cases, not the use of particular verbs or constructs. It is true that
if you don't use GOTO's, you'll be forced to think about the program and
plan it (perhaps) better, because you can't write it the easy way. But
a GOOD programmer can write programs with and without GOTO's and will
produce equal quality work either way.
(End of controversy. My example follows).
If your 15-year-old code contains GOTO's, don't worry too much about it:
if the programs are hard to follow and maintain it's because they are
badly written, not that they contain GOTO's. I presented to this group
two examples of my own - 100 programs, 65,000 lines or so, using GOTO's;
the system has now been running since 1996, with only spec changes or
data problems afflicting it; it survived Y2K with no changes needed and
will be going for some years yet. Another similar system was taken over
by the customer and the only problem they had was that I hadn't given
them the copy books. (This one was superseded by SAP). I asked the
group how the situation could be bettered: a stony silence, zero
responses, occurred.
(End of example).
If you are having to cope with a bunch of poorly written programs, about
all you can do is document the file specs, make up cross-references, and
make notes about everything!
PL
| |
| epc8@juno.com 2006-02-02, 6:55 pm |
| apple.time@yahoo.com wrote:
> My head is full of stuff... but I cannot find a bulleted list of why
> structured code is better. I personally believe it is better, but I
> want to document the many ways for my code assessment, to have evidence
> on why the 15 year old code is needing to be retired. Any help would
> be appreciated! (two heads are ALWAYS better than one! aren't they?)
Maybe "Structured Cobol Methods" by Noll might help? I no longer have
the book on my shelf, but I believe that it had an introduction which
explained the principles involved. It then went on to develop an
application using these principles. I believe that this was acutally a
variation of what as a Pascal programmer I would call "Top - Down
structured programming." But this was a long time ago in a galaxy far
away....
-- Elliot
| |
| Chuck Stevens 2006-02-02, 6:55 pm |
| "Ian Dalziel" <iandalziel@lineone.net> wrote in message
news:hg35u1dh9iug5k1oja69a9knbadh0sl5i3@
4ax.com...
> On Thu, 02 Feb 2006 22:47:59 +0000, Frederico Fonseca
> <real-email-in-msg-spam@email.com> wrote:
>
>
> 15 years ago was before the time of structured code...
>
> I can see at least one mark being lost before we start here.
> --
>
> Ian
Nah, I don't think so. I remember the concepts being widely discussed as
applicable to COBOL programming before 1978. I wrote my first COBOL
program that was specifically designed to embody those principles as I
understood them right around then. Maybe nobody *you* ran around with
around 1990 and before had heard of Structured Programming, but I certainly
knew the term and the associated principles some thirteen years before that!
....
-Chuck Stevens
| |
| Ian Dalziel 2006-02-02, 6:55 pm |
| On Thu, 2 Feb 2006 16:10:23 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>"Ian Dalziel" <iandalziel@lineone.net> wrote in message
> news:hg35u1dh9iug5k1oja69a9knbadh0sl5i3@
4ax.com...
>
>Nah, I don't think so. I remember the concepts being widely discussed as
>applicable to COBOL programming before 1978. I wrote my first COBOL
>program that was specifically designed to embody those principles as I
>understood them right around then. Maybe nobody *you* ran around with
>around 1990 and before had heard of Structured Programming, but I certainly
>knew the term and the associated principles some thirteen years before that!
>...
>
Try re-reading the thread? The OP said "really ancient code (15
years). This was before the time of structured code."
OF COURSE it was in use way before then. Michael Jackson's book was
published in 1975. I was using broadly similar principles - top down
structure, not data-related structure - in COBOL by about 1974.
Sheesh...
--
Ian
| |
| Frank Swarbrick 2006-02-02, 9:55 pm |
| Hmm, 1991 was definitely *not* "before the time of sturctured code". I
learned about structured coding when was was in junior high school in 1982
or so. This was using Pascal. I'm not even sure if Pascal has a goto
statement! (No, just kidding, I'm sure it does. We were just told to not
use it.)
[color=darkred]
I am working on a system that has really ancient code (15 years). This
was before the time of sturctured code. Can someone tell me the
reasons why structured coding is BETTER?
| |
|
| In article <1138919750.009976.189420@f14g2000cwb.googlegroups.com>,
apple.time@yahoo.com <apple.time@yahoo.com> wrote:
>I am working on a system that has really ancient code (15 years).
Fifteen years ago... that was after the ANSI '74 Standard, right?
>This
>was before the time of sturctured code.
This is something that Dijkstra would be surprised to learn.
>Can someone tell me the
>reasons why structured coding is BETTER?
I'm sure someone can.
DD
| |
|
| In article <1138921006.560382.140020@z14g2000cwz.googlegroups.com>,
apple.time@yahoo.com <apple.time@yahoo.com> wrote:
>I have tried to find this out!
Where?
>But when I get the the real answer, I
>have to pay to get it!
Sometimes tuition-fees are required, sure.
>This is not for school, but for my employer...
Either you are qualified for the job for which your employer hired you or
you are not.
DD
| |
|
| apple.time@yahoo.com wrote:
> I am working on a system that has really ancient code (15 years). This=
> was before the time of sturctured code. Can someone tell me the
> reasons why structured coding is BETTER?
>=20
You are only _off_ by about 23 years! It took me more time to WRITE=20
this than it did to do the searches that resulted in the references=20
below. In the future, you really should make some attempt at finding=20
answers without having others do it for you.
The early concepts of structured programming go back to work by Edsger=20
Dijkstra in 1968 "Go To Statement Considered Harmful". This evolved=20
into the idea of formal verification and a "mathematical proof of=20
correctness" could be developed for any program using a fixed set of=20
constructs. In the 1970s, Harlan Mills, also a key figure in this area, =
headed IBM research project on "Clean room development" that resulted=20
in an IBM product, COBOL Structuring Facility, [interestingly enough,=20
written in PL/I] that takes spaghetti COBOL code and turns it into 100%=20
structured code. Unfortunately, the product [5696-737] has been=20
withdrawn from marketing, but you can locate documentation that will=20
help you here:
> http://publibz.boulder.ibm.com/cgi-...helves/ECFSH003
Any reasonable answer to your question would require one or more of the=20
dozens [or maybe hundreds?] of _books_ that have been written on this=20
subject. As a start on some of these you can go to:
> http://en.wikipedia.org/wiki/Edsger_Dijkstra
There you will see references such as:
> "Go To Statement Considered Harmful", Communications of the ACM, Vol. 1=
1 (1968) 147=96148; online edition (EWD215)
And, you can go to:
> http://en.wikipedia.org/wiki/Harlan_Mills
for more information Harlan Mills, including the following reference:
> Linger and Witt (1979), Structured Programming: Theory and=20
Practice, presents Mills' function-theoretic approach to program=20
verification
Carl
[Been there; done that for over 44 years...]
| |
| Howard Brazee 2006-02-08, 8:52 am |
| On Thu, 2 Feb 2006 18:11:46 -0700, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:
>Hmm, 1991 was definitely *not* "before the time of sturctured code". I
>learned about structured coding when was was in junior high school in 1982
>or so. This was using Pascal. I'm not even sure if Pascal has a goto
>statement! (No, just kidding, I'm sure it does. We were just told to not
>use it.)
True enough. But 2006 isn't the time after spaghetti code,
unfortunately.
| |
| SkippyPB 2006-02-08, 8:52 am |
| On Thu, 2 Feb 2006 16:10:23 -0800, "Chuck Stevens"
<charles.stevens@unisys.com> enlightened us:
>"Ian Dalziel" <iandalziel@lineone.net> wrote in message
> news:hg35u1dh9iug5k1oja69a9knbadh0sl5i3@
4ax.com...
>
>Nah, I don't think so. I remember the concepts being widely discussed as
>applicable to COBOL programming before 1978. I wrote my first COBOL
>program that was specifically designed to embody those principles as I
>understood them right around then. Maybe nobody *you* ran around with
>around 1990 and before had heard of Structured Programming, but I certainly
>knew the term and the associated principles some thirteen years before that!
>...
>
> -Chuck Stevens
>
I was in college in the mid 70's and part of our COBOL courses was an
introduction to structured programming. It is probably more than 30
years old.
Regards,
////
(o o)
-oOO--(_)--OOo-
WOODY: "How's it going Mr. Peterson?"
NORM: "It's a dog eat dog world, Woody and I'm wearing Milk Bone underwear."
From the TV Series Cheers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
| |
| Pat Hall 2006-02-08, 8:52 am |
| epc8@juno.com wrote:
> apple.time@yahoo.com wrote:
>
>
>
> Maybe "Structured Cobol Methods" by Noll might help? I no longer have
> the book on my shelf, but I believe that it had an introduction which
> explained the principles involved. It then went on to develop an
> application using these principles. I believe that this was acutally a
> variation of what as a Pascal programmer I would call "Top - Down
> structured programming." But this was a long time ago in a galaxy far
> away....
>
> -- Elliot
>
I have Structured Programming for the COBOL Programmer by Noll pub date
1977. Also Structured ANS COBOL part 1 and 2 by Noll pub in 1979.
Haven't looked at them lately though. Maybe I should is there a future
in spaghetti to structured conversion? LOL
PatH
| |
| void * clvrmnky() 2006-02-08, 8:52 am |
| On 02/02/2006 5:35 PM, apple.time@yahoo.com wrote:
> I am working on a system that has really ancient code (15 years). This
> was before the time of sturctured code. Can someone tell me the
> reasons why structured coding is BETTER?
>
Obviously, you haven't made a living by maintaining legacy code. I like
my pasta on my plate, not in my code libraries.
<http://www.google.com/search?hl=en&q=%22structured+code>
-- Clever "USENET Considered Harmful" Monkey
| |
| Alistair 2006-02-08, 8:52 am |
|
apple.time@yahoo.com wrote:
> My head is full of stuff... but I cannot find a bulleted list of why
> structured code is better. I personally believe it is better, but I
> want to document the many ways for my code assessment, to have evidence
> on why the 15 year old code is needing to be retired. Any help would
> be appreciated! (two heads are ALWAYS better than one! aren't they?)
Structured code is pretty code. Pretty code is easier to maintain and
cheaper to maintain.
| |
| Alistair 2006-02-08, 8:52 am |
|
CG wrote:
> apple.time@yahoo.com wrote:
In the 1970s, Harlan Mills, also a key figure in this area,
> headed IBM research project on "Clean room development" that resulted
> in an IBM product, COBOL Structuring Facility, [interestingly enough,
> written in PL/I] that takes spaghetti COBOL code and turns it into 100%
> structured code. Unfortunately, the product [5696-737] has been
> withdrawn from marketing, but you can locate documentation that will
> help you here:
>
I once passed a program to IBM to use CSF on as a restructuring
exercise.
The resulting program was one which, if I had seen a trainee programmer
write it, would have been binned. I understand that CSF is driven by
parameters defining the required result so I expect that what I saw was
not the best possible result.
| |
| Gerry Palmer 2006-02-08, 8:52 am |
| On Thu, 02 Feb 2006 18:00:04 -0600, Peter Lacey <lacey@mts.net> wrote:
>There has been an enormous amount of blather since structured
>programming was first written about concerning the GOTO statement. It's
>been blamed for all the ills that programming is heir to. There are
>people, in fact, who define "Structured" programming as "GOTO-less"
>programming.
I recall reading a tongue-in-ch article in the early 70s (in
Computerworld, perhaps?) that proposed an elegant remedy to the then
current "no GO TOs allowed" dictums. The author suggested a minor
compiler change that would instead support the "COME FROM" construct.
| |
| SkippyPB 2006-02-08, 8:52 am |
| On 4 Feb 2006 06:23:50 -0800, "Alistair"
<alistair@ld50macca.demon.co.uk> enlightened us:
>
>apple.time@yahoo.com wrote:
>
>Structured code is pretty code. Pretty code is easier to maintain and
>cheaper to maintain.
Not necessarily. I've seen structured code that just gave me a
headache trying to follow. Perform this which performs this which
performs this which performs this which performs this ad nauseam. When
you're trying to track where a field is getting corrupted or trying to
find a place to apply some new logic, this kind of structure is just
frustrating.
Regards,
////
(o o)
-oOO--(_)--OOo-
WOODY: "How's it going Mr. Peterson?"
NORM: "It's a dog eat dog world, Woody and I'm wearing Milk Bone underwear."
From the TV Series Cheers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
| |
| Donald Tees 2006-02-08, 8:52 am |
| Alistair wrote:
> apple.time@yahoo.com wrote:
>
>
>
> Structured code is pretty code. Pretty code is easier to maintain and
> cheaper to maintain.
>
Real Programmers Don't Use Pascal
[ A letter to the editor of Datamation, volume 29 number 7, July 1983.
I've long ago lost my dog-eared photocopy, but I believe this was
written (and is copyright) by Ed Post, Graphic Software Systems,
Wilsonville OR USA.
The story of Mel is a related article. ]
Back in the good old days-- the "Golden Era" of computers-- it was easy
to separate the men from the boys (sometimes called "Real Men" and
"Quiche Eaters" in the literature). During this period, the Real Men
were the ones who understood computer programming, and the Quiche Eaters
were the ones who didn't. A real computer programmer said things like
"DO 10 I=1,10" and "ABEND" (they actually talked in capital letters, you
understand), and the rest of the world said things like "computers are
too complicated for me" and "I can't relate to computers-- they're so
impersonal". (A previous work [1] points out that Real Men don't
"relate" to anything, and aren't afraid of being impersonal.)
But, as usual, times change. We are faced today with a world in which
little old ladies can get computers in their microwave ovens, 12 year
old kids can blow Real Men out of the water playing Asteroids and
Pac-Man, and anyone can buy and even understand their very own personal
Computer. The Real Programmer is in danger of becoming extinct, of being
replaced by high school students with TRASH-80s.
There is a clear need to point out the differences between the typical
high school junior Pac-Man player and a Real Programmer. If this
difference is made clear, it will give these kids something to aspire
to-- a role model, a Father Figure. It will also help explain to the
employers of Real Programmers why it would be a mistake to replace the
Real Programmers on their staff with 12 year old Pac-Man players (at a
considerable salary savings).
The easiest way to tell a Real Programmer from the crowd is by the
programming language he (or she) uses. Real Programmers use Fortran.
Quiche Eaters use Pascal. Nicklaus Wirth, the designer of Pascal, gave a
talk once at which he was asked, "How do you pronounce your name?". He
replied, "You can either call me by name, pronouncing it 'Veert', or
call me by value, 'Worth'." One can tell immediately by this comment
that Nicklaus Wirth is a Quiche Eater. The only parameter passing
mechanism endorsed by Real Programmers is call-by-value-return, as
implemented in the IBM/370 Fortran G and H compilers. Real Programmers
don't need all these abstract concepts to get their jobs done-- they are
perfectly happy with a keypunch, a Fortran IV compiler, and a beer.
Real Programmers do List Processing in Fortran.
Real Programmers do String Manipulation in Fortran.
Real Programmers do Accounting (if they do it at all) in Fortran.
Real Programmers do Artificial Intelligence programs in Fortran.
If you can't do it in Fortran, do it in assembly language. If you can't
do it in assembly language, it isn't worth doing.
The academics in computer science have gotten into the "structured
programming" rut over the past several years. They claim that programs
are more easily understood if the programmer uses some special language
constructs and techniques. They don't all agree on exactly which
constructs, of course, and the example they use to show their particular
point of view invariably fit on a single page of some obscure journal or
another-- clearly not enough of an example to convince anyone. When I
got out of school, I thought I was the best programmer in the world. I
could write an unbeatable tic-tac-toe program, use five different
computer languages, and create 1000 line programs that WORKED (Really!).
Then I got out into the Real World. My first task in the Real World was
to read and understand a 200,000 line Fortran program, then speed it up
by a factor of two. Any Real Programmer will tell you that all the
Structured Coding in the world won't help you solve a problem like
that-- it takes actual talent. Some quick observations on Real
Programmers and Structured Programming:
Real Programmers aren't afraid to use GOTOs.
Real Programmers can write five page long DO loops without getting  .
Real Programmers like Arithmetic IF statements-- they make the code more
interesting.
Real Programmers write self-modifying code, especially if they can save
20 nanoseconds in the middle of a tight loop.
Real Programmers don't need comments-- the code is obvious.
Since Fortran doesn't have a structured IF, REPEAT ... UNTIL, or CASE
statement, Real Programmers don't have to worry about not using them.
Besides, they can be simulated when necessary using assigned GOTOs.
Data structures have also gotten a lot of press lately. Abstract Data
Types, Structures, Pointers, Lists, and Strings have become popular in
certain circles. Wirth (the above mentioned Quiche Eater) actually wrote
an entire book [2] contending that you could write a program based on
data structures, instead of the other way around. As all Real
Programmers know, the only useful data structure is the Array. Strings,
Lists, Structures, Sets-- these are all special cases of arrays and can
be treated that way just as easily without messing up your programming
language with all sorts of complications. The worst thing about fancy
data types is that you have to declare them, and Real Programming
Languages, as we all know, have implicit typing based on the first
letter of the (six character) variable name.
What kind of operating system is used by a Real Programmer? CP/M? God
forbid-- CP/M, after all, is basically a toy operating system. Even
little old ladies and grade school students can understand and use CP/M.
Unix is a lot more complicated of course-- the typical Unix hacker never
can remember what the PRINT command is called this w-- but when it
gets right down to it, Unix is a glorified video game. People don't do
Serious Work on Unix systems: they send jokes around the world on
UUCP-net and write Adventure games and research papers.
No, your Real Programmer uses OS/370. A good programmer can find and
understand the description of the IJK305I error he just got in his JCL
manual. A great programmer can write JCL without referring to the manual
at all. A truly outstanding programmer can find bugs buried in a 6
megabyte core dump without using a hex calculator. (I have actually seen
this done.)
OS is a truly remarkable operating system. It's possible to destroy days
of work with a single misplaced space, so alertness in the programming
staff is encouraged. The best way to approach the system is through a
keypunch. Some people claim there is a Time Sharing system that runs on
OS/370, but after careful study I have come to the conclusion that they
were mistaken.
What kind of tools does a Real Programmer use? In theory, a Real
Programmer could run his programs by keying them into the front panel of
the computer. Back in the days when computers had front panels, this was
actually done occasionally. Your typical Real Programmer knew the entire
bootstrap loader by memory in hex, and toggled it in whenever it got
destroyed by his program. (Back then, memory was memory-- it didn't go
away when the power went off. Today, memory either forgets things when
you don't want it to, or remembers things long after they're better
forgotten.) Legend has it that Seymore Cray, inventor of the Cray I
supercomputer and most of Control Data's computers, actually toggled the
first operating system for the CDC7600 in on the front panel from memory
when it was first powered on. Seymore, needless to say, is a Real
Programmer.
One of my favorite Real Programmers was a systems programmer for Texas
Instruments. One day, he got a long distance call from a user whose
system had crashed in the middle of saving some important work. Jim was
able to repair the damage over the phone, getting the user to toggle in
disk I/O instructions at the front panel, repairing system tables in
hex, reading register contents back over the phone. The moral of this
story: while a Real Programmer usually includes a keypunch and line
printer in his toolkit, he can get along with just a front panel and a
telephone in emergencies.
In some companies, text editing no longer consists of ten engineers
standing in line to use an 029 keypunch. In fact, the building I work in
doesn't contain a single keypunch. The Real Programmer in this situation
has to do his work with a "text editor" program. Most systems supply
several text editors to select from, and the Real Programmer must be
careful to pick one that reflects his personal style. Many people
believe that the best text editors in the world were written at Xerox
Palo Alto Research Center for use on their Alto and Dorado computers[3].
Unfortunately, no Real Programmer would ever use a computer whose
operating system is called SmallTalk, and would certainly not talk to
the computer with a mouse.
Some of the concepts in these Xerox editors have been incorporated into
editors running on more reasonably named operating systems-- EMACS and
VI being two. The problem with these editors is that Real Programmers
consider "what you see is what you get" to be just as bad a concept in
Text Editors as it is in Women. No, the Real Programmer wants a "you
asked for it, you got it" text editor-- complicated, cryptic, powerful,
unforgiving, dangerous. TECO, to be precise.
It has been observed that a TECO command sequence more closely resembles
transmission line noise than readable text[4]. One of the more
entertaining games to play with TECO is to type your name in as a
command line and try to guess what it does. Just about any possible
typing error while talking with TECO will probably destroy your program,
or even worse-- introduce subtle and mysterious bugs in a once working
subroutine.
For this reason, Real Programmers are reluctant to actually edit a
program that is close to working. They find it much easier to just patch
the binary object code directly, using a wonderful program called
SUPERZAP (or its equivalent on non-IBM machines). This works so well
that many working programs on IBM systems bear no relation to the
original Fortran code. In many cases, the original source code is no
longer available. When it comes time to fix a program like this, no
manager would even think of sending anything less than a Real Programmer
to do the job-- no Quiche Eating structured programmer would even know
where to start. This is called "job security".
Some programming tools NOT used by Real Programmers:
Fortran preprocessors like MORTRAN and RATFOR. The Cuisinarts of
programming-- great for making Quiche. See comments above on structured
programming.
Source language debuggers. Real Programmers can read core dumps.
Compilers with array bounds checking. They stifle creativity, destroy
most of the interesting uses for EQUIVALENCE, and make it impossible to
modify the operating system code with negative subscripts. Worst of all,
bounds checking is inefficient.
Source code maintenance systems. A Real Programmer keeps his code locked
up in a card file, because it implies that its owner cannot leave his
important programs unguarded [5].
Where does the typical Real Programmer work? What kind of programs are
worthy of the efforts of so talented an individual? You can be sure that
no Real Programmer would be caught dead writing accounts-receivable
programs in COBOL, or sorting mailing lists for People magazine. A Real
Programmer wants tasks of earth-shaking importance (literally!).
Real Programmers work for Los Alamos National Laboratory, writing atomic
bomb simulations to run on Cray I supercomputers.
Real Programmers work for the National Security Agency, decoding Russian
transmissions.
It was largely due to the efforts of thousands of Real Programmers
working for NASA that our boys got to the moon and back before the Russkies.
The computers in the Space Shuttle were programmed by Real Programmers.
Real Programmers are at work for Boeing designing the operation systems
for cruise missiles.
Some of the most awesome Real Programmers of all work at the Jet
Propulsion Laboratory in California. Many of them know the entire
operating system of the Pioneer and Voyager spacecraft by heart. With a
combination of large ground-based Fortran programs and small
spacecraft-based assembly language programs, they are able to do
incredible feats of navigation and improvisation-- hitting ten-kilometer
wide windows at Saturn after six years in space, repairing or bypassing
damaged sensor platforms, radios, and batteries. Allegedly, one Real
Programmer managed to tuck a pattern matching program into a few hundred
bytes of unused memory in a Voyager spacecraft that searched for,
located, and photographed a new moon of Jupiter.
The current plan for the Galileo spacecraft is to use a gravity assist
trajectory past Mars on the way to Jupiter. This trajectory passes
within 80 +/- 3 kilometers of the surface of Mars. Nobody is going to
trust a Pascal program (or Pascal programmer) for navigation to these
tolerances.
As you can tell, many of the world's Real Programmers work for the U.S.
Government-- mainly the Defense Department. This is as it should be.
Recently, however, a black cloud has formed on the Real Programmer
horizon. It seems that some highly placed Quiche Eaters at the Defense
Department decided that all Defense programs should be written in some
grand unified language called "ADA" ((C), DoD). For a while, it seemed
that ADA was destined to become a language that went against all the
precepts of Real Programming-- a language with structure, a language
with data types, strong typing, and semicolons. In short, a language
designed to cripple the creativity of the typical Real Programmer.
Fortunately, the language adopted by DoD had enough interesting features
to make it approachable-- it's incredibly complex, includes methods for
messing with the operating system and rearranging memory, and Edsger
Dijkstra doesn't like it [6]. (Dijkstra, as I'm sure you know, was the
author of "GOTOs Considered Harmful"-- a landmark work in programming
methodology, applauded by Pascal Programmers and Quiche Eaters alike.)
Besides, the determined Real Programmer can write Fortran programs in
any language.
The Real Programmer might compromise his principles and work on
something slightly more trivial than the destruction of life as we know
it. Providing there's enough money in it. There are several Real
Programmers building video games at Atari, for example. (But not playing
them-- a Real Programmer knows how to beat the machine every time: no
challenge in that.) Everyone working at LucasFilm is a Real Programmer.
(It would be crazy to turn down the money of fifty million Star Trek
fans.) The proportion of Real Programmers in Computer Graphics is
somewhat lower than the norm, mostly because nobody has found a use for
Computer Graphics yet. On the other hand, all Computer Graphics is done
in Fortran, so there are a fair number of people doing Graphics in order
to avoid having to write COBOL programs.
Generally, the Real Programmer plays the same way he works-- with
computers. He is constantly amazed that his employer actually pays him
to do what he would be doing for fun anyway (although he is careful not
to express this opinion out loud). Occasionally, the Real Programmer
does step out of the office for a breath of fresh air and a beer or two.
Some tips on recognizing Real Programmers away from the computer room:
At a party, the Real Programmers are the ones in the corner talking
about operating system security and how to get around it.
At a football game, the Real Programmer is the one comparing the plays
against his simulations printed on 11 by 14 fanfold paper.
At the beach, the Real Programmer is the one drawing flowcharts in the sand.
At a funeral, the Real Programmer is the one saying "Poor George. And he
almost had the sort routine working before the coronary."
In a grocery store, the Real Programmer is the one who insists on
running the cans past the laser checkout scanner himself, because he
never could trust keypunch operators to get it right the first time.
What sort of environment does the Real Programmer function best in? This
is an important question for the managers of Real Programmers.
Considering the amount of money it costs to keep one on the staff, it's
best to put him (or her) in an environment where he can get his work done.
The typical Real Programmer lives in front of a computer terminal.
Surrounding this terminal are:
Listings of all programs the Real Programmer has ever worked on, piled
in roughly chronological order on every flat surface in the office.
Some half-dozen or so partly filled cups of cold coffee. Occasionally,
there will be cigarette butts floating in the coffee. In some cases, the
cups will contain Orange Crush.
Unless he is very good, there will be copies of the OS JCL manual and
the Principles of Operation open to some particularly interesting pages.
Taped to the wall is a line-printer Snoopy calendar for the year 1969.
Strewn about the floor are several wrappers for peanut butter filled
cheese bars-- the type that are made pre-stale at the bakery so they
can't get any worse while waiting in the vending machine.
Hiding in the top left-hand drawer of the desk is a stash of
double-stuff Oreos for special occasions.
Underneath the Oreos is a flow-charting template, left there by the
previous occupant of the office. (Real Programmers write programs, not
documentation. Leave that to the maintenence people.)
The Real Programmer is capable of working 30, 40, even 50 hours at a
stretch, under intense pressure. In fact, he prefers it that way. Bad
response time doesn't bother the Real Programmer-- it gives him a chance
to catch a little sleep between compiles. If there is not enough
schedule pressure on the Real Programmer, he tends to make things more
challenging by working on some small but interesting part of the problem
for the first nine ws, then finishing the rest in the last w, in
two or three 50-hour marathons. This not only impresses the hell out of
his manager, who was despairing of ever getting the project done on
time, but creates a convenient excuse for not doing the documentation.
In general:
No Real Programmer works 9 to 5. (Unless it's the ones at night.)
Real Programmers don't wear neckties.
Real Programmers don't wear high heeled shoes.
Real Programmers arrive at work in time for lunch.
A Real Programmer might or might not know his wife's name. He does,
however, know the entire ASCII (or EBCDIC) code table.
Real Programmers don't know how to cook. Grocery stores aren't open at
three in the morning. Real Programmers survive on Twinkies and coffee.
What of the future? It is a matter of some concern to Real Programmers
that the latest generation of computer programmers are not being brought
up with the same outlook on life as their elders. Many of them have
never seen a computer with a front panel. Hardly anyone graduating from
school these days can do hex arithmetic without a calculator. College
graduates these days are soft-- protected from the realities of
programming by source level debuggers, text editors that count
parentheses, and "user friendly" operating systems. Worst of all, some
of these alleged "computer scientists" manage to get degrees without
ever learning Fortran! Are we destined to become an industry of Unix
hackers and Pascal programmers?
From my experience, I can only report that the future is bright for Real
Programmers everywhere. Neither OS/370 nor Fortran show any signs of
dying out, despite all the efforts of Pas- cal programmers the world
over. Even more subtle tricks, like adding structured coding constructs
to Fortran, have failed. Oh sure, some computer vendors have come out
with Fortran 77 compilers, but every one of them has a way of converting
itself back into a Fortran 66 compiler at the drop of an option card--
to compile DO loops like God meant them to be.
Even Unix might not be as bad on Real Programmers as it once was. The
latest release of Unix has the potential of an operating system worthy
of any Real Programmer-- two different and subtly incompatible user
interfaces, an arcane and complicated teletype driver, virtual memory.
If you ignore the fact that it's "structured", even 'C' programming can
be appreciated by the Real Programmer: after all, there's no type
checking, variable names are seven (ten? eight?) characters long, and
the added bonus of the Pointer data type is thrown in-- like having the
best parts of Fortran and assembly language in one place. (Not to
mention some of the more creative uses for #define.)
No, the future isn't all that bad. Why, in the past few years, the
popular press has even commented on the bright new crop of computer
nerds and hackers ([7] and [8]) leaving places like Stanford and MIT for
the Real World. From all evidence, the spirit of Real Programming lives
on in these young men and women. As long as there are ill-defined goals,
bizarre bugs, and unrealistic schedules, there will be Real Programmers
willing to jump in and Solve The Problem, saving the documentation for
later. Long live Fortran!
References:
[1] Feirstein, B., "Real Men don't Eat Quiche", New York, Pocket Books,
1982.
[2] Wirth, N., "Algorithms + Data Structures = Programs", Prentice Hall,
1976.
[3] Ilson, R., "Recent Research in Text Processing", IEEE Trans. Prof.
Commun., Vol. PC-23, No. 4, Dec. 4, 1980.
[4] Finseth, C., "Theory and Practice of Text Editors - or - a Cookbook
for an EMACS", B.S. Thesis, MIT/LCS/TM-165, Massachusetts Institute of
Technology, May 1980.
[5] Weinberg, G., "The Psychology of Computer Programming", New York,
Van Nostrand Reinhold, 1971, p. 110.
[6] Dijkstra, E., "On the GREEN language submitted to the DoD", Sigplan
notices, Vol. 3, No. 10, Oct 1978.
[7] Rose, Frank, "Joy of Hacking", Science 82, Vol. 3, No. 9, Nov 82,
pp. 58-66.
[8] "The Hacker Papers", Psychology Today, August 1980.
Webbed by Greg Lindahl (lindahl@pbm.com)
| |
| Arnold Trembley 2006-02-08, 8:52 am |
|
Alistair wrote:
> CG wrote:
>
>
> In the 1970s, Harlan Mills, also a key figure in this area,
>
>
>
> I once passed a program to IBM to use CSF on as a restructuring
> exercise.
> The resulting program was one which, if I had seen a trainee programmer
> write it, would have been binned. I understand that CSF is driven by
> parameters defining the required result so I expect that what I saw was
>
> not the best possible result.
>
I have commented on IBM CSF in this forum before. I suppose this URL
will be too long, so watch the wrap:
http://groups.google.com/group/comp...orldnet.att.net
I was impressed by IBM's COBOL Structuring Facility, but if the
original data names and procedure names were confusing, they would
still be confusing in the re-structured program. The generated
program could still be improved by an intelligent progammer.
Back to the original question, why is structured programming better
than spaghetti code? Because the control flow through the program
should be easier to understand. Of course, it's still possible to
write crap in structured code.
I used to "maintain" a macro-level CICS COBOL program with 42 ALTER
statements in it. Thank God those days are gone.
--
http://arnold.trembley.home.att.net/
| |
| Alistair 2006-02-08, 8:52 am |
|
Donald Tees wrote:
> Alistair wrote:
> Real Programmers Don't Use Pascal
I thoroughily enjoyed that article. Thanks Donald.
| |
| Alistair 2006-02-08, 8:52 am |
|
Arnold Trembley wrote:
> Alistair wrote:
>
> I have commented on IBM CSF in this forum before. I suppose this URL
> will be too long, so watch the wrap:
> http://groups.google.com/group/comp...orldnet.att.net
>
Thanks Arnold. My experience of CSF was at the hands of another so I
did not get the option to tweak the options and I did not get a second
go, either. I did, however, get to run the same program though a tool
provided by Namic (Compuware now). I think it was called XA-Systems and
it produced the style of code and structure as I would expect a
seasoned programmer to write.
| |
| Donald Tees 2006-02-08, 8:52 am |
| Alistair wrote:
> Donald Tees wrote:
>
>
>
> I thoroughily enjoyed that article. Thanks Donald.
>
I should have posted an URL to it, rather than trying to cut and paste,
but I liked the article as well, and I am still getting used to Firefox.
Glad you enjhoyed it.
Donald
| |
|
| Wow! You really hit a nerve. Lighten up people.
But then it seems that phrase 'Structured Code' has always caused a
turmoil ever since it was first introduced by some guy who couldn't
spell GO TO, or was it the guy suffering from PASCAL envy?
| |
|
| Donald Tees wrote:
> Alistair wrote:
> I should have posted an URL to it, rather than trying to cut and paste,
> but I liked the article as well, and I am still getting used to Firefox.
> Glad you enjhoyed it.
>
> Donald
I would still like to see the URL if you can post it, please...
Carl
| |
| Donald Tees 2006-02-08, 8:53 am |
| CG wrote:
> Donald Tees wrote:
>
>
> I would still like to see the URL if you can post it, please...
> Carl
Here you go ... http://www.donald-tees.ca/misc/real
Donald
| |
| Arnold Trembley 2006-02-08, 8:53 am |
|
Alistair wrote:
> Arnold Trembley wrote:
>
>
>
> Thanks Arnold. My experience of CSF was at the hands of another so I
> did not get the option to tweak the options and I did not get a second
> go, either. I did, however, get to run the same program though a tool
> provided by Namic (Compuware now). I think it was called XA-Systems and
> it produced the style of code and structure as I would expect a
> seasoned programmer to write.
>
I would have been extremely interested in seeing how different
restructuring/refactoring tools would have handled the same input
source program. That would have been a useful head-to-head test, but
usually cost factors intervene.
There is no doubt in my mind that we can use the computer to improve
the process of writing programs. So why don't we? I've seen a lot of
bad COBOL code in my 26+ years of programming, and even written my
fair share of it. It's amazing what a low level of quality is
acceptable to most businesses. It's depressing how much time and
money is wasted on abandoned projects. Even the successful projects
often cost more and have poorer quality than they should.
--
http://arnold.trembley.home.att.net/
| |
|
| Arnold Trembley wrote:
>
>
> Alistair wrote:
>
> I have commented on IBM CSF in this forum before. I suppose this URL
> will be too long, so watch the wrap:
> http://groups.google.com/group/comp...orldnet.att.net
>
>
> I was impressed by IBM's COBOL Structuring Facility, but if the original
> data names and procedure names were confusing, they would still be
> confusing in the re-structured program. The generated program could
> still be improved by an intelligent progammer.
>
> Back to the original question, why is structured programming better than
> spaghetti code? Because the control flow through the program should be
> easier to understand. Of course, it's still possible to write crap in
> structured code.
>
> I used to "maintain" a macro-level CICS COBOL program with 42 ALTER
> statements in it. Thank God those days are gone.
>
It is and will always be true that you can write good and bad code in
any language and using any given style. Which recalls one of the better
books I ever read on this subject: "Reliable Software Through Composite
Design" by Glen Myers. [Mason/Charters Publishers, Inc., 1975] Glen
started the book with one of my favorite statements:
"Most programs are never designed. Rather they are created
on the coding pad, resulting in programs that are poorly
constructed, far too expensive and unreliable."
Structured programs, without a careful design, are only marginally
better than spaghetti code that has not been properly designed. While a
well designed program is usually far more easily tested, modified and
enhanced, no matter what the coding technique.
It should also be noted that 'Top-Down' and 'Structured' are not the
same. You can write 'Top-Down' or you can design 'Top-Down' and not use
Structured coding. Structured coding is generally top-down, but even
that is also not a guarantee.
A carefully designed _and_ structured program is the best of both
worlds. "Composite Design" is a refinement of top-down and structured
concepts with a few more 'rules' thrown in to improve the overall
quality of the resulting application.
| |
|
|
| James J. Gavan 2006-02-08, 8:53 am |
| Arnold Trembley wrote:
>
>
> Alistair wrote:
>
>
> I would have been extremely interested in seeing how different
> restructuring/refactoring tools would have handled the same input source
> program. That would have been a useful head-to-head test, but usually
> cost factors intervene.
>
> There is no doubt in my mind that we can use the computer to improve the
> process of writing programs. So why don't we? I've seen a lot of bad
> COBOL code in my 26+ years of programming, and even written my fair
> share of it. It's amazing what a low level of quality is acceptable to
> most businesses. It's depressing how much time and money is wasted on
> abandoned projects. Even the successful projects often cost more and
> have poorer quality than they should.
>
>
Interesting, and back to when Structured got introduced. Skippy was
learning COBOL/Structured at school mid-seventies.
I wasn't into programming back then - enough problems as a Systems
Analyst initially playing 'politico' with non-friendly end-users, at my
second installation. I came to Canada in Feb 75 but some two or more
years prior to that, our Chief Programmer had the thought to recruit
some young kids and teach them COBOL from scratch. (Obviously that would
have been COBOL '68). He found a twenty-five something programming
consultant who ran a two-w course. Bright, pleasing young man. Course
was intensive over some two ws. We advertised and got about a dozen
locals who were already at Tech schools.
Not my baby back then, so I didn't have any documentation. (Wish I had
grabbed a copy). He jumped into Structured right from Lesson 1. His
approach was a small series of template programs which had *oodles and
oodles* of comment statements spelling out the structure - then of
course you filled in the bits in between with *actual* code. The ratio
was about two page of comments to one of 'real' code :-)
Naturally some of the beginners dropped out early, (programming just
wasn't their thing). Subsequently others moved on to larger
installations at Bristol etc. We retained some four until I left UK.
Within less than a month of the course we had some very *elegant* and
working programs from those youngsters. Needless to say the programs
contained no ambiguities but still contained those oodles of comment
statements. The rest of the programming team got copies of the tutorials
and it became an installation standard. Naturally as newcomers became
more comfortable they paraphrased the original template comment statements.
You're into the 'Education' game Arnold - how about another feather in
your cap - offer a course on Structured Programming ?
Jimmy
| |
| Pat Hall 2006-02-08, 8:53 am |
| Arnold,
You should try www.tinyurl.com to handle those long urls. Works
great for me.
PatH
Arnold Trembley wrote:
>
>
> Alistair wrote:
>
>
> I have commented on IBM CSF in this forum before. I suppose this URL
> will be too long, so watch the wrap:
> http://groups.google.com/group/comp...orldnet.att.net
>
>
> I was impressed by IBM's COBOL Structuring Facility, but if the original
> data names and procedure names were confusing, they would still be
> confusing in the re-structured program. The generated program could
> still be improved by an intelligent progammer.
>
> Back to the original question, why is structured programming better than
> spaghetti code? Because the control flow through the program should be
> easier to understand. Of course, it's still possible to write crap in
> structured code.
>
> I used to "maintain" a macro-level CICS COBOL program with 42 ALTER
> statements in it. Thank God those days are gone.
>
| |
| Michael Wojcik 2006-02-08, 8:53 am |
|
In article <1138919750.009976.189420@f14g2000cwb.googlegroups.com>, "apple.time@yahoo.com" <apple.time@yahoo.com> writes:
> I am working on a system that has really ancient code (15 years).
15-year-old code is hardly ancient. I regularly maintain code older
than that in current products.
Microsoft Windows 3.0 came out 15 years ago, and Windows NT was
announced. The first Linux release was in 1991. The World Wide Web
was launched that year. PGP. TrueType. MS-DOS 5.0.
15 years ago is comfortably in the modern era of computer use. There's
a lot of 15-year-old code running, on systems small and large.
> This was before the time of sturctured code.
No, it wasn't. Dijkstra's famous caution against unstructured
code ("Go To Statement Considered Harmful", CACM 11.3) was
published in 1968, almost 40 years ago, for example.
Aside from a few specialized domains, there's no excuse for
writing unstructured code in the past 15 years.
> Can someone tell me the
> reasons why structured coding is BETTER?
For the same reasons that structured anything is better than its
unstructured form.[1]
In my kitchen I have several drawers: one for flatware, one for
cooking implements, one for cutting boards... Of course, I could
just have one big bin and toss everything in there. Can you see
why having separate drawers is better? Or, similarly, why keeping
documents in files is better than piling them up on your desk, and
so forth.
Structure incorporates information. That information makes it
easier to abstract processes; categories like "flatware" and
"cooking implements" are an abstraction that lets me more quickly
locate what I want in my kitchen. Abstraction, in turn, makes it
easier to understand and reason about those processes. Thus
structured code is easier to write correctly, read, and maintain
than unstructured code.
1. That doesn't mean that the benefits of structure always
outweigh the benefits of non-structure, of course. There are
domains where it may sometimes be more useful to eschew those
benefits - such as art.
--
Michael Wojcik michael.wojcik@microfocus.com
Some there are, brave, high-souled fellows, who could borrow the world to
play at ball, and never feel the responsibility, whereas others are uneasy
and not themselves with a single shilling that does not belong to them.
-- Arthur Ransome
| |
| Michael Wojcik 2006-02-08, 8:53 am |
|
In article <43E29D04.787FBCA8@mts.net>, Peter Lacey <lacey@mts.net> writes:
>
> There has been an enormous amount of blather since structured
> programming was first written about concerning the GOTO statement. It's
> been blamed for all the ills that programming is heir to.
Yes, but nearly always by people who have not read, or have not
understood, Dijkstra's piece, which started the whole thing.
Dijkstra was not arguing that GOTO should never be used (note the
title "Go To Statement Considered Harmful" was added by the editor
of CACM); he was arguing for including more expressive looping
constructs in programming languages. In 1968, that was an eminently
sensible position.
In effect, what Dijkstra was really arguing was that programming
languages for general use should reflect programming as a craft, and
not simply try to represent computation theory. In other words, he
was arguing for good tools for building software, and not just ones
for demonstrating mathematical results.
A good retrospective on the subject can be found at
http://david.tribble.com/text/goto.html.
> There are
> people, in fact, who define "Structured" programming as "GOTO-less"
> programming. That's nonsense.
Agreed. It's perfectly possible to write well-structured code
using no control structure other than IF and GOTO; that's what
most assembly looks like,[1] after all, and there are structured
assembly programs.
1. There are processors with higher-level looping operations, like
the x86 "rep" prefix. They're rarely useful, though, and they do
little if anything to improve code structure.
--
Michael Wojcik michael.wojcik@microfocus.com
Q: What is the derivation and meaning of the name Erwin?
A: It is English from the Anglo-Saxon and means Tariff Act of 1909.
-- Columbus (Ohio) Citizen
| |
| Michael Wojcik 2006-02-08, 8:53 am |
|
In article <gtk9u1dkg8dog1kkig12v9hfu6of4pq7sk@4ax.com>, Gerry Palmer <gpalmer@pobox.com> writes:
>
> I recall reading a tongue-in-ch article in the early 70s (in
> Computerworld, perhaps?) that proposed an elegant remedy to the then
> current "no GO TOs allowed" dictums. The author suggested a minor
> compiler change that would instead support the "COME FROM" construct.
Hmm. C-INTERCAL implements COME FROM, but the C-INTERCAL manual[1]
cites Clark's "A linguistic contribution to GOTO-less programming"
from CACM 27, in 1984, as the earliest known example in the
literature.
Wait... I just discovered that Clark published a piece on COME FROM
in Datamation in 1973.[2] I bet that's the one you were thinking of.
Someone should probably ask Eric Raymond to update the C-INTERCAL
manual.
C-INTERCAL does provide COME FROM specifically because it does not
provide GOTO. Of course, INTERCAL is the original perverse
programming language, so that only goes to emphasize Peter's original
point.
1. http://www.progsoc.uts.edu.au/~sbg/...l/ick3.html#3.1
2. http://www.fortran.com/fortran/come_from.html
--
Michael Wojcik michael.wojcik@microfocus.com
Do we have boyfriends? We are interested in delicious food and sweets.
And tiny animals like the cat. -- Naoko Yamano
| |
| Michael Wojcik 2006-02-08, 8:53 am |
|
In article <44foukF1vhs6U2@individual.net>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
> Hmm, 1991 was definitely *not* "before the time of sturctured code". I
> learned about structured coding when was was in junior high school in 1982
> or so. This was using Pascal. I'm not even sure if Pascal has a goto
> statement! (No, just kidding, I'm sure it does. We were just told to not
> use it.)
Standard Pascal does include goto, but it's deprecated, and labels
can only be integers of up to four digits (which is odd, considering
Wirth's goal of expressive and readable code). Many Pascal
implementations allow symbolic labels, but they still typically
discourage use of goto in Pascal programs.
Typically, goto is used in Pascal to escape from nested loops in the
event of an error.
Java has no goto statement proper, though it provides restricted
gotos that can only branch to certain locations (break and continue).
OCaml has no goto; there's no use for it that can't be reasonably
expressed by one of the other control structures. For example, OCaml
exceptions are much better for leaving loops prematurely.
--
Michael Wojcik michael.wojcik@microfocus.com
World domination has encountered a momentary setback. Talk amongst
yourselves. -- Darby Conley
| |
| void * clvrmnky() 2006-02-08, 6:55 pm |
| On 04/02/2006 12:16 PM, Donald Tees wrote:
> Alistair wrote:
> Real Programmers Don't Use Pascal
> [ A letter to the editor of Datamation, volume 29 number 7, July 1983.
> I've long ago lost my dog-eared photocopy, but I believe this was
> written (and is copyright) by Ed Post, Graphic Software Systems,
> Wilsonville OR USA.
> The story of Mel is a related article. ]
[...]
Hilarious. I'm sure I've seen this somewhere, myself.
> It was largely due to the efforts of thousands of Real Programmers
> working for NASA that our boys got to the moon and back before the Russkies.
> The computers in the Space Shuttle were programmed by Real Programmers.
> Real Programmers are at work for Boeing designing the operation systems
> for cruise missiles.
Wasn't it also Real Programmers that wrote and tested some FORTRAN that
happily added one to X in a conditional, (perhaps prompting the great
"=" vs. "==" operator wars)?
I guess this goes from Clever Hack to Oh Shit only when the code in
question is part of a rocket control system, causing Real Technicians to
have to blow the thing up as it decided to rapidly yaw toward earth near
escape velocity? Real Managers then no longer see the humour, as they
know that Real Taxpayers may not immediately see the humour.
I bet more than a few Real Engineers rolled their eyes over this back
then, adding another tick to their side in the great Software vs.
Hardware Error scorecard.
Ah, the good ole days. I hear that they are letting women code
nowadays. I guess we can blame Admiral Hopper for that.
[In the interest of being exceedingly clear, that last comment is
intended as a joke, in the same spirit of the original posting.]
| |
| Frank Swarbrick 2006-02-09, 9:55 pm |
| >>>> Michael Wojcik<mwojcik@newsguy.com> 02/06/06 11:01 AM >>>
>
>In article <44foukF1vhs6U2@individual.net>, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> writes:
1982[color=darkred]
not[color=darkred]
>
>Standard Pascal does include goto, but it's deprecated, and labels
>can only be integers of up to four digits (which is odd, considering
>Wirth's goal of expressive and readable code). Many Pascal
>implementations allow symbolic labels, but they still typically
>discourage use of goto in Pascal programs.
>
>Typically, goto is used in Pascal to escape from nested loops in the
>event of an error.
>
>Java has no goto statement proper, though it provides restricted
>gotos that can only branch to certain locations (break and continue).
I like this quote from _Learning Java_:
"Multilevel break and continue statements remove the remaining justification
for the evil 'goto' statement in C/C++".
I've personally never used it, but then I haven't done a huge amount of Java
anyway. (Other than rewriting the same program over and over each time I
find a new feature. "-) )
Bought a book on C# the other day. Has a surprising amount of good stuff.
Can't recall offhand if it has multilevel break/continue statements, or
something similar.
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Michael Wojcik 2006-02-10, 6:55 pm |
|
In article <45209mF4ia9nU1@individual.net>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
> <Frank.Swarbrick@efirstbank.com> writes:
>
> I like this quote from _Learning Java_:
> "Multilevel break and continue statements remove the remaining justification
> for the evil 'goto' statement in C/C++".
Really? It's impossible to tell out of context (we don't know what
justifications remain, because we don't know which ones the author(s)
have eliminated), but it reads to me like a bit of idle demagoguery.
> Bought a book on C# the other day. Has a surprising amount of good stuff.
C#, or the book?
I have two C# books at the moment, both by Jesse Liberty. _Programming
C#_ is a reference, and is OK, but somewhat out of date because
Microsoft is changing the language and even more so the APIs (and the
Visual Studio IDE, if you care about such things) rapidly. _Learning
C#_ I think was probably not worth my money. It's aim isn't clear;
it's not a proper introduction to programming, but it claims that its
audience includes new programmers, and it tries to teach such basic
concepts as arrays. It's not a large book and it devotes far too
many pages to elementary topics like that, and far too little to ones
of more interest to experienced programmers coming to C# (notably
what approaches are preferable for given situations, and why).
C# has a number of nice features; its main problem is that that number
is growing far too quickly. It's losing any hope it had of being more
elegant than C++.
However, it will likely always be better than C++.NET, which will
always be an awkward combination of a bloated, complicated standard
language and a wide array of proprietary extensions. Ugh.
Now F#, *there* is a language for .NET programming...
> Can't recall offhand if it has multilevel break/continue statements, or
> something similar.
It doesn't, unless they've been added very recently. While C# is in
many ways closer to Java than it is to C++, this is one of the places
where it didn't pick up a Java feature. It also retains goto and
adds "goto case", which it uses to make C++'s default fall-through
(which C++ got from C) explicit rather than implicit.
--
Michael Wojcik michael.wojcik@microfocus.com
Q: What is the derivation and meaning of the name Erwin?
A: It is English from the Anglo-Saxon and means Tariff Act of 1909.
-- Columbus (Ohio) Citizen
| |
| Frank Swarbrick 2006-02-10, 6:55 pm |
| Michael Wojcik<mwojcik@newsguy.com> 02/10/06 7:23 AM >>>
>In article <45209mF4ia9nU1@individual.net>, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> writes:
not[color=darkred]
justification[color=darkred]
>
>Really? It's impossible to tell out of context (we don't know what
>justifications remain, because we don't know which ones the author(s)
>have eliminated), but it reads to me like a bit of idle demagoguery.
>
stuff.[color=darkred]
>
>C#, or the book?
Sorry, I was referring to C# the language, not the book that I am using to
learn it.
>I have two C# books at the moment, both by Jesse Liberty. _Programming
>C#_ is a reference, and is OK, but somewhat out of date because
>Microsoft is changing the language and even more so the APIs (and the
>Visual Studio IDE, if you care about such things) rapidly. _Learning
>C#_ I think was probably not worth my money. It's aim isn't clear;
>it's not a proper introduction to programming, but it claims that its
>audience includes new programmers, and it tries to teach such basic
>concepts as arrays. It's not a large book and it devotes far too
>many pages to elementary topics like that, and far too little to ones
>of more interest to experienced programmers coming to C# (notably
>what approaches are preferable for given situations, and why).
The book I am reading is _Programming C#_ (by Jesse Liberty) (hmm, looks
like I should have got it from amazon.com and saved myself $15.00...). I
like the book less than I like the language. It seems like some more
advanced concepts (such as classes, etc.) are addressed earlier than simpler
concepts (such as arrays and strings). Or maybe he just has a different
opinion on what is advanced and what is not. Still, I'm finding it fairly
useful. Not for a beginning programmer, though. And it sounds like
_Learning C#_ is not either. Not that I need that, but I'd be curious as to
what book a non-programmer might pick up to learn C# as a first language.
Or perhaps C# simply is not a "first language" at all? I'm personally not
convinced that any OOP language would be a good first language to learn.
But, then, it's hard to erase all these years of procedural programming and
picture what it would have been like to learn an OO language first. Is
there anyone out there who learned, say, Java first and then COBOL (or C, or
some other procedural non-OO language)?
(It's interesting to note that the Wikipedia [yes, I love Wikipedia] page
for Procedural programming refers to C++, C#, Delphi, etc. as being
procedural languages, even though they are also OO languages. I guess once
could certainly limit themselves to procedural programming only in those
languages, but I can't imagine anyone doing so.)
>C# has a number of nice features; its main problem is that that number
>is growing far too quickly. It's losing any hope it had of being more
>elegant than C++.
It seems to me that it's rather difficult to have a language that is both
small enough to not be overwhelming to learn, yet large enough to be quite
powerful. Still looking...
>However, it will likely always be better than C++.NET, which will
>always be an awkward combination of a bloated, complicated standard
>language and a wide array of proprietary extensions. Ugh.
Heh. I learned C++ back in the early 90s. Looking an Visual C++ it seems
like I would have to learn the whole thing all over again, so many things
have changed!
>Now F#, *there* is a language for .NET programming...
I wasn't specifically looking for a .NET language. I just thought I'd take
a look at C#. Looking up F# I see that it implements functional programming
and has similarities to your apparent favorite, OCaml. I still haven't
really tried to learn functional programming, but it looks to me to be too
much like Calculus, which I failed three times, so...
>
>It doesn't, unless they've been added very recently. While C# is in
>many ways closer to Java than it is to C++, this is one of the places
>where it didn't pick up a Java feature. It also retains goto and
>adds "goto case", which it uses to make C++'s default fall-through
>(which C++ got from C) explicit rather than implicit.
I'm not fan of the C/C++ case "fallthrough". Don't think I've ever
intentionally utilized it. Seems to me it's more likely to cause problems
than it is to help clarify things.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Pete Dashwood 2006-02-10, 9:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4543mdF4run2U1@individual.net...
> Michael Wojcik<mwojcik@newsguy.com> 02/10/06 7:23 AM >>>
> <Frank.Swarbrick@efirstbank.com> writes:
> not
> justification
> stuff.
>
> Sorry, I was referring to C# the language, not the book that I am using to
> learn it.
>
>
> The book I am reading is _Programming C#_ (by Jesse Liberty) (hmm, looks
> like I should have got it from amazon.com and saved myself $15.00...). I
> like the book less than I like the language. It seems like some more
> advanced concepts (such as classes, etc.) are addressed earlier than
> simpler
> concepts (such as arrays and strings). Or maybe he just has a different
> opinion on what is advanced and what is not. Still, I'm finding it fairly
> useful. Not for a beginning programmer, though. And it sounds like
> _Learning C#_ is not either. Not that I need that, but I'd be curious as
> to
> what book a non-programmer might pick up to learn C# as a first language.
> Or perhaps C# simply is not a "first language" at all? I'm personally not
> convinced that any OOP language would be a good first language to learn.
> But, then, it's hard to erase all these years of procedural programming
> and
> picture what it would have been like to learn an OO language first. Is
> there anyone out there who learned, say, Java first and then COBOL (or C,
> or
> some other procedural non-OO language)?
It is amazing the diversity of ways in which people learn. (I did an adult
teaching course last year - that's a course for teaching adults - and was
very fascinated by the perceptual and psychological interactions that occur
when we learn something. There is no "one size fits all". Some people are
more visual, some are more conceptual, some are more language oriented. All
of us are different, and a good teacher will include material in his course
that appeals to all types.
Unlike you, Frank, I AM convinced that OO is a good way to learn programming
as a first language. (That doesn't mean I think you are "wrong" - your
statement is certainly true for many people.)
I had major problems struggling with OO COBOL when it was first released. I
spent three months trying to get my head around the new concepts and
suffered from exactly what you outlined above - a lifetime of procedural
COBOL.
In the end, in despair, I thought: "XXXX it. Maybe I'll just learn Java..."
So I invested in a couple of Java books (the best was "Java 2 in 24 Hours"
by Rogers Cadenhead - possibly one of the best books on learning a
programming language ever written; light hearted, witty, amusing,
entertaining, and VERY useful), and tried to clear my mind of everything I
knew and approach it as something not seen before, without making judgements
based on other experience. Within 3 days I was hooked. It was so obvious.
Simple, elegant, and fun. By the time I had my first Java programs and
applets running, my mind was racing ahead exploring the implications of
this new freedom. I went back to OO COBOL and saw it in a new light. The
concepts I had previously struggled with were now an open book and
everything fell into place. I started writing components...
Later I had to run some courses in Java Web programming (servlets) and
JavaScript (for client). I found the "computer programmers (COBOL)" had the
hardest time and were the last to pick it up. The people who had never
programmed in their life took to it like ducks to water.
I think that once we become competent in COBOL (for instance) it is very
easy to believe that is THE way to do things. To succeed with OO you should
clear your mind, or at least agree with yourself to suspend criticism or
evaluation until you have written some samples and got them working. And
learn OO by means of a language that was OO from its inception, designed to
be OO, not having had a bolt on of Object handling to make it "socially
acceptable", even if (as in the case of COBOL) that bolt on is superbly and
cleverly engineered.
I recommend Java because it meets those criteria.
>
> (It's interesting to note that the Wikipedia [yes, I love Wikipedia] page
> for Procedural programming refers to C++, C#, Delphi, etc. as being
> procedural languages, even though they are also OO languages. I guess
> once
> could certainly limit themselves to procedural programming only in those
> languages, but I can't imagine anyone doing so.)
>
>
> It seems to me that it's rather difficult to have a language that is both
> small enough to not be overwhelming to learn, yet large enough to be quite
> powerful. Still looking...
>
That is very true. If you consider all the available classes as "part of the
language" (and you certainly have to at least read through a list to know
what is available, even if you don't memorise every class by heart), it is a
lot to learn.
<snip>
Pete.
| |
| Michael Wojcik 2006-02-12, 6:55 pm |
|
In article <4543mdF4run2U1@individual.net>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
> Michael Wojcik<mwojcik@newsguy.com> 02/10/06 7:23 AM >>>
> <Frank.Swarbrick@efirstbank.com> writes:
>
>
> The book I am reading is _Programming C#_ (by Jesse Liberty) (hmm, looks
> like I should have got it from amazon.com and saved myself $15.00...). I
> like the book less than I like the language. It seems like some more
> advanced concepts (such as classes, etc.) are addressed earlier than simpler
> concepts (such as arrays and strings).
Well, I think _Programming C#_ is intended as a reference and usage
guide for experienced programmers, and not as a tutorial, so Liberty
may be operating on the assumption that his readers will want first
to know how C# approaches its major features (such as OO), and only
then learn about the details of its string handling and so forth.
But I agree it's not ideal. I don't think Liberty is a terrible
technical author, but he's not among the greats, either.
> ... Not for a beginning programmer, though. And it sounds like
> _Learning C#_ is not either. Not that I need that, but I'd be curious as to
> what book a non-programmer might pick up to learn C# as a first language.
> Or perhaps C# simply is not a "first language" at all?
I don't think I'd recommend C# as a first language, but then my
reasons for recommending any language for that purpose would be
pretty subjective.
I don't know what the current state of computer-programming pedagogy
is, but I've never heard really compelling arguments for any language
as "first". There are languages like Pascal and Logo that were
intended as teaching languages, and their authors make claims about
why they're suited for that purpose, but they seem to me speculative
rather than substantial.
Still, I'd think that for a first language an interpreted (or
incrementally compiled in an interactive environment, like OCaml) one
would be useful, so that the student gets immediate feedback. Even
in the VS2005 IDE, the write-build-run cycle for C# is a bit
cumbersome for experimentation.
Beyond that, it probably depends on what the student wants to
concentrate on first. Functional languages in the LISP and ML
families (including Logo, which uses more English-like syntax than
most of the LISP derivatives) are good for studying some data
structures, computing theory, recursion, and, well, functional
programming (the application and manipulation of functions).
Procedural languages are useful for learning programming as an
analogue of real-world imperative models, like following a recipie or
giving orders, and use a "closer to the metal" abstraction (which is
useful if the student wants to learn how a computer works).
Visual drop-and-wire component-based environments let students
quickly build useful applications, and provide a very high level of
abstraction, so the student can initially focus on the "what" rather
than the "how".
> (It's interesting to note that the Wikipedia [yes, I love Wikipedia] page
> for Procedural programming refers to C++, C#, Delphi, etc. as being
> procedural languages, even though they are also OO languages. I guess once
> could certainly limit themselves to procedural programming only in those
> languages, but I can't imagine anyone doing so.)
I haven't looked at the article, but I expect it's using "procedural"
in the sense of "not functional". "Imperative" might be a better
term - those are all imperative languages without functional features
(namely dynamic closures and higher-order functions).
>
> It seems to me that it's rather difficult to have a language that is both
> small enough to not be overwhelming to learn, yet large enough to be quite
> powerful. Still looking...
The problem I see with C# is that features are being added ad hoc to
address perceived shortcomings. It has 83 keywords currently, and
some of them (eg "using") are overloaded. And while it's true that
accessors and indexers and attributes and generics and reflection and
so on are all lovely when you need them, that's a lot of features to
keep track of (particularly if you're reading someone else's code).
>
> Heh. I learned C++ back in the early 90s. Looking an Visual C++ it seems
> like I would have to learn the whole thing all over again, so many things
> have changed!
True, C++ since the 1998 standard is very different from C++ in the
early 90s (when used well, ie with appropriate use of standard
templates and so forth), but that's another story. C++.NET is an
ugly attempt to bolt enough extensions onto C++ to make it suitable
for .NET, and the result has all of the charm and simplicity of C++
and all the portability of .NET.
>
> I wasn't specifically looking for a .NET language. I just thought I'd take
> a look at C#. Looking up F# I see that it implements functional programming
> and has similarities to your apparent favorite, OCaml.
I don't know that OCaml's my favorite language, but yes, F# is
basically an attempt by Microsoft Research to implement most of
OCaml under .NET. They've made concessions where standard OCaml
isn't such a good match for .NET.
I wasn't really serious in suggesting it, by the way, though it does
have the advantage, like C#, that it was designed for .NET rather
than being coerced into it.
> I still haven't
> really tried to learn functional programming, but it looks to me to be too
> much like Calculus, which I failed three times, so...
Nah. The calculus you studied is continuous, and lambda calculus is
discrete. :-)
Seriously, if you ever decide you want to try functional programming,
an ML derivative like OCaml or F# probably isn't your best bet for a
first language (though again this is all speculation). Logo (I bet
there's a free Logo around) is basically a simplified LISP with some
built-in vector graphics; Dr Scheme is a free, friendly version of
Scheme, which is LISP tidied up for school. They'd both be good
choices.
But there's also Ruby, which is a functional language of a rather
different, indeed unique, sort, and currently very popular for some
kinds of applications. Ruby is probably the most currently
marketable functional language. And it's free, and there are tons
of components available.
>
> I'm not fan of the C/C++ case "fallthrough". Don't think I've ever
> intentionally utilized it. Seems to me it's more likely to cause problems
> than it is to help clarify things.
Few people are fans of fallthrough, and I think this is an area where
C# improved things, albeit in the form of a rather inelegant design.
(Fallthrough does happen in C# if a case is empty, which is incon-
sistent for the sake of syntactic sugar. And explicit fallthrough is
done with "goto case", which is actually more powerful, but introduces
new syntax that reuses existing keywords - something C-derived
languages have enough of already.)
Tom Duff believes that even Brian Kernighan (coauthor of _The C
Programming Language_) has expressed a dislike of default fallthrough
(see the note at the end of [1]). I don't think Dennis Ritchie has
ever said he regrets it, in anything I've seen, but he does note that
C got its switch mechanism from B, which inherited it from an early
version of BCPL before the "endcase" statement was introduced. He
wanted C to support multiple cases for a block in a switch statement
(which is very often useful), and default fallthrough was an easy way
to do that.
1. http://www.lysator.liu.se/c/duffs-device.html
--
Michael Wojcik michael.wojcik@microfocus.com
How can I sing with love in my bosom?
Unclean, immature and unseasonable salmon. -- Basil Bunting
| |
| Jesse Liberty 2006-02-13, 6:55 pm |
| First, thank you for reading my books, and please do not read what follows
as defensive, but rather as an attempt to exchange views with a reader (and
thus to improve the next edition).
Before I go on, let me also mention that you can find an errata, a FAQ,
source code and a link to a free private support discussion on my web site
(http://www.LibertyAssociates.com) - click on Books.
> The book I am reading is _Programming C#_ (by Jesse Liberty) (hmm, looks
> like I should have got it from amazon.com and saved myself $15.00...). I
> like the book less than I like the language. It seems like some more
> advanced concepts (such as classes, etc.) are addressed earlier than
> simpler
> concepts (such as arrays and strings). Or maybe he just has a different
> opinion on what is advanced and what is not.
It is not that I think that classes are "easier" or less advanced, it is
that I feel strongly that object oriented programming should be taught
classes-first, from the earliest opportunity; and everything that follows
should be within the context of classes and objects. In C# Arrays are
implemented with the Array class, and while they have traditional array
semantics, they also have properties, methods and so forth. So this was a
conscious decision.
Absolutely, Programming C# assumes some experience with a related language
(C++, Java, etc.)
[color=darkred]
Ah, now that would be a failure on my part. Learning C# was targeted at
novice programmers, and in the next edition we go further to make that
explicit (adding more introductory material as well as quizzes, etc.)
[color=darkred]
> Or perhaps C# simply is not a "first language" at all?
Oh, I think if written correctly (and I accept that so far I may have failed
in doing so) C# makes a terrific first language, if used within the constext
of Visual Studio 2005.
----
Jesse Liberty
| |
| Jesse Liberty 2006-02-13, 6:55 pm |
| > Well, I think _Programming C#_ is intended as a reference and usage
> guide for experienced programmers, and not as a tutorial,
Actually, just the opposite. I wrote the book as a tutorial, or more
accurately, as an attempt at telling the story of Programming in C#, and
explicitly not as a reference book. Seems that for at least one reader I
have failed miserably <smile>.
My goal in all my books it take the reader through the complexity of the
language, in a logical and coherent way, not filling in every obscure detail
but finding a thread that leads to proficiency and the ability to go back to
the reference material to fill in the more esoteric details as needed.
> But I agree it's not ideal. I don't think Liberty is a terrible
> technical author, but he's not among the greats, either.
Ouch. <grin>. Without in any way being insulted (actually that's easy for
me as I see myself as a programmer who writes, rather than as a writer who
programs) can you tell me who you see as the great technical authors, and
what maks them great? That would be a terribly useful thread.
---
Jesse
| |
| Frank Swarbrick 2006-02-13, 6:55 pm |
| Pete Dashwood<dashwood@enternet.co.nz> 02/10/06 6:37 PM >>>
>
>It is amazing the diversity of ways in which people learn. (I did an adult
>teaching course last year - that's a course for teaching adults - and was
>very fascinated by the perceptual and psychological interactions that occur
>when we learn something. There is no "one size fits all". Some people are
>more visual, some are more conceptual, some are more language oriented. All
>of us are different, and a good teacher will include material in his course
>that appeals to all types.
>
>Unlike you, Frank, I AM convinced that OO is a good way to learn
programming
>as a first language. (That doesn't mean I think you are "wrong" - your
>statement is certainly true for many people.)
>
>I had major problems struggling with OO COBOL when it was first released. I
>spent three months trying to get my head around the new concepts and
>suffered from exactly what you outlined above - a lifetime of procedural
>COBOL.
>
>In the end, in despair, I thought: "XXXX it. Maybe I'll just learn Java..."
>So I invested in a couple of Java books (the best was "Java 2 in 24 Hours"
>by Rogers Cadenhead - possibly one of the best books on learning a
>programming language ever written; light hearted, witty, amusing,
>entertaining, and VERY useful), and tried to clear my mind of everything I
>knew and approach it as something not seen before, without making
judgements
>based on other experience. Within 3 days I was hooked. It was so obvious.
>Simple, elegant, and fun. By the time I had my first Java programs and
>applets running, my mind was racing ahead exploring the implications of
>this new freedom. I went back to OO COBOL and saw it in a new light. The
>concepts I had previously struggled with were now an open book and
>everything fell into place. I started writing components...
>
>Later I had to run some courses in Java Web programming (servlets) and
>JavaScript (for client). I found the "computer programmers (COBOL)" had the
>hardest time and were the last to pick it up. The people who had never
>programmed in their life took to it like ducks to water.
>
>I think that once we become competent in COBOL (for instance) it is very
>easy to believe that is THE way to do things. To succeed with OO you should
>clear your mind, or at least agree with yourself to suspend criticism or
>evaluation until you have written some samples and got them working. And
>learn OO by means of a language that was OO from its inception, designed to
>be OO, not having had a bolt on of Object handling to make it "socially
>acceptable", even if (as in the case of COBOL) that bolt on is superbly and
>cleverly engineered.
>
>I recommend Java because it meets those criteria.
Actually, I only said that because I don't know anyone who learned OO first,
so I had no data that would allow me to state that OO programming languages
are good first languages to learn. But you appear to have experience with
other people, if not yourself, learning an OO language first, and finding it
"simple" (well, as simple as any programming paradigm might be), so you can
state that, and I can as well if I use you as a reference <g>.
Anyway, don't take my message as saying that I am not a fan of OO. I am
definitely a fan. I am constantly going crazy using procedural COBOL
because I know that so many of the things I have to do could be done so much
simpler with an OO language. All I was getting at, and you apparently
agree, is that in order to learn OO you have to leave a lot of your
procedural thinking behind. It's often hard.
I have a general question... With COBOL, if you add a new field to a group
that is passed between programs (program to sub-program, etc) you pretty
much have to recompile any programs that use that group in order for things
to not break. You don't have to do that with Java because the "group" is a
class, essentially, and when you instantiate the class it creates the new
object based on the current version of the class -- basically the class
itself has control over it's own instantiation. As long as the
instantiating class does not attempt to access class variables directly then
it doesn't matter if the changed class is larger, smaller, has variables
moved around in memory, etc.
So the question, is, can this type of behavior be somehow simulated in a
procedural (non-OO) language? Seems to me not very easily. Perhaps you
could get your procedural code to "act" as if it's OO, but I'm sure that
wouldn't be worth it.
Sorry if that question didn't really make sense. I'm having a hard time
phrasing it. Anyway...
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Frank Swarbrick 2006-02-13, 6:55 pm |
| Jesse Liberty<jliberty@libertyassociates.com> 02/13/06 7:29 AM >>>
>First, thank you for reading my books, and please do not read what follows
>as defensive, but rather as an attempt to exchange views with a reader (and
>thus to improve the next edition).
No problem, Jesse! Can I assume you googled your name, and that lead you
here? Or are you a comp.lang.cobol lurker? :-)
>Before I go on, let me also mention that you can find an errata, a FAQ,
>source code and a link to a free private support discussion on my web site
>(http://www.LibertyAssociates.com) - click on Books.
I'll check it out. Thanks.
I[color=darkred]
>
>It is not that I think that classes are "easier" or less advanced, it is
>that I feel strongly that object oriented programming should be taught
>classes-first, from the earliest opportunity; and everything that follows
>should be within the context of classes and objects. In C# Arrays are
>implemented with the Array class, and while they have traditional array
>semantics, they also have properties, methods and so forth. So this was a
>conscious decision.
Makes sense. As I said, I only have my own "learning" experience to base my
opinion on. If you've found that it's better to teach OO earlier on then I
don't think I can argue. To me, objects are somewhat more "advanced"
features of a language. But, as I say, that's very likely just because I
learned them last.
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
>
>Absolutely, Programming C# assumes some experience with a related language
>(C++, Java, etc.)
>
>
>
>Ah, now that would be a failure on my part. Learning C# was targeted at
>novice programmers, and in the next edition we go further to make that
>explicit (adding more introductory material as well as quizzes, etc.)
Well, that latter was based on someone else's opinion. I have not read
_Learning C#_, and since I'm not a beginning programmer I assume I don't
need to.
>
>Oh, I think if written correctly (and I accept that so far I may have
failed
>in doing so) C# makes a terrific first language, if used within the
constext
>of Visual Studio 2005.
As I said, it not being my first language it's hard for me to evaluate
whether or not it would be a good "first language".
Thanks for your input!
Frank
| |
| Pete Dashwood 2006-02-14, 7:55 am |
| Hi Jesse,
I was quite stunned at the good humoured and insightful responses you posted
here.
I haven't read your book but you can rest assured when it comes time to
learn C# it will be your book I go for.
And I think you are right to cover Classes and Objects first and foremost.
Bear in mind that in this forum the majority of the posters are not
"language neutral". There are some highly competent and very experienced
procedural programmers here, and they are harder to teach than people with
no experience at all, because all of us tend to relate what is new, to what
we already know. (I covered this in another post in the same thread, and
also in a thread about components.)
I wish you every success.
Pete.
TOP POST NO MORE BELOW.
<snip>
| |
| Pete Dashwood 2006-02-14, 7:55 am |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:45c6vsF5qmkpU1@individual.net...
> Pete Dashwood<dashwood@enternet.co.nz> 02/10/06 6:37 PM >>>
>
>
>
>
> programming | | |