On Scheme Programmers

The biggest thing I learned in that thread is that Schemers know what the truth
is, and as a result have an inferiority complex which manifests itself when
someone merely mentions a feature of Lisp that is not present in Scheme. Such a
mention is instantly interpreted as a flaming attack. This is simply evidence
that they know what the truth is, but simply refuse to accept it.

Rational debate is difficult with Schemers, because their positions tend to be
undefined and contradictory. They believe the lack of functionality in the
language as a virtue---Lisp is said to have a lot of unneeded ``cruft'' in it.
But then it comes to light that Scheme implementations have their own
ad hoc imitations of some of this cruft, which Schemers are happy to use in
their programs, at the cost of portability. They believe that they are still
programming in Scheme, when much of the code is written in an implementation's
dialect. The term Scheme is elastic, undefined. It would be nice to be able
to get them to commit to a definition of ``Scheme'' that is as precise as the
meaning of ``Common Lisp''.

Schemers prefer to believe in some unspecificed notions like ``purity'',
instead of reasoning from facts. It's important to them to have a *feeling*
that they are working with something pure, determined by some arbitrary
emotional standard.

I suspect that, demographically, Schemers are simply a younger, dumber crowd.
That is, if we had a histogram breaking down Lispers and Schemers by age, the
Scheme one would be fatter in the younger years. This is the natural
consequence of Scheme having been flogged at Universities.
Moreover, people are drawn to programming tools according to their
personalities and maturity. Inferior tools naturally attract only those people
who are not able to think clearly and boldly enough to recognize inferiority,
and name it for what it is. The culture that forms around tools consists of
those people whom those tools are able to attract and captivate. When people
change, they move on, and are replaced by an influx of replacements who inherit
their discarded attitudes; so what is observed is that the cultures appear
static, despite membership turnover.

It has been my consistent observation that immature programmers revel in
undefined concepts like simplicity and purity. They like small languages, and
don't mind reinventing wheels and building complex things from scratch. The
effort of continuous reinventing somehow justifies the saving of effort from
not having to initially absorb a larger set of axioms. The justification is,
they can do it better than anyone who came before them, so those extra axioms
are worthless anyway! To convince themselves that they can do it better,
despite not being any smarter than their predecessors, they resort to the
argument that they are more ``in touch'' with the current world and its
technology. Whatever they do is better simply because it is modern, and it is
modern simply because it is more recent. A binary tree module written in C
yesterday is exciting and new. An equivalent one from eighteen years ago is
antiquated crud. This is a form of denial, an emotional response to the pain
that comes from knowing that someone did it eighteen years ago just as well,
and that he would laugh at the modern reinvention effort.

Moreover, immature programmers don't appreciate the role of precise
specifications and standards; to specify an interface or behavior means to code
it. If two or more groups implement a common specification, they are simply
wasting their time doing redundant, ungratifying, inferior work. Those people
must be mechanical drones if they need someone to specify to them how something
should work; real programmers never work from someone else's designs, they just
sit down and crank out the system according to their whims. Also, they don't
interface with specifications, they interface with implementations. The
implementation is always right, so why bother with documents? If requirements
are imposed on these programmers, they must never be so precise that they can't
be loosely interpreted or tweaked to suit their tastes. Something as precise as
a programming language standard is so abhorrent, so that if there must be a
standard, it must be the smallest possible document. Nobody has the right to
impose a precise design on someone else; there must always be room left for the
human element: esthetic taste, creative interpretation, the license to
cull or embelish.

The biggest thing I learned in that thread is that C Programmers know what the truth
is, and as a result have an inferiority complex which manifests itself when
someone merely mentions a feature of C++ that is not present in C. Such a
mention is instantly interpreted as a flaming attack. This is simply evidence
that they know what the truth is, but simply refuse to accept it.

Rational debate is difficult with C Programmers, because their positions tend to be
undefined and contradictory. They believe the lack of functionality in the
language as a virtue-- C++ is said to have a lot of unneeded ``cruft'' in it.
But then it comes to light that C implementations have their own
ad hoc imitations of some of this cruft(such as GNU extensions), which C Programmers are happy to use in
their programs, at the cost of portability. They believe that they are still
programming in C, when much of the code is written in an implementation's
dialect. The term C is elastic, implementation-defined. It would be nice to be able
to get them to commit to a definition of ``C'' that is as precise as the
meaning of ``Standard C++ ''.

C Programmers prefer to believe in some unspecificed notions like ``purity'',
instead of reasoning from facts. It's important to them to have a *feeling*
that they are working with something pure, determined by some arbitrary
emotional standard.

I suspect that, demographically, C Programmers are simply a younger, dumber crowd.
That is, if we had a histogram breaking down C++ and C Programmers by age, the
C one would be fatter in the younger years. This is the natural
consequence of C having been flogged at Universities.
Moreover, people are drawn to programming tools according to their
personalities and maturity. Inferior tools naturally attract only those people
who are not able to think clearly and boldly enough to recognize inferiority,
and name it for what it is. The culture that forms around tools consists of
those people whom those tools are able to attract and captivate. When people
change, they move on, and are replaced by an influx of replacements who inherit
their discarded attitudes; so what is observed is that the cultures appear
static, despite membership turnover.

It has been my consistent observation that immature programmers revel in
undefined concepts like simplicity and purity. They like small languages, and
don't mind reinventing wheels and building complex things from scratch. The
effort of continuous reinventing somehow justifies the saving of effort from
not having to initially absorb a larger set of axioms. The justification is,
they can do it better than anyone who came before them, so those extra axioms
are worthless anyway! To convince themselves that they can do it better,
despite not being any smarter than their predecessors, they resort to the
argument that they are more ``in touch'' with the current world and its
technology. Whatever they do is better simply because it is modern, and it is
modern simply because it is more recent. A binary tree module written in C
yesterday is exciting and new. An equivalent one from eighteen years ago is
antiquated crud. This is a form of denial, an emotional response to the pain
that comes from knowing that someone did it eighteen years ago just as well,
and that he would laugh at the modern reinvention effort.

Moreover, immature programmers don't appreciate the role of precise
specifications and standards; to specify an interface or behavior means to code
it. If two or more groups implement a common specification, they are simply
wasting their time doing redundant, ungratifying, inferior work. Those people
must be mechanical drones if they need someone to specify to them how something
should work; real programmers never work from someone else's designs, they just
sit down and crank out the system according to their whims. Also, they don't
interface with specifications, they interface with implementations. The
implementation is always right, so why bother with documents? If requirements
are imposed on these programmers, they must never be so precise that they can't
be loosely interpreted or tweaked to suit their tastes. Something as precise as
a programming language standard is so abhorrent, so that if there must be a
standard, it must be the smallest possible document. Nobody has the right to
impose a precise design on someone else; there must always be room left for the
human element: aesthetic taste, creative interpretation, the license to
cull or embelish.