An earlier post discussed Exercise 3 from Paul Graham's "ANSI
Common Lisp", Chapter 3:
"Define a function that takes a list and returns a list
indicating the number of times each (eql) element appears,
sorting from most common element to least common."
(occurrences '(a b a d a c d c a)) => ((A . 4) (C . 2) (D . 2) (B .1))
A participant named Bill Atkins suggested this nifty snippet:
;;; Bill Atkin's occurrences
(defun occurrences-atkins (list)
(let ((counts '()))
(dolist (item list)
(if (assoc item counts :test #'eql)
(incf (cdr (assoc item counts :test #'eql)))
(setf counts (acons item 1 counts))))
(sort counts #'> :key #'cdr)))
My own shot is probably very typical for a typical reader
of "ANSI Common Lisp", because chapter three has a focus on
recursion and stuff. It is longer, and it involves more functions:
(defun incf-pair (pair)
(incf (cdr pair)))
(defun countem (lst &optional accu)
(if (null lst)
accu
(let ((fpair (assoc (car lst) accu)))
(if fpair
(incf-pair fpair)
(push (cons (car lst) 1) accu))
(countem (cdr lst) accu))))
(defun sort-hits (lst)
(sort lst #'> :key #'cdr))
(defun occurrences (lst)
(sort-hits (countem lst)))
Although I admire Bill Atkin's suggestion for its brevity,
I'm not sure if I wouldn't like the longer version better
in a production environment, for the following reasons.
- It's easier to understand because the important parts of
the logic are separated in their own functions
- It's easier to refactor (incf-pair can be used for other
functions, for example)
- It's recursive and purely functional
The last point is probably subjective and not a real virtue,
but after all that brainwashing that comes with reading books
on Lisp, recursion makes me feel good. In a way, I've come
to loath non-functional (i.e. stateful) code.
Although this simple program is a toy-example, it can serve
as a toy-example for where to set priorities in a production
environment, so here is the question for you: Which approach
would a real Lispnik prefer? Which approach would make me
look more amateurish?
References:
http://groups.google.at/group/comp.lang.lisp/browse_frm/thread/1112134060ed6cd0/f5e95853c33b4cf9?lnk=st&q=%22ansi+common+lisp%22&rnum=2&hl=de#f5e95853c33b4cf9
This is the original post I'm referring to.
--
Lisp kann nicht kratzen, denn Lisp ist fluessig
Have you gone through the following thread titled "Curious about
functional programming"
from sometime in 2000 ? Here's quoting Erik Naggum in one of his posts
in that thread:
" I view functional programming as an
attempt to solve certain hard problems -- not those of application,
infrastructure, modeling, human requirements, etc, but in the design
of languages -- a consequence of which is that certain programming
paradigms emerge and prove themselves worthy of examination and the
occasional use, but 100% pure functional style is simply useless: If
you have no side-effects, you have no effects on the real world,
which has the same identity before and after your side-effect-free
program. Taken to its extreme, side-effect-free programming would
mean you had to create a new universe with every computation.
"
>
> The last point is probably subjective and not a real virtue,
> but after all that brainwashing that comes with reading books
> on Lisp, recursion makes me feel good. In a way, I've come
> to loath non-functional (i.e. stateful) code.
>
People here usually suggest -- be open to all paradigms. follow the one
the most adequately addresses the problem space
Aravindh Johendran wrote:
> Have you gone through the following thread titled "Curious about
> functional programming"
> from sometime in 2000 ? Here's quoting Erik Naggum in one of his posts
> in that thread:
>
> " I view functional programming as an
> attempt to solve certain hard problems -- not those of application,
> infrastructure, modeling, human requirements, etc, but in the design
> of languages -- a consequence of which is that certain programming
> paradigms emerge and prove themselves worthy of examination and the
> occasional use, but 100% pure functional style is simply useless: If
> you have no side-effects, you have no effects on the real world,
> which has the same identity before and after your side-effect-free
> program. Taken to its extreme, side-effect-free programming would
> mean you had to create a new universe with every computation.
> "
>
This is exactly the problem, I have scars to prove it!
It goes without saying that at some point you always need
side-effects, because you want to leave your mark somewhere
in the system, i.e. update state or even persist it.
However, functional programming (where appropriate/feasible)
REALLY is a good idea. I like staring at functional code
and being able to more or less PROVE that it cannot have
any bugs. Functional code might be messy, unnecessarily
complex or might miss the problem domain, but what you
see is what you get and what you get is what you see. If
you don't see bugs, chances are, that there are no bugs.
In other words: I'm sold.
>
>>The last point is probably subjective and not a real virtue,
>>but after all that brainwashing that comes with reading books
>>on Lisp, recursion makes me feel good. In a way, I've come
>>to loath non-functional (i.e. stateful) code.
>>
>
>
> People here usually suggest -- be open to all paradigms. follow the one
> the most adequately addresses the problem space
... what is not always an obvious choice, alright.
Thanks bro
>
--
Lisp kann nicht kratzen, denn Lisp ist fluessig
Tin Gherdanarra <···········@gmail.com> writes:
> This is exactly the problem, I have scars to prove it!
> It goes without saying that at some point you always need
> side-effects, because you want to leave your mark somewhere
> in the system, i.e. update state or even persist it.
> However, functional programming (where appropriate/feasible)
> REALLY is a good idea. I like staring at functional code
> and being able to more or less PROVE that it cannot have
> any bugs. Functional code might be messy, unnecessarily
> complex or might miss the problem domain, but what you
> see is what you get and what you get is what you see. If
> you don't see bugs, chances are, that there are no bugs.
> In other words: I'm sold.
On the contrary, proving correctness is even more straightforward with
the iterative solution than with the recursive one, since all the
functionality is concentrated in one place.
Given:
1. PUSH, SETF, and all other operators in the COMMON-LISP package
behave as specified.
2. LIST is a list of objects with length N, where N >= 0. M is the set of
unique elements in this list, where |M| <= N.
Show that for any LIST, OCCURRENCES will return a list of length |M|
where each element is of the form (x . n), where x element_of M and n
is the number of occurrences of x in LIST.
If N = 0, OCCURRENCES will return the empty list - trivially. Check.
We'll prove this inductively over the number of elements in LIST.
Base case:
If N = 1, then the IF condition will fail, and the pair (X . 1) will
be added onto the list, where X is the sole element in LIST. The
result will be sorted by the second element of each pair in RESULT
(we are given that SORT works). Check.
Inductive assumption:
For a list of length |N|, OCCURRENCES will return a list M where
each element of M is a pair (x . n).
Inductive proof:
Given the inductive assumption, show that given a list of N + 1
elements OCCURRENCES will return a list of the proper format.
Since we know that the first N elements have been properly placed
into RESULT, we examine the last element. There are two cases here:
1) the element is already in RESULT; its count is increased by one
2) the element is not in RESULT; it is added to it with a count of 1.
In either case, RESULT holds a list meeting the initial criteria.
Check.
In other imperative languages, like C, Java, or C++, where you'd have
to do a lot of bookkeeping to get this done, proofs are more
complicated. But since we can take all of Common Lisp as a given,
proving this algorithm correct is not so hard, despite the fact that
it's not purely functional.
I think this proof is correct (but IANAM). I'm not sure if it's even
worthwhile to post this to c.l.l, but I just got out of a Models of
Computation exam and am in a "Let's prove things!" mood.
--
This is a song that took me ten years to live and two years to write.
- Bob Dylan
Tin Gherdanarra <···········@gmail.com> writes:
> My own shot is probably very typical for a typical reader
> of "ANSI Common Lisp", because chapter three has a focus on
> recursion and stuff.
It is typical in other ways, such as using "lst" instead of
"list". This is a pretty ugly habit.
> - It's recursive and purely functional
>
> The last point is probably subjective and not a real virtue,
> but after all that brainwashing that comes with reading books
> on Lisp, recursion makes me feel good. In a way, I've come
> to loath non-functional (i.e. stateful) code.
This harmful side-effect of Paul Graham's Lisp books fortunately wears
off with experience.
Zach
Zach Beane wrote:
> Tin Gherdanarra <···········@gmail.com> writes:
>
>
>>My own shot is probably very typical for a typical reader
>>of "ANSI Common Lisp", because chapter three has a focus on
>>recursion and stuff.
>
>
> It is typical in other ways, such as using "lst" instead of
> "list". This is a pretty ugly habit.
Hm. Paul G probably uses "lst" because it's not easy to
/print/ longish variable names in a paper-back book.
I thought using "list" sucks because "list" is the
name of a Lisp operator. (Yes, I know the difference between
a Lisp-1 and a Lisp-2, but still...) So "lst" is ugly, while
"list" isn't, you say?
>
>
>>- It's recursive and purely functional
>>
>>The last point is probably subjective and not a real virtue,
>>but after all that brainwashing that comes with reading books
>>on Lisp, recursion makes me feel good. In a way, I've come
>>to loath non-functional (i.e. stateful) code.
>
>
> This harmful side-effect of Paul Graham's Lisp books fortunately wears
> off with experience.
I'll be curious to see THAT happen. Thanks for your support.
>
> Zach
--
Lisp kann nicht kratzen, denn Lisp ist fluessig
Zach Beane wrote:
> Tin Gherdanarra <···········@gmail.com> writes:
>
>
>>My own shot is probably very typical for a typical reader
>>of "ANSI Common Lisp", because chapter three has a focus on
>>recursion and stuff.
>
>
> It is typical in other ways, such as using "lst" instead of
> "list". This is a pretty ugly habit.
>
>
>>- It's recursive and purely functional
>>
>>The last point is probably subjective and not a real virtue,
>>but after all that brainwashing that comes with reading books
>>on Lisp, recursion makes me feel good. In a way, I've come
>>to loath non-functional (i.e. stateful) code.
>
>
> This harmful side-effect of Paul Graham's Lisp books fortunately wears
> off with experience.
So you don't buy into PG's
"13. Functional programming, which means avoiding side-effects,
is the dominant paradigm in Lisp"?
It's a quote from ACL, summary chapter 2.
>
> Zach
--
Lisp kann nicht kratzen, denn Lisp ist fluessig
Tin Gherdanarra <···········@gmail.com> writes:
> So you don't buy into PG's
>
> "13. Functional programming, which means avoiding side-effects,
> is the dominant paradigm in Lisp"?
No, I don't.
Here's a nice site with notable oddities in Paul Graham's ANSI Common
Lisp:
http://www.cs.northwestern.edu/academics/courses/325/readings/graham/graham-notes.html
Zach
<snippo />
>
> No, I don't.
>
> Here's a nice site with notable oddities in Paul Graham's ANSI Common
> Lisp:
>
> http://www.cs.northwestern.edu/academics/courses/325/readings/graham/graham-notes.html
Curiouser and curiouser. There is a website dedicated to rebutting
"ANSI Common Lisp" by Paul Graham. I can't imagine this getting
any better.
--
Lisp kann nicht kratzen, denn Lisp ist fluessig
Zach Beane <····@xach.com> writes:
> Tin Gherdanarra <···········@gmail.com> writes:
>
>> My own shot is probably very typical for a typical reader
>> of "ANSI Common Lisp", because chapter three has a focus on
>> recursion and stuff.
>
> It is typical in other ways, such as using "lst" instead of
> "list". This is a pretty ugly habit.
>
While I personally prefer 'list' to 'lst' because I use text-to-speech
to access the screen and 'list' is spoken correctly/meaningfully, I do
think this is a purely personal style issue and like all similar
personal style issues, it is really a matter of individual choice.
I do wonder though if 'list' may cause confusion for the new user who
is accustomed to more limited languages which have reserved words etc.
I didn't have issues with it, but maybe others would get confused?
I do believe the objective should be placed on clarity. Sometimes,
code can be clearer if it is breif and concise, but sometimes it helps
to be very explicit. I don't think things should be made brief simply
to save keystrokes. I also believe comments should be precise and
informative - I hate seeing comments like "#setting variable x to 2"
as they don't add any real value and comments without value just add
clutter. Everyone has to develop their own style and individual milage
can differ greatly.
Tim
--
tcross (at) rapttech dot com dot au
Tin Gherdanarra <···········@gmail.com> writes:
> An earlier post discussed Exercise 3 from Paul Graham's "ANSI
> Common Lisp", Chapter 3:
>
> "Define a function that takes a list and returns a list
> indicating the number of times each (eql) element appears,
> sorting from most common element to least common."
>
> (occurrences '(a b a d a c d c a)) => ((A . 4) (C . 2) (D . 2) (B .1))
>
> A participant named Bill Atkins suggested this nifty snippet:
>
>
> ;;; Bill Atkin's occurrences
> (defun occurrences-atkins (list)
> (let ((counts '()))
> (dolist (item list)
> (if (assoc item counts :test #'eql)
> (incf (cdr (assoc item counts :test #'eql)))
> (setf counts (acons item 1 counts))))
> (sort counts #'> :key #'cdr)))
>
>
> My own shot is probably very typical for a typical reader
> of "ANSI Common Lisp", because chapter three has a focus on
> recursion and stuff. It is longer, and it involves more functions:
>
> (defun incf-pair (pair)
> (incf (cdr pair)))
>
> (defun countem (lst &optional accu)
> (if (null lst)
> accu
> (let ((fpair (assoc (car lst) accu)))
> (if fpair
> (incf-pair fpair)
> (push (cons (car lst) 1) accu))
> (countem (cdr lst) accu))))
>
> (defun sort-hits (lst)
> (sort lst #'> :key #'cdr))
>
> (defun occurrences (lst)
> (sort-hits (countem lst)))
>
>
> Although I admire Bill Atkin's suggestion for its brevity,
> I'm not sure if I wouldn't like the longer version better
> in a production environment, for the following reasons.
>
> - It's easier to understand because the important parts of
> the logic are separated in their own functions
> - It's easier to refactor (incf-pair can be used for other
> functions, for example)
> - It's recursive and purely functional
>
> The last point is probably subjective and not a real virtue,
> but after all that brainwashing that comes with reading books
> on Lisp, recursion makes me feel good. In a way, I've come
> to loath non-functional (i.e. stateful) code.
>
> Although this simple program is a toy-example, it can serve
> as a toy-example for where to set priorities in a production
> environment, so here is the question for you: Which approach
> would a real Lispnik prefer? Which approach would make me
> look more amateurish?
>
> References:
> http://groups.google.at/group/comp.lang.lisp/browse_frm/thread/1112134060ed6cd0/f5e95853c33b4cf9?lnk=st&q=%22ansi+common+lisp%22&rnum=2&hl=de#f5e95853c33b4cf9
> This is the original post I'm referring to.
>
>
> --
> Lisp kann nicht kratzen, denn Lisp ist fluessig
I disagree with all of this - and not just because I wrote the code in
question. :)
Recursion is a natural fit for some problems, but for just walking
through a list, there is a lot of extra clutter involved in the code
that isn't necessary. Someone skimming your code now has to separate
out the recursive template from the actual processing; I don't think
that's a win.
I don't think that recursion and "purely functional"-ness should be
placed above more practical goals like readability, brevity, and
efficiency. I truly don't find your example easier to understand; the
IF expression at the heart of both of our solutions is basically the
same, except for some stylistic changes. Yet the blubber surrounding
that IF expression puts a much greater cognitive strain on the person
reading it. And for what net win? It's not clear.
Factoring out the sorting and the counting can be done without
resorting to what you've done. If you don't like stateful
programming, maybe Common Lisp isn't the language for you. It's not a
purely functional language, nor was it intended to be. You'll notice
that your own example makes use of the non-functional INCF, SORT, and
PUSH.
You modified my code segment a little - why? Also, you are linking to
a different thread that I was involved in on the same issue, where I
give a different solution, since the poster was looking for something
else. Here is my own code:
(defun occurrences (list)
(let (result)
(dolist (x list)
(if (assoc x result)
(incf (cdr (assoc x result)))
(push (cons x 1) result)))
(sort result #'> :key #'cdr)))
--
This is a song that took me ten years to live and two years to write.
- Bob Dylan
Bill Atkins <············@rpi.edu> writes:
> You modified my code segment a little - why? Also, you are linking to
> a different thread that I was involved in on the same issue, where I
> give a different solution, since the poster was looking for something
> else. Here is my own code:
>
> (defun occurrences (list)
> (let (result)
> (dolist (x list)
> (if (assoc x result)
> (incf (cdr (assoc x result)))
> (push (cons x 1) result)))
> (sort result #'> :key #'cdr)))
Can I modify it a bit, too? :)
(defun occurrences (list)
(let (result)
(dolist (x list)
(let ((count-pair (assoc x result)))
(if count-pair
(incf (cdr count-pair))
(push (cons x 1) result))))
(sort result #'> :key #'cdr)))
I feel dirty calling #'assoc more times than necessary, is all.
Ari Johnson <················@gmail.com> writes:
> Bill Atkins <············@rpi.edu> writes:
>> You modified my code segment a little - why? Also, you are linking to
>> a different thread that I was involved in on the same issue, where I
>> give a different solution, since the poster was looking for something
>> else. Here is my own code:
>>
>> (defun occurrences (list)
>> (let (result)
>> (dolist (x list)
>> (if (assoc x result)
>> (incf (cdr (assoc x result)))
>> (push (cons x 1) result)))
>> (sort result #'> :key #'cdr)))
>
> Can I modify it a bit, too? :)
>
> (defun occurrences (list)
> (let (result)
> (dolist (x list)
> (let ((count-pair (assoc x result)))
> (if count-pair
> (incf (cdr count-pair))
> (push (cons x 1) result))))
> (sort result #'> :key #'cdr)))
>
> I feel dirty calling #'assoc more times than necessary, is all.
Fair enough. The LET is more efficient but the extra indentation
bothers the aesthete in me. :)
How about a compromise:
(defun occurrences (list)
(let (result)
(dolist (x list)
(aif (assoc x result)
(incf (cdr it))
(push (cons x 1) result)))
(sort result #'> :key #'cdr)))
--
This is a song that took me ten years to live and two years to write.
- Bob Dylan
Bill Atkins <············@rpi.edu> writes:
> Fair enough. The LET is more efficient but the extra indentation
> bothers the aesthete in me. :)
>
> How about a compromise:
>
> (defun occurrences (list)
> (let (result)
> (dolist (x list)
> (aif (assoc x result)
> (incf (cdr it))
> (push (cons x 1) result)))
> (sort result #'> :key #'cdr)))
Works for me! The two spaces of extra indentation is actually more
preferable to me in this case, but things can get hairy if you're
doing anything much more complicated. Since only the IF cares about
the result of #'assoc, it is clearer to read with AIF as long as the
reader (as in the person, not #'read) is aware of AIF's semantics.
>
>
> I disagree with all of this - and not just because I wrote the code in
> question. :)
>
> Recursion is a natural fit for some problems, but for just walking
> through a list, there is a lot of extra clutter involved in the code
> that isn't necessary. Someone skimming your code now has to separate
> out the recursive template from the actual processing; I don't think
> that's a win.
Another poster enlighted me with "[Focus on recursion] is a side-effect
of Paul Graham's book that wears off with experience."
>
> Factoring out the sorting and the counting can be done without
> resorting to what you've done. If you don't like stateful
> programming, maybe Common Lisp isn't the language for you. It's not a
> purely functional language, nor was it intended to be. You'll notice
> that your own example makes use of the non-functional INCF, SORT, and
> PUSH.
That's right, but it's sort of "local".
>
> You modified my code segment a little - why?
I did not. You posted similiar code in reply to two different
posters, both with a question regarding Ex3Chapter3AnsiCL.
I picked the older one, dated March 2nd, 2006. You probably
refer to the post from April 28th, 2006. I did not modify the
code from the March 2nd-post in any way.
Also, you are linking to
> a different thread that I was involved in on the same issue, where I
> give a different solution, since the poster was looking for something
> else. Here is my own code:
>
> (defun occurrences (list)
> (let (result)
> (dolist (x list)
> (if (assoc x result)
> (incf (cdr (assoc x result)))
> (push (cons x 1) result)))
> (sort result #'> :key #'cdr)))
It's even shorter. Heh.
>
--
Lisp kann nicht kratzen, denn Lisp ist fluessig
> "Define a function that takes a list and returns a list
> indicating the number of times each (eql) element appears,
> sorting from most common element to least common."
>
> (occurrences '(a b a d a c d c a)) => ((A . 4) (C . 2) (D . 2) (B .1))
>
Not efficient, but fun:
(defun occs (x)
(remove-duplicates
(maplist #'(lambda (l) (cons (car l) (count (car l) x))) x)
:test #'equal))
===
BA (Biographical Annotation for ykw): Yes, I'm an experienced APL
programmer too!
Tin Gherdanarra <···········@gmail.com> writes:
> [...]
> Although this simple program is a toy-example, it can serve
> as a toy-example for where to set priorities in a production
> environment, so here is the question for you: Which approach
> would a real Lispnik prefer?
A production environment would have additionnal constraints. Perhaps
you have to handle one million entries?
(defun length-less-p (list length)
(not (nthcdr length list)))
(defun occurences (list)
(if (length-less-p list #+clisp 35 #+sbcl 5 #+openmcl 7
#-(or clisp sbcl openmcl) 10)
(occurences-atkins list)
(let ((counts (make-hash-table :test (function eql))))
(dolist (item list) (incf (gethash item counts 0)))
(let ((results (make-array (hash-table-count counts) :fill-pointer 0)))
(maphash (lambda (k v) (vector-push (cons v k) results)) counts)
(coerce (sort results (function >) :key (function cdr)) 'list)))))
(compile 'occurences)
(let ((data (loop for i from 1 to 1414
nconc (loop for j from 1 to i collect j))))
(time (occurences data)))
Real time: 0.712708 sec.
Run time: 0.612038 sec.
Space: 127672 Bytes
...
(compile 'OCCURRENCES-ATKINS)
(let ((data (loop for i from 1 to 1414
nconc (loop for j from 1 to i collect j))))
(time (occurrences-atkins data)))
Real time: 51.297806 sec.
Run time: 49.45509 sec.
Space: 28280 Bytes
...
> Which approach would make me look more amateurish?
If you want to look professionnal:
http://www.youngmoney.com/careers/job_hunt/021007_03
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
Pascal Bourguignon wrote:
> Tin Gherdanarra <···········@gmail.com> writes:
>
>>[...]
>>Although this simple program is a toy-example, it can serve
>>as a toy-example for where to set priorities in a production
>>environment, so here is the question for you: Which approach
>>would a real Lispnik prefer?
>
>
> A production environment would have additionnal constraints. Perhaps
> you have to handle one million entries?
In this case, it probably pays to resort to a hash-table,
as you did in your example. Thanks, by the way.
I'm surprised how well it pays off.
>
>
>
>>Which approach would make me look more amateurish?
>
>
> If you want to look professionnal:
> http://www.youngmoney.com/careers/job_hunt/021007_03
This does not look like good advice to me. How would any
potential employer trust my abilities if I show up in a suit?
I think you fell for a spoof.
>
>
>
--
Lisp kann nicht kratzen, denn Lisp ist fluessig
Tin Gherdanarra wrote:
> This does not look like good advice to me. How would any
> potential employer trust my abilities if I show up in a suit?
> I think you fell for a spoof.
IMHO, when you interview you are trying to show yourself in your best
light in all possible ways. You wouldn't show up in your underwear, or
with food on your clothes, or unshowered. Your personal appearance and
demenor is much easier to judge at an interview than your tech skills.
Most interviews that I have participated in (on both sides) boil down
to two things
1) Check that they have the skills that they said they had on paper
2) Make sure that they are taking the job seriously and will fit in
with the existing team.
At the interview stage your technical skills have already been assessed
(from your application to the job), and have been found to be alright -
otherwise you wouldn't be there. An interview is a personality
contest.
So my advice is:
Shave, shower, smell nice (but not overpowering), dress as best you
can. Make small talk, but don't tell me major personal details. Make
non-offensive jokes every now and then. Listen to the interviewers,
they should do most of the talking. Be as personable as you possibly
can - these people want to know they can work with you.
Cheers
Brad
PS - I've gotten every job that I ever interviewed for.
"bradb" <··············@gmail.com> writes:
> Tin Gherdanarra wrote:
>> This does not look like good advice to me. How would any
>> potential employer trust my abilities if I show up in a suit?
>> I think you fell for a spoof.
>
> IMHO, when you interview you are trying to show yourself in your best
> light in all possible ways. You wouldn't show up in your underwear, or
> with food on your clothes, or unshowered. Your personal appearance and
> demenor is much easier to judge at an interview than your tech skills.
> Most interviews that I have participated in (on both sides) boil down
> to two things
> 1) Check that they have the skills that they said they had on paper
> 2) Make sure that they are taking the job seriously and will fit in
> with the existing team.
>
> At the interview stage your technical skills have already been assessed
> (from your application to the job), and have been found to be alright -
> otherwise you wouldn't be there. An interview is a personality
> contest.
>
> So my advice is:
> Shave, shower, smell nice (but not overpowering), dress as best you
> can. Make small talk, but don't tell me major personal details. Make
> non-offensive jokes every now and then. Listen to the interviewers,
> they should do most of the talking. Be as personable as you possibly
> can - these people want to know they can work with you.
>
I think Brad is pretty close to the mark in his comment on the
interview being a personality contest. My advice would be to also jump
at any chance to be on an interview committee trying to fill a
position. This can be an extremely enlightening experience as it
gives you an idea of what is going through the mind of the
interviewers. Once I did this, I found I gained an incredible increase
in confidence and have gained every job I've gone to interview for
ever since. Selecting someone for a position is a difficult task and
something which often has to be judged in a relatively short period of
actual contact. In some ways, it is as hard as being interviewed.
I personally also like to try and get either one of the first or last
interview slots as I think this helps too - but this is often outside
your control.
Tim
--
tcross (at) rapttech dot com dot au
Tin Gherdanarra <···········@gmail.com> writes:
>>>Which approach would make me look more amateurish?
>> If you want to look professionnal:
>> http://www.youngmoney.com/careers/job_hunt/021007_03
>
> This does not look like good advice to me. How would any
> potential employer trust my abilities if I show up in a suit?
> I think you fell for a spoof.
;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
Tin Gherdanarra wrote:
>
> (defun countem (lst &optional accu)
> (if (null lst)
> accu
> (let ((fpair (assoc (car lst) accu)))
> (if fpair
> (incf-pair fpair)
> (push (cons (car lst) 1) accu))
> (countem (cdr lst) accu))))
>
If you are going to take the recursive route you may want to consider
changing your external interface to eliminate the optional parameter.
Provide users a function to call w/ only the required args. Have this
function call the function that actually does the work. The way you've
written it requires Lisp to do extra work on every invocation to manage
the presence or omission of the optional arg. This is really a question
that only needs to be asked once if at all. Instead:
(defun countem (list)
(labels ((do-count (list result)
(if (endp list)
result
(let ((fpair (assoc (first list) result)))
(if fpair
(incf-pair fpair)
(push (cons (first list) 1) result))
(do-count (rest list) result)))) )
(do-count list '())))
Aloha,
David Sletten