(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:

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:

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.

In article <3445B1F0.3F294...@isu.edu>, Joe Ng  <ng...@isu.edu> wrote:

(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))

In article <86g1q1kji8....@g.pet.cam.ac.uk>,
Gareth McCaughan  <gj...@dpmms.cam.ac.uk> wrote:

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.

: > 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

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.

Ken Tilton wheezed these wise words:

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.

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.

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.

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.

In article <629a38$c4...@mycroft.westnet.com>,
Lawrence Troxler  <l...@westnet.com> wrote:

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.

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.

In article <lypvp2kvr0....@morannon.bfr.co.il>, Aaron Gross

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?

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.

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.

"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."

* 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".

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.

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.

In article <bc-2210971433350...@17.127.18.137>, b...@wetware.com (Mister

Some people are thinking that Lisp is their assembler.
The interesting stuff is built on top of Lisp

;-)