Should I learn C or Pascal?
Ralph Silverman
Gabor Egressy (gegr...@uoguelph.ca) wrote:
: Seth Perlman (sper...@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 gegr...@uoguelph.ca
: Guelph, Ontario ga...@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 schw...@imn.th-leipzig.de Fri Apr 12 11:47:54 1996
Date: Wed, 28 Jun 95 11:42:19 +0200
From: rainer schwarze <schw...@imn.th-leipzig.de>
To: z007...@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
z007...@bcfreenet.seflin.lib.fl.us
Steve Sobol
z007...@bcfreenet.seflin.lib.fl.us (Ralph Silverman) wrote:
>Gabor Egressy (gegr...@uoguelph.ca) wrote:
>: Seth Perlman (sper...@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 == sjs...@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. :)
Lee Crites
z007...@bcfreenet.seflin.lib.fl.us (Ralph Silverman) wrote:
>Gabor Egressy (gegr...@uoguelph.ca) wrote:
>: Seth Perlman (sper...@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
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
djoh...@ucsd.edu O-
Support your right to own gnus.
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
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
Aron Felix Gurski
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
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.
> technique in which it is used. Lean a
> language well. but more importantly, learn the technique of good
> 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
kan...@pacificnet.net
check out my web site at
http://www.pacificnet.net/~kanner/
----------------------------------------------------
Jason Alan Turnage
Patrick Horgan (pat...@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
tur...@cc.gatech.edu
Ralph Silverman
Chris Engebretson (enge...@sg2.cr.usgs.gov) wrote:
: |> >In article <4s0kb0$m...@btmpjg.god.bel.alcatel.be>, i...@rsd.bel.alcatel.be (Ian Ward) writes:
: [ snip some comments and code ]
: |> But it does get functionally simpler, if you had a language that
: |> could define varying length arrays, which had their lengths built-in,
: |> then the programmer would not have to specify the 9 and 5 in the
: |> call. This construct of course would be much easier to maintain than
: |> your given example.
: True. And speaking strictly of arrays, this is possible in C through the
: use of macros and the sizeof operator (as Lawrence pointed out a few days
: ago) although this would not work or buy you anything with pointers to
: arrays. (Then of course, one might defend or attack the use of macros
: to introduce "features" like this into a language, but I'll make no such
: presumption here. :-)
: |> (This I recognise is nothing to do with our thread here. :-)
: |>
: |> Again, I agree, but this kid wants to learn to be a good programmer,
: |> not the best implementation of some problem. Incidentally, I did say
: |> that I would not recommend Pascal anyway, even though it meets its
: |> requirements well, I suggested Ada95 instead, because as he got better,
: |> would learn, safely, about OOP, inheritance, multi-threading, pointers,
: |> exception handling etc.
: This is a valid point. Actually, experience with a certain number of
: arbitrary _languages_ might not be the best source of experience; rather
: it may be experience with a certain number of _methodologies_ and
: structures. At that point a programmer can say "Okay .. I've walked on the
: strongly-typed and 'safe' side of things and I've walked on the lenient and
: more forceful side of things .. and <xxxxx> is what I prefer."
: |> >more than we'd care to admit, I daresay.) What I _am_ saying is that these
: |> >programmers will generally be able to identify the source of these errors,
: |> >and don't really need the help of language-level protection mechanisms.
: |>
: |> This is a contentious issue, and I'm not going to get into this argument.
: |> I guess we should agree to disagree on this one.
: Contentious .. how true. :-) Most of the programmers in this organization
: look down on mechanisms designed to protect them from their own mistakes at
: the potential cost of decreased runtime efficiency. In fact, we have
: individuals who are against prototyping our library functions in header
: files. But as you pointed out, this certainly is not a universal
: attitude and is going to vary from programmer to programmer, from
: organization to organization, and from project to project.
: |> Not to you perhaps, but to the parents of the children you have just ran over,
: |> I am sure it does :-)
: This has become overly and philisophically symbolic. :-)
: |> >I use debuggers/profilers/etc. profusely, but there's a distinction here:
: |> >
: |> >They aren't part of the language itself. There's a world of difference
: |> >between lint warning me about a suspicious assignment and the compiler
: |> >simply not allowing me to do it. :-)
: |>
: |> The compiler will let you do it, but you have to force it to, but nine
: |> times out of ten, you realise that you did not mean it anyway, it is
: |> usually a mistake.
: |>
: |> The only distinction I see is that with C the checking is after, and with
: |> Pascal, Ada etc. the checking is before.
: But again, speaking of the language's (Pascal's) production value as
: opposed to its educational value, there does not exist a way to disable
: the language's type checking when you need to. Or, as, Kernighan puts it:
: "There is no escape."
: This is what dooms Pascal in its standard form to be nothing more than a
: language for teaching, although in that respect it performs as advertised.
: Regards,
: --
: /*-------------------------------------------------------------
: Chris Engebretson // CSB - SED - Scientific Systems Development
: United States Geological Survey - National Mapping Division
: Mundt Federal Building, USGS EROS Data Center
: Sioux Falls, SD 57198 http://edcwww.cr.usgs.gov/eros-home.html
: email: enge...@edcserver1.cr.usgs.gov phone: 605-594-6829
: -------------------------------------------------------------*/
--
**************begin r.s. response*************
regarding advantages of use of
varying language
(traditions, levels, implementations)
by same programmer...
(also operating systems, hardware, projects)
a deep understing of the
fundamentals of the art
is good to develop
yes
?
such is enhanced by such varying experience.
**************end r.s. response***************
Ralph Silverman
z007...@bcfreenet.seflin.lib.fl.us
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.
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 pat...@broadvision.com Have horse will ride.
Opinions mine, not my employer's except by most bizarre coincidence.
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.
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.
Dirk Dickmanns
"Carlos DeAngulo" <cd...@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++
Philip Brashear
In article <4sjmtk$e...@herald.concentric.net>,
Mark McKinney <mck...@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
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 (k...@mol.biol.ethz.ch, http://www.mol.biol.ethz.ch/~kor)
Tim Behrendsen
Carlos DeAngulo <cd...@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.
Scott McMahan - Softbase Systems
Patrick Horgan (pat...@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
johnf
In article <01bb7591$83087d60$87ee...@timpent.airshields.com>, "Tim
Behrendsen" <t...@airshields.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?
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
Go Falcons
Carlos DeAngulo
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.
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. 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 Dewar <de...@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
Andrew Gierth
[This thread should never have been injected into comp.unix.programmer.
Would further contributors *please* take note. Followups set.]
bi...@cast.msstate.edu wrote:
>In article <dewar.837728071@schonberg>, de...@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.
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.
Jon Bell
Robert Dewar <de...@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 <jtb...@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
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).
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.
Vic Metcalfe
Jason Alan Turnage (tur...@cc.gatech.edu) wrote:
: Patrick Horgan (pat...@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.
Billy Chambless
In article <dewar.837728071@schonberg>, de...@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 | bi...@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.1...@netlabs.com>
Jeremy Nelson
johnf <jo...@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
Andrew Gierth
[This thread should never have been injected into comp.unix.programmer.
Would respondents *please* take that into account. Followups set.]
Andrew Gierth
[This thread should never have been injected into comp.unix.programmer.
Would all respondents *please* take that into account. Followups set.]
Andrew Gierth
[This thread should never have been injected into comp.unix.programmer.
Craig Franck <clfr...@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...
Craig Franck
Jason Alan Turnage
johnf (jo...@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
tur...@cc.gatech.edu
Tim Behrendsen
johnf <jo...@nando.com> wrote in article
<johnf-19079...@johnf-mac.nando.com>...
> In article <01bb7591$83087d60$87ee...@timpent.airshields.com>, "Tim
> Behrendsen" <t...@airshields.com> wrote:
>
> >Carlos DeAngulo <cd...@msg.itg.ti.com> wrote in article
> ><01bb74ac$b7aa7860$7b91f780@deangulo>...
as
> >its
> >> power language to develop the finest applications. Don't let anyone
guide
> >> you wrong.
> >
> >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.
>
>
> 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?
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...
>
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*.
Mark Eissler
In article <1996Jul20.1...@kuhub.cc.ukans.edu>,
a...@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.
teq...@interlog.com | Still Raining. http://www.interlog.com/~tequila/ | Still...
Tim Behrendsen
Scott McMahan - Softbase Systems <soft...@mercury.interpath.com> wrote in
article <4sokr1$4...@news.interpath.net>...
> Patrick Horgan (pat...@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."
TRAN PHAN ANH
In article <dewar.837815529@schonberg>, de...@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 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
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.
Andy Askey
a...@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
aja...@gnn.com
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$6bf4...@dave.iceslimited.com>, "David Verschoore" <dve...@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
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
> djoh...@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.
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 <gue...@gnat.com>, Team Ada.
"Use the Source, Luke. The Source will be with you, always (GPL)."
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.
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
Stig Norland
In article <4svvjf$c...@news1.i1.net>, tro...@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 ???
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.
Stephen M O'Shaughnessy
>
>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.
>
>
Yes, but "Hello World" is not a 'real' program. 8}
Stephen M O'Shaughnessy
In article <4t01v4$8...@news.inc.net>, nel...@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.
Ralph Silverman
Tim Behrendsen (t...@airshields.com) wrote:
: Scott McMahan - Softbase Systems <soft...@mercury.interpath.com> wrote in
: article <4sokr1$4...@news.interpath.net>...
: > Patrick Horgan (pat...@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
z007...@bcfreenet.seflin.lib.fl.us
Janus
With nothing better to do on Mon, 22 Jul 1996 13:21:32 GMT,
tro...@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 : j...@iol.ie
WWW : http://www.iol.ie/~jab
Stephen M O'Shaughnessy
In article <4sord0$l...@solaria.cc.gatech.edu>, tur...@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?
TRAN PHAN ANH
In article <dewar.837900271@schonberg>, de...@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."
>
> 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
Jeremy Nelson
In article <Duy1n...@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
Ralph Silverman
johnf (jo...@nando.com) wrote:
: In article <01bb7591$83087d60$87ee...@timpent.airshields.com>, "Tim
: Behrendsen" <t...@airshields.com> wrote:
: OK
: Thank you,
: Johnf
: --
: jo...@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
z007...@bcfreenet.seflin.lib.fl.us
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
djoh...@ucsd.edu O-
Where am I? In the village... What do you want? Information...
Tim Oxler
jtb...@presby.edu (Jon Bell) wrote:
> Robert Dewar <de...@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 <jtb...@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.
tro...@i1.net
http://www.i1.net/~troxler
http://users.aol.com/TEOcorp
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
djoh...@ucsd.edu O-
"Particle Man, Particle Man, doing the things a particle can"
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.
Ralph Silverman
TRAN PHAN ANH (a...@kuhub.cc.ukans.edu) wrote:
: In article <dewar.837815529@schonberg>, de...@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 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
z007...@bcfreenet.seflin.lib.fl.us
Ralph Silverman
Robert Dewar (de...@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
z007...@bcfreenet.seflin.lib.fl.us
Ralph Silverman
Robert Dewar (de...@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.
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 <31EF54...@spectrospin.ch>, Reto Koradi <k...@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 (k...@mol.biol.ethz.ch, http://www.mol.biol.ethz.ch/~kor)
John A Hughes
In article <johnf-19079...@johnf-mac.nando.com>,
johnf <jo...@nando.com> wrote:
>In article <01bb7591$83087d60$87ee...@timpent.airshields.com>, "Tim
>Behrendsen" <t...@airshields.com> wrote:
>
>>Carlos DeAngulo <cd...@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
>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
>[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
John A Hughes
In article <4sntoi$i...@ns1.sw-eng.falls-church.va.us>,
Philip Brashear <bras...@ns1.sw-eng.falls-church.va.us> wrote:
>In article <4sjmtk$e...@herald.concentric.net>,
>Mark McKinney <mck...@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
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
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"
TRAN PHAN ANH
In article <Duy3I...@most.fw.hac.com>, smo...@most.fw.hac.com (Stephen M O'Shaughnessy) writes:
> In article <1996Jul20.1...@kuhub.cc.ukans.edu>, a...@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?
>>
>>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.
>>
>>
>
> 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
Richard A. O'Keefe
>Gabor Egressy (gegr...@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.
Tim Behrendsen
Ralph Silverman <z007...@bcfreenet.seflin.lib.fl.us> wrote in article
<4t0pcb$p...@nntp.seflin.lib.fl.us>...
> Tim Behrendsen (t...@airshields.com) wrote:
> : Scott McMahan - Softbase Systems <soft...@mercury.interpath.com> wrote
in
> : article <4sokr1$4...@news.interpath.net>...
> : > Patrick Horgan (pat...@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."
>
> 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.
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
djoh...@ucsd.edu O-
Gravity is a harsh mistress - The Tick
Michael Feldman
In article <qq3f2i6...@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
------------------------------------------------------------------------
Andrew J Steinbach
Darin Johnson (djoh...@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
stei...@maroon.tc.umn.edu
Jon Bell
[followups set to comp.edu, which is where this discussion really belongs]
Andrew J Steinbach <stei...@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.
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:denn...@escmail.orl.mmc.com |
| Home - mailto:denn...@iag.net |
| URL - http://www.iag.net/~dennison |
Darin Johnson
gw...@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
djoh...@ucsd.edu O-
The opinions expressed are not necessarily those of the
Frobozz Magic Hacking Company, or any other Frobozz affiliates.
Ralph Silverman
Darin Johnson (djoh...@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
: djoh...@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
z007...@bcfreenet.seflin.lib.fl.us
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
> : 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
> : djoh...@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
> z007...@bcfreenet.seflin.lib.fl.us
>
John A Hughes
In article <gwinn-23079...@smc19.ed.ray.com>,
Joe Gwinn <gw...@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
Jon S Anthony
> 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
sys...@niuhep.physics.niu.edu
stei...@maroon.tc.umn.edu (Andrew J Steinbach) writes:
>Darin Johnson (djoh...@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
>stei...@maroon.tc.umn.edu
Ralph Silverman
Darin Johnson (djoh...@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.
John A Hughes
In article <4t49om$e...@epx.cis.umn.edu>,
>: 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?).
>
>invalid and stupid. Now swallow everything we feed you, because it is
>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
Erik Seaberg
In article <tequila-2007...@tequila.interlog.com>,
Mark Eissler <teq...@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.
Andy Askey
djoh...@tartarus.ucsd.edu (Darin Johnson) wrote:
>gw...@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
>djoh...@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
aja...@gnn.com
++ robin
Carlos DeAngulo <cd...@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
>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.
Randy Kaelber
John A Hughes (j...@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: kael...@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.
Tim Behrendsen
Mark Eissler <teq...@interlog.com> wrote in article
<tequila-2007...@tequila.interlog.com>...
> Yes, but since just about everyone else has said something I'd say follow
> this path BASIC -> Pascal -> C -> C++ -> JAVA.
I think that is fine for the casual programmer. If you want to be
a professional programmer, I think this is the *best* course, but
not the easiest ...
Assembly -> C [non-GUI] -> C-GUI -> C++
All the rest of the languages are variations on the same theme.
Here's my rationale ...
Assembly: Learn what's *really* going on. The most important.
C: Learn structured programming. C is close enough
to assembly that a student can really *see* how the
compiler translates the code to assembly, and really
understand what languages are all about.
C-GUI: Learn the concept of event-driven programming (which
is all GUI is, stripped of the extraneous stuff).
C++: Even though I think C++ is brain damaged, it is
close enough to C that the student can see what OOP
really is in the context of, again, assembly
language. Assembly is without the "abstraction
bias" that other languages have. IMO, the only
thing OOP brings to the table is the concept of
assigning methods to areas of memory, AKA objects.
Non-OOP: Apply methods to memory. OOP: Execute
method abstractly bound to memory. All the rest
of the concepts of OOP derive from that. Obviously,
I'm speaking from a "reality" point of view, not from
the OO abstraction.
My point is there is nothing that is all that complicated
in computer science, if it can be expressed in the fundamental
components of programming, which are move, arithmetic, logicals,
test, and branch (might be something else I'm leaving out). If
a student is ground in these fundamentals, there is nothing else
they can't learn.
-- Tim Behrendsen (t...@airshields.com)
Mark Eissler
gw...@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
teq...@interlog.com | happening soon, I'm gonna http://www.interlog.com/~tequila/ | take up Yak farming!
Rick Elbers
"Tim Behrendsen" <t...@airshields.com> wrote:
>Mark Eissler <teq...@interlog.com> wrote in article
><tequila-2007...@tequila.interlog.com>...
>> Yes, but since just about everyone else has said something I'd say follow
>> this path BASIC -> Pascal -> C -> C++ -> JAVA.
>I think that is fine for the casual programmer. If you want to be
>a professional programmer, I think this is the *best* course, but
>not the easiest ...
>Assembly -> C [non-GUI] -> C-GUI -> C++
>All the rest of the languages are variations on the same theme.
>Here's my rationale ...
>Assembly: Learn what's *really* going on. The most important.
I fully agree, i did not get the *concept*( i do not mean just the
use) of pointers and reference down without an understanding of
Assembly. I wonder how other C++ ers do this ....
>C: Learn structured programming. C is close enough
> to assembly that a student can really *see* how the
> compiler translates the code to assembly, and really
> understand what languages are all about.
>C-GUI: Learn the concept of event-driven programming (which
> is all GUI is, stripped of the extraneous stuff).
>C++: Even though I think C++ is brain damaged, it is
> close enough to C that the student can see what OOP
> really is in the context of, again, assembly
> language. Assembly is without the "abstraction
> bias" that other languages have. IMO, the only
> thing OOP brings to the table is the concept of
> assigning methods to areas of memory, AKA objects.
> Non-OOP: Apply methods to memory. OOP: Execute
> method abstractly bound to memory. All the rest
> of the concepts of OOP derive from that. Obviously,
> I'm speaking from a "reality" point of view, not from
> the OO abstraction.
>My point is there is nothing that is all that complicated
>in computer science, if it can be expressed in the fundamental
>components of programming, which are move, arithmetic, logicals,
>test, and branch (might be something else I'm leaving out). If
>a student is ground in these fundamentals, there is nothing else
>they can't learn.
Yep this approach is IMHO the very best approach to understand almost
every *over-mystified* topic (though later on you might just switch
the other way around ..and considers "nothing compared......").
But when radically following this lead i think you can as well start
with BASIC to get the hunch ( while all the concepts of
branch,test,arithmic, move and logic are there also ...)
rick
>-- Tim Behrendsen (t...@airshields.com)
Rick Elbers
e-mail: rick....@tip.nl
J. Christian Blanchette
> >Assembly -> C [non-GUI] -> C-GUI -> C++
This is really crazy!
It's maybe interesting to understand how arguments are passed on the
stack, but i strongly believe that simple high-level languages must be
learned first, and more complex one after. Since there is a performance
vs. simplicity tradeoff all along, the performance desire (usually for
graphical applications) makes people learn lower level languages. I know
many people, including myself, who made the Basic/C step for
performances.
C must me learned before C++, that's a point since C++ is a really more
complex superset.
I see no reason why learning GUI programming before OOP: in my sense
they're not related at all. I've never did any GUI app, but the concept
of multiple entry points is easy to understand, as well as that of
object-orientedness (which can be found even in C programs, although
C++/Java are more adequate).
Understanding the machine architecture is one thing, using assembly
languages is another. There's no real interest in knowing all the
mnemonics of a peculiar assembly language for a C coder: knowing how
stacks work or how system calls are performed is enough to make efficient
C programs.
Jas.
Mark Eissler
> "Tim Behrendsen" <t...@airshields.com> wrote:
>
> >Mark Eissler <teq...@interlog.com> wrote in article
> ><tequila-2007...@tequila.interlog.com>...
> >> Yes, but since just about everyone else has said something I'd say follow
> >> this path BASIC -> Pascal -> C -> C++ -> JAVA.
>
> >I think that is fine for the casual programmer. If you want to be
> >a professional programmer, I think this is the *best* course, but
> >not the easiest ...
>
> >Assembly -> C [non-GUI] -> C-GUI -> C++
>
> >All the rest of the languages are variations on the same theme.
I would still argue that some form of BASIC should be taken as a
preliminary step to any programming. Going from nothing into Assembly is
suicidal. Something as simple as a loop tends to appear 8 billion times
more complicated than the same thing in BASIC. Not only that, but you
can't argue that ASM isn't more cryptic than any high level language.
Although I've only dabbled in Assembly (I do intend to crack this beast!),
I don't think it's a great starting point. Possibly a next step. Structure
will be more clear learned from BASIC (writing sequentially executed
programs). ASM code looks like it jumps around an awful lot (because it
does).
I think it can be agreed, though, that learning to program is a
progression. You can't just pick up one book one day and expect to write
the next killer app the day after.
My first programming experiences began with a ZX-81 about 15 or 16 years
ago. I must have learned at least 4 or 5 different interpretations of
BASIC after that before moving on to dBASE, C (got confused), Pascal
(needed it to understand the developer docs. provided by Apple for the
Mac), C again (Pascal knowledge helped me real big with this), C++. I'm
still dealing with C++ right now. Plan to learn JAVA next (don't feel too
pressured though) and want to get back into learning ASM. I think I might
add Ada to my list of things to do.
I guess there are arguments that you don't need to learn a billion
languages in order to learn how to program. Having spent a great deal of
time learning this (without too much formal instruction -- 'cause I
really suck at the math courses they always make mandatory at
Universities) I think the progression from one language to the next has
only helped me.
Robert Dewar
Tim recommends
"Assembly -> C [non-GUI] -> C-GUI -> C++
All the rest of the languages are variations on the same theme.
Here's my rationale ...
Assembly: Learn what's *really* going on. The most important."
I strongly disagree. A student treading this path will have a hard time
learning what abstraction is all about. Teaching abstraction is the
biggest challenge in teaching at an elementary level. It is possible
to recover from a (mis)education that follows the path above, but
very difficult for most people.
Robert Dewar
iJas says
"C must me learned before C++, that's a point since C++ is a really more
complex superset."
This is a mistake. Learning C before C++ makes it hard to understand
what C++ is all about. I still see huge quantities of C++ code clealry
written by C programmers, and it is basically C++ written in C style.
It is much more effective to teach C++ first, at an appropriate level
of abstraction, and then later on you can introduce the low level
features of C++ that are inherited from C, and are occasionally
appropriate for low level code.
Ralph Silverman
Randy Kaelber (kael...@avian.dars.muohio.edu) wrote:
--
*************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
z007...@bcfreenet.seflin.lib.fl.us
Tim Behrendsen
J. Christian Blanchette <jbl...@ivic.qc.ca> wrote in article
<31FBC5...@ivic.qc.ca>...
> > >Assembly -> C [non-GUI] -> C-GUI -> C++
>
>
> It's maybe interesting to understand how arguments are passed on the
> stack, but i strongly believe that simple high-level languages must be
> learned first, and more complex one after. Since there is a performance
> vs. simplicity tradeoff all along, the performance desire (usually for
> graphical applications) makes people learn lower level languages. I know
> many people, including myself, who made the Basic/C step for
> performances.
The point isn't that your actually going to use it day-to-day, the point is
really understand what's going on in terms of the fundamentals. People
who program in C who do not understand assembly are dangerous
because they don't truly understand what the compiler is producing.
> I see no reason why learning GUI programming before OOP: in my sense
> they're not related at all. I've never did any GUI app, but the concept
> of multiple entry points is easy to understand, as well as that of
> object-orientedness (which can be found even in C programs, although
> C++/Java are more adequate).
I could go either way on this one; I chose GUI first because the student
can
understand event-driven programming without the added baggage of OOP
abstractions.
> Understanding the machine architecture is one thing, using assembly
> languages is another. There's no real interest in knowing all the
> mnemonics of a peculiar assembly language for a C coder: knowing how
> stacks work or how system calls are performed is enough to make efficient
> C programs.
The point isn't to learn a specific one; I don't that really matters. The
student needs *something* to play on. The point is to see what's really
going on, to see the bytes flow in and out of memory locations, to really
experience that it's only a big table of bytes that you're moving around.
The most important thing any student can learn is the stripping away
of the shroud of abstractions, and seeing the simplicity of what's
really underneath. Once they get that, all the rest of it comes naturally.
-- Tim Behrendsen (t...@airshields.com)
Tim Behrendsen
Robert Dewar <de...@cs.nyu.edu> wrote in article
<dewar.838609515@schonberg>...
> Tim recommends
>
> "Assembly -> C [non-GUI] -> C-GUI -> C++
>
> Here's my rationale ...
>
> Assembly: Learn what's *really* going on. The most important."
>
> I strongly disagree. A student treading this path will have a hard time
> learning what abstraction is all about. Teaching abstraction is the
> biggest challenge in teaching at an elementary level. It is possible
> to recover from a (mis)education that follows the path above, but
> very difficult for most people.
I arrived at this conclusion based on the students that were coming
to me to be hired. I give a standard test to all my applicants that
tests two primary attributes,
1) How well they understand what's *really* going on; the best
programmers have a solid foundation.
2) How well the can take a problem they've (probably) never seen
before and generate a solution.
I was shocked at the results. I had people with Masters and
Doctorates who were completely incapable of creating new solutions
that they had never seen before. I had people, with *degrees* now,
tell me "convert argument to binary" as one of the steps on a
logical operation problem! The latter are people who are ground
in the "abstraction" of an integer, but are completely clueless
that the computer works in binary. How can a student get a
full-blown degree, and not understand a computer works in binary?
It's like graduating someone with a writing degree who is
illiterate.
This is what convinced me that our CS education is being done
completely wrong. I've said this before [excuse my repetition];
it would be as if EE students were taught IC design in the first
course, and were only given resisters, capacitors, ohm's law,
etc. in their senior year, almost as an afterthought!
Bottom line, a student cannot fundamentally understand an
abstraction until they understand the abstraction
in terms of the fundamental components of programming; again:
Move, Arithmetic, Test, Branch, and Logicals.
CS is currently taught the way you describe. Why do you think
it's so hard to teach abstractions at the elementary level?
It's because the students get so wrapped up in the fancy
terminology, they don't see that its really all smoke and
mirrors, and the concepts are very, very basic. If it's
expressed in fundamental ways, it's very easy to see what
abstractions are really saying in *real* terms.
I have seen it! Teaching CS the way you describe it is
producing brain damage of the highest degree.
-- Tim Behrendsen (t...@airshields.com)
Arra Avakian
In article <01bb7da2$6c505ac0$96ee6fcf@timhome2>, "Tim Behrendsen" <t...@airshields.com> wrote:
..
>The most important thing any student can learn is the stripping away
>of the shroud of abstractions, and seeing the simplicity of what's
>really underneath. Once they get that, all the rest of it comes naturally.
>
I can see both sides of this issue: the importance of understanding
abstractions, and the importance of understanding what is underneath.
I think that a programmer needs to have a model of how a computation occurs in
order to understand issues such as time and space efficiency of the
computation. On the other hand, understanding the abstractions presented by
both language constructs and by APIs is absolutely critical to being able to
deal with complex systems. A curriculum that does not accomplish the learning
of computing abstractions fails. Its hard for me to judge the "best" approach
for someone learning now, when I have had the experience of learning gradually
over a lifetime.
I learned programming in the summer between my freshman and sophomore years in
high school (1960!!). I was taught two "languages" that summer: IBM 1620
assembly language and FORTRAN II. I do recall being mystified and puzzled by
the concept of how FORTRAN source code could "execute", but could readily
"grok" how a dumb machine could blindly execute machine code. It wasn't until
I understood the concepts behind a compiler that the mystery faded and I could
accept the abstraction of FORTRAN. What is interesting in hindsight was that
the concept of an assembler did not cause any mystification - its role as a
translator was "obvious", but the role of a compiler was definitely not
obvious. The foundation of understanding the concepts of a stored program
computer was essential for me to understand anything else.
I still to this day need to understand the execution model of an abstraction
in order to "really" understand it. I guess my character is to be suspicious
of the mystery, and not be able to take it on "faith".
Arra Avakian
Intermetrics, Inc.
733 Concord Avenue
Cambridge, Massachusetts 02138
USA
(617) 661-1840
ar...@inmet.com
Tim Behrendsen
> 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 (t...@airshields.com)
Paul Campbell
>>>>>>
I was shocked at the results. I had people with Masters and
Doctorates who were completely incapable of creating new solutions
that they had never seen before. I had people, with *degrees* now,
tell me "convert argument to binary" as one of the steps on a
logical operation problem! The latter are people who are ground
in the "abstraction" of an integer, but are completely clueless
that the computer works in binary. How can a student get a
full-blown degree, and not understand a computer works in binary?
It's like graduating someone with a writing degree who is
illiterate.
<<<<<<<
We have had CS students on placement here after 2 years of study who
didn't even understand hexedecimal !.
Paul C.
UK.