A: These kinds of 
"real-programmers" statements often reflect what
is called self-over-others attitude, and they are a part of a kind
of a programming lore or cult. Basically, these attitudes waive the
simple fact that one should select one's tools according to the task
at hand, not vice versa. On the other hand one's productivity is
usually best when being able to use tools which one is familiar and
comfortable with. (Note however that the real-programmer's lore is
not really interested in producing results.)
   In very rough terms there are two attitudes to programming
languages. They can be seen as tools for writing applications, or
(by surprisingly many) as ends themselves.
   If we first look at standard Pascal (versus Turbo Pascal),
considering the language primary and its usage secondary is 
common.
This results from the history of Pascal, since as we all know it was
originally meant as a means for teaching programming concepts, 
not
at all for writing applications. But because Pascal turned out to be
useful also for writing applications, it has been extended for some
operating systems, most notably MS-DOS (Turbo Pascal) and 
VAX/VMS
(VAX Pascal). Both remedy a lot of flaws from the application
programmer's point of view. Most importantly they have a true file
I/O interface, and enhanced string handling. Turbo Pascal (the 
more
generic of these two) clearly draws from the structure and ideas of
advanced BASICs (and vice versa). While in standard Pascal the
language is an end by itself, for Turbo Pascal the only relevant
issue is its usefulness for writing applications.
   One problem that one encounters when moving away from 
standard
Pascal is the problem of portability. This is a truly serious
problem, since most often extensive rewriting is necessary from
converting say Turbo Pascal to, say, Unix Pascal. I have taken 
Unix
Pascal as the extreme example, since Unix Pascal is almost 
nothing
but the standard Pascal having no useful file I/O.
   If one considers C, its best aspect from applications point of
view is portability, and its strength for system programming. But it
is not an easy language to learn. Proponents of C also often have
the tendency discussed above, that is seeing the language as
primary, and its utilization as secondary. Now why this tendency,
not only for C, but in general? I've had the opportunity of writing
programs starting from the late 1960's, and one observation I have
made, and often propounded the view is that it is not writing code
that is the really difficult part. What is really difficult it is
coming up with good and original ideas for programs to write. I see
applications as primary, and the tools as secondary. As to Turbo
Pascal, I've written in many languages (including Cobol, Fortran,
several Basics and Pascals, and command languages) and I like 
Turbo
Pascal because it is one of the most convenient and flexible tools
for writing the kind of applications that I usually write and
distribute for the Public Domain. That is I use Turbo Pascal 
because
I'm comfortable with it in writing applications, and have thus
gathered a very useful modular library for it over the years, not
because of any inherent value attached to Turbo Pascal per se.

 A2: Another, a 
somewhat resembling line is made up by the arguments
about standards in Pascal which were recycled in the late
comp.lang.pascal time after time. Very often they end up with
purists vs pragmatists arguing about the true or imaginary viles of
using GOTOs. I find all this somewhat futile, although I understand
the academic nature of the background. As you'll recall, Pascal 
was
first developed for academic teaching programming concepts, not 
for
any practical programming. That came later, and the ensuing
popularity of Pascal in practical applications must have come as 
a
surprise way back then. I admit being biased in not sympathizing
with Pascal standard stalwarts. I am far more interested in getting
the job done than in defending a barren orthodoxy.
   Since Turbo Pascal version 7.0 introduced the 
"break" and
"continue" keywords to handle jumps in loops, GOTOs 
are much easier
to avoid without undue complications.