What does “my other car is a cdr” mean?
stackoverflow.com
stackoverflow.com
Same on the next one.
Since cdr always returns a list, to get a single item you would need to call car on it, therefore cadr.
My it's sad how Common Lisp has faded away in the last 10 years. It had a great community.
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.
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.
Surely not in Common Lisp. Common Lisp code is often just as imperative as Python code.
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).
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
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.
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.
What tipped you off? Was it setq, or perhaps nconc or delete?
For me, it was tagbody. I was like, "go ? Okay, this is still a functional language, but now way can I call it truly functional."
I will leave discourse about the degree of purity that grants a "truly" moniker to people with more free time, but I suspect it's counter-productive.