Re: Should I learn C or Pascal?

Re: Should I learn C or Pascal?

[W. Wesley Groleau (Wes)]

C.A. says:
"You should definitely learn C/C++.  [Untruth deleted] Don't let anyone
guide you wrong."

D.D. retorts:
"The world does _NOT_ end at C or C++, even if Carlos says so."

If enough people in certain places let Carlos guide them wrong, maybe
the world WILL end.  :-)  (Especially if they work for the US NRC.)

Before you flame me for the word "untruth" read what Carlos said, paying
particular attention to the words "finest applications."  Then if you still
disagree, flame on!

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Should I learn C or Pascal?

[Ralph Silverman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 43954 bytes --]


Gabor Egressy (gegressy@uoguelph.ca) wrote:
: Seth Perlman (sperlman@ezo.net) wrote:
: : Hi, all. I'm new to this newsgroup (and most of the comp. hierarchy), so
: : bear with me...

: : First, my situation: I am going to be a senior in high school in the fall.
: : I've been toying with programming computers ever since I learned BASIC on
: : my Commodore 64 at the age of 6. I learned a smattering of C a few years
: : ago, and I took a semester course in school this year which was an intro
: : to Pascal. Sadly, it's the most advanced computer course at my school,
: : which means that I have nowhere else to turn for instruction in
: : programming.


: : *** Should I learn to program in C or Pascal? ***

: Here is a quote from Brian W. Kernighan of "The C Programming Language" fame.
: He is also an internationally respected lecturer who has been there since 
: the inception of UNIX and C.
: "I feel that it is a mistake to use Pascal for anything much beyond its 
: original target. In its pure form, Pascal is a toy language, suitable for 
: teaching but not for real programming."
: Draw your own conclusions.

: To read his essay on this topic point your web browser at
: http://www.lysator.liu.se/c
: There are other articles of interest there.

: --
: ---------------------------------------------------------------------
: Gabor Egressy                gegressy@uoguelph.ca
: Guelph, Ontario              gabor@snowhite.cis.uoguelph.ca
: Canada

: No beast so fierce but knows some touch of pity
: But I know none, And therefore am no beast
:               Richard III., William Shakespeare
: vim : the best editor
: ftp.fu-berlin.de/misc/editors/vim/beta-test
: ---------------------------------------------------------------------

--
***********begin r.s. response***************

From schwarze@imn.th-leipzig.de Fri Apr 12 11:47:54 1996
Date: Wed, 28 Jun 95 11:42:19 +0200
From: rainer schwarze <schwarze@imn.th-leipzig.de>
To: z007400b@bcfreenet.seflin.lib.fl.us

Why Pascal is Not My Favorite Programming Language

Brian W. Kernighan, April 2, 1981
AT&T Bell Laboratories,� Murray Hill, New Jersey 07974

Abstract

The programming language Pascal has become the dominant language of instruction in computer science
education.� It has also strongly influenced languages developed subsequently, in particular Ada. 

Pascal was originally intended primarily as a teaching language, but it has been more and more often
recommended as a language for serious programming as well, for example, for system programming tasks
and even operating systems. 

Pascal, at least in its standard form, is just plain not suitable for serious programming.� This
paper discusses my personal discovery of some of the reasons why. 

1.� Genesis

This paper has its origins in two events - a spate of papers that compare C and Pascal(1, 2, 3, 4)
and a personal attempt to rewrite 'Software Tools'(5) in Pascal. 

Comparing C and Pascal is rather like comparing a Learjet to a Piper Cub - one is meant for getting
something done while the other is meant for learning - so such comparisons tend to be somewhat
farfetched.� But the revision of Software Tools seems a more relevant comparison.� The programs
therein were originally written in Ratfor, a ``structured'' dialect of Fortran implemented by a
preprocessor.� Since Ratfor is really Fortran in disguise, it has few of the assets that Pascal
brings - data types more suited to character processing, data structuring capabilities for better
defining the organization of one's data, and strong typing to enforce telling the truth about the
data. 

It turned out to be harder than I had expected to rewrite the programs in Pascal.� This paper is an
attempt to distill out of the experience some lessons about Pascal's suitability for programming (as
distinguished from learning about programming).� It is not a comparison of Pascal with C or Ratfor. 

The programs were first written in that dialect of Pascal supported by the Pascal interpreter pi
provided by the University of California at Berkeley.� The language is close to the nominal standard
of Jensen and Wirth,(6) with good diagnostics and careful run-time checking.� Since then, the
programs have also been run, unchanged except for new libraries of primitives, on four other systems:
an interpreter from the Free University of Amsterdam (hereinafter referred to as VU, for Vrije
Universiteit), a VAX version of the Berkeley system (a true compiler), a compiler purveyed by
Whitesmiths, Ltd., and UCSD Pascal on a Z80.� All but the last of these Pascal systems are written in
C. 

Pascal is a much-discussed language.� A recent bibliography(7) lists 175 items under the heading of
``discussion, analysis and debate.'' The most often cited papers (well worth reading) are a strong
critique by Habermann(8) and an equally strong rejoinder by Lecarme and Desjardins.(9) The paper by
Boom and DeJong(10) is also good reading.� Wirth's own assessment of Pascal is found in [11].� I have
no desire or ability to summarize the literature; this paper represents my personal observations and
most of it necessarily duplicates points made by others.� I have tried to organize the rest of the
material around the issues of 

   types and scope 
   control flow 
   environment 
   cosmetics 

and within each area more or less in decreasing order of significance. 

To state my conclusions at the outset: Pascal may be an admirable language for teaching beginners how
to program; I have no first-hand experience with that.� It was a considerable achievement for 1968.� 
It has certainly influenced the design of recent languages, of which Ada is likely to be the most
important.� But in its standard form (both current and proposed), Pascal is not adequate for writing
real programs.� It is suitable only for small, self-contained programs that have only trivial
interactions with their environment and that make no use of any software written by anyone else. 

2.� Types and Scopes

Pascal is (almost) a strongly typed language.� Roughly speaking, that means that each object in a
program has a well-defined type which implicitly defines the legal values of and operations on the
object.� The language guarantees that it will prohibit illegal values and operations, by some mixture
of compile- and run-time checking.� Of course compilers may not actually do all the checking implied
in the language definition.� Furthermore, strong typing is not to be confused with dimensional
analysis.� If one defines types 'apple' and 'orange' with 

     type
             apple = integer;
             orange = integer;

then any arbitrary arithmetic expression involving apples and oranges is perfectly legal.

Strong typing shows up in a variety of ways.� For instance, arguments to functions and procedures are
checked for proper type matching.� Gone is the Fortran freedom to pass a floating point number into a
subroutine that expects an integer; this I deem a desirable attribute of Pascal, since it warns of a
construction that will certainly cause an error.

Integer variables may be declared to have an associated range of legal values, and the compiler and
run-time support ensure that one does not put large integers into variables that only hold small
ones.� This too seems like a service, although of course run-time checking does exact a penalty.

Let us move on to some problems of type and scope. 

2.1.� The size of an array is part of its type

If one declares 

     var     arr10 : array [1..10] of integer;
             arr20 : array [1..20] of integer;

then arr10 and arr20 are arrays of 10 and 20 integers respectively.� Suppose we want to write a
procedure 'sort' to sort an integer array.� Because arr10 and arr20 have different types, it is not
possible to write a single procedure that will sort them both. 

The place where this affects Software Tools particularly, and I think programs in general, is that it
makes it difficult indeed to create a library of routines for doing common, general-purpose
operations like sorting. 

The particular data type most often affected is 'array of char', for in Pascal a string is an array
of characters.� Consider writing a function 'index(s,c)' that will return the position in the string
s where the character c first occurs, or zero if it does not.� The problem is how to handle the
string argument of 'index'.� The calls 'index('hello',c)' and 'index('goodbye',c)' cannot both be
legal, since the strings have different lengths.� (I pass over the question of how the end of a
constant string like 'hello' can be detected, because it can't.) The next try is 

     var     temp : array [1..10] of char;
     temp := 'hello';

     n := index(temp,c);

but the assignment to 'temp' is illegal because 'hello' and 'temp' are of different lengths. 

The only escape from this infinite regress is to define a family of routines with a member for each
possible string size, or to make all strings (including constant strings like 'define' ) of the same
length.

The latter approach is the lesser of two great evils.� In 'Tools', a type called 'string' is declared
as 

     type    string = array [1..MAXSTR] of char;

where the constant 'MAXSTR' is ``big enough,'' and all strings in all programs are exactly this
size.� This is far from ideal, although it made it possible to get the programs running.� It does not
solve the problem of creating true libraries of useful routines. 

There are some situations where it is simply not acceptable to use the fixed-size array
representation.� For example, the 'Tools' program to sort lines of text operates by filling up memory
with as many lines as will fit; its running time depends strongly on how full the memory can be
packed.

Thus for 'sort', another representation is used, a long array of characters and a set of indices into
this array: 

     type    charbuf = array [1..MAXBUF] of char;
             charindex = array [1..MAXINDEX] of 0..MAXBUF;

But the procedures and functions written to process the fixed-length representation cannot be used
with the variable-length form; an entirely new set of routines is needed to copy and compare strings
in this representation.� In Fortran or C the same functions could be used for both. 

As suggested above, a constant string is written as 

     'this is a string'

and has the type 'packed array [1..n] of char', where n is the length.� Thus each string literal of
different length has a different type.� The only way to write a routine that will print a message and
clean up is to pad all messages out to the same maximum length: 

     error('short message                    ');
     error('this is a somewhat longer message');

Many commercial Pascal compilers provide a 'string' data type that explicitly avoids the problem; '
string's are all taken to be the same type regardless of size.� This solves the problem for this
single data type, but no other.� It also fails to solve secondary problems like computing the length
of a constant string; another built-in function is the usual solution. 

Pascal enthusiasts often claim that to cope with the array-size problem one merely has to copy some
library routine and fill in the parameters for the program at hand, but the defense sounds weak at
best:(12) 

  ``Since the bounds of an array are part of its type (or, more exactly, of the type of its
  indexes), it is impossible to define a procedure or function which applies to arrays with
  differing bounds.� Although this restriction may appear to be a severe one, the experiences we
  have had with Pascal tend to show that it tends to occur very infrequently.� [...] However, the
  need to bind the size of parametric arrays is a serious defect in connection with the use of
  program libraries.'' 

This botch is the biggest single problem with Pascal.� I believe that if it could be fixed, the
language would be an order of magnitude more usable.� The proposed ISO standard for Pascal(13)
provides such a fix (``conformant array schemas''), but the acceptance of this part of the standard
is apparently still in doubt. 

2.2.� There are no static variables and no initialization

A 'static' variable (often called an 'own' variable in Algol-speaking countries) is one that is
private to some routine and retains its value from one call of the routine to the next.� De facto,
Fortran variables are internal static, except for COMMON; in C there is a 'static' declaration that
can be applied to local variables.� (Strictly speaking, in Fortran 77 one must use SAVE to force the
static attribute.) 

Pascal has no such storage class.� This means that if a Pascal function or procedure intends to
remember a value from one call to another, the variable used must be external to the function or
procedure.� Thus it must be visible to other procedures, and its name must be unique in the larger
scope.� A simple example of the problem is a random number generator: the value used to compute the
current output must be saved to compute the next one, so it must be stored in a variable whose
lifetime includes all calls of the random number generator.� In practice, this is typically the
outermost block of the program.� Thus the declaration of such a variable is far removed from the
place where it is actually used. 

One example comes from the text formatter described in Chapter 7 of 'Tools'.� The variable 'dir'
controls the direction from which excess blanks are inserted during line justification, to obtain
left and right alternately.� In Pascal, the code looks like this: 

     program formatter (...);

     var
             dir : 0..1;     { direction to add extra spaces }
             .
             .
             .
     procedure justify (...);
     begin
             dir := 1 - dir; { opposite direction from last time }
             ...
     end;

             ...

     begin { main routine of formatter }
             dir := 0;
             ...
     end;

The declaration, initialization and use of the variable 'dir' are scattered all over the program,
literally hundreds of lines apart.� In C or Fortran, 'dir' can be made private to the only routine
that needs to know about it: 

             ...
     main()
     {
             ...
     }

             ...

     justify()
     {
             static int dir = 0;

             dir = 1 - dir;
             ...
     }

There are of course many other examples of the same problem on a larger scale; functions for buffered
I/O, storage management, and symbol tables all spring to mind. 

There are at least two related problems.� Pascal provides no way to initialize variables statically
(i.e., at compile time); there is nothing analogous to Fortran's DATA statement or initializers like 

     int dir = 0;

in C.� This means that a Pascal program must contain explicit assignment statements to initialize
variables (like the 

     dir := 0;

above).� This code makes the program source text bigger, and the program itself bigger at run time. 

Furthermore, the lack of initializers exacerbates the problem of too-large scope caused by the lack
of a static storage class.� The time to initialize things is at the beginning, so either the main
routine itself begins with a lot of initialization code, or it calls one or more routines to do the
initializations.� In either case, variables to be initialized must be visible, which means in effect
at the highest level of the hierarchy.� The result is that any variable that is to be initialized has
global scope.

The third difficulty is that there is no way for two routines to share a variable unless it is
declared at or above their least common ancestor.� Fortran COMMON and C's external static storage
class both provide a way for two routines to cooperate privately, without sharing information with
their ancestors. 

The new standard does not offer static variables, initialization or non-hierarchical communication. 

2.3.� Related program components must be kept separate

Since the original Pascal was implemented with a one-pass compiler, the language believes strongly in
declaration before use.� In particular, procedures and functions must be declared (body and all)
before they are used.� The result is that a typical Pascal program reads from the bottom up - all the
procedures and functions are displayed before any of the code that calls them, at all levels.� This
is essentially opposite to the order in which the functions are designed and used. 

To some extent this can be mitigated by a mechanism like the #include facility of C and Ratfor:
source files can be included where needed without cluttering up the program.� #include is not part of
standard Pascal, although the UCB, VU and Whitesmiths compilers all provide it. 

There is also a 'forward' declaration in Pascal that permits separating the declaration of the
function or procedure header from the body; it is intended for defining mutually recursive
procedures.� When the body is declared later on, the header on that declaration may contain only the
function name, and must not repeat the information from the first instance. 

A related problem is that Pascal has a strict order in which it is willing to accept declarations.� 
Each procedure or function consists of 

  label label declarations, if any
  const constant declarations, if any
  type type declarations, if any
  var variable declarations, if any

  procedure and function declarations, if any
  begin
  body of function or procedure
  end

This means that all declarations of one kind (types, for instance) must be grouped together for the
convenience of the compiler, even when the programmer would like to keep together things that are
logically related so as to understand the program better.� Since a program has to be presented to the
compiler all at once, it is rarely possible to keep the declaration, initialization and use of types
and variables close together.� Even some of the most dedicated Pascal supporters agree:(14) 

  ``The inability to make such groupings in structuring large programs is one of Pascal's most
  frustrating limitations.'' 

A file inclusion facility helps only a little here. 

The new standard does not relax the requirements on the order of declarations. 

2.4.� There is no separate compilation

The ``official'' Pascal language does not provide separate compilation, and so each implementation
decides on its own what to do.� Some (the Berkeley interpreter, for instance) disallow it entirely;
this is closest to the spirit of the language and matches the letter exactly.� Many others provide a
declaration that specifies that the body of a function is externally defined.� In any case, all such
mechanisms are non-standard, and thus done differently by different systems. 

Theoretically, there is no need for separate compilation - if one's compiler is very fast (and if the
source for all routines is always available and if one's compiler has a file inclusion facility so
that multiple copies of source are not needed), recompiling everything is equivalent.� In practice,
of course, compilers are never fast enough and source is often hidden and file inclusion is not part
of the language, so changes are time-consuming. 

Some systems permit separate compilation but do not validate consistency of types across the
boundary.� This creates a giant hole in the strong typing.� (Most other languages do no
cross-compilation checking either, so Pascal is not inferior in this respect.)� I have seen at least
one paper (mercifully unpublished) that on page n castigates C for failing to check types across
separate compilation boundaries while suggesting on page n+1 that the way to cope with Pascal is to
compile procedures separately to avoid type checking. 

The new standard does not offer separate compilation. 

2.5.� Some miscellaneous problems of type and scope

Most of the following points are minor irritations, but I have to stick them in somewhere. 

It is not legal to name a non-basic type as the literal formal parameter of a procedure; the
following is not allowed: 

     procedure add10 (var a : array [1..10] of integer);

Rather, one must invent a type name, make a type declaration, and declare the formal parameter to be
an instance of that type: 

     type    a10 = array [1..10] of integer;
     ...
     procedure add10 (var a : a10);

Naturally the type declaration is physically separated from the procedure that uses it.� The
discipline of inventing type names is helpful for types that are used often, but it is a distraction
for things used only once. 

It is nice to have the declaration 'var' for formal parameters of functions and procedures; the
procedure clearly states that it intends to modify the argument.� But the calling program has no way
to declare that a variable is to be modified - the information is only in one place, while two places
would be better.� (Half a loaf is better than none, though - Fortran tells the user nothing about who
will do what to variables.) 

It is also a minor bother that arrays are passed by value by default - the net effect is that every
array parameter is declared 'var' by the programmer more or less without thinking.� If the 'var'
declaration is inadvertently omitted, the resulting bug is subtle. 

Pascal's 'set' construct seems like a good idea, providing notational convenience and some free type
checking.� For example, a set of tests like 

     if (c = blank) or (c = tab) or (c = newline) then ...

can be written rather more clearly and perhaps more efficiently as 

     if c in [blank, tab, newline] then ...

But in practice, set types are not useful for much more than this, because the size of a set is
strongly implementation dependent (probably because it was so in the original CDC implementation: 59
bits).� For example, it is natural to attempt to write the function 'isalphanum(c)' (``is c
alphanumeric?'') as 

     { isalphanum(c) -- true if c is letter or digit }
     function isalphanum (c : char) : boolean;
     begin
             isalphanum := c in ['a'..'z', 'A'..'Z', '0'..'9']
     end;

But in many implementations of Pascal (including the original) this code fails because sets are just
too small.� Accordingly, sets are generally best left unused if one intends to write portable
programs.� (This specific routine also runs an order of magnitude slower with sets than with a range
test or array reference.) 

2.6.� There is no escape

There is no way to override the type mechanism when necessary, nothing analogous to the ``cast''
mechanism in C.� This means that it is not possible to write programs like storage allocators or I/O
systems in Pascal, because there is no way to talk about the type of object that they return, and no
way to force such objects into an arbitrary type for another use.� (Strictly speaking, there is a
large hole in the type-checking near variant records, through which some otherwise illegal type
mismatches can be obtained.) 

3.� Control Flow

The control flow deficiencies of Pascal are minor but numerous - the death of a thousand cuts, rather
than a single blow to a vital spot.

There is no guaranteed order of evaluation of the logical operators 'and' and 'or' - nothing like &&
and || in C.� This failing, which is shared with most other languages, hurts most often in loop
control: 

     while (i <= XMAX) and (x[i] > 0) do ...

is extremely unwise Pascal usage, since there is no way to ensure that i is tested before x[i] is. 

By the way, the parentheses in this code are mandatory - the language has only four levels of
operator precedence, with relationals at the bottom. 

There is no 'break' statement for exiting loops.� This is consistent with the one entry-one exit
philosophy espoused by proponents of structured programming, but it does lead to nasty
circumlocutions or duplicated code, particularly when coupled with the inability to control the order
in which logical expressions are evaluated.� Consider this common situation, expressed in C or
Ratfor: 

     while (getnext(...)) {
             if (something)
                     break
             rest of loop
     }

With no 'break' statement, the first attempt in Pascal is 

     done := false;
     while (not done) and (getnext(...)) do
             if something then
                     done := true
             else begin
                     rest of loop
             end

But this doesn't work, because there is no way to force the ``not done'' to be evaluated before the
next call of 'getnext'.� This leads, after several false starts, to 

     done := false;
     while not done do begin
             done := getnext(...);
             if something then
                     done := true
             else if not done then begin
                     rest of loop
             end
     end

Of course recidivists can use a 'goto' and a label (numeric only and it has to be declared) to exit a
loop.� Otherwise, early exits are a pain, almost always requiring the invention of a boolean variable
and a certain amount of cunning.� Compare finding the last non-blank in an array in Ratfor: 

     for (i = max; i > 0; i = i - 1)
             if (arr(i) != ' ')
                     break

with Pascal: 

     done := false;
     i := max;
     while (i > 0) and (not done) do
             if arr[i] = ' ' then
                     i := i - 1
             else
                     done := true;

The index of a 'for' loop is undefined outside the loop, so it is not possible to figure out whether
one went to the end or not.� The increment of a 'for' loop can only be +1 or -1, a minor restriction.

There is no 'return' statement, again for one in-one out reasons.� A function value is returned by
setting the value of a pseudo-variable (as in Fortran), then falling off the end of the function.� 
This sometimes leads to contortions to make sure that all paths actually get to the end of the
function with the proper value.� There is also no standard way to terminate execution except by
reaching the end of the outermost block, although many implementations provide a 'halt' that causes
immediate termination. 

The 'case' statement is better designed than in C, except that there is no 'default' clause and the
behavior is undefined if the input expression does not match any of the cases.� This crucial omission
renders the 'case' construct almost worthless.� In over 6000 lines of Pascal in 'Software Tools in
Pascal', I used it only four times, although if there had been a 'default', a 'case' would have
served in at least a dozen places.

The new standard offers no relief on any of these points. 

4.� The Environment

The Pascal run-time environment is relatively sparse, and there is no extension mechanism except
perhaps source-level libraries in the ``official'' language. 

Pascal's built-in I/O has a deservedly bad reputation.� It believes strongly in record-oriented input
and output.� It also has a look-ahead convention that is hard to implement properly in an interactive
environment.� Basically, the problem is that the I/O system believes that it must read one record
ahead of the record that is being processed.� In an interactive system, this means that when a
program is started, its first operation is to try to read the terminal for the first line of input,
before any of the program itself has been executed.� But in the program 

     write('Please enter your name: ');
     read(name);
     ...

read-ahead causes the program to hang, waiting for input before printing the prompt that asks for it.

It is possible to escape most of the evil effects of this I/O design by very careful implementation,
but not all Pascal systems do so, and in any case it is relatively costly. 

The I/O design reflects the original operating system upon which Pascal was designed; even Wirth
acknowledges that bias, though not its defects.(15) It is assumed that text files consist of records,
that is, lines of text.� When the last character of a line is read, the built-in function 'eoln'
becomes true; at that point, one must call 'readln' to initiate reading a new line and reset 'eoln'.�
Similarly, when the last character of the file is read, the built-in 'eof' becomes true.� In both
cases, 'eoln' and 'eof' must be tested before each 'read' rather than after. 

Given this, considerable pains must be taken to simulate sensible input.� This implementation of '
getc' works for Berkeley and VU I/O systems, but may not necessarily work for anything else: 

     { getc -- read character from standard input }
     function getc (var c : character) : character;
     var
             ch : char;
     begin
             if eof then
                     c := ENDFILE
             else if eoln then begin
                     readln;
                     c := NEWLINE
             end

             else begin
                     read(ch);
                     c := ord(ch)
             end;
             getc := c
     end;

The type 'character' is not the same as 'char', since ENDFILE and perhaps NEWLINE are not legal
values for a 'char' variable. 

There is no notion at all of access to a file system except for predefined files named by (in effect)
logical unit number in the 'program' statement that begins each program.� This apparently reflects
the CDC batch system in which Pascal was originally developed.� A file variable 

     var fv : file of type

is a very special kind of object - it cannot be assigned to, nor used except by calls to built-in
procedures like 'eof', 'eoln', 'read', 'write', 'reset' and 'rewrite'.� ('reset' rewinds a file and
makes it ready for rereading; 'rewrite' makes a file ready for writing.) 

Most implementations of Pascal provide an escape hatch to allow access to files by name from the
outside environment, but not conveniently and not standardly.� For example, many systems permit a
filename argument in calls to 'reset' and 'rewrite': 

     reset(fv, filename);

But 'reset' and 'rewrite' are procedures, not functions - there is no status return and no way to
regain control if for some reason the attempted access fails.� (UCSD provides a compile-time flag
that disables the normal abort.) And since fv's cannot appear in expressions like 

     reset(fv, filename);
     if fv = failure then ...

there is no escape in that direction either.� This straitjacket makes it essentially impossible to
write programs that recover from mis-spelled file names, etc.� I never solved it adequately in the
'Tools' revision. 

There is no notion of access to command-line arguments, again probably reflecting Pascal's
batch-processing origins.� Local routines may allow it by adding non-standard procedures to the
environment. 

Since it is not possible to write a general-purpose storage allocator in Pascal (there being no way
to talk about the types that such a function would return), the language has a built-in procedure
called 'new' that allocates space from a heap.� Only defined types may be allocated, so it is not
possible to allocate, for example, arrays of arbitrary size to hold character strings.� The pointers
returned by 'new' may be passed around but not manipulated: there is no pointer arithmetic.� There is
no way to regain control if storage runs out.

The new standard offers no change in any of these areas. 

5.� Cosmetic Issues

Most of these issues are irksome to an experienced programmer, and some are probably a nuisance even
to beginners.� All can be lived with. 

Pascal, in common with most other Algol-inspired languages, uses the semicolon as a statement
separator rather than a terminator (as it is in PL/I and C).� As a result one must have a reasonably
sophisticated notion of what a statement is to put semicolons in properly.� Perhaps more important,
if one is serious about using them in the proper places, a fair amount of nuisance editing is
needed.� Consider the first cut at a program: 

     if a then
             b;
     c;

But if something must be inserted before b, it no longer needs a semicolon, because it now precedes
an 'end': 

     if a then begin
             b0;
             b
     end;
     c;

Now if we add an 'else', we must remove the semicolon on the 'end': 

     if a then begin
             b0;
             b
     end
     else
             d;
     c;

And so on and so on, with semicolons rippling up and down the program as it evolves. 

One generally accepted experimental result in programmer psychology is that semicolon as separator is
about ten times more prone to error than semicolon as terminator.(16) (In Ada,(17) the most
significant language based on Pascal, semicolon is a terminator.) Fortunately, in Pascal one can
almost always close one's eyes and get away with a semicolon as a terminator.� The exceptions are in
places like declarations, where the separator vs. terminator problem doesn't seem as serious anyway,
and just before 'else', which is easy to remember.

C and Ratfor programmers find 'begin' and 'end' bulky compared to { and }. 

A function name by itself is a call of that function; there is no way to distinguish such a function
call from a simple variable except by knowing the names of the functions.� Pascal uses the Fortran
trick of having the function name act like a variable within the function, except that where in
Fortran the function name really is a variable, and can appear in expressions, in Pascal, its
appearance in an expression is a recursive invocation: if f is a zero-argument function, 'f:=f+1' is
a recursive call of f. 

There is a paucity of operators (probably related to the paucity of precedence levels).� In
particular, there are no bit-manipulation operators (AND, OR, XOR, etc.).� I simply gave up trying to
write the following trivial encryption program in Pascal: 

     i := 1;
     while getc(c) <> ENDFILE do begin
             putc(xor(c, key[i]));
             i := i mod keylen + 1
     end

because I couldn't write a sensible 'xor' function.� The set types help a bit here (so to speak), but
not enough; people who claim that Pascal is a system programming language have generally overlooked
this point.� For example, [18, p. 685] 

  ``Pascal is at the present time [1977] the best language in the public domain for purposes of
  system programming and software implementation.'' 

seems a bit naive. 

There is no null string, perhaps because Pascal uses the doubled quote notation to indicate a quote
embedded in a string: 

     'This is a '' character'

There is no way to put non-graphic symbols into strings.� In fact, non-graphic characters are
unpersons in a stronger sense, since they are not mentioned in any part of the standard language.� 
Concepts like newlines, tabs, and so on are handled on each system in an 'ad hoc' manner, usually by
knowing something about the character set (e.g., ASCII newline has decimal value 10). 

There is no macro processor.� The 'const' mechanism for defining manifest constants takes care of
about 95 percent of the uses of simple #define statements in C, but more involved ones are hopeless.�
It is certainly possible to put a macro preprocessor on a Pascal compiler.� This allowed me to
simulate a sensible 'error' procedure as 

     #define error(s)begin writeln(s); halt end

('halt' in turn might be defined as a branch to the end of the outermost block.) Then calls like 

     error('little string');
     error('much bigger string');

work since 'writeln' (as part of the standard Pascal environment) can handle strings of any size.� It
is unfortunate that there is no way to make this convenience available to routines in general. 

The language prohibits expressions in declarations, so it is not possible to write things like 

      const   SIZE = 10;
      type    arr = array [1..SIZE+1] of integer;

or even simpler ones like 

      const   SIZE = 10;
              SIZE1 = SIZE + 1;

6.� Perspective

The effort to rewrite the programs in 'Software Tools' started in March, 1980, and, in fits and
starts, lasted until January, 1981.� The final product(19) was published in June, 1981.� During that
time I gradually adapted to most of the superficial problems with Pascal (cosmetics, the inadequacies
of control flow), and developed imperfect solutions to the significant ones (array sizes, run-time
environment). 

The programs in the book are meant to be complete, well-engineered programs that do non-trivial
tasks.� But they do not have to be efficient, nor are their interactions with the operating system
very complicated, so I was able to get by with some pretty kludgy solutions, ones that simply
wouldn't work for real programs. 

There is no significant way in which I found Pascal superior to C, but there are several places where
it is a clear improvement over Ratfor.� Most obvious by far is recursion: several programs are much
cleaner when written recursively, notably the pattern-search, quicksort, and expression evaluation. 

Enumeration data types are a good idea.� They simultaneously delimit the range of legal values and
document them.� Records help to group related variables.� I found relatively little use for pointers.

Boolean variables are nicer than integers for Boolean conditions; the original Ratfor programs
contained some unnatural constructions because Fortran's logical variables are badly designed. 

Occasionally Pascal's type checking would warn of a slip of the hand in writing a program; the
run-time checking of values also indicated errors from time to time, particularly subscript range
violations. 

Turning to the negative side, recompiling a large program from scratch to change a single line of
source is extremely tiresome; separate compilation, with or without type checking, is mandatory for
large programs. 

I derived little benefit from the fact that characters are part of Pascal and not part of Fortran,
because the Pascal treatment of strings and non-graphics is so inadequate.� In both languages, it is
appallingly clumsy to initialize literal strings for tables of keywords, error messages, and the
like. 

The finished programs are in general about the same number of source lines as their Ratfor
equivalents.� At first this surprised me, since my preconception was that Pascal is a wordier and
less expressive language. The real reason seems to be that Pascal permits arbitrary expressions in
places like loop limits and subscripts where Fortran (that is, portable Fortran 66) does not, so some
useless assignments can be eliminated; furthermore, the Ratfor programs declare functions while
Pascal ones do not. 

