To me the original makes more sense. A cons cell is a 2-tuple. CAR retrieves the first element; CDR retrieves the "other" one. The fact that CARs are usually atoms and CDRs are usually lists is a convention, not a rule. You can easily put an atom in the CDR of a cons (this is called a dotted pair) and you can easily put a list in the CAR.
If you have a list `(Odyssey Model-S)`, `car` will be `Odyssey`, `cdr` will be a list `(Model-S)`. You yet need to do a `car` on that.. So `(car (cdr ..))` will give you `Model-S`. `(cadr ..)` is short for `(car (cdr ..))`.
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.
More or less every mainstream language has adopted first-class functions to the extent that they can. JS has always had them. C++, C#, Java have all added them; Python and Ruby have had them for a while now. Standard functional programming constructs like map, filter, and reduce are now extremely familiar, whereas not too long ago they would have required a tutorial and explanation.
And just as imperative languages have adopted functional features, functional languages are growing more popular. Even if you just limit yourself to Lisps, Clojure is used widely. There are probably many more Lisp programmers now than there were 5 or 10 years ago, thanks to Clojure's adoption. Branching out a bit, Scala is also very popular.
That's not even to consider hipper, trendier things like Elm, or the increased popularity and visibility of Haskell.
Huh, maybe I just haven't been talking to the right people. I always felt like I was surrounded by people who didn't want to bother with functional languages any further.
It's true that every mainstream language has adopted first-class functions, but that's not all that a functional language gives you. Writing in Common Lisp or Scheme, you have to adapt a different outlook on how you view states, what a function means, what side-effects are, and you become very much more careful about how and when you apply those concepts in your programs.
But yeah, I agree with you, those concepts being included in mainstream languages definitely decreases the barrier to entry to more pure functional languages, and definitely pushed more people toward there.
Didn't think of Scala, you're right, it's very popular.
I was just speaking from personal experience, didn't actually look into how things are going outside my scope.
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).
> 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, ...
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.
> My take is that Common Lisp was never really truly a functional language.
Lisps in general have always been what now is sometimes called "impure functional programming languages"; until fairly recently, it wasn't really all that common to equate pure functional languages with "real" functional languages, it seems to me that is used to be that a "real functional language" was one that had reasonable ergonomic support for programming in the functional paradigm, not one that supported only the functional paradigm.
I keep meaning to learn some functional programming just for learning and introduction to new ideas, but I basically forget they exist typically. Never see them referenced in the "business" side, only ever in techie discussion. Not much motivation indeed.
I would say exactly the opposite is happening. While I can't comment on how many people are using out and out functional languages (like Haskell or Lisp), I would say that far more developers and modern languages are adopting functional techniques and paradigms than they were 10 years ago (even developers and languages that were traditionally staunchly OO, such as Java).
Had to learn Scheme in college too. It was the only functional language taught, it was taught as an intro course, and most people, including professors, didn't like Scheme.
