This just links to a Telegraph article talking about something that was talked about in a New York Times article, with no link to either that or the original source. Come on, Slashdot.
Re:Windows 7 is the new XP windows 8 is the new vi
on
10 Years of Windows XP
·
· Score: 1
In our case, it was Linux. We had already bought our workstations for the office (assembled from components off Newegg), and called up to get volume licensing on Win7, since we could only find volume OS upgrades on their action pack deal online. We were told we "weren't allowed" to build our own boxes; we had to buy hardware with OEM OS licenses, then upgrade from those. Standalone licenses were no longer offered, and the upgrade pack was in a similar price range that the full OS licenses were in the past.
No, Microsoft, you're not going to double-dip. We're now a Linux shop.
Had we not already purchased the hardware, Macs would have been a serious consideration. But Linux is chugging along fine with our network environment & applications. Meanwhile, the Mac Mini in the conference room being the only box that gives us grief. From my anecdotal input here & from others, a Mac is fine as long as it's a standalone or internet box. But once you start playing around with identities on LANs and get heterogeneous, you really battle the OS and have to dig into the half-BSD half-Apple nightmare under the pretty face.
Software development used to be easier when I started this life...
I don't know when you started yours, but I got going in the 80s 8-bit home computer era. Everything of consequence was assembly language, and every platform was completely incompatible. Even on the mainframes, you still had a variety of HLLs and completely different OSes & architectures.
Everything nowadays is x86/x64, everything runs C++ and hence most interpreted languages, and most everything runs Java. Graphics are fast, storage is gigantic, libraries are mature, and connectivity is pretty much a given. Software development is MUCH easier nowadays.
Just as random musing, I think this sort of life could work with a 2-class system.
The creative class will be small, those with independent drive to go out and accomplish something. The rest will be the hedonistic class, just trying different ways of keeping themselves amused.
Transitioning between the two classes should be possible, but both would need some sort of legal system. The creative class would have larger resources available to them, but should be bound to actually using them for productive goal-driven purposes, instead of just being hedonistic in a different context. The hedonistic class needs to be bounded in terms of what they can do to others, and maintaining basic civility. Of course, if there's no resource scarcity at all (free replicators, etc, not just automated gruntwork), then who knows.
Real estate will always be a scarcity, though. Popular places, ability to own larger areas, etc, are not going to diminish in attractiveness.
I actually don't think there's anything wrong with encouraging people and companies to develop these kinds of inventions. If we can push-off all the $5 jobs to machines and expect our citizens to have a decent education, that's good in my book.
That's a nice sentiment, but how do they pay for that education? What about people who simply are not and will not be skilled beyond basic gruntwork?
Also, if living becomes cheaper due to automation, you still need some small income in order to purchase & maintain your own automation equipment, or to purchase the cheap products that come from automation. Having easy (for a human), low-paying jobs could allow a number of otherwise impoverished people to live decently in such circumstances, and a reduction of minimum wage (or classification of certain menial jobs exempt from minimum wage) might stimulate that.
However, we're not there yet. Things like rent are still going to be an issue for the foreseeable future with respect to $2/hr work.
Some other blog also pointed out that one of the big "modern" features tons of people rely on was invented in 1959: Garbage collection.
Say what you will about Lisp (and I'll say lots of good things about it), but practical GC has tremendous impact. Now, we just have to wait for everything else to catch up to all the other 1960s feature sets (both software & hardware).:-)
Note that I've only recently read up on Paul's stances. Seeing all the "R'evol'ution" signs and whatnot, I always thought Ron Paul was the guy behind some concerts or festivals or something.
Ruin Paul's political philosophy seems to be that since government has been unable to completely solve every problem perfectly, we should just stop using it.
No, his philosophy is that the constitution doesn't specifically permit the government to do what it's doing, so all those extra-constitutional departments and authorities should not be run at the federal level. It's not that those programs shouldn't exist, they just shouldn't exist *federally*; they should be run by the state governments, or privately. He seems to have been saying that exact same thing for decades, even through the prosperous ones.
The instant you start giving money, everybody bends themselves to get the biggest slice of that pie, regardless of the effect. Schools know that students will be propped up by loans, so they can increase their spending without changing their student demographics. You see the same thing in insurance rackets and everywhere else.
For many bedroom or non-game coders who've had vague ideas about doing a game, but never bothered going beyond simple code-tests, the deadline is a great kick in the pants to actually start *and finish* a game, teaching you to overcome analysis paralysis or feature creep. Plus, in a team, each member gets to focus on their expertise instead of needing to pull the whole game together on their own. And for everybody, it's a nice short, condensed means to exercise your chops, and make connections for larger projects.
The actual game's quality might not have anything to do with a successful jam.
Btw, the above is a reconstruction. I don't have my original source code; my edits morphed into a larger VM, eventually replacing all the SWEET16-isms with a stack-based architecture. I'm not sure what I wrote above is proper, but it was something around the branching instructions that could be shortened slightly. Remains [citation needed] unfortunately.:-(
The 6510 was derived from the plain 6502, and has the exact same set of opcodes. I'm not sure about the "illegal opcodes", since I think I've only ever used them once (and never in doing robust things like these bytecode VMs).
No, there aren't any 6510-only instructions. I seemed to be remembering a bit incorrectly, because now that I looked it up, what I believe I did was move the BC implementation above BR, replacing BC's "BCS BR , RTS" with a single "BCC BNC2" instruction, which saves 1 byte, not 2 cycles.
I thought I had optimized away a single SEC/CLC instruction for 2 cycles, but it was an RTS that I eliminated from the footprint, but not from the actual execution flow, making use of a preexisting RTS. Given an equal amount of BC branches & non-branches, the cycle count would have remained the same, but dangit it's one whole byte shorter!:-)
It's great to see as time marches on, that Woz remains so true to his roots & initial interests.
As a side note, I removed 2 cycles from his SWEET16 interpreter when I ported it to the C64, without affecting functionality. That was an amazing little moment in my life, and felt as a great accomplishment given the body of work.:-)
How do trade, communication, negotiation, and travel with the rest of the world mean "pretend the rest of the world doesn't exist"? None of these subvert the sovereignty of the nations involved; tying or forcing the hands of individual nations' laws via these treaties & organizations does.
Scripting controls, configures, and gives data to existing programs as its primary purpose, while programming creates new programs.
It's a lay definition of course. s/programs/behaviors/ to taste. You can perform programming in scripting languages and vice versa, and if you dig too deep the definition breaks down.
(Just to be fully clear, I view this as an interesting semantic dive, not a heated argument; I hope you consider it the same)
From our exchange so far I think you are too stuck on mutability, while I insist on using some programming techniques whenever programming language allows them.
First part, yes, I've been using mutability as a contrast to your point. (The core of my programming is in functional style.) Your statement was that first class functions, etc, are indicators that a language is "more functional" because of them. I say it's not a measure of how functional it is because it's a completely independent language feature, orthogonal to and irrelevant to functional vs not, fitting in just as comfortably with mutable & imperative languages/styles by example.
Second part, I agree with you, and that's not a concept I took issue with. The above is.
You keep deferring to the use of the features, but your suspect statements were about intrinsic properties of the features themselves, and of the languages which contain those features, not their use.
I've no problem in seeing things this way, but the problem in defining things negatively like this is that it does not answer the question: what *does* have to do with (pure or not) functional languages?
In this, I didn't define features negatively. I just said that they're cool language features. That's it. You seem to have invented the term "functional but not 'pure functional' language feature" but I haven't seen that actually work; the stuff brought up so far has no distinction making it "functional" at all. CPS, first-class functions, TCO, have their own definition as plain-Jane normal regular features, and can be individually added to or removed from pretty much any language regardless of functional programming support, style, or usage (from either the programmer or the language itself).
If a language itself provides features specific to functional programming, those would be things which allow the user to communicate, and the compiler/runtime to take advantage of, the implications of referential transparency, which is likely the most important differentiator of that programming style: Arbitrary evaluation order, arbitrary short-cutting, arbitrary memoization, arbitrary parallelism, enforcement or containment of immutability, etc. Most functional features are semantic and don't manifest in syntactic language constructs, because stateful/mutating/imperative programming languages already contain the primitives needed for expressing the actual computation; functional languages don't need to do anything new there.
An answer I offered was: a purely functional program is made of composition of (no side-effects) functions, and has referential transparency. Category theory offers us an even more general definition.
Your original statement was not about a program, but if a language itself was "more functional" or "less functional" based on the presence of first-class functions, TCO, CPS, and the like. All the other stuff you've brought up I tend to agree with; that original point of a scalar "functional" property is what I keep pointing back to.;-)
Regarding "functional but not 'pure functional'" language features, I don't think they exist but solely due to the lack of examples. Since none was given, I would accept the definition as "a feature which is generally useful only to functional programming, but can freely coexist in a language that is mutable and imperative." That which meets the former but not the latter would be a "pure functional" feature, and that which meets the latter but not the former is just a general feature (or a purely imperative/mutable feature). Does this align with your line of thinking, as you brought the distinction up?
First class functions, TCO, CPS, are exactly as useful outside of functional style as within it, so they just fall back to being general features by
Yes, I think it's a difference in definitions. There's a lot of redundancy coming up, just to be utterly clear in my understanding of the disconnect.
I obviously agree that immutable/functional programming style has great benefits, and that most languages do not enforce the style as Haskell does.
I do NOT see the specific language features of anonymous procedures+closures (which is what Lisp "lambdas" really are), recursion, continuation passing style, and the like as having *anything at all to do with functional programming*. I've used lots of these (or built-up equivalents) as organizational tools managing *fully mutable state* in C++, Java and other non-"functional" languages, to the same organizational benefit as they yield in functional contexts. None of these require functional programming or are indicators that functional style is being used. You can use them to the exact same benefit without functional programming. They're orthogonal concepts.
So the these particular features have nothing to do with being used functionally, nor do their presence in a language make the language any "more" or "less" functional, which was what I started this on.
For example:
It's not just that functional programming restricts, it also offers certain techniques of programming, like continuation-passing.
Continuation-passing style has nothing to do with functional programming, and is available & just as useful in mutable contexts. Functional programming does not "offer" CPS; it's an independent idiom available anywhere, functional or not. Same thing with first-class functions, TCO, etc. They have no connection with functional programming, beyond the connection that the less-than operator has to functional programming (ie, they're used by it, but every style can use it so there's no real link).
I've also used the features in question heavily in strictly immutable contexts in Lisp and Erlang, taking full advantage of MVCC and thread-safety gained from immutability. They're truly general purpose idioms and features, not bound to a particular style. They do not beckon "functional" into their use by their nature and are fully compatible with mutability, offering the *exact* same benefits to both mutable and immutable programming.
Other language features which do beckon "functional" into their use by their nature are not compatible with mutability (all the Haskell differentiations, basically), I agree. You call these "pure functional" features, but I don't think ANY "functional" features which are not "pure functional" actually exist as such. All the ones discussed so far are exactly as useful in mutable/stateful contexts and thus don't have anything to do with being "functional" themselves (first-class procedures, continuation passing, etc).
So I can agree to disagree. I disagree that "C doesn't have first class functions" leads to "therefore it is less functional than Lisp", as the presence or use of first class functions neither indicates nor requires functional style or its benefits. In the other direction, I think you've not considered the value of these features as part of mutable solutions where they're just as great. This fact enforces the orthogonality which breaks your "therefore".
(gotta run, the above could probably have been edited more)
I find it a bit difficult to see your responses in terms of the question actually asked, so let's back up a bit. You had originally said that Lisp is "more" functional or "less" functional than other languages, even though it doesn't have any functional features or assumptions at all. Then you say it's "not functional in the modern sense of the word" (pure functional), implying it's functional in some other sense. I'm asking what sense that is.
Recursion, first-class functions, recursive data structures, etc, are general purpose programming tools perfectly useful and applicable in any code, including stateful mutating imperative code.
The things you list in your 2nd "if" paragraph are focused functional programming tools, but they obviously collide with stateful constructs if they were to coexist in the same language, tending to yield mutually exclusive language features. (See also Erlang's tenuous balancing act between the two concepts.) Common Lisp's language design doesn't wander into that territory at all. Everything in CL is mutable and there's no mechanisms for communicating functional usage or constraints into the system; they exist purely and solely as programmer discipline, not language features. A single setf inside some optimized loop somewhere in a utility function, or not realizing that something like 'sort' is allowed to trample its parameters, can screw your whole program up if you're trying to stick to functional style, forcing you do manually manage copies for different contexts. I'm not aware of any means for the compilers to detect and issue warnings about such intent breaches. And yes, I say this as somebody who develops commercial software using heavily functional style in Common Lisp: There is nothing functional about the language itself.
I'm wondering why you consider it "more functional" than C or other non-pure-functional languages, especially given the age of Lisp and that actual pure functional languages are a recent development. It's a strictly ordered, fully mutable language, with some really cool metaprogramming, dispatch, runtime, math, and symbolic features among others. While it's very powerful, it's still completely imperative by nature with no inbuilt concessions to intrinsically support functional discipline. Functional style in Lisp is built on top of ordered imperative Lisp constructs (constructors & unconstrained in-order procedure calls, same as any other imperative language) and the GC.
Slashdot Mirror
Right, "but is it cool?" is the question at hand.
This just links to a Telegraph article talking about something that was talked about in a New York Times article, with no link to either that or the original source. Come on, Slashdot.
In our case, it was Linux. We had already bought our workstations for the office (assembled from components off Newegg), and called up to get volume licensing on Win7, since we could only find volume OS upgrades on their action pack deal online. We were told we "weren't allowed" to build our own boxes; we had to buy hardware with OEM OS licenses, then upgrade from those. Standalone licenses were no longer offered, and the upgrade pack was in a similar price range that the full OS licenses were in the past.
No, Microsoft, you're not going to double-dip. We're now a Linux shop.
Had we not already purchased the hardware, Macs would have been a serious consideration. But Linux is chugging along fine with our network environment & applications. Meanwhile, the Mac Mini in the conference room being the only box that gives us grief. From my anecdotal input here & from others, a Mac is fine as long as it's a standalone or internet box. But once you start playing around with identities on LANs and get heterogeneous, you really battle the OS and have to dig into the half-BSD half-Apple nightmare under the pretty face.
Software development used to be easier when I started this life...
I don't know when you started yours, but I got going in the 80s 8-bit home computer era. Everything of consequence was assembly language, and every platform was completely incompatible. Even on the mainframes, you still had a variety of HLLs and completely different OSes & architectures.
Everything nowadays is x86/x64, everything runs C++ and hence most interpreted languages, and most everything runs Java. Graphics are fast, storage is gigantic, libraries are mature, and connectivity is pretty much a given. Software development is MUCH easier nowadays.
Just as random musing, I think this sort of life could work with a 2-class system.
The creative class will be small, those with independent drive to go out and accomplish something. The rest will be the hedonistic class, just trying different ways of keeping themselves amused.
Transitioning between the two classes should be possible, but both would need some sort of legal system. The creative class would have larger resources available to them, but should be bound to actually using them for productive goal-driven purposes, instead of just being hedonistic in a different context. The hedonistic class needs to be bounded in terms of what they can do to others, and maintaining basic civility. Of course, if there's no resource scarcity at all (free replicators, etc, not just automated gruntwork), then who knows.
Real estate will always be a scarcity, though. Popular places, ability to own larger areas, etc, are not going to diminish in attractiveness.
Still, nobody gets the proper capitalization of Lisp.
I actually don't think there's anything wrong with encouraging people and companies to develop these kinds of inventions. If we can push-off all the $5 jobs to machines and expect our citizens to have a decent education, that's good in my book.
That's a nice sentiment, but how do they pay for that education? What about people who simply are not and will not be skilled beyond basic gruntwork?
Also, if living becomes cheaper due to automation, you still need some small income in order to purchase & maintain your own automation equipment, or to purchase the cheap products that come from automation. Having easy (for a human), low-paying jobs could allow a number of otherwise impoverished people to live decently in such circumstances, and a reduction of minimum wage (or classification of certain menial jobs exempt from minimum wage) might stimulate that.
However, we're not there yet. Things like rent are still going to be an issue for the foreseeable future with respect to $2/hr work.
Some other blog also pointed out that one of the big "modern" features tons of people rely on was invented in 1959: Garbage collection.
Say what you will about Lisp (and I'll say lots of good things about it), but practical GC has tremendous impact. Now, we just have to wait for everything else to catch up to all the other 1960s feature sets (both software & hardware). :-)
*closes a Lisp paren (in a real, commercial Lisp application no less) in honor of McCarthy*
Maternal trust & comfort seems a more like culprit than sexual attraction.
Note that I've only recently read up on Paul's stances. Seeing all the "R'evol'ution" signs and whatnot, I always thought Ron Paul was the guy behind some concerts or festivals or something.
Ruin Paul's political philosophy seems to be that since government has been unable to completely solve every problem perfectly, we should just stop using it.
No, his philosophy is that the constitution doesn't specifically permit the government to do what it's doing, so all those extra-constitutional departments and authorities should not be run at the federal level. It's not that those programs shouldn't exist, they just shouldn't exist *federally*; they should be run by the state governments, or privately. He seems to have been saying that exact same thing for decades, even through the prosperous ones.
The instant you start giving money, everybody bends themselves to get the biggest slice of that pie, regardless of the effect. Schools know that students will be propped up by loans, so they can increase their spending without changing their student demographics. You see the same thing in insurance rackets and everywhere else.
Free money ruins good intentions.
Do tinfoil hats cause cancer?
For many bedroom or non-game coders who've had vague ideas about doing a game, but never bothered going beyond simple code-tests, the deadline is a great kick in the pants to actually start *and finish* a game, teaching you to overcome analysis paralysis or feature creep. Plus, in a team, each member gets to focus on their expertise instead of needing to pull the whole game together on their own. And for everybody, it's a nice short, condensed means to exercise your chops, and make connections for larger projects.
The actual game's quality might not have anything to do with a successful jam.
IABCOD "Imagine a Beowulf cluster of dishes!"
Btw, the above is a reconstruction. I don't have my original source code; my edits morphed into a larger VM, eventually replacing all the SWEET16-isms with a stack-based architecture. I'm not sure what I wrote above is proper, but it was something around the branching instructions that could be shortened slightly. Remains [citation needed] unfortunately. :-(
The 6510 was derived from the plain 6502, and has the exact same set of opcodes. I'm not sure about the "illegal opcodes", since I think I've only ever used them once (and never in doing robust things like these bytecode VMs).
No, there aren't any 6510-only instructions. I seemed to be remembering a bit incorrectly, because now that I looked it up, what I believe I did was move the BC implementation above BR, replacing BC's "BCS BR , RTS" with a single "BCC BNC2" instruction, which saves 1 byte, not 2 cycles.
I thought I had optimized away a single SEC/CLC instruction for 2 cycles, but it was an RTS that I eliminated from the footprint, but not from the actual execution flow, making use of a preexisting RTS. Given an equal amount of BC branches & non-branches, the cycle count would have remained the same, but dangit it's one whole byte shorter! :-)
It's great to see as time marches on, that Woz remains so true to his roots & initial interests.
As a side note, I removed 2 cycles from his SWEET16 interpreter when I ported it to the C64, without affecting functionality. That was an amazing little moment in my life, and felt as a great accomplishment given the body of work. :-)
Way to false dichotomy there, genius.
How do trade, communication, negotiation, and travel with the rest of the world mean "pretend the rest of the world doesn't exist"? None of these subvert the sovereignty of the nations involved; tying or forcing the hands of individual nations' laws via these treaties & organizations does.
Scripting controls, configures, and gives data to existing programs as its primary purpose, while programming creates new programs.
It's a lay definition of course. s/programs/behaviors/ to taste. You can perform programming in scripting languages and vice versa, and if you dig too deep the definition breaks down.
(Just to be fully clear, I view this as an interesting semantic dive, not a heated argument; I hope you consider it the same)
From our exchange so far I think you are too stuck on mutability, while I insist on using some programming techniques whenever programming language allows them.
First part, yes, I've been using mutability as a contrast to your point. (The core of my programming is in functional style.) Your statement was that first class functions, etc, are indicators that a language is "more functional" because of them. I say it's not a measure of how functional it is because it's a completely independent language feature, orthogonal to and irrelevant to functional vs not, fitting in just as comfortably with mutable & imperative languages/styles by example.
Second part, I agree with you, and that's not a concept I took issue with. The above is.
You keep deferring to the use of the features, but your suspect statements were about intrinsic properties of the features themselves, and of the languages which contain those features, not their use.
I've no problem in seeing things this way, but the problem in defining things negatively like this is that it does not answer the question: what *does* have to do with (pure or not) functional languages?
In this, I didn't define features negatively. I just said that they're cool language features. That's it. You seem to have invented the term "functional but not 'pure functional' language feature" but I haven't seen that actually work; the stuff brought up so far has no distinction making it "functional" at all. CPS, first-class functions, TCO, have their own definition as plain-Jane normal regular features, and can be individually added to or removed from pretty much any language regardless of functional programming support, style, or usage (from either the programmer or the language itself).
If a language itself provides features specific to functional programming, those would be things which allow the user to communicate, and the compiler/runtime to take advantage of, the implications of referential transparency, which is likely the most important differentiator of that programming style: Arbitrary evaluation order, arbitrary short-cutting, arbitrary memoization, arbitrary parallelism, enforcement or containment of immutability, etc. Most functional features are semantic and don't manifest in syntactic language constructs, because stateful/mutating/imperative programming languages already contain the primitives needed for expressing the actual computation; functional languages don't need to do anything new there.
An answer I offered was: a purely functional program is made of composition of (no side-effects) functions, and has referential transparency. Category theory offers us an even more general definition.
Your original statement was not about a program, but if a language itself was "more functional" or "less functional" based on the presence of first-class functions, TCO, CPS, and the like. All the other stuff you've brought up I tend to agree with; that original point of a scalar "functional" property is what I keep pointing back to. ;-)
Regarding "functional but not 'pure functional'" language features, I don't think they exist but solely due to the lack of examples. Since none was given, I would accept the definition as "a feature which is generally useful only to functional programming, but can freely coexist in a language that is mutable and imperative." That which meets the former but not the latter would be a "pure functional" feature, and that which meets the latter but not the former is just a general feature (or a purely imperative/mutable feature). Does this align with your line of thinking, as you brought the distinction up?
First class functions, TCO, CPS, are exactly as useful outside of functional style as within it, so they just fall back to being general features by
Yes, I think it's a difference in definitions. There's a lot of redundancy coming up, just to be utterly clear in my understanding of the disconnect.
I obviously agree that immutable/functional programming style has great benefits, and that most languages do not enforce the style as Haskell does.
I do NOT see the specific language features of anonymous procedures+closures (which is what Lisp "lambdas" really are), recursion, continuation passing style, and the like as having *anything at all to do with functional programming*. I've used lots of these (or built-up equivalents) as organizational tools managing *fully mutable state* in C++, Java and other non-"functional" languages, to the same organizational benefit as they yield in functional contexts. None of these require functional programming or are indicators that functional style is being used. You can use them to the exact same benefit without functional programming. They're orthogonal concepts.
So the these particular features have nothing to do with being used functionally, nor do their presence in a language make the language any "more" or "less" functional, which was what I started this on.
For example:
It's not just that functional programming restricts, it also offers certain techniques of programming, like continuation-passing.
Continuation-passing style has nothing to do with functional programming, and is available & just as useful in mutable contexts. Functional programming does not "offer" CPS; it's an independent idiom available anywhere, functional or not. Same thing with first-class functions, TCO, etc. They have no connection with functional programming, beyond the connection that the less-than operator has to functional programming (ie, they're used by it, but every style can use it so there's no real link).
I've also used the features in question heavily in strictly immutable contexts in Lisp and Erlang, taking full advantage of MVCC and thread-safety gained from immutability. They're truly general purpose idioms and features, not bound to a particular style. They do not beckon "functional" into their use by their nature and are fully compatible with mutability, offering the *exact* same benefits to both mutable and immutable programming.
Other language features which do beckon "functional" into their use by their nature are not compatible with mutability (all the Haskell differentiations, basically), I agree. You call these "pure functional" features, but I don't think ANY "functional" features which are not "pure functional" actually exist as such. All the ones discussed so far are exactly as useful in mutable/stateful contexts and thus don't have anything to do with being "functional" themselves (first-class procedures, continuation passing, etc).
So I can agree to disagree. I disagree that "C doesn't have first class functions" leads to "therefore it is less functional than Lisp", as the presence or use of first class functions neither indicates nor requires functional style or its benefits. In the other direction, I think you've not considered the value of these features as part of mutable solutions where they're just as great. This fact enforces the orthogonality which breaks your "therefore".
(gotta run, the above could probably have been edited more)
I find it a bit difficult to see your responses in terms of the question actually asked, so let's back up a bit. You had originally said that Lisp is "more" functional or "less" functional than other languages, even though it doesn't have any functional features or assumptions at all. Then you say it's "not functional in the modern sense of the word" (pure functional), implying it's functional in some other sense. I'm asking what sense that is.
Recursion, first-class functions, recursive data structures, etc, are general purpose programming tools perfectly useful and applicable in any code, including stateful mutating imperative code.
The things you list in your 2nd "if" paragraph are focused functional programming tools, but they obviously collide with stateful constructs if they were to coexist in the same language, tending to yield mutually exclusive language features. (See also Erlang's tenuous balancing act between the two concepts.) Common Lisp's language design doesn't wander into that territory at all. Everything in CL is mutable and there's no mechanisms for communicating functional usage or constraints into the system; they exist purely and solely as programmer discipline, not language features. A single setf inside some optimized loop somewhere in a utility function, or not realizing that something like 'sort' is allowed to trample its parameters, can screw your whole program up if you're trying to stick to functional style, forcing you do manually manage copies for different contexts. I'm not aware of any means for the compilers to detect and issue warnings about such intent breaches. And yes, I say this as somebody who develops commercial software using heavily functional style in Common Lisp: There is nothing functional about the language itself.
I'm wondering why you consider it "more functional" than C or other non-pure-functional languages, especially given the age of Lisp and that actual pure functional languages are a recent development. It's a strictly ordered, fully mutable language, with some really cool metaprogramming, dispatch, runtime, math, and symbolic features among others. While it's very powerful, it's still completely imperative by nature with no inbuilt concessions to intrinsically support functional discipline. Functional style in Lisp is built on top of ordered imperative Lisp constructs (constructors & unconstrained in-order procedure calls, same as any other imperative language) and the GC.