To close, let me summarize the main points in the case against Pascal. 

1. Since the size of an array is part of its type, it is not possible to write general-purpose
   routines, that is, to deal with arrays of different sizes.� In particular, string handling is very
   difficult. 
2. The lack of static variables, initialization and a way to communicate non-hierarchically combine
   to destroy the ``locality'' of a program - variables require much more scope than they ought to. 
3. The one-pass nature of the language forces procedures and functions to be presented in an
   unnatural order; the enforced separation of various declarations scatters program components that
   logically belong together. 
4. The lack of separate compilation impedes the development of large programs and makes the use of
   libraries impossible. 
5. The order of logical expression evaluation cannot be controlled, which leads to convoluted code
   and extraneous variables. 
6. The 'case' statement is emasculated because there is no default clause. 
7. The standard I/O is defective.� There is no sensible provision for dealing with files or program
   arguments as part of the standard language, and no extension mechanism. 
8. The language lacks most of the tools needed for assembling large programs, most notably file
   inclusion. 
9. There is no escape. 

This last point is perhaps the most important.� The language is inadequate but circumscribed, because
there is no way to escape its limitations.� There are no casts to disable the type-checking when
necessary.� There is no way to replace the defective run-time environment with a sensible one, unless
one controls the compiler that defines the ``standard procedures.'' The language is closed. 

People who use Pascal for serious programming fall into a fatal trap.

Because the language is so impotent, it must be extended.� But each group extends Pascal in its own
direction, to make it look like whatever language they really want.� Extensions for separate
compilation, Fortran-like COMMON, string data types, internal static variables, initialization, octal
numbers, bit operators, etc., all add to the utility of the language for one group, but destroy its
portability to others. 

I feel that it is a mistake to use Pascal for anything much beyond its original target.� In its pure
form, Pascal is a toy language, suitable for teaching but not for real programming. 

Acknowledgments

I am grateful to Al Aho, Al Feuer, Narain Gehani, Bob Martin, Doug McIlroy, Rob Pike, Dennis Ritchie,
Chris Van Wyk and Charles Wetherell for helpful criticisms of earlier versions of this paper. 

1. Feuer, A. R. and N. H. Gehani, ``A Comparison of the Programming Languages C and Pascal - Part I:
   Language Concepts,'' Bell Labs internal memorandum (September 1979). 
2. N. H. Gehani and A. R. Feuer, ``A Comparison of the Programming Languages C and Pascal - Part II:
   Program Properties and Programming Domains,'' Bell Labs internal memorandum (February 1980). 
3. P. Mateti, ``Pascal versus C: A Subjective Comparison,'' Language Design and Programming
   Methodology Symposium, Springer-Verlag, Sydney, Australia (September 1979). 
4. A. Springer, ``A Comparison of Language C and Pascal,'' IBM Technical Report G320-2128, Cambridge
   Scientific Center (August 1979). 
5. B. W. Kernighan and P. J. Plauger, Software Tools, Addison-Wesley, Reading, Mass. (1976). 
6. K. Jensen, Pascal User Manual and Report, Springer-Verlag (1978). (2nd edition.) 
7. David V. Moffat, ``A Categorized Pascal Bibliography,'' SIGPLAN Notices 15(10), pp. 63-75 (October
   1980). 
8. A. N. Habermann, ``Critical Comments on the Programming Language Pascal,'' Acta Informatica 3, pp.
   47-57 (1973). 
9. O. Lecarme and P. Desjardins, ``More Comments on the Programming Language Pascal,'' Acta
   Informatica 4, pp. 231-243 (1975). 
10. H. J. Boom and E. DeJong, ``A Critical Comparison of Several Programming Language
   Implementations,'' Software Practice and Experience 10(6), pp. 435-473 (June 1980). 
11. N. Wirth, ``An Assessment of the Programming Language Pascal,'' IEEE Transactions on Software
   Engineering SE-1(2), pp. 192-198 (June, 1975). 
12. O. Lecarme and P. Desjardins, ibid, p. 239. 
13. A. M. Addyman, ``A Draft Proposal for Pascal,'' SIGPLAN Notices 15(4), pp. 1-66 (April 1980). 
14. J. Welsh, W. J. Sneeringer, and C. A. R. Hoare, ``Ambiguities and Insecurities in Pascal,''
   Software Practice and Experience 7, pp. 685-696 (1977). 
15. N. Wirth, ibid., p. 196. 
16. J. D. Gannon and J. J. Horning, ``Language Design for Programming Reliability,'' IEEE Trans.
   Software Engineering SE-1(2), pp. 179-191 (June 1975). 
17. J. D. Ichbiah, et al, ``Rationale for the Design of the Ada Programming Language,'' SIGPLAN
   Notices 14(6) (June 1979). 
18. J. Welsh, W. J. Sneeringer, and C. A. R. Hoare, ibid. 
19. B. W. Kernighan and P. J. Plauger, Software Tools in Pascal, Addison-Wesley (1981). 



***********end r.s. response*****************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[Steve Sobol]

z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman) wrote:

>Gabor Egressy (gegressy@uoguelph.ca) wrote:
>: Seth Perlman (sperlman@ezo.net) wrote:

Ralph,

This thing is huge... isn't it on a web page somewhere? :-/

>: : bear with me...

>: : First, my situation: I am going to be a senior in high school in the fall.

-- 
North Shore Technologies		Me == Steve Sobol == sjsobol@nstc.com
Web Consulting, PC Sales		Personal page: http://junior.apk.net/~sjsobol
Custom Win3.1/Win95 Programming 	Corporate page: http://www.nstc.com/nstc
        				(both under construction... bear with me..)
                    (Speak for North Shore? I *AM* North Shore. :)

Re: Should I learn C or Pascal?

[Lee Crites]

z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman) wrote:
>Gabor Egressy (gegressy@uoguelph.ca) wrote:
>: Seth Perlman (sperlman@ezo.net) wrote:
>: : First, my situation: I am going to be a senior in high school in the fall.
>: : I've been toying with programming computers ever since I learned BASIC on
>: : my Commodore 64 at the age of 6. I learned a smattering of C a few years
>: : ago, and I took a semester course in school this year which was an intro
>: : to Pascal. Sadly, it's the most advanced computer course at my school,
>: : which means that I have nowhere else to turn for instruction in
>: : programming.
>
>
>: : *** Should I learn to program in C or Pascal? ***
>
>: Here is a quote from Brian W. Kernighan of "The C Programming Language" fame.
>: He is also an internationally respected lecturer who has been there since 
>: the inception of UNIX and C.
>: "I feel that it is a mistake to use Pascal for anything much beyond its 
>: original target. In its pure form, Pascal is a toy language, suitable for 
>: teaching but not for real programming."
>: Draw your own conclusions.

Before you "draw your own conclusions," keep in mind that Kernighan is one of the 
founding voices in c.  A more biased opinion could hardly be found.  Ask Wirth what 
he thinks about the C vs Pascal dispute.  It would be the same kind of thing.

Also keep in mind that this rather lengthy diatribe was comparing c with the 
'standard' pascal, not what it has become.  Today's pascal is as different from what 
was being discussed as today's c++ is from the old c.

Both languages are evolving and becoming more and more of what the programmers need. 
Part and parcel to the "should I learn this or that" question, though, is the 
thought that one can do without knowing one of them.  I believe this is wrong.  The 
real answer, from my perspective, is you should learn BOTH, and learn both WELL!

After all, these c vs pascal disputes are chiefly religious in nature.  Dispense 
with the arm waving and name calling, either one will do for most applications.  I 
have heard some tell me how some application could only be written in one or the 
other, but so far nobody's been able to really convince me.

I remember the arguments about how COBOL was the ultimate language and nothing else 
could be needed.  I've been hearing these rather anal arguments for nearly 20 years. 
(I started learning programming in college in 1976)

So please, don't trap yourself in the one-or-the-other mindset.  Learn both.  You 
will be a better programmer -- and a more valuable employee -- for it.

Lee Crites
Computer Mavericks

Re: Should I learn C or Pascal?

[David Verschoore]

[snip]
> So please, don't trap yourself in the one-or-the-other mindset.  Learn
both.  You 
> will be a better programmer -- and a more valuable employee -- for it.
> 
> Lee Crites
> Computer Mavericks
> 
Bravo!
I would like to point out that a language is a tool.  Any tool used
improperly will give less than expected results.
What makes a good programmer is not necessarily the language but the
technique in which it is used. Lean a 
language well. but more importantly, learn the technique of good
programming practices.  Once you develop your 
personal 'technique', try another language and see how well your
techniques port to the new language.

An artist is more likely able to paint a masterpiece than the man selling
the paints. ;-)

You may want to check out Steve McConnell's book Code Complete as you
learn your target language.
-Dave

Re: Should I learn C or Pascal?

[Mark McKinney]

Dave Vershore wrote:

>What makes a good programmer is not necessarily the language but the
>technique in which it is used. Lean a 
>language well. but more importantly, learn the technique of good
>programming practices.

This raises a big concern I have always had about how programming is taugh 
in general. Problem solving techniques, style, methodologies etc. should 
be taught or learned prior to a programming language. The "this is how you 
do it and then this is how yu do it well" approach seems highly 
ineffective. 
-Mark

Re: Should I learn C or Pascal?

[Philip Brashear]

In article <4sjmtk$e95@herald.concentric.net>,
Mark  McKinney  <mckmark@mail.concentric.net> wrote:
>
>This raises a big concern I have always had about how programming is taugh 
>in general. Problem solving techniques, style, methodologies etc. should 
>be taught or learned prior to a programming language. The "this is how you 
>do it and then this is how yu do it well" approach seems highly 
>ineffective. 
>-Mark
>
>

This reminds me of the high school English teacher who said "Teach them
grammar in elementary school, and I'll teach them how to write (compose)."

How do you learn grammar without writing (composing)?  How do you learn
problem solving techniques, style, methodologies, etc. without actually
solving problems, creating programs according to certain styles, using
a programming language to apply a methodology?  Might as well try to teach
a child the mathematical discipline of knot theory before teaching her how
to tie her shoes!

Phil B

Re: Should I learn C or Pascal?

[John A Hughes]

In article <4sntoi$i71@ns1.sw-eng.falls-church.va.us>,
Philip Brashear <brashear@ns1.sw-eng.falls-church.va.us> wrote:
>In article <4sjmtk$e95@herald.concentric.net>,
>Mark  McKinney  <mckmark@mail.concentric.net> wrote:
>>
>>This raises a big concern I have always had about how programming is taugh 
>>in general. Problem solving techniques, style, methodologies etc. should 
>>be taught or learned prior to a programming language. The "this is how you 
>>do it and then this is how yu do it well" approach seems highly 
>>ineffective. 
>>-Mark
>
>This reminds me of the high school English teacher who said "Teach them
>grammar in elementary school, and I'll teach them how to write (compose)."
>
>How do you learn grammar without writing (composing)?  How do you learn
>problem solving techniques, style, methodologies, etc. without actually
>solving problems, creating programs according to certain styles, using
>a programming language to apply a methodology?  Might as well try to teach
>a child the mathematical discipline of knot theory before teaching her how
>to tie her shoes!

I personally think the one doesn't preclude the other. Programming
*is* a little more than just problem solving. A lot of times people
around here have bizarre bugs they can't find that end up depending on
the language-- some flaky syntax fact or a well-known obscure
implementation detail (and yes, I did intend to write that--
computation is rife with well-known obscurities :). All that needs to
be learned all at once. What doesn't need to be learned is linguistic
fossilization. The particular language doesn't matter much except as a
source of trivia; however, the PROCESS of USING a precise language
PROPERLY is very important.

I think classroom-style instruction for computer science is bogus. The
typical ratio of lecture to lab should be inverted in my opinion-- 3
labs to each lecture. And lectures should introduce the labs and then
discuss problems in the labs, and the broader significance of problems
people had or differences in various solutions, NOT the other way
around, where labs are some kind of vesigial "illustration" of lecture
concepts.

I also think at more advanced levels the labs should really teach
collaborative programming, where everyone must work on a large
project, everyone must discuss how the project should be broken up,
and maybe teams should have to trade software components during
implementation to teach them how to write maintainable code.

This kind of class would be very hard to design and teach, and would
be a total blast.


jah

Re: Should I learn C or Pascal?

[Randy Kaelber]

John A Hughes (jah@cais.cais.com) wrote:
> I think classroom-style instruction for computer science is bogus. The
> typical ratio of lecture to lab should be inverted in my opinion-- 3
> labs to each lecture. And lectures should introduce the labs and then
> discuss problems in the labs, and the broader significance of problems
> people had or differences in various solutions, NOT the other way
> around, where labs are some kind of vesigial "illustration" of lecture
> concepts.

I think I agree with the concepts you're suggesting, but I still feel 
there is need for lecture... maybe 2 lec/3 lab, especially in more 
concentrated classes (database, Operating systems, automata, compilers, 
balh blah blah). But absolutely I tired of having 8 or 9 dinky little 
assignments through a semester. Give me one or two BIG projects and make 
it half my grade.

> I also think at more advanced levels the labs should really teach
> collaborative programming, where everyone must work on a large
> project, everyone must discuss how the project should be broken up,
> and maybe teams should have to trade software components during
> implementation to teach them how to write maintainable code.

YES! YES! YES! YES!!! Absolutely! Very little software development 
happens in a vacuum. The team concept should be highly stressed. Getting 
a certificate in computer programming from Sally Struthers does not a 
computing professional make. One needs to be able to maintain code and be 
able to write maintainable code. I think that's why new programmers get 
maintenance jobs... so they can see what maintainable and unmaintainable 
code looks like. Plus, all the experienced people want to develop new 
systems, not maintain old code. :)

> This kind of class would be very hard to design and teach, and would
> be a total blast.

God knows I'd love to try it! Teach it, take it, I don't care.

--
Randy Kaelber:  kaelbers@muohio.edu
DARS Programmer/Analyst, Miami University, Oxford, OH 45056 USA
http://avian.dars.muohio.edu/~kaelbers/

Unsolicited commercial E-mail will be spell checked for a fee of $50.
Sending such mail constitutes acceptance of these terms. 

Re: Should I learn C or Pascal?

[Ralph Silverman]

Randy Kaelber (kaelbers@avian.dars.muohio.edu) wrote:
: John A Hughes (jah@cais.cais.com) wrote:
: > I think classroom-style instruction for computer science is bogus. The
: > typical ratio of lecture to lab should be inverted in my opinion-- 3
: > labs to each lecture. And lectures should introduce the labs and then
: > discuss problems in the labs, and the broader significance of problems
: > people had or differences in various solutions, NOT the other way
: > around, where labs are some kind of vesigial "illustration" of lecture
: > concepts.

: I think I agree with the concepts you're suggesting, but I still feel 
: there is need for lecture... maybe 2 lec/3 lab, especially in more 
: concentrated classes (database, Operating systems, automata, compilers, 
: balh blah blah). But absolutely I tired of having 8 or 9 dinky little 
: assignments through a semester. Give me one or two BIG projects and make 
: it half my grade.

: > I also think at more advanced levels the labs should really teach
: > collaborative programming, where everyone must work on a large
: > project, everyone must discuss how the project should be broken up,
: > and maybe teams should have to trade software components during
: > implementation to teach them how to write maintainable code.

: YES! YES! YES! YES!!! Absolutely! Very little software development 
: happens in a vacuum. The team concept should be highly stressed. Getting 
: a certificate in computer programming from Sally Struthers does not a 
: computing professional make. One needs to be able to maintain code and be 
: able to write maintainable code. I think that's why new programmers get 
: maintenance jobs... so they can see what maintainable and unmaintainable 
: code looks like. Plus, all the experienced people want to develop new 
: systems, not maintain old code. :)

: > This kind of class would be very hard to design and teach, and would
: > be a total blast.

: God knows I'd love to try it! Teach it, take it, I don't care.

: --
: Randy Kaelber:  kaelbers@muohio.edu
: DARS Programmer/Analyst, Miami University, Oxford, OH 45056 USA
: http://avian.dars.muohio.edu/~kaelbers/

: Unsolicited commercial E-mail will be spell checked for a fee of $50.
: Sending such mail constitutes acceptance of these terms. 


--
*************begin r.s. response***************

	done both...
	if the career you are looking at
	involves working in groups...
	then there is plenty of time
	for that later...
	would suggest...
	enjoy programming by,
	and for,
	yourself...
	while you can...

*************end r.s. response*****************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[StHeller]

In article <4taik0$1o2q@rose.muohio.edu>, kaelbers@avian.dars.muohio.edu
(Randy Kaelber) writes:

>God knows I'd love to try it! Teach it, take it, I don't care.
  Yes, it has been a lot of fun for both the teacher (me) and my students.
They
also have learned a lot about programming in the process.

Steve Heller
http://ourworld.compuserve.com/homepages/steve_heller/

Re: Should I learn C or Pascal?

[Anthony Kanner]

David Verschoore wrote:
> 
> [snip]
> > So please, don't trap yourself in the one-or-the-other mindset.  Learn
> both.  You
> > will be a better programmer -- and a more valuable employee -- for it.
> >
> > Lee Crites
> > Computer Mavericks
> >
> Bravo!
> I would like to point out that a language is a tool.  Any tool used
> improperly will give less than expected results.
> What makes a good programmer is not necessarily the language but the
> technique in which it is used. Lean a
> language well. but more importantly, learn the technique of good
> programming practices.  Once you develop your
> personal 'technique', try another language and see how well your
> techniques port to the new language.
> 
> An artist is more likely able to paint a masterpiece than the man selling
> the paints. ;-)
> 
> You may want to check out Steve McConnell's book Code Complete as you
> learn your target language.
> -Dave

I most definitely agree with Dave.  Code Complete is a GREAT book. I am on page 100 and 
it is one of the best books on computer programming I have read.

Anthony
-- 
----------------------------------------------------
saturn/psx/snes
kanner@pacificnet.net
check out my web site at 
http://www.pacificnet.net/~kanner/
----------------------------------------------------

Re: Should I learn C or Pascal?

[TRAN PHAN ANH]

Absolutely right.

But Pascal or C was the original question.  Start with C is what I say.  
Better yet, why not C++ then move on to JAVA?

Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn 
Pascal.  Actually, if one has a solid foundation in programming techniques and
a solid understanding of one or two languages, one can aquire a working 
knowledge of any language in no time.

From my point of view, right now, C/C++, and JAVA on a resume is hotter 
than Pascal.

Anh


In article <01bb73e3.1c6a0060$6bf467ce@dave.iceslimited.com>, "David Verschoore" <dversch@ibm.net> writes:
> [snip]
>> So please, don't trap yourself in the one-or-the-other mindset.  Learn
> both.  You 
>> will be a better programmer -- and a more valuable employee -- for it.
>> 
>> Lee Crites
>> Computer Mavericks
>> 
> Bravo!
> I would like to point out that a language is a tool.  Any tool used
> improperly will give less than expected results.
> What makes a good programmer is not necessarily the language but the
> technique in which it is used. Lean a 
> language well. but more importantly, learn the technique of good
> programming practices.  Once you develop your 
> personal 'technique', try another language and see how well your
> techniques port to the new language.
> 
> An artist is more likely able to paint a masterpiece than the man selling
> the paints. ;-)
> 
> You may want to check out Steve McConnell's book Code Complete as you
> learn your target language.
> -Dave

Re: Should I learn C or Pascal?

[Andy Askey]

anh@kuhub.cc.ukans.edu (TRAN PHAN ANH) wrote:

>Absolutely right.

>But Pascal or C was the original question.  Start with C is what I say.  
>Better yet, why not C++ then move on to JAVA?

>Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn 
>Pascal.  Actually, if one has a solid foundation in programming techniques and
>a solid understanding of one or two languages, one can aquire a working 
>knowledge of any language in no time.

>From my point of view, right now, C/C++, and JAVA on a resume is hotter 
>than Pascal.

>Anh


Absolutely right, Anh.  I started with Fortran, taught myself C and
C++ in about a month or so, and then picked up Ada in a couple weeks.

Andy Askey
--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com

Re: Should I learn C or Pascal?

[steidl]

In <4srb1i$n04@news-e2c.gnn.com>, ajaskey@gnn.com (Andy Askey) writes:
>anh@kuhub.cc.ukans.edu (TRAN PHAN ANH) wrote:
>
>>Absolutely right.
>
>>But Pascal or C was the original question.  Start with C is what I say.  
>>Better yet, why not C++ then move on to JAVA?
>
>>Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn 
>>Pascal.  Actually, if one has a solid foundation in programming techniques and
>>a solid understanding of one or two languages, one can aquire a working 
>>knowledge of any language in no time.

It seems naive to think that one could have a "solid foundation in
programming techniques" if one only has a "solid understanding of one
or two languages" such as C/C++ and JAVA.  How can you obtain a solid
foundation of making use of dynamic types if you haven't had a lot of
practice with SmallTalk or some other language that supports it?  How
can you have a solid foundation in lazy evaluation if you don't have
a decent amount of experience with Haskell or some other language that
supports it?  How can you have a solid foundation in non-procedural
programming if you've only used procedural languages?  What about
functional programming, reflective programming, higher-order functions,
continuation semantics, syntactical pattern matching, metaclasses?
Yes, most of these can be emulated in C/C++, but not easily, and you
are not likely to be well versed in their use if C/C++/JAVA are the
only languages you've really used.

The statement "one can aquire a working knowledge of any language in no
time" also seems quite naive.  The languages that do support these
features are not as easy to pick up as you might think - using them to
their fullest requires learning substantially different approaches to
programming problems, just as OOP C++ requires a significantly
different approach than non-OOP C (or non-OOP C++).  And the learning
that comes out of taking that different approach is what will make you
a better programmer.

>>From my point of view, right now, C/C++, and JAVA on a resume is hotter 
>>than Pascal.
>>Anh

That's true, but how long will C++ be king of the hill?  Besides, when
I interview someone for a job, I don't care if their C++ specific
skills are at 100% or not.  I have even let interviewees answer
interview questions using their language of choice because I know that
picking up syntax is simple, but learning concepts is hard (and some
people never learn them).

>Absolutely right, Anh.  I started with Fortran, taught myself C and
>C++ in about a month or so, and then picked up Ada in a couple weeks.
>
>Andy Askey

If you think you learned C++ (and OOP) in a month after only knowning
ForTran, then either you are fooling yourself, or you're a hell of a
lot smarter then me or anyone else I know.  Most of the syntax can be
learned in a week or less.  But OOP (and some of the more obscure
facets of C++) take much longer.

As to the original question, if it is an either-or situation and you
are only considering strict Pascal, then yes C++ is probably the better
choice.  If you allow for Pascal variants (such as Delphi) or more
recent versions of Pascal (i.e. Modula 3), then the choice is not so
clear cut.  If your only goal in life is to get a job [:-(], then C++
probably still edges out the newer Pascals.  But that question is moot
and not even worth arguing since no aspiring programmer should limit
themselves to only one language.


-Jeff

steidl@centuryinter.net - http://www.dont.i.wish.com/
All opinions are my own, and are subject to change without notice.

Re: Should I learn C or Pascal?

[Andy Askey]

steidl@centuryinter.net wrote:

>If you think you learned C++ (and OOP) in a month after only knowning
>ForTran, then either you are fooling yourself, or you're a hell of a
>lot smarter then me or anyone else I know.  Most of the syntax can be
>learned in a week or less.  But OOP (and some of the more obscure
>facets of C++) take much longer.


>-Jeff

>steidl@centuryinter.net - http://www.dont.i.wish.com/
>All opinions are my own, and are subject to change without notice.


Jeff,
I find OOD/OOP more of a state of mind than anything mystical and not
immediately apparent.  I guess I have also looked at all things
objectively.  System design and coding is an art form and it really
does not take alot of brains.  It is like the 5 year old who can play
concert piano.  The kid aint necessarily smart, he/she can just play
piano.  Don't make OOP out to be rocket science.

The real amazing achievement, as I see it, is the fact that I was able
to write Fortran code for 5 years without going nuts.

--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com

Re: Should I learn C or Pascal?

[Mark Eissler]

In article <1996Jul20.124025.122789@kuhub.cc.ukans.edu>,
anh@kuhub.cc.ukans.edu (TRAN PHAN ANH) wrote:

> Absolutely right.
> 
> But Pascal or C was the original question.  Start with C is what I say.  
> Better yet, why not C++ then move on to JAVA?
> 
> Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn 
> Pascal.  Actually, if one has a solid foundation in programming techniques and
> a solid understanding of one or two languages, one can aquire a working 
> knowledge of any language in no time.
> 
> From my point of view, right now, C/C++, and JAVA on a resume is hotter 
> than Pascal.
> 

Yes, but since just about everyone else has said something I'd say follow
this path BASIC -> Pascal -> C -> C++ -> JAVA. 

Jumping from nothing to C is likely to end up with nowhere. Pascal is a
simple language that will teach you certain things that will make it
easier to adapt to or "learn" C. While Pascal may not be used all that
much at a commercial level, it is still an excellent teaching language and
therefore a good place to start. 

Adapting to C is a breeze once you know Pascal. Of course, having had some
passing familarity with the concepts of programming (possibly picked up
from BASIC) will help a great deal. 

Becoming a "programmer" is something that happens in steps, not all at
once. And the learning continues as the languages evolve.

--
Mark Eissler                      |  Still in Toronto.
tequila@interlog.com              |  Still Raining.    http://www.interlog.com/~tequila/ |  Still...

Re: Should I learn C or Pascal?

[Erik Seaberg]

In article <tequila-2007961836190001@tequila.interlog.com>,
	Mark Eissler <tequila@interlog.com> writes:
> Yes, but since just about everyone else has said something I'd say follow
> this path BASIC -> Pascal -> C -> C++ -> JAVA. 

I find this odd.  I'd suggest learning Java (it has garbage collection
and simplified semantics, and it's almost impossible to hurt yourself)
as a prelude to modern C++ (new-style casts, RTTI, STL), perhaps
followed by C if you expect to run into a platform lacking a C++
compiler (or really want to know about the few dark corners that
aren't subsets of C++).  It seems to me that Pascal offers very little
over Java even for teaching - Java is lexically weird because C is,
but Pascal is syntactically weird for cheaper parsers, a less sensible
tradeoff these days.

I suppose my wish list order (with what one at least ought to learn
from them):

* Scheme (functional algorithms, recursion, closures and continuations
  as "all you need")
* Java (imperative algorithms, classes, polymorphism, containers)
* C++ (runtime costs, memory management, real-world utility)
* Eiffel (programming by contract, module isolation and cohesion)
  [perhaps Sather or Ada would work here, I don't know]

but then I expect each language I learn to demand I wrap my brain
around it for a while, or I won't bother studying it unless using some
implementation happens to be expedient.

Re: Should I learn C or Pascal?

[Robert Dewar]

Tran said

"Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn
Pascal.  Actually, if one has a solid foundation in programming techniques and
a solid understanding of one or two languages, one can aquire a working
knowledge of any language in no time."

Evenm allowing for a reasonable amount of rhetorical exaggeration, this is
false. First of all, there is no language C/C++, they are two quite
separate languages, and it definitely is NOT the case that if you have
learned one language that you can learn another in five minutes. Pretty
quickly sure, but not five minutes, for example, the notion of 
non-deterministic semantics for "and" in Pascal will be quite unfamiliar
to a C (or for that matter C++ programmer), and there are always enough
fine points like this to make it more than a trivial matter to become
a knowledgable programmer in a new language.

Re: Should I learn C or Pascal?

[TRAN PHAN ANH]

In article <dewar.837900271@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
> Tran said
> 
> "Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn
> Pascal.  Actually, if one has a solid foundation in programming techniques and
> a solid understanding of one or two languages, one can aquire a working
> knowledge of any language in no time."
> 
> Evenm allowing for a reasonable amount of rhetorical exaggeration, this is
> false. First of all, there is no language C/C++, they are two quite

This is nitpicking buddy.  Let's replace / with and, and say C and C++.

> separate languages, and it definitely is NOT the case that if you have
> learned one language that you can learn another in five minutes. Pretty

6, make that 6 minutes...

> quickly sure, but not five minutes, for example, the notion of 
> non-deterministic semantics for "and" in Pascal will be quite unfamiliar
> to a C (or for that matter C++ programmer), and there are always enough
> fine points like this to make it more than a trivial matter to become
> a knowledgable programmer in a new language.

Add an extra minute or 2 for unexpected problems. :-) Besides, I never 
claimed that you will become an expert in the language.  I said "a 
working knowledge".

Loosen up dude...:-)

Anh

Re: Should I learn C or Pascal?

[Ken Garlington]

Robert Dewar wrote:
> 
> Tran said
> 
> "Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn
> Pascal.  Actually, if one has a solid foundation in programming techniques and
> a solid understanding of one or two languages, one can aquire a working
> knowledge of any language in no time."

Except RPG or APL, of course. No one has ever learned those two :)

-- 
LMTAS - "Our Brand Means Quality"

Re: Should I learn C or Pascal?

[Stephen M O'Shaughnessy]

In article <1996Jul20.124025.122789@kuhub.cc.ukans.edu>, anh@kuhub.cc.ukans.edu 
says...
>
>Absolutely right.
>
>But Pascal or C was the original question.  Start with C is what I say.  
>Better yet, why not C++ then move on to JAVA?
>
>Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn 
>Pascal.  Actually, if one has a solid foundation in programming techniques and
>a solid understanding of one or two languages, one can aquire a working 
>knowledge of any language in no time.
>
>Anh
>

Yes, but "Hello World" is not a 'real' program. 8}

Re: Should I learn C or Pascal?

[TRAN PHAN ANH]

In article <Duy3Iy.86A@most.fw.hac.com>, smosha@most.fw.hac.com (Stephen M O'Shaughnessy) writes:
> In article <1996Jul20.124025.122789@kuhub.cc.ukans.edu>, anh@kuhub.cc.ukans.edu 
> says...
>>
>>Absolutely right.
>>
>>But Pascal or C was the original question.  Start with C is what I say.  
>>Better yet, why not C++ then move on to JAVA?
>>
>>Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn 
>>Pascal.  Actually, if one has a solid foundation in programming techniques and
>>a solid understanding of one or two languages, one can aquire a working 
>>knowledge of any language in no time.
>>
>>Anh
>>
> 
> Yes, but "Hello World" is not a 'real' program. 8}

We learned Smalltalk, Prolog, ML, and a dataflow language (can't recall 
the name right now) in one semester (adv. prg. lang. topics course) , and we 
did not say hello to the world one single time. :-)

About the projects, for sure, noone lost sleep over the syntactic aspects 
and the different programming paradigms. :-)

The course, of course, did not make us experts on all these languages, 
but, which course make students expert in its area?

Anh

Re: Should I learn C or Pascal?

[Carlos DeAngulo]

You should definitely learn C/C++. The business world today uses C++ as its
power language to develop the finest applications. Don't let anyone guide
you wrong.

Re: Should I learn C or Pascal?

[Robert Dewar]

Carlos says

