HELP Newbie solve this Problem - Some Lessons?

[Dennis E. Hamilton]

Felix,

I'd like to see people respond to the original challenge to produce a Python
solution to the given problem (once the homework aspect has passed).
Meanwhile, I will use your question as a soap box.  I wouldn't have thought
to work out a FORTRAN solution, as Bieber did, and I am grateful that he
provided that.  The first program that I ever managed to have executed by a
computer was written in FORTRAN (release 1!  Boy, talk about bugs) around
May of 1958.  But I haven't done much with it in a long time.

Here's a little more for those wanting a comparative view of the Fortran
solution to the simple text-analysis problem:

ANATOMY OF A LITTLE FORTRAN STRUCTURE

The statements numbered 10, 20, and 30 are null statements.  They are being
used by Bieber as place-holders for statement numbers.  It is part of his
programming style for this example.  The original use for FORTRAN's
"continue" was to have a place at the end of an iteration body that you
could break (actually, branch) to in order to continue with the next
iteration cycle without performing any further action in the current
iteration.  The non-null "continue" statement in C Language has similar
purpose with a cleaner approach.

If you moved the first continue before the first read statement, the
duplicate read statement before "goto 10" can be eliminated.

Bieber has shown Python-like indentation in his version, which helps
somewhat to make the structure clear.

There are other details stemming from FORTRAN's origin in an era of only 48
character codes (no separate [ and ] so ( and ) serve for all brackets) and
punched-card input organization.   The first six columns of a line have
special rules (the "X" in column 6 on the line below the elsif statement is
FORTRAN's way of introducing a continuation line) and white space outside of
strings is *ignored* to the right of column 6 of any line.

In FORTRAN, statement numbers were required for introduction of
non-sequential control flow.  Block-structured languages (using bracketing
instead of labeling) and structured programming hadn't been invented yet.
Over the years, counterparts of standard program structures have been
blended into the language, and Bieber uses some of those (such as the if ...
then ... else ... endif  structure).

Without getting too far into it, you should be able to discern that the
procedural structure of this and a Python solution are very close. The
details, idiosyncrasies, and common idioms are different, but at this basic
level of computational method, there is not much different.  There are more
syntactic irregularities in FORTRAN, although it can feel that way using
Python too, until you get the principles down.  In FORTRAN, you don't want
to know the principle, which is pretty much an exposure of the
implementation of the original parser, devised before we learned to specify
grammars for programming languages and then produce grammar-based parsers.

SOME LESSONS HERE

1. I want to acknowledge something that Bieber and these exchanges
demonstrate, and that is outstanding about the use of Python.  One of the
first thing I notice about Python is that snippets, using modern e-mail
technology, are easily exchanged, discussed and actually tried out.  I was
struck by that the moment I subscribed to this list, less than two months
ago.  I say that is a *very* big deal.  FORTRAN was the first production
programming language that allowed that kind of collegiality, along with the
introduction of definable functions and subroutines in FORTRAN II.  I always
admired it for that achievement.  The Algol community perpetuated that idea,
and a body of algorithms and practical computational methods was developed
by collaborative refinement over many years.  Young students like Donald
Knuth and Niklaus Wirth published their solutions and other people provided
alternatives, translations, and corrections.  That was a lively and
energetic time, dependent on the willingness of people to publish their
methods and allow them to be debugged in public.  Today's open-source
movement provides a counterpart of that approach, though most problems and
solutions are now much larger and not the kind of thing that one should use
for study and practice, perhaps.  The Python libraries and discussions seem
to have provided a forum that revives what was best about that, and we have
the Internet to support us now.

2. It is easy to forget how much had to be invented, and how much difference
some simple inventions and refinements have provided.  The subroutine,
(i.e., def of anything) that could be reused multiple times, and a way to
code that in machine language, was an invention.  Then there were the
interesting issues about providing different parameters to different
executions, and then accommodation of the impact of recursion and
re-entrance on that, etc., etc.  None of these things stepped out of the
waves in complete purity and completeness of form.  And the lessons and
experiences played out in the work of individuals as well as communities.
Young John Backus worked on the 1950's FORTRAN team (it was at least his
second language development).  He then saw a better way to specify language
grammars when people were working on Algol 58 as an international community
solution for the problem domain that FORTRAN already lived in.  This
inspired the syntactic specification of ALGOL 60, which led to
syntax-oriented parsing and compiling.  Later, John worked out FP, his
approach to functional programming introduced to the world in his Turing
Award lecture.  Functional programming was older than that, but John's
particular approach to it provided a lot to think about.  The idea of
functions that deliver (derived) functions (or closures) as first-class
results is still not well established.  Python barely allows it at all.

