Quoth Nadav Har'El on Fri, Jun 06, 2003:
> On Fri, Jun 06, 2003, Vadim Vygonets wrote about "C flame (was: FS/OS in schools)":
> > > Actually, yes, it's the best programming language to teach the basic
> > > concepts of programming and computer-science. (in my opinion).
> >
> > Pascal?
>
> I know Pascal well, and I actually used it a lot and liked it, so I won't
> argue with you - Pascal is indeed a good language for teaching programming.
> However, I still think C is better. Especially if those kids end up actually
> using what they've learnt in real projects, and especially if you talk about
> "standard pascal" (whatever that was) which was missing a lot of features
> people have come to expect from C (Brian Kernighan even wrote once a paper
> called "Why Pascal is not my favorite programming language).
I quite agree with that paper. However, I'm trying to make a
point that even for real life projects C is seldom the best
choice. It's often the best choise available for technical
reasons, like availability of compilers, which makes it the
language of choice for most projects.
> Maybe Pascal has made some sort of huge leap forward since, I don't know.
I don't think so.
> > Too much of "no magic" isn't good either. It's great that C
> > teaches you pointers, but it's not so great that you need to use
> > pointers for call-by-reference (is it the correct terminology?).
> > Memory allocation in C is too low-level, which results in more
>
> I argue that these *are* good things to teach, because this is what
> the call-by-reference and garbage collection in more complex languages
> end up doing anyway.
Function calls with change of value of a variable may be
implemented differently, e.g. like in Forth (you leave the value
on the stack, and a different value returns to you on the stack).
Even if your way to achieve this is to pass the variables by
reference, you don't need to use pointers explicitly (indeed,
Pascal uses "var" and C++ uses reference ("&"), which is the
same as address ("*") except of the syntax).
Memory allocation is, of course, important, but why not go all
the way and abandon malloc(3) and free(3) in favour of sbrk(2),
or even use assembly? Indeed, there are University courses that
teach exactly those things, but I don't think that suffering
strengthens the soul outside of the scope of these courses.
> Let's face it, when you teach someone to drive its enough to teach them
> to use the pedals and the steering-wheel. But when you teach someone to
> become a mechanic, you have no option but showing them what the engine
> looks like by opening the hood, even if it's an ugly, greasy, mess.
Teach it, then. But don't make it the central part of your
doctrine. The reason that assembly languages were abandoned for
most tasks in favour of higher level languages was to minimize
messing with low level stuff like moving bytes from memory to
registers and concentrate at the task at hand. C is not high
level enough for most real life programming tasks, it seems.
Herouth has addressed this point beautifully.
> > memory leaks in C programs than in comparably complex programs in
> > other languages. Strings in C are not a first-class type, which
> > means that you need to work with them almost manually, peeking
> > the characters from within the string.
>
> Pascal has an even worse implementation of strings (the length of the
> string was part of the type, last time I used Pascal!)...
Indeed, Pascal sucks as well in this respect.
> Anyway, C is
> not a convenient string-processing language, I admit. I never said it
> is the only language that should be learnt - languages like AWK and Perl
> are much more convenient for writing simple text-processing programs.
True. AWK, however, is not powerful enough for most tasks
(although I use it a lot in shell scripts), and Perl is a
syntactic disaster.
> > Pascal. I would never dream of writing a real program in Pascal,
> > but it's a good functional programming language for students, one
> > of the reason being that the student can concentrate on learning
> > concepts instead of fighting with pointers and memory allocation
> > when it's not needed.
>
> Please remind me - how does Pascal make it easy not to "fight with pointers
> and memory allocation"?? Last time I checked, pascal did not have any
> notion of garbage collection, and had both pointers and memory allocation
But you don't use pointers and memory allocation nearly as much.
> (not needed for strings, true, but in C you also don't need memory allocation
> for strings if you always used fixed-length arrays!).
Yes, Pascal is not the best language, and using it for variable
length arrays is damn impossible.
> If you want a language with no concept whatsoever of dynamic memory
> allocation, try Fortran 77 :) However, this is a copout: if a language
> does not have memory allocation, it doesn't mean this feature isn't
> necessary in real-life, as any seasoned Fortran programmer can tell you...
A language may be designed to require less explicit memory
allocation (by making strings first class variables of variable
length, for example), and use of this feature may be made easier.
> > No. As I wrote in my response to Amos, it will stay because it's
> > taught everywhere. Also, UNIX with its language xenophoby (one
> > word: libc) makes sure C stays as long as UNIX stays (yes,
> > Bourne^H^H^H^H^H^HPOSIX shell will stay too).
>
> I disagree that Unix forces people to use C.
The only portable way to do system calls is via libc, which
requires C-style argument passing and C-style strings in function
calls, which means that to access many system features from other
languages, you need to implement them in C first. Example: many
Perl packages from CPAN have C code in them. Not to mention that
almost all compilers and interpreters in UNIX are written in C ;)
> I know a number of people
> that use UNIX and the only programming language they know is Fortran.
I wonder how opening network sockets is implemented in Fortran,
and at what level the influence of C starts showing through.
> I know a number of other people who only use C++.
C++ is *almost* as good as C in UNIX, because all C libraries are
accessible from C++ for free (except the magic wrapper lines in
header files). But it means you use C-like function calls from
within C++, and don't get class-based API for these packages.
Again, how do you open a network socket from C++? bind(2),
connect(2) and such, right? I would expect something like:
sock = new Socket("remote.host", "smtp");
> Other people avoid all
> of these and use Perl or Python.
I'm not familiar with Python, and I mentioned Perl's dependence
on C above.
> Knuth wrote TeX in Pascal :)
Yes, that's weird.
> People continue to use C because, frankly, it's better at what it's being
> used for.
People continue to use C because they don't know better. Or
because they don't have any better on their platform.
> This is also why C succeeded in the first place,
It was quite good for 1980, don't you agree?
> and why it ended
> up replacing Pascal as a teaching language in the Technion, for example.
Well... Pascal is inappropriate for teaching operating systems
course, it doesn't have lex and yacc (another C centrism in UNIX)
which are nice to have for compilers course, it doesn't has GL
which is oh so beneficial for 3D graphics course, etc., which is
not the fault of the language per se, but rather that of the
environment (well, not "fault" as such, but a "feature" of UNIX,
or what have you there).
> > These examples don't show the essence of Forth (which is quite
> > interesting), but they show a couple of things in C that we
> > consider for granted in programming languages, apparently without
> > a good reason.
>
> For a useful language similar to Forth, how about learning Postscript?
> I'm not joking. It's actually more interesting than it sounds (and the book
> is available freely on the net).
Yes, I might consider that, but I will consider Lisp first. BTW,
I learned Forth while playing with the FreeBSD boot loader, and
learned to appreciate its minimalism and ability. I don't quite
grok it yet, sadly.
Vadik.
--
If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?
-- Tom Cargill, C++ Journal, Fall 1990.
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