"You should definitely learn C/C++. The business world today uses C++ as its
power language to develop the finest applications. Don't let anyone guide
you wrong."

Well I would say Carlos gives good advice (don't let anyone guide you wrong)
and you can start by not letting Carlos guide you wrong.

First, the business world uses many languages -- even today far more programs
are written in COBOL than in C and C++ combined by a very large margin. It is
true that a segment of the technical engineering and software devlopment
market uses C and C++ heavily today, but who knows what they may be using
tomorrow. Don't concentrate on learning languages, concentrate on learning
how to program.

Re: Should I learn C or Pascal?

[Jon Bell]

 Robert Dewar <dewar@cs.nyu.edu> wrote:
>First, the business world uses many languages -- even today far more programs
>are written in COBOL than in C and C++ combined by a very large margin.

Just out of curiosity, how much *new* development takes place in COBOL, 
as opposed to maintainance and extension of existing systems?   This does 
not imply that I'm downgrading maintainance, by the way.  I've done some 
of it (although not in COBOL), and I know that it can be a real challenge.

-- 
Jon Bell <jtbell@presby.edu>                        Presbyterian College
Dept. of Physics and Computer Science        Clinton, South Carolina USA

Re: Should I learn C or Pascal?

[Tim Oxler]

jtbell@presby.edu (Jon Bell) wrote:

> Robert Dewar <dewar@cs.nyu.edu> wrote:
>>First, the business world uses many languages -- even today far more programs
>>are written in COBOL than in C and C++ combined by a very large margin.

>Just out of curiosity, how much *new* development takes place in COBOL, 
>as opposed to maintainance and extension of existing systems?   This does 
>not imply that I'm downgrading maintainance, by the way.  I've done some 
>of it (although not in COBOL), and I know that it can be a real challenge.

>-- 
>Jon Bell <jtbell@presby.edu>                        Presbyterian College
>Dept. of Physics and Computer Science        Clinton, South Carolina USA


Quite a bit.  ALL of my work is new development (12 new CICS pgms in
the past 2 months).  All of it, for my current client, has been on
mainframe.  Just because it's "legacy" doesn't mean that it's static.
Corporations are very dynamic.  Some systems move to client/server
(with the mainframe connected), and many are written in Cobol.

Here's the source Infoworld, April 8, 1996, page 56.

Sentry Market Research surveyed 700 IS mangers what language they used
for client/server application development:

Visual Basic	23%
Cobol		21%
C++		18%
C		15%
4GL		15%
Other		  8%

Key findings:

The use of languages has doubled since 1993.

The fastest growing are Cobol and VB.

4GLs, Object Cobol, and C++ are the highest rated.

The use of model driven development tools is growing.

VB's strength is in graphical tool development, but placed in the
middle of the ratings list.


Tim Oxler


TEO Computer Technologies Inc.
troxler@i1.net
http://www.i1.net/~troxler
http://users.aol.com/TEOcorp

Re: Should I learn C or Pascal?

[Janus]

With nothing better to do on Mon, 22 Jul 1996 13:21:32 GMT,
troxler@i1.net (Tim Oxler) dropped 2 cents in the slot and wrote:

<snip>
>Sentry Market Research surveyed 700 IS mangers what language they used
>for client/server application development:
>
<snip>
>
>The use of languages has doubled since 1993.
>
Maybe I'm particularly dense tonight - but what does that sentence
mean ? 


Bye from
Janus at Kerry, Ireland
email : jab@iol.ie
WWW : http://www.iol.ie/~jab

Re: Should I learn C or Pascal?

[Robert Dewar]

Tim Oxler quoted:

Sentry Market Research surveyed 700 IS mangers what language they used
for client/server application development:

Visual Basic    23%
Cobol           21%
C++             18%
C               15%

and note that client server applications probably have a lower percentage
of COBOL than all applications, because there are still lots of 
traditional batch programs being generated in IS shops in COBOL.

Re: Should I learn C or Pascal?

[Tim Behrendsen]

Robert Dewar <dewar@cs.nyu.edu> wrote in article
<dewar.838067532@schonberg>...
> Tim Oxler quoted:
> 
> Sentry Market Research surveyed 700 IS mangers what language they used
> for client/server application development:
> 
> Visual Basic    23%
> Cobol           21%
> C++             18%
> C               15%
> 
> and note that client server applications probably have a lower percentage
> of COBOL than all applications, because there are still lots of 
> traditional batch programs being generated in IS shops in COBOL.

I wonder how many of those C++ people actually use the language
features beyond // comments?  The reason I ask this is I see so
many resumes with "C/C++" listed on it (which is a dead giveaway,
since they are very different languages) but when you ask them about
it, they admit "well, I read a book about it.  My previous positions
didn't actually use it".  That makes me think that they people who
are answering this survey checked the C++ box to be "hip".  "Well,
I'm *really* going to crack that C++ book next week and convert
my 100,000 lines over, so I might as well check the box."

I sort of doubt that C++ is being used more than straight C in
anything more than a trivial way.

-- Tim Behrendsen (tim@airshields.com)

Re: Should I learn C or Pascal?

[Patrick Horgan]

In article <dewar.838067532@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
> Tim Oxler quoted:
> 
> Sentry Market Research surveyed 700 IS mangers what language they used
> for client/server application development:
> 
> Visual Basic    23%
> Cobol           21%
> C++             18%
> C               15%
> 
> and note that client server applications probably have a lower percentage
> of COBOL than all applications, because there are still lots of 
> traditional batch programs being generated in IS shops in COBOL.
> 

Most of us don't work in IS shops though...it's a very different market than
the kind of development environment you find in a software shop.  Those numbers
are completely inapplicable to the workplaces most of us live in.

Out here in Silicon Valley it's almost impossible to get a job without C++.
I've been involved in several companies with the interviewing/hiring 
process, (cause I do a good job of finding out how much air is in a
resume;) and you don't even get in the door without C++ on your resume.  You
don't get called back for a second interview unless you can demonstrate
C++ ability.

Note that this is not a comment on C++ as a good/poor language for learning/
object-oriented-programming/life.  Just a note on industry practice.

Some of the defense contractors out here are using Ada, and others still use
C, and a few use Cobol, but you really limit your market with those.  Defense
contractors don't pay nearly as well as the rest of the market either. (So
where ARE all those tax dollars going?)


-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

Re: Should I learn C or Pascal?

[Stig Norland]

In article <4svvjf$c3i@news1.i1.net>, troxler@i1.net (Tim Oxler) writes:

[snip]

> Sentry Market Research surveyed 700 IS mangers what language they used
> for client/server application development:
> 
> Visual Basic	23%
> Cobol		21%
> C++		18%
> C		15%
> 4GL		15%
> Other		  8%
> 
> Key findings:
> 
> The use of languages has doubled since 1993.
> 
> The fastest growing are Cobol and VB.
> 
> 4GLs, Object Cobol, and C++ are the highest rated.
> 
> The use of model driven development tools is growing.
> 
> VB's strength is in graphical tool development, but placed in the
> middle of the ratings list.
> 
> 
> Tim Oxler

And Delphi wasn't in the survey at al ???

Re: Should I learn C or Pascal?

[Robert Dewar]

Carlos said

"And about your COBOL remark... The only reason COBOL is still alive in the
business world, is because large corporations have this code so spread out
through out their corporations that changing to anything else would cost
millions of dollars. Convincing customers to change to another language
because it is more powerful usually doesn't "cost justify" itself to them.
Fortunatelly we as programmers have the choice of what environment we want
to spend our time in. If you want to spend your time working on a dinosaur
language like COBOL, or if you want to spend your time on C++ which is the
language that most of the software development corporations in the world
are using."

In the information systems world, which clearly from your remarks you
are unfamiliar with, C++ is not particularly attractive, and for example
Smalltalk has generated much more interest. COBOL, which I also would guess
from your remarks is something you are not familiar with, is in fact a 
powerful tool, and is the language of choice, even for a lot of new
development being done in client/server setups using PC's.

One thing you quickly learn in this field is that most people have a rather
narrow view of the world (for example, it is not unusual to find people
who assume that Unix has a large percentable of the operating system
market).

Re: Should I learn C or Pascal?

[steidl]

In <01bb7588$236982e0$7b91f780@deangulo>, "Carlos DeAngulo" <cdvi@msg.itg.ti.com> writes:
>Robert Dewar <dewar@cs.nyu.edu> wrote in article
><dewar.837728192@schonberg>...
>> Carlos says
>> 
>> "You should definitely learn C/C++. The business world today uses C++ as
>its
>> power language to develop the finest applications. Don't let anyone guide
>> you wrong."
>> 
>> Well I would say Carlos gives good advice (don't let anyone guide you
>wrong)
>> and you can start by not letting Carlos guide you wrong.
>> 
>> First, the business world uses many languages -- even today far more
>programs
>> are written in COBOL than in C and C++ combined by a very large margin.
>It is
>> true that a segment of the technical engineering and software devlopment
>> market uses C and C++ heavily today, but who knows what they may be using
>> tomorrow. Don't concentrate on learning languages, concentrate on
>learning
>> how to program.
>> 
>When I say business world I mean the working world. The question was
>whether to learn C or Pascal. All you have to do is pick up any newspaper
>anywhere in the country and see how many jobs are offered for Pascal
>programmers, and compare it to how many jobs are offered to C/C++
>programmers. If you spend your time learning Pascal, that's all you will
>end up doing... spending your time. Pick up a real language, don't waste
>your time on other ones.

OK, so your point is that we all need to program in C/C++ - we don't
really have a choice because that's where the jobs are.

>And about your COBOL remark... The only reason COBOL is still alive in the
[Reasons for COBOL's continue existence snipped]
>Fortunatelly we as programmers have the choice of what environment we want
>to spend our time in.

Oh, but Carlos, poor little me is confused.  Now you say we have a
choice?

>If you want to spend your time working on a dinosaur
>language like COBOL, or if you want to spend your time on C++ which is the
>language that most of the software development corporations in the world
>are using. If it isn't obvious how easy the decision is to go with C++ over
>COBOL and Pascal then your bank account will show the error you made!

Robert never said the person should learn COBOL, and he certainly never
said the person should learn COBOL to the exclusion of all else.  He
just said the person should learn "programming", and that C/C++ is
neither the only language used, nor is it the last word on programming.

You seemed to react quite unreasonably and vehemently to the mere
*mention* of COBOL.  To this I just have one thing to say:

   COBOL  COBOL  COBO   COBOL  C      CO
   C      C   L  C   L  C   L  C      CO
   C      C   L  COBOL  C   L  C      CO
   C      C   L  C   L  C   L  C
   COBOL  COBOL  COBO   COBOL  COBOL  CO

:-)

-Jeff

steidl@centuryinter.net - http://www.dont.i.wish.com/
All opinions are my own, and are subject to change without notice.

Re: Should I learn C or Pascal?

[Dirk Dickmanns]

"Carlos DeAngulo" <cdvi@msg.itg.ti.com> writes:

>You should definitely learn C/C++. The business world today uses C++ as its
>power language to develop the finest applications. Don't let anyone guide
>you wrong.

Yes, and don't look at anything else, it could happen that you
would learn something about programming!

The world does _NOT_ end at C or C++, even if Carlos says so.

Dirk

--
Dirk Dickmanns -- REALIS -- real-time dynamic computer vision
Sun OS 4.1.3; PC Linux; Ada, OCCAM, C, Eiffel, PROLOG, C++

Re: Should I learn C or Pascal?

[johnf]

In article <01bb7591$83087d60$87ee6fce@timpent.airshields.com>, "Tim
Behrendsen" <tim@airshields.com> wrote:

>Carlos DeAngulo <cdvi@msg.itg.ti.com> wrote in article
><01bb74ac$b7aa7860$7b91f780@deangulo>...
>> You should definitely learn C/C++. The business world today uses C++ as
>its
>> power language to develop the finest applications. Don't let anyone guide
>> you wrong.
>
>Not to start a flame war on C++, but all you newbie programmers
>out there, don't believe everything you hear about C++.  Object
>oriented programming has a lot of good concepts, but C++ is a bad
>implementation of them.  Not that you shouldn't learn it, but
>don't think it's the ultimate expression of what OOP is all about.
>
>C++: The PL/I of the 90s.

OK

I am one of these newbies.
I haven't programmed anything, ever, with any language.
I am currently learning C with the help of Dave Mark (Learn C on Mac) as
my baptism into programming. 
So, I am I only learning C, and not "how to program"? I don't understand
how the two can be exclusive.
How does one learn how to be a "Good Programmer" without picking a
language to learn first, learning it well, then learning others as they
interest you? 
I am not trying to be a wise guy, just a guy who can learn to program well
enough to get out of his crappy job and into this (for me) exciting field
as a career.
I don't expect to start as the Sr. Developer on some project, I will
happily slog it out in the trenches and pay my dues, just explain to me
how to get there...

Thank you,

Johnf

-- 
johnf@nando.com

Go Falcons

Re: Should I learn C or Pascal?

[Jeremy Nelson]

johnf <johnf@nando.com> wrote:
>So, I am I only learning C, and not "how to program"? I don't understand
>how the two can be exclusive.

"Programming" is seeing a problem and knowing how to construct a
language-independant algorithm for solving the problem.  Ie, programming
is problem solving, with the added value that you understand how to make
a computer help you do the work.

"Learning C" is understanding the syntax and semantics of a specific
computer programming language without understanding the nuances of how
it can be applied to solve larger problems that may transcend the ability
of that language.


If you know how to program, then you already know how to determine which
language is the right tool for the problem.  Not every problem can be solved
in every language, and knowing which one to use at which time is fundamental.

If you know how to write semantically correct C programs, but you dont have
any idea what to do if you are confronted with a problem that you cant solve
using C, then you really dont have the "programming" side of it.

As warped as it sounds, i knew several languages, but i never really
became a "programmer" until i took a fortran class where the whole idea was
using the computer to do problem solving.

jfn

Re: Should I learn C or Pascal?

[Jason Alan Turnage]

johnf (johnf@nando.com) wrote:

: OK

: I am one of these newbies.
: I haven't programmed anything, ever, with any language.
: I am currently learning C with the help of Dave Mark (Learn C on Mac) as
: my baptism into programming. 
: So, I am I only learning C, and not "how to program"? I don't understand
: how the two can be exclusive.
: How does one learn how to be a "Good Programmer" without picking a
: language to learn first, learning it well, then learning others as they
: interest you? 

	Never, never, never try to start learning a language before you
	learn how to program.  A good algorithm simply cannot be replaced,
	and learning how to write an alogrithm is in programming, not
	in learning a language.  You can sit down and read a hundred books
	about how to use pointers and linked lists in c++, and you still
	won't know how to use them in a good manner, if at all.

	Here at GA Tech, in the first computer course you can take, a
	pseudo language is taught so that the real objective of the class,
	algorithm teaching, won't be disturbed by students trying to jump
	the gun and diving in to any one language.  This pseudo language
	is a mixture of c, pascal, and a few other languages, along with
	some non-language stuff like 'var1 isa number', so the non-programmers
	can understand it.  Probably half or more students going into
	a programming major here have never programmed before, and would be
	totally lost in the second computer programming course (programming
	in pascal) if they hadn't taken this course first.

: I am not trying to be a wise guy, just a guy who can learn to program well
: enough to get out of his crappy job and into this (for me) exciting field
: as a career.
: I don't expect to start as the Sr. Developer on some project, I will
: happily slog it out in the trenches and pay my dues, just explain to me
: how to get there...

	The best programmers can do anything on a computer, absolutely
	anything that the computer will let them do, and sometimes even
	more.  And these are the guys that make the money.  And the only
	way to become one of these guys is to learn how to program.
	Once you learn how to program, a language is no problem, it's the
	easy part.  If you start with learning a language, you'll have one
	hell of a time if you ever have to learn another language, or better
	yet, to convert your current code to another language.

	Good luck.

--
Jason Turnage
Georgia Tech
turnage@cc.gatech.edu
www.prism.gatech.edu/~gt8678a

Re: Should I learn C or Pascal?

[Robert Dewar]

"
        Never, never, never try to start learning a language before you
        learn how to program.  A good algorithm simply cannot be replaced,
        and learning how to write an alogrithm is in programming, not
        in learning a language.  You can sit down and read a hundred books
        about how to use pointers and linked lists in c++, and you still
        won't know how to use them in a good manner, if at all."


I am very familiar with the highly unusual approach Georgia Tech takes, but
I find the above remark rubbish. You cannot express algorithms unless you
use a language to express them in, and for my taste, a well chosen 
programming language is as good choice as anything.

Re: Should I learn C or Pascal?

[Jon Bell]

[removed comp.unix programmer (irrelevant) and comp.dos.programmer 
(bogus) 'from Newsgroups:' line; added comp.edu]

 Robert Dewar <dewar@cs.nyu.edu> wrote:
>  You cannot express algorithms unless you
>use a language to express them in, and for my taste, a well chosen 
>programming language is as good choice as anything.

For *my* taste, a real programming language is *better*, because you can 
test the correctness of your solution by executing it.  Try *that* with 
pseudocode or data flow diagrams!  :-)

(Which is not to downgrade their usefulness as design tools.)

I do appreciate the counter-argument that it's asking a lot of students 
to master both program design skills and language syntax at the same 
time.  Therefore I respect the decisions made by schools that use a
"non-marketable" language such as Modula-"n" or Scheme as their first 
programming language.  I think it is a reasonable strategy to start with 
such a language, then switch to a "real" language later, in the context 
of a four-year degee program.  Of course, students may need to be 
persuaded that this is actually worthwhile!

-- 
Jon Bell <jtbell@presby.edu>                        Presbyterian College
Dept. of Physics and Computer Science        Clinton, South Carolina USA
[for beginner's Usenet info, see http://cs1.presby.edu/~jtbell/usenet/]

Re: Should I learn C or Pascal?

[Robert Dewar]

Jon Bell said

"I do appreciate the counter-argument that it's asking a lot of students
to master both program design skills and language syntax at the same
time.  Therefore I respect the decisions made by schools that use a
"non-marketable" language such as Modula-"n" or Scheme ...

and what makes you think that Modula-"n" does not have a language syntax?
Even Scheme has a syntax, but it is a simple one. Modula-"n" is a fully
developed procedural language with a syntax not particularly more simple
than obviously comparable languages.

The motivation for teaching Modula-"n", or Scheme is not to avoid teaching
syntax (although it is true that Scheme reduces the syntactic burden, but
that is not a primary reason for introducing it as a first language
(actually in practice scheme is almost never introduced to anyone as a 
first language -- at schools where scheme is taught in the equivalent of
CS1, most students know how to program in some other language first).

Re: Should I learn C or Pascal?

[Alexander Vrenios]

   C. Check the job ads in your Sunday paper and count those that are
looking for C programmers and those that are looking for Pascal skills.

Re: Should I learn C or Pascal?

[Steve Tate]

Jon Bell (jtbell@presby.edu) wrote:

>  Robert Dewar <dewar@cs.nyu.edu> wrote:
> >  You cannot express algorithms unless you
> >use a language to express them in, and for my taste, a well chosen 
> >programming language is as good choice as anything.

> For *my* taste, a real programming language is *better*, because you can 
> test the correctness of your solution by executing it.  Try *that* with 
> pseudocode or data flow diagrams!  :-)

I believe that pseudo-code is better for getting across general
principles without getting bogged down in implementation details.  As
another reason to promote pseudocode, I suggest in a half-serious way
that it is less likely to have people say things like this last
poster.  To explain that a little better: you can never, EVER "test
the correctness" of an *algorithm* by executing it.  I don't care how
you design your test cases, the ONLY way to show the correctness of an
algorithm is with a formal mathematical proof.  Of course,
implementations are good for demonstrating the INcorrectness of some
algorithms!  :-)

--
Steve Tate  ---  srt@cs.unt.edu | "As often as a study is cultivated by narrow
Dept. of Computer Sciences      |  minds, they will draw from it narrow
University of North Texas       |  conclusions."  -- John Stuart Mill, 1865.
Denton, TX  76201               | 

Re: Should I learn C or Pascal?

[Robert Dewar]

Steve Tate said

"I believe that pseudo-code is better for getting across general
principles without getting bogged down in implementation details.  As
another reason to promote pseudocode, I suggest in a half-serious way
that it is less likely to have people say things like this last
poster.  To explain that a little better: you can never, EVER "test
the correctness" of an *algorithm* by executing it.  I don't care how
you design your test cases, the ONLY way to show the correctness of an
algorithm is with a formal mathematical proof.  Of course,
implementations are good for demonstrating the INcorrectness of some
algorithms!  :-)"


But you certainly cannot prove the correctness of an algorithm written
in pseudo-code, at best you could produce an informal proof. If you
really want to write proofs of correctness, then you need to write
not just in a programming language, but in one whose semantics are
rigorously understood and formally defined.

Re: Should I learn C or Pascal?

[Phil Howard]

On 21 Jul 1996 19:24:07 GMT Steve Tate (srt@zaphod.csci.unt.edu) wrote:

| I believe that pseudo-code is better for getting across general
| principles without getting bogged down in implementation details.  As
| another reason to promote pseudocode, I suggest in a half-serious way
| that it is less likely to have people say things like this last
| poster.  To explain that a little better: you can never, EVER "test
| the correctness" of an *algorithm* by executing it.  I don't care how
| you design your test cases, the ONLY way to show the correctness of an
| algorithm is with a formal mathematical proof.  Of course,
| implementations are good for demonstrating the INcorrectness of some
| algorithms!  :-)

Even that isn't right.  I can send you bad code and _claim_ it to be an
implementation of _any_ algorithm, thus disproving.  Not!

There are multiple issues in programming that one needs to deal with.
There are abstract concepts (what data structure do I need to use?)
and concrete concepts (how do I format the output to be readable?)
involved.  Programming is essentially the bringing together of these
concepts.  The program is thus the bridge between the abstract and the
concrete.  You need to learn and understand both.

Programming languages are just tools.  The right tools for the job do
work better, but you have to know how to choose the correct tool and
also how to use that correct tool in the correct way.  Often these things
are not yet answered for what you may need to do.  Thus you need to look
at programming also as a problem solving situation and that takes a good
foundational understanding of all aspects.  That includes the abstract,
the concrete, and the tools for making programs that are the bridges.

--
Phil Howard KA9WGN   +-------------------------------------------------------+
Linux Consultant     |  Linux installation, configuration, administration,   |
Milepost Services    |  monitoring, maintenance, and diagnostic services.    |
phil@milepost.com    +-------------------------------------------------------+

Re: Should I learn C or Pascal?

[Robert Dewar]

Steve said

"| poster.  To explain that a little better: you can never, EVER "test
| the correctness" of an *algorithm* by executing it.  I don't care how
| you design your test cases, the ONLY way to show the correctness of an
| algorithm is with a formal mathematical proof.  Of course,
| implementations are good for demonstrating the INcorrectness of some
| algorithms!  :-)"

Well it is a reasonable guess that Steve is pretty new to the field and
is repeating what he has been taught. But still, this concentration on
correctness seems a mistake to me, and it particularly seems a mistake
to concentrate on correctness to the exclusion of pragmatic understanding
of the real issues.

Steve, you need to understand that correctness is just one aspect of a 
program. Correct programs are not necessarily usable or acceptable, and
incorrect programs are often both usable and acceptable. There are two
issues here.

Correctness only reflects the match between a program and it spec (Note; i
know we had a discussion about the confusion caused by taking a general
term like correctness and using in this restricted sense, but that is clearly
what Steve is talking about when he talks about a mathematic proof, since
clearly you cannot proove a program correct if you use the more general
informal meaning of correct :-)

But:

 a) how do you know the spec is correct (now we are using the informal sense
    of the term -- since sooner or later you have to track back to the real
    world, and at the point you do, the notion of mathematical proof fails
    you.

 b) what if the spec is not formalizable ("make the screen appearence 
    aesthetically pleasing", "generate good error messages" etc.) Such
    specs can *only* be realized via testing, since they are subjective,
    but often subjective requirements like this are as important as
    anything else (is the interface of Windows 95 correct?????)

Proof of correctness is an important tool, but accepting the orthodoxy that
it is the only useful approach and that testing of implementations is
useless reflects a rather large gap between your thinking and the real world!

Re: Should I learn C or Pascal?

[Steve Tate]

Robert Dewar (dewar@cs.nyu.edu) wrote:
> Steve said

> "| poster.  To explain that a little better: you can never, EVER "test
> | the correctness" of an *algorithm* by executing it.  I don't care how
> | you design your test cases, the ONLY way to show the correctness of an
> | algorithm is with a formal mathematical proof.  Of course,
> | implementations are good for demonstrating the INcorrectness of some
> | algorithms!  :-)"

> Well it is a reasonable guess that Steve is pretty new to the field and
> is repeating what he has been taught. 

Ummm... no.  I've been programming for about 18 years, and have had a
Ph.D. and been teaching for about 5.

> But still, this concentration on
> correctness seems a mistake to me, and it particularly seems a mistake
> to concentrate on correctness to the exclusion of pragmatic understanding
> of the real issues.

> Steve, you need to understand that correctness is just one aspect of a 
> program. Correct programs are not necessarily usable or acceptable, and
> incorrect programs are often both usable and acceptable. There are two
> issues here.

And you seem to have totally missed what I said.  Nowhere (not even
once) did I say anything about proving that a *program* was correct.
I was talking about correctness proofs for *algorithms*.  Take, for
example, Prim's algorithm for finding a minimum spanning tree.  There
are a huge number of different ways you can implement this, using
different data structures or different languages, but the abstract
sequence of steps that makes it Prim's algorithm is very well
defined.  Furthermore, you can formally prove the correctness of the
algorithm which, of course, doesn't depend in the least on
implementation details such as exact data structures of programming
language.  I think using a real programming language to describe
Prim's algorithm would be a mistake because it wouldn't clearly
emphasize that these details are not relevant to what "Prim's
algorithm" really is.

Let me give you another example that better illustrates what I said
about an implementation telling you nothing about the correctness of
an algorithm.  There is a proposed primality testing algorithm (based
on a sequence of numbers called the "Perrin Sequence") which was
recently (June 1996) described in Scientific American.  The algorithm
has been known for about 100 years, but noone has been able to either
prove that it works correctly or give a counter example.  There have
been implementations, and for almost a century all empirical tests
have shown that the algorithm works.  Until a couple of weeks ago.
That's when a counter example was found.  So I repeat what I said
before: you can tell absolutely nothing about the correctness of an
algorithm by testing --- the only thing that reasonably shows the
correctness of an algorithm is a good mathematical proof.

> Correctness only reflects the match between a program and it spec (Note; i
> know we had a discussion about the confusion caused by taking a general
> term like correctness and using in this restricted sense, but that is clearly
> what Steve is talking about when he talks about a mathematic proof, since
> clearly you cannot proove a program correct if you use the more general
> informal meaning of correct :-)

Again, I was talking about algorithms, not writing a program "to
spec".  When you talk about algorithm, you are normally given a clear,
unambiguous, mathematical description of what needs to be computed.
Proving correctness is clearly desirable in such a situation.

--
Steve Tate  ---  srt@cs.unt.edu | "As often as a study is cultivated by narrow
Dept. of Computer Sciences      |  minds, they will draw from it narrow
University of North Texas       |  conclusions."  -- John Stuart Mill, 1865.
Denton, TX  76201               | 

Re: Should I learn C or Pascal?

[Stephen M O'Shaughnessy]

In article <Duuoxq.IK1@presby.edu>, jtbell@presby.edu says...
>I do appreciate the counter-argument that it's asking a lot of students 
>to master both program design skills and language syntax at the same 
>time.  Therefore I respect the decisions made by schools that use a
>"non-marketable" language such as Modula-"n" or Scheme as their first 
>programming language.  I think it is a reasonable strategy to start with 
>such a language, then switch to a "real" language later, in the context 
>of a four-year degee program.  Of course, students may need to be 
>persuaded that this is actually worthwhile!
>

What separates a 'real' language from a (fake?) language? Would not the students still have to 
learn the syntax of even psudocode?  Is a 'non-marketable' language inherent in all 
programmers?  Because I can program in assembler, fortran, Forth, HP Basic, Borland C and Ada 
but I have never written a single line of Modula-"n" or Scheme.  All the psudocode I have ever 
written was made up of bits and pieces of the afore mentioned languages.  i.e I have never 
used a for loop in normal conversation, written or spoken.

Re: Should I learn C or Pascal?

[++ robin]

	jtbell@presby.edu (Jon Bell) writes:

	> Robert Dewar <dewar@cs.nyu.edu> wrote:
	>>  You cannot express algorithms unless you
	>>use a language to express them in, and for my taste, a well chosen 
	>>programming language is as good choice as anything.

	>For *my* taste, a real programming language is *better*, because you can 
	>test the correctness of your solution by executing it.  Try *that* with 
	>pseudocode or data flow diagrams!  :-)

You can test the correctness of a solution with
the *algorithm*, whether it's expressed in flowchart,
pseuducode, etc form.

It's considered better to get the design correct *before*
committing the design into detailed code.  Re-designing
the detailed code tends to be more expensive than
re-designing the algorithm.

Re: Should I learn C or Pascal?

[TRAN PHAN ANH]

In article <dewar.837815529@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
> "
>         Never, never, never try to start learning a language before you
>         learn how to program.  A good algorithm simply cannot be replaced,
>         and learning how to write an alogrithm is in programming, not
>         in learning a language.  You can sit down and read a hundred books
>         about how to use pointers and linked lists in c++, and you still
>         won't know how to use them in a good manner, if at all."
> 
> 
> I am very familiar with the highly unusual approach Georgia Tech takes, but
> I find the above remark rubbish. You cannot express algorithms unless you
> use a language to express them in, and for my taste, a well chosen 
> programming language is as good choice as anything.

Rubbish....absolutely.  I know some friendly dudes, who know all the bloody 
O(n) for every algorithms, but as soon as they sit down to implement 
one...oh opps...core dump.   Oh, to make matter worse, they choose algorithms 
based solely on O(n).

Anh 

Re: Should I learn C or Pascal?

[Ralph Silverman]

TRAN PHAN ANH (anh@kuhub.cc.ukans.edu) wrote:
: In article <dewar.837815529@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
: > "
: >         Never, never, never try to start learning a language before you
: >         learn how to program.  A good algorithm simply cannot be replaced,
: >         and learning how to write an alogrithm is in programming, not
: >         in learning a language.  You can sit down and read a hundred books
: >         about how to use pointers and linked lists in c++, and you still
: >         won't know how to use them in a good manner, if at all."
: > 
: > 
: > I am very familiar with the highly unusual approach Georgia Tech takes, but
: > I find the above remark rubbish. You cannot express algorithms unless you
: > use a language to express them in, and for my taste, a well chosen 
: > programming language is as good choice as anything.

: Rubbish....absolutely.  I know some friendly dudes, who know all the bloody 
: O(n) for every algorithms, but as soon as they sit down to implement 
: one...oh opps...core dump.   Oh, to make matter worse, they choose algorithms 
: based solely on O(n).

