Y Combinator is not simply recursion, and a function that creates other functions isn't necessarily recursive anyway. He should have called it Factory Pattern.
Paul Graham isn't a Java hacker, and isn't a fan of complex OO design patterns. Naming it Factory Pattern would therefore be unlikely to appeal to him.
Just a small remark: Factory pattern is anything but complex. Y combinator actually seems much more complex to me (though, I'm not proficient in functional programming, so that might be why I find it complicated).
Thanks for posting that ... I'm happy to see I'm not the only one who eschews OOP and sticks to plain old routines. I've been programming for over 30 years, and I went through an OOP phase, but I got over it.
Do you really stick to plain old routines? If you have a data structure, and a module full of functions that manipulate it, that is an object. Just with a polluted global namespace and extra typing.
You don't even need the data structure since you can simulate that with functions too in order to make a basic object system. Consider a simple example like this:
Plenty of people have said data structures are a poor mans functions. I think it's in that famous list of programmer quotes collected by alan perlis that everyone inevitably comes across at some point.
In many cases where you want object orientation something like this will be sufficient. No need to go the whole way with inheritance and whatnot.
You know, even when I did use OOP, I avoided inheritance altogether and stuck with containment instead. The semantics seemed clearer to me, and I later read some essays from excellent programmers who shared my sentiments.
Nice trick with your little module-in-a-box there. I think it's roughly analogous to the technique I used in my "handy_module" example here: http://news.ycombinator.com/item?id=2580717 .
That's right, we are both using the same technique.
It's interesting to note though that the difference between this and a data structure is not that great. I haven't looked into it but I'm certain I've read somewhere that data structures as implemented in racket (which is what my example is written in) actually desugar into something like my example code.
I still like to use this technique here and there, especially when there will only be one copy of the structure in use in my program. This is because it's simply more convenient to write something like (counter++) rather than declaring a global COUNTER and typing in (set! COUNTER (add1 COUNTER)) etc.
Thanks for asking. Yeah, I actually do. Certainly when I'm programming in C, I use plain old routines, 'cause that's all I got.
But recently I even "de-objectified" a body of Perl code I wrote (a standalone server called "loom" https://loom.cc/source).
I systematically refactored it to get rid of all $object->function constructs. I ended up with a flat name space with names like trans_get, trans_put, span_encrypt, diceware_passphrase, file_update, dttm_as_cookie, api_grid_move, valid_id, trimblanks, token_get, etc. etc.
I even have a little script in there called "show_subs" which lists all the routine names in alphabetical order. There are 410 of them.
You might call that a "polluted" name space, but to me it smells like clarity. I can now look at any snippet of code completely out of context and know exactly what it does.
You might say that the downside is that each piece of code is not "configurable", meaning that it can't operate on different types of things depending on context. If and when that ever became necessary, I could easily manage it. But I never found it to be necessary.
By the way, this discussion reminds me of this article posted earlier: http://erlang.org/pipermail/erlang-questions/2011-May/058769... . I look at the list of functions he exports there and I think yeah, I bet I could use those in a heartbeat without a second thought.