
What does “my other car is a cdr” mean? - palad1n
https://stackoverflow.com/questions/1864795/what-does-my-other-car-is-a-cdr-mean
======
sf_rob
Reminds me of my Lisp professor's terrible joke, "Today we're going to learn
about defining functions because that's where de fun's at"...

~~~
plafl
Related:
[http://www.poppyfields.net/filks/00103.html](http://www.poppyfields.net/filks/00103.html)

------
frou_dh
Small sticker on a car's rear bumper: "If you can read this then you're my
cdr".

Same on the next one.

------
lispfan01
CAR and CDR
[https://en.m.wikipedia.org/wiki/CAR_and_CDR](https://en.m.wikipedia.org/wiki/CAR_and_CDR)

------
technologia
Personally I love the response that Peter gave, especially the revision "my
other CAR is a CADR. CDR isn't a CAR at all"

~~~
gm-conspiracy
CDR is the "input" to CADR and the result is CAR?

~~~
ball_of_lint
Not exactly, cadr is what you would get if you called CDR on a list, then car
on the result of that. Lisp has several of these types of chains.

Since cdr always returns a list, to get a single item you would need to call
car on it, therefore cadr.

~~~
ambulancechaser
someone mentioned it earlier but it's not true that cdr always returns a list,
for instance, `(cdr `(1 . 2))`

------
KirinDave
Oooohhh I had forgotten this. For once, this website made me smile.

My it's sad how Common Lisp has faded away in the last 10 years. It had a
great community.

~~~
teolandon
It's very sad how most new programmers aren't even versed in any functional
languages, or even know what they are. Everyone learns imperative because
they're so much easier and intuitive initially. Well, that and... almost
everyone in software development now uses some kind of imperative language, or
some .js framework.

Granted, there still are big projects in Common Lisp today, Emacs still going
strong, lots of travel websites are also in Lisp. But yeah, not much
motivation for new programmers to learn that type of language.

~~~
KirinDave
I suppose, and I'm a big Purescript & Haskell fan these days but...

My take is that Common Lisp was never really truly a functional language. It
has always been a hybrid language that focused on the unique aspects of Lisp
first, and everything else second. Lisp's focus on superior macro facilities,
the CLOS, and the MOP really shows in the spec. CL primitives were never as
concerned about general composability as they were about offering syntax to
cover every conceivable case.

To some extent, I miss this philosophy. Meta-syntactic programming is
something important and fundamental to language (as opposed to the monadic
style of haskell which is more fundamental to computation).

~~~
lispm
> My take is that Common Lisp was never really truly a functional language.

That's not really news. Lisp was always trying to support functional
programming, but it was not enforcing it - though in some parts of the
language non-pure functional programming is slightly difficult to avoid.

What Common Lisp did first in Lisp was that it took the lexical binding
first/always idea, explored in Scheme, and integrated it into Lisp. Different
from Scheme, Common Lisp kept the support for dynamic binding directly in the
language and still made use of it in the language. Closures already existed in
the precursors of Common Lisp, but as a separate construct (see for example
the support in Lisp Machine Lisp).

Common Lisp also defined that lexical binding had to work both for the
interpreter and the compiler - whereas in precursors of Common Lisp the
Interpreter usually implemented dynamic binding by default and the compiler
implemented lexical binding. Scheme in its standard did not mention
compilation/interpretation and their effects - though it was expected that
both, interpreters and compilers, use the same semantics.

What Common Lisp does, both in the language and in its library, is to support
a form of programming with functions, first class functions, higher-order
functions. Implementations also support TCO, which enables a more functional
style of control flow. Libraries then explore lazy streams (see for example
the chapter on Series in CLtL2 from 1990) and similar concepts.

Common Lisp was always a hybrid language supporting multiple paradigms out-of-
the-box: symbolic programming, imperative/procedural programming, meta-
syntactic programming, reflective programming, object-oriented programming,
non-pure functional programming, meta-object-oriented programming. More
complete implementations/applications add various forms of logic programming,
rule-based programming, concurrent/parallel programming, visual-programming,
...

The

~~~
KirinDave
Since I have little to no patience today, I cannot resist saying: I have no
idea why you said this, who you said it to, who you thought would find it
compelling, or what it's point is.

I know a lot of what you're saying, but you presented it in a contrarian mode.
Like you were trying to make something clear. But your post doesn't illuminate
anything except perhaps some trivia acquired in our shared history.

My only conclusion is that you were eager to talk about this but not to have a
conversation about it. Perhaps in the future, placing it higher up the comment
hierarchy will get you want you want.

------
jeremy0x4a
I _just_ came across a reference to this while attempting to establish my
Keybase proof for Hacker News and now I've fallen down a rabbit hole.

------
lathiat
Here I was thinking it was some kind of joke about you wouldn't download a
car.. never learnt Lisp!

------
diegoprzl
Mess with the car die like the cdr.

