Lisp
Now that I have the free time to justify it, I've been working through Project Euler in Lisp. It has been exquisite.
I'd done perhaps fifty problems from PE in C when I was considering making a go of it in computer science/software engineering and was practicing for interview questions. It may be that this time around I'm just free from the anxiety of narrowing my job prospects if I didn't code quickly/cleanly/natively enough, but the difference in feel is striking in a way that seems to transcend the obvious explanation, i.e. procedural-vs-functional. I guess I'd always accepted the received opinion that what Ritchie did, in part, was to develop a syntax that facilitated the expression of certain thoughts. Specifically, certain patterns of good thoughts, and in such a way that the average programmer could keep the entire structure of the language in their head. But with Lisp, it's as though I'm sitting at Uncle John McCarthy's knee as he reaches behind my ear and pulls out the structure of reality like so many quarters.
Another way this difference cashes out, at least in my limited experience, is in how the languages draw one to the more "native" features of their specifications. I remember taking a class in C and spending weeks and weeks implementing the bestiary of lists and doubly linked lists, yea unto queues and stacks. Then we'd tackle a project where it seemed even half-reasonable to roll up on a problem with an abstract data type, whereupon the instructor would kind of kick at the ground and mutter "well, you'd probably just want to use a nested for loop here." And forsooth, we probably did just want to use a nested for loop, because that would usually be a) easier and b) more readily comprehensible if we reviewed the code in another month. I don't mean to suggest that the NFL was the Right Thing there-it almost certainly wasn't. And if I had better intuitions about C, I would no doubt reread the code I wrote and lemon-pucker. I mean that nothing in the structure of C seemed to scream at me like second gear on the highway when I wasn't doing the Right Thing. Kludging heartily away with the basic constructs felt, throughout, like a perfectly reasonable thing to do.
With Lisp, however, I often get a prickly sense when coding that there should be a better way. Then I rummage around and, much more often than not, find the construct I should have been using all the while. You might object that this is a trivial anthropic-principle phenomenon: in one's initial courtship with a language, one will almost always be coding without recourse to its full functionality so it should come as no surprise that one is Doing it Wrong. All true, yet I've never before felt such a compulsion from the language itself to work out the more recondite features in order to solve problems.
One might locate that difference in the fact that, in Lisp, the more "recondite" features are so much more powerful, usually much closer to the core of the language, and therefore less justifiably thought "recondite" in the first place. I'm sure that in C, for example, if one had fiery passion and Godlike clarity about the relationship between compiler and the physical state of the machine, it would be possible to write things that resembled higher-order functions. (I mean "possible" in the sense that the C-T thesis stipulates.) But few are so disposed, and as it's been pointed out many times, the easiest way to do such a thing would be to re-implement a Lisp interpreter in C. So in C, one learns to do without. Once you've had them, though, doing without feels like self-sequestration to a mental ghetto.
I'd done perhaps fifty problems from PE in C when I was considering making a go of it in computer science/software engineering and was practicing for interview questions. It may be that this time around I'm just free from the anxiety of narrowing my job prospects if I didn't code quickly/cleanly/natively enough, but the difference in feel is striking in a way that seems to transcend the obvious explanation, i.e. procedural-vs-functional. I guess I'd always accepted the received opinion that what Ritchie did, in part, was to develop a syntax that facilitated the expression of certain thoughts. Specifically, certain patterns of good thoughts, and in such a way that the average programmer could keep the entire structure of the language in their head. But with Lisp, it's as though I'm sitting at Uncle John McCarthy's knee as he reaches behind my ear and pulls out the structure of reality like so many quarters.
Another way this difference cashes out, at least in my limited experience, is in how the languages draw one to the more "native" features of their specifications. I remember taking a class in C and spending weeks and weeks implementing the bestiary of lists and doubly linked lists, yea unto queues and stacks. Then we'd tackle a project where it seemed even half-reasonable to roll up on a problem with an abstract data type, whereupon the instructor would kind of kick at the ground and mutter "well, you'd probably just want to use a nested for loop here." And forsooth, we probably did just want to use a nested for loop, because that would usually be a) easier and b) more readily comprehensible if we reviewed the code in another month. I don't mean to suggest that the NFL was the Right Thing there-it almost certainly wasn't. And if I had better intuitions about C, I would no doubt reread the code I wrote and lemon-pucker. I mean that nothing in the structure of C seemed to scream at me like second gear on the highway when I wasn't doing the Right Thing. Kludging heartily away with the basic constructs felt, throughout, like a perfectly reasonable thing to do.
With Lisp, however, I often get a prickly sense when coding that there should be a better way. Then I rummage around and, much more often than not, find the construct I should have been using all the while. You might object that this is a trivial anthropic-principle phenomenon: in one's initial courtship with a language, one will almost always be coding without recourse to its full functionality so it should come as no surprise that one is Doing it Wrong. All true, yet I've never before felt such a compulsion from the language itself to work out the more recondite features in order to solve problems.
One might locate that difference in the fact that, in Lisp, the more "recondite" features are so much more powerful, usually much closer to the core of the language, and therefore less justifiably thought "recondite" in the first place. I'm sure that in C, for example, if one had fiery passion and Godlike clarity about the relationship between compiler and the physical state of the machine, it would be possible to write things that resembled higher-order functions. (I mean "possible" in the sense that the C-T thesis stipulates.) But few are so disposed, and as it's been pointed out many times, the easiest way to do such a thing would be to re-implement a Lisp interpreter in C. So in C, one learns to do without. Once you've had them, though, doing without feels like self-sequestration to a mental ghetto.