: Anh 

--
***********begin r.s. response***************

	(theory vs.  practice)

	obviously...
	these are interrelated and interdependent!

	(since "the beginning of time"...)

	stone throwing like this...
	in either direction...
	is unintelligent!

***********end r.s. response*****************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[Crash]

On 19 Jul 1996, Robert Dewar wrote:

><O<)"
><O<)        Never, never, never try to start learning a language before you
><O<)        learn how to program.  A good algorithm simply cannot be replaced,
><O<)        and learning how to write an alogrithm is in programming, not
><O<)        in learning a language.  You can sit down and read a hundred books
><O<)        about how to use pointers and linked lists in c++, and you still
><O<)        won't know how to use them in a good manner, if at all."
><O<)
><O<)
><O<)I am very familiar with the highly unusual approach Georgia Tech takes, but
><O<)I find the above remark rubbish. You cannot express algorithms unless you
><O<)use a language to express them in, and for my taste, a well chosen 
><O<)programming language is as good choice as anything.
><O<)
><O<)

An algorithm is just a set of instructions on how to accomplish a task. An
algorithm does not depend at all on any sort of programming "language". In
fact, I was taught that you should write out your "game plan" and psuedo
code before you even touch any sort of syntax in any language. Yes, I do
tend to write up my psuedo-code in a C-like syntax frequently but you
don't need to.

     Loop until variable is equal to 7
	Add 1 to variable
	Print out the following string to screen: ;-)
	end of loop

There's an algorithm written in plain english. It's a stupid algorithm,
I'll give you that, but one none the less and it's not written in any
programming "lanugage/syntax" I have ever worked with.

Re: Should I learn C or Pascal?

[Robert Dewar]

"An algorithm is just a set of instructions on how to accomplish a task. An
algorithm does not depend at all on any sort of programming "language". In
fact, I was taught that you should write out your "game plan" and psuedo
code before you even touch any sort of syntax in any language. Yes, I do
tend to write up my psuedo-code in a C-like syntax frequently but you
don't need to.

     Loop until variable is equal to 7
        Add 1 to variable
        Print out the following string to screen: ;-)
        end of loop

There's an algorithm written in plain english. It's a stupid algorithm,"

First of all "pseudo-code" is still written in a language, which has syntax
and semantics. The trouble with an algorithm written in "plain english"
like the above is that it is imprecise. For example does the string that
is written to screen include a leading blank? I have no idea from the above.

If variable is 2**32-1, does the above still work? I have no idea.

Are the strings on separate lines of the screen? I have no idea.

writing

   while variable /= 7 loop
      variable := variable + 1;
      put_line (";-)");
   end loop;

is less writing than you did, just as clear, and importantly, exactly
precise (I had to make some guesses as to what your intention was, but
if my guesses were wrong, the above is easily modified to accomodate
them).

Writing at a high semantic level is desirable, and your example would
have been much more effective if for example it had included universal
quantification over finite sets, but that too would better be written
in a well-defined language.

If you went a step further, and wrote non-effective computation steps
involving for example membership in infinite sets, then of course what
you wrote would not correspond to an executable program, but would still
be better written in a precise language (e.g. one of the many
specification languages like Z)

Writing in "plain english" may appeal to those who are petrified of
formal notation of any kind, but such people are not likely to get
very far in this field anyway!

Re: Should I learn C or Pascal?

[Ralph Silverman]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: "
:         Never, never, never try to start learning a language before you
:         learn how to program.  A good algorithm simply cannot be replaced,
:         and learning how to write an alogrithm is in programming, not
:         in learning a language.  You can sit down and read a hundred books
:         about how to use pointers and linked lists in c++, and you still
:         won't know how to use them in a good manner, if at all."


: I am very familiar with the highly unusual approach Georgia Tech takes, but
: I find the above remark rubbish. You cannot express algorithms unless you
: use a language to express them in, and for my taste, a well chosen 
: programming language is as good choice as anything.


--
***********begin r.s. response*************

	(computer programmers as
	misfits,  nerds,  outcasts,
	outlaws,  renegades etc.)

	traditionally,
	the art of computer programming
	fostered,  and required,
	individual,  independent
	thinking.

	this trend was fostered by the
	availability,  and use,  of objective
	arbitration of competing interpretations
	and ideas by computer systems...

	largely,  specifically,
	software development systems,
	such as compilers...

	because of this,  programmers tended
	to develop empirical,  aauthoritarian
	views on verification and applicability...

	in view of this,
	practically speaking,
	in the traditional system,
	clever students might readily challenge
	teachers.

	efforts to overturn this traditional
	system in the education of programmers
	may be rooted in the perceived social
	disruption caused by such,  more than by
	any putative effort to improve the education
	of these.

***********end r.s. response***************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[Stephen M O'Shaughnessy]

In article <4sord0$l0k@solaria.cc.gatech.edu>, turnage@cc.gatech.edu says...

>        Never, never, never try to start learning a language before you
>        learn how to program.  A good algorithm simply cannot be replaced,
>        and learning how to write an alogrithm is in programming, not
>        in learning a language.  You can sit down and read a hundred books
>        about how to use pointers and linked lists in c++, and you still
>        won't know how to use them in a good manner, if at all.
>
I am with Mr. Dewar on this one.  What Jeremy is saying is like saying learn theology or 
philosophy before you learn to read or write or even speak!  You can't understand the 
concepts of any discipline until you learn the language that describes that discipline.

There is some validity in Mr. Nelson's  statements.  Don't get caught up in the language 
war when trying to understand the concepts of programming.  It is  like arguing merits of 
Greek or Hebrew in understanding Christianity.  It misses the whole point.  But you must 
have at least one language to even begin.

So for the original poster, does Mr. Nelson have a reference for the none language 
specific programming?

Re: Should I learn C or Pascal?

[Jeremy Nelson]

In article <Duy1nn.7t5@most.fw.hac.com>,
>>
>I am with Mr. Dewar on this one.  What Jeremy is saying is like saying learn theology or 
>philosophy before you learn to read or write or even speak!  You can't understand the 
>concepts of any discipline until you learn the language that describes that discipline.

I think you missed your attributions here -- The only post i made in this
thread was on an entirely different branch (the posting i made has not been 
followed up to yet, even), so just a friendly reminder to go back and make
sure that you dont get me into a flame war that i never really intended to
get into. ;-)

>So for the original poster, does Mr. Nelson have a reference for the none language 
>specific programming?


Please read my post again.  What i said was "You arent really a programmer
until you learn to solve problems."  That does not preclude the ability to 
learn a computer language, but there is much more to programming then just
producing semantically correct programs.  You have to understand how to apply
the nuances of the _appropriate_ language to get the _appropriate_ answer.

FORTRAN is easy to learn, and works well for math computation problems.
C is more difficult to learn, but can be used for most pragmatic problems.
C++ is even more difficult to learn, but can be used for more abstract
   problems.
lisp is easy to learn, and can be used for a very useful set of specific
   problems requiring a functional programming approach.
Pascal is trivially easy to learn, and that was the point.  Pure pascal
   is limited in its usefulness, but several enhanced dialects of pascal
   can be quite useful for what may be refered to as "user-land" problems.
   I dont believe pascal is an appropriate tool for system programming.

I wouldnt write space shuttle software in lisp, but FORTRAN has done very 
well in this respect, for many years.

As i said in my (one and only) post, 

"Not every language solves every problem.  Programming is knowing which 
language to use at what time." And i might add also "And you also have
to know how to use that language to get the computer to do the most
work for you in the least amount of human-time."

Programming is not about languages.  Its about problem-solving using computers.

Jeremy

Re: Should I learn C or Pascal?

[Stephen M O'Shaughnessy]

In article <4t01v4$8a6@news.inc.net>, nelson@cs.uwp.edu says...

>I think you missed your attributions here -- The only post i made in this
>thread was on an entirely different branch (the posting i made has not been 
>followed up to yet, even), so just a friendly reminder to go back and make
>sure that you dont get me into a flame war that i never really intended to
>get into. ;-)
>
You are correct, I missed quoted you.  Sorry.

Re: Should I learn C or Pascal?

[Tim Behrendsen]

johnf <johnf@nando.com> wrote in article
<johnf-1907961506170001@johnf-mac.nando.com>...
> In article <01bb7591$83087d60$87ee6fce@timpent.airshields.com>, "Tim
> Behrendsen" <tim@airshields.com> wrote:
> 
> >Carlos DeAngulo <cdvi@msg.itg.ti.com> wrote in article
> ><01bb74ac$b7aa7860$7b91f780@deangulo>...
> >> You should definitely learn C/C++. The business world today uses C++
as
> >its
> >> power language to develop the finest applications. Don't let anyone
guide
> >> you wrong.
> >
> >Not to start a flame war on C++, but all you newbie programmers
> >out there, don't believe everything you hear about C++.  Object
> >oriented programming has a lot of good concepts, but C++ is a bad
> >implementation of them.  Not that you shouldn't learn it, but
> >don't think it's the ultimate expression of what OOP is all about.
> >
> >C++: The PL/I of the 90s.
> 
> OK
> 
> I am one of these newbies.
> I haven't programmed anything, ever, with any language.
> I am currently learning C with the help of Dave Mark (Learn C on Mac) as
> my baptism into programming. 
> So, I am I only learning C, and not "how to program"? I don't understand
> how the two can be exclusive.
> How does one learn how to be a "Good Programmer" without picking a
> language to learn first, learning it well, then learning others as they
> interest you? 
> I am not trying to be a wise guy, just a guy who can learn to program
well
> enough to get out of his crappy job and into this (for me) exciting field
> as a career.
> I don't expect to start as the Sr. Developer on some project, I will
> happily slog it out in the trenches and pay my dues, just explain to me
> how to get there...
> 
> Thank you,
> Johnf
> 
> -- 
> johnf@nando.com

I will go so far as to say when you are learning to program, it doesn't
matter which language you learn. The important things to learn are
conceptual, not syntactical. In other words, you want to learn how
the computer works, and to understand the "mechanistic nature" of
programs. The actual details of the language are not as important.

If you want to program recreationally, then what you're doing is fine.

If you are really serious about programming as a career, and you want
to be ahead of 99% of all the other programmers, then let me make
a suggestion: Learn assembly language. It will probably be a bit more
confusing at the beginning, but start small and work your way up.
I guarantee you will learn more about programming than *any*
high-level language you could learn. After you gain confidence there,
you will truly understand how high-level languages *work*.

Re: Should I learn C or Pascal?

[Ralph Silverman]

johnf (johnf@nando.com) wrote:
: In article <01bb7591$83087d60$87ee6fce@timpent.airshields.com>, "Tim
: Behrendsen" <tim@airshields.com> wrote:

: >Carlos DeAngulo <cdvi@msg.itg.ti.com> wrote in article
: ><01bb74ac$b7aa7860$7b91f780@deangulo>...
: >> You should definitely learn C/C++. The business world today uses C++ as
: >its
: >> power language to develop the finest applications. Don't let anyone guide
: >> you wrong.
: >
: >Not to start a flame war on C++, but all you newbie programmers
: >out there, don't believe everything you hear about C++.  Object
: >oriented programming has a lot of good concepts, but C++ is a bad
: >implementation of them.  Not that you shouldn't learn it, but
: >don't think it's the ultimate expression of what OOP is all about.
: >
: >C++: The PL/I of the 90s.

: OK

: I am one of these newbies.
: I haven't programmed anything, ever, with any language.
: I am currently learning C with the help of Dave Mark (Learn C on Mac) as
: my baptism into programming. 
: So, I am I only learning C, and not "how to program"? I don't understand
: how the two can be exclusive.
: How does one learn how to be a "Good Programmer" without picking a
: language to learn first, learning it well, then learning others as they
: interest you? 
: I am not trying to be a wise guy, just a guy who can learn to program well
: enough to get out of his crappy job and into this (for me) exciting field
: as a career.
: I don't expect to start as the Sr. Developer on some project, I will
: happily slog it out in the trenches and pay my dues, just explain to me
: how to get there...

: Thank you,

: Johnf

: -- 
: johnf@nando.com

: Go Falcons

--
**************begin r.s. response****************

	poster admits to being inexperienced
	but manifests great common sense and
	good intelligence...

	the question is...
	is this adequate anymore...
	?

	the sense of frustration manifested
	is on the mark...
	what unseen and unadmitted factors
	are in operation here???

**************end r.s. response******************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[Joe Gwinn]

Shouldn't we answer the man's question, without drifting into theological
discussions about the relative merits of various languages?  He wants to
find a better job, not find religion, or become a better person.  So,
where are the jobs?  

Joe Gwinn


> : I am one of these newbies.
> : I haven't programmed anything, ever, with any language.
> : I am currently learning C with the help of Dave Mark (Learn C on Mac) as
> : my baptism into programming. 
> : So, I am I only learning C, and not "how to program"? I don't understand
> : how the two can be exclusive.
> : How does one learn how to be a "Good Programmer" without picking a
> : language to learn first, learning it well, then learning others as they
> : interest you? 
> : I am not trying to be a wise guy, just a guy who can learn to program well
> : enough to get out of his crappy job and into this (for me) exciting field
> : as a career.
> : I don't expect to start as the Sr. Developer on some project, I will
> : happily slog it out in the trenches and pay my dues, just explain to me
> : how to get there...

Re: Should I learn C or Pascal?

[Theodore E. Dennison]

Joe Gwinn wrote:
> 
> Shouldn't we answer the man's question, without drifting into theological
> discussions about the relative merits of various languages?  He wants to
> find a better job, not find religion, or become a better person.  So,
> where are the jobs?

Everywhere, and in every language.

Not a particularly helpful anwer I'm afraid...

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Should I learn C or Pascal?

[John A Hughes]

In article <gwinn-2307961502440001@smc19.ed.ray.com>,
Joe Gwinn <gwinn@res.ray.com> wrote:
>Shouldn't we answer the man's question, without drifting into theological
>discussions about the relative merits of various languages?  He wants to
>find a better job, not find religion, or become a better person.  So,
>where are the jobs?  

I hope the jobs are where the people who know what they're doing are.
I thought I *did* answer the guy's question-- pick the one that looks
easiest to you or for which you have the most resources, pay attention
to what people say about programming in the language, and when you're
comfortable with the ideas behind programming, learn whatever you
want.

The surest sign that a programmer is in the wrong field is his
inability to move from one language to another, or even, I would
argue, one paradigm to another. (There are tons of such people in this
industry. I'm no genius, but I think what they end up doing is pretty
sad.)  Time you spend learning any language will not be wasted. You do
not suddenly become magic and omniscient because you learn C or
Pascal.  And you do not suddenly become marketable because you taught
yourself C instead of Pascal. You're up against a wall of "experience
necessary" no matter what you do when you're learning. By all means,
learn C, because there really are tons of jobs for that, but "learning
C" is not enough.

To the original poster: Please, ignore this thread, and read the other
ones, and try to understand the advice you find there. You'll get much
farther paying close attention to that sort of thing and only
practical attention to the particular language you practice in. My
personal belief is that Pascal is better for starting out, as it's a
little easier for total neophytes. Learning C from there, once you
have the right habits, is a snap. If you find moving from Pascal to C
a big step, you should probably look for a different career.


jah

Re: Should I learn C or Pascal?

[John A Hughes]

In article <johnf-1907961506170001@johnf-mac.nando.com>,
johnf <johnf@nando.com> wrote:
>In article <01bb7591$83087d60$87ee6fce@timpent.airshields.com>, "Tim
>Behrendsen" <tim@airshields.com> wrote:
>
>>Carlos DeAngulo <cdvi@msg.itg.ti.com> wrote in article
>><01bb74ac$b7aa7860$7b91f780@deangulo>...
>>> You should definitely learn C/C++. The business world today uses C++ as
>>its
>>> power language to develop the finest applications. Don't let anyone guide
>>> you wrong.
>>
>>Not to start a flame war on C++, but all you newbie programmers
>>out there, don't believe everything you hear about C++...
>OK
>
>I am one of these newbies.
>I haven't programmed anything, ever, with any language.
>I am currently learning C with the help of Dave Mark (Learn C on Mac) as
>my baptism into programming. 
>So, I am I only learning C, and not "how to program"? I don't understand
>how the two can be exclusive...
>[deletia]
>I don't expect to start as the Sr. Developer on some project, I will
>happily slog it out in the trenches and pay my dues, just explain to me
>how to get there...

I was a TA for introductory computer science classes one year in grad
school.  The experience was pretty illuminating and I always remember
it when I read these silly arguments.

The first semester, they taught the poor kids Scheme, a dialect of
LISP.  These are kids who've never seen a program before in their
lives. However, one thing about the language is that its syntax and
semantics are crystal clear. When you program in Scheme, you're really
doing pure problem solving. The brightest kids in the class understood
this after a while and went to work. A sizeable portion of the class,
however, whined because they talked to "big, smart people in the real
world" who told them they were wasting their time, no one uses Scheme,
it's a stupid language, you can't do XYZ like you can in C or
whatever, man, universities are stupid, this country is fucked up
blablabla. I was a very friendly TA and did what I could to try to
persuade these students that there is more to learning a skill than
aping what big smart people in the real world do, and point out that
they were learning basics that they would use over and over in
whatever language they eventually used-- they were just starting out
with the basics and not spending time on syntactic crypticness and
memory management exotica. Some understood. Some never shut up with
their whining. And they were lousy students, too, and had bizarre,
undeserved arrogances because they were hobbyists who could write
programs to do this or that in whatever language and didn't need to
pay any attention to what we were trying to teach them.

Of course this would not be so interesting if I did not TA most of the
same students the very next semester in part II of intro comp sci,
which was taught in C++. Now, I personally don't believe C++ is a
language for beginners at all, though I don't sharre the opinion that
the language "sucks" or is a "bad implementation of OOL". However, the
good students, who had paid attention in the first semester, got used
to thinking about how to solve problems and express them in a
formalism, and didn't whine constantly about all those stupid
parentheses, managed to pick up the basics of C++ just as easily and
go on to solve the significantly harder problems they were given in
that semester. A significant portion of the whiners all practically
flunked; it was very sad. They hadn't learned a damn thing the first
semester except how stupid computer scientists are, and then with
their first taste of the "real world" they were hopeless.

I am not saying that this is anything other than anecdotal, but I
think it illustrates very nicely how someone who is really interested
in what programming is differs from someone who isn't, and exercises
linguistic bigorty in the name of what goes on in the real world. What
goes on in the real world, in fact, is that a bunch of morons who
really don't know how to program but have "used" hot new languages get
lots of jobs writing lousy code that other people who like solving
problems and expressing them in a formalism (any one will do, really)
have to maintain, debug, and rewrite totally when the smallest thing
changes because they have no foresight.

THAT is the real world.

Pick a language you feel comfortable with and that looks kind of easy
to start with. Read what EVERYone has to say about programming and
think about those things while you learn. Stuff will become clear to
you. Then you can move on to other languages to see how different
formalisms can help you express solutions differently. You will have
wasted no time learning any of the languages, and you'll be
appreciated more for being intelligent and having broad experience
than your coworkers who learned C++ out of the womb but has no idea
what it's for. IMHO, C and Pascal are not different enough to warrant
this silly argument; Pascal's a bit easier and probably better for
newbies. Learning C from there will be a total snap. And if you really
know what you're doing, you'll impress people in interviews and you
WILL get a job.


jah

Re: Should I learn C or Pascal?

[Craig Franck]

Just an observation about people you argue (excuse me discuss)  
programing languages. The people who know and use several languages 
seem much less inclined to declare any one the best, while those who
know or use only one language seem to think its always the best. 
My answer to the question would be with another question :
Why not learn both?

Since pascal is like so many other languages its good to in case 
you ever need to learn something like ada or join a team who is 
going to use Borland's Delphi to develope database applications.

Also since c is so unlike so many other langauages ie. its terse
syntax and heavy use of operators as oposed to keywords, that its
possible after years of heavy use to become "syntacticly crippled".
I know some excellent, highly intelligent programmers who can not
look at a COBOL listing with out having to sit down and stare out
the window just to get reorientated to reality...

Re: Should I learn C or Pascal?

[Patrick Horgan]

In my company and in many other startups in Silicon Valley doing the bleeding
edge work in the newest cool stuff, you can't get a job without being a C++
programmer, period.

If C++ is not a choice for you learn C.  Pascal won't get you a job.

Of course I think you should learn at least seven or eight high level languages
just for fun, and five or six assemblers for the same reason.

-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

Re: Should I learn C or Pascal?

[Jason Alan Turnage]

Patrick Horgan (patrick@broadvision.com) wrote:

: If C++ is not a choice for you learn C.  Pascal won't get you a job.

   Unless you want to be a high school computer teacher (snicker, snicker)

: Of course I think you should learn at least seven or eight high level
: languages just for fun, and five or six assemblers for the same reason.

   No doubt.  No good programmer only knows one language.  And no
   really good programmer doesn't know assembly.


--
Jason Turnage
Georgia Tech
turnage@cc.gatech.edu

Re: Should I learn C or Pascal?

[Robert Dewar]

Jason said

": Of course I think you should learn at least seven or eight high level
: languages just for fun, and five or six assemblers for the same reason.

   No doubt.  No good programmer only knows one language.  And no
   really good programmer doesn't know assembly."

I worry at this recommendation. It encourages what I often see at the
beginning level of the "language collecting" phenomenon. People think
that learning about programming is learning the syntax of lots of 
different languages, while not really knowing how to program in any of
them.

Yes it is true that really good programmers tend to know several languages
and to know assembler, but this is not always true, I know some quite
brilliant COBOL programmers around who don't know other languages, and
these days you quite often find very good programmers who only know C.

On the other hand, I sure know lots of *terrible* programmers who can
program equally terribly in many different languages.

I still think the important thing at the start is to learn how to program. It
is worth using a language that is rich enough to introduce all the necessary
abstraction concepts (Borland Object Pascal, Ada 95, C++ meet this criterion,
this is not a complete list of course, but you get the idea). It is a 
mistake to learn C to start with, since it lacks critical abstraction
features and so you will tend to miss the importance of data abstraction
and parametrization at the module level (it is not that this cannot be done
in C, just that you are unlikely to learn it if you start by learning C).

But in any case, the important thing is to concentrate on programming, not
on language collecting, at an early stage. Unfortunately many high school
teachers who teach computing have not progressed much beyond the language
collecting stage themselves, so you often have to rely on books at that
level.

Re: Should I learn C or Pascal?

[steved]

Robert Dewar writes:
[snip]
>I still think the important thing at the start is to learn how to program. It
>is worth using a language that is rich enough to introduce all the necessary
>abstraction concepts (Borland Object Pascal, Ada 95, C++ meet this criterion,
>this is not a complete list of course, but you get the idea). It is a 
>mistake to learn C to start with, since it lacks critical abstraction
>features and so you will tend to miss the importance of data abstraction
>and parametrization at the module level (it is not that this cannot be done
>in C, just that you are unlikely to learn it if you start by learning C).

Agreed.  I have an academic background in Computer Information Science and
Physics.  Since then I have worked as a "Software Engineer" for the last ten
years.

Physics teaches problem solving.  This involves breaking things down in an
abstract manner to learn things about the physical world.

IMHO Computer Science (really engineering) is best applied by breaking a
a problem down to an abstract description, and then designing a software
solution in terms of that abstraction.

Pascal, Ada, Modula-2 (and more I'm sure) permit you to write software in
what I would call "the problem domain".

In my experience, people with a 'C' only background have great difficulty in
understanding this form of abstraction.

In 'C' I find that programmers talk about the types "integer", and "double".
In Pascal I find that programmers talk about "inches" and "liters".

I also think it's a lot easier to go from Pascal to C than from C to Pascal,
although I did the first so it's hard to say.

Steve Doiel

Re: Should I learn C or Pascal?

[Peter Seebach]

In article <4spj1f$prf@news.pacifier.com>,
Steve Doiel <steved@pacifier.com> wrote:
>In 'C' I find that programmers talk about the types "integer", and "double".
>In Pascal I find that programmers talk about "inches" and "liters".

I object to this generalization.

This is true of inexperienced programmers in many languages.  It may be
true of more C programmers, but then, there are an awful lot of C programmers
from which to select the worst.  :)

However, it's not the C language that predisposes people to think in terms of
implementation rather than interface; rather, such people are likely to drift
towards C, because it allows them to work in this domain, and even makes it
tolerably easy.

I don't think it's fair or appropriate to blame C for the vast population of
idiots who get involved with it.  It's an excellent language in some ways,
which led to its eventual success in some fields, which led to a lot of utter
morons trying to use it, or write books about it.

This doesn't mean it can't be used well; although C doesn't always help you
write good code, it certainly doesn't prevent you from doing so.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

Re: Should I learn C or Pascal?

[Robert Dewar]

Peter says

"This doesn't mean it can't be used well; although C doesn't always help you
write good code, it certainly doesn't prevent you from doing so."

Although I agree that it does not *prevent* you, it certainly makes it
hard, and what we see in practice is that few programmers persevere
through the road blocks.

For example, headers can almost be used like package specs. They very 
seldom are (it is common for example to find uncommented headers).
But if you use headers as package specs, you find you have a nasty
problem if these headers define data, since the notion of macro copying
is not quite right. Yes, you can get around this, but most people don't
bother to do it systematically.

As anoher example, the lack of named types that are well separated means
that you gain much less from

   typedef int Inches;

than from (in Ada)

   type Inches is new Integer;

since in C you can assign Inches to int (or anything else) anyway. The
result, alhough it would still be useful for documentation and specification
purposes to introduce a typedef like the above, most C code does not bother.

In general both data abstraction and separation of interfaces and 
implementation do not come very naturally in a C environment. Now if
you have learned these principles in the context of another language
like Ada 95, then you will find that you can indeed apply them in C,
but people who learn C as their only, or first language, if not taught
*really* well are likely to establish their understanding of what
programming is about with a complete lack of understanding of these
fundamental issues.

Languages are more than just a set of syntax and semantic rules, they also
come with a "typical style" of writing code. This style is partly a matter
of tradition, but is strongly influenced by the design of the syntax and
semantics.

In language comparisons and discussions, people often trot out arguments
that boil down to the following:

   Anyone can write bad code in style x in language y for all x,y
   Anyone can use good technique x in language y for all x,y

These statements are generally true for any language other than a very
trivial one, or for techniques that are very specifically geared to 
language features.

However, they do not address the real issue, which is what is he typical
style of writing code in a given language and why? For the majority of 
programs, these are the real issues, and what we look for are languages
where the typical style of writing in the language embodies the principles
and techniques that we would like to encourage.

One clue of the importance of these typical style issues is the difficulty
of writing effective automatic translation programs from one language to
another. It is not too hard to write a translator that translates one
computer language to another, but to write one that takes a program written
in the typical style of language X and produces an idiomatic program written
in the typical style of langauge Y is extremely difficult. 

In fact I would venture to guess that at this stage translation of natural
languages from one to another is more successful than translation of
computer programming languages. That's because the entire strucure of
a program can be altered as a result of the shift of styles.

Note that this applies to a human too. Someone who knows French and 
English really well can take a novel written in one language, and produce
an acceptable idiomatic translation by translating sentence by sentence.

But even if you know C and Ada well, you will typically find that translating
a C program into Ada will involve major restructuring, and cannot be done
on a statement by statement basis.

Re: Should I learn C or Pascal?

[steidl]

In <dewar.837864318@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
>Peter says
>
[Lots of stuff talking about the limitations of C header files snipped.]
>
>Languages are more than just a set of syntax and semantic rules, they also
>come with a "typical style" of writing code. This style is partly a matter
>of tradition, but is strongly influenced by the design of the syntax and
>semantics.
>
[Some style stuff snipped.]
>
>One clue of the importance of these typical style issues is the difficulty
>of writing effective automatic translation programs from one language to
>another. It is not too hard to write a translator that translates one
>computer language to another, but to write one that takes a program written
>in the typical style of language X and produces an idiomatic program written
>in the typical style of langauge Y is extremely difficult. 
>
>In fact I would venture to guess that at this stage translation of natural
>languages from one to another is more successful than translation of
>computer programming languages. That's because the entire strucure of
>a program can be altered as a result of the shift of styles.
>
>Note that this applies to a human too. Someone who knows French and 
>English really well can take a novel written in one language, and produce
>an acceptable idiomatic translation by translating sentence by sentence.

It sounds like you have some experience with translating computer
prorams, but no real experience translating novels.  Human language
translation presents many of the same problems as computer program
translation does - i.e. different sentences may talk about the same
thing or be in the same style, or even talk about each other, and
translating them from one language to another without consistency
will result in a lackluster outcome.  Both programs and novels involve
a certain style and content.  However, I think that human novels are
generally harder to translate than computer programs because a
computer program is self-contained (if you include the language and
libraries), whereas a novel draws on an entire culture.  Translating
the novel effectively often means having intimate knowledge of two
cultures and being able to make mappings (which are sometimes very
subtle) from one to the other.  Some really difficult problems
(difficult even for very intelligent humans) can arise when trying to
perform this task.  To see examples of such, you should read "Godel,
Escher, Bach:  The Eternal Golden Braid" by Douglas Hofstadter.

BTW, everyone who likes to program should read this book, IMHO.

Of course, if you want to make computer program translation as hard as
translating novels, require the translater to translate the comments
from the context of the first languages' community to that of the
second would be a start.


-Jeff

steidl@centuryinter.net - http://www.dont.i.wish.com/
All opinions are my own, and are subject to change without notice.

Re: Should I learn C or Pascal?

