Beware of "C" Hackers -- A rebuttal to Bertrand Meyer
Robert Martin
Success". I would like to say that I have a great deal of respect for
Meyer. Moreover, I have read many good things in this book so far.
However I take extreme exception to something he wrote in this book.
On page 91 he writes the following which is included in its entirety.
I will comment on it afterwards.
-------------------------------------------------------------------------
PRUDENT HIRING PRINCIPLE: Beware of C hackers.
A "C hacker" is somewone who has had too much practice writing
low-level C software and making use of all the special techniques and
tricks permitted by that language.
Why single out C? First, interestingly enough, one seldom hears about
Pascal hackers, Ada hackers or Modula hackers. C, which since the
late nineteen-seventies has spread rapidly throughought the computing
community, especially in the USA, typifies a theology of computing
where the Computer is the central deity and its altar reads
Efficiency. Everything is sacrificed to low-level performance, and
programs are built in terms of addresses, words, memory cells,
pointers, manual memory allocation and deallocation, unsafe type
conversions, signals and similar machine-oriented constructs. In this
almost monotheist cult, where the Microsecond and the Kilobyte
complete the trinity, there is little room for such idols of software
engineering as Readability, Provability and Extendibility.
Not surprisingly, former believers need a serious debriefing before
they can rejoin the rest of the computing community and its progress
towards more modern forms of software development.
The above principle does not say "Stay away from C hackers", which
would show lack of faith in the human aptitude to betterment. There
have indeed been cases of former C hackers who became born-again O-O
developers. But in general you should be cautious about including C
hackers in your projects, as they are often the ones who have the most
trouble adapting to the abstraction-based form of software development
that object technology embodies.
----------------------------------------------------------------------
There is only one word that can accurately describe these sentiments.
That word is biggotry. I don't like to use a word like that to
describe the words of someone who is obviously intelligent. Yet
there is no other option. The words he has written create a class of
people whom he recommends ought to be hired, only with caution.
Who are these "C Hackers"? Has Dr. Meyer given us any means to
identify them? Yes.
A "C hacker" is somewone who has had too much
practice writing low-level C software and making
use of all the special techniques and tricks
permitted by that language.
What possible recourse can a manager have but to look with prejudice
against anyone who happens to put "C" on their resume. By associating
"C" with "Hackers", Dr. Meyer damages everyone who uses that language,
whether they are hackers are not. In effect, Dr. Meyer is making a
statement that is equivalent to: "Beware of the Thieving Frenchmen."
What is a hacker? A hacker is someone who writes computer programs
without employing sound principles of software engineering. Someone who
simply throws code together without thought to structure or lifecycle.
Certainly there are hackers who use C. But there are Hackers who use
every language. And in this, Dr. Meyer is quite negligent, for he says
nearly the opposite:
Why single out C? First, interestingly enough,
one seldom hears about Pascal hackers, Ada hackers
or Modula hackers.
This may or may not be true, I have no statistics. However, *if* it is
true I would be willing to bet that the reason has something to do with
the difference in the number of C programmers as compared to Ada, Pascal
and Modula programmers. If there are 20 times as many C programmers,
then there are probably 20 times as many C hackers.
My point is that C does not predispose someone to be a hacker. And that
the ratio of C hackers to C programmers is probably the same as Ada
hackers to Ada programmers.
So Dr. Meyer casts aspersions upon all C programmers while giving
amnesty to Ada, Pascal and Modula programmers. According to Dr. Meyer,
it is only, or especially, the "C hacker" that you must be wary of. He
does not say: "Beware of Hackers", rather he says: "Beware of C
hackers." And this is simply biggotry, the segregation and defamation
of a class of people based only upon the language that the program in.
And why this malevolence towards C? One can only conjecture. He offers
reasons, but they are nearly mystical in their descriptions. Consider:
C [...] typifies a theology of computing where the
Computer is the central deity and its altar reads
Efficiency.
Dr. Meyer does not provide any proof, or even a scrap of evidence to
support this rediculous claim. He states it as fact. This is an abuse
of authority. What every author fears, (or ought to fear in my opinion)
is that he cast his own opinions as unalterable truth. Yet, rather than
proceed with trepdiation, Dr. Meyer seems to glory in his deprication of
C. His writing becomes almost frenzied as he attacks it.
Everything is sacrificed to low-level performance,
and programs are built in terms of addresses,
words, memory cells, pointers, manual memory
allocation and deallocation, unsafe type
conversions, signals and similar machine-oriented
constructs. In this almost monotheist cult, where
the Microsecond and the Kilobyte complete the
trinity, there is little room for such idols of
software engineering as Readability, Provability
and Extendibility.
Here he names every evil trick and bad practice that he can, and
ascribes it all to C, as though no other language had the capability of
supporting bad practices. He also claims that C programmers religiously
follow these bad practices as the sacrements of their religion.
These statements are extremely irresponsible. There is no basis of fact
that Dr. Meyer has supplied for these extreme accusations and
defamations. Dr. Meyer has a right to dislike C if he chooses. But his
vehemence against its programmers is unreasonable, and unreasoned.
It is easy to refute nearly all of Dr. Meyer's claims regarding C
programmers. I have known many many C programmers who were very
concerned with good software engineering. Who considered the quest for
ulimate efficiency to be absurd. Who were careful with their
programming practices. In fact, I have never met a single C programmer
who fits the description that Dr. Meyer ascribes to them all.
In my opinion, he is very wrong, not only professionally, but moraly.
And he owes the industry an apology and a retraction.
--
Robert Martin | Design Consulting | Training courses offered:
Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
2080 Cranbrook Rd. | Tel: (708) 918-1004 | Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.
Jim Fleming
>
>I have recently acquired a copy of Bertrand Meyer's new book "Object
>Success". I would like to say that I have a great deal of respect for
>Meyer. Moreover, I have read many good things in this book so far.
>
So far so good...
BTW...Dr. Bertrand Meyer is probably one of the most *abused* people in
the OO community. He is also probably one of the most intelligent,
experienced, prolific, readable, and *successful*. It is a shame that
the OO community has not given him more recognition and it is also a
shame that *some* members of the OO community have not been required
either by law or their companies to issue public statements of apology
to Dr. Meyer.
@@@@@@
RM>However I take extreme exception to something he wrote in this book.
RM[snip]
RM
RM>In my opinion, he is very wrong, not only professionally, but moraly.
RM>And he owes the industry an apology and a retraction.
RM>
RM>--
RM>Robert Martin | Design Consulting | Training courses offered:
@@@@@@
I started out to write a detailed response to the [snipped] posting. I
have decided that it is not worth the time and/or energy.
@@@@@@
Aside from the above...
There is something clearly wrong in the OO industry and especially in
the C++ community.
My theory is that, "C++ has WON", and now it must deliver!!!!
The pressures must be enormous. The liabilities incurred from recommending
C++ must be massive by this time. I believe that what we are seeing is a
situation where C++ advocates are now trying to make good on their OO
promises and they are coming up short. This probably makes for a certain
amount of frustration and instead of admitting they were wrong (and now
liable for their recommendations) they instead turn to the world as a
punching bag.
For the past 15 years, I have watched the C++ community grow from a few
advocates to a mob of zealots. I have personally been attacked by that
mob on several occasions. Recently, one posting on Usenet has resulted
in a significant loss of business for myself and my companies. Despite
this event, I try to push on, to move forward, to write code, to write
documentation and to attempt to earn a living.
I have often wondered what it must be like for Betrand Meyer to try to
live and work in this environment where open hostility is encouraged,
where large companies support people that breed these hostilities, and
where our government clearly has very little ability to monitor or control
this type of hostility. (If you do not believe me, talk to the FBI some
time, they make "brilliant" suggestions like "get a new phone number", or
"find another line of work".)
I wonder if the day will ever come, when everyone that has been abused
by the C++ community assembles at the doors of some institution or
government agency and demands compensation. If that occurred, I wonder
how fast the abusers would scatter like the wind and claim that they were
not involved.
We are approaching the Fourth of July here in the United States. This
should be a time of celebration. Maybe we can use this event as a turning
point. Maybe we can try to get the OO industry moving and try to recover
some of the years that have been lost because of stupid language wars.
Hang in there Betrand...we are not dead yet...!!!
@@@@@@@@@@@@@
--
Jim Fleming /|\ Unir Corporation Unir Technology, Inc.
j...@tiger.bytes.com / | \ One Naperville Plaza 184 Shuman Blvd. #100
%Techno Cat I / | \ Naperville, IL 60563 Naperville, IL 60563
East End, Tortola |____|___\ 1-708-505-5801 1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX) 1-708-305-0600
\__/-------\__/ http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|
Murray J. Root
His attack (as perceived by R.Martin and others) was on 'C'. A BIG difference.
From his article, and his response to R.Martin's post, it is QUITE CLEAR that
'C' was the ONLY target of his comments, and only a subset of the 'C'
programming community, at that.
[>==========Jim Fleming, 7/3/95==========
[>
----entire post cut as it did not seem relevant to R.Martin's post nor
B.Meyer's book----
***************************************************************
AT&T Global Information Solutions would probably disavow any knowledge of
this, if they had any knowledge of this. Look for press releases to get the
official opinion.
For a change - THINK!
***************************************************************
Igor Chudov @ home
* Relax. A little dissent will spice up your life. You are not out
* of a job yet. And if you hire programmers, check that they know C
* as well as something else. But take my word for it: beware of
* C hackers.
Well, we mignt take a look at it from another point of view: C, not C++,
Eiffel, Pascal or Ada is the lingua franca of computer programming. Far
too many programming concepts are expressed in C, and far too many
essential, totally portable libraries, programs and operating systems
have been written in C.
It would be a big mistake to hire a programmer who does _not_ know C.
Also, the word "hacker" is abused and misused in this discussion,
because originally it means a person who wants to go into details of
computer and other systems and know more than s/he is supposed to.
Luckily, nearly every programmer is a C programmer anyway.
--
- Igor. (My opinions only) http://www.galstar.com/~ichudov/index.html
For public PGP key, finger me or send email with Subject "send pgp key"
Dave Griffiths
>
>Relax. A little dissent will spice up your life. You are not out
And also beware of academics who have had little commercial experience. You
say "everything is sacrificed to low-level performance". There are plenty of
situations where people _needlessly_ try to optimize their code. But there
are plenty of other cases where the performance of the code is absolutely
vital. I've made money from being employed _specifically_ to speed up
programs! It's a huge problem out here in the real world.
Dave
Bertrand Meyer
``Object Success'' and do not quite understand why he chose to
pick a fight. (I am also assiduous enough as a news reader to know
that no one, ever, anywhere, has had the last word in a discussion
with Mr. Martin, and have no hope of breaking that tradition; in
fact I expect to give up right after this message, but not without
having publicly expressed my admiration for
his inexhaustible net-energy.)
As the extract from ``Object Success'' quite clearly shows, my advice
is to beware of C hackers, not C programmers in general. I am certainly
not the first person to have noticed that C is a low-level language
that promotes machine-oriented thinking. This is in fact rather
a cliche in the software community. It does not mean that
you cannot do excellent programming in C; there are many examples
of that. It does mean that C does not share the high-level,
abstraction-oriented, safe, stronlgy typed approach of many
other modern programming languages.
I have often observed that there is a category of C programmers
(often including people that have used no other language) that
have been so influenced by this machine-oriented approach that
they have trouble adapting to ``programming by abstraction'',
also known as object technology. Those are the ones which
the extract from ``Object Success'' that offended Mr. Martin
calls ``C hackers'', and of course they are a small subset of
the set of C programmers, as the book makes clear.
In the chapter from which the extract is taken, I was discussing
the somewhat amazing observation that, in my relatively long
experience of teaching O-O techniques, I have found it
essentially impossible to identify specific categories
of people that could not ``make it'' and become talented O-O
designers. It is in fact incredible to see the diversity of
backgrounds that can lead to this skill, from theoretical physics
to career-long Cobol programming. But from my own observations and,
more importantly, from talking with other managers, there seems
to be an exception to this rule: a small number of people who had
done too much C hacking to be quite ready for more modern views
of software development without retraining. I am certainly not
the only one to have made this observation, and although I don't
want to engage in name-dropping I can testify to have heard it
confirmed by very famous people in the software industry.
[For an incisive criticism of C, read ``Type Syntax in the Language
C: An Object Lesson in Syntactic Innovation'' by Bruce Anderson
in the book ``Comparing & Assessing Programming Languages''
by Feuer and Gehani, eds., Prentice Hall, 1984. This is also
where you will find ``Why Pascal Is Not My Favorite Programming
Language'', an entertaining critique by Brian Kernighan of C fame
whom no one, as far as I know, has yet accused of moral indignity.]
Since my book is a compendium of practical advice for managers
in companies that are transitioning to object technology, it was
my duty to pass on my best cautionary advice, even if some of it
is unpopular. (Not all of it is, I hope.)
Mr. Martin accuses me of harming the career of the unfortunate people
who are careless enough to admit on their resume that they know
C (subjecting themselves, it would seem, to a new version of the
famous question: ``Are you now, or have you ever been...?'').
This is again flattering; it assumes that Mr. Martin sees
my book as becoming soon the primary universal reference for all
software managers, and with all my heart I hope that he is right.
But even then his compassion for those esteemable engineers whose
careers I will have broken is perhaps a bit exaggerated. My note
was about C hackers, not C programmers in general. Everyone has
C on his resume these days; actually if I was applying
for a programming job I would probably put C on my resume.
(After all I can explain the difference between int*x[] and
int(*x)[] - I think.) And I certainly expect any programmer who is
a candidate for any programming job today to know C.
But that's not the same thing as being a C hacker - someone
whose entire view of the programming world is defined by
low-level C manipulations. I am sure that Mr. Martin, who if I
understand properly is also a manager, would also want to
stay away from such people.
It would be absurd to deny that the extraordinary success of
C reflects some real qualities of that language, and it is
not difficult to list these qualities. But along with these
qualities are a number of major deficiencies, especially
if you apply to C what we know today about software development.
To say so is not insulting; after all C dates back to 1968 or
so, and how many 1968 languages are still alive (and thriving)
to be criticized? I am not the only one to have stated
the obvious comment that C is a portable assembly language, the
modern realization (this is for readers who like to
browse through very old issues of the Communications of the
ACM) of what used to be called UNCOL - UNiversal COmputer Language.
Viewed in that way it can be extremely useful: everyone (including
object-oriented programmers) needs low-level mechanism to interface
with the hardware and the operating system. But as a language
for building large, reliable, extendible software systems -
sorry, thanks, but no thanks.
It is really surprising to see how thin-skinned some representatives
of the C/C++ community are. In hardly more than a decade C has all
but erased everything else. It dominates the software scene like no
other language in the history of computing - Fortran, Cobol, PL/I,
Basic, Pascal never even came close. Yet every time someone timidly
suggests that maybe, just maybe, this is not the ideal solution for
eternity, the screams of sacrilege start again.
Relax. A little dissent will spice up your life. You are not out
of a job yet. And if you hire programmers, check that they know C
as well as something else. But take my word for it: beware of
C hackers.
--
Bertrand Meyer, ISE Inc., Santa Barbara
805-685-1006, fax 805-685-6869, <bert...@eiffel.com>
Web home page: http://www.eiffel.com
ftp://eiffel.com
Redestination REAL Soon Now
| For the past 15 years, I have watched the C++ community grow from a few
| advocates to a mob of zealots. I have personally been attacked by that
| mob on several occasions. Recently, one posting on Usenet has resulted
| in a significant loss of business for myself and my companies. Despite
| this event, I try to push on, to move forward, to write code, to write
| documentation and to attempt to earn a living.
Off topic for this thread, but I have seen you complain like
this a number of times and finally had to react. If you have
been involved in this 'scene' for 15 years I am surprised that
you are surprised by the reaction you received to numerous
negative posts to comp.lang.c++ and comp.std.c++. Spam
generates spam. You put an 800 number in your spam, how could
people resist a free way to spam you in return?
I'm not saying that your posts are good or bad, I actually like
sifting through all of them for the occasional item of interest.
And it is fun to see the ruling class taken to task. But you
can't have your cake and eat it too.
Scott Wheeler
>I have recently acquired a copy of Bertrand Meyer's new book "Object
>Success". I would like to say that I have a great deal of respect for
>Meyer. Moreover, I have read many good things in this book so far.
>
>However I take extreme exception to something he wrote in this book.
>On page 91 he writes the following which is included in its entirety.
>I will comment on it afterwards.
This sort of comment in books reflects badly on the credibility of the
author's other statements, but I think it does little damage to C
programmers. Like you, I've seen huge amounts of solid, working C code.
What I haven't seen is performance-tuned bit-bashing (except in one
part of a real-time system I wrote myself, where it was justified).
When an author flames a language known to be effective, I doubt the
author. When I first came across Meyer's views on C and C++ in OOSWC, I
set the book aside for several months as it seemed so ill-informed on
that subject that I imagined there was little to learn from the book -
unfortunate, as I later found that apart from this region of
non-linearity, Meyer has much to contribute. I suppose it's just a
question of getting used to some of the "greats" being as prone to
hobby-horses as the rest of us.
BTW, I wish non-C people would drop the "portable assembler" tag as well.
C can be used as a portable assembler (as in ISE Eiffel, or early C++
compilers, or a multitude of pre-processors), but this is not its
normal use. It can be used for bit-bashing, but this use is even rarer.
The code one normally sees in the wild is perfectly normal structured
programming, which could be done (more labouriously) in Pascal or Modula.
I suggest that a better description is "RISC language", a description that
BM uses for his own Eiffel.
Scott
Jonathan Edwards
Bertrand Meyer <bert...@eiffel.com> wrote:
[Response to Robert Martin]
Isn't this really a cloaked attack on C++?
And isn't that what really bothers Mr. Martin?
Two (perhaps the major two) design goals of C++ were linguistic and performance
compatibility with C.
If C is too machine-level and demonstrates a pathological concern with
efficiency, then C++ is infected with the same disease.
I don't think there is really much disagreement about this fact, just about
whether it is a positive or negative fact.
>It is really surprising to see how thin-skinned some representatives
>of the C/C++ community are. In hardly more than a decade C has all
>but erased everything else. It dominates the software scene like no
>other language in the history of computing - Fortran, Cobol, PL/I,
>Basic, Pascal never even came close. Yet every time someone timidly
>suggests that maybe, just maybe, this is not the ideal solution for
>eternity, the screams of sacrilege start again.
I think you are giving up too easily.
It comes as a shock to most people that in fact the dominant programming
language in the world is COBOL. Counted either by lines of code in production
or number of employed programmers, COBOL blows everything else away.
C/C++ is dominant only in "mind-share". It dominates in marketing
budgets and number of trees consumed by printing presses. The only segment
of software where it really dominates is shrink-wrapped mass-market software.
That is but the tip of the software iceberg. It is significant in revenue,
but not in lines of code, numbers of programmers, numbers of products
or companies.
While all right-thinking people are aghast that C++ seems to be taking over
the world, in fact it has a long way to go. And I think it highly unlikely that
C++ will supplant COBOL. It would be hard to imagine a language worse suited
to the task. Visual Basic is a far more likely contender (The MS-DOS of
programming languages).
Smalltalk seems like the only reasonable language with a shot (sorry, Bertrand)
--
Jonathan Edwards edw...@intranet.com
IntraNet, Inc 617-527-7020
One Gateway Center FAX: 617-527-6779
Newton, MA 02158
Richard A Gams
I am sympathetic with Robert Martin's position but I have some sympathy with
Dr. Meyer as well. Consider the most recent Dr. Dobbs in which Walter
Bright, the original author of the Symantec compiler, writes about "Optimizing
C++ Code." He suggests that we avoid exception handling, virtual functions,
virtual base classes, destructors, multiple inheritance, and built in memory
allocators using new and delete. He advises us to write programs so as to
optimize "page space accesses."
I am a long time C++ convert from C who is happy to leave such details as "page
space access" encapsulated in a well written framework. I am thinking about
dumping one compiler for another because of a more complete and current
implementation of C++ language features. These new features seem just the ones
that are discouraged by Walter Bright. Is he a "C hacker" or am I wrong to
want to use these new features?
-- Dick
Richard van de Stadt
>In article <3t8192$b...@espresso.internet-cafe.com>,
[...]
>It comes as a shock to most people that in fact the dominant programming
>language in the world is COBOL. Counted either by lines of code in production
>or number of employed programmers, COBOL blows everything else away.
This is no miracle, considering the number of lines of code one needs to
implement what can be done with much less code in most other languages.
In order to write all these lines of code, one needs lots of programmers...
Richard.
---
<A HREF="http://wwwtrese.cs.utwente.nl">TRESE WWW Server</A>
Rick Smith
book "Object Success" where Bertrand states:
PRUDENT HIRING PRINCIPLE: Beware of C hackers.
Visionary people sound excessively opinionated. Anything I can remember
reading from a language designer seemed quite strongly posititoned. I
imagine if language designers were open to every little thing, there is
no way they could design a language. Things I have read from Dr. Meyer
have come across to me as strongly opinionated. However, Robert calling
Bertrand "biggotted" seems too strong for the comment regarding his
statements about C hackers.
I have no statistics either, but I know exactly who Dr. Meyer is talking
about. I call them speed freaks. They always look at the assembly
generated, tweak the C until better assembly comes forth. And not
looking beyond. I agree with another responder's comments that in
the real world we need speed. We make printers, and try to squeeze
all we can out of the cheapest processor possible. That is the only way
to keep the price down. I'm pretty good at doing the speed freak thing.
I have increased performance 20% by hacking C to give better assembly.
I've also increased subsystem performance 100% by choosing a different
data layout. That is, all of my large speed gain has been done at the
language independent level. And OO modeling has helped me at that level.
I agree that the speed freak hackers are a small portion of C programmers,
but the comments of Dr. Meyer are congruent with my experience. I have
seen a fear with abstraction because they feel a loss of power and skill.
Dr. Meyer wrote:
> But from my own observations and, more importantly, from talking with
> other managers, there seems to be an exception to this rule: a small
> number of people who had done too much C hacking to be quite ready for
> more modern views of software development without retraining.
The training is essential to restore the feeling of control of what is
going on. Without the training, my experience has been one of arguments.
With training, my experience has been interacting with a good designer
with a broad foundation.
I have found that C programmers who weren't in the speed freak class were
more open to accepting an interface that was laid out using abstraction.
The speed freaks would make internal data structures global and directly
access struct members. The small speed up in performance made it too
expensive to alter the data model to be able to obtain a larger speed
up. This is how I interpret the warning given by Dr. Meyer. Simply
"beware".
--
Rick Smith my experience, not those of HP in general
HP San Diego
Robert Martin
>I am flattered that Robert Martin has read in detail my book
>``Object Success'' and do not quite understand why he chose to
>pick a fight. (I am also assiduous enough as a news reader to know
>that no one, ever, anywhere, has had the last word in a discussion
>with Mr. Martin, and have no hope of breaking that tradition; in
>fact I expect to give up right after this message, but not without
>having publicly expressed my admiration for
>his inexhaustible net-energy.)
Thanks for granting me the priviledge of the last word. I will, of
course, accept. However, I would like to note for the record that I
do not always get the last word in my net arguments. Case in point,
the "Princiciples of OOD #2 thread" which I am not only observing.
(It's kind of like watching the game of life).
>As the extract from ``Object Success'' quite clearly shows, my advice
>is to beware of C hackers, not C programmers in general. I am certainly
>not the first person to have noticed that C is a low-level language
>that promotes machine-oriented thinking. This is in fact rather
>a cliche in the software community. It does not mean that
>you cannot do excellent programming in C; there are many examples
>of that. It does mean that C does not share the high-level,
>abstraction-oriented, safe, stronlgy typed approach of many
>other modern programming languages.
This kind of consideration is what was missing from your book. The
statements in your book were far more intense and all inclusive. So
I consider the words you have written here as a retraction of the
*tone* of your book. The fact that you admit that there are many
examples of excellent programming in C, is a relief to me. I wish you
had said so in your book.
>I have often observed that there is a category of C programmers
>(often including people that have used no other language) that
>have been so influenced by this machine-oriented approach that
>they have trouble adapting to ``programming by abstraction'',
>also known as object technology. Those are the ones which
>the extract from ``Object Success'' that offended Mr. Martin
>calls ``C hackers'', and of course they are a small subset of
>the set of C programmers, as the book makes clear.
No, the book does not make this clear. That was my problem. Not even
the slightest intimation of the concept of a "small subset" is present
in the book. On the contrary there are strong implications (e.g. the
"theology" argument) that C leads all its programmers into hackery. A
statement that you do not back up with fact.
>It is really surprising to see how thin-skinned some representatives
>of the C/C++ community are. In hardly more than a decade C has all
>but erased everything else. It dominates the software scene like no
>other language in the history of computing - Fortran, Cobol, PL/I,
>Basic, Pascal never even came close. Yet every time someone timidly
>suggests that maybe, just maybe, this is not the ideal solution for
>eternity, the screams of sacrilege start again.
Had you simply attacked C, I would not have responded. Rather, you
attacked the characters of people. This required a response.
Harley Davis
I have often wondered what it must be like for Betrand Meyer to try to
live and work in this environment where open hostility is encouraged,
where large companies support people that breed these hostilities, and
where our government clearly has very little ability to monitor or control
this type of hostility. (If you do not believe me, talk to the FBI some
time, they make "brilliant" suggestions like "get a new phone number", or
"find another line of work".)
I'm glad to see that all the money we in the C++ community have been
funneling into the various law enforcement agencies has not gone to
waste! I think they deserve a big bonus this month.
-- Harley Davis
--
------------------------------------------------------------------------------
Harley Davis net: da...@ilog.fr
Ilog S.A. tel: +33 1 46 63 66 66
2 Avenue Galliéni, BP 85 fax: +33 1 46 63 15 82
94253 Gentilly Cedex, France url: http://www.ilog.com/
Kenneth Oksanen
rma...@rcmcon.com (Robert Martin) writes:
>What is a hacker? A hacker is someone who writes computer programs
>without employing sound principles of software engineering. Someone who
>simply throws code together without thought to structure or lifecycle.
The Hacker Jargon file gives a very different definition, this is from
3.0.0:
:hacker: [originally, someone who makes furniture with an axe] n.
1. A person who enjoys exploring the details of programmable
systems and how to stretch their capabilities, as opposed to most
users, who prefer to learn only the minimum necessary. 2. One who
programs enthusiastically (even obsessively) or who enjoys
programming rather than just theorizing about programming. 3. A
person capable of appreciating {hack value}. 4. A person who is
good at programming quickly. 5. An expert at a particular program,
or one who frequently does work using it or on it; as in `a UNIX
hacker'. (Definitions 1 through 5 are correlated, and people who
fit them congregate.) 6. An expert or enthusiast of any kind. One
might be an astronomy hacker, for example. 7. One who enjoys the
intellectual challenge of creatively overcoming or circumventing
limitations. 8. [deprecated] A malicious meddler who tries to
discover sensitive information by poking around. Hence `password
hacker', `network hacker'. The correct term is {cracker}.
The term `hacker' also tends to connote membership in the global
community defined by the net (see {network, the} and
{Internet address}). It also implies that the person described
is seen to subscribe to some version of the hacker ethic (see
{hacker ethic, the}.
It is better to be described as a hacker by others than to describe
oneself that way. Hackers consider themselves something of an
elite (a meritocracy based on ability), though one to which new
members are gladly welcome. There is thus a certain ego
satisfaction to be had in identifying yourself as a hacker (but if
you claim to be one and are not, you'll quickly be labeled
{bogus}). See also {wannabee}.
-=-
; Kenneth Oksanen, email: ce...@cs.hut.fi, http://www.cs.hut.fi/~cessu
((lambda(a) (a a((lambda(a)(lambda()(set! a(+ a 1))a))1)))(lambda(a c)
((lambda(b) (newline)(write b)(a a((lambda(c)(lambda()(c c)))(lambda(a)
((lambda(c) (if(=(modulo c b)0)(a a)c))(c))))))(c)))) ; Scheme me!
Paul Hepworth
> There is only one word that can accurately describe these sentiments.
> That word is biggotry. I don't like to use a word like that to
> describe the words of someone who is obviously intelligent. Yet
> there is no other option. The words he has written create a class of
> people whom he recommends ought to be hired, only with caution.
[ hundreds more protestations snipped ]
He doth protest too much, methinks!
Paul
Steve Clamage
>In article <3t8192$b...@espresso.internet-cafe.com>,
>Bertrand Meyer <bert...@eiffel.com> wrote:
>[Response to Robert Martin]
>
>Isn't this really a cloaked attack on C++?
It sounds like you didn't read Meyer's statement. It was not an attack
on C or on C++, but on the mentality found in some C programmers whom
he characterises as "hackers".
>If C is too machine-level and demonstrates a pathological concern with
>efficiency, then C++ is infected with the same disease.
Once again, the subject is not the C (or any particular) language, but a
mind-set which considers only the machine representation of the program,
ignoring portability, readability, and maintainability.
I have taught C++ to classes containing such programmers. When you introduce
polymorphism, the first question is "Isn't a virtual function call awfully
expensive?" It takes considerable time (the "retraining" Meyer discussed)
to get past the concern with program speed and size as the very first,
and perhaps only, consideration.
Of course program speed and size matter. But they are usually not the only
things which matter, and in many situations are rather low on the priority
list.
---
Steve Clamage, stephen...@eng.sun.com
Dr. Rich Artym
to rid the world from C as anything but an intermediate language for OO
translators. (:-) It must be said that not many would have noticed that
particular passage in Bertrand's book if Robert hadn't mentioned it ...
Come on guys, both of you write wonderfully excellent gems of wisdom on
occasion (as do many other people), and both of you are highly opinionated
(just like the rest of us), and both of you sometimes espouse viewpoints
that are clearly coloured by your particular camps --- no big deal, we all
do that. Separating the useful output from the less useful is a task at
which most of us are extremely proficient, fortunately.
Since both of you no doubt would agree that ad hoc coding with bad tools
by insufficiently competent people is very detrimental to the engineering
of quality software, it should be easy for you to reach an understanding.
I suggest that Bertrand simply states that the hacking mentality is bad for
software engineering, and that the lower the level of the language used,
the greater the likelihood that some hacking will result. He should also
state that this is a statistical observation (highly likely but nevertheless
unsubstantiated, unless he has the figures to prove it), and therefore has
the unmoveable quality of statistics but says nothing at all about specific
cases. Most importantly, he should also say that the passage in his book
was not intended to impune users of C as being hackers. Robert can then
agree with this, and to show goodwill, will note that C++ is lower-level
than Eiffel, and that C is lower-level than C++. That seems even-handed.
Then we can all go back to discussing the much more interesting issues
currently occupying us here, and which, incidentally are as relevant to
Eiffel as to C++, even when we're using Sather in the examples. Eiffel
and C++ are both very far from being silver bullets, and the insights of
both excellent gentlemen would be much appreciated in trying to advance
the state of OO understanding beyond that in existing implementations.
########### Dr. Rich Artym ================ PGP public key available
# galacta # Internet: ri...@galacta.demon.co.uk DNS 158.152.156.137
# ->demon # ri...@mail.g7exm[.uk].ampr.org DNS 44.131.164.1
# ->ampr # NTS/BBS : g7exm@gb7msw.#33.gbr.eu
# ->nexus # Fun : Unix, X, TCP/IP, OSI, kernel, O-O, C++, Soft/Eng
# ->NTS # More fun: Regional IP Coordinator Hertfordshire + N.London
########### Q'Quote : "Object type is a detail of its implementation."
Matthew Kennel
: >What if *I* wrote a book, and in it I said:
: >
: >this is | Managers, whatever you do, don't hire programmers who
: >simply an | admit to knowing Eiffel. Eiffel, as a language,
: >example and | poisons their minds. People who have been exposed to
: >does not | Eiffel, even for only a short time, believe that it is
: >reflect the | the only true language in the universe. Moreover,
: >opinion of | other languages, and the people who program in them,
: >the author. | make them physically ill. Thus, they won't be able to
: > | touch your legacy systems without fits of intense
: > | nausea.
: >
: >I think Dr. Meyer, or Ian Joyner, or one of the other notable
: >supporters of Eiffel would have a duty to step forward and rebut such
: >nonsense.
The equivalent passage would have to read: "Avoid programmers who have only
used Eiffel all their lives and do not see beyond it in the overall scheme
of business and engineering and refuse to attack practical problems out of
some odd pique of anal-retentive disgust. etc. etc."
I think Messrs. Meyer and Joyner and certainly myself would certainly
*agree* with those sentiments.
The original concern was about people who do NOT see beyond C, not all those
ever exposed to it. There was *never* any implication that people exposed to
C, even for a short time, are forever tainted. The original passage
said something like "too much time" programming only C.
Too much for what? Too much to get any wider perspective, that's what.
Dr. Meyer was saying that in his actual empirical observations,
this can be a problem.
Given the predominance of C, it's very unlikely that there are many Ada
'hackers' or CLOS 'hackers' or Eiffel 'hackers' who have never once used C,
whereas there are some of these "C hackers" who in fact do NOT have a wiser
view. This set is NOT by any means the total set of C programmers, or even
the set of people who program in C most of the time.
: >Robert Martin | Design Consulting | Training courses offered:
: >Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
: >2080 Cranbrook Rd. | Tel: (708) 918-1004 | Mgt. Overview of OOT
: >Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.
: This is precisely the impression I get by reading the quote from Dr.
: Meyer's book, and even from his followup newsgroup response.
I didn't.
: If C is deeply flawed (as Dr. Meyer seems to feel) then it's a short
: leap of logic to believe that C programmers (excuse me, I mean "C
: hackers") are deeply flawed.
Dr. Meyer's point is that C is flawed for what he wants to do, and presumably
what the people in his audience want to do. Using C does not, by itself,
encourage more sophisticated views of software that he cares about, so that
there may be, *among* those who have lived only C, people who are not
sympathetic to those views. He said that in his experience they
do exist and to watch out for those.
: The notion that people are somehow corrupted by the tools they use is a
: complete fallacy. What is state-of-the-art today will become an object
: of ridicule in the future. If Dr. Meyer doesn't realize this, he no
: doubt will in the not-to-distant future when Eiffel becomes a niche
: legacy language.
: --
: Jerry Fitzpatrick Consulting and Training for
: Red Mountain Corporation Software Architecture and Quality
: 1795 N. Fry Rd, Suite 329 (including C / C++ / OOA / OOD)
: Katy Texas USA 77449 Phone/Fax: 713-578-8174
cheers
Matt
Robb Nebbe
: edw...@world.std.com (Jonathan Edwards) wrote:
: >In article <3t8192$b...@espresso.internet-cafe.com>,
: [...]
: >language in the world is COBOL. Counted either by lines of code in production
: >or number of employed programmers, COBOL blows everything else away.
: This is no miracle, considering the number of lines of code one needs to
: implement what can be done with much less code in most other languages.
: In order to write all these lines of code, one needs lots of programmers...
I have never met a programmer that was limited by his typing speed.
The idea behind lines of code is that somehow this measures the
intellectual effort behind writing the code. 10 lines of COBOL may
very well represent the same intellectual effort as 4 lines of C.
When you try and understand the code the 10 lines may very well be
clearer than the 4. It is certainly possible to write more lines of
code with less effort in one language as compared to another.
Robb Nebbe
Michael Schweitzer
A historical comment:
ISE's Eiffel compiler was implemented in C - until, as far as I
know, versions 3.x. The first Eiffel/S compiler (1.0) was imple-
mented in C and, again, as far as I know, the current Tower com-
piler is implemented in C. C is and, I believe, will be, the lingua
franca of the computer business. It's simply the only 'universally'
available language - you can get a compiler for it on almost all
platforms and you can do almost everything with it - from low-
level programming to high-level programming. There are definitely
more substancial commerical programs out there written in C than
in Eiffel - and I can't imagine that it is possible to write
any 'movable' Eiffel software without the help of 'C'.
About hackers:
In my professional career I've seen a lot of bad C code, written
by what you may call C-hackers - but I've also seen a lot of bad
Eiffel code - written by OO-hackers. After all, you can write
bad code in any language - even in Eiffel!
About learning:
Sometimes I get the feeling that the Eiffel dogma is: everything
that counts is the abstraction, the class interface. If you take
a closer look on some of the 'professional' Eiffel libraries then
you will find that they have nice (inter)faces but the implementation
is just a nightmare (I once saw a class PRIMES which had a very
nice interface but the _worst possible_ implementation). Here their's
much to learn from C-programmers (hackers?): the actual implementation
is equally well as important as the interface - there's no substitute
for good algorithms. Performance is not a matter of 'low-level-mani-
pulations' it's a matter of sound scientific education - if you don't
know how to compute, e.g., a minimal spanning tree of a graph effi-
ciently, then neither your C-solution nor your Eiffel-solution will
perform adequately.
Summary:
The Eiffel dogma, spread by Bertrand and others, that the interface
is everything, the implementation is nothing, is plain wrong. And I
must say that the C dogma is not: the implementation is everything,
the interface is nothing. An Eiffel class is (re-)usabale only if it
has a good interface and a good implementation. A nice interface and
an impressive class hierarchy is not useful by itself - after all,
the implementation counts. It's the implementation which actually
performs the computation - not the interface. Classification as
l'art pour l'art is totally useless: Software isn't reusable
if it isn't usable (to solve a given problem efficiently) in the
first place. C-programmers may have a temptation to focus on the
'efficiency' aspect, but Eiffel programmers, on the other hand, may
have a tendency to focus on the 'interface' aspect - both is in-
adequate: software has to be well specified _and_ implemented
efficiently. Or would you be satisfied with a class which adverises
some sort of 'sortedness' which, after closer inspection, is im-
plemented with bubble-sort? Ok, OO-hackers would say : "one of
the strengths of OO is that you can inherit from a badly (in
your opinion) implemented class and supply a better implementation
in the descendant" - well (reusable ???) ...
Regards,
Michael Schweitzer
p.s.: Don't get me wrong: I'm responsible for the Eiffel/S compiler
and I definitely support Eiffel, but I've not lost sight -
I have the deepest respect for K&R and all the 'C-hackers'
who provided us with wonderful tools, (less) wonderful OS's
etc. who, in a nutshell, made it all happen. Can you imagine
that we were able to exchange our ideas worldwide without
the 'terrible' language C? I can't.
SwisSoft, Michael Schweitzer Geismar Landstr. 16 D-37083 Goettingen
Fax : +49 551 770 35 44 email : eif...@swissoft.h.provi.de
Neil Wilson
: I suggest that a better description [for C] is "RISC language", a description that
'C' is a language that has three types of loop, two ways of doing an
'if', two ways of sequencing instructions and three types of goto
statement. I would suggest that RISC is a somewhat inappropriate
term.
--
Neil Wilson (N.Wi...@geog.leeds.ac.uk) "nil illigitimi carborundum"
Information Modelling Programme, Leeds, UK
Alun Da Penguin Jones
>>What is a hacker? A hacker is someone who writes computer programs
>>without employing sound principles of software engineering. Someone who
>>simply throws code together without thought to structure or lifecycle.
>
Poor definition.
>both). In the programming world, the biggest assholes are the
>"hacker" types who basically don't give a damn that you will have to
>maintain their excrement for years to come. There really should be
>prison terms for these programmers.
Likewise there should be a prison term for people who hijack words.
Cheers,
Alun.
--
$_='\=*Sxw!jds@j$.jl.dt#Rw%^dcn"K1x(=Bl1nwl!\*1enab^h"F=!J$h%fhcq',
tr&J-ZA-Ij-za-i&A-Za-z&&s&\(&logic&&&s&\*&un&g&s&=&al&g&s&\^&it&g&&
s&%&st&g&&s&\$&ber&g&s&\#&\n&&s&"& of&g,s&([A-Z])& $1&g&&s&\\u&U&&&
s&!&es, &g&s&\\a&A&&s&1&i&g&&print" $_\n";sub liminal{"use perl!";}
Martin Cracauer
>I am sympathetic with Robert Martin's position but I have some sympathy with
>Dr. Meyer as well. Consider the most recent Dr. Dobbs in which Walter
>Bright, the original author of the Symantec compiler, writes about "Optimizing
>C++ Code." He suggests that we avoid exception handling, virtual functions,
>virtual base classes, destructors, multiple inheritance, and built in memory
^^^^^^^^^^^^^^^^^^^^
This at least is not true. For non-virtual functions, MI cannot slow
down code. Every C++ virtual function implementation I know of handles
MI anyway. Maybe they're a bit slower therefore, but given such a
compiler you don't spped up code by limiting to single inheritance.
>allocators using new and delete. He advises us to write programs so as to
>optimize "page space accesses."
>I am a long time C++ convert from C who is happy to leave such details as "page
>space access" encapsulated in a well written framework. I am thinking about
>dumping one compiler for another because of a more complete and current
>implementation of C++ language features. These new features seem just the ones
>that are discouraged by Walter Bright. Is he a "C hacker" or am I wrong to
>want to use these new features?
He is performance-oriented and names some C++ features that have
runtime overhead. However, that doesn't mean these features are
useless. A virtual function usually reselbles some kind of if()
statement. If it doesn't, you can bind statically.
AFAIK, exceptions are the only C++ feature that can cause an overall
slowdown with current implementations. I'm not sure whether this can
be avoided by better compilers.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@wavehh.hanse.de>. No NeXTMail, please.
Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a
private address. At (netless) work programming in data analysis.
Robert Martin
>In article <3t8192$b...@espresso.internet-cafe.com>,
>Bertrand Meyer <bert...@eiffel.com> wrote:
>[Response to Robert Martin]
>Isn't this really a cloaked attack on C++?
>And isn't that what really bothers Mr. Martin?
No.
What bothers me is that Dr. Meyer was attacking a class of people, not
a language. He is a well known author, and his book will have a wide
distribution. And his book is full of very good stuff. But in the
midst of all this he makes the recommendation to managers that they
not hire C hackers.
What if *I* wrote a book, and in it I said:
this is | Managers, whatever you do, don't hire programmers who
simply an | admit to knowing Eiffel. Eiffel, as a language, poisons
example and | their minds. People who have been exposed to Eiffel, even
does not | for only a short time, believe that it is the only true
relfect the | language in the universe. Moreover, other languages,
opinion of | and the people who program in them, make them
the author. | physically ill. Thus, they won't be able to touch
| your legacy systems without fits of intense nausea.
I think Dr. Meyer, or Ian Joyner, or one of the other notable
supporters of Eiffel would have a duty to step forward and rebut such
nonsense.
--
Robert Martin
>Rabid worship of C increases the probabilty the person is a hacker.
>Why? The basic tenents of C culture are anti-software engineering.
I refer you to the "The C Programming Language" by Kernighan and
Ritchie (any edition) for a good example of the counter view. The
authors are very sensitive to software engineering principles, and
stress them throughout the book.
If there is such a think as "C culture" (which I doubt) then I, and
most of my associates must be members of that culture. And we have
been concerned about software engineering principles for the last 20
years.
It is always dangerous to create classes (e.g. "C culture) into which
you can insert groups of people based upon a simple attribute. It
leads to wrong conclusions. i.e. software engineering principles are
antithetical to "C" culture, thus all C programmers are hackers.
In my direct experience, nothing is further from the truth.
Robert Cragie
: Rabid worship of C increases the probabilty the person is a hacker.
: Why? The basic tenents of C culture are anti-software engineering.
I don't entirely agree with this. C is a very flexible language, and can
be written neatly, but it requires a lot of self-discipline. However...
: (1) C makes low level code extremely easy to create and the C culture
: says that low level code is cool.
: (2) Many C programmers follow these bad practices.
Low level code is efficient. Speed tweaking is very common. But even this
can be done neatly. The irony is that a competent C programmer _can_ produce
neat, efficient, and _readable_ code.
: I have met tons of C hackers / software incompetents.
This is where there is a big difference between a competent C programmer,
and a 'clever dick' C programmer. Both are experienced, and know C well.
But the latter thinks it smart to write code as unreadable and terse as
possible. C allows both. It also doesn't really discipline an incompetent
programmer either.
: I don't really understand this defense of the "character" of people.
: In my cynical view most people are either "assholes" or "idiots" (or
: both). In the programming world, the biggest assholes are the
: "hacker" types who basically don't give a damn that you will have to
: maintain their excrement for years to come. There really should be
: prison terms for these programmers.
Too right! I am also sick and tired of 'clever dick' programmers.
These are sad people. BTW, I also generally agree with Dr. Meyer.
Jerry Fitzpatrick
writes:
>
>I have recently acquired a copy of Bertrand Meyer's new book "Object
>Success". I would like to say that I have a great deal of respect for
>Meyer. Moreover, I have read many good things in this book so far.
>
>However I take extreme exception to something he wrote in this book.
>On page 91 he writes the following which is included in its entirety.
>I will comment on it afterwards.
>
--
>PRUDENT HIRING PRINCIPLE: Beware of C hackers.
>
>low-level C software and making use of all the special techniques and
>tricks permitted by that language.
>
>Why single out C? First, interestingly enough, one seldom hears about
>Pascal hackers, Ada hackers or Modula hackers. C, which since the
>late nineteen-seventies has spread rapidly throughought the computing
>community, especially in the USA, typifies a theology of computing
>where the Computer is the central deity and its altar reads
>Efficiency. Everything is sacrificed to low-level performance, and
>programs are built in terms of addresses, words, memory cells,
>pointers, manual memory allocation and deallocation, unsafe type
>conversions, signals and similar machine-oriented constructs. In this
>almost monotheist cult, where the Microsecond and the Kilobyte
>complete the trinity, there is little room for such idols of software
>engineering as Readability, Provability and Extendibility.
>
>Not surprisingly, former believers need a serious debriefing before
>they can rejoin the rest of the computing community and its progress
>towards more modern forms of software development.
>
>The above principle does not say "Stay away from C hackers", which
>would show lack of faith in the human aptitude to betterment. There
>have indeed been cases of former C hackers who became born-again O-O
>developers. But in general you should be cautious about including C
>hackers in your projects, as they are often the ones who have the most
>trouble adapting to the abstraction-based form of software development
>that object technology embodies.
>----------------------------------------------------------------------
>
> [snip]
>
>Robert Martin | Design Consulting | Training courses offered:
>Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
>2080 Cranbrook Rd. | Tel: (708) 918-1004 | Mgt. Overview of OOT
>Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.
I am concerned about Dr. Meyer's use of language here.
The term "hacker" with its obvious negative connotation would have been
sufficient to make his point. To single out C as the preferred hacker
language promotes a ridiculous stereotype. But then to prattle on at
length about "C hacker" cultism, deities, and brainwashing is simply
demeaning and unnecessary.
Although the tone of Dr. Meyer's rebuttal to Bob Martin's posting is
less zealous, he still reiterates that we should "Beware of the C
hacker". Clearly, he does not recognize (or care to admit) the
demeaning and stereotypical nature of these warnings. This sounds no
different to me than the ill-conceived advice some people give about
minorities, other cultures, or the opposite sex. Bah!
If the statement being made were "Beware of the female hacker" it would
be clear to most people that the complaint was about females, not
hackers. Clearly, it is the C language that Dr. Meyer is complaining
about, and our recognition of that has nothing to do with being overly
sensitive.
I seriously doubt if Dr. Meyer has conducted a scientific survey of
hacker language preferences. I'd be surprised if he has even attempted
an informal poll. (please correct me if I'm wrong) If so, then his
image of the "C hacker" is simply a personal belief having no basis in
fact. It seems to me that any "hacker" concerned about size or speed
will skip C in favor of assembly language in nanoseconds flat.
Dr. Meyer, you are certainly entitled to your opinion, but I'm afraid I
don't share it. Moreover, I'm disappointed that you would promote such
a jaundiced view in a technical book.
Thomas E Janzen
competent C hackers:
bit-twiddling anti-software-engineering types who hand-optimize code but
are good at it, and as a result write obscure unsupportable,
untestable code;
incompetent C hackers:
People who still write K&R I function definitions;
insert a goto every 300 lines;
have never heard of ANSI or ISO;
and just plain C hackers:
Can't show any traceable documents for reqs, specs, designs and test;
Have no test data;
Write almost no comments (or write joke comments);
Use C as a requirements definition language, a functional specification
language, and a design language;
Think that structured programming is passe` or a joke or both.
Use one-character identifiers.
This thread has helped me re-evaluate my bigotry against ex-scientists
who are hired to write software. I think that such an individual may
have demonstrated a commitment to developing themselves into commercial
software developers, but if they havn't, a person with 3 degrees in
science who starts working on commercial software is working on a
high-school diploma. If you were driving a semi with 2 heavily-loaded
trailors down the road towards a gorge, and a sign on the road said "the
next suspension bridge was the first design of a PhD in Biology who
changed careers; alternate route through gorge adds 40 miles", would you
take the bridge or the gorge route?
--
Tom Janzen - t...@world.std.com USA Distributed Real-Time Data Acquisition S/W
for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio
Jerry Fitzpatrick
writes:
>>What is a hacker? A hacker is someone who writes computer programs
>>without employing sound principles of software engineering. Someone
who
>>simply throws code together without thought to structure or
lifecycle.
>
>Good definition.
>
use
>> every language. And in this, Dr. Meyer is quite negligent, for he
says
>> nearly the opposite:
>
>> Why single out C? First, interestingly enough,
>> one seldom hears about Pascal hackers, Ada hackers
>> or Modula hackers.
>
is
>> true I would be willing to bet that the reason has something to do
with
>> the difference in the number of C programmers as compared to Ada,
Pascal
>> and Modula programmers. If there are 20 times as many C
programmers,
>> then there are probably 20 times as many C hackers.
>
>Oh come on! If you are libertarian lone cowboy hacker which language
>with its corresponding philosophy are you going to embrace, the macho
>culture of C or the protect you from yourself, nanny-istic, shove
>software engineering down your throat culture of Ada/Eiffel?
>C is a magnet to hacker types.
>
>> My point is that C does not predispose someone to be a hacker. And
that
>> the ratio of C hackers to C programmers is probably the same as Ada
>> hackers to Ada programmers.
>
>Rabid worship of C increases the probabilty the person is a hacker.
>Why? The basic tenents of C culture are anti-software engineering.
>
>> support this rediculous claim. He states it as fact. This is an
abuse
>> of authority. What every author fears, (or ought to fear in my
opinion)
>> is that he cast his own opinions as unalterable truth. Yet, rather
than
>> proceed with trepdiation, Dr. Meyer seems to glory in his
deprication of
>> C.
>
>As anybody in this field knows, proof (aka research study) is a
>red herring. The only ones who have the time to such research
>studies are academics and they won't because they all have their
>heads too far up their theoretical butts. Dr. Meyer thus states the
>facts given his experience.
>
>> Here he names every evil trick and bad practice that he can, and
>> ascribes it all to C, as though no other language had the capability
of
>> supporting bad practices. He also claims that C programmers
religiously
>> follow these bad practices as the sacrements of their religion.
>
>(1) C makes low level code extremely easy to create and the C culture
> says that low level code is cool.
>
>(2) Many C programmers follow these bad practices.
>
fact
>> that Dr. Meyer has supplied for these extreme accusations and
>> defamations. Dr. Meyer has a right to dislike C if he chooses. But
his
>> vehemence against its programmers is unreasonable, and unreasoned.
>
>I have met tons of C hackers / software incompetents.
>
>> who fits the description that Dr. Meyer ascribes to them all.
>
>Wow, you must really be sheltered or have really low expectations.
>
>> In my opinion, he is very wrong, not only professionally, but
moraly.
>> And he owes the industry an apology and a retraction.
>
>I appreciate opinions by computer scientists and not the usual
>sterile "I have no position / all approaches are equal and based
>on personal preference" crap.
>> There is only one word that can accurately describe these
sentiments.
>> That word is biggotry. I don't like to use a word like that to
>> describe the words of someone who is obviously intelligent.
>
>> amnesty to Ada, Pascal and Modula programmers. According to Dr.
Meyer,
>> it is only, or especially, the "C hacker" that you must be wary of.
He
>> does not say: "Beware of Hackers", rather he says: "Beware of C
>> hackers." And this is simply biggotry, the segregation and
defamation
>> of a class of people based only upon the language that the program
in.
>
>If I judge a programmer to be software incompetent, then I have no
>problem labelling that person as such. Unthinking worship of some of
>the more idiotic parts and culture of C are in my view a
>demonstration of their incompetence. I will do everything in my
>disposal to get that person far away from my project. I guess I am a
>bigotted against software engineering incompetents. Bigotry must be
>good if it keeps hackers away!
>
>I have high standards, thus I see that the software industry is strewn
>with incompetent programmers. I am sick of this everyone is a genius
>/ respect their artistic integrity and personal preference / kiss
>everyones butt attitude in software (which leads to not getting
>answers and thus poor software). I am sick of the lack of definition
>in this field of what is good and what is bad, the only way to answer
>these questions are research studies, yet no one is doing them!
>
>I can understand apathetic programmers, "Hey Bob, why do you use that
>shitty tool? Bob: Because I am a bonehead!". C Hackers are more
>fanatical, they are usually convinced of their brilliance and
>religious devotion to their C dirty-tricks. Getting these people to
>use a software engineering language is nearly impossible. The
>prototypical C hacker even curses Stroustrup for some of his less than
>worshipful comments on certain aspects of C.
>> Had you simply attacked C, I would not have responded. Rather, you
>> attacked the characters of people. This required a response.
>
>In my cynical view most people are either "assholes" or "idiots" (or
>both). In the programming world, the biggest assholes are the
>"hacker" types who basically don't give a damn that you will have to
>maintain their excrement for years to come. There really should be
>prison terms for these programmers.
>
>
I've found that fervent criticism says more about the criticizer than
the target of their criticism. To say (or imply) that C promotes a
hacker culture is like saying that a crowbar promotes break-ins. This
is patently false and no amount of boisterous illogic will make it
true.
'Nuff said.
Luther Hampton
>
> Richard van de Stadt (st...@cs.utwente.nl) wrote:
> : edw...@world.std.com (Jonathan Edwards) wrote:
> : >In article <3t8192$b...@espresso.internet-cafe.com>,
> : [...]
> : >It comes as a shock to most people that in fact the dominant programming
> : >language in the world is COBOL. Counted either by lines of code in production
> : >or number of employed programmers, COBOL blows everything else away.
>
Speaking as an ex-hacker (or perhaps continuing hacker, as I do write
a lot of C++), let me make this observation: for hackers, what's important
is the elegance of the program in the context of maximum machine
utilization. The actual results of the program are not nearly as
important as the elegance and efficiency of the code. Languages such
as COBOL and Smalltalk are uncool because the author can't control the
details of the implementation of the program, just its output. That's
no fun. In other words, C is preferrable to hackers because it keeps
enables the programmer to more closely control the way his program is
implemented in the the computer, and for many people (I must include
myself here at least part-time), what's really interesting is the internal
dance, data flying from register to register, memory bank switching,
context switching etc.
I'm reformed now, because this is a very inefficient way to develop
programs. I've switched to languages such as Smalltalk and I concentrate
on the program's output, not its implementation details, which are
in a realistic sense somewhat irrelevent, particularly as machines
become faster and the overheads associated with the actual implementation
become more unimportant. Sometimes however I still feel the old longing
to really "get my hands dirty". It was fun back in the old assembly
language days.........
Luther Hampton
Jay Martin
>without employing sound principles of software engineering. Someone who
>simply throws code together without thought to structure or lifecycle.
Good definition.
> Certainly there are hackers who use C. But there are Hackers who use
> every language. And in this, Dr. Meyer is quite negligent, for he says
> nearly the opposite:
> Why single out C? First, interestingly enough,
> one seldom hears about Pascal hackers, Ada hackers
> or Modula hackers.
> This may or may not be true, I have no statistics. However, *if* it is
Jerry Fitzpatrick
writes:
>edw...@world.std.com (Jonathan Edwards) writes:
>
>>In article <3t8192$b...@espresso.internet-cafe.com>,
>>Bertrand Meyer <bert...@eiffel.com> wrote:
>>[Response to Robert Martin]
>
>>Isn't this really a cloaked attack on C++?
>>And isn't that what really bothers Mr. Martin?
>
>No.
>
>What bothers me is that Dr. Meyer was attacking a class of people, not
>a language. He is a well known author, and his book will have a wide
>distribution. And his book is full of very good stuff. But in the
>midst of all this he makes the recommendation to managers that they
>not hire C hackers.
>
>What if *I* wrote a book, and in it I said:
>
>this is | Managers, whatever you do, don't hire programmers who
>simply an | admit to knowing Eiffel. Eiffel, as a language,
>does not | Eiffel, even for only a short time, believe that it is
>reflect the | the only true language in the universe. Moreover,
>opinion of | other languages, and the people who program in them,
>the author. | make them physically ill. Thus, they won't be able to
> | touch your legacy systems without fits of intense
> | nausea.
>
>I think Dr. Meyer, or Ian Joyner, or one of the other notable
>supporters of Eiffel would have a duty to step forward and rebut such
>nonsense.
>
>--
>Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
>2080 Cranbrook Rd. | Tel: (708) 918-1004 | Mgt. Overview of OOT
>Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.
This is precisely the impression I get by reading the quote from Dr.
Meyer's book, and even from his followup newsgroup response.
If C is deeply flawed (as Dr. Meyer seems to feel) then it's a short
leap of logic to believe that C programmers (excuse me, I mean "C
hackers") are deeply flawed.
The notion that people are somehow corrupted by the tools they use is a
complete fallacy. What is state-of-the-art today will become an object
of ridicule in the future. If Dr. Meyer doesn't realize this, he no
doubt will in the not-to-distant future when Eiffel becomes a niche
legacy language.
--
shankar n. swamy
Jim Fleming <jim.f...@bytes.com> wrote:
>In article <1995Jul3.0...@rcmcon.com>, rma...@rcmcon.com says...
>>
>>
>
>@@@@@@
>RM>However I take extreme exception to something he wrote in this book.
>RM[snip]
>RM
>RM>In my opinion, he is very wrong, not only professionally, but moraly.
>RM>And he owes the industry an apology and a retraction.
>RM>
This editing is very unfair to Robert Martin. You have snipped the
most improtant point - that he was talking about C (NOT C++). You
have edited that part, and that gives wrong impressions to the
people reading your article, particularly if they have missed
Mr Martin's.
>@@@@@@
>
>Aside from the above...
>
>There is something clearly wrong in the OO industry and especially in
>the C++ community.
>
>My theory is that, "C++ has WON", and now it must deliver!!!!
>
If you have something to say about the C++ programming/programmers -
which you apparently do - it would have been more appropriate to start
a new thread on that instead of trying to lead the discussion off the
subject.
>
>@@@@@@@@@@@@@
>--
>Jim Fleming /|\ Unir Corporation Unir Technology, Inc.
>j...@tiger.bytes.com / | \ One Naperville Plaza 184 Shuman Blvd. #100
>%Techno Cat I / | \ Naperville, IL 60563 Naperville, IL 60563
>East End, Tortola |____|___\ 1-708-505-5801 1-800-222-UNIR(8647)
>British Virgin Islands__|______ 1-708-305-3277 (FAX) 1-708-305-0600
> \__/-------\__/ http:199.3.34.13 telnet: port 5555
>Smooth Sailing on Cruising C+@amarans ftp: 199.3.34.12 <-----stargate----+
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|
>
- shankar swamy
------------------------------------------------------------------------------
sha...@cs.indiana.edu
Paul Long
>I've seen huge amounts of solid, working C code.
>What I haven't seen is performance-tuned bit-bashing
I agree. Check out comp.dsp sometime. I haven't done a study :-), but I'd say
that most programmers there avoid C because they view it as a bloated,
inefficient high-level language, unsuitable for the "bit bashing" that they
_must_ do. Some compromise by using C as the skeleton for their program, e.g.,
for function calls, but the guts of the program are written in assembler. A
minority use C in all its "glory."
In the 10+ years I've been programming in C, I have rarely seen the hacked C
code described by Bertrand. To be sure, I've seen A LOT of really wretched,
unportable, and unmaintainable C code, but not that much that has been
pointlessly optimized for speed and space. Cynically, the average programmer
doesn't know enough about the machine on which they are working to write this
kind of code. The bad code that I do see is bad due to the same reason that
code is bad in other languages--poor understanding of the problem and bad
coding practices.
--
Paul Long 45:29:14N 122:48:09W
pl...@perf.com http://www.teleport.com/~pciwww/
"O! that way madness lies; let me shun that."
Ian Fairman
: edw...@world.std.com (Jonathan Edwards) wrote:
: >In article <3t8192$b...@espresso.internet-cafe.com>,
: [...]
: >It comes as a shock to most people that in fact the dominant programming
: >language in the world is COBOL. Counted either by lines of code in production
: >or number of employed programmers, COBOL blows everything else away.
: This is no miracle, considering the number of lines of code one needs to
: implement what can be done with much less code in most other languages.
: In order to write all these lines of code, one needs lots of programmers...
I partially agree with this. You need more code with something like COBOL
but it's easier to write this code. When I was a COBOL programmer (there's
an admission :-) I use to churn out a thousand line program every other
day.
There is just no comparison with languages like C++ in terms of lines of
code.
Ian.
--
Ian Fairman, BT.
Email: ifai...@jungle.bt.co.uk
Disclaimer: My opinions are my own and not those of my employer.
Jay Martin
>jma...@cs.ucla.edu (Jay Martin) writes:
>>Rabid worship of C increases the probabilty the person is a hacker.
>>Why? The basic tenents of C culture are anti-software engineering.
>I refer you to the "The C Programming Language" by Kernighan and
>Ritchie (any edition) for a good example of the counter view. The
>authors are very sensitive to software engineering principles, and
>stress them throughout the book.
>If there is such a think as "C culture" (which I doubt) then I, and
>most of my associates must be members of that culture. And we have
>been concerned about software engineering principles for the last 20
>years.
What K&R hacked 20+ years ago was fine technically given the times and
having the constraint of 50k of memory. Nowdays Unix and C are really
poor examples of computer software and are widely seen as holding back
the software/operating field. If you want to hold K&R up as dieties,
then I must give my my opinion that their work from that era would
qualify them as software engineering clowns today. Even for that era
the tools were recognized as poor. In my opinion, only free source
code and the hacker incompetence of Computer Science which stressed
getting out neat performance graphs allowed this stuff to become
widespread. You may have been concerned about software engineering
principles for the last 20 years, but in my opinion you obviously
never really understood software engineering principles. Software
engineering dictates the use of quality tools.
Jay
Jay Martin
>I've found that fervent criticism says more about the criticizer than
>the target of their criticism. To say (or imply) that C promotes a
>hacker culture is like saying that a crowbar promotes break-ins. This
>is patently false and no amount of boisterous illogic will make it
>true.
Machine guns don't promote violence?
Sports cars don't promote speeding?
Low level languages don't promote low level code?
(Low level code = anti-software engineering).
Jay
Jay Martin
>If C is deeply flawed (as Dr. Meyer seems to feel) then it's a short
>leap of logic to believe that C programmers (excuse me, I mean "C
>hackers") are deeply flawed.
People who use poor tools without at least some level of grumbling are
not very competent. People who use poor tools and don't even realize
that they are poor are really incompetent.
>The notion that people are somehow corrupted by the tools they use is a
>complete fallacy.
I agree with good ol Dijkstra: "COBOL programmers are braindamaged for
life" (Substitute COBOL with C). People get locked into old
restricted ineffective modes of thought everyday. Last night I
watched a program of taking of France in WWII, France got its butts
kicked due to that military leaders just could not adjust to the
concepts of modern warfare. If people adjusted to new software
paradigms easily then I would agree with you, but they usually learn
one way and don't want to change. This is why I see C++ as a sneak
attack on these regressives, you sneak it in as a better C when it is
actually a very major change.
Jay
Robin Rowe
Robb Nebbe <Robb....@di.epfl.ch> wrote:
>I have never met a programmer that was limited by his typing speed.
Well, I sure have. I've met many programmers who can't type fast enough or
accurately enough to have decent productivity. I find it quite frustrating
to watch someone program by hunt and peck. Don't you?
Robin
--
-----
Robin Rowe c...@netcom.com 408-626-6646 Carmel, CA
Rowe Technology C++ Design/Training Email for sample C++ Newsletter!
Dave Howard
>
>I have recently acquired a copy of Bertrand Meyer's new book "Object
>Success". I would like to say that I have a great deal of respect for
>Meyer. Moreover, I have read many good things in this book so far.
>
>I will comment on it afterwards.
>
>PRUDENT HIRING PRINCIPLE: Beware of C hackers.
>
>A "C hacker" is somewone who has had too much practice writing
>low-level C software and making use of all the special techniques and
>tricks permitted by that language.
>
One also seldom hears of Pascal jobs or Modula jobs.
(Ada is another story I'll leave off for now)
dave howard
da...@hendrix.reno.nv.us
Jim Fleming
sha...@cs.indiana.edu says...
>
>
>Jim Fleming <jim.f...@bytes.com> wrote:
>>In article <1995Jul3.0...@rcmcon.com>, rma...@rcmcon.com says...
>>>
>>>
>>
>>@@@@@@
>>RM>However I take extreme exception to something he wrote in this book.
>>RM[snip]
>>RM
>>RM>In my opinion, he is very wrong, not only professionally, but moraly.
>>RM>And he owes the industry an apology and a retraction.
>>RM>
>
>This editing is very unfair to Robert Martin. You have snipped the
>most improtant point - that he was talking about C (NOT C++). You
>
>- shankar swamy
>---------------------------------------------------------------------------
---
>sha...@cs.indiana.edu
@@@@@@@@@@@@@@@@@@@@@@@
I think that anyone that is closely following the C/C++ ANSI Standards
effort would note that C++ and C are blurring into one language.
(See the August 1995 issue of Dr. Dobb's Journal)
C++ has been sold by riding the coat-tails of C. I am not sure that C only
compilers are even sold in retail stores.
I have a feeling that Dr. Bertrand Meyer was including C++ programmers
with C programmers when commenting in his book. I imagine that a man like
him, that has been treated so poorly by the C++ community, would find it
very unpleasant to type the letters C++.
It would be interesting to see if Dr. Meyer (or anyone) has found any
substantial difference between the C programmer population and the C++
programmer population. The C++ community loves to quote huge usage
statistics based on C/C++ compiler sales as if all of those users were
using the OO extensions which make C into C++.
C and C++ are largely the same...(i.e. C++ @= C)....:)
C++ has WON!!!...now it must deliver...
Jim Fleming
>
>There seems to be some confusion between
>
>This thread has helped me re-evaluate my bigotry against ex-scientists
>who are hired to write software. I think that such an individual may
>have demonstrated a commitment to developing themselves into commercial
>software developers, but if they havn't, a person with 3 degrees in
>science who starts working on commercial software is working on a
>high-school diploma.
@@@@@@@@@@@@@@@@@@@@@
Yes...I suggest that you go and read the last few years of some of the
major C/C++ publications...
It is humorous to see (or C) that some people go from being self-ascribed
novices in C++ to being the industry experts in less than a few years...
I guess this is like going from being able to drive an 18 wheel "semi" to
being a 747 pilot simply because you deliver cargo to the planes...
It is shocking that our industry seems to allow magazine editors and
other industry pundits to wander from one venue to another and simply
because of their distribution channel, they are "licensed" to advise
the people on future directions...and also write our ANSI standards...
@@@@@@@@@@@@@@@@@@@@@
> If you were driving a semi with 2 heavily-loaded
>trailors down the road towards a gorge, and a sign on the road said "the
>next suspension bridge was the first design of a PhD in Biology who
>changed careers; alternate route through gorge adds 40 miles", would you
>take the bridge or the gorge route?
>
>--
>Tom Janzen - t...@world.std.com USA Distributed Real-Time Data Acquisition
S/W
>for Scientists and Engineers using POSIX, C, C++, X, Motif, Graphics, Audio
>
@@@@@@@@@@@@@@@@@@@@@
That is a tough choice...because the "semi" was likely the first design
of an ex-747 pilot that decided to apply for a patent and copyright on
some trivial truck component and the manufacturer promoted him to "god
of truck design" and never checked his engineering skills...
@@@@@@@@@@@@@@@@@@@@@
Tom Payne
: In <1995Jul3.0...@rcmcon.com> rma...@rcmcon.com (Robert Martin)
: writes:
: >
: >I have recently acquired a copy of Bertrand Meyer's new book "Object
: >Success". I would like to say that I have a great deal of respect for
: >Meyer. Moreover, I have read many good things in this book so far.
: >
: >However I take extreme exception to something he wrote in this book.
: >On page 91 he writes the following which is included in its entirety.
: >I will comment on it afterwards.
: >
: >----------------------------------------------------------------------
: --
: >PRUDENT HIRING PRINCIPLE: Beware of C hackers.
: I am concerned about Dr. Meyer's use of language here.
: The term "hacker" with its obvious negative connotation would have been
: sufficient to make his point. To single out C as the preferred hacker
: language promotes a ridiculous stereotype. But then to prattle on at
: length about "C hacker" cultism, deities, and brainwashing is simply
: demeaning and unnecessary.
Unacceptable: the denigrating H-word
Preferred: "semantically challenged"
Never: associate this stereotypical impairment with a particular
linguistic persuasion
Tom Payne
t...@cs.ucr.edu
Steven D. Majewski
If you can't really argue with what your opponent *says*, paraphrase
it into something he doesn't say, and argue with THAT!
Robert Martin gives us a good example of that technique: Where Dr.
Meyer clearly distinguishes between "C hackers" and "C programmers",
Mr. Martin tries to tell us that he must have really MEANT his
comments to apply to all C programmers, and then tears apart his
own "straw man".
What passion drives Mr. Martin to use such base tactics ?
He gives us a clue below:
In article <1995Jul3.0...@rcmcon.com>,
Robert Martin <rma...@rcmcon.com> wrote:
>
>What is a hacker? A hacker is someone who writes computer programs
>without employing sound principles of software engineering. Someone who
>simply throws code together without thought to structure or lifecycle.
>
Now Mr. Martin is slandering hackers with his own made up definition!
I would not recognize most of the hackers I've known by that
description. Many of them are quite good software engineers.
( Some are just the sort of "C hackers" Dr. Meyer describes.
The best of them have usually had experience with more that just
the C language, even if they have become "C hackers". ) Sometimes
thought on structure and lifecycle even seems to DEMAND a "hack"!
Clearly, if Mr. Martin has such a low and mistaken impression of
hackers, then we can understand why he feels so insulted.
However, as a proud former "C hacker" ( I first took up C as a
replacement for both Fortran and PDP-11&VAX assembler, and part
of it's appeal was that it was "close to the machine" - I could
usually predict the assembler output fairly closely, but it was
less work and less error prone than actually writing it in
assembler.) and current "C programmer", I find Dr. Meyer's comments
quite reasonable. ( But then, I'm capable of distinguishing between
"hackers", "C hackers" and "C programmers" - which is something with
which Mr. Martin appears to have trouble. )
On problem is that "hack" is one of those english verbs, like "dust"
and "cleave", that can mean two opposite things. From the first
two definitions in the Jargon File:
:hack: 1. n. Originally, a quick job that produces what is
needed, but not well. 2. n. An incredibly good, and perhaps very
time-consuming, piece of work that produces exactly what is needed.
[ ... ]
And from that verb, derives:
:hacker: n. [originally, someone who makes furniture with an
axe] 1. A person who enjoys exploring the details of programmable
systems and how to stretch their capabilities, as opposed to most
users, who prefer to learn only the minimum necessary. 2. One who
programs enthusiastically (even obsessively) or who enjoys
programming rather than just theorizing about programming. 3. A
person capable of appreciating {hack value}. 4. A person who is
good at programming quickly. 5. An expert at a particular program,
or one who frequently does work using it or on it; as in `a UNIX
hacker'. (Definitions 1 through 5 are correlated, and people who
fit them congregate.) 6. An expert or enthusiast of any kind. One
might be an astronomy hacker, for example. 7. One who enjoys the
intellectual challenge of creatively overcoming or circumventing
limitations. 8. [deprecated] A malicious meddler who tries to
discover sensitive information by poking around. Hence `password
hacker', `network hacker'. The correct term is {cracker}.
Robert Martin closes his diatribe against Bertrand Meyer with:
>
>In my opinion, he is very wrong, not only professionally, but moraly.
>And he owes the industry an apology and a retraction.
>
Not any more wrong, professionally or morally, that you are in your
distorted definition of "hacker" - in fact much less so, I think.
I quite agree with Dr. Meyer's characterization. ( And I hope that
I've been successfully rehabilitated! :-)
I think his only error is that, considering that the books target
is software managers, he may be making a too subtle distinction.
If YOU can misread him so completely, then I suspect many of the
target readers of his book may also miss the distinction.
Dr. Meyer is guilty only of excess subtlety, and is more clearly
innocent of malice that you are in your reply to his words.
You owe him, and the hackers you have so professionally and morally
maligned, an apology, Mr. Martin.
---| Steven D. Majewski (804-982-0831) <sd...@Virginia.EDU> |---
---| Computer Systems Engineer University of Virginia |---
---| Department of Molecular Physiology and Biological Physics |---
---| Box 449 Health Science Center Charlottesville,VA 22908 |---
Jim Fleming
>
>ifai...@jungle.bt.co.uk (Ian Fairman) wrote:
>>
>> Richard van de Stadt (st...@cs.utwente.nl) wrote:
>> : edw...@world.std.com (Jonathan Edwards) wrote:
>> : >In article <3t8192$b...@espresso.internet-cafe.com>,
>> : [...]
>> : >It comes as a shock to most people that in fact the dominant
programming
>> : >language in the world is COBOL. Counted either by lines of code in
production
>> : >or number of employed programmers, COBOL blows everything else away.
>>
>
>a lot of C++), let me make this observation: for hackers, what's important
>is the elegance of the program in the context of maximum machine
>utilization. The actual results of the program are not nearly as
>important as the elegance and efficiency of the code. Languages such
>as COBOL and Smalltalk are uncool because the author can't control the
>details of the implementation of the program, just its output. That's
>no fun. In other words, C is preferrable to hackers because it keeps
>enables the programmer to more closely control the way his program is
>implemented in the the computer, and for many people (I must include
>myself here at least part-time), what's really interesting is the internal
>dance, data flying from register to register, memory bank switching,
>context switching etc.
>
>I'm reformed now, because this is a very inefficient way to develop
>programs. I've switched to languages such as Smalltalk and I concentrate
>on the program's output, not its implementation details, which are
>in a realistic sense somewhat irrelevent, particularly as machines
>become faster and the overheads associated with the actual implementation
>become more unimportant. Sometimes however I still feel the old longing
>to really "get my hands dirty". It was fun back in the old assembly
>language days.........
> Luther Hampton
I don't think that anyone (including Bertrand) would disagree with the fact
that there are times when a few people have to get close to the machine.
This is primarily because our friends that design and manufacture silicon
have not raised their level abstraction for many years. They have made
the processors wider and faster and reduced the number of instructions,
but they have not provided for example, an "object processor". (Yes, Intel
tried the 432, but people did not understand the adavantages of OO, they
were still trying to figure out what graphics board to put in their PCs).
You may find it interesting that when C+@ was developed, some of the best
hackers at Bell Labs were assigned to develop the low-level engines that
had to provide reasonable performance on an old Sun 2 (68000 based machine).
Without those hackers, C+@ would not exist.
When the SPARC came along, much of the 68000 assembly language code
was moved to C and there was not very much performance increase because
what was lost by moving the hacker code to C was offset by the speed of
the SPARC.
Through the 10 year evolution of C+@, the object-oriented code has not
changed much. At this stage, most people can program only in C+@ and
do not have to worry about the great job the hackers did behind the
scenes. It is a shame that the hackers have not gotten better support
from the silicon chip designers, but those are the market forces.
One of the advantages of having a companion language like C+@ is that
hackers can continue to work with high-performance C and programmers
that are more interested in OO, reuse, portability, etc. can work in
C+@. The two populations work well together.
A similar situation exists with Sun's Java (see: http://java.sun.com).
Most of the "hot" Java (NOT Hot Java) code is written in C (not C++).
The rest of the system (including Hot Java) is written in Java which
is similar to C+@.
One of the differences in Java and C+@ is that C+@ has a mature visual
development environment. I find it interesting that it seems easier for
C hackers to write Java code without the fancy GUI environment because
it more closely matches their current development environment. This
same phenomenon still exists with C+@. The hackers who work on the
low-level virtual machines prefer to avoid the visual development
environment...UNTIL...they have to reuse code and then they find that
they have to begin using the tools to be productive.
Some C/C++ programmers find that being forced into anything is restrictive.
This seems to be the nature of the religion. In the case of C++, a certain
amount of "language marketing" was done that emphasized that programmers
could chose the OO paradigm on a line-by-line basis. This has resulted
in a mess and has given hard-core C programmers an endorsement that
cryptic code is appreciated. (Also, the C++ books and magazines thrive on
tricks and puzzles, because doing anything substantial in the language is
a lot of work...compare that to Smalltalk books and magazines which have
substantial working examples of systems).
With C+@, this problem has been avoided by allowing C hackers to work
the "low-road" while C+@ programmers take the "high-road"...they all
come together and meet and working systems are easier to produce and
document...
Jim Fleming
>
>jma...@cs.ucla.edu (Jay Martin) writes:
>
>
>It is always dangerous to create classes (e.g. "C culture) into which
>you can insert groups of people based upon a simple attribute. It
>leads to wrong conclusions. i.e. software engineering principles are
>antithetical to "C" culture, thus all C programmers are hackers.
>In my direct experience, nothing is further from the truth.
>
>--
>Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
>2080 Cranbrook Rd. | Tel: (708) 918-1004 | Mgt. Overview of OOT
>Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.
I have been a "C Hacker" since 1975. I took my first formal C course
from Brian Kernighan when he was still using paper notes which became
a little white book called "The C Programming Language".
I signed a contract with Addison-Wesley to write the "second C book"
and I had a good start when another book arrived on the market. I
foolishly decided that there were now 2 C books and that the market
was saturated. I gave the publisher back the $5,000 royalty advance
they had paid, despite their objections that there was probably room
for a third C book. I refused to appear to be a "me-too" book writer.
I was not offended by Dr. Bertrand Meyer's comments and I think that
I understand what Bertrand is talking about. I feel that the wide-spread
reaction to these postings is just another form of abuse that Bertrand
and others have wrongly endured over the years.
@@@@@@@@@@@@@@@@@@@@
Rick Lutowski
: It would be a big mistake to hire a programmer who does _not_ know C.
Back in the 60's a person held in high esteem by many chimed
"It's the singer and not the song."
Translated and updated: "It's the programmer and not the language."
Great craftsmen build great products, usually with their own
set of outmoded, but familiar, tools. The greatest professional
I've ever known was an "old style" naval architect, who could
design a better ship with his ancient hand-crank calculater
than any of us young guys with all our fancy computers.
Conversely, mediocre practitioners will frequently surround
themselves with the latest and greatest tools, usually in the
hope that the tools will somehow compensate for their lack
of expertise.
Dr. Meyer was warning us about the mediocre software practitioner
("hacker") and not the tool ("C").
This leads to a related observation. I find it disconcerting that
a discussion group on object-oriented technology should be so
focused on tools. This is a mistake, alebit an easy one to fall
into. Two of my former projects made the same mistake of letting
tools drive methodology. That this is completely backwards becomes
obvious when one considers that a methodology constitutes the
requirements for a CASE toolset (of which a language and compiler
are but one component).
This mentality is evidenced by statements like "It would be a big
mistake to hire a programmer who does _not_ know C." This reflects
a dangerous overemphasis on tools, rather than on expertise and
experience. If you want good software, hire a good software
engineer - even if all (s)he knows is COBOL or FORTRAN. It's
a lot easier to teach C or C++ than software engineering. And
don't delude yourself: COBOL or FORTRAN practitioners can be
great software engineers, just as users of hand-crank calculators
can be great naval architects.
To skeptical C/C++ language proponents, I pose a question:
Back in the late 60's, another person held in high esteem by many
claimed that it was possible to encapsulate ("information-hide")
requirements. This was back in the days of COBOL, FORTRAN, and PL/1.
Apparently, this great software practitioner felt he knew how to
accomplish this feat with the "non-OO" languages of the time. The
challenge is - how does one use C or C++ to information-hide
requirements?
If no one can produce a workable, practical solution to this question
using the powerful modern tools of C and/or C++, a question which
was addressed by this talented software professional 25 years ago
with the language tools of his time, then it proves the point -
It's the programmer and not the language.
Rick
+--------------------------------------------------------+
| Rick Lutowski o...@killerbee.jsc.nasa.gov |
| Object Access, Inc. 713-554-7617 (oa=OO) |
+--------------------------------------------------------+
Jim Fleming
Yes, C++ used the "Trojan Horse" approach to marketing. It has worked
very well. Unfortunately, many companies and people have been mislead
about the power and potential of this horse. One company in particular
has probably spent over $100,000,000 on this horse. The stakes are
very high.
For the past 10 years, many experts have been advising the management
of AT&T about the flawed way that C++ tries to introduce OO on an
incremental basis. They have chosen not to listen and continue to
showcase the C++ monster as the future of OO programming.
They refuse to come forward with any metrics or proof that their
internal projects have either benefited or failed under the weight of
this dinasour. They continue to showcase the beast, solely on the basis
that AT&T Bell Laboratories surely must know what they are doing.
That may have been true in the 70's but times have changed. Many companies
and many countries are now populated with computer experts. The Internet
allows these experts to communicate on a minute by minute basis. The
experts are no longer clustered in places like AT&T Bell Laboratories.
In the old model, the assumption was that inside the hallowed walls of
Murray Hill sat the *only* experts in the world and they pontificated
to the rest of us peons the direction to steer the horses. I for one
can tell you, that most of the experts are now gone, and those that
remain do not have a clue as to which way to steer the horses which
are now out of control. Anyone that follows their direction is a fool.
It is a shame that so many people have invested so much time and energy
into something that has been flawed from the beginning. Now that C++
has "won", it must deliver and AT&T must be held accountable for taking
the industry down this path. AT&T had its chance to rectify this problem
and chose to stay the course. Unfortunately, this is a case where 1% of
the population steered the other 99% over the cliff.
Unfortunately, this was a virus that was born out of the Divestiture
and was cultivated in the late 80's UNIX commercialization. This resulted
in AT&T filing suit to try to stop the progress of software to protect
their prima donnas in the UNIX Systems Labs and Murray Hill. This same
virus has been present in C++ from the beginning and has resulted in
wide-spread destructive activities being beamed from the networks of
AT&T Bell Laboratories in New Jersey. Unfortunately, many people around
the world have taken this as an endorsement to continue the destruction.
While AT&T trys to figure out how to explain to the world that their
*experts* did not know what they were doing, the rest of the world is
moving forward. Fortunately, companies like Sun have broken themselves
from the AT&T Bell Labs umbilical cord (after being infected with System
V Release 4) and have awoken to find that they have their own brilliant
computer scientists. This was hard to do after being told for years that
"the boys in the valley" were inferior to the "boys on the hill".
As I have suggested before, check out Sun's Java programming language.
(http://java.sun.com). This is only the tip of the iceberg of what
we can expect to see in the next few years. With the growth of the Internet
*all* people all around the world can now participate in forums where
experts come together to discuss leading edge topics.
As we celebrate this Fourth of July in the United States, it is important
to remember that freedom and innovation are alive and well. We all need
to move forward and ignore the transmissions that come from AT&T Bell
Laboratories calling for people to censor communications or to devise
solutions to do away with dangerous people. Hopefully, the U.S. Federal
government will be able to handle those matters.
It has been interesting to watch this interchange and to realize that
people can agree to disagree without promoting violence or illegal
activities toward any of the parties. I encourage *everyone* to keep
posting and I hope that no one promotes censorship or destructive
business practices.
Bradley Yearwood
>of a job yet. And if you hire programmers, check that they know C
>as well as something else. But take my word for it: beware of
>C hackers.
>
Down here in the lower engineering compartments of the great ship of
programming, the great periodic piston moves quickly, collapsing the
universe to irrelevance, save a select few state variables, at the
end of every millisecond. I need an abstraction to cope with the
10,000 instructions into which that millisecond is divided, but that
abstraction need not be much more than the C language and a simple
state diagram.
We stokers may daydream of the fancy things served on the captain's
table, but we must still shovel all of our bits and get out before
the great periodic piston comes around again and smashes our poor stoker
butts into oblivion. Did I neglect to mention also that our compartment is
very small?
But it is good to have aspirations. One question which I often ask candidates
for non-stoker positions is "What is the most important feature of an object
programming language?". Somehow, most people forget to mention that the
language which brings extensive, coherent, and proven libraries and tools
is likely to be the most useful. Most people give popularity-based or
sticker-priced arguments for C++. If someone finds the language with the
extensive, coherent, and proven libraries and tools, please let me know.
Brad Yearwood b...@crl.com
Cotati, CA
Jim Fleming
>
>In article <3t8192$b...@espresso.internet-cafe.com>,
>Bertrand Meyer <bert...@eiffel.com> wrote:
>>
>>Relax. A little dissent will spice up your life. You are not out
>>of a job yet. And if you hire programmers, check that they know C
>>as well as something else. But take my word for it: beware of
>>C hackers.
>>
>
>Down here in the lower engineering compartments of the great ship of
>programming, the great periodic piston moves quickly, collapsing the
>universe to irrelevance, save a select few state variables, at the
>end of every millisecond. I need an abstraction to cope with the
>10,000 instructions into which that millisecond is divided, but that
>abstraction need not be much more than the C language and a simple
>state diagram.
>
Yes, many people find that after using C++, they appreciate the subset
called C and write better C code than before as they avoid the C++
extensions.
@@@@@@@@@@@@@@
>We stokers may daydream of the fancy things served on the captain's
>table, but we must still shovel all of our bits and get out before
>the great periodic piston comes around again and smashes our poor stoker
>butts into oblivion. Did I neglect to mention also that our compartment is
>very small?
>
@@@@@@@@@@@@@@
I like this analogy. C is definately for the internal systems programming
work. We use C+@ for setting the "captain's table".
I have a similar analogy where we design a game with a chess board
mounted above a checker board. We have C programmers program the
checkers on the lower level and we have C+@ programmers program
chess pieces on the upper level. A thin and controlled interface
is used to connect the boards.
C++ is like putting the checkers and chess pieces on the same board
and trying to explain the rules of chess, checkers and the combined
game at the same time.
In the multi-level approach (or companion approach), you do not have
to learn new rules for chess or checkers, just the rules for how they
interact. It is easier to keep the pieces on their own board, especially
when new people arrive to take over the code.
@@@@@@@@@@@@@@
>But it is good to have aspirations. One question which I often ask
candidates
>for non-stoker positions is "What is the most important feature of an
object
>programming language?". Somehow, most people forget to mention that the
>language which brings extensive, coherent, and proven libraries and tools
>is likely to be the most useful. Most people give popularity-based or
>sticker-priced arguments for C++. If someone finds the language with the
>extensive, coherent, and proven libraries and tools, please let me know.
>
>Brad Yearwood b...@crl.com
>Cotati, CA
>
@@@@@@@@@@@
I agree, I have always found it amazing that OO software engineers that
are expected to design using high-levels of abstraction are asked some
of the most detailed questions about "syntax" tricks known to man. This
seems to be the nature of the C++ industry which is shaped by the sum
total of everyone in the industry interacting. If the majority (or a
*vocal* minority) like puzzles, then the literature will be filled with
puzzles.
BTW...for other languages check Java (http://java.sun.com)
and of course C+@...
Maarten Landzaat
>....... ``Why Pascal Is Not My Favorite Programming
>Language'', an entertaining critique by Brian Kernighan of C fame
>whom no one, as far as I know, has yet accused of moral indignity.]
There is a very good reason for that difference:
Mr. Kernighan's story is modest and entertaining, while your story
sounds self-fulfilled. You do not seem to respect the 'C-hackers',
and it is your good right, but don't expect to be respected for that.
You might come up with some reasons to respect C-hackers for, and
since you are an intelligent software engineering authority, I (and
probably your attackers) expect you to do so. But you choose not to.
This is where your morals come in.
The religiousness you attribute to C-hackers applies all the more
to yourself: the -ities you spell with a capital are important issues
on some occasions, but so may be the speed at which a C-hacker can program,
or the nice atmosphere a strange creative hacker can bring to a software
development team. It takes every kind of people....
Concluding:
I respect you for your efforts to bring software engineering to a
higher level.
I respect C-hackers for producing Unix, GNU, Linux, X, etc.
I do not respect people who do not respect people.
Robert Cain
ifai...@jungle.bt.co.uk "Ian Fairman" writes:
>
> I partially agree with this. You need more code with something like COBOL
> but it's easier to write this code. When I was a COBOL programmer (there's
> an admission :-) I use to churn out a thousand line program every other
> day.
>
> There is just no comparison with languages like C++ in terms of lines of
> code.
>
> Ian.
> --
> Ian Fairman, BT.
> Email: ifai...@jungle.bt.co.uk
> Disclaimer: My opinions are my own and not those of my employer.
>
Hi Ian!
Escapee from the dreaded UERG.
I am not a COBOL programmer, but while I was on a DEC course I was very
impressed with a COBOL programmer who completed all the assignements
quickly and with few bugs, while I struggled to complete the
assignments within the allotted time using C. No doubt the programmer
was pretty exceptional, but I have a strong suspicion that COBOL can
be very effective.
(did you really produce that many lines of COBOL?)
Rob C.
Gareth Rees
> It is always dangerous to create classes [...]
ROBERT MARTIN SLAMS C++ SHOCK HORROR!
le...@lwebber.ultranet.com
> I have recently acquired a copy of Bertrand Meyer's new book "Object
> PRUDENT HIRING PRINCIPLE: Beware of C hackers.
>
As my contribution to this vital thread :-), I have the following points:
1. Contra Meyer, there is something worse than the C hacker: the BLISS
hacker. It is my proud legacy that I have been both. I remember a time
back in the early '80s when I and the DEC BLISS compiler group played
a vigorous game of Arms Race: I would tune my code to generate the
best possible assembler, then complain to the compiler people about an
area where BLISS was inefficient, they would issue a new release that
fixed all the places I found, and I would go back and try to break it again.
Of course, I would point out that we were trying to shoehorn a full-
featured DECnet router into a 128K PDP-11/40...
2. Contra Meyer again, but also contra Martin, I submit myself as evidence
that even the most evil sinner can reform if provided a few more resources.
Today, my language of choice is Modula-2 (as opposed to my language
of preference, which is Eiffel -- but we went through that a few weeks
ago...:-). I use C only when a client insists or no other environment is
available, for the same reasons as other OO converts: it is unsafe.
Sometimes, being an ex C hacker is a positive advantage; it denotes
someone who has used the efficent/unsafe parts of C by choice rather
than by inertia, and thus is aware or what they are good for and what
they are not.
Des Herriott
>
>C++ and C+@ mix about as well as oil and water. There is no need for
>C++ when C+@ is used.
>
>C+@ was designed to allow easy access and inter-working with C. You
>can easily enter C from a C+@ program and you can even reach a C+@
>method from C (although this is rarely needed now that the system
>is written in C+@).
I have a suspicion I might get flamed for my ignorance here, but
what is C+@? I've never heard of it, speaking as a C programmer.
Where I can find references to it, examples of it, and how does it
obsolete C++?
--
Des Herriott, Micro Focus, Newbury, UK / I'm good at feeling bad,
d...@mfltd.co.uk / I'm even better at feeling worse
http://www.mfltd.co.uk/~dnh / -- L7
Robb Nebbe
|> jma...@cs.ucla.edu (Jay Martin) writes:
|>
|> >Why? The basic tenents of C culture are anti-software engineering.
|>
|> Ritchie (any edition) for a good example of the counter view. The
|> authors are very sensitive to software engineering principles, and
|> stress them throughout the book.
If I didn't know better I'd say you hadn't read the book. The authors
may be sensitive to software engineering principles, I don't know, but
what I think of as software engineering principles are certainly not
stressed throughout the book.
There is no concept of the software life cycle so obviously there is
nothing on how the various features of C affect this life cycle. There
is little about how to structure code to make it maintainable or
readable. They do mention that you can use the underscore to make long
variable names more readable of course they don't use any of these
long variable names instead prefering "bufp", "strcmp", "tnode" etc.
It is obvious from the design of the language that many problems such
as program reliability, and coherency were not addressed during the
design of the langauge and are still weak spots in C++.
Maybe you could elaborate on these software engineering principles
that are "stressed throughout the book."
Robb Nebbe
Murray J. Root
----hack----
[>Not having read Dr Meyers book, I am just talking off the top of
[>my head, but
[>at least in his rebuttal to your rebuttal doesnt he make it
[>clear that that is
----hack, again----
The problem (IMO) was that the BOOK should have made clear the difference.
Most of the people who are going to make use of BM's book DO NOT read the
Internet news ( or the programming groups, at least). They will not see RM's
objection, nor BM's clarification. To management, all dedicated programmers
are hackers, therefore, BM's warning applies to ALL 'C' programmers. In other
words - he should have used other words.
***************************************************************
AT&T Global Information Solutions would probably disavow any knowledge of
this, if they had any knowledge of this. Look for press releases to get the
official opinion.
For a change - THINK!
***************************************************************
Kevlin Henney
ne...@geog.leeds.ac.uk "Neil Wilson" writes:
>Scott Wheeler (sco...@bmtech.demon.co.uk) wrote:
>: I suggest that a better description [for C] is "RISC language", a description
> that
>: BM uses for his own Eiffel.
>
>'C' is a language that has three types of loop, two ways of doing an
>'if', two ways of sequencing instructions and three types of goto
>statement. I would suggest that RISC is a somewhat inappropriate
>term.
Now come on, Neil, you know that's not a useful metric. Try doing the
same thing for FORTRAN (each dialect in turn), assembler (your favourite),
Ada, Oberon-2, Pascal and Eiffel, including a couple of other structures,
eg. number of block types, number of boolean operatives, number of types of
assertion expressions, keywords etc. You will find the results to be
surprisingly unuseful. Measurement w/o meaning will (and has) mislead people.
Eiffel is categorically _not_ a RISC language -- that's just marketing
hype. An Eiffel system is difficult to implement, C is easier, and Oberon-2
is the RISCiest by far. So what does that tell us? Niklaus Wirth, come on
down! Dennis Ritchie gets 2nd prize, and BM gets the wooden spoon.
The question you have to ask is: was that a useful measure? Doubt it.
+-----------------------------+-------------------------------------+
| Kevlin A P Henney | Can you secure Christmas with an |
| kev...@spuddy.mew.co.uk | approximation only eighteen million |
| Westinghouse Systems Ltd | seconds left of the original old |
| kev...@wslint.demon.co.uk | red chimney? - Jack Kerouac |
+-----------------------------+-------------------------------------+
Murray J. Root
[>==========Des Herriott, 7/5/95==========
[>
[>I have a suspicion I might get flamed for my ignorance here, but
[>what is C+@? I've never heard of it, speaking as a C programmer.
[>Where I can find references to it, examples of it, and how does it
[>obsolete C++?
***************************************************************
agurski on BIX
I beg to differ.
I haven't read Meyer's book, just the quotes from it that have
appeared in this newsgroup. I tend to agree with what I've read.
I, too, have seen that there are C programmers who are quite capable of
writing quality software. However, that doesn't change the general
impression that I have of a sizable number of C programmers and the
software for which they are responsible.
One brief example. A couple of years ago, I had a look at a copy of
the C snippets collection that moves around the Internet. In particular,
I looked at one of the random number generators that was billed as
the fastest good RNG around. I wasn't impressed. Fast it was. Random it
wasn't. Coincidentally, I read an article in the "New Scientist" in
1993 about a physicist who was using that RNG in his research. He was
getting odd results and finally tracked it down to this RNG not giving
sufficiently random results. What good is a piece of software if it is
fast/efficient if it doesn't do the job for which it was intended?
Personally, I do most of my programming in Modula-2. When I am pro-
gramming for the PC, I found that I *have* to add extra code to
catch other programs (*invariably* written in C -- given the copyright
messages in the executable code) that have stomped over my data.
While I am sure that there are some poor programmers and outright
code hackers who use Ada, Pascal and Modula-2, my own observation is
that they tend to be few and far between. Amongst C programmers,
however (and *unfortunately*), I have seen a shockingly large number
of them.
0000-Admin(0000)
>``Object Success'' and do not quite understand why he chose to
>pick a fight. (I am also assiduous enough as a news reader to know
>that no one, ever, anywhere, has had the last word in a discussion
>with Mr. Martin, and have no hope of breaking that tradition; in
>fact I expect to give up right after this message, but not without
>having publicly expressed my admiration for
>his inexhaustible net-energy.)
What is this garbage? First you do a _personal_ attack on someone who
critisized your _work_ ("...always has to have the last word...") and
then go on to say something like, "Here is my refutation, but I don't
care what you think because I'm not going to play with you any more."
Grow up.
Brian
( bcw...@bnr.ca )
-------------------------------------------------------------------------------
In theory, theory and practice are the same. In practice, they're not.
Igor Chudov @ home
* Igor Chudov @ home (ich...@star89.galstar.com) wrote:
* : It would be a big mistake to hire a programmer who does _not_ know C.
* Conversely, mediocre practitioners will frequently surround
* themselves with the latest and greatest tools, usually in the
* hope that the tools will somehow compensate for their lack
* of expertise.
* Dr. Meyer was warning us about the mediocre software practitioner
* ("hacker") and not the tool ("C").
* This mentality is evidenced by statements like "It would be a big
* mistake to hire a programmer who does _not_ know C." This reflects
* a dangerous overemphasis on tools, rather than on expertise and
* experience. If you want good software, hire a good software
* engineer - even if all (s)he knows is COBOL or FORTRAN. It's
* a lot easier to teach C or C++ than software engineering. And
* don't delude yourself: COBOL or FORTRAN practitioners can be
* great software engineers, just as users of hand-crank calculators
* can be great naval architects.
* It's the programmer and not the language.
You are totally right.
However
The need to know C does not come from software engineering or computer
science or "principles of tools".
It comes from reality of dealing with hundreds of libraries, operating
systems, and recipes. You need not _use_ C. But not knowing it means
blindness. Bertrand Meyer is 100% right about hacker types. However, an
implication that some people can make that C knowledge is dangerous,
would be misleading.
For entertainment purposes, you might take a look at the program below.
--
- Igor. (My opinions only) http://www.galstar.com/~ichudov/index.html
----------------------------------------------------------------------------
char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Igor Chudov @ home
* I do not respect people who do not respect people.
Sounds very recursive. :)
--
- Igor. (My opinions only)
http://www.galstar.com/~ichudov/index.html
For public PGP key, finger me or send email with Subject "send pgp key"
Rick Lutowski
: One of the advantages of having a companion language like C+@ is that
: hackers can continue to work with high-performance C and programmers
: that are more interested in OO, reuse, portability, etc. can work in
: C+@. The two populations work well together.
The idea of a set of "companion languages" has been tried before.
I seem to recall that one of the 8-bit chip vendors - perhaps it
was Zilog - attempted to introduce a syntactically- compatible
"family of languages" about 10 years ago. I guess a chip
manufacturer was the wrong company to try it, because it
never caught on, but I thought it was a great idea then, and still
do. The family approach simplified learning and use, because
common constructs were identical among the languages; e.g., they
all used the same control statement syntax, for example.
Of course, these languages were not OO, but that's not the
issue. OO and companion languages are orthogonal concepts.
From what I remember of the 10 year old attempt, I think I liked
that language family better, because they gave the appearance
of the family actually being _designed_. C++ and C+@ seem more
like shotgun wedding partners. Now, if someone could actually
_design_ a family of OO languages as a family, we might have
something worth posting about.
Srinvas Nedunuri
Robert Martin <rma...@rcmcon.com> wrote:
>edw...@world.std.com (Jonathan Edwards) writes:
>
>>In article <3t8192$b...@espresso.internet-cafe.com>,
>>Bertrand Meyer <bert...@eiffel.com> wrote:
>
>>Isn't this really a cloaked attack on C++?
>>And isn't that what really bothers Mr. Martin?
>
>No.
>
>What bothers me is that Dr. Meyer was attacking a class of people, not
>a language. He is a well known author, and his book will have a wide
>distribution. And his book is full of very good stuff. But in the
>midst of all this he makes the recommendation to managers that they
>not hire C hackers.
>
>What if *I* wrote a book, and in it I said:
>
>this is | Managers, whatever you do, don't hire programmers who
>simply an | admit to knowing Eiffel. Eiffel, as a language, poisons
>example and | their minds. People who have been exposed to Eiffel, even
>does not | for only a short time, believe that it is the only true
>relfect the | language in the universe. Moreover, other languages,
>opinion of | and the people who program in them, make them
>the author. | physically ill. Thus, they won't be able to touch
> | your legacy systems without fits of intense nausea.
>
>I think Dr. Meyer, or Ian Joyner, or one of the other notable
>supporters of Eiffel would have a duty to step forward and rebut such
>nonsense.
Not having read Dr Meyers book, I am just talking off the top of my head, but
at least in his rebuttal to your rebuttal doesnt he make it clear that that is
xactly one of the generalizations he *not* trying to make? eg. he says
I have often observed that there is a category of C programmers
(often including people that have used no other language) that
have been so influenced by this machine-oriented approach that
they have trouble adapting to ``programming by abstraction'',
also known as object technology. Those are the ones which
the extract from ``Object Success'' that offended Mr. Martin
calls ``C hackers'', and of course they are a small subset of
the set of C programmers, as the book makes clear.
to make it clear that he is not trying to tarnish all C programmers.
And he goes on to add
actually if I was applying
for a programming job I would probably put C on my resume.
(After all I can explain the difference between int*x[] and
int(*x)[] - I think.) And I certainly expect any programmer who is
a candidate for any programming job today to know C.
But that's not the same thing as being a C hacker - someone
whose entire view of the programming world is defined by
low-level C manipulations.
to make it clear he is not advising potential employers to stay away from C
programmers, just a certain kind of C programmer, whose style or philosophy
of programming, I am sure even they will admit, is the antithesis of
software engineering principles.
And why not Pascal hackers or COBOL hackers? I think it has something to do
with the language. Those languages simply do not permit the style of
programming that C (at least pre-ANSI C) seemed to encourage. And naturally
there arose an entire group of people ready able and willing to take
advantage of their new found high-level programming freedom.
--srin;
Jim Fleming
>
>Jim Fleming (jim.f...@bytes.com) wrote:
>
>: One of the advantages of having a companion language like C+@ is that
>: hackers can continue to work with high-performance C and programmers
>: that are more interested in OO, reuse, portability, etc. can work in
>: C+@. The two populations work well together.
>
>I seem to recall that one of the 8-bit chip vendors - perhaps it
>was Zilog - attempted to introduce a syntactically- compatible
>"family of languages" about 10 years ago. I guess a chip
>manufacturer was the wrong company to try it, because it
>never caught on, but I thought it was a great idea then, and still
>do. The family approach simplified learning and use, because
>common constructs were identical among the languages; e.g., they
>all used the same control statement syntax, for example.
>Of course, these languages were not OO, but that's not the
>issue. OO and companion languages are orthogonal concepts.
>
>From what I remember of the 10 year old attempt, I think I liked
>that language family better, because they gave the appearance
>of the family actually being _designed_. C++ and C+@ seem more
>like shotgun wedding partners. Now, if someone could actually
>_design_ a family of OO languages as a family, we might have
>something worth posting about.
>
>Rick
>
C++ and C+@ mix about as well as oil and water. There is no need for
C++ when C+@ is used.
C+@ was designed to allow easy access and inter-working with C. You
can easily enter C from a C+@ program and you can even reach a C+@
method from C (although this is rarely needed now that the system
is written in C+@).
C+@ was designed from the beginning to be a companion language for C.
The designers were not only experts in language design but also in
real-time systems. This second part has been critical in making the
C+@ execution environment efficient, portable, architecture neutral,
and compact (to improve networked object performance).
Any modern language design must take into account not only the
syntax but also the intended usage as well as the expected level of
support from the environment. To pull all of these pieces together
requires a good working knowledge of all of the components of the
system.
In this day and age, a theoritician can not design a very useful
language. The modern language designer must be 1/5th OO machine architect,
1/5 operating system guru, 1/5th language/compiler guru, 1/5th graphical
interface expert, and 1/5th application domain wizard. The language
guru component is one of the easiest to satisfy and is only 20% of
the required set of skills.
Your idea about a family of languages is an interesting concept. It
has been my experience that the language definition is not where I
would encourage the family but rather the various execution environments.
If the language is simple, it can be easily supported anywhere. The
family approach can be introduced when various class libraries are used
to build functionality on top of the run-time system.
This might result in subsets of the language being deployed, but it
is more likely that subsets of the run-time will be offered. For example,
run-times for networked enterprise environments may be very different
from the run-time for an automobile dash-board.
Also, it will be likely that large companies could specify their own
run-time to ensure that only software created for their system works.
If this occurs then we might have large families of families. For
example, XYZ Corp. might have a family of run-times that are used
in all of their products and even on their centralized support systems.
This would lower their employee training costs and might lock people
into jobs for a longer period of time because of the high cost of
changing jobs and being retrained.
OO lends itself very well to the coming era when software and documents
will be flowing across the Internet. Maybe a family of client/server
systems can be developed to support this flow of information in action.
A well engineered language that was designed from the beginning to
support this type of environment can make life a lot easier.
My suggestion is to look at Java for starters (http://java.sun.com/)
and then C+@, Smalltalk, Eiffel, Oberon, etc. Even though I am biased,
I feel that C+@ has the best integration with C. That is an important
feature which everyone seems to desire in the beginning before they
learn the class library which for C+@ numbers over 350 classes.
Scott A. Whitmire
>It comes as a shock to most people that in fact the dominant programming
>language in the world is COBOL. Counted either by lines of code in production
>or number of employed programmers, COBOL blows everything else away.
Actually, the dominant programming language is (or was) Lotus 123 Macros. It's
probably Excel Macros by now. Yes, spreadsheets are computer programs. They fit
all of the definitions, including having input, processing, and output. Some
companies have go so far as to put their spreadsheets under configuration control.
>While all right-thinking people are aghast that C++ seems to be taking over
>the world, in fact it has a long way to go. And I think it highly unlikely that
>C++ will supplant COBOL. It would be hard to imagine a language worse suited
>to the task. Visual Basic is a far more likely contender (The MS-DOS of
>programming languages).
>Smalltalk seems like the only reasonable language with a shot (sorry, Bertrand)
Although your tone smaks of bigotry and dogma, you're probably right about Smalltalk.
On the other hand, if Visual Basic does win out, the real dominant language will be
C++ (what do you think all those VBXs and OCXs are written in?)
Scott A. Whitmire sco...@advsysres.com
Advanced Systems Research
25238 127th Avenue SE tel:(206)631-7868
Kent Washington 98031 fax:(206)630-2238
Consultants in object-oriented development, network-based
applications, and software metrics.
Ebneter
> This thread has helped me re-evaluate my bigotry against ex-scientists
> who are hired to write software. I think that such an individual may
> have demonstrated a commitment to developing themselves into commercial
> software developers, but if they havn't, a person with 3 degrees in
> science who starts working on commercial software is working on a
> high-school diploma.
Ummm, as opposed to, say, comp. sci. graduates with no concept of the
realities of real-world software engineering?
I'm an astronomy Ph.D. currently working in the commercial software
industry (at Apple). I don't think my science background makes me any more
or less competent as a programmer than any other self-taught programmer,
and in terms of practical software engineering, I may have had _more_
experience than many C.S. grads I've met... but frankly, I wish people'd
just judge programmers on their demonstrated programming skills, not on
their language preferences or their background.
Kate Ebneter
Disclaimer: No one knows I have opinions, let alone agrees with them,
particularly not my employer. AOL User, NOT AOL Newbie.
Robert Martin
>red...@ix.netcom.com (Jerry Fitzpatrick) writes:
>>I've found that fervent criticism says more about the criticizer than
>>the target of their criticism. To say (or imply) that C promotes a
>>hacker culture is like saying that a crowbar promotes break-ins. This
>>is patently false and no amount of boisterous illogic will make it
>>true.
>Machine guns don't promote violence?
No. They don't. A violent person will *use* a machine gun to express
his violence. If no machine gun avails itself, he will pick up a
crowbar, or a big piece of wood, or simply use his fists.
A non-violent person will not pick the machine gun up unless attacked.
Perhaps not even then.
>Sports cars don't promote speeding?
No. Speeders speed in any car they drive. Non-speeders drive sports
cars under the limit.
>Low level languages don't promote low level code?
Nope. Software engineers consider things like lifecycle,
maintainability, reusability, readability, etc. This has no bearing
on high/low level. Lots of high level code can be written in assembly
language.
> (Low level code = anti-software engineering).
This tautology is nonsense. Low level code can, and should, be
engineered. The principles of software engineering apply to the high
and low level equally.
Robert Martin
>Robert Martin closes his diatribe against Bertrand Meyer with:
>>
>>In my opinion, he is very wrong, not only professionally, but moraly.
>>And he owes the industry an apology and a retraction.
>>
>Not any more wrong, professionally or morally, that you are in your
>distorted definition of "hacker" - in fact much less so, I think.
If I have misused the word "hacker", I do apologize. I was not
familiar with the definitions that you posted, and I thank you for
informing me about them. I do, however, think that the definition I
posed is the same that Dr. Meyer was using in his writing.
In any case, Dr. Meyer's recommendation to managers that "C hackers"
should be avoided is still an extremely inappropriate statement. And
the fact that he singles out "C hackers" from other "hackers" is even
more inappropriate.
While I apologize for my ignorance of some of the definitions of the
word "hacker", I do not apologize for brining Dr. Meyer to task for
maligning a class of people.
Robert Martin
>The equivalent passage would have to read: "Avoid programmers who have only
>used Eiffel all their lives and do not see beyond it in the overall scheme
>of business and engineering and refuse to attack practical problems out of
>some odd pique of anal-retentive disgust. etc. etc."
>I think Messrs. Meyer and Joyner and certainly myself would certainly
>*agree* with those sentiments.
Yet, Dr. Meyer said nearly the opposite when he attacked "C Hackers"
specifically. He implied that there were no such things as "Ada
Hackers, Pascal Hackers and Modula Hackers". I presume that the
implication also goes as far as Eiffel hackers.
He was not telling managers to avoid "hackers". He was telling
managers to avoid "C hackers".
>The original concern was about people who do NOT see beyond C, not all those
>ever exposed to it. There was *never* any implication that people exposed to
>C, even for a short time, are forever tainted. The original passage
>said something like "too much time" programming only C.
No, it said: "A 'C Hacker' is someone who has had too much practice of
writing low-level C software and making use of all the special
techniques and tricks permitted by that language."
However, in the very next paragraph he says: (heavily editted) "C
[...] typifies a theology of computing [...]." Which implies that C,
by itself is a religion. He goes on: "Everything is sacrificed to
low-level performance [...].". This is not only greviously incorrect,
but is it also implies universality.
So I disagree. The implication was that exposure to C 'taints'
people into becoming "C Hackers".
>Too much for what? Too much to get any wider perspective, that's
>what.
That's not what he said. And in any case, he singled out C. Had he
said: "Avoid people who are not polylinqual", that would have been one
thing. But no, he advised that people who have had too much exposure
to C should be avoided. And then he went on to paint his rediculous
religion theory which implies that *any* exposure to C is *too much*.
>Dr. Meyer was saying that in his actual empirical observations,
>this can be a problem.
He mentioned nothing about empirical observations. And, I think, that
when you recommend that a group of people not be hired, you should be
very very specific in what constitutes that group (he wasn't), and you
should provide all the data you can to justify such a damaging
recommendation (he didn't).
>Given the predominance of C, it's very unlikely that there are many Ada
>'hackers' or CLOS 'hackers' or Eiffel 'hackers' who have never once used C,
>whereas there are some of these "C hackers" who in fact do NOT have a wiser
>view. This set is NOT by any means the total set of C programmers, or even
>the set of people who program in C most of the time.
This sentiment was not projected in Dr. Meyer's book.
>Dr. Meyer's point is that C is flawed for what he wants to do, and presumably
>what the people in his audience want to do. Using C does not, by itself,
>encourage more sophisticated views of software that he cares about,
No language does. Language does not teach semantics.
>so that
>there may be, *among* those who have lived only C, people who are not
>sympathetic to those views.
Which is like saying: "There may be, *among* those who live in the
next block over, thieves and rapists. So we had better not associate
with the next block."
>He said that in his experience they
>do exist and to watch out for those.
But he provided no criteria other than that they use C.
Rich Miller
Robert Martin <rma...@rcmcon.com> claimed that machine guns don't promote
violence, sports cars don't promote speeding, and that low level languages
don't promote low level code:
>Software engineers consider things like lifecycle,
>maintainability, reusability, readability, etc. This has no bearing
>on high/low level. Lots of high level code can be written in assembly
>language.... Low level code can, and should, be engineered. The principles
>of software engineering apply to the high and low level equally.
Yet a highly successful defense to government "sting" operations is to show
that the defendant was offered an opportunity to break the law that was, in
some sense, too tempting to pass up. The point is that while facilitating
"bad" or "incorrect" behavior may not seem to be the same as promoting it,
at a certain point it does just that. Yes -- low level code can, and should,
be highly engineered -- but it is rarely as well engineered in code written
in languages more appropriate to the task at hand. I venture to guess that
few commercial uses of assembler would not be better served by a higher
level language. This is eloquently discussed (for example) in "The Mythical
Man-month", by Brooks -- the manager in charge of IBM's OS/360 project,
which was (as it happens) written in assembler....
-- Rich Miller (rmi...@wolfe.net)
Anil Joshi
>No language does. Language does not teach semantics.
Language may not teach semantics but the syntax should be close
to the semantics. C probably is the only language that has no relation
between syntax and semantics.
Ex:
1. i++;
2. a += b;
3. Declaration syntax
I can come up with more examples if I think about it long enough.
>--
>Robert Martin | Design Consulting | Training courses offered:
>Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
>2080 Cranbrook Rd. | Tel: (708) 918-1004 | Mgt. Overview of OOT
>Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.
Anil Joshi
jo...@cs.uiuc.edu
--
Sathsangatve nissangatvam From good company to no company
Nissangatve nirmohatvam From no company to lack of desire
Nirmohatve nischalatatvam From lack of desire to concentration of mind
Nischalatatve jeevanmuktihi From concentration of mind to liberation of life
Jay Martin
>jma...@cs.ucla.edu (Jay Martin) writes:
>>red...@ix.netcom.com (Jerry Fitzpatrick) writes:
>>>I've found that fervent criticism says more about the criticizer than
>>>the target of their criticism. To say (or imply) that C promotes a
>>>hacker culture is like saying that a crowbar promotes break-ins. This
>>>is patently false and no amount of boisterous illogic will make it
>>>true.
>>Machine guns don't promote violence?
>No. They don't. A violent person will *use* a machine gun to express
>his violence. If no machine gun avails itself, he will pick up a
>crowbar, or a big piece of wood, or simply use his fists.
Then why are they banned?
Is because they can do more damage with machine guns or nuclear weapons.
This can be directly applied to hackers with C.
>A non-violent person will not pick the machine gun up unless attacked.
>Perhaps not even then.
>>Sports cars don't promote speeding?
>No. Speeders speed in any car they drive. Non-speeders drive sports
>cars under the limit.
Then why do insurance companies charge more to insure them?
Answer: its easier and more fun to go fast in a Porshe, than
a some piece of crap car.
>>Low level languages don't promote low level code?
>Nope. Software engineers consider things like lifecycle,
>maintainability, reusability, readability, etc. This has no bearing
>on high/low level. Lots of high level code can be written in assembly
>language.
Nope. High level code must be written with high level constructs.
Maximum lifecycle, maintainability, reusability and readability can only
occur with high level code.
>> (Low level code = anti-software engineering).
>This tautology is nonsense. Low level code can, and should, be
>engineered. The principles of software engineering apply to the high
>and low level equally.
Good software engineering dictates the minimization of low level code
in a system. C promotes the use of low level code where high
level is appropriate. Anyone who doesn't understand this
does not understand software engineering. Software engineering is
not just shoving in comments in poorly designed puke.
It is pretty obvious to me that the C philosophy is based on wacko
libertarian political beliefs which have little use in cooperative
software development.
Jay
Robert Martin
>I agree with good ol Dijkstra: "COBOL programmers are braindamaged for
>life"
I have never seen anything like that attributed to Dijkstra. If he
*did* actually write something like that, then I will be disappointed.
But it has always been true that a person's technical genius has
nothing to do with his moral genius. (Witness Isaac Newton.)
>(Substitute COBOL with C).
You can't agree with good ol Dijkstra and then change the words on
him.
> People get locked into old
>restricted ineffective modes of thought everyday.
Yes, like sneering at the tools that other people use.
Robert Martin
>And why not Pascal hackers or COBOL hackers? I think it has something to do
>with the language. Those languages simply do not permit the style of
>programming that C (at least pre-ANSI C) seemed to encourage.
It is just as easy to hack in Pascal as it is in C or Fortran or COBOL
or assembly language or even Eiffel. Hacking is a behavior, not a
language feature. The ability, or predisposition, to hack has nothing
whatever to do with C or any other language.
James Logajan
: Do a web search. What you get is all there is.
: [>==========Des Herriott, 7/5/95==========
: [>
: [>I have a suspicion I might get flamed for my ignorance here, but
: [>what is C+@? I've never heard of it, speaking as a C programmer.
: [>Where I can find references to it, examples of it, and how does it
: [>obsolete C++?
I think that is precisely what he was doing by posing the question to
the only known general purpose "natural language" search engine currently
available on the Internet: he posted a Usenet news article to all the search
engines (humans with memories), and looked for a response. Looks like one
of the search engines generates the occasional null response. Maybe its
got a bug.
Dongxiao Yue
[deltetion ...]
>I have often observed that there is a category of C programmers
>(often including people that have used no other language) that
>have been so influenced by this machine-oriented approach that
>they have trouble adapting to ``programming by abstraction'',
>also known as object technology. Those are the ones which
>the extract from ``Object Success'' that offended Mr. Martin
>calls ``C hackers'', and of course they are a small subset of
>the set of C programmers, as the book makes clear.
[deletion ...]
I think the paragraph in your book is misleading and prejudicial to
C programmers. You basically said "C Hackers" are no good.
But you did not give a precise definition of the term "C hacker",
does it mean:
1) an experienced C programmer who writes optimized C code.
(seems to be what you are referring to)
or/and 2) an inexperience / experienced C programmer who writes
non-portable C code. You mentioned C hackers do "low-level"
programming. Does not make sense to me, since C is not a machine
language. And the low-level building blocks for C++ is
largelly C. C++ is C++.
or/and 3) a C programmer that is very knowledgeable about Computer Science
(especially OSes) and apply them in C programming.
(this is my usage of the term "C hacker").
or/and 4) others
?
Without a clear definition, the term "C hackers" would be overly generalized.
If your definition is 1) or 3), ...
If 2) , I will use the term "bad C coder" instead of "hacker"
Furthermore, do you have any data to support your claim, or just pure
heresay. If you do, you should at least list some examples, in which
a "C hacker" ruined C++ development.
D. Yue
A C++ compiler writer.
Igor Chudov @ home
* sned...@us.oracle.com (Srinvas Nedunuri) writes:
* It is just as easy to hack in Pascal as it is in C or Fortran or COBOL
* or assembly language or even Eiffel. Hacking is a behavior, not a
* language feature. The ability, or predisposition, to hack has nothing
* whatever to do with C or any other language.
What would be the methods to prove your assertion? A vote, a statistical
survey among managers, cost of maintaining a thousand lines of code/a
similar project?
John DiCamillo
>>Machine guns don't promote violence?
>No. They don't.
Um. Actually, they do (or at least, they appear to).
A couple of months ago, Time magazine published an article on
the "rising tide of violence" or some such. In the article,
they refer to a study of people's response to the presence of
weapons. In that study, people behaved more violently when
just the pictures of weapons (including machine guns :-) were
present in the environment. I think they called it "the weapon
effect".
Completely off topic, I know, but this thread hasn't had much
of a topic in a while anyways.
--
ciao,
milo
================================================================
John DiCamillo Fiery the Angels Fell
mi...@netcom.com Deep thunder rode around their shores
Des Kenny
Jerry Fitzpatrick <red...@ix.netcom.com> wrote:
> In <3tap9h$q...@saba.info.ucla.edu> jma...@cs.ucla.edu (Jay Martin)
> writes:
> >
> >>What is a hacker? A hacker is someone who writes computer programs
> >>without employing sound principles of software engineering. Someone
> who
> >>simply throws code together without thought to structure or
> lifecycle.
> >
> >Good definition.
> >
> >> Certainly there are hackers who use C. But there are Hackers who
> use
> >> every language. And in this, Dr. Meyer is quite negligent, for he
> says
> >> nearly the opposite:
> >
> >> Why single out C? First, interestingly enough,
> >> one seldom hears about Pascal hackers, Ada hackers
> >> or Modula hackers.
> >
> >> This may or may not be true, I have no statistics. However, *if* it
> is
> >> true I would be willing to bet that the reason has something to do
> with
> >> the difference in the number of C programmers as compared to Ada,
> Pascal
> >> and Modula programmers. If there are 20 times as many C
> programmers,
> >> then there are probably 20 times as many C hackers.
> >
> >Oh come on! If you are libertarian lone cowboy hacker which language
> >with its corresponding philosophy are you going to embrace, the macho
> >culture of C or the protect you from yourself, nanny-istic, shove
> >software engineering down your throat culture of Ada/Eiffel?
> >C is a magnet to hacker types.
> >
> >> My point is that C does not predispose someone to be a hacker. And
> that
> >> the ratio of C hackers to C programmers is probably the same as Ada
> >> hackers to Ada programmers.
> >
> >Rabid worship of C increases the probabilty the person is a hacker.
> >Why? The basic tenents of C culture are anti-software engineering.
> >
> >> support this rediculous claim. He states it as fact. This is an
> abuse
> >> of authority. What every author fears, (or ought to fear in my
> opinion)
> >> is that he cast his own opinions as unalterable truth. Yet, rather
> than
> >> proceed with trepdiation, Dr. Meyer seems to glory in his
> deprication of
> >> C.
> >
> >As anybody in this field knows, proof (aka research study) is a
> >red herring. The only ones who have the time to such research
> >studies are academics and they won't because they all have their
> >heads too far up their theoretical butts. Dr. Meyer thus states the
> >facts given his experience.
> >
> >> Here he names every evil trick and bad practice that he can, and
> >> ascribes it all to C, as though no other language had the capability
> of
> >> supporting bad practices. He also claims that C programmers
> religiously
> >> follow these bad practices as the sacrements of their religion.
> >
> >(1) C makes low level code extremely easy to create and the C culture
> > says that low level code is cool.
> >
> >(2) Many C programmers follow these bad practices.
> >
> >> These statements are extremely irresponsible. There is no basis of
> fact
> >> that Dr. Meyer has supplied for these extreme accusations and
> >> defamations. Dr. Meyer has a right to dislike C if he chooses. But
> his
> >> vehemence against its programmers is unreasonable, and unreasoned.
> >
> >I have met tons of C hackers / software incompetents.
> >
> >> In fact, I have never met a single C programmer
> >> who fits the description that Dr. Meyer ascribes to them all.
> >
> >Wow, you must really be sheltered or have really low expectations.
> >
> >> In my opinion, he is very wrong, not only professionally, but
> moraly.
> >> And he owes the industry an apology and a retraction.
> >
> >sterile "I have no position / all approaches are equal and based
> >on personal preference" crap.
> >
> >> There is only one word that can accurately describe these
> sentiments.
> >> That word is biggotry. I don't like to use a word like that to
> >> describe the words of someone who is obviously intelligent.
> >
> >> So Dr. Meyer casts aspersions upon all C programmers while giving
> >> amnesty to Ada, Pascal and Modula programmers. According to Dr.
> Meyer,
> >> it is only, or especially, the "C hacker" that you must be wary of.
> He
> >> does not say: "Beware of Hackers", rather he says: "Beware of C
> >> hackers." And this is simply biggotry, the segregation and
> defamation
> >> of a class of people based only upon the language that the program
> in.
> >
> >If I judge a programmer to be software incompetent, then I have no
> >problem labelling that person as such. Unthinking worship of some of
> >the more idiotic parts and culture of C are in my view a
> >demonstration of their incompetence. I will do everything in my
> >disposal to get that person far away from my project. I guess I am a
> >bigotted against software engineering incompetents. Bigotry must be
> >good if it keeps hackers away!
> >
> >I have high standards, thus I see that the software industry is strewn
> >with incompetent programmers. I am sick of this everyone is a genius
> >/ respect their artistic integrity and personal preference / kiss
> >everyones butt attitude in software (which leads to not getting
> >answers and thus poor software). I am sick of the lack of definition
> >in this field of what is good and what is bad, the only way to answer
> >these questions are research studies, yet no one is doing them!
> >
> >I can understand apathetic programmers, "Hey Bob, why do you use that
> >shitty tool? Bob: Because I am a bonehead!". C Hackers are more
> >fanatical, they are usually convinced of their brilliance and
> >religious devotion to their C dirty-tricks. Getting these people to
> >use a software engineering language is nearly impossible. The
> >prototypical C hacker even curses Stroustrup for some of his less than
> >worshipful comments on certain aspects of C.
> >
> >> Had you simply attacked C, I would not have responded. Rather, you
> >> attacked the characters of people. This required a response.
> >
> >I don't really understand this defense of the "character" of people.
> >In my cynical view most people are either "assholes" or "idiots" (or
> >both). In the programming world, the biggest assholes are the
> >"hacker" types who basically don't give a damn that you will have to
> >maintain their excrement for years to come. There really should be
> >prison terms for these programmers.
> >
> >Jay
> >
>
> I've found that fervent criticism says more about the criticizer than
> the target of their criticism. To say (or imply) that C promotes a
> hacker culture is like saying that a crowbar promotes break-ins. This
> is patently false and no amount of boisterous illogic will make it
> true.
If I have an industrial task to perform I prefer to use the tool that is
most effective for the task. It should also be the most efficient and
in general terms the most economic for the project and the overall
strategy and constraints of the organisation, which may not mean it
is the cheapest tool on the market.
This is not always an easy judgement to find an optimal solution.
As Technology advances we are presented, we hope, with more optimal tools.
(At which point we often chase harder problems with these new and
powerful tools. Maybe we are all just masochists at heart)
Effectivenes:
It seems from what little we understand about how our brains work,
that we deal with complexity by abstracting it to a level where we can
cope with it and still have some connection with a very detailed and
complex reality, such as it is.
So it seems reasonable to me that languages, indeed any tools, should
continue to evolve to higher and higher levels of abstraction, hiding
detailed mechanisms and processes from us so that we can deal with a
wider range of problems and let the lower machine levels take care
of the details.
Most engineering/industrialisation has followed this path. Indeed
most successful evolutions of any kind seem to follow this trend.
It is quite amazing to reading how extremely complex and ingenious
the internal biological mechanisms of our bodies, organ systems,organs,
cells, subcellular, biochemical, chemical, atomic, subatomic,
quantum...(?) processes are. Yet they all proceed, hopefully,
and most of the time, without a moments thought.
The path to evolutionary success is abstraction. We and other
natural systems encapsulate behaviour by abstraction.
If we don't do this we are overwhelmed by complexity. We may battle
on using arcane skills, which were once shiny and new. But are we
evolving or stagnating when we exhibit this behaviour in industrial
tasks?
The hardware vendors are following this evolutionary growth strategy.
If a component can be encapsulated in an effective and efficient way
then they do it. There are hardware levels of abstraction.
This is an economical way to develop hardware systems.
Dealing with software complexity is similar. We should raise the
level of software abstraction to as high a level as we can, given
the machine resources available. As hardware resources become
rapidly more abundant and cheaper then we should raise the level
of abstraction of the software to take advantage of this abundance.
So we delegate more details to the lower levels of the virtual machine
to deal with.
We can then raise our sights to solving more advanced industrial problems,
or even playing more advanced games.
There is a place for people who want to use lower level tools.
Sometimes the combination of circumstances requires a lower level tool.
There may be very limited hardware resources for the task at hand,
although this should be a decreasing problem.
There are people that enjoy tinkering at lower levels of abstraction.
They want to work at a lower level because it satisfies some need in them.
I am not going to try to define what that need is, because it is probably
far too complex, and is not the issue here.
There are people that enjoy being blacksmiths, some people pull cars or
TVs or whatever to bits. Fair enough, this is their hobby, and long may
they enjoy it. There are craft activities where people deliberately use
older technologies for all sorts of reasons.
They consciously choose to use less economic tools because they enjoy
doing so and/or there is a market for craft products that satisfies
their needs. OK, each to their own lifestyle.
There is a continually evolving pattern in all systems. Today's advanced
abstract method will be tomorrow's less technically advanced hobby.
However, if we are talking about industrial tasks then we are constrained
by economics. We should pick the most economical tools to perform the task.
Since we are most effective in solving problems when we can raise them
to the highest level of abstraction that we know how to handle, then we
should choose the tools that are most suited to this high level of
abstraction. The tools should not allow us to go to any lower level of
detail than is neccesary within the constraints of the hardware and
other resources. We should be continually delegating details to the
lower levels. This is the nature of the evolution of management in all
complex systems,human or otherwise.
So if we don't really need all the low level capabilities of C for
a task then we should not use such a tool that allows such low
level capabilities. Otherwise there is a danger that we are confusing
the most economic way to develop software with a hobby activity where
we are really tinkering, because it is fun, or maybe because we are
not evolving our skills to a more abstract level to deal with more advanced
problems. It may be comfortable to remain at a lower level of abstraction,
but it is probably somewhat risky as others move upwards to deal with
higher level problems.
Gradually, or maybe suddenly, nobody will want to pay for
such low level skills anymore. Then people that insist on being C
programmers will become the blacksmiths of programming.
If you think this is unlikely to happen, think about the tiny, shrinking
market for assembler programmers. Also I have heard of people developing
native Eiffel compilers, so no C will be required at all to develop
applications in Eiffel, provided the hardware is not severely
constrained for the task, again a decreasing problem.
These compilers will be written in Eiffel and generate native code.
Suddenly the level of abstraction will jump a few quantum levels.
Why would anyone then want to descend to the lower levels that C makes
possible, only if hardware is the constraint, or they are tinkering as
a hobby because it's fun.
If the task requires a lower level tool such as C because the hardware
is too limited then there is not much choice. I can't really see any
other strong argument for using C for industrial tasks.
Because C++ also allows access to such lower level capabilities I think
it goes against a direction of increasing abstraction, which conflicts
with the general trend of more econonic development of systems. I believe
that this will become an increasing disadvantage, as it is already for C,
when it is used at times that it is not really required.
> 'Nuff said.
Maybe, maybe not.
Cheers
--Des Kenny
Suresh Vaidyanathan
>Good software engineering dictates the minimization of low level code
>in a system.
And Localization.
>C promotes the use of low level code where high level is appropriate.
Not True! May be your teacher promotes that.
Software design attempts to layer the complete system into multiple layers,
each at a different level of abstraction, going from high-level (domain specific)
to low-level (machine specific).
`C' (or for that matter any other language that you have to write in)
knows little about the domain.
An ignorant Eiffel programmer (hacker? by B.M.) could well design
a class called Memory_Allocator and do the allocation and deallocation
himself, where unnecessary.
> Anyone who doesn't understand this does not understand software engineering.
Anyone who makes such a statement has at least 2 more years
left before graduation (I hope).
>
>Jay
>
Steven D. Majewski
Robert Martin <rma...@rcmcon.com> wrote (in reply to Bertrand Meyer's
reply to his rebuttal that started this thread. ):
>
>This kind of consideration is what was missing from your book. The
>statements in your book were far more intense and all inclusive. So
>I consider the words you have written here as a retraction of the
>*tone* of your book. The fact that you admit that there are many
>examples of excellent programming in C, is a relief to me. I wish you
>had said so in your book.
>
What a trick! ( What gall! )
First you distort what Bertrand Meyer wrote.
Then you deign to take his clarification and correction of
YOUR words as a retraction of what he never wrote in the
first place.
>No, the book does not make this clear. That was my problem.
Other than the excerpt in your post, I have only read a bit of
his book while standing in Barnes and Noble, but that quote did
not support your misreading of his words.
Bertrand Meyer said in his reply:
>>It is really surprising to see how thin-skinned some representatives
>>of the C/C++ community are.
One of the characteristics of the hacker is an emotional attachment
to the tools of computing, and a tendency to focus on the PROCESS of
programming, rather than the goal or outcome of a particular project.
( This admission from a self-confessed hacker, who believes that you
can fight the tendency towards premature coding, as well as the
tendency to react irractionally when "the object of desire" ( a
particular programming language ) is criticised. I reject, however,
Robert Martin's slanderous definition of a hacker. See instead:
<http://wombat.doc.ic.ac.uk/?hacker> )
>
>Had you simply attacked C, I would not have responded. Rather, you
>attacked the characters of people. This required a response.
>
In an earlier post, Robert Martin said:
> In my opinion, he is very wrong, not only professionally, but moraly.
And *THAT* isn't attacking someone's character ( *morally* wrong ? ) ?
Dr. Meyer *is* guilty of advising people to consider a (choose one
of the following, depending on how you want to bias the outcome):
stereotype
generalization
prototypical member of a group
when evaluating an individual.
Some consider this action ALWAYS invidious.
I think, however, that it's natural and unavoidable. We always
consider a person's *category* - their degree, their college,
their appearance, their favorite programming language - when
we don't know enough to judge them AS individuals. The invidious
thing is to forget that that is a very unreliable and preliminary
judgement of a unique individual. I think Dr. Meyer was stepping
on a fine line ( as we all do ) by saying "Beware of C hackers",
but I think he did make that line clear enough to not be judged
'morally wrong'.
As to whether his characterization of that stereotyped "C hacker"
was accurate or not - several people have already chimed in that
they recongnize his description as quite accurate. That is admittedly
opinion, and you are free to disagree, but to characterize those who
disagree with you as "wrong, not only professionally, but moraly"
is TRULY WRONG, not only professionally, but moraly!
>
>Had you simply attacked C, I would not have responded. Rather, you
>attacked the characters of people. This required a response.
>
Shall we read that as a retraction and an apology ? ;-)
---| Steven D. Majewski (804-982-0831) <sd...@Virginia.EDU> |---
---| Computer Systems Engineer University of Virginia |---
---| Department of Molecular Physiology and Biological Physics |---
---| Box 449 Health Science Center Charlottesville,VA 22908 |---
BTW: Programming Languages Critiques page at
<http://minsky.med.virginia.edu/sdm7g/LangCrit/>
Suresh Vaidyanathan
Jay Martin <jma...@cs.ucla.edu> wrote:
>What K&R hacked 20+ years ago was fine technically given the times and
>having the constraint of 50k of memory. Nowdays Unix and C are really
>poor examples of computer software and are widely seen as holding back
>the software/operating field.
>If you want to hold K&R up as dieties,
>then I must give my my opinion that their work from that era would
>qualify them as software engineering clowns today.
Just this statement from you will qualify you as a chief-clown without
qualification.
>Software engineering dictates the use of quality tools.
Great tools in the hands of an idiot will be of no use. As you
will find out (my optimism shows) 20 years after you graduate
(if you do, that is).
>Jay
Suresh Vaidyanathan
>>In article <1995Jul4.1...@rcmcon.com>, rma...@rcmcon.com (Robert Martin) writes:
>>|>
>>|> I refer you to the "The C Programming Language" by Kernighan and
>>|> Ritchie (any edition) for a good example of the counter view. The
>>|> authors are very sensitive to software engineering principles, and
>>|> stress them throughout the book.
>
>>
>>The authors may be sensitive to software engineering principles, I don't know, but
>>what I think of as software engineering principles are certainly not
>>stressed throughout the book ...
>>There is little about how to structure code to make it maintainable or
>>readable.
The `C' book had one purpose - describing the usage of `C'.
(This in itself [ Do one thing in one module. And Do it well. ]
is a principle tacitly advocated by K&R,
that a software engineer would do well to follow.)
If you want principles, go read Kernighan & Plauger. And then
re-read K&R. And you will realize how well each example in the `C' book
extolls the principles laid out there.
>>They do mention that you can use the underscore to make long
>>variable names more readable of course they don't use any of these
>>long variable names instead prefering "bufp", "strcmp", "tnode" etc.
If you are arguing that this is the great software development principle
that K&R have chosen to not follow, I think that you are grasping at straws.
Long variable names by themselves do not make code more
understandable. Is "the_big_buffer_pointer" contain any more information
than bufp? Or "avl_balanced_tree_node" more than tnode? Especially, inside
the "balance_tree" function? In fact, for highly localized auto-variables
a small name is much preferred.
Long variable names have their place. When you have to do a mental context-switch
to remember the context surrounding the variable.
Only dogmatics(?) would insist that long names should be used universally.
Robert Martin
>In article <1995Jul5.1...@rcmcon.com>,
>Robert Martin <rma...@rcmcon.com> claimed that machine guns don't promote
>violence, sports cars don't promote speeding, and that low level languages
>don't promote low level code:
>Yet a highly successful defense to government "sting" operations is to show
>that the defendant was offered an opportunity to break the law that was, in
>some sense, too tempting to pass up.
Right. An officer of the law is not allowed to tempt people to break
the law, and then prosecute them. In our culture, this is called
entrapment.
However, C is not an active agent, like an officer. An officer may
'entrap', but C cannot. C cannot plan an entrapment stragtegy.
Now, are their constructs in C that can be abused. Yes. But such
constructs exist in every language. Are ther constructs that
*promote* bad practice? No, the very idea is absurd.
If a man sells you a stolen watch at a price that cannot be beat. Then
you are guilty of a crime, and the man bears some responsibility as
being the facilitator. But if you kill someone with a hammer, the
hammer is not guilty of a crime.
Now, are there dangerous constructs in C? Yes. Are they too
dangerous? In many cases yes? I prefer to use stronger typing to
avoid these dangers. But do these dangers turn ordinary programmers into
depraved C hackers? No.
There is nothing mutagenic about C. It does not turn Kung-fu masters
into rats, nor turtles into pizza loving martial artists. C is just a
language that some of us use sometimes.
Robert Martin
>It is pretty obvious to me that the C philosophy is based on wacko
>libertarian political beliefs which have little use in cooperative
>software development.
Wacko libertarian political beliefs. B^) UuuuuuuHUH. Right. OK.
Jay Martin
>In article <3tc1eq$h...@saba.info.ucla.edu>,
>Jay Martin <jma...@cs.ucla.edu> wrote:
>>What K&R hacked 20+ years ago was fine technically given the times and
>>having the constraint of 50k of memory. Nowdays Unix and C are really
>>poor examples of computer software and are widely seen as holding back
>>the software/operating field.
>>If you want to hold K&R up as dieties,
>>then I must give my my opinion that their work from that era would
>>qualify them as software engineering clowns today.
>Just this statement from you will qualify you as a chief-clown without
>qualification.
If you don't have understand the lack of software engineering quality
of C and Unix you are indeed the clown. Unix and C are terrible and are
causing great damage to the software industry and research communinity
by holding back progress.
>>Software engineering dictates the use of quality tools.
>Great tools in the hands of an idiot will be of no use. As you
>will find out (my optimism shows) 20 years after you graduate
>(if you do, that is).
Ah the pinhead, "You can abuse any tool" (you can crash any car) C
hacker argument, great excuse for never thinking about better tools
or the understanding that software is a social undertaking with many
less than brilliant project members. The more you talk the more you
sound like the "C hackers" you are defending.
Sorry, but I have 10 years industry experience, BSs in Computer Science
and Mathematics and a MS in Computer Science and am currently in
a PHD program in CS. I like have an extensive background and most likely
like many who disagree with you in this newsgroup.
Jay
Matthew Kennel
: * It's the programmer and not the language.
: You are totally right.
Then why don't we use 370 assembly?
Why should we use C++ instead of faking object-orientation with
function pointers in C? Or BLISS? Or.....
accomplishment = power(language)*power(tools)*programer.ability(language)
lim(accomplishment,programer.ability(alpha) alpha in all_language -> 0) = 0.
Matthew Kennel
: sned...@us.oracle.com (Srinvas Nedunuri) writes:
: >And why not Pascal hackers or COBOL hackers? I think it has something to do
: >with the language. Those languages simply do not permit the style of
: >programming that C (at least pre-ANSI C) seemed to encourage.
: It is just as easy to hack in Pascal as it is in C or Fortran or COBOL
: or assembly language or even Eiffel. Hacking is a behavior, not a
: language feature. The ability, or predisposition, to hack has nothing
: whatever to do with C or any other language.
It does not?
It could be that 'hackers' in other language have bad habits of their own,
but not the particular ones that Bertrand is railing against.
What are they programming today?
Let's take over all the whole world those black-hat "bad" hackers who
find it too difficult or alien to think abstractly in the particular
way that Dr. Meyer is talking about.
What language are they programming? (Given that they have some free
choice of their own.)
I'd say 10% use mostly assembly, 80% use mostly C, and 10% use mostly
everything else.
Anybody think the reality is strikingly different from this guess?
Remember, Dr. meyer did specifically consider take COBOL programmers and
said that he had less difficulty than with the 'C hackers'.
: Robert Martin | Design Consulting | Training courses offered:
cheers
Matt
Igor Chudov @ home
* Igor Chudov @ home (ich...@star89.galstar.com) wrote:
* : * It's the programmer and not the language.
* : You are totally right.
* Then why don't we use 370 assembly?
Matt,
You, too, are totally right. :) Sorry for not expressing myself clearly
enough. In fact, you snipped too much from my post - I agreed with him
that we sometimes put too much emphasis on tools vs. techniques, not
just to the last phrase about programmers vs. languages. And my point
was that C is not just a tool, it is a fact of our life.
Joshua Dunfield
>jma...@cs.ucla.edu (Jay Martin) writes:
>
>>I agree with good ol Dijkstra: "COBOL programmers are braindamaged for
>>life"
>
>I have never seen anything like that attributed to Dijkstra. If he
>*did* actually write something like that, then I will be disappointed.
>But it has always been true that a person's technical genius has
>nothing to do with his moral genius. (Witness Isaac Newton.)
From "How Do We Tell Truths That Might Hurt?" in _Selected Writings
On Computing: A Personal Perspective_:
"The use of COBOL cripples the mind; its teaching should, therefore,
be regarded as a criminal offence."
...
"It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers
they are mentally mutilated beyond hope of regeneration."
-jcd
Matthew Kennel
: >Machine guns don't promote violence?
: No. They don't. A violent person will *use* a machine gun to express
: his violence. If no machine gun avails itself, he will pick up a
: crowbar, or a big piece of wood, or simply use his fists.
And likely not kill.
That is the point of being wary of "C" + "hackers" (in the pejorative sense).
: Robert Martin | Design Consulting | Training courses offered:
: Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
ma...@godzilla.eecs.berkeley.edu
> : It is just as easy to hack in Pascal as it is in C or Fortran or COBOL
> : or assembly language or even Eiffel. Hacking is a behavior, not a
> : language feature. The ability, or predisposition, to hack has nothing
> : whatever to do with C or any other language.
>
> It does not?
>
> It could be that 'hackers' in other language have bad habits of their own,
> but not the particular ones that Bertrand is railing against.
I agree. The word "hackers" might have been slightly the wrong one:
what Dr. Meyer was talking about, specifically, was having too
low-level a view of programming, thinking too much about registers and
clock cycles and bit twiddling instead of the problem domain.
"Hacker" has slightly that connotation, but it has other connotations
as well.
I don't think it's really possible to be a "hacker" in that sense if
you're mainly using Pascal or Eiffel---in fact, since low-level
programming is sometimes necessary, you might even think of that as a
criticism of those languages.
--
Matt Austern ma...@physics.berkeley.edu
http://dogbert.lbl.gov/~matt
Robert Martin
>In article <1995Jul4.1...@rcmcon.com>, rma...@rcmcon.com (Robert Martin) writes:
>|> jma...@cs.ucla.edu (Jay Martin) writes:
>|>
>|> >Rabid worship of C increases the probabilty the person is a hacker.
>|> >Why? The basic tenents of C culture are anti-software engineering.
>|>
>|> I refer you to the "The C Programming Language" by Kernighan and
>|> Ritchie (any edition) for a good example of the counter view. The
>|> authors are very sensitive to software engineering principles, and
>|> stress them throughout the book.
>If I didn't know better I'd say you hadn't read the book. The authors
>may be sensitive to software engineering principles, I don't know, but
>what I think of as software engineering principles are certainly not
>stressed throughout the book.
>There is no concept of the software life cycle so obviously there is
>nothing on how the various features of C affect this life cycle. There
>is little about how to structure code to make it maintainable or
>readable. They do mention that you can use the underscore to make long
>variable names more readable of course they don't use any of these
>long variable names instead prefering "bufp", "strcmp", "tnode" etc.
Look at the programs themselves. There are no (or very few) gotos.
All functions are small, and nicely cohesive. A reasonable level of
abstraction was used throughout. In 1978, this was what software
engineering was! Concepts like Structured Analysis and Structured
Design had not yet taken the fore. The issues back then were
structured and modular programming.
And long variable names? Jeez, most C compilers in 1978 balked at
more than 8 chars in the symbol names. Most linkers balked at 6.
>It is obvious from the design of the language that many problems such
>as program reliability, and coherency were not addressed during the
>design of the langauge and are still weak spots in C++.
>Maybe you could elaborate on these software engineering principles
>that are "stressed throughout the book."
No, you are right. K&R is not a modern software engineering handbook.
However, in 1978, it did a very good job of espousing the popular
principles of the time. Those principles are still important, but we
know a lot more now.
Remember, Jay was contending that "The basic tenents of C culture are
anti-software engineering." My point was the K&R denies this. You
have pointed out that, by todays standards, K&R does not promote
strong software engineering principles. But by the standards of the
time they were.
--
Robert Martin
>I, too, have seen that there are C programmers who are quite capable of
>writing quality software. However, that doesn't change the general
>impression that I have of a sizable number of C programmers and the
>software for which they are responsible.
>One brief example. A couple of years ago, I had a look at a copy of
>the C snippets collection that moves around the Internet. In particular,
>I looked at one of the random number generators that was billed as
>the fastest good RNG around. I wasn't impressed. Fast it was. Random it
>wasn't.
Clearly, this is the fault of the language it was programmed in. If
that same programmer had only used Pascal or Modula, or Ada (language
that don't force you to become a hacker) his algorithm would have been
correct. ;)
>Personally, I do most of my programming in Modula-2. When I am pro-
>gramming for the PC, I found that I *have* to add extra code to
>catch other programs (*invariably* written in C -- given the copyright
>messages in the executable code) that have stomped over my data.
Again, clearly the language is evil. Those poor programmers would
have written much better code if they only hadn't used C.
>While I am sure that there are some poor programmers and outright
>code hackers who use Ada, Pascal and Modula-2, my own observation is
>that they tend to be few and far between. Amongst C programmers,
>however (and *unfortunately*), I have seen a shockingly large number
>of them.
The law of large numbers I am afraid. The important question to ask
yourself is if the *ratio* of good/bad programmers is higher in any
particular language.
Suresh Vaidyanathan
Robert Martin<rma...@rcmcon.com>
>-------------------------------------------------------------------------
>PRUDENT HIRING PRINCIPLE: Beware of C hackers.
>
>
> C ... typifies a theology of computing where the Computer is the central
> deity and its altar reads Efficiency. Everything is sacrificed to
> low-level performance ...
> In this almost monotheist cult, where the Microsecond and the Kilobyte
> complete the trinity, there is little room for such idols of software
> engineering as Readability, Provability and Extendibility.
This is just plain wrong! It looks like Meyer in his self-serving enthusiasm
to push Eiffel is indulging in blatant vilification of C. It is a clever
attempt to portray C as nothing but another assembly language, suitable only
for low-level programming. Of Course, we in the industry know that C has enough
mechanisms to support high-level programming, and complex systems such as X
have been built and are being maintained using it.
Of Course, this is not to suggest that C is the be-all and end-all of
all software development. If Meyer had said something to this
effect, he would not have gotten any argument from the practitioners.
It is unfortunate that someone in the position of Betrand Meyer,
who commands a great deal of respect from the software community is not
more measured in his statements. A greater disservice of this act is that
net-weasels (you-know-who) use these irresponsible statements to malign
and throw stones at successful practitioners, who have been more than kind
to contribute useful and interesting posts on this group.
>Not surprisingly, former believers need a serious debriefing before
>they can rejoin the rest of the computing community and its progress
>towards more modern forms of software development.
Once again, an ominous comment which is also a serious falsehood.
To date, the most successful products that have been delivered
and are being maintained (UNIX, X, Microsoft products) have all
been written in C. Even OO which holds great appeal to the serious
software engineer, has not proven itself to this degree as yet.
David Hanley
: I have a suspicion I might get flamed for my ignorance here,
The only thing you might get flamed for is encouraging Jim
Flemming. soon to be inducted to net.kooks.
: but
: what is C+@? I've never heard of it, speaking as a C programmer.
: Where I can find references to it, examples of it, and how does it
: obsolete C++?
This group is the probably the only place you'll ever hear of
it. From all appearances, it's a language being promoted by one
person who has shown himself to be a poor programmer, as well as
psychologically unstable. The language appears to be relatively
useless for several reasons:
1) Other languages exist that do the same things, and better. ( Smalltalk,
Modula-3 , C++ , ML )
2) It appears to encompass some pretty bad concepts( A wealkly-typed
C-like OOP language, etc).
3) No one can get a compiler, code samples, language definition, etc.
Some of his claims about the user base are obviously
falsifications, you must understand. Furthermore, when he flames C++,
keep in mind, he claims not to know anything about C++.
--
------------------------------------------------------------------------------
| David James Hanley, KSC--d...@lac.eecs.uic.edu -- C++, OOD, martial arts|
| Laboratory for advanced computing | My employer barely KNOWS me. |
------------------------------------------------------------------------------
Remember: Adolf Hitler died for your sins.
Igor Chudov @ home
* If you don't have understand the lack of software engineering quality
* of C and Unix you are indeed the clown. Unix and C are terrible and are
* causing great damage to the software industry and research communinity
* by holding back progress.
Please elaborate.
* Ah the pinhead, "You can abuse any tool"
... snip ...
* Sorry, but I have 10 years industry experience, BSs
The problem is that we take too many "principles" too seriously.
Remember that everything that has not been proven with mathematical
quality is a matter of belief or personal benefit. None of the theories
telling what should be "good engineering" in programming has been proven
as a mathematical theorem. So, we should treat them accordingly - only
as unproven propositions that may be useful or not.
After all, every principle has been invented by some human being for
other human beings. Therefore, if a principle is actually working and
helps those other humans, it is great. Note that the reverse is not true
- a principle that is not working may be useful in the future.
If we apply this simple rule to real life examples, we shall admit that
if some academic "principles" say Unix or DOS or COBOL is a bad
engineering, but in reality millions of people use it, it can be the
great time to review the principles or defiition of "progress".