Conference turris::languages

re: .0

>I'd like to introduce my 10 year old to the concept of programming.
>I have a Pentium PC with both MSDOS and Windows NT and I have Visual
>C++ (version 3.1 I believe). However, I don't believe that C++ is
>a particularly good language to learn first. 
>
>I looked around for LOGO interpreters and picked up one from '87 or so -- 
>it works, but is a little crufty. It's awkward enough to work with that
>I don't think it would provide a `quality learning experience'.
>
>I don't really like BASIC or Pascal or Modula.

Although I historically share your dislike of BASIC as a programming
language, I recommend that you consider Visual Basic anyway.  It doesn't
really have much in common with the BASIC that you (and I) remember.  It
makes it real easy to throw together nice GUIs.

-Hal

Well, if it's really the concept you're after, there are a number of "game"
programs that get this across well; I believe there's a series called
"The Incredible Machine" that lets you build a Rube Goldberg-like contraption
to solve a particular problem.  Of course, since it's ostensibly a game, it's
mostly a graphical approach.

    
    It's difficult to comment without raising a lot of religious ire, but
    IMHO, the most important thing to learn in programming is STRUCTURE.
    Note, I'm not talking about Wirthian "structured programming" or "gotoless
    style", I'm talking about recognising the inherent structure in the
    problem to be solved, then translating that into the data structures
    required to represent those structures (build a model) and (finally!)
    using the *appropriate* control structures to manipulate the data 
    structures. For example, a counted loop is *only* appropriate for scanning
    an array of known size. The C "for" loop is an undirected abomination, 
    unsuitable for any real structure, but attractive to bit heads who like
    "flexibility" and "cleverness" at the expense of clarity.
    
    Approached this way, you don't *need* to teach "gotoless" programming
    since so few problems have discontinuities there will be no need to
    use them. I think the best way to learn about structure is not at
    a terminal, but in the "real" world. Give the kid a wind up clock and
    have them take it apart piece by piece. Eventually they'll be able to
    put it back together again.
    
    Writing CODE is very easy, the trick it to design the right data
    structures to hang the code on. Diving into BASIC or PASCAL or LOGO
    places far too much emphasis on the procedural part and little, if
    any, on the hard part.
    
    Back in the mid 60's Fred Brooks said it (see The Mythical Man Month,
    still relevant today!) "Show me your code and hide your tables and I
    will continue to be mystified. Show me your tables and I won't *need*
    to see your code as it will be obvious". Apart from the quaint use of
    the term "tables" for what we now call "data structures", I reckon this
    is THE secret to programming in any language, then and now.
    
    Choose a language which allows clear and consise descriptions of data
    structures and has a set of obvious control structures to manipulate
    them. Personally, I think that Pascal is the best choice to start with,
    but I'm sure there will be a lot of people who'd argue with that. I
    also think that the *worst* choice is C since even seasoned
    professionals need a program to tell them what a data structure
    declaration actually means, and the control structures are a complete
    dogs breakfast.
    
                                           John Gillings, Sydney CSC

I do appreciate all the responses I am getting here. I agree with
a lot of what you say, John (.3) about `problem solving' being the
most important concept in programming. I have quibbles with some of
your comments:

>For example, a counted loop is *only* appropriate for scanning
>    an array of known size. The C "for" loop is an undirected abomination, 
>    unsuitable for any real structure, but attractive to bit heads who like
>    "flexibility" and "cleverness" at the expense of clarity.
 
Sorry, but I like flexibility -- it allows me to write my code with
the utmost clarity. The for loop does what *I* want it to do, not just
stepping through an array of known size.

Also:

> I
>    also think that the *worst* choice is C since even seasoned
>    professionals need a program to tell them what a data structure
>    declaration actually means, and the control structures are a complete
>    dogs breakfast.

So the dog gets a good start in the morning, right?

re .2: I'll look into ``The Incredible Machine'' -- it sounds like fun.

Andy V

    re .4
    
>Sorry, but I like flexibility -- it allows me to write my code with
>the utmost clarity. The for loop does what *I* want it to do, not just
>stepping through an array of known size.
    
    Clear to whom?
    
    Does anyone else have to read your code later on, years later on?
    Perhaps even yourself?
    
    re .3
    
    Personally I don't see anything wrong with using a C for loop to
    process a linked list i.e. I don't see the need to distinguish a
    variable length "sequence" from a fixed length one, or to distinguish
    whether the underlying implementation of the sequence is an "array" or
    a "linked list". The "for" statement nicely captures the "do it for
    each one" concept.
    
    It is however easy and common to abuse "for". That's why our local C
    guidelines place some constraints on what is recommended practice.
    
    I believe C's type declaration syntax was described as "innovative"
    when it was introduced. I think most people recognise it now as an
    unmitigated disaster.
    
    Maybe someone will come up with a pre-processor that will convert
    readable PASCAL-like declarations into C. (-:
    
#var math : array[1..N] of ^ function( arg : float ) : float;

>Sorry, but I like flexibility -- it allows me to write my code with
>the utmost clarity. The for loop does what *I* want it to do, not just
>stepping through an array of known size.
    
:    Clear to whom?
:    
:    Does anyone else have to read your code later on, years later on?
:    Perhaps even yourself?

I haven't had any complaints yet. :-)

:    Maybe someone will come up with a pre-processor that will convert
:    readable PASCAL-like declarations into C. (-:
    
:#var math : array[1..N] of ^ function( arg : float ) : float;

There is a program that will translate English-like declarations into
C and vice-versa. I don't know if it was announced here or in the
VAX C conference. (CDECL perhaps?)

Andy V

    re .6
    
    Yeah I know about the C -> Comprehensible translator. I'm not sure I was
    aware that it could go the other way. I haven't ever looked at it so I
    don't know how easy it would be to use as a preprocessor.

You can find cdecl (and c++decl) in the comp.sources.unix archives; there's
a copy on gatekeeper somewhere.  They handle declarations and casts, both
encoding and decoding.  A few examples from the test file:

cdecl> declare x as func(ptr to char, int) ret ptr to int
int *x(char *, int )
cdecl> cast x into ptr to func ret int
(int (*)())x
cdecl> explain int *x(args)
declare x as function (args) returning pointer to int
cdecl> explain (char *)x
cast x into pointer to char

(an aside)

How about a version of C that automatically saw "declare", "cast" (and whatever
cdecl's other keywords are) and called cdecl on them, and proceeded to use the
result in the program.  e.g.:

declare x as func(ptr to char a, int b)
{
//the definition of x, using parameters a and b
}

is treated as

int *x(char * a, int b)
{
//the definition of x, using parameters a and b
}

Then that cryptic part of C would no longer be a stumbling block.

	:Karl.