[Stephen M O'Shaughnessy]

In article <4suk39$9h2@news.ld.centuryinter.net>, steidl@centuryinter.net says...
 However, I think that human novels are
>generally harder to translate than computer programs because a
>computer program is self-contained (if you include the language and
>libraries), whereas a novel draws on an entire culture.  Translating
>the novel effectively often means having intimate knowledge of two
>cultures and being able to make mappings (which are sometimes very
>subtle) from one to the other.  Some really difficult problems
>(difficult even for very intelligent humans) can arise when trying to
>perform this task.  To see examples of such, you should read "Godel,
>Escher, Bach:  The Eternal Golden Braid" by Douglas Hofstadter.
>
>BTW, everyone who likes to program should read this book, IMHO.
>
Most people believe the Bible to be the in-errant word of God.  For a real eye opener read two 
versions side by side, say the King James and the Living Bible.

Sorry for straying off the subject.

Re: Should I learn C or Pascal?

[Richard A. O'Keefe]

smosha@most.fw.hac.com (Stephen M O'Shaughnessy) writes:

>In article <4suk39$9h2@news.ld.centuryinter.net>, steidl@centuryinter.net says...
>Most people believe the Bible to be the in-errant word of God.

Quantifying over the whole world, this statement is false.

For those people who *do* believe it, the agreed definition of
inerrancy applies *solely* to the original text in the original languages;
every copy, every translation, and every interpretation is corrigible.

>For a real eye opener read two 
>versions side by side, say the King James and the Living Bible.

(a) The Authorised Version came out in 1611.  That's a long time ago,
    and English has changed quite a lot.
(b) The Living Bible IS NOT A TRANSLATION!  It is openly and unashamedly
    a *paraphrase*.

For a fairer comparison, consider the current Jewish Publication Society
translation of the Tanach, and a really professional Christian translation
such as The Revised English Bible or the International Version.  Despite
being produced by disjoint committees with radically different
theological biases; some of the sentences are word for word identical.

I think that what this shows is that it *is* possible to do a very good
job of translating between languages in two unrelated families 2500+
years apart in dramatically different cultures *if* you take hundreds of
scholars, hundreds of years, and build up a "translation technology",
and libraries full of information about the cultural background.

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Should I learn C or Pascal?

[Michael Ickes]

Richard A. O'Keefe wrote:
> 
> smosha@most.fw.hac.com (Stephen M O'Shaughnessy) writes:
> 
> >In article <4suk39$9h2@news.ld.centuryinter.net>, steidl@centuryinter.net says...
> >Most people believe the Bible to be the in-errant word of God.
> 
> Quantifying over the whole world, this statement is false.
> 
> For those people who *do* believe it, the agreed definition of
> inerrancy applies *solely* to the original text in the original languages;
> every copy, every translation, and every interpretation is corrigible.
> 
> >For a real eye opener read two
> >versions side by side, say the King James and the Living Bible.
> 
> (a) The Authorised Version came out in 1611.  That's a long time ago,
>     and English has changed quite a lot.
> (b) The Living Bible IS NOT A TRANSLATION!  It is openly and unashamedly
>     a *paraphrase*.
> 
> For a fairer comparison, consider the current Jewish Publication Society
> translation of the Tanach, and a really professional Christian translation
> such as The Revised English Bible or the International Version.  Despite
> being produced by disjoint committees with radically different
> theological biases; some of the sentences are word for word identical.
> 
> I think that what this shows is that it *is* possible to do a very good
> job of translating between languages in two unrelated families 2500+
> years apart in dramatically different cultures *if* you take hundreds of
> scholars, hundreds of years, and build up a "translation technology",
> and libraries full of information about the cultural background.
> 
> --
> Fifty years of programming language research, and we end up with C++ ???
> Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

 Should'nt this post go in alt.religious.stuff..................?

Re: Should I learn C or Pascal?

[Andy Askey]

Michael Ickes <mickes@gnn.com> wrote:

> Should'nt this post go in alt.religious.stuff..................?

I thought Ada was a religion.  A form of Budhism, I believe.
--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com

Re: Should I learn C or Pascal?

[system]

 ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>smosha@most.fw.hac.com (Stephen M O'Shaughnessy) writes:
>
>(b) The Living Bible IS NOT A TRANSLATION!  It is openly and unashamedly
>    a *paraphrase*.

amen (and a lousy one IMHO)

>consider the current Jewish Publication Society
>translation of the Tanach, and a really professional Christian translation
>such as The Revised English Bible or the International Version.  Despite
>being produced by disjoint committees with radically different
>theological biases; some of the sentences are word for word identical.

>I think that what this shows is that it *is* possible to do a very good
>job of translating between languages in two unrelated families 2500+
>years apart in dramatically different cultures *if* you take hundreds of
>scholars, hundreds of years, and build up a "translation technology",
>and libraries full of information about the cultural background.

And if you include enough footnotes to double the amount of text.

[although this started out as a religious discussion and so discussing
the Bible seems on topic I will try to make it even more on-topic]

It also shows (by analogy) that it is possible to do good programming
in any language as long as you work at it.

>Fifty years of programming language research, and we end up with C++ ???
>Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Robert

Re: Should I learn C or Pascal?

[Jon Bell]

 Peter Seebach <seebs@solon.com> wrote:
>I don't think it's fair or appropriate to blame C for the vast population of
>idiots who get involved with it.  It's an excellent language in some ways,
>which led to its eventual success in some fields, which led to a lot of utter
>morons trying to use it, or write books about it.

It also led to C being used as a "Swiss-army-knife" language, often in 
areas in which another language would be a better choice.

>This doesn't mean it can't be used well; although C doesn't always help you
>write good code, it certainly doesn't prevent you from doing so.

Agreed.  By the same token, it's perfectly possible to design good
programs and write good code in older versions of Fortran or BASIC.  But
you have to take a lot more care when doing this; you have to invent your
own "building blocks" for good design, and you have to use them
consistently.  Languages with good modularizing features built into them
make this easier. 

When someone is beginning to program, it's hard enough already to get 
them to use these modularizing features, even when they're built in, 
because they require some (gasp!) thought and planning before coding.  
When they have to "simulate" these features using lower-level constructs, 
it just makes more work for them, and they resist even more strongly.

-- 
Jon Bell <jtbell@presby.edu>                        Presbyterian College
Dept. of Physics and Computer Science        Clinton, South Carolina USA
[for beginner's Usenet info, see http://cs1.presby.edu/~jtbell/usenet/]

Re: Should I learn C or Pascal?

[Andy Askey]

jtbell@presby.edu (Jon Bell) wrote:

> Peter Seebach <seebs@solon.com> wrote:
>>This doesn't mean it can't be used well; although C doesn't always help you
>>write good code, it certainly doesn't prevent you from doing so.

>Agreed.  By the same token, it's perfectly possible to design good
>programs and write good code in older versions of Fortran or BASIC.  But
>you have to take a lot more care when doing this; you have to invent your
>own "building blocks" for good design, and you have to use them
>consistently.  Languages with good modularizing features built into them
>make this easier. 

>When someone is beginning to program, it's hard enough already to get 
>them to use these modularizing features, even when they're built in, 
>because they require some (gasp!) thought and planning before coding.  
>When they have to "simulate" these features using lower-level constructs, 
>it just makes more work for them, and they resist even more strongly.

>-- 
>Jon Bell <jtbell@presby.edu>                        Presbyterian College
>Dept. of Physics and Computer Science        Clinton, South Carolina USA
>[for beginner's Usenet info, see http://cs1.presby.edu/~jtbell/usenet/]


I have found that there are always littlet nuances of algorithm
implementation depending on the language choosen.  While most well
designed algorithms can be implemented in any language, it is not
always a 1 to 1 maping when switching languages.  If you wish to see
the complexity of implementing a C or Fortran algorithm in Ada, take a
look at the book "Numerical Recipes in C" (or Fortran).  Try porting
these routines from one language to another.  You can usually do it,
but you always can find an neater approach in the different language.

So much for the standard languages.  If you begin to look at parallel
processing on multiple CPUs, then the algorithms are in no way
similar.  Computing an FFT on a set of data in Ada or C calls for one
or more loops of simplistic calculations and data moving.  If you
write the same code in parallel C on a massively parallel computer
with 16,000 processors, then no looping is required.

And with PCs moving to multiprocessors as the next great jump of in my
den technology,  algorithms will become more and more dependent on the
language and hardware used.  (Kinda like when computers were first
discovered -- I believe earth must be the cosmic junk yard of old
technology after other beings grow tired with "the next great thing")

Oh, by the way, learn C and not Pascal.  Everyone will hire a C
programmer but I see very few jobs for Pascal gurus.

--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com

Re: Should I learn C or Pascal?

[Ralph Silverman]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Jason said

: ": Of course I think you should learn at least seven or eight high level
: : languages just for fun, and five or six assemblers for the same reason.

:    No doubt.  No good programmer only knows one language.  And no
:    really good programmer doesn't know assembly."

: I worry at this recommendation. It encourages what I often see at the
: beginning level of the "language collecting" phenomenon. People think
: that learning about programming is learning the syntax of lots of 
: different languages, while not really knowing how to program in any of
: them.

: Yes it is true that really good programmers tend to know several languages
: and to know assembler, but this is not always true, I know some quite
: brilliant COBOL programmers around who don't know other languages, and
: these days you quite often find very good programmers who only know C.

: On the other hand, I sure know lots of *terrible* programmers who can
: program equally terribly in many different languages.

: I still think the important thing at the start is to learn how to program. It
: is worth using a language that is rich enough to introduce all the necessary
: abstraction concepts (Borland Object Pascal, Ada 95, C++ meet this criterion,
: this is not a complete list of course, but you get the idea). It is a 
: mistake to learn C to start with, since it lacks critical abstraction
: features and so you will tend to miss the importance of data abstraction
: and parametrization at the module level (it is not that this cannot be done
: in C, just that you are unlikely to learn it if you start by learning C).

: But in any case, the important thing is to concentrate on programming, not
: on language collecting, at an early stage. Unfortunately many high school
: teachers who teach computing have not progressed much beyond the language
: collecting stage themselves, so you often have to rely on books at that
: level.


--
************begin r.s. response*****************

	1) learn programming
		without practising programming
	??????????
	actually,  some very advanced minds of the
	past did the like of this and produced the 
	foundations of computer programming of today...

	arguably,  gottlib frege,  a german mathematics
	specialist of the 19th century researched
		formal languages
	which are much like programming languages...

	in ancient greece,  a mathematics specialist
	known as
		eretosthenes
	produced the algorithm for a
		prime number finder
	known as the
		sieve of eretosthenes
	this has been used as the basis for
	widely utilized benchmarking programs
	(in the decade 1980-1989) and now.  
	
	(a team i worked with in 1983 coded this in
	the 'c' programming language
	and ran this on a
		western electric 3b20s!)

	however...
	reasonably,  the great mathematics minds
	of the past generally would have preferred to use
	computers such as we have,  if such then were
	available...

	2) collecting languages?????????
	the computer science curriculum of the
		acm
	(in past times)
	included such.
	personally,  i learned this way...
	this was very difficult...
	and certainly beneficial!

************end r.s. response*******************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[Vic Metcalfe]

Jason Alan Turnage (turnage@cc.gatech.edu) wrote:
: Patrick Horgan (patrick@broadvision.com) wrote:

: : If C++ is not a choice for you learn C.  Pascal won't get you a job.
:    Unless you want to be a high school computer teacher (snicker, snicker)

My company does development in Delphi, which is a mutant version of Pascal.
We recently tried to hire additional Delphi programmers, but found that
none who were at all qualified could be found.  We would have been happy
to find any programmer that knew Pascal as well as most good programmers 
know C.

I didn't see in your orignal post what platform you are learning on, but
if it is MS-Windows, and you have access to Delphi, there are plenty of
jobs out there.  On the other hand, if you are using unix, and have a
standard or extended pascal compiler, I wouldn't waste my time with it,
but would learn other more common languages.

Good luck,
  Vic.

Re: Should I learn C or Pascal?

[Robert Dewar]

Patrick said

"In my company and in many other startups in Silicon Valley doing the bleeding
edge work in the newest cool stuff, you can't get a job without being a C++
programmer, period."

Note the phrase "C++ programmer"

the second word is by FAR the most important. Concentrate on learning the
basic principles of computer science and software engineering. The language
you learn at first is not so important, and I would say Pascal is probably
a far better choice than C for experimentation with algorithms. You can
easily learn whatever is the language-du-jour when it comes to getting
a job later on.

Re: Should I learn C or Pascal?

[Billy Chambless]

In article <dewar.837728071@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
 
|> Note the phrase "C++ programmer"
 
|> the second word is by FAR the most important. Concentrate on learning the
|> basic principles of computer science and software engineering. The language
|> you learn at first is not so important, and I would say Pascal is probably

Amen! Any good programmer can learn any new langauge that coems along.
The danger new programmers often fall into is that of learning to be a
"foo programmer", where foo is the language du jour.

The technology changes to fast to be locked into one mode. C++ is
meaga-way-cool today, but remember, C was the end-all a while back, and
COBOL before that.

Don't strive to be a C++ Programmer or a Java Programmer -- become a
Good Programmer.
-- 
* Billy Chambless  | billy@cast.msstate.edu |  voice: 601-688-7608
* Mississippi State University Center for Air-Sea Technology 
* "And I don't like doing silly things (except on purpose)."
*                  --Larry Wall in <1992Jul3.191825.14435@netlabs.com>

Re: Should I learn C or Pascal?

[Reto Koradi]

Patrick Horgan wrote:
> In my company and in many other startups in Silicon Valley doing
> the bleeding edge work in the newest cool stuff, you can't get a
> job without being a C++ programmer, period.

Such statements keep irritating me. Programming languages are nothing
but tools, and if you know the principles of programming and have
learned a few other languages, you start programming in C on the
first day, and learn about the more subtle points with time.
I grew up with the Pascal/Modula-2/Oberon line (what do you expect
when studying at Wirth's university?), and didn't have the
slightest problem programming in C when I started my first job.

Even though C and C++ dominate the workplace, languages like Modula-2
are still much better for learning programming.
-- 
Reto Koradi (kor@mol.biol.ethz.ch, http://www.mol.biol.ethz.ch/~kor)

Re: Should I learn C or Pascal?

[TRAN PHAN ANH]

Irritating, but that's the reality.  There are subtle points and pitfalls 
with all languages.  How many times have you wondered why something that 
should work, but does not?  Then you find that the reason it does not work 
is due to some "idosynchracies" or "features" of the language? :-)  
Therefore, companies ask for experience.  And C/C++ is a skill that is 
asked about quite often.

Of course, a good problem solver makes a better employee than a person, who 
"just" knows a dozen of languages.  But a good problem solver with expertise 
in a dozen of languages is a dream for any company.

Anh

In article <31EF54CA.15FB@spectrospin.ch>, Reto Koradi <kor@spectrospin.ch> writes:
> Patrick Horgan wrote:
>> In my company and in many other startups in Silicon Valley doing
>> the bleeding edge work in the newest cool stuff, you can't get a
>> job without being a C++ programmer, period.
> 
> Such statements keep irritating me. Programming languages are nothing
> but tools, and if you know the principles of programming and have
> learned a few other languages, you start programming in C on the
> first day, and learn about the more subtle points with time.
> I grew up with the Pascal/Modula-2/Oberon line (what do you expect
> when studying at Wirth's university?), and didn't have the
> slightest problem programming in C when I started my first job.
> 
> Even though C and C++ dominate the workplace, languages like Modula-2
> are still much better for learning programming.
> -- 
> Reto Koradi (kor@mol.biol.ethz.ch, http://www.mol.biol.ethz.ch/~kor)

Re: Should I learn C or Pascal?

[Scott McMahan - Softbase Systems]

Patrick Horgan (patrick@broadvision.com) wrote:

: Of course I think you should learn at least seven or eight high level languages
: just for fun 

Once you know C, Pascal and other structured languages
aren't much of a challenge. Perl is very similar. You can
learn 5-6 languages just from C and a little study. Throw
in C++ and couple of others and you'll be all set.

: and five or six assemblers for the same reason.

I'd rather just learn C and port it. Asm isn't as important
anymore now that there's so many different platforms.

Scott

Re: Should I learn C or Pascal?

[steidl]

In <4sokr1$4c9@news.interpath.net>, softbase@mercury.interpath.com (Scott McMahan - Softbase Systems) writes:
>Patrick Horgan (patrick@broadvision.com) wrote:
>
>: Of course I think you should learn at least seven or eight high level languages
>: just for fun 
>
>Once you know C, Pascal and other structured languages
>aren't much of a challenge. Perl is very similar. You can
>learn 5-6 languages just from C and a little study. Throw
>in C++ and couple of others and you'll be all set.

It is more challenging (and beneficial) if you pick languages that are
*not* like C/C++ when picking other languages to learn.  Just a few
examples:  SmallTalk, Haskell, Prolog.  Each of these has unique and
fundamental ways of doing things that are not a part of C or C++.

>: and five or six assemblers for the same reason.
>
>I'd rather just learn C and port it. Asm isn't as important
>anymore now that there's so many different platforms.

He didn't say to write your programs in assembler, just learn it.  It
can give you a better understanding of what's going on "under the hood"
and can thus improve your C/C++ programming.  (I personally found that
pointers were much easier to learn in 6809 than in C.)  Someone in the
comp.lang.c++ group recently asked why they were getting a stack
overflow when their procedure said they had sufficient stack space.  If
that person had been initiated into the world of assembly language
programming and interrupt handling, they would have known why their C++
program wasn't working.


-Jeff

steidl@centuryinter.net - http://www.dont.i.wish.com/
All opinions are my own, and are subject to change without notice.

Re: Should I learn C or Pascal?

[Tim Behrendsen]

Scott McMahan - Softbase Systems <softbase@mercury.interpath.com> wrote in
article <4sokr1$4c9@news.interpath.net>...
> Patrick Horgan (patrick@broadvision.com) wrote:
> 
> 
> : and five or six assemblers for the same reason.
> 
> I'd rather just learn C and port it. Asm isn't as important
> anymore now that there's so many different platforms.
> 
> Scott

Big disagreement ... assembler is most critical thing any
programmer can learn.  Not because you're going to use it
every day, but because it will teach you more about what's
*really* going on than 10 high-level language classes.

That's like saying that since most Electronic Engineers use
ICs, it's not necessary to learn the fundamentals of resisters,
capaciters, and transisters.

Programmers who do not assembly language are dangerous,
because they do not fundamentally understand what the
compiler is generating. They believe in "The Myth of the
Optimizing Compiler", that "compilers are so good nowadays
that you don't have to worry about writing efficient code.
If you do have to worry, then get a better compiler."

Re: Should I learn C or Pascal?

[Rich Maggio]

> That's like saying that since most Electronic Engineers use
> ICs, it's not necessary to learn the fundamentals of resisters,
> capaciters, and transisters.

Amen!

> Programmers who do not assembly language are dangerous,
> because they do not fundamentally understand what the
> compiler is generating. They believe in "The Myth of the
> Optimizing Compiler", that "compilers are so good nowadays
> that you don't have to worry about writing efficient code.
> If you do have to worry, then get a better compiler."

An additional thought along these lines.  A programmer should be VERY familiar with the inner workings of the 
OS that they are working with.  When working in a multitasking environment, it is important for the programmer 
(software engineer) to understand just how the multitasking is achieved in the OS.  With this understanding, 
efficient and bug free code can be written.  Programmers that see multitasking as "some magic thing that just 
happens" are pretty dangerous.  I have seen numerous bugs that can be explained understood very easily with an 
understanding of what the OS is really doing under the hood.

Rich Maggio

Re: Should I learn C or Pascal?

[Robert Dewar]

"> Programmers who do not assembly language are dangerous,
> because they do not fundamentally understand what the
> compiler is generating."

What I tell my students is that learning assembly language (or rather
machine architecture and machine language, which is really the issue) is
like learning how internal combustion engines and other elements of a car
work. Even if you do not plan to become an auto mechanic, you will find
that this knowledge is very useful, both from the point of view of allowing
you to figure out what might be wrong, and in understanding what the
auto-mechanic has to say when something really does go wrong.

Re: Should I learn C or Pascal?

[Ralph Silverman]

Tim Behrendsen (tim@airshields.com) wrote:
: Scott McMahan - Softbase Systems <softbase@mercury.interpath.com> wrote in
: article <4sokr1$4c9@news.interpath.net>...
: > Patrick Horgan (patrick@broadvision.com) wrote:
: > 
: > 
: > : and five or six assemblers for the same reason.
: > 
: > I'd rather just learn C and port it. Asm isn't as important
: > anymore now that there's so many different platforms.
: > 
: > Scott

: Big disagreement ... assembler is most critical thing any
: programmer can learn.  Not because you're going to use it
: every day, but because it will teach you more about what's
: *really* going on than 10 high-level language classes.

: That's like saying that since most Electronic Engineers use
: ICs, it's not necessary to learn the fundamentals of resisters,
: capaciters, and transisters.

: Programmers who do not assembly language are dangerous,
: because they do not fundamentally understand what the
: compiler is generating. They believe in "The Myth of the
: Optimizing Compiler", that "compilers are so good nowadays
: that you don't have to worry about writing efficient code.
: If you do have to worry, then get a better compiler."

--
***********begin r.s. response*************

	a) start low and go high...
	b) start high and go low...

	common sense tells us either might work...
	experience tells us each has...

***********end r.s. response***************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[Tim Behrendsen]

Ralph Silverman <z007400b@bcfreenet.seflin.lib.fl.us> wrote in article
<4t0pcb$poq@nntp.seflin.lib.fl.us>...
> Tim Behrendsen (tim@airshields.com) wrote:
> : Scott McMahan - Softbase Systems <softbase@mercury.interpath.com> wrote
in
> : article <4sokr1$4c9@news.interpath.net>...
> : > Patrick Horgan (patrick@broadvision.com) wrote:
> : > 
> : > 
> : > : and five or six assemblers for the same reason.
> : > 
> : > I'd rather just learn C and port it. Asm isn't as important
> : > anymore now that there's so many different platforms.
> : > 
> : > Scott
> 
> : Big disagreement ... assembler is most critical thing any
> : programmer can learn.  Not because you're going to use it
> : every day, but because it will teach you more about what's
> : *really* going on than 10 high-level language classes.
> 
> : That's like saying that since most Electronic Engineers use
> : ICs, it's not necessary to learn the fundamentals of resisters,
> : capaciters, and transisters.
> 
> : Programmers who do not assembly language are dangerous,
> : because they do not fundamentally understand what the
> : compiler is generating. They believe in "The Myth of the
> : Optimizing Compiler", that "compilers are so good nowadays
> : that you don't have to worry about writing efficient code.
> : If you do have to worry, then get a better compiler."
> 
> 	a) start low and go high...
> 	b) start high and go low...
> 
> 	common sense tells us either might work...
> 	experience tells us each has...

Uh, so what?  The fact that people have learned both ways
is completely irrelevent.

The important question is what is the best way for the most
people, and experience has shown me that it's way better to
ground people in foundations of how computers really work. That
way they get a sense of the procedural nature of computers, and
they are not bogged down with 10 tons of abstract crap before
they are prepared to know what it really means.

Re: Should I learn C or Pascal?

[Andrew Gierth]

[This thread should never have been injected into comp.unix.programmer.
Would further contributors *please* take note. Followups set.]

billy@cast.msstate.edu wrote:
>In article <dewar.837728071@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
>|> Note the phrase "C++ programmer"
 
>|> the second word is by FAR the most important. Concentrate on learning the
>|> basic principles of computer science and software engineering. The language
>|> you learn at first is not so important, and I would say Pascal is probably

>Amen! Any good programmer can learn any new langauge that coems along.
>The danger new programmers often fall into is that of learning to be a
>"foo programmer", where foo is the language du jour.

>The technology changes to fast to be locked into one mode. C++ is
>meaga-way-cool today, but remember, C was the end-all a while back, and
>COBOL before that.

>Don't strive to be a C++ Programmer or a Java Programmer -- become a
>Good Programmer.

Re: Should I learn C or Pascal?

[Walter B. Hollman Sr.]

Would you be terribly upset if I asked you to take your SILLY-ASSED
Question To The "C" or "Pascal" news group? 
 
On Jul 16, 1996 05:30:47 in article <Re: Should I learn C or Pascal?>, 'Lee
Crites <adonai@mail.jump.net>' wrote: 
 
 
>z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman) wrote: 
>>Gabor Egressy (gegressy@uoguelph.ca) wrote: 
>>: Seth Perlman (sperlman@ezo.net) wrote: 
>>: : First, my situation: I am going to be a senior in high school in the 

>fall. 
>>: : I've been toying with programming computers ever since I learned
BASIC on 
>>: : my Commodore 64 at the age of 6. I learned a smattering of C a few
years 
>>: : ago, and I took a semester course in school this year which was an
intro 
>>: : to Pascal. Sadly, it's the most advanced computer course at my
school, 
>>: : which means that I have nowhere else to turn for instruction in 
>>: : programming. 
>> 
>> 
>>: : *** Should I learn to program in C or Pascal? *** 
>> 
>>: Here is a quote from Brian W. Kernighan of "The C Programming Language"
 
>fame. 
>>: He is also an internationally respected lecturer who has been there
since  
>>: the inception of UNIX and C. 
>>: "I feel that it is a mistake to use Pascal for anything much beyond its
 
>>: original target. In its pure form, Pascal is a toy language, suitable
for  
>>: teaching but not for real programming." 
>>: Draw your own conclusions. 
> 
>Before you "draw your own conclusions," keep in mind that Kernighan is one
of  
>the  
>founding voices in c.  A more biased opinion could hardly be found.  Ask
Wirth  
>what  
>he thinks about the C vs Pascal dispute.  It would be the same kind of
thing. 
> 
>Also keep in mind that this rather lengthy diatribe was comparing c with
the  
>'standard' pascal, not what it has become.  Today's pascal is as different
from  
>what  
>was being discussed as today's c++ is from the old c. 
> 
>Both languages are evolving and becoming more and more of what the
programmers  
>need.  
>Part and parcel to the "should I learn this or that" question, though, is
the  
>thought that one can do without knowing one of them.  I believe this is
wrong.   
>The  
>real answer, from my perspective, is you should learn BOTH, and learn both
 
>WELL! 
> 
>After all, these c vs pascal disputes are chiefly religious in nature.   
>Dispense  
>with the arm waving and name calling, either one will do for most
applications.  
>I  
>have heard some tell me how some application could only be written in one
or  
>the  
>other, but so far nobody's been able to really convince me. 
> 
>I remember the arguments about how COBOL was the ultimate language and
nothing  
>else  
>could be needed.  I've been hearing these rather anal arguments for nearly
20  
>years.  
>(I started learning programming in college in 1976) 
> 
>So please, don't trap yourself in the one-or-the-other mindset.  Learn
both.   
>You  
>will be a better programmer -- and a more valuable employee -- for it. 
> 
>Lee Crites 
>Computer Mavericks 
> 
> 
> 
> 
> 
-- 
Walter B. Hollman Sr 
 
 
 
 
 
 
 

Re: Should I learn C or Pascal?

[Richard A. O'Keefe]

>Gabor Egressy (gegressy@uoguelph.ca) wrote:
>: Here is a quote from Brian W. Kernighan of "The C Programming Language" fame.
>: He is also an internationally respected lecturer who has been there since 
>: the inception of UNIX and C.
>: "I feel that it is a mistake to use Pascal for anything much beyond its 
>: original target. In its pure form, Pascal is a toy language, suitable for 
>: teaching but not for real programming."
>: Draw your own conclusions.


I have read that paper, and have often recommended it to people.
But by now it is an OLD paper, so it is important to understand that
Kernighan is basically talking about ISO 7185 Level 0 Pascal.
 - Turbo Pascal is a completely different language
 - Delphi is a completely different language
 - ISO Pascal Extended (with or without the Object-Oriented Extensions
   to Pascal) is a completely different language

It would be very easy for someone familiar with ISO Pascal Extended to
write a paper "Why C is not my favourite programming language" pointing
out that unlike (the current international standard entitled to the name)
Pascal, C
 - does not have modules
 - does not have type-safe separate compilation
 - does not have Ada-style "type schemas"
 - does not have syntax for string concatenation, comparison, substring
 - does not have support for arrays whose size is not known until run time
 - does not have nested procedures
 - does not have complex arithmetic


The only thing is, after studying ISO 10206 I can see little reason for
using Pascal instead of Ada; Ada has everything that Pascal has and then
some.  As for the 1993 Object Oriented Extensions to Pascal, I greatly
prefer the object model of Ada 95 (having to *manually* destroy every
object because objects are really pointers does *not* appeal to me).

My answer to the question that is the Subject of this thread is
    - don't learn Pascal first
    - don't learn C first either
    - do learn Scheme first (try "The Little Schemer", then "Simply Scheme")
    - or learn Ada first.

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Should I learn C or Pascal?

[Darin Johnson]

> Also keep in mind that this rather lengthy diatribe was comparing c with the 
> 'standard' pascal, not what it has become.  Today's pascal is as
> different from what was being discussed as today's c++ is from the old c.

True, Pascal has been mostly subsumed by Modula II and III.  These are
nice languages, and you can do real-world and systems programming in
them.  They're not as popular (you probably have to go commercial to
get a compiler).
-- 
Darin Johnson
djohnson@ucsd.edu	O-
       Support your right to own gnus.

Re: Should I learn C or Pascal?

[Ralph Silverman]

Darin Johnson (djohnson@tartarus.ucsd.edu) wrote:
: > Also keep in mind that this rather lengthy diatribe was comparing c with the 
: > 'standard' pascal, not what it has become.  Today's pascal is as
: > different from what was being discussed as today's c++ is from the old c.

: True, Pascal has been mostly subsumed by Modula II and III.  These are
: nice languages, and you can do real-world and systems programming in
: them.  They're not as popular (you probably have to go commercial to
: get a compiler).
: -- 
: Darin Johnson
: djohnson@ucsd.edu	O-
:        Support your right to own gnus.

--
************begin r.s. response********************

	(re.  modula2
		in posting cited above)

	an amazing
		shareware
		^^^^^^^^^
		modula2 compiler
	for
		(ms pc dr)dos
	is widely available,  named

		fmodula2
		^^^^^^^^
	.

************end r.s. response**********************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[Aron Felix Gurski]

Darin Johnson wrote:
> 
> > Also keep in mind that this rather lengthy diatribe was comparing c with the
> > 'standard' pascal, not what it has become.  Today's pascal is as
> > different from what was being discussed as today's c++ is from the old c.
> 
> True, Pascal has been mostly subsumed by Modula II and III.  These are
> nice languages, and you can do real-world and systems programming in
> them.  They're not as popular (you probably have to go commercial to
> get a compiler).
> --
> Darin Johnson
> djohnson@ucsd.edu       O-
>        Support your right to own gnus.

The language names are Modula-2 and Modula-3. There is a shareware Modula-2
compiler available for the DOS platform. Check the FAQ in comp.lang.modula2
for information about this and other compilers. Modula-3 compilers are 
available by ftp; check the faq in comp.lang.modula3.

		-- Aron

Re: Should I learn C or Pascal?

[Andrew Gierth]

[This thread should never have been injected into comp.unix.programmer.
Would respondents *please* take that into account. Followups set.]

Craig Franck <clfranck@worldnet.att.net> wrote:
>Just an observation about people you argue (excuse me discuss)  
>programing languages. The people who know and use several languages 
>seem much less inclined to declare any one the best, while those who
>know or use only one language seem to think its always the best. 
>My answer to the question would be with another question :
>Why not learn both?

>Since pascal is like so many other languages its good to in case 
>you ever need to learn something like ada or join a team who is 
>going to use Borland's Delphi to develope database applications.

>Also since c is so unlike so many other langauages ie. its terse
>syntax and heavy use of operators as oposed to keywords, that its
>possible after years of heavy use to become "syntacticly crippled".
>I know some excellent, highly intelligent programmers who can not
>look at a COBOL listing with out having to sit down and stare out
>the window just to get reorientated to reality...

Re: Should I learn C or Pascal?

[Andrew Gierth]

[This thread should never have been injected into comp.unix.programmer.
Would all respondents *please* take that into account. Followups set.]

jtbell@presby.edu wrote:
> Robert Dewar <dewar@cs.nyu.edu> wrote:
>>First, the business world uses many languages -- even today far more programs
>>are written in COBOL than in C and C++ combined by a very large margin.
>
>Just out of curiosity, how much *new* development takes place in COBOL, 
>as opposed to maintainance and extension of existing systems?   This does 
>not imply that I'm downgrading maintainance, by the way.  I've done some 
>of it (although not in COBOL), and I know that it can be a real challenge.

Re: Should I learn C or Pascal?

[Andrew Gierth]

[This thread should never have been injected into comp.unix.programmer.
Would respondents *please* take that into account. Followups set.]

brashear@ns1.sw-eng.falls-church.va.us wrote:
>In article <4sjmtk$e95@herald.concentric.net>,
>Mark  McKinney  <mckmark@mail.concentric.net> wrote:
>>
>>This raises a big concern I have always had about how programming is taugh 
>>in general. Problem solving techniques, style, methodologies etc. should 
>>be taught or learned prior to a programming language. The "this is how you 
>>do it and then this is how yu do it well" approach seems highly 
>>ineffective. 
>>-Mark
>>
>>
>
>This reminds me of the high school English teacher who said "Teach them
>grammar in elementary school, and I'll teach them how to write (compose)."
>
>How do you learn grammar without writing (composing)?  How do you learn
>problem solving techniques, style, methodologies, etc. without actually
>solving problems, creating programs according to certain styles, using
>a programming language to apply a methodology?  Might as well try to teach
>a child the mathematical discipline of knot theory before teaching her how
>to tie her shoes!
>
>Phil B

Re: Should I learn C or Pascal?

[Laurent Guerby]

Robert> Well of course, Andy may be a brilliant exception, but most
Robert> people who learn "Ada in a couple of weeks" on their own with
Robert> a background like his tend to write just terrible Ada, having
Robert> completely misunderstood the critical use of abstraction, the
Robert> right way to use exceptions, the right way to use generics,

   I would say it depends of what what they were looking for in
learning Ada. If one (C/Fortran/Basic) programmer feels that his
language is not enough to build in a satisfactory way good code and is
looking for new SE principle in learning Ada, then there's a chance
that the misunderstanding won't be that sytematic. And remember that the
very good and *free* Ada material is available all over the
net. Example: the Ada Quality & Style is full of very interesting
discussions (pros & cons, more interesting than guidelines most of the
time) on good use of Ada features. (Aren't you a reviewer of this
document? ;-). URL:

   http://sw-eng.falls-church.va.us/AdaIC/standards/Welcome.html
   (or something near this URL)

Robert> and probably I would guess that they only know a small subset
Robert> of the language (typically not including the annexes for
Robert> example).

   The advantage of the annexes in Ada 95 is that you don't have to
learn them if you don't use them, that's not "subsetting". I guess the
right example and common case is learning Ada without tasking.

   (Knowing all Ada 95 annexes means that you know: 
Annex A: all the core standard libraries (IO, Strings, ...)
Annex B: all of C, Fortran, COBOL languages
Annex C: all of your machine  (interruptions, assembly)
Annex D: all of priority scheduling (RMS, Ceiling, ...)
Annex E: all of distributed systems programming
Annex F: all of COBOL pictures strings editing and decimal arithmetic
Annex G: all of numerics (accuracy, complex arithmetic)
Annex H: all of safety critical system concerns (implementation choices)
Annex J: all of Ada 83 obsolescent features
... definitly a large amount of knowledge and experience!)

Robert> Learning a language is more than learning where the semicolons
Robert> go!

   Right (since most languages come with a philosophy of programming,
especially Ada in the realm of SE).

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Should I learn C or Pascal?

[Stephen M O'Shaughnessy]

All this rhetoric is fine as far as it goes, BUT, for me it is not what you can write, but what you 
can read.  It does not matter how many languages you know.  It does not really matter what style you 
use.  In most cases it does not matter which language you apply to which problem.  Problem spaces 
change, evolve.  Sooner or later you or someone else will look at your code and want to change it.  
In most cases this occures before the product is even delivered.  Most institutions have procedures 
to review code.  From turning in assignments at school to walk-throughs and peer reviews in 
industry, someone is looking at your code.  This is the motivation behind Ada, the human aspect.  
And Ada wins, hands down.  If you want/need to learn a language, Ada has it all.  Object 
Orientation, all the constructs, availability, understandability, and most important for new 
programmers -- readability.

Re: Should I learn C or Pascal?

[Wayne]

Darin Johnson wrote:
> 
> > Also keep in mind that this rather lengthy diatribe was comparing c with the
> > 'standard' pascal, not what it has become.  Today's pascal is as
> > different from what was being discussed as today's c++ is from the old c.
> 
> True, Pascal has been mostly subsumed by Modula II and III.  These are
> nice languages, and you can do real-world and systems programming in
> them.  They're not as popular (you probably have to go commercial to
> get a compiler).
> --
> Darin Johnson
> djohnson@ucsd.edu       O-
>        Support your right to own gnus.

Isn't there an GNU Pascal compiler?  I think it also supports some Borland changes
to the ISO standard as well.


Wayne
-- 
Hit any user to continue.

Re: Should I learn C or Pascal?

[Darin Johnson]

> Add an extra minute or 2 for unexpected problems. :-) Besides, I never 
> claimed that you will become an expert in the language.  I said "a 
> working knowledge".

