Mail Archives: djgpp/2000/01/02/10:54:07
Eli Zaretskii wrote:
>
> On Sat, 1 Jan 2000, bowman wrote:
>
> > >Does anyone know of a more basic, freeware
> > >compiler that I could try?
> >
> > http://www.hitech.com.au/products/pacific.html
>
> How is this easier than DJGPP? The installation instructions sound a lot
> like ours.
>
> > If you find Pacific too difficult, you might want to look at Python,
> > which is an excellent first language, as well as a very useful tool
> > in general.
>
> I'm not sure it is wise to introduce the issue of ``the first language''
> into this thread ;-). If we do, there are many more choices to consider
> beyond C and Python.
Also, we should distinguish 'ease of setup' from 'ease of using the
tools' from 'ease of learning to program in the language' from 'ease of
programming in the language'.
With the zip picker, setting up DJGPP is just a matter of unzip less
than a dozen files, and defining one environment variable. I don't
think you can make the process simpler than that. That's the easiness
of setup of DJGPP.
With an editor of your choice (Emacs and vi are hinted), most of the
beginner's books example programs can be handled in an
edit->compile->execution loop:
+ Edit should always succede.
+ Compile is just a matter of issuing 'gcc myprog.c', and you either
succede with an executable A.EXE or you fail with an error message
telling you which lines are wrong in your program. Now you compare the
program you typed in with the one printed in the book to see if they are
the same. If they are not, you correct your program. If they are the
same, then it's the book's fault! Try another book.
+ Execute A.EXE should either succede with the intended effect or fail
with the wrong result or with a crash, in which case you compare your
code with the one in the book, etc., ...
That's the easiness of learning.
I don't think you can make the process any easier for a compiled
language. The read->eval->print loop of an interpretted language might
be easier (hance Python?)
That's the easiness of using the tools.
C/C++ loses out to almost any other language in the 'learning to program
in the language' department. An impatient student will usually deviate
from the book and get obscure error messages immediately which he's not
capable of interpreting for days. A patient student with follow the
book more closely and never put a line of code in his program that he
doesn't understand. He would actually *READ* the book and not let a
single detail escape his scrutiny. Either way, it will take a long time
to learn to program in C/C++, and he will be rewarded amply at the end.
By 'ease of programming in the language' I mean the relative easiness of
achieving your objectives in a programming project, not programming with
the fewest keystrokes, or in the shorted amount of time. Beginners are
not usually affect by this aspect. However they should be aware that C
is most often the language of choice of library writters. There is
rarely a thing that can be done in another language yet cannot be done
in C.
A mistake teacher's usually make is trying to 'get the setup out of the
way so that the students can concentrate on using the tools', yet they
do this by making the actual set up more complicated and therefore more
error prone.
Another one is 'get using the tools out of the way so that the student
can concentrate on learning the language', yet they do this by making
the mechanics of using to tool seemingly simpler but not providing
enough of the underlying support system so that when something do go
wrong the student is at a loss.
For me, 'primitive with understanding' is better than 'user friendly
with magic'. After all, the students are learning to become a
*PROGRAMMER*.
--
Weiqi Gao
weiqigao AT a DOT crl DOT com
- Raw text -