3. There is a big difference in the programming styles that are cleanly
supported by post-ALGOL languages.  What we learned about clean styles and
use of inspectable invariants through Spartan control structures can be
honored by *practice* using FORTRAN, but it isn't something that there is
natural support for in the design of the language itself.  An even bigger
difference in the trans-ALGOL languages and in the parallel-evolved LISP
languages is in regard to what is "first class" and what the richness of
objects and types can be.  Those contributions are simply beyond FORTRAN's
conceptual reach, not that people won't hack some of it into the language
anyhow.  Nevertheless, FORTRAN has provided a stable platform for the
collegial development and preservation of high-performance numerical
software for almost 50 years.  That's pretty remarkable.

4. It is also the case that for the toy problem that began this thread, an
archaic programming language works about as well as any other.  It's not so
smooth looking, because FORTRAN doesn't have the smooth kind of free-form
syntax that we are now accustomed to.  But since the problem deals with
immutable scalar values and simple kinds of vectors, lists, and strings,
there is not too much stress on FORTRAN's sweet spot.  It is the case that
the programming languages that have wide currency today, however new, also
manage to preserve the simple usages and structures that were all that the
original programming languages had to offer.  Languages that use descriptive
paradigms often lose this, and become too inaccessible to existing
practitioners and neophytes both.  It can be important to let people build
on what they already know or find easy to comprehend.  The Von Neumann style
of programming may have its limitations, but one advantage is that people
have some familiarity with it in everyday "computational" chores.  There may
be a time to kick over the ladder and ascend to the next level another way.
But leave the ladder down there for the next guy.

-- Dennis

-----Original Message-----
From: python-list-admin at python.org
[mailto:python-list-admin at python.org]On Behalf Of Felix Thibault
Sent: Friday, March 24, 2000 23:15
To: python-list at python.org; python-list at python.org
Subject: Re: HELP Newbie solve this Problem



Are 10, 20, and 30 continuations ?

At 21:10 3/23/00 -0800, Dennis Lee Bieber wrote:
>On Fri, 24 Mar 2000 03:43:38 GMT, race9047 at my-deja.com declaimed the
>following in comp.lang.python:
>	I must be from a different world then... The second part is what
>I'd find easy... even in FORTRAN (maybe too easy in FORTRAN)
>
>	integer	counts(26)	/ 26 * 0 /	! or is it 0 * 26?
>	character	line*132	! set for the longest line the
>					! the data file can contain
>	open(10, file="data", status="old")
>	read(10, '(a132)', iostat=ios) line
>   10	continue
>	if (ios .eq. 0) then
> 	    do 20 i=1, 132		! or the line length max
>		if (line(i:i) .ge. 'a' .and. line(i:i) .le. 'z') then
>			inx = ichar(line(i:i)) - ichar('a') + 1
>			counts(inx) = counts(inx) + 1
>		elseif (line(i:i) .ge. 'A' .and. line(i:i) .le. 'Z')
>     x							then
>			inx = ichar(line(i:i)) - ichar('A') + 1
>			counts(inx) = counts(inx) + 1
>		else
>			continue	! just my style
>		endif
>   20	    continue
>	    read(10, '(a132)', iostat=ios) line
>	goto 10
>	endif
>	close(10)
>	do 30 i=1, 26
>	    print *, char(i), '     ', counts(i)
>   30	continue
>	stop
>
>
>	It would look much cleaner in Python, and I'd use case
>conversion modules rather than the duplicates in the IF statements...
>
>
>--
> > ============================================================== <
> >   wlfraed at ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
> >      wulfraed at dm.net     |       Bestiaria Support Staff       <
> > ============================================================== <
> >        Bestiaria Home Page: http://www.beastie.dm.net/         <
> >            Home Page: http://www.dm.net/~wulfraed/             <
>--
>http://www.python.org/mailman/listinfo/python-list
>
>


--
http://www.python.org/mailman/listinfo/python-list