I learned C during a lecture.  The prof let us do programs in either
Pascal or C, so during the lecture I would occasionally ask my friend
for the equivalents of certain constructs.  Then after class I sat
down and wrote my assignment in C, then alternated each assignment
between C and Pascal after that.  The knowledge I was lacking was in
the details, stuff like printf specifications.  Certainly no abstract
programming details were missing (like what's a pointer, and how to do
recursion, etc, although it was odd losing out on the modularization I
was used to).

Ok, it wasn't 6 minutes, but I didn't have a book or summary sheet to
go on, only whispers.  When I actually got around to reading K&R, much
of it was old hat.
-- 
Darin Johnson
djohnson@ucsd.edu	O-
    "Particle Man, Particle Man, doing the things a particle can"

Re: Should I learn C or Pascal?

[Darin Johnson]

> Robert> Well of course, Andy may be a brilliant exception, but most
> Robert> people who learn "Ada in a couple of weeks" on their own with
> Robert> a background like his tend to write just terrible Ada, having
> Robert> completely misunderstood the critical use of abstraction, the
> Robert> right way to use exceptions, the right way to use generics,

This makes the assumption that the learner has never seen abstraction,
exceptions or generics before coming to Ada.  If the learner has seen
these before then Ada is just a matter of learning the syntax,
semantics and standard packages.  And even if not all of these have
been seen, having a decent brain gets over those hurdles (ie, a brain
that says "I don't understand generics fully, so I won't use them just
yet").
-- 
Darin Johnson
djohnson@ucsd.edu	O-
    Where am I?  In the village...  What do you want?  Information...

Re: Should I learn C or Pascal?

[Darin Johnson]

> A sizeable portion of the class,
> however, whined because they talked to "big, smart people in the real
> world" who told them they were wasting their time, no one uses Scheme,
> it's a stupid language, you can't do XYZ like you can in C or
> whatever, man, universities are stupid, this country is fucked up
> blablabla.

Unfortunately, this group exists regardless of what you teach or how.
I've TA'd and proctored a variety of classes (programming and
architecture), and you don't get away from them.  And it's not just
that they want the university to be a trade school either, I had
people in '81 (back when you had to know a variety of things and be
able to adapt in order to program) and they were complaining about why
they should learn Pascal since they already knew BASIC and didn't need
this intro to programming class.  They didn't do that well in the
class however.  Had a student complain about why he should learn how
compiler work since we already have a good C compiler.  And of course,
plenty were upset that they had to learn about the eniac or
computability or PDA's or what-not.

Of course, IMHO, I think the solution would be to take the military
route.  Don't reason with the students, make them do laps or pushups
instead.  Call them names and insult their mothers when they claim to
be smarter than you.  Get rid of all their preconceived notions in
boot camp so they can actually learn something later on.  (what, do
students actually say "only wussies use Pascal in the real world" at
West Point?).

The old saying goes, "he can write Fortran in any language".  Which is
just a way of saying that you can present a programmer with any
language you want, but if they can't program well you won't get a good
program at the end.
-- 
Darin Johnson
djohnson@ucsd.edu	O-
    Gravity is a harsh mistress - The Tick

Re: Should I learn C or Pascal?

[Michael Feldman]

In article <qq3f2i61zo.fsf@tartarus.ucsd.edu>,

>(what, do
>students actually say "only wussies use Pascal in the real world" at
>West Point?).

Actually, starting this year, they'll probably say "only wussies 
use Ada....":-)

West Point is switching its intro courses to Ada in Sept.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) 
http://www.seas.gwu.edu/faculty/mfeldman
------------------------------------------------------------------------
       Pork is all that money the government gives the other guys.
------------------------------------------------------------------------
WWW: http://lglwww.epfl.ch/Ada/ or http://info.acm.org/sigada/education
------------------------------------------------------------------------

Re: Should I learn C or Pascal?

[Andrew J Steinbach]

Darin Johnson (djohnson@tartarus.ucsd.edu) wrote:
: > A sizeable portion of the class,
: > however, whined because they talked to "big, smart people in the real
: > world" who told them they were wasting their time, no one uses Scheme,
: > it's a stupid language, you can't do XYZ like you can in C or
: > whatever, man, universities are stupid, this country is fucked up
: > blablabla.

: Unfortunately, this group exists regardless of what you teach or how.
: I've TA'd and proctored a variety of classes (programming and
: architecture), and you don't get away from them.  And it's not just
: that they want the university to be a trade school either, I had
: people in '81 (back when you had to know a variety of things and be
: able to adapt in order to program) and they were complaining about why
: they should learn Pascal since they already knew BASIC and didn't need
: this intro to programming class.  They didn't do that well in the
: class however.  Had a student complain about why he should learn how
: compiler work since we already have a good C compiler.  And of course,
: plenty were upset that they had to learn about the eniac or
: computability or PDA's or what-not.

: Of course, IMHO, I think the solution would be to take the military
: route.  Don't reason with the students, make them do laps or pushups
: instead.  Call them names and insult their mothers when they claim to
: be smarter than you.  Get rid of all their preconceived notions in
: boot camp so they can actually learn something later on.  (what, do
: students actually say "only wussies use Pascal in the real world" at
: West Point?).

	Absolutely.  "We know what's good for you.  Your ideas are 
invalid and stupid.  Now swallow everything we feed you, because it is 
the WORD."  Free thought, opinions, what a concept.  Ugh.  Have you 
considered that these people may actually have *valid* complaints with 
Scheme?

: The old saying goes, "he can write Fortran in any language".  Which is
: just a way of saying that you can present a programmer with any
: language you want, but if they can't program well you won't get a good
: program at the end.

	This is true, but the choice of language does make a difference in
the final result, too.  I do have a problem with using Scheme as a
learning tool in intro courses.  Why is it wrong to teach students basic
algorithms and data structures using a language which they probably 
already know?  Most intro CSci students aren't programming virgins (well, 
at least the ones I know).

--
Andy Steinbach
stei0113@maroon.tc.umn.edu

Re: Should I learn C or Pascal?

[John A Hughes]

In article <4t49om$ebi@epx.cis.umn.edu>,
Andrew J Steinbach <stei0113@maroon.tc.umn.edu> wrote:
>Darin Johnson (djohnson@tartarus.ucsd.edu) wrote:
>: Of course, IMHO, I think the solution would be to take the military
>: route.  Don't reason with the students, make them do laps or pushups
>: instead.  Call them names and insult their mothers when they claim to
>: be smarter than you.  Get rid of all their preconceived notions in
>: boot camp so they can actually learn something later on.  (what, do
>: students actually say "only wussies use Pascal in the real world" at
>: West Point?).
>
>	Absolutely.  "We know what's good for you.  Your ideas are 
>invalid and stupid.  Now swallow everything we feed you, because it is 
>the WORD."  Free thought, opinions, what a concept.  Ugh.  Have you 
>considered that these people may actually have *valid* complaints with 
>Scheme?

I have yet to encounter anything in my life that someone could not have valid
complaints about. One can argue which style of teaching and which tools are
the best for that style, and I would find that a pretty interesting argument,
but I do believe the classes I was TAing were tailored towards a certain
set of goals and that the choice of Scheme was not unreasonable for those
goals. The most troubling thing is that people feel there are expendable
concepts that you can ignore if you use the right language, that all this
discussion about correct programming, giving an eye to maintainability and
extensibility, and using the features of various languages properly is
all airy-fairy and gets in the way of doing "real work". There are brilliant
people who can do anything with any tool and any methodology, but normal
people need to be taught specific methodologies with specific tools. And
as far as I can tell there was nothing we taught in our class that was
not worth learning, and the people who complained about the language are
morons who I hope no one ever hires, especially not in any company where
I might have to deal with them and their code.

>	This is true, but the choice of language does make a difference in
>the final result, too.  I do have a problem with using Scheme as a
>learning tool in intro courses.  Why is it wrong to teach students basic
>algorithms and data structures using a language which they probably 
>already know?  Most intro CSci students aren't programming virgins (well, 
>at least the ones I know).

I think you have to pick a language for intro classes. And I don't think
picking one they're already familiar with, and presumably already have
bad habits in, is a priori any better than choosing one they've never 
seen before intending them to actually pay attention to someone else's
experience in that language and in programming in general.

I'll say it again; if you think a particular language only teaches you things 
not worth learning, you have a pretty impoverished idea of what useful 
knowledge is.


jah

Re: Should I learn C or Pascal?

[Jon Bell]

[followups set to comp.edu, which is where this discussion really belongs]

 Andrew J Steinbach <stei0113@maroon.tc.umn.edu> wrote:
> Why is it wrong to teach students basic
>algorithms and data structures using a language which they probably 
>already know?  Most intro CSci students aren't programming virgins (well, 
>at least the ones I know).

Believe it or not, many prospective CS majors do *not* have significant 
programming experience when they arrive at college/university.  This 
varies from school to school, of course.  Here, it is unusual for a 
student in my CS1/CS2 courses to have *any* real programming experience.
Our situation isn't really relevant because we don't offer a CS major 
(just a minor); nevertheless, I have seen comments from people at larger 
schools with CS degree programs that a significant number of their 
prospective majors are programming "virgins" or almost so.

Also, the ones that *do* have programming experience haven't all been using 
the same language.  One reason for using a "different" programming 
language like Scheme is that it tends to "level the playing field" for 
students in the course.

Many factors go into the choice of an introductory programming language.  
Different schools weigh those factors differently.  In our case, since we 
offer only a minor, we don't have *time* to start with one language, then 
switch to another; so we use C++ for CS1/CS2.  Actually, we also have a 
"CS0" course which is mostly descriptive, but has a bit of programming in 
the HyperTalk scripting language, and practically all our CS minors take 
that first.

-- 
Jon Bell <jtbell@presby.edu>                        Presbyterian College
Dept. of Physics and Computer Science        Clinton, South Carolina USA

Re: Should I learn C or Pascal?

[system]

 stei0113@maroon.tc.umn.edu (Andrew J Steinbach) writes:
>Darin Johnson (djohnson@tartarus.ucsd.edu) wrote:
>: > A sizeable portion of the class,
>: > however, whined because they talked to "big, smart people in the real
>: > world" who told them they were wasting their time, no one uses Scheme,
>: > it's a stupid language, you can't do XYZ like you can in C or
>: > whatever, man, universities are stupid, this country is fucked up
>: > blablabla.
>
>: Unfortunately, this group exists regardless of what you teach or how.
>: I've TA'd and proctored a variety of classes (programming and
>: architecture), and you don't get away from them.  And it's not just

[clip]

>: Of course, IMHO, I think the solution would be to take the military
>: route.  Don't reason with the students, make them do laps or pushups
>: instead.  Call them names and insult their mothers when they claim to
>: be smarter than you.  Get rid of all their preconceived notions in
>: boot camp so they can actually learn something later on.  (what, do
>: students actually say "only wussies use Pascal in the real world" at
>: West Point?).

I personally assumed that this was at least partly tongue-in-cheek.

I have been a T.A. as well (for physics) and fully sympathize with
the above posters' feelings about the whiners.  Most who have valid
complaints (e.g. "The only reason I am being forced to take physics is to
weed out students applying for my program") Don't whine about it,
they state it and go to work.

>	Absolutely.  "We know what's good for you.  Your ideas are 
>invalid and stupid.  Now swallow everything we feed you, because it is 
>the WORD."  Free thought, opinions, what a concept.  

Have you considered that maybe, just maybe, the teachers know something 
the students don't?  That the students should work on learning what is
being taught?  The students expressed their feelings and the Profs and 
TAs argued (ARGUED not DECLARED) that the coursework was valid and usefull.

>Ugh.  Have you 
>considered that these people may actually have *valid* complaints with 
>Scheme?

After reading the original post? no.

>: The old saying goes, "he can write Fortran in any language".  Which is
>: just a way of saying that you can present a programmer with any
>: language you want, but if they can't program well you won't get a good
>: program at the end.
>
>	This is true, but the choice of language does make a difference in
>the final result, too.  I do have a problem with using Scheme as a
>learning tool in intro courses.  Why is it wrong to teach students basic
>algorithms and data structures using a language which they probably 
>already know?  

like Basic?

More to the point, it is wrong because with a new language it is easier
to break their bad habits.  Once they learn the new habits taught by
the class they can (in the long run) compare and decide which is better.

>Most intro CSci students aren't programming virgins (well, 
>at least the ones I know).

I took assembler here at NIU, many of the students in the class had had
one prior programming course, COBOL.  Blech, the prof and T.A.s had to
teach them programming as well as assembler.

Robert Morphis

>Andy Steinbach
>stei0113@maroon.tc.umn.edu

Re: Should I learn C or Pascal?

[Ralph Silverman]

Darin Johnson (djohnson@tartarus.ucsd.edu) wrote:
: > A sizeable portion of the class,
: > however, whined because they talked to "big, smart people in the real
: > world" who told them they were wasting their time, no one uses Scheme,
: > it's a stupid language, you can't do XYZ like you can in C or
: > whatever, man, universities are stupid, this country is fucked up
: > blablabla.

: Unfortunately, this group exists regardless of what you teach or how.
: I've TA'd and proctored a variety of classes (programming and
: architecture), and you don't get away from them.  And it's not just
: that they want the university to be a trade school either, I had
: people in '81 (back when you had to know a variety of things and be
: able to adapt in order to program) and they were complaining about why
: they should learn Pascal since they already knew BASIC and didn't need
: this intro to programming class.  They didn't do that well in the
: class however.  Had a student complain about why he should learn how
: compiler work since we already have a good C compiler.  And of course,
: plenty were upset that they had to learn about the eniac or
: computability or PDA's or what-not.

: Of course, IMHO, I think the solution would be to take the military
: route.  Don't reason with the students, make them do laps or pushups
: instead.  Call them names and insult their mothers when they claim to
: be smarter than you.  Get rid of all their preconceived notions in
: boot camp so they can actually learn something later on.  (what, do
: students actually say "only wussies use Pascal in the real world" at
: West Point?).

: The old saying goes, "he can write Fortran in any language".  Which is
: just a way of saying that you can present a programmer with any
: language you want, but if they can't program well you won't get a good
: program at the end.
: -- 
: Darin Johnson
: djohnson@ucsd.edu	O-
:     Gravity is a harsh mistress - The Tick

--
*************begin r.s. response*****************

	(re.  '...military style...'
		in posting cited above)

	who will watch the watchers?

	...
	a teacher who can not hold the interest
	of the students in this area without
	resort to draconian measures may be
		the problem!!!


	(re.  '...Don't reason with the students...'
		in the posting cited above)

	this is a pretty pass!!!
	if we can not reason about
		computer programming!!!

*************end r.s. response*******************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[TRAN PHAN ANH]

Allow me to round off this thread.

You don't need to start with lots of parentheses, or Pascal to learn 
problem solving.  And you don't screw up your learning ability if you 
start off with C or machine code.  Heck, I wonder if turning switches 
made Knuth a worse Computer Scientist than what he is?  :-))

Anyway, reality check, 2 students looking for an internship or a 
part-time job, which requires programming.  All things being equal, one 
with a working knowledge of C/C++, and one with a working knowledge of 
parantheses, who gets the job (most of the times)?  By the time they
graduate, both will have covered the same material.  But one will have 
EXPERIENCE to put on the resume.

If one has the desire, and an open mind...anything can be learned.  On 
the other hand, if one thinks that what one knows is enough, be it lisp, 
basic, scheme, C, or anything, one will never learn new things.  That's 
given by definition.

Anh


In article <4t5ebb$hp3@nntp.seflin.lib.fl.us>, z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman) writes:
> Darin Johnson (djohnson@tartarus.ucsd.edu) wrote:
> : > A sizeable portion of the class,
> : > however, whined because they talked to "big, smart people in the real
> : > world" who told them they were wasting their time, no one uses Scheme,
> : > it's a stupid language, you can't do XYZ like you can in C or
> : > whatever, man, universities are stupid, this country is fucked up
> : > blablabla.
> 
> : Unfortunately, this group exists regardless of what you teach or how.
> : I've TA'd and proctored a variety of classes (programming and
> : architecture), and you don't get away from them.  And it's not just
> : that they want the university to be a trade school either, I had
> : people in '81 (back when you had to know a variety of things and be
> : able to adapt in order to program) and they were complaining about why
> : they should learn Pascal since they already knew BASIC and didn't need
> : this intro to programming class.  They didn't do that well in the
> : class however.  Had a student complain about why he should learn how
> : compiler work since we already have a good C compiler.  And of course,
> : plenty were upset that they had to learn about the eniac or
> : computability or PDA's or what-not.
> 
> : Of course, IMHO, I think the solution would be to take the military
> : route.  Don't reason with the students, make them do laps or pushups
> : instead.  Call them names and insult their mothers when they claim to
> : be smarter than you.  Get rid of all their preconceived notions in
> : boot camp so they can actually learn something later on.  (what, do
> : students actually say "only wussies use Pascal in the real world" at
> : West Point?).
> 
> : The old saying goes, "he can write Fortran in any language".  Which is
> : just a way of saying that you can present a programmer with any
> : language you want, but if they can't program well you won't get a good
> : program at the end.
> : -- 
> : Darin Johnson
> : djohnson@ucsd.edu	O-
> :     Gravity is a harsh mistress - The Tick
> 
> --
> *************begin r.s. response*****************
> 
> 	(re.  '...military style...'
> 		in posting cited above)
> 
> 	who will watch the watchers?
> 
> 	...
> 	a teacher who can not hold the interest
> 	of the students in this area without
> 	resort to draconian measures may be
> 		the problem!!!
> 
> 
> 	(re.  '...Don't reason with the students...'
> 		in the posting cited above)
> 
> 	this is a pretty pass!!!
> 	if we can not reason about
> 		computer programming!!!
> 
> *************end r.s. response*******************
> Ralph Silverman
> z007400b@bcfreenet.seflin.lib.fl.us
> 

Re: Should I learn C or Pascal?

[Darin Johnson]

gwinn@res.ray.com (Joe Gwinn) writes:
> Shouldn't we answer the man's question, without drifting into theological
> discussions about the relative merits of various languages?  He wants to
> find a better job, not find religion, or become a better person.  So,
> where are the jobs?  

And speaking of theology - give a man a fish and you feed him for a
day, teach a man to fish and you feed him for life.

That's why the thread has drifted.  The original poster wanted to know
where to get a fish.  If he learns the language that gets him a job
now, what happens next year?  The language will change - and more
often the way the language is used will change.  When you know how to
program, the choice of language is just a matter of syntax and
idiosyncracies.  If all you know is one language/methodology, then
everything else is viewed as "a silly way of doing things".  If you
learn abstraction, you can use it in any language.  If you learn C and
have never seen abstraction, you're not going to use abstraction until
years of experience cause you to use it.  These aren't things you
learn on the job unless you work with people that also know these
things and they make an effort to teach you (and this is becoming less
and less likely).

I have to maintain code written by someone who just learned C after
decades of assembler.  He thinks it's the greatest language in the
world, and is always wondering why I am spending the time improving
code (because it saves me time in the long run).  There's absolutely
no sense of abstraction in the code, no comments (except to tell the
name of the file), little portability (he thinks separate source trees
are fine), and whatever gets the job done is what gets done.  That's
what happens when you just learn the language but not the programming.

Same thing everywhere.  They teach English to English speakers in
school.  They teach music theory to people who can already play.
Are computers supposed to be the exception?
-- 
Darin Johnson
djohnson@ucsd.edu	O-
       The opinions expressed are not necessarily those of the
       Frobozz Magic Hacking Company, or any other Frobozz affiliates.

Re: Should I learn C or Pascal?

[Andy Askey]

djohnson@tartarus.ucsd.edu (Darin Johnson) wrote:

>gwinn@res.ray.com (Joe Gwinn) writes:
>> Shouldn't we answer the man's question, without drifting into theological
>> discussions about the relative merits of various languages?  He wants to
>> find a better job, not find religion, or become a better person.  So,
>> where are the jobs?  

>And speaking of theology - give a man a fish and you feed him for a
>day, teach a man to fish and you feed him for life.
snip
>Darin Johnson
>djohnson@ucsd.edu	O-
>       The opinions expressed are not necessarily those of the
>       Frobozz Magic Hacking Company, or any other Frobozz affiliates.



See, I knew programming was like Buddism.

--
May your karma be excellent for forgiving my spelling mishaps.

Andy Askey
ajaskey@gnn.com

Re: Should I learn C or Pascal?

[Mark Eissler]

gwinn@res.ray.com (Joe Gwinn) writes:

>> Shouldn't we answer the man's question, without drifting into theological
>> discussions about the relative merits of various languages?  He wants to
>> find a better job, not find religion, or become a better person.  So,
>> where are the jobs?  
 
The jobs? What jobs? I don't about your town, but around here most places
require a degree these days. That being the case, a teaching institution
and its curriculum will figure this out. Going it alone would (I suppose)
require some type of portfolio (someone correct me on this?) that could be
shown to prospective employers as proof you have a clue.

That said, C and C++ programmers are probably more in demand than anything
else, although there's also JAVA, COBOL, and Ada... See, there's still
demand for programmers that can maintain older systems (institutions don't
tend to sack their mainframes and legacy apps every couple of years).

All in all, I think a lot of people will agree that it is better to evolve
as a programmer rather than just learn ONE language and say "Here I am,
give me $80k/yr plus moving expenses!"

Or something like that.

For instance: get a book on Pascal, get a compiler, breeze through the
book, write a few utilities (apps, whatever) and then move on to the next
language.

As you learn a new language, with its own convoluted concepts, it will be
somewhat comforting to have another language to relate to.

--
Mark Eissler                      |  If something doesn't start
tequila@interlog.com              |  happening soon, I'm gonna    http://www.interlog.com/~tequila/ |  take up Yak farming!

Re: Should I learn C or Pascal?

[Patrick Horgan]

In article <qqspaho8h3.fsf@tartarus.ucsd.edu>, djohnson@tartarus.ucsd.edu (Darin Johnson) writes:

> That's why the thread has drifted.  The original poster wanted to know
> where to get a fish.  If he learns the language that gets him a job
> now, what happens next year?  The language will change - and more
> often the way the language is used will change.  When you know how to
> program, the choice of language is just a matter of syntax and
> idiosyncracies.  If all you know is one language/methodology, then
> everything else is viewed as "a silly way of doing things".  If you
> learn abstraction, you can use it in any language.  If you learn C and
> have never seen abstraction, you're not going to use abstraction until
> years of experience cause you to use it.  These aren't things you
> learn on the job unless you work with people that also know these
> things and they make an effort to teach you (and this is becoming less
> and less likely).

You're making a few unspoken assumptions here.  First that the
previous thread had anything to do with learning abstractions, (and I'll
expand that to mean "all the good things that make the difference 
between someone that I would respect as an elegant developer"), second 
that everyone can and will learn these things if exposed to them, and most
chilling, that no one will make an effort to continue their education on
their own unless someone else takes the bull by the horns and leads them.
Nevertheless what you've said is valid and good and I agree with it.  To
show that I do, let me say what you've said only in my usual blathering 
way with large amounts of voluminous text;)

Most of the previous discussion has been along the lines of, "well, learn it
in this order and somehow that will teach you the higher level abstractions
you need to know.  I think that's silly.  Programming languages might lead
you along the path a bit, (yes even assembler even though you ~seem~ to
feel that all assembler programmers are archaic spaghetti code hacks;),
but courses in data structures, algorithms, object oriented programming,
and other abstractions do a better job.  The better intro programming
courses cover a bit of all of this along with some language, and the
people might come out of the course assuming that learning the language
taught them these things, but it's not true.  

I can write spaghetti, structured, procedural, object-oriented, or anything
you desire in ada, scheme, assembler, C++, pascal, boern shell, or logo.
Languages don't teach you programming, they're just the medium in which
you do it.  I can learn them in any order I want, and as long as all I'm
learning is the language constructs I'll still suck;)

Nevertheless it's obvious that these things can be learned (by some;).  Often
times the genesis is a set of rules to follow.  I remember when structured 
programming was all the rage.  Its intent was to do away with spaghetti
code in assembler and fortran and basic, and lead programmers to a better,
in that it was more understandable and more maintainable, way of programming.
Most people's exposure to this was as a set of rules such as:

o modularise
o a module should have no more than N lines/should fit on M screens
o a module should have only one entrance and exit (well, in a non-procedural
  language you had to tell people these things!)
o frequently reused code segments should be abstracted into their own module

etc...some people blindly adhered to these rules in a completely anal way that
demonstrated that they didn't get it...they thought that following the rules
was the thing, but the original intent was to show better tools to get things
done.  Like in all other things, the better people got the idea, the abstraction
behind the rules, and applied it without having to think about the rules, or
worry about if it was ever appropriate to do something outside the rules.

Later more and more design methodologies came along.  Some people blindly adhered
to them, some people took the good ideas behind them that they where trying to
express and added them to their repertoire.  (Many projects that insisted on
blindly following a particular design methodology failed, see the literature
for many many details;)

It became clearer and clearer that people fell into a few categories, there were
those that just liked it, and learned more and more on their own all the time,
and considered it a moving, changing, growing body of knowledge.  There were
those that wanted to know "what worked", studied it, decided they knew and
wrote up whatever particular abstractions and methodologies they'd come up
with as if it was on tablets from heaven (although I know with the best
intentions).  There were those who just believed what they were told and
blindly followed it.

There were more of the latter category.

I believe the first guys that want to learn and grow and add more and more tools
and concepts and paradigms to their toolkits all the time are the best.  They
are flexible.  They use what works.  They understand why it works.  They know
where the ideas for structured programming came from, they know where the ideas
for object oriented programming came from.  They've internalised these things
to the point that they are common sense, and they're still spending more time
learning about their field (and usually lots of other things in life) than
most people spent in college.  They like to think.  They like elegant abstractions.

