Hi,I am a lisp beginer picking up this language. I am working on a
problem of writing a function to take a square array ( a 2 D array whose
dimensions are (n n)) and rotate it 90 degrees clockwise: It should have
the following output:
>(quarter-turn #2A(a b)(c d)))
#2A((C A)(D B))
I think I need to have a seperate function of (array-dimension array)
which return a list of integers representing the length of each
dimension of array. But, I just stucked in there for couple days without
any clues.
I will highly appreciate if any lisp expert can show me how to do this
problem. I am looking forward to have a help on that!
In article <·················@isu.edu>, Joe Ng <·····@isu.edu> wrote:
>Hi,I am a lisp beginer picking up this language. I am working on a
>problem of writing a function to take a square array ( a 2 D array whose
>dimensions are (n n)) and rotate it 90 degrees clockwise: It should have
>the following output:
>
>>(quarter-turn #2A(a b)(c d)))
>#2A((C A)(D B))
>
>I think I need to have a seperate function of (array-dimension array)
>which return a list of integers representing the length of each
>dimension of array. But, I just stucked in there for couple days without
>any clues.
If you want to get a list of all the dimensions, you should use
ARRAY-DIMENSIONS. ARRAY-DIMENSION takes two arguments, the array and a
dimension number, and returns the length of just that dimension. Of
course, in the case of a square array, either one will be useful.
>I will highly appreciate if any lisp expert can show me how to do this
>problem. I am looking forward to have a help on that!
Untested:
(defun quarter-turn (square)
(let* ((size (array-dimension square 0))
(result (make-array (list size size))))
(dotimes (i size)
(dotimes (j size)
(setf (aref result j (- size i 1))
(aref square i j))))
result))
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
From: marisal
Subject: Re: question from a lisp beginer!
Date:
Message-ID: <3445EF8E.2209@wrq.com>
Joe Ng wrote:
>
> Hi,I am a lisp beginer picking up this language. I am working on a
> problem of writing a function to take a square array ( a 2 D array whose
> dimensions are (n n)) and rotate it 90 degrees clockwise: It should have
> the following output:
>
> >(quarter-turn #2A(a b)(c d)))
> #2A((C A)(D B))
>
> I think I need to have a seperate function of (array-dimension array)
> which return a list of integers representing the length of each
> dimension of array. But, I just stucked in there for couple days without
> any clues.
>
> I will highly appreciate if any lisp expert can show me how to do this
> problem. I am looking forward to have a help on that!
If you have the array in the form of a list of lists, you just need to
tranpose the array. This is a classic example of the 'elegance' of Lisp,
and you don't need to worry about the dimensions of the array at all:
(defun transpose (m)
(apply #'mapcar #'list m))
(transpose '((a b)(c d)))
--> ((a c) (b d))
This is the opposite sense of rotation that you wanted, so just invert
each element:
(mapcar #'reverse *)
--> ((c a) (d b))
·······@wrq.com wrote:
> If you have the array in the form of a list of lists, you just need to
> tranpose the array. This is a classic example of the 'elegance' of Lisp,
> and you don't need to worry about the dimensions of the array at all:
>
> (defun transpose (m)
> (apply #'mapcar #'list m))
And the fact that this is so easy is a classic example of the danger
of programming in Lisp: there are so many elegant buut inefficient
solutions to any problem... (See, for instance, Gabriel's famous
`Good news, bad news, how to win big' paper, where someone really
seriously implemented arrays with lists of lists for numerical work!)
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
In article <··············@g.pet.cam.ac.uk>,
Gareth McCaughan <·····@dpmms.cam.ac.uk> wrote:
>·······@wrq.com wrote:
>
>> If you have the array in the form of a list of lists, you just need to
>> tranpose the array. This is a classic example of the 'elegance' of Lisp,
>> and you don't need to worry about the dimensions of the array at all:
>>
>> (defun transpose (m)
>> (apply #'mapcar #'list m))
>
>And the fact that this is so easy is a classic example of the danger
>of programming in Lisp: there are so many elegant buut inefficient
>solutions to any problem... (See, for instance, Gabriel's famous
>`Good news, bad news, how to win big' paper, where someone really
>seriously implemented arrays with lists of lists for numerical work!)
>
I still don't know how much that should be considered a danger.
Most people get into optimization too soon, at the expense of
correctness, readability, and development time. Much of their
effort and sacrifice is wasted, as they optimize things that really
aren't going to be executed many times. Further, people are
generally bad at picking out those parts of the program that are
going to need optimization.
The way of Lisp, as I understand it, is to get a system working first,
then figure out what you've got to do to it to make the performance
criteria. A properly-written Lisp program can have algorithms changed
all over the place, with fewer consequences to the rest of the code
than any other language I've ever used, so it should be possible to
optimize whatever is being a bottleneck. Once the program is running,
figure out whether it's fast enough. If not, profile it and see where
it's bogging down.
It might well be that it's running too slowly partly because arrays
are being represented as lists of lists, or it might be that the
array handling is so small a part of the execution time that the
programmer may as well leave it alone. In either case, you know
what to do with it.
This is a very foreign mindset to C/Unix programmers, who (to use
a stereotype) value efficiency and tight code for their own sake
(Koenig, in his _Ruminations_on_C++_, catches himself in this
mindset). However, a delivered program only has to be fast enough,
whatever that is, and extra expense spent on making it faster than
that is waste. Most consumer software spends most of its time waiting
for bytes to trickle in, anyway, and there's no virtue in speeding up
an idle loop.
--
David H. Thornley | These opinions are mine. I
·····@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly.
David Thornley wrote:
> >And the fact that this is so easy is a classic example of the danger
> >of programming in Lisp: there are so many elegant buut inefficient
> >solutions to any problem... (See, for instance, Gabriel's famous
> >`Good news, bad news, how to win big' paper, where someone really
> >seriously implemented arrays with lists of lists for numerical work!)
> >
> I still don't know how much that should be considered a danger.
>
> Most people get into optimization too soon, at the expense of
> correctness, readability, and development time. Much of their
> effort and sacrifice is wasted, as they optimize things that really
> aren't going to be executed many times. Further, people are
> generally bad at picking out those parts of the program that are
> going to need optimization.
Very true. I'd say that the ease of writing bad Lisp is a *danger*
but not a *problem*. And one of the good things about Lisp is that
it encourages a programming style in which decisions like "let's
represent arrays as lists of lists" can be undone without rewriting
the whole program.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
From: Ken Tilton
Subject: Make it right, then make it fast
Date:
Message-ID: <3447D1E5.1C4@bway.net>
David Thornley wrote:
>
> In article <··············@g.pet.cam.ac.uk>,
> Gareth McCaughan <·····@dpmms.cam.ac.uk> wrote:
> >·······@wrq.com wrote:
> >
> >> If you have the array in the form of a list of lists, you just need to
> >> tranpose the array. This is a classic example of the 'elegance' of Lisp,
> >> and you don't need to worry about the dimensions of the array at all:
> >>
> >> (defun transpose (m)
> >> (apply #'mapcar #'list m))
> >
> >And the fact that this is so easy is a classic example of the danger
> >of programming in Lisp: there are so many elegant buut inefficient
> >solutions to any problem...
[snip]
> The way of Lisp, as I understand it, is to get a system working first,
> then figure out what you've got to do to it to make the performance
> criteria.
[snip]
> This is a very foreign mindset to C/Unix programmers,
I agree completely with your point, and wish only to note that at least
two c/unix programmers shared that mindset: K&R themselves in their C
style book offered "Make it right, then make it fast" for all the
reasons you offered.
Ken
: > The way of Lisp, as I understand it, is to get a system working first,
: > then figure out what you've got to do to it to make the performance
: > criteria.
: [snip]
: > This is a very foreign mindset to C/Unix programmers,
: I agree completely with your point, and wish only to note that at least
: two c/unix programmers shared that mindset: K&R themselves in their C
: style book offered "Make it right, then make it fast" for all the
: reasons you offered.
: Ken
I'm purposely avoiding attribing authors to the above quotes, expecially
the "This is a very foreign mindest to C/Unix programmers"
comment, since I dont' have the
originals handy, and don't want to perpetuate something, if in fact that
author is being quoted out of context.
That being said, and being a long-term C programmer myself, I wonder where
the evidence is for such a statement. If someone is going to paint
modern-day C programmers, or Unix programmers, as having a mindset that is
too heavily biased toward run-time performance, I'd like to see some
references or at least anecdotes, to back this up. Personally, I tend to
doubt that there is much correlation between a programmer's programming
language and his relative emphasis on run-time speed, for non-realtime
applications.
Larry
-- -- Larry Troxler --
··@westnet.com -- Patterson, NY USA --
From: Ken Tilton
Subject: Re: Make it right, then make it fast
Date:
Message-ID: <3448F02A.2F95@bway.net>
Lawrence Troxler wrote:
> I wonder where
> the evidence is for such a statement. If someone is going to paint
> modern-day C programmers, or Unix programmers, as having a mindset that is
> too heavily biased toward run-time performance, I'd like to see some
> references or at least anecdotes, to back this up.
I think you have to go back to where this started, viz., someone
bemoaning the danger of having powerful stuff like mapcar built into a
language: beginners (myself included) can write some incredibly slow
code, innocently unaware of the hidden cost of cons-ing.
Then someone countered that it is nice to prototype quickly with
powerful but inefficient stuff like mapcar (cons-ing all over the place)
and then tune later.
Although it was not written precisely this way, I /think/ the original
"mindset" rap against C/Unixers had to do more with C programmers not
having powerful constructs readily available within the language, so
they do not get into the "right vs fast" thing _specifically because of
high-powered constructs_. But of course in any language one can write
simpler code of dubious efficiency in the hope that it will not prove to
be a bottleneck, deferring more tortuous solutions until actual
performance dashes that hope.
Ken Tilton wrote:
> I think you have to go back to where this started, viz., someone
> bemoaning the danger of having powerful stuff like mapcar built into a
> language: beginners (myself included) can write some incredibly slow
> code, innocently unaware of the hidden cost of cons-ing.
I think you're referring to me here. Just for the record,
I think `bemoaning' is entirely the wrong word for what I
was trying to say.
1. I'm very glad that Lisp has all these nice powerful functions.
2. I think the (apply #'mapcar #'list x) trick for transposing
a matrix represented as a list of lists is beautiful.
BUT, I think it's bad code even so, because
3. It's cryptic and hard to understand.
4. It encourages the use of a totally inappropriate data structure.
If you want to do things with matrices, lists are not the right
way to do it.
It seems to me that the apply-mapcar-list trick is sort of like
the slimy but beautiful things one finds in the International
Obfuscated C Code Competition; very clever, very concise, but
not really the sort of thing you'd want to find in someone else's
program if you hadn't seen it before. And given that it requires
you to use a data structure that makes your program inefficient,
it seems to me that it's sacrificing both clarity and efficiency
at the altar of conciseness. Is this really the Lisp way?
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
Gareth McCaughan wrote:
> 2. I think the (apply #'mapcar #'list x) trick for transposing
> a matrix represented as a list of lists is beautiful.
>
> BUT, I think it's bad code even so, because
>
> 3. It's cryptic and hard to understand.
It took me some time to realize what was going on, and yes I agree
with you it's far too cryptic. Here's what happens, for those
who are still puzzled:
Supposing (setf x '((1 2 3) (4 5 6) (7 8 9)))
Then (apply #'mapcar #'list x)
is, by the definition of apply, equivalent to
(apply #'mapcar (cons #'list x))
which, with the above value of x, is
(apply #'mapcar `(,#'list (1 2 3) (4 5 6) (7 8 9)))
which is
(mapcar #'list '(1 2 3) '(4 5 6) '(7 8 9))
which can be readily seen to return the value
((1 4 7) (2 5 8) (3 6 9))
which is the transpose of x.
> It seems to me that the apply-mapcar-list trick is sort of like
> the slimy but beautiful things one finds in the International
> Obfuscated C Code Competition; very clever,
To quote Charniak, Riesbeck and McDermott (Artificial Intelligence
Programming, p27):
"1.12.5 Cleverness
Avoid it. <snip>
To paraphrase Samuel Johnson, we advise you to look over your
code very carefully, and whenever you find a part that you think
is particularly fine, strike it out."
> Gareth McCaughan--
Le Hibou (mo bheachd fhe/in : my own opinion)
"What the ... This is Lambic! Where's my culture of amoebic
dysentery?"
-- Gary Larson
* Donald Fisk
| "1.12.5 Cleverness
|
| Avoid it. <snip>
|
| To paraphrase Samuel Johnson, we advise you to look over your
| code very carefully, and whenever you find a part that you think
| is particularly fine, strike it out."
hm. how does this relate to the genesis of idiomatic forms of expression?
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://www.naggum.no/emacs/ for Emacs-20-related material.
Erik Naggum wrote:
> | "1.12.5 Cleverness
> |
> | Avoid it. <snip>
> |
> | To paraphrase Samuel Johnson, we advise you to look over your
> | code very carefully, and whenever you find a part that you think
> | is particularly fine, strike it out."
>
> hm. how does this relate to the genesis of idiomatic forms of expression?
I agree with the point I believe Erik to be making, but I don't
think the specific case presently being discussed comes under
that heading. It's not (so far as I know) a special case of any
idiomatic *form* of expression; it's just a one-off piece of
cleverness.
Perhaps a good analogy would be with Duff's device, although
even that comes much closer to being a `form of expression'
(although, I hope, not idiomatic in most circles) than the
apply-mapcar-list trick.
Idioms are good because one can get used to them. One-offs like
this are not good unless they're very common (which transposing
an array represented as a list of lists isn't) -- they're too
easy to forget.
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
·····@dpmms.cam.ac.uk Cambridge University, England.
Lawrence Troxler <··@westnet.com> writes:
> That being said, and being a long-term C programmer myself, I wonder
> where the evidence is for such a statement. If someone is going to
> paint modern-day C programmers, or Unix programmers, as having a
> mindset that is too heavily biased toward run-time performance, I'd
> like to see some references or at least anecdotes, to back this up.
> Personally, I tend to doubt that there is much correlation between a
> programmer's programming language and his relative emphasis on
> run-time speed, for non-realtime applications.
First of all, I think the original comment was not that C programmers
are "too heavily biased toward run-time performance", but rather that
they are (I'm paraphrasing) too heavily biased toward stupid,
premature, ineffective "optimization". I'm also primarily a C
programmer, by the way.
No references, but for anecdotes, try reading comp.lang.c for a few
weeks. I used to read the newsgroup regularly until I got sick of it.
It was full of idiotic posts asking how to micro-optimize this or that
statement regardless of its effect on overall performance. Also
questions like "which construct is better, i.e., faster,...".
In contrast, optimization questions in comp.lang.lisp seem pretty
intelligent, and seem to follow the "Make it right, then make it fast"
philosophy. For instance, a while ago there was a question about
optimizing some procedure that calculates a distance between two
vectors, and the programmer pointed out that the calculation was done
millions of times and was a bottleneck.
It seems intuitively clear, to me at least, that a low-level language
like C encourages bad approaches to optimization more than a
high-level language like Lisp, but I don't have the evidence to argue
this point. In any case, I'd guess that the main reason for the
difference between Lisp programmers and C programmers is simply that
programmers in less popular "niche" languages tend to be smarter than
programmers in more widespread and popular languages.
Aaron
Aaron Gross <·····@morannon.bfr.co.il> writes:
> It seems intuitively clear, to me at least, that a low-level
> language like C encourages bad approaches to optimization more than
> a high-level language like Lisp, but I don't have the evidence to
> argue this point.
I think what you mean to say here is that you have no "empirical
evidence " to argue this point. Sort of like seeing the program
(defun f () (let ((a 'b)) (+ a 1)))
and saying you haven't seen (f) called a lot so you can't say whether
it results in error. I think some problems don't require empirical
evidence and in fact the empirical evidence can obscure the problem.
They are better diagnosed by looking at the source.
Programming is what I have always called a "cascade of decision
making". There are myriad points at which decisions can be made,
and making a decision at a wrong time is a common source of program
error. This is what drives me generally nuts about static languages.
I think it's a wonderful thing to specify things statically IF YOU
KNOW THEM THEN (sorry for shouting, but gee...) but if you do not
know things then, then the mere requirement to try is a bug.
As an aside, this kind of reminds me of an interview I saw between
a TV interviewer and a mathemetician where the mathemetician was
trying to explain a rate of growth that was o(n^2) and the interviewer
was not getting it and so he said "yeah, i understand that. but in
plainer terms, is that like twice as big or three times as big or...?"
Back to the optimization issue, when you're sitting around designing
a program and you get to the point of a "thing" going in the box and
the system is saying "what kind of thing?" (i.e., "undeclared variable
thing") you feel such pressure from people to make efficient
declarations... You want to say "I don't know, that's why I didn't
declare it" but C and C++ don't even have a type T, so the
option isn't open to you. So you make up some default assumption.
And this is the point of the error that you were intuiting. Instead
of picking a "null default" you have picked a "plausible default".
Which means you have EXCLUDED all set members less plausible.
In LISP, everything is defaultly type T and we feel no shame about
that because we know that THAT represents lack of knowledge and,
effectively, an unmade decision. So we don't initially exclude
anything. Even for integers, we assume bignums might be in there.
But in C you can't. So you make a guess and it's easy for it to
be wrong and to EXCLUDE something.
Optimization is an engineering trade-off. It is properly done by
a negotiation between the user of the system and the programmer
in which the user specifies situations that will never occur,
that are unlikely, etc. and the programmer tightens things up to
give you speed in exchange for such a constraint. But done too
early, you have "premature optimization" which typically leads to
conversations between the programmer and user where you say things
like "oh, it'll just never be able to do x" and when you ask why
they say "i never imagined you'd want to vary this". And there's
altogether too little chopping off of C programmers' heads for
having had the gall to make such decisions early. Instead, the
user (a non-programmer who doesn't understand the nature of the
choice space and whether this problem was avoidable) often just
says "oh" and chalks it up to inflexible COMPUTERS instead of to
inflexible LANGUAGES and people whose minds have been warped by
that.
> In any case, I'd guess that the main reason for the difference
> between Lisp programmers and C programmers is simply that
> programmers in less popular "niche" languages tend to be smarter
> than programmers in more widespread and popular languages.
I don't think this is so. I think that cognitive dissonance
plays a great role. Assuming for the moment that you are the
smartest programmer around, I could still put you in C for a while
and you'd probably be frustrated for days by the absence of type T
until you finally invented reasons in your mind why you were using
C in spite of this absence, and then eventually you'd invent reasons
why premature optimization was fortuitous and saved stress later
on. And after a while, Lisp would be a distant memory of an
overluxurious world that wasn't being sensible.
The sad fact is that for commodity programming often the "plausible
default" is the "right default" but mostly by coincidence. Actually,
this wouldn't even be sad if that's as far as it went. But often it
leads to ridiculous claims that C is all you need and attempts to
squash Lisp as an unnecessary frill. But the fact is that people
have tried for a long time to squash Lisp and they haven't.
And the reason they haven't is that it it's good for certain
non-commodity things that C is plainly not good for. One should never
confuse "commodity needs" with "all needs". Commodity needs will, by
their nature, outnumber other needs. But both are still needed.
General practioner doctors may be good for a lot of things, but
one still needs skilled surgeons and should not assert just because
surgeons are in small numbers that it's a (pardon the pun) dying art.
Hmm. I gotta make a note to extract some of this into my
Parenthetically Speaking series of articles. It's really frustrating
how often I repeat these arguments. I should just point to them
by pointer..
In article <··············@morannon.bfr.co.il>, Aaron Gross
<·····@morannon.bfr.co.il> wrote:
> In contrast, optimization questions in comp.lang.lisp seem pretty
> intelligent, and seem to follow the "Make it right, then make it fast"
> philosophy. For instance, a while ago there was a question about
> optimizing some procedure that calculates a distance between two
> vectors, and the programmer pointed out that the calculation was done
> millions of times and was a bottleneck.
Make it right, then make it fast. Then throw away both of those versions,
and make it right, fast and _understandable_.
>Sender: ······@netcom8.netcom.com
> Make it right, then make it fast. Then throw away both of those versions,
> and make it right, fast and _understandable_.
This is right on the money, redoing an implementation after you've more
fully understood the problem, and it potential performance bottlenecks
and possible alternative requirements is best.
As Kent points out, Lisp code can be written in ways that build in
less assumptions than statically typed code.
But ultimately most truly useful code will be used for a long time,
and will need changes to adapt to future demands,
and therefore understood by someone else
long after the original author is gone.
Let me use this as a plug for using LOOP ;)
Since my conversion from ardent functional/mapping advocacy to LOOP,
I've found using LOOP makes it much easier
to modify code to do something different or additional.
So while (mapcar #'name (objects-list))
is a concise way to get a list of object
names, it takes more effort to change it to do something else,
such as add a check if the object is something special,
or perhaps ensure the length of the name get truncated to 20
characters, or truncated to some variable length, etc.
-Kelly Murray ···@franz.com
In article <············@mycroft.westnet.com>,
Lawrence Troxler <··@westnet.com> wrote:
>: > The way of Lisp, as I understand it, is to get a system working first,
>: > then figure out what you've got to do to it to make the performance
>: > criteria.
>
>: [snip]
>
>: > This is a very foreign mindset to C/Unix programmers,
>
>: I agree completely with your point, and wish only to note that at least
>: two c/unix programmers shared that mindset: K&R themselves in their C
>: style book offered "Make it right, then make it fast" for all the
>: reasons you offered.
>
>I'm purposely avoiding attribing authors to the above quotes, expecially
>the "This is a very foreign mindest to C/Unix programmers"
>comment, since I dont' have the
>originals handy, and don't want to perpetuate something, if in fact that
>author is being quoted out of context.
>
Nope, in context. I hereby plead guilty to overgeneralization and
stereotyping, my only mitigation being that my diversity training never
covered this point.
This is a very foreign mindset to many C programmers that I have
argued with, and many that have posted to comp.lang.c and the like
while I lurked. Many of these are Unix people, but many are
unfortunates who program on Microsoft OSs. (Should we have covered
MS users in diversity training?)
To give a bit more anecdotal evidence, consider Andrew Koenig's
_Ruminations_on_C++_, chapter 11. He gives three reasons why not
all functions should be virtual. The first reason, and the one he
spends the most time on, is efficiency. The other two reasons are
fundamentally that polymorphism isn't always what you want, and you
may want classes that can't be inherited from or behavior that is
determined by the static type. These two reasons are what I find
convincing, since they relate to correctness. My impression is
that Koenig has a brain and isn't afraid to use it, and therefore
I get the feeling that there are cultural reasons why he emphasizes
efficiency here.
>That being said, and being a long-term C programmer myself, I wonder where
>the evidence is for such a statement. If someone is going to paint
>modern-day C programmers, or Unix programmers, as having a mindset that is
>too heavily biased toward run-time performance, I'd like to see some
>references or at least anecdotes, to back this up. Personally, I tend to
>doubt that there is much correlation between a programmer's programming
>language and his relative emphasis on run-time speed, for non-realtime
>applications.
>
I would strongly suspect a correlation, myself. Programmers who want
their code blazingly fast will usually write it in assembler language
or C or some other low-level language. Not only will this cause a
correlation by itself, but it will tend to set up a cultural bias that
will affect newcomers to a field. If I look at comp.lang.c and comp.
lang.lisp, it seems that there are excellent people in both newsgroups,
but the real nimnos are very heavily concentrated in comp.lang.c
(except when they come to comp.lang.lisp to troll about inefficient
languages).
Your mileage may vary, as always, but my experience is that most Lisp
programmers, and relatively fewer C/C++ programmers, have the sort of
mindset and approach that I approve of.
--
David H. Thornley | These opinions are mine. I
·····@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly.
Lawrence Troxler <··@westnet.com> wrote:
| That being said, and being a long-term C programmer myself, I wonder where
| the evidence is for such a statement. If someone is going to paint
| modern-day C programmers, or Unix programmers, as having a mindset that is
| too heavily biased toward run-time performance, I'd like to see some
| references or at least anecdotes, to back this up. Personally, I tend to
| doubt that there is much correlation between a programmer's programming
| language and his relative emphasis on run-time speed, for non-realtime
| applications.
Here is a strong anecdote, bordering on "real evidence":
In an average year, there will be MANY flamewars between the C and Lisp
camps about which language is "better." In every single one of those
flamewars (as best I can tell), one of the major C-proponent points of
contention is that "faster is always better," and that "C is always faster
than Lisp," and therefore "C is better than Lisp." (You can research this
yourself in DejaNews, if it interests you.)
I do NOT think that this C-programmers's preference is produced by the
language itself, as someone else seemed to be asserting. I think that
these preferences are memetic viruses that seem to infect entire
generations of programmers.
For instance, "every" programmer "knows" that "BASIC is a BAD BAD
programming language." (Or the variant: "BASIC is a beginner's language;
REAL programmers use a REAL programming language, and the ONLY REAL
programming language is C.") This knowledge, however, seems to be
remarkably obtained without any experience programming BASIC.
The simple point is this: there are many cases where using a high-level,
probably slower, more reliable programming language will end up saving you
time and money. I've made a WHOLE LOT of money doing just that: writing
simple "text formatting"-like programs in BASIC, or HyperTalk, or Lisp,
rather than in C. I've shipped commercial software like that. One year I
made some rather outrageous amounts of money doing that, because the
client paid extra for the program to be written in 24 hours, not 24 days.
So, assuming I'm not a liar nor the "one in a million", why don't
programmers realize this and start using BASIC for some of their tasks?
Part of it seems to be fear of chastisement -- they're afraid their
friends will laugh, and part of it seems to be willful ignorance -- they
just assume that what they were told is right, without bothering to verify
it.
I don't have any real numbers about these last points, but you can easily
see that IF a major topic of conversation in C programming circles is
"micro-optimization" (which you can, if you read the C groups), AND IF you
happen to know that many many advanced-programmer texts and studies and
anecdotes showing that programmers rarely guess correctly optimizing code,
THEN the books/studies/anecdotes aren't having an effect, and programmers
aren't coming to the same conclusion themselves at any significant rate.
Both of these conclusions support my assertion -- that programmers tend to
assume what they "know" is right, and don't trust different opinions, and
don't verify these things for themselves.
So what I am saying:
1) a large proportion of C programmers seem to have an opinion that
program speed is one of the principle measures of "goodness" of a program;
2) a large proportion of C programmers are convinced that high-level
languages, such as Lisp and BASIC, are always slower than C, and therefore
"bad;"
3) many of these same programmers somehow think that C++ combines all the
high-level features of Lisp with the speed of C, and therefore it's "extra
good;"
4) a large proportion of programmers in general, whether Lisp or C, tend
to be prejudiced against some languages to the point of deriding them
without any personal experience; and further, that programmers tend to
resist new ideas.
I have offered a small amount of data to back up these assertions. I
agree, I haven't "proved" anything, and I certainly don't assert that
"ALL" C programmers are <whatever>, but I hope I've caused a little
introspection.
··@wetware.com (Mister HEINOUS) writes:
<snip>
> So, assuming I'm not a liar nor the "one in a million", why don't
> programmers realize this and start using BASIC for some of their tasks?
> Part of it seems to be fear of chastisement -- they're afraid their
> friends will laugh, and part of it seems to be willful ignorance -- they
> just assume that what they were told is right, without bothering to verify
> it.
Because Perl kicks BASIC butt ;)
In article <···················@17.127.18.137>, ··@wetware.com (Mister
HEINOUS) wrote:
> 1) a large proportion of C programmers seem to have an opinion that
> program speed is one of the principle measures of "goodness" of a program;
Speed is important. Even for Lisp programmers.
> 2) a large proportion of C programmers are convinced that high-level
> languages, such as Lisp and BASIC, are always slower than C, and therefore
> "bad;"
Lisp can be fast. Sometimes it can made to be much faster (by
using techniques of macro programming, partial evaluation,
runtime compilation, memoization, ...
> 3) many of these same programmers somehow think that C++ combines all the
> high-level features of Lisp with the speed of C, and therefore it's "extra
> good;"
C++ is not my favorite language. I consider C++ to be ugly. Most
design decisions for C++ are making sense looked at in isolation.
The complete picture is totally different. It's mutated
to some ugly Frankenstein monster.
I still don't understand why people are sending me random job
offers for C++ programming projects. What a waste of time.
> 4) a large proportion of programmers in general, whether Lisp or C, tend
> to be prejudiced against some languages to the point of deriding them
> without any personal experience; and further, that programmers tend to
> resist new ideas.
A Lisp programmer not willing to incorporate new ideas and
paradigms is not a real Lisp programmer. Lisp has survived
because it is changing as the requirements are changing.
It is a programmable programming language.
Some people are thinking that Lisp is their assembler.
The interesting stuff is built on top of Lisp
;-)
--
http://www.lavielle.com/~joswig/
Ken Tilton wheezed these wise words:
> I agree completely with your point, and wish only to note that at least
> two c/unix programmers shared that mindset: K&R themselves in their C
> style book offered "Make it right, then make it fast" for all the
> reasons you offered.
Add P.J. Plauger to that list. His name is on my copy of "Elements of
Programming Style". It's also one of the ideas in "Software Tools".
K&P even gave a simple example: a spelling checker written as a Unix
pipline. Ideas like that also pop up in functional programming.
Most of the developers that I know use this principle already, even if
they don't know C or Lisp. They can first use tool like a spreadsheet
or a database, then translate it into a lower level, like VB. If
that's still not enough, they can rewrite it in C++. Instead of using
existing command line tools in a pipeline, they use existing tools in
a DLL, OCX, OLE, etc.
When most of the work is done by a tool that you just plug into your
app, there's little difference between VB, C++, Lisp, or whatever.
That may be why so many of them use VB. OTOH, maybe they use it simply
because they can. Unfortunately, making it work is sometimes the only
criteria practical, due to time constraints. This is why "making it
fast" is so wrong IMHO. It's no good if the code is late, esp if the
deadline counts. We can do it better when we have the luxury of time.
--
Please note: my email address is munged
You can never browse enough