We should be teaching free thinking and flexibility in college.  Instead, since
MANY college professors and their TAs fall into the second category (excluding
well known examples like Pohl and Knuth and others that are the good guys,)
we get rules to follow.  We get punishment for free thinking and flexibility.

It's sad, but not actually that bad, because only a small percentage of the
folks in college have the ability to be in the first group.  I don't know
what it is that separates the top guys from the rest...it's not intelligence.
I've known a lot of really bright but rigid folks in the field.

The folks that belong in the top group will most likely get there in spite of
any obstacles placed in front of them by the educational system.

So, if the question is what language should you learn to get a job, I'll still
say C++.  Most work these days in Unix or Windows is done in C++, and that's
most of the work.  Is it enought to just learn a language?  No.  Will learning
several languages in some particular order teach you what you need?  No.  Learn
everything, learn constantly, seek to always grow.  Learn what you need for
school, learn what you need for work, but don't stop there.  Learn the basic
underpinnings of algorithms and data structures...if it's hard for you read
it again.  If it's still hard get a different book and read it.  Learn until
it's common sense to you and then go on to something else.  Learn always.

If you show up on a job interview I should be able to say, "write me a quick
binary sort algorithm" and you have no problem doing it because you know how
it works...you don't have to memorise it, you create if from well understood
basic principles as needed.

Then you'll end up being the developer that's sought out.  You'll make more
money!  And if you're lucky, you'll end up in a startup that hired a lot of
people like you and your peers will push you to new heights, and appreciate
what makes you different from the vast bulk of your peers:)  (Can you tell
I'm happy where I work?:)  If you find yourself in a place that's stifling,
a place where you're a big fish in a pool of minnows, move on.

And always, always, always keep learning, be one of the people that learns 
new stuff first.  Be a leader.  But always learn in depth.  It doesn't really
get added to your repertoire until it becomes common sense.

-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

Re: Should I learn C or Pascal?

[Gary M. Greenberg]

Eloquently, patrick@broadvision.com wrote:

>  you have no problem doing it because you know how it works...
>  you don't have to memorise it, you create if from well understood
>  basic principles as needed.
> [ ... ] 
>  If you find yourself in a place that's stifling,
>  a place where you're a big fish in a pool of minnows, move on.
>  
>  And always, always, always keep learning, be one of the people
>  that learns new stuff first.  Be a leader.  But always learn in
>  depth.  It doesn't really get added to your repertoire until it
>  becomes common sense.
>  

    The quintessential statement of success! Bravo!

>     Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.

gary    /* the Sorcerer's Apprentice */

Re: Should I learn C or Pascal?

[Ralph Silverman]

StHeller (stheller@aol.com) wrote:
: In article <4ttmpi$l3k@ns.broadvision.com>, patrick@broadvision.com
: (Patrick Horgan) writes:

: >If you show up on a job interview I should be able to say, "write me a
: quick
: >binary sort algorithm" and you have no problem doing it because you know
: how
: >it works...you don't have to memorise it, you create if from well
: understood
: >basic principles as needed.
:   I assume you mean a "binary search". If you want a fast sort that's easy
: to program, then distribution counting fills the bill quite nicely; I've
: used it as
: a programming test with great success.

: Steve Heller
: http://ourworld.compuserve.com/homepages/steve_heller/

--
***********begin r.s. response***************

	re.
	"...binary sort algorithm..."

	i remember such from the
		military programming of the 1980's
	...

	has this reached the textbooks now?

	also,
	seems pretty hard for a
		technical interview question
	!!!

***********end r.s. response*****************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[Patrick Horgan]

In article <4u7hi6$s2b@nntp.seflin.lib.fl.us>, z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman) writes:
> 
> 	re.
> 	"...binary sort algorithm..."
> 
> 	i remember such from the
> 		military programming of the 1980's
> 	...
> 
> 	has this reached the textbooks now?
> 
> 	also,
> 	seems pretty hard for a
> 		technical interview question

A binary sort, also known as quicksort, or Hoare's sort is covered extensively
in Knuth's volume three (from 1971) and in every undergraduate data structure
and algorithm course in the world;)...you would expect anyone with a CS degree
to be familiar with it.




-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

Re: Should I learn C or Pascal?

[Darin Johnson]

> A binary sort, also known as quicksort, or Hoare's sort is covered extensively
> in Knuth's volume three (from 1971) and in every undergraduate data structure
> and algorithm course in the world;)...you would expect anyone with a CS degree
> to be familiar with it.

Actually, I learned it freshman year, but didn't understand it.
Entire new concepts of programming were still trying to find niches in
my head, leaving no room for understanding what was going on with
quicksort.  Most later classes assumed I already knew it.  I did get
clued into it later on, but I think many of my classmates kept the
"quicksort is the fastest sort" categorization without really
understanding it.  Too many people fall asleep in algorithms class
(then bitch about the waste of time later).
-- 
Darin Johnson
djohnson@ucsd.edu	O-
  - I'm not a well adjusted person, but I play one on the net.

Re: Should I learn C or Pascal?

[Richard A. O'Keefe]

djohnson@tartarus.ucsd.edu (Darin Johnson) writes:
>Actually, I learned it freshman year, but didn't understand it.
...
>I think many of my classmates kept the
>"quicksort is the fastest sort" categorization without really
>understanding it.  Too many people fall asleep in algorithms class
>(then bitch about the waste of time later).

The *really* sad thing here is that quicksort is *not* the fastest sort.
Quicksort was specifically designed (see Hoare's paper in Computer
Journal, 1960 or 61, can't remember the issue) for a machine with 256
words of memory.  Not 256M.  Not 256k.  Two hundred and fifty-six words
of main memory.  Backing store was a drum with 16384 words, transferred
in 64 word pages.  Hoare knew at the time that it did more comparisons
than merge sort, but merge sort need extra memory that simply wasn't there.

Quicksort still has a niche in embedded processors,
although there is a new version of heapsort (also published in the
Computer Journal, but I can't find the reference) which can challenge it:
the modern heapsort has the virtue that its worst case is O(nlgn) which
makes it a better bet for soft-real-time work.

For general use, a well engineered merge sort is as good as a well engineered
quicksort; sometimes better.

For sorting machine integers, a well engineered radix sort (or even count
sort if the range is small enough) is so much faster that it isn't funny.

For most programmers, the main issue is that it is cheaper to re-use
an existing expertly implemented and thoroughly tested sort procedure
than to write their own buggy code.
-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Should I learn C or Pascal?

[Lawrence Kirby]

In article <4uu9v3$hrp@goanna.cs.rmit.edu.au>
           ok@goanna.cs.rmit.edu.au "Richard A. O'Keefe" writes:

>Quicksort still has a niche in embedded processors,
>although there is a new version of heapsort (also published in the
>Computer Journal, but I can't find the reference) which can challenge it:

My experience of heapsort is that while it can beat quicksort in number
of comparisons it requires more data movement and has more algorithmic
overhead which makes it slower.

>the modern heapsort has the virtue that its worst case is O(nlgn) which
>makes it a better bet for soft-real-time work.

Heapsort has always been O(n log n). You're right that a guaranteed
reasonable worst case is sometimes useful.

>For general use, a well engineered merge sort is as good as a well engineered
>quicksort; sometimes better.

It is close but very rare indeed for a heapsort to run faster than
a quicksort.

>For sorting machine integers, a well engineered radix sort (or even count
>sort if the range is small enough) is so much faster that it isn't funny.
>
>For most programmers, the main issue is that it is cheaper to re-use
>an existing expertly implemented and thoroughly tested sort procedure
>than to write their own buggy code.

As far as the C language is concerned merge sort and radix sort aren't good
choices for qsort().

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Should I learn C or Pascal?

[Ken Pizzini]

In article <840279292snz@genesis.demon.co.uk>,
Lawrence Kirby  <fred@genesis.demon.co.uk> wrote:
>As far as the C language is concerned merge sort and radix sort aren't good
>choices for qsort().

The function prototype for qsort() indeed makes radix sort a poor
choice.  I also see that a "traditional" merge sort's memory
requirements make that a questionable implementation, but there are
in-place merge sort algorithms with reasonable performance; I don't
recall off hand if any actually can compete with quicksort for the
average case (quicksort has a mean inner loop), but I recall that
some of the variants are quite respectable in their worst case
behavior.

My memory is a little fuzzy on this because I tend to use the
implementation offered by the system; it is rarely worth my
time to try and get an application-specific improvement in
my sorts.

		--Ken Pizzini

Re: Should I learn C or Pascal?

[Richard A. O'Keefe]

I wrote:
>>the modern heapsort has the virtue that its worst case is O(nlgn) which
>>makes it a better bet for soft-real-time work.

Lawrence Kirby <fred@genesis.demon.co.uk> writes:

>Heapsort has always been O(n log n). You're right that a guaranteed
>reasonable worst case is sometimes useful.

Mea culpa.  What I meant, of course, was that it has now been known for
several years (from my known knowedge) [since 1968 at least, according
to Robert Dewar] how to do heapsort with 1.0 N.lg N + cruft element
comparisons.

>>For general use, a well engineered merge sort is as good as a well engineered
>>quicksort; sometimes better.

>It is close but very rare indeed for a heapsort to run faster than
>a quicksort.

Perhaps, but I wrote "a well engineered MERGE sort" at this point, and
that's what I meant.  It is quite common for a well engineered merge sort
to beat quick sort; I've beaten UNIX qsort by 20% on occasion. (It is
*much* harder to beat the Bentley & someone "engineered" quick sort in
Software Practice & Experience a year or two ago, but it isn't at all hard
to *match* it).

>As far as the C language is concerned merge sort and radix sort aren't good
>choices for qsort().

That was not proposed by anyone.
It is so ruddy obvious that a sorting interface which accepts an
arbitrary comparison function cannot use radix sort that surely Kirby
didn't need to mention it.

As for whether merge sort is a good choice for qsort():  if you have the
spare memory (which in most cases on workstations and mainframes you _have_)
and if you care about performance (which again one usually does) merge sort
makes an *excellent* implementation of qsort(), if you are as good a
hacker as whoever would have written the quicksort.  UNIX on a PDP-11 *had*
to make use of a less efficient sort than merge sort because in 64k you
didn't have the memory to spare for anything.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Should I learn C or Pascal?

[Joe Keane]

In article <4v99re$g3s@goanna.cs.rmit.edu.au>
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> writes:
>As for whether merge sort is a good choice for qsort():  if you have the
>spare memory (which in most cases on workstations and mainframes you _have_)
>and if you care about performance (which again one usually does) merge sort
>makes an *excellent* implementation of qsort(), if you are as good a
>hacker as whoever would have written the quicksort.  UNIX on a PDP-11 *had*
>to make use of a less efficient sort than merge sort because in 64k you
>didn't have the memory to spare for anything.

These days, with virtual memory, asking for a bit of extra space is
probably a good idea if it gives you a faster algorithm.  I'd say that
once you have the `qsort' interface, calling a function for comparison,
quicksort has lost its biggest advantage, the tight inner loops.

Indeed the GNU `qsort' is actually a merge sort, pretty much textbook,
and it beats any quick sort i've seen.  The FreeBSD `mergesort' function
is considerably more funky, but it seems to work very well.

More specifically, what the GNU `qsort' function does is this: if the
extra space needed is small, allocate it off the stack, otherwise call
malloc, and if that fails, fall back on a quicksort.  It's attention to
detail like this that distinguishes robust library functions from some
code that someone was playing around with.

--
Joe Keane, amateur mathematician

Re: Should I learn C or Pascal?

[Mike Rubenstein]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) wrote:

> djohnson@tartarus.ucsd.edu (Darin Johnson) writes:
> >Actually, I learned it freshman year, but didn't understand it.
> ...
> >I think many of my classmates kept the
> >"quicksort is the fastest sort" categorization without really
> >understanding it.  Too many people fall asleep in algorithms class
> >(then bitch about the waste of time later).
> 
> The *really* sad thing here is that quicksort is *not* the fastest sort.
> Quicksort was specifically designed (see Hoare's paper in Computer
> Journal, 1960 or 61, can't remember the issue) for a machine with 256
> words of memory.  Not 256M.  Not 256k.  Two hundred and fifty-six words
> of main memory.  Backing store was a drum with 16384 words, transferred
> in 64 word pages.  Hoare knew at the time that it did more comparisons
> than merge sort, but merge sort need extra memory that simply wasn't there.

Where did you get this idea?  Certainly not from the Hoare's paper.
In the paper he reports testing on such a machine, but he does not say
that quicksort was designed for such a machine.  In fact, he concludes
that

	Quicksort is a sorting method ideally adapted for sorting in 
	the random access store of a computer.  ...  Quicksort is 
	likely to recommend itself as the standard sorting method on
	most computers with a large enough random access store to make

	internal sorting worthwhile.

He includes the case where the random access store is disk or drum.
Not unreasonable on the computers of the early 60s, but not realistic
today.  In general, today quicksort is not suitable unless the data to
be sorted can pretty much be held in real memory.

> 
> Quicksort still has a niche in embedded processors,
> although there is a new version of heapsort (also published in the
> Computer Journal, but I can't find the reference) which can challenge it:
> the modern heapsort has the virtue that its worst case is O(nlgn) which
> makes it a better bet for soft-real-time work.

It's not that new -- Knuth discusses heapsort with guaranteed O(N log
N) performancein his 1973 book.  I was unaware that there was ever a
version that does not guarantee O(N log N) behavior.  But it's very
hard to get the constant as low as that for quicksort and quite easy
to make O(N log N) behavior almost certain in quicksort.  Sometimes
heapsort is better for soft real time work, but not always.

In fact, if the maximum number of items to be sorted is fixed in
advance, insertion sort is often very good if the number is very small
and Shell sort for several hundred items.

> 
> For general use, a well engineered merge sort is as good as a well engineered
> quicksort; sometimes better.
> 
> For sorting machine integers, a well engineered radix sort (or even count
> sort if the range is small enough) is so much faster that it isn't funny.

Of course, but how often do you sort machine integers?  In 35 years of
programming, I can count on my fingers how often that problem came up
and in most of those cases the amount of data was so small that it
would be hard to choose a sort that isn't adequate.

> 
> For most programmers, the main issue is that it is cheaper to re-use
> an existing expertly implemented and thoroughly tested sort procedure
> than to write their own buggy code.

Sometimes.  It pays to think.  A number of years ago I did a billing
program for a large retailer.  Transactions were stored in the order
in which they were received and had to be sorted in order of
transaction date.  For the most part, the data was already sorted
correctly.  The main exception was that billing transactions for items
shipped were batched and processed overnight.  In some cases they were
not processed for a day or two.  If a person placed an order the day
after an item was shipped, the data could be out of order.

Aside from the fact that the data was almost in order, the number of
items to be sorted was quite small (for a variety of reasons it was
not desirable to presort all the transactions, so the transactions for
each customer were sorted separately).  That alone made any sort
package undesirable.

Here C and C++ are much better than most languages I know.  qsort() is
generally decent for small sorts (though I'd not use it in the case I
jsut mentioned).  I've not done much work in them recently, but when I
programmed in PL/I and COBOL their sort routines were completely
unsuitable if one was doing a large number of small sorts (unlike C's,
they were extremely good for very large sorts).

Michael M Rubenstein

Re: Should I learn C or Pascal?

[Alexander J Russell]

In article <4uu9v3$hrp@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au says...
>
>djohnson@tartarus.ucsd.edu (Darin Johnson) writes:
>>Actually, I learned it freshman year, but didn't understand it.
>...
>>I think many of my classmates kept the
>>"quicksort is the fastest sort" categorization without really
>>understanding it.  Too many people fall asleep in algorithms class
>>(then bitch about the waste of time later).
>
>The *really* sad thing here is that quicksort is *not* the fastest sort.
>Quicksort was specifically designed (see Hoare's paper in Computer
>Journal, 1960 or 61, can't remember the issue) for a machine with 256
>words of memory.  Not 256M.  Not 256k.  Two hundred and fifty-six words
>of main memory.  Backing store was a drum with 16384 words, transferred
>in 64 word pages.  Hoare knew at the time that it did more comparisons
>than merge sort, but merge sort need extra memory that simply wasn't there.
>
>Quicksort still has a niche in embedded processors,
>although there is a new version of heapsort (also published in the
>Computer Journal, but I can't find the reference) which can challenge it:
>the modern heapsort has the virtue that its worst case is O(nlgn) which
>makes it a better bet for soft-real-time work.
>
>For general use, a well engineered merge sort is as good as a well engineered
>quicksort; sometimes better.
>
>For sorting machine integers, a well engineered radix sort (or even count
>sort if the range is small enough) is so much faster that it isn't funny.
>
>For most programmers, the main issue is that it is cheaper to re-use
>an existing expertly implemented and thoroughly tested sort procedure
>than to write their own buggy code.
>-- 
>Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
>Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

heap sort: average N log N, worst case N log N
quick sort: average N log N, worst case N^2

But heap sort is more complicated, requires more code and generally runs slower 
than quick-sort for random data.

Quick-Sort is more fragile, and is realy bad for sorting sorted data.

So, heap sort CAN be faster than quick-sort, but it is false to clain that it 
is ALWAYS faster.

In general it is good to know a number of sorting algoriths and use the one 
best suited to the data being sorted.
-- 
The AnArChIsT! Anarchy! Not Chaos!
aka
Alex Russell
alexad3@iceonline.com

Re: Should I learn C or Pascal?

[Dr E. Buxbaum]

djohnson@tartarus.ucsd.edu (Darin Johnson) wrote:
>> A binary sort, also known as quicksort, or Hoare's sort is covered extensively

>"quicksort is the fastest sort" categorization without really
>understanding it.  

A common misconception. Quicksort is fast for UNSORTED data. For data 
which are largely presorted (a common occurance if a bunch of additional 
data has to be added to a list), Quicksort becomes Slowsort. 

Resume: Spend some time on checking your data first, then decide on the 
proper sorting algorithm!

Re: Should I learn C or Pascal?

[Lawrence Kirby]

In article <4v1r2a$gh6@falcon.le.ac.uk> EB15@le.ac.uk "Dr E. Buxbaum" writes:

>djohnson@tartarus.ucsd.edu (Darin Johnson) wrote:
>>> A binary sort, also known as quicksort, or Hoare's sort is covered
> extensively
>
>>"quicksort is the fastest sort" categorization without really
>>understanding it.  
>
>A common misconception. Quicksort is fast for UNSORTED data. For data 
>which are largely presorted (a common occurance if a bunch of additional 
>data has to be added to a list), Quicksort becomes Slowsort. 

Quicksort is faster for sorted data than unsorted data: any passable
implementation will use at the very least median-of-three pivot selection.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Should I learn C or Pascal?

[Paul Hsieh]

Lawrence Kirby wrote:
> 
> In article <4v1r2a$gh6@falcon.le.ac.uk> EB15@le.ac.uk "Dr E. Buxbaum" writes:
> 
> >djohnson@tartarus.ucsd.edu (Darin Johnson) wrote:
> >>> A binary sort, also known as quicksort, or Hoare's sort is covered
> > extensively
> >
> >>"quicksort is the fastest sort" categorization without really
> >>understanding it.
> >
> >A common misconception. Quicksort is fast for UNSORTED data. For data
> >which are largely presorted (a common occurance if a bunch of > >additional
> >data has to be added to a list), Quicksort becomes Slowsort.
> 
> Quicksort is faster for sorted data than unsorted data: any passable
> implementation will use at the very least median-of-three pivot > selection.

Geez ... pay attention in class next time folks:

On a reversed list, quicksort==bubble sort.
On a shifted list, quicksort==bubble sort.
On most other arrangements quicksort = O(nlnn)

Merge sort is O(nln) in all situations and hence is better when reliable
running time is required.

-- 
Paul Hsieh
qed@chromatic.com
http://www.geocities.com/SiliconValley/9498
Graphics Programmer
Chromatic Research

What I say and what my company says are not always the same thing

Re: Should I learn C or Pascal?

[Mike Rubenstein]

Paul Hsieh <qed@xenon.chromatic.com> wrote:

> Lawrence Kirby wrote:
> > 
> > In article <4v1r2a$gh6@falcon.le.ac.uk> EB15@le.ac.uk "Dr E. Buxbaum" writes:
> > 
> > >djohnson@tartarus.ucsd.edu (Darin Johnson) wrote:
> > >>> A binary sort, also known as quicksort, or Hoare's sort is covered
> > > extensively
> > >
> > >>"quicksort is the fastest sort" categorization without really
> > >>understanding it.
> > >
> > >A common misconception. Quicksort is fast for UNSORTED data. For data
> > >which are largely presorted (a common occurance if a bunch of > >additional
> > >data has to be added to a list), Quicksort becomes Slowsort.
> > 
> > Quicksort is faster for sorted data than unsorted data: any passable
> > implementation will use at the very least median-of-three pivot > selection.
> 
> Geez ... pay attention in class next time folks:
> 
> On a reversed list, quicksort==bubble sort.
> On a shifted list, quicksort==bubble sort.
> On most other arrangements quicksort = O(nlnn)
> 
> Merge sort is O(nln) in all situations and hence is better when reliable
> running time is required.

You should not have cut class the day they covered the techniques for
making O(N^2) performance very unlikely.  In fact, properly
implemented, quicksort will give O( N log N) performance on both a
reversed list and a shifted list.

Michael M Rubenstein

Re: Should I learn C or Pascal?

[Richard A. O'Keefe]

miker3@ix.netcom.com (Mike Rubenstein) writes:
>You should not have cut class the day they covered the techniques for
>making O(N^2) performance very unlikely.  In fact, properly
>implemented, quicksort will give O( N log N) performance on both a
>reversed list and a shifted list.

Yes, well I suppose all of us missed _something_ in our CS educations,
such as the fact that the "proof" that O(N**2) is unlikely assumes that
every possible permutation of the input is equally likely, which is not
true in the real world.  Check the paper by Bentley and someone (McIlroy?)
in Software Practice and Experience on "Engineering a Sort":  the UNIX
qsort() routine *did* yield O(N**2) behaviour in actual use by people who
were trying to solve a real problem, not break the sorting routine.

The likelihood of quicksort doing badly on *your* data depends on the
actual probability distribution of *your* data.

This leads to the odd observation that if you don't know what the
distribution of your data is, and you would like to be confident that
bad things are genuinely unlikely, a good first step is to *scramble*
your array before sorting it, so that the assumption of this proof is
known to be true!  (Permuting an array randomly is only O(N).)

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Should I learn C or Pascal?

[Mike Rubenstein]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) wrote:

> miker3@ix.netcom.com (Mike Rubenstein) writes:
> >You should not have cut class the day they covered the techniques for
> >making O(N^2) performance very unlikely.  In fact, properly
> >implemented, quicksort will give O( N log N) performance on both a
> >reversed list and a shifted list.
> 
> Yes, well I suppose all of us missed _something_ in our CS educations,
> such as the fact that the "proof" that O(N**2) is unlikely assumes that
> every possible permutation of the input is equally likely, which is not
> true in the real world.  Check the paper by Bentley and someone (McIlroy?)
> in Software Practice and Experience on "Engineering a Sort":  the UNIX
> qsort() routine *did* yield O(N**2) behaviour in actual use by people who
> were trying to solve a real problem, not break the sorting routine.

No.  The assumption that O(N^2) performance is unlikely assumes that
quicksort is properly implemented.  The distribution of the data has
nothing to do with it.

The fact that some versions of UNIX qsort() were badly implemented
doesn't change the fact that Hoare gave a simple method in his
original paper for making O(N^2) performance very unlikely for any
data distribution.

> 
> The likelihood of quicksort doing badly on *your* data depends on the
> actual probability distribution of *your* data.

Again, not if quicksort is implemented properly.
 
> This leads to the odd observation that if you don't know what the
> distribution of your data is, and you would like to be confident that
> bad things are genuinely unlikely, a good first step is to *scramble*
> your array before sorting it, so that the assumption of this proof is
> known to be true!  (Permuting an array randomly is only O(N).)

There is no need to permute the array.  Just follow Hoare's suggestion
for avoiding O(N^2) performance.

Hoare suggested choosing the pivot randomly.  This has the same effect
on overall performance as permuting the data.

Choosing the median of the first, middle, and last elements for the
pivot also works well in practice.  In particular, it will prevent
O(N^2) performance if the data is nearly in order or reverse order.


Michael M Rubenstein

Re: Should I learn C or Pascal?

[Richard A. O'Keefe]

miker3@ix.netcom.com (Mike Rubenstein) writes:
>No.  The assumption that O(N^2) performance is unlikely assumes that
>quicksort is properly implemented.  The distribution of the data has
>nothing to do with it.

The point I was trying to make is that the allegedly "unlikely"
behaviour is already *known* to have occurred much more often than
the theorems you see in data structures books would have you
believe.  Given any non-randomising version of quicksort, I can
construct a pessimal input for that version.  If the distribution
of the input I supply is such that pessimal problems occur with
probability 1, I will get so-called "unlikely" behaviour with
probability 1.  So *in the absence of built-in randomisation*
the distribution has a lot to do with it.

Again, some of the proofs of the unlikelihood of bad behaviour
tacitly assume that all elements are distinct.  Even randomisation
won't help unless you use a fat pivot or some other technique that
handles repeated elements well.

So if Mike Rubenstein means by "properly implemented" a quicksort
using randomisation and a fat pivot, then I am forced to agree with
him.  On the other hand, while the quicksort I use (the "Engineered"
one by Bentley & McIlroy) uses a fat pivot, it doesn't use randomisation,
so for a recently version of quicksort designed and tested by experts
and published in a refereed journal, which gets impressive performance
in practice (it is the first quicksort I've ever come across which can
routinely compete with a well implemented merge sort), it is possible
to find an input distribution for which "Engineered" qsort will behave
badly with probability 1.  So either Mike Rubenstein is wrong, or
Bentley & McIlroy's qsort is not "properly implemented".

>> The likelihood of quicksort doing badly on *your* data depends on the
>> actual probability distribution of *your* data.

>Again, not if quicksort is implemented properly.

Which either means "using randomisation and a fat pivot" or is false.

>There is no need to permute the array.  Just follow Hoare's suggestion
>for avoiding O(N^2) performance.

>Hoare suggested choosing the pivot randomly.  This has the same effect
>on overall performance as permuting the data.

Permuting the whole array is simpler and faster.  There is a phase where
the random number generator is in the cache and the sorting code is not,
then there is a phase when the sorting code is in the cache and the
random number generator is not.  What's more, depending on the random
number generator, it may be possible to vectorise the random number
generation and fuse that loop with the permutation loop.  The separated
approach *looks* as though it ought to be easier to make fast.  (For
example, if using AS183, the three integers it maintains can be kept in
registers during the permutation phase instead of being repeatedly
stored back into memory and reloaded.)

There is also the practical point that if you want to use someone else's
quicksort and don't fully trust it, you can permute the array yourself
before calling qsort, without being able to modify the qsort code.

>Choosing the median of the first, middle, and last elements for the
>pivot also works well in practice.

Ahem.  This is the approach that has yielded bad behaviour IN PRACTICE.

>In particular, it will prevent
>O(N^2) performance if the data is nearly in order or reverse order.

Only if (a) repeated elements are rare or (b) you use a fat pivot.

The only ways to make bad runtime cost unlikely for any algorithm are
(a) use an algorithm for which bad cost can *never* happen
(b) randomise so that you *know* what the distribution is.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Should I learn C or Pascal?

[Mike Rubenstein]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) wrote:

> miker3@ix.netcom.com (Mike Rubenstein) writes:
> >No.  The assumption that O(N^2) performance is unlikely assumes that
> >quicksort is properly implemented.  The distribution of the data has
> >nothing to do with it.
> 
> The point I was trying to make is that the allegedly "unlikely"
> behaviour is already *known* to have occurred much more often than
> the theorems you see in data structures books would have you
> believe.  Given any non-randomising version of quicksort, I can
> construct a pessimal input for that version.  If the distribution
> of the input I supply is such that pessimal problems occur with
> probability 1, I will get so-called "unlikely" behaviour with
> probability 1.  So *in the absence of built-in randomisation*
> the distribution has a lot to do with it.
> 
> Again, some of the proofs of the unlikelihood of bad behaviour
> tacitly assume that all elements are distinct.  Even randomisation
> won't help unless you use a fat pivot or some other technique that
> handles repeated elements well.
> 
> So if Mike Rubenstein means by "properly implemented" a quicksort
> using randomisation and a fat pivot, then I am forced to agree with
> him.  On the other hand, while the quicksort I use (the "Engineered"
> one by Bentley & McIlroy) uses a fat pivot, it doesn't use randomisation,
> so for a recently version of quicksort designed and tested by experts
> and published in a refereed journal, which gets impressive performance
> in practice (it is the first quicksort I've ever come across which can
> routinely compete with a well implemented merge sort), it is possible
> to find an input distribution for which "Engineered" qsort will behave
> badly with probability 1.  So either Mike Rubenstein is wrong, or
> Bentley & McIlroy's qsort is not "properly implemented".

I certainly mean that a properly implemented quicksort (or any other
algorithm) is one that is also properly applied and is implemented
with due consideration to the problem at hand.  For a general purpose
quicksort, this certainly means randomization and a fat pivot (or some
other technique for handling multiple elements).
 
> >> The likelihood of quicksort doing badly on *your* data depends on the
> >> actual probability distribution of *your* data.
> 
> >Again, not if quicksort is implemented properly.
> 
> Which either means "using randomisation and a fat pivot" or is false.
> 
> >There is no need to permute the array.  Just follow Hoare's suggestion
> >for avoiding O(N^2) performance.
> 
> >Hoare suggested choosing the pivot randomly.  This has the same effect
> >on overall performance as permuting the data.
> 
> Permuting the whole array is simpler and faster.  There is a phase where
> the random number generator is in the cache and the sorting code is not,
> then there is a phase when the sorting code is in the cache and the
> random number generator is not.  What's more, depending on the random
> number generator, it may be possible to vectorise the random number
> generation and fuse that loop with the permutation loop.  The separated
> approach *looks* as though it ought to be easier to make fast.  (For
> example, if using AS183, the three integers it maintains can be kept in
> registers during the permutation phase instead of being repeatedly
> stored back into memory and reloaded.)

What nonsense.  If you mean the instruction cache, it's unlikely that
the code for quicksort will fit in the cache.  If you mean high speed
memory (e.g., the typical memory cache on an 80x86 or pentium), both
will almost certainly fit.

Using a random pivot requires no movement of the data.  Rearranging
the data requires moving the data or constructing an array of pointers
of indices that will slow down the comparison.
 
> There is also the practical point that if you want to use someone else's
> quicksort and don't fully trust it, you can permute the array yourself
> before calling qsort, without being able to modify the qsort code.

If you are using untrusted code when timing is critical, you deserve
everything that happens to you.

If timing is really critical, functions like C's qsort() are
unsuitable anyways since they rely on inefficient comparison and,
possibly, swapping code.

I've never seen a general sort program that is always suitable.
 
> >Choosing the median of the first, middle, and last elements for the
> >pivot also works well in practice.
> 
> Ahem.  This is the approach that has yielded bad behaviour IN PRACTICE.
> 
> >In particular, it will prevent
> >O(N^2) performance if the data is nearly in order or reverse order.
> 
> Only if (a) repeated elements are rare or (b) you use a fat pivot.

Actually, repeated elements don't have to be rare.  What matters is if
there are a lot of a few elements.  For example, if every element
appears twice, repeated elements are common, but performance is still
O(n log n).  If there is likely to be items that are repeated many
times, a fat pivot should certainly be used.  My experience is that
this is not a very common situation, but your experience may differ.
 
> The only ways to make bad runtime cost unlikely for any algorithm are
> (a) use an algorithm for which bad cost can *never* happen
> (b) randomise so that you *know* what the distribution is.

More nonesense.  In practice one often knows a great deal about the
input.  Randomising may be the worst thing to do.  It's much better to
think than blindly follow rules.

Elsewhere, I've mentioned a problem I ran into of doing a lot of sorts
on almost in order data.  Insertion sort, with a known worst and
average case terrible performance, works quite well in such a
situation.  Randomizing and using someone elses quicksort would almost
certainly have been disasterous.


Michael M Rubenstein

Re: Should I learn C or Pascal?

[Mike Rubenstein]

"Dr E. Buxbaum" <EB15@le.ac.uk> wrote:

> djohnson@tartarus.ucsd.edu (Darin Johnson) wrote:
> >> A binary sort, also known as quicksort, or Hoare's sort is covered extensively
> 
> >"quicksort is the fastest sort" categorization without really
> >understanding it.  
> 
> A common misconception. Quicksort is fast for UNSORTED data. For data 
> which are largely presorted (a common occurance if a bunch of additional 
> data has to be added to a list), Quicksort becomes Slowsort. 

Only if it is implemented by an idiot.  Techniques that make O(n^2)
operation extremely unlikely are well known and are covered in any
decent book of algorithms.  Hoare's 1962 paper points out one of them.

If the data is known to be very close to being sorted, quicksort
(properly implemented) isn't the sort of choice, but it's not
terrible.

Michael M Rubenstein

Re: Should I learn C or Pascal?

[Paul Schlyter]

In article <4v1r2a$gh6@falcon.le.ac.uk>, Dr E. Buxbaum <EB15@le.ac.uk> wrote:
 
> djohnson@tartarus.ucsd.edu (Darin Johnson) wrote:
>>> A binary sort, also known as quicksort, or Hoare's sort is
>>> covered extensively
> 
>>"quicksort is the fastest sort" categorization without really
>>understanding it.  
> 
> A common misconception. Quicksort is fast for UNSORTED data. For data 
> which are largely presorted (a common occurance if a bunch of additional 
> data has to be added to a list), Quicksort becomes Slowsort. 
> 
> Resume: Spend some time on checking your data first, then decide on the 
> proper sorting algorithm!
 
The performane of Quicksort on already sorted, or almost-sorted, data
can be dramatically improved by first scrambling the data(!) somewhat.
 
For instance the first element can be exchanged with some element
near the middle, and then that new first element can be used as a
pivot.  This matters little on unsorted data, but ensures that on
almost-sorted data the pivot will each time split the data set into
two approximately equally large parts, which will yield near-optimum
performance of Quicksort.
 
Of course, this trick still does not ensure that Quicksort never will
perform miserably -- it still may do if the input data is ordered in
some particular way.  But at least it's much less likely to encounter
this "wost performance" initial order, and it's is quite different
from almost-sorted order.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch@saaf.se        psr@home.ausys.se

Re: Should I learn C or Pascal?

[Mike Rubenstein]

pausch@electra.saaf.se (Paul Schlyter) wrote:

> In article <4v1r2a$gh6@falcon.le.ac.uk>, Dr E. Buxbaum <EB15@le.ac.uk> wrote:
>  
> > djohnson@tartarus.ucsd.edu (Darin Johnson) wrote:
> >>> A binary sort, also known as quicksort, or Hoare's sort is
> >>> covered extensively
> > 
> >>"quicksort is the fastest sort" categorization without really
> >>understanding it.  
> > 
> > A common misconception. Quicksort is fast for UNSORTED data. For data 
> > which are largely presorted (a common occurance if a bunch of additional 
> > data has to be added to a list), Quicksort becomes Slowsort. 
> > 
> > Resume: Spend some time on checking your data first, then decide on the 
> > proper sorting algorithm!
>  
> The performane of Quicksort on already sorted, or almost-sorted, data
> can be dramatically improved by first scrambling the data(!) somewhat.
>  
> For instance the first element can be exchanged with some element
> near the middle, and then that new first element can be used as a
> pivot.  This matters little on unsorted data, but ensures that on
> almost-sorted data the pivot will each time split the data set into
> two approximately equally large parts, which will yield near-optimum
> performance of Quicksort.
>  
> Of course, this trick still does not ensure that Quicksort never will
> perform miserably -- it still may do if the input data is ordered in
> some particular way.  But at least it's much less likely to encounter
> this "wost performance" initial order, and it's is quite different
> from almost-sorted order.

Why not just pick the pivot randomly?  This was suggested by Hoare in
1962.

Michael M Rubenstein

Re: Should I learn C or Pascal?

[James Youngman]

In article <4vblm8$df9@electra.saaf.se>, pausch@electra.saaf.se says...

>The performane of Quicksort on already sorted, or almost-sorted, data
>can be dramatically improved by first scrambling the data(!) somewhat.

It all depends exactly on the Quicksort implementation chosen.  For example, 
the implementation in "The Standard C Library" by PJ Plauger runs fastest on 
fully-sorted input.

-- 
James Youngman                               VG Gas Analysis Systems
The trouble with the rat-race is, even if you win, you're still a rat.

Re: Should I learn C or Pascal?

[TRAN PHAN ANH]

Just a side comment, by the time this thread and its offsprings end, the 
original author will have learned both C and Pascal. :-)

Anh

In article <4veqrn$9qi@halon.vggas.com>, JYoungman@vggas.com (James Youngman) writes:
> In article <4vblm8$df9@electra.saaf.se>, pausch@electra.saaf.se says...
> 
>>The performane of Quicksort on already sorted, or almost-sorted, data
>>can be dramatically improved by first scrambling the data(!) somewhat.
> 
> It all depends exactly on the Quicksort implementation chosen.  For example, 
> the implementation in "The Standard C Library" by PJ Plauger runs fastest on 
> fully-sorted input.
> 
> -- 
> James Youngman                               VG Gas Analysis Systems
> The trouble with the rat-race is, even if you win, you're still a rat.
> 

Re: Should I learn C or Pascal?

[Dr E. Buxbaum]

anh@kuhub.cc.ukans.edu (TRAN PHAN ANH) wrote:
>Just a side comment, by the time this thread and its offsprings end, the 
>original author will have learned both C and Pascal. :-)

The discussion which programming language is best is as old as 
programming. Any choice reflects the needs and personality of the 
programmer at least as much as anything else (appart, of course, from the 
needs and personality of your employer).

First, I think, anybody commenting on this issue should state which 
languages he/she knows. A lot of people advocate the only language they 
know, not because it is best, but becaus it is the only language they 
know. I myself started with Fortran on a Cyber mainfraim computer, but 
when I started to learn Pascal, it was like a revelation and I have not 
written a single line of Fortran ever since. My second revelation came 
when I first started working on a microcomputer, getting fast responses, 
graphical output, a user friendly interface and no hassle with user 
numbers has thoroughly convinced me of their value. Over the last 10 
years I have looked at a few other programming languages like, C, APL, 
Forth, Basic and Prolog. None of them have had the same 'Aha' effect on 
me as Pascal did. C in particular is to cryptic for my taste, although I 
know it good enough to port the odd interesting routine to Pascal. 

Part of the problem is of course the kind of programs you write. My own 
work is mainly concerned with the handling and evaluation of scientific 
data (I am a biochemist). I like a language which allows me to come back 
to my own programs (or that of other people) after a couple of years and 
see immediately how things work. Short utility programs, which work close 
to the hardware, may be a different kettle of fish. Of course, I work 
exclusively in the MS-DOS world, if I had to port programs between 
different operating systems, Pascal might not be such a good choice 
(although with the new Pascal standard and Gnu-Pascal being available for 
different systems, this may change). 

On a more partisan tone, I always wondered whether or not the quality of 
a programming language should not be reflected somehow in the final 
product. Questions of maintainability, readability, compiler complexity  
and so on should leave traces in the programs for the end user to see. 
This would require 2 programs, serving the same purpose, written in 
different languages. These programs should be generally available and 
have a function common enough that the comparison can be done without 
specialist knowledge.

I know of only one pair of programs that meet these standards: 
COMMAND.COM, the shell of the MS-DOS operating system is written in C and 
Assembler. 4DOS.EXE, its replacement, is written in Pascal, with some C 
and Assembler. So, if you whant to know which language is better, go 
ahead and compare these two programs. May I add that my own computer runs 
4DOS?

Re: Should I learn C or Pascal?

[Jeffrey C. Dege]

On 13 Aug 1996 10:44:56 -0700, Darin Johnson <djohnson@tartarus.ucsd.edu> wrote:
>Too many people fall asleep in algorithms class
>(then bitch about the waste of time later).

It's odd how little things can bring back memories.

Sitting there at nine o'clock at night, because I couldn't fit the
day class into my schedule, listening to Sartaj Sahni drone:

    And in step 27, we set temp.prev.next to temp.next.

Then watching him erase the arrow connecting bubble C to bubble B,
then watching him draw an array connecting bubble C to bubble A.

    And in step 28, we set temp.next.prev to temp.prev.

Then watching him erase the arrow connecting bubble A to bubble B,
then watching him draw an array connecting bubble A to bubble C.

    And in step 30, we...

Has _anyone_ had an instructer who brought any excitement to this stuff,
or is it inherently impossible to teach without becoming dull and tedious?

-- 
Anyone who cannot cope with mathematics is not fully human.  At best he
is a tolerable subhuman who has learned to wear shoes, bathe and not
make messes in the house.
                -- Lazarus Long, "Time Enough for Love"

Re: Should I learn C or Pascal?

[Steve Heller]

jdege@jdege.visi.com (Jeffrey C. Dege) wrote:

>Has _anyone_ had an instructer who brought any excitement to this stuff,
>or is it inherently impossible to teach without becoming dull and tedious?
  I don't believe it's inherently impossible, and I suspect my
students would agree with me. In fact, I have had some of them doubled
over with laughter in class (and not at my inability to express
myself, either). For a sample of my writing and teaching style, as
well as information on my books, you might want to visit my web site.
I'd appreciate any feedback you might have to give me on it.


Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller 

Re: Should I learn C or Pascal?

[Craig Franck]

jdege@jdege.visi.com (Jeffrey C. Dege) wrote:
>On 13 Aug 1996 10:44:56 -0700, Darin Johnson <djohnson@tartarus.ucsd.edu> wrote:
>>Too many people fall asleep in algorithms class
>>(then bitch about the waste of time later).
>
>It's odd how little things can bring back memories.
>
>Sitting there at nine o'clock at night, because I couldn't fit the
>day class into my schedule, listening to Sartaj Sahni drone:
>
>    And in step 27, we set temp.prev.next to temp.next.
>
>Then watching him erase the arrow connecting bubble C to bubble B,
>then watching him draw an array connecting bubble C to bubble A.
>
>    And in step 28, we set temp.next.prev to temp.prev.
>
>Then watching him erase the arrow connecting bubble A to bubble B,
>then watching him draw an array connecting bubble A to bubble C.
>
>    And in step 30, we...
>
>Has _anyone_ had an instructer who brought any excitement to this stuff,
>or is it inherently impossible to teach without becoming dull and tedious?
>
>-- 
>Anyone who cannot cope with mathematics is not fully human.  At best he
>is a tolerable subhuman who has learned to wear shoes, bathe and not
>make messes in the house.
>                -- Lazarus Long, "Time Enough for Love"
>

Robet Heinlein "Time Enough for Algorithms". It's a story about a 
liberal arts student who gets his brain transplanted into the body of 
a famous mathematician. So of course eveyone takes him seriously, and 
he then goes on to describe the "Worlds Most Important Algorithm".

I had a professor who used to say "I am here to teach, not entertain!".
Why the two had to become separated is a mystery to me...

-- 
Craig  
clfranck@worldnet.att.net 
Manchester, NH
"You see all around you people engaged in making others live
lives which are not their own, while they themselves care
nothing for their own real lives -- men who hate life though
they fear death". -- William Morris, "News from Nowhere" (1891)

Re: Should I learn C or Pascal?

[Ted Dennison]

Craig Franck wrote:
> 
> 
> I had a professor who used to say "I am here to teach, not entertain!".
> Why the two had to become separated is a mystery to me...
> 

(S)He's a moron. The best teachers I ever had were the MOST entertaining. 

One was even a former stand-up comedian, and it sure showed. Imagine a
prob/stat class being so interesting that people who aren't even taking
the course come to class!

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Should I learn C or Pascal?

[John Hobson]

Ted Dennison wrote:
> 
> Craig Franck wrote:
> > I had a professor who used to say "I am here to teach, not entertain!".
> > Why the two had to become separated is a mystery to me...
> 
> (S)He's a moron. The best teachers I ever had were the MOST entertaining.
> 
> One was even a former stand-up comedian, and it sure showed. Imagine a
> prob/stat class being so interesting that people who aren't even taking
> the course come to class!

As an undergraduate, I had a professor who was a Southern Baptist
minister.
His lectures were spellbinding.

I also once took a physics class from a Nobel Prize winner.  They missed
a sure bet by not taping his lectures and selling them as cures for
insomnia.

--
John Hobson             |Whenever someone says to me,
Unix Support Group      |"Have a nice day", I reply,
ComEd, Chicago, IL, USA |"Sorry, I've made other plans."
jhobson@ceco.ceco.com   |	-- Sir Peter Ustinov

Re: Should I learn C or Pascal?

[Ted Dennison]

Jeffrey C. Dege wrote:
> 
> On 13 Aug 1996 10:44:56 -0700, Darin Johnson <djohnson@tartarus.ucsd.edu> wrote:
> >Too many people fall asleep in algorithms class
> >(then bitch about the waste of time later).
> 
> It's odd how little things can bring back memories.
> 
> Sitting there at nine o'clock at night, because I couldn't fit the
> day class into my schedule, listening to Sartaj Sahni drone:
> 
>     And in step 27, we set temp.prev.next to temp.next.
> 

> Has _anyone_ had an instructer who brought any excitement to this stuff,
> or is it inherently impossible to teach without becoming dull and tedious?
> 

My graduate Algorithms instructor at UCF was pretty interesting. He even
made sure to point out the relationship between the FindIth algorithm, 
tennis matches, and Alice in Wonderland.

Of course, I've had some of my fellow students violently disagree with me
on this. But I think they were reacting to the course's heavy math content.


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Should I learn C or Pascal?

[Bob Cousins]

jdege@jdege.visi.com (Jeffrey C. Dege) wrote:

>Has _anyone_ had an instructer who brought any excitement to this stuff,
>or is it inherently impossible to teach without becoming dull and tedious?

If you want entertainment go and watch a movie.


-- 
Bob Cousins, Software Engineer.
http://www.demon.co.uk/sirius-cybernetics/

Re: Should I learn C or Pascal?

[Robert Dewar]

Jefferey asks

"Has _anyone_ had an instructer who brought any excitement to this stuff,
or is it inherently impossible to teach without becoming dull and tedious?
"

Well I have had plenty of students who did not find this dull and tedious,
but of course that may be because of them rather than me :-)

Re: Should I learn C or Pascal?

[Patrick Horgan]

In article <slrn524jju.7hg.jdege@jdege.visi.com>, jdege@jdege.visi.com (Jeffrey C. Dege) writes:
> 
> Has _anyone_ had an instructer who brought any excitement to this stuff,
> or is it inherently impossible to teach without becoming dull and tedious?

I think I've done a pretty good job of it with pictures and arrows and yelling,
and drawing faces on things and jokes.  If you're interesting and you keep a
close lookout for glazed eyes and fix it before its a problem you can teach
things pretty well.  I suspect that I can do a good job of it because I like
it.  I get excited about cool algorithms and I like to show other people how
cool they are.

That's not to say that I uniformly teach well to all though.  One of the
hardest things about teaching (and the reason I like tutoring better) is
that everyone brings something different to the classroom and nothing you
can do will be right for everyone...sigh...

-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

Re: Should I learn C or Pascal?

[Ralph Silverman]

Patrick Horgan (patrick@broadvision.com) wrote:
: In article <4u7hi6$s2b@nntp.seflin.lib.fl.us>, z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman) writes:
: > 
: > 	re.
: > 	"...binary sort algorithm..."
: > 
: > 	i remember such from the
: > 		military programming of the 1980's
: > 	...
: > 
: > 	has this reached the textbooks now?
: > 
: > 	also,
: > 	seems pretty hard for a
: > 		technical interview question

: A binary sort, also known as quicksort, or Hoare's sort is covered extensively
: in Knuth's volume three (from 1971) and in every undergraduate data structure
: and algorithm course in the world;)...you would expect anyone with a CS degree
: to be familiar with it.




: -- 

:    Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
:    Opinions mine, not my employer's except by most bizarre coincidence.



--
************begin r.s. response*******************

	are such commonly termed
		binary sort
	?

	in any case these are not the
		intended reference!

************end r.s. response*********************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[Darin Johnson]

> Resume: Spend some time on checking your data first, then decide on the 
> proper sorting algorithm!

And that's the whole point.  If a student learns "quicksort is
fastest" they won't ever think about the issues involved.  I ran
across one program where an item was added to a sort list by adding it
the end and then calling qsort().  Yes, very abstract with code
re-use, but it ignored efficiency altogether (it appeared though that
this was written quickly to get things working, and the author never
came back later to improve it).


-- 
Darin Johnson
djohnson@ucsd.edu	O-
	My shoes are too tight, and I have forgotten how to dance - Babylon 5

Re: Should I learn C or Pascal?

[Darin Johnson]

> Why not just pick the pivot randomly?  This was suggested by Hoare in
> 1962.

I seem to recall a paper or method that basically said that the better
you picked your pivot, the better the quicksort, and then gave some
alternatives.  My recollection was that you could pick a quick set of
points (first, last, middle; or all random) and then choose the median
of that set.

And of course, you can always sort in O(n) as long as you have a
finite set of things to sort :-)  (actually, in O(1) theoretically
but real world implications say that a finite 'n' is still an 'n')
-- 
Darin Johnson
djohnson@ucsd.edu	O-
    "Floyd here now!"

Re: Should I learn C or Pascal?

[Sherwin Anthony Sequeira]

In article <4ttmpi$l3k@ns.broadvision.com>,
	patrick@broadvision.com (Patrick Horgan) writes:
> In article <qqspaho8h3.fsf@tartarus.ucsd.edu>, djohnson@tartarus.ucsd.edu (Darin Johnson) writes:
> 
[lots snipped]
> And always, always, always keep learning, be one of the people that learns 
> new stuff first.  Be a leader.  But always learn in depth.  It doesn't really
> get added to your repertoire until it becomes common sense.

	Bingo! 
> -- 
> 
>    Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
>    Opinions mine, not my employer's except by most bizarre coincidence.
> 

-- 
Tony Sequeira

Re: Should I learn C or Pascal?

[Jon S Anthony]

In article <gwinn-2307961502440001@smc19.ed.ray.com> gwinn@res.ray.com (Joe Gwinn) writes:

> He wants to find a better job, not find religion, or become a better
                     ^^^^^^
> person.  So, where are the jobs?
                         ^^^
I don't think there's much correlation between these, but if the latter
is what's desired, then clearly the answer is:


Visual Basic...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Should I learn C or Pascal?

[++ robin]

	Carlos DeAngulo <cdvi@msg.itg.ti.com> wrote in article
	<01bb74ac$b7aa7860$7b91f780@deangulo>...
	> You should definitely learn C/C++. The business world today uses C++ as
	>its
	> power language to develop the finest applications. Don't let anyone guide
	> you wrong.
	
	>Not to start a flame war on C++, but all you newbie programmers
	>out there, don't believe everything you hear about C++.  Object
	>oriented programming has a lot of good concepts, but C++ is a bad
	>implementation of them.  Not that you shouldn't learn it, but
	>don't think it's the ultimate expression of what OOP is all about.
	
	>C++: The PL/I of the 90s.

---The PL/I of the 90s is considerably enhanced,
with strong typing for list processing,
ordinals, an extended macroprocessor, Year 2000
date processing, and much more.

Re: Should I learn C or Pascal?

[++ robin]

	dewar@cs.nyu.edu (Robert Dewar) writes:

	>"An algorithm is just a set of instructions on how to accomplish a task. An
	>algorithm does not depend at all on any sort of programming "language". In
	>fact, I was taught that you should write out your "game plan" and psuedo
	>code before you even touch any sort of syntax in any language. Yes, I do
	>tend to write up my psuedo-code in a C-like syntax frequently but you
	>don't need to.

	>     Loop until variable is equal to 7
	>        Add 1 to variable
	>        Print out the following string to screen: ;-)
	>        end of loop

	>There's an algorithm written in plain english."

---To be an algorithm, it must be definite.  This one isn't.
The variable "variable" must be intialized.

	>First of all "pseudo-code" is still written in a language, which has syntax
	>and semantics. The trouble with an algorithm written in "plain english"
	>like the above is that it is imprecise. For example does the string that
	>is written to screen include a leading blank? I have no idea from the above.

	>If variable is 2**32-1, does the above still work? I have no idea.

	>Are the strings on separate lines of the screen? I have no idea.

	>writing

	>   while variable /= 7 loop
	>      variable := variable + 1;
	>      put_line (";-)");
	>   end loop;

	>is less writing than you did, just as clear, and importantly, exactly
	>precise

---This isn't any more of an algorithm than that of the
previous writer.  The variable "variable" still isn't
initialized.

Now, how about:

	DO I = 1 TO 7 BY 1;
		PUT SKIP LIST ( ';-)' );
	END;

is abundantly clear that the loop is being executed with
clear start and finish values of the control variable.
Furthermore, the loop will be executed exactly 7 times.

Might be better to consider learning PL/I . . .

Re: Should I learn C or Pascal?

[Robert Barnes]

++ robin wrote:
> 
>         dewar@cs.nyu.edu (Robert Dewar) writes:
> 
>         >"An algorithm is just a set of instructions on how to accomplish a task. An
>         >algorithm does not depend at all on any sort of programming "language".True, but the way that you express an algorithm is at least partly conditioned by your proposed implementation. 
 Not that there's anything wrong with this IMHO. I used to use a mixture of PL/I and English - where PL/I was 
at least as concise, then I saw no point in writing "English" just to be "Not a programming language".  
Similarly, if you're going to be expressing in C, or Pascal, or whatever.  

The rule for pseudocode should be "use the clearest communication to your audience".  Who is your audience?  
Yourself, and your collegues.  There needs to be some degree of consensus with your collegues (= documentation 
standards), but these needn't be rigid.  If your task was doing something with valid account data (let's 
assume that this is properly understood in this context), then in my programming group I'd have allowed forms 
such as:-
	DO for every valid account
	   xxxxx
	ENDDO
and
	FOR EVERY valid account DO
	   xxxxx
	END
and variations on these - LOOP, FOR ALL, WITH EACH ...   whatever.  As long as it's clear and unequivocal.

Pseudocode should summarize.  Thus in the example given:-
> 
>         >     Loop until variable is equal to 7
>         >        Add 1 to variable
>         >        Print out the following string to screen: ;-)
>         >        end of loop
> the introduction of "variable", is unnecessary, and has only added to the confusion.  Hence the subsequent 
discussion which has generated more heat than light. In fact, like Robin, at this level I'd have written the 
PL/I directly, but if I did feel the need for pseudocode (because there was some real complexity to the logic 
within the loop), I'd probably have written something like:-
	DO 7 times
	  xxxx
The whole point about successive refinement is to avoid getting bogged down in detail that is irrelevant to the 
level that you're designing.

Re: Should I learn C or Pascal?

[Rob(t.) Brannan]

As a first language Pascal is the way to go for many reasons.

C is very complicated as a first language (libraries,pointers,numerous
low level routines), not to mention some of the errors that you will
encounter are not exactly well covered in any book.

As a newbie , remember trying to figure out whats wrong when an
included file or library was just left out!

Re: Should I learn C or Pascal?

[++ robin]

	robt2@ix.netcom.com(Rob(t.) Brannan) writes:

	>As a first language Pascal is the way to go for many reasons.

	>C is very complicated as a first language (libraries,pointers,numerous
	>low level routines), not to mention some of the errors that you will
	>encounter are not exactly well covered in any book.

	>As a newbie , remember trying to figure out whats wrong when an
	>included file or library was just left out!

---Then use PL/I.  That just can't happen!

PL/I is an excellent first language.  And the
output is even *easier* to do than Pascal or C.

BTW, one of the advantages of PL/I for a beginner
is the excellent diagnstic messages not only at run time,
but also at compile time.

Re: Should I learn C or Pascal?

[Ralph Silverman]

++           robin (rav@goanna.cs.rmit.edu.au) wrote:
: 	robt2@ix.netcom.com(Rob(t.) Brannan) writes:

: 	>As a first language Pascal is the way to go for many reasons.

: 	>C is very complicated as a first language (libraries,pointers,numerous
: 	>low level routines), not to mention some of the errors that you will
: 	>encounter are not exactly well covered in any book.

: 	>As a newbie , remember trying to figure out whats wrong when an
: 	>included file or library was just left out!

: ---Then use PL/I.  That just can't happen!

: PL/I is an excellent first language.  And the
: output is even *easier* to do than Pascal or C.

: BTW, one of the advantages of PL/I for a beginner
: is the excellent diagnstic messages not only at run time,
: but also at compile time.

--
*************begin r.s. response***************

	pl/1  certainly would be good...
	but is this available for the pc?

	once found a kind of interpreter/simulator...
	but this was quite limited in language features!

*************end r.s. response*****************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[++ robin]

	z007400b@bcfreenet.seflin.lib.fl.us (Ralph Silverman) writes:

	>++           robin (rav@goanna.cs.rmit.edu.au) wrote:
	>: 	robt2@ix.netcom.com(Rob(t.) Brannan) writes:

	>: 	>As a first language Pascal is the way to go for many reasons.

	>: 	>C is very complicated as a first language (libraries,pointers,numerous
	>: 	>low level routines), not to mention some of the errors that you will
	>: 	>encounter are not exactly well covered in any book.

	>: 	>As a newbie , remember trying to figure out whats wrong when an
	>: 	>included file or library was just left out!

	>: ---Then use PL/I.  That just can't happen!

	>: PL/I is an excellent first language.  And the
	>: output is even *easier* to do than Pascal or C.

	>: BTW, one of the advantages of PL/I for a beginner
	>: is the excellent diagnstic messages not only at run time,
	>: but also at compile time.

	>*************begin r.s. response***************

	>	pl/1  certainly would be good...
	>	but is this available for the pc?

---PL/I is available on the PC in various versions:

1.  from Liant Software (PL/I for Windows)
2.  from IBM (PL/I for Windows 95/NT; 
3.  from IBM (PL/I for OS/2).

	>	once found a kind of interpreter/simulator...
	>	but this was quite limited in language features!

	>*************end r.s. response*****************
	>Ralph Silverman
	>z007400b@bcfreenet.seflin.lib.fl.us

Re: Should I learn C or Pascal?

[Tony Konashenok]

One of my pet peeves about C is REALLY poor diagnostics from the vast
majority of compilers. Certain easily-correctable syntax errors cause
a fatal error when they could easily be fixed by compiler and only induce
a warning; many error messages point very far from the place where the
error actually happened (well, it's mostly the language syntax that caused
it, but compilers could also be somewhat smarter); hardly any compiler
produces a cross-reference dictionary.
Another serious limitation is that fixed-point numbers can only be integer.
I can't count how many times I had to do dirty tricks to circumvent it.

Pascal is better... but I am not into B&D. I vote for PL/I!

Tony Konashenok
Team PL/I

Re: Should I learn C or Pascal?

[Lawrence Kirby]

In article <4tqoru$kdn@overload.lbl.gov>
           tonyk@sseos.lbl.gov "Tony Konashenok" writes:

>One of my pet peeves about C is REALLY poor diagnostics from the vast
>majority of compilers. Certain easily-correctable syntax errors cause
>a fatal error when they could easily be fixed by compiler and only induce
>a warning;

You're saying that the compiler complaining in the strongest terms about
invalid syntax is poor diagnostics? I call it essential diagnostic.
I do not want the compiler to 2nd guess my intent, it can all too easily
get it wrong (even another programmer can easily misjudge where that
extra brace is supposed to go). A syntax error means the source code
needs fixing and a good compiler will highlight that and not try to
work around it.

>many error messages point very far from the place where the
>error actually happened (well, it's mostly the language syntax that caused
>it, but compilers could also be somewhat smarter);

Some compilers are better than others, I don't find this to be much of
a problem.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Should I learn C or Pascal?

[Verne Arase]

In article <4tqoru$kdn@overload.lbl.gov>,
tonyk@sseos.lbl.gov (Tony Konashenok) wrote:

 >Another serious limitation is that fixed-point numbers can only be
integer.
 >I can't count how many times I had to do dirty tricks to circumvent it.

... or really stupid stuff like having a numeric interger constant suddenly
shift over into octal because you coded a leading zero.

Yes I know a leading zero makes it octal. Yes, I know that C was originally
designed to be run on much slower hardware, and some shortcuts had to be
taken.

Doesn't mean that I don't occasionaly get bitten by this one though :-/.

---
The above are my own opinions, and not those of my employer.

Re: Should I learn C or Pascal?

[++ robin]

	Crash <wakko@starbase1.htls.lib.il.us> writes:

	>An algorithm is just a set of instructions on how to accomplish a task. An
	>algorithm does not depend at all on any sort of programming "language". In
	>fact, I was taught that you should write out your "game plan" and psuedo
	>code before you even touch any sort of syntax in any language. Yes, I do
	>tend to write up my psuedo-code in a C-like syntax frequently but you
	>don't need to.

	>     Loop until variable is equal to 7
	>	Add 1 to variable
	>	Print out the following string to screen: ;-)
	>	end of loop

	>There's an algorithm written in plain english.

---To be an algorithm, it must be definite.  This one isn't.
The variable "variable" is never initialized.

	 It's a stupid algorithm,
	>I'll give you that, but one none the less and it's not written in any
	>programming "lanugage/syntax" I have ever worked with.