8 ms·

FP is becoming the new OOP. People who don't understand its original meaning are misinterpreting it and incorrectly expounding its usefulness. Newcomers are not

by tumult 15y ago

FP is becoming the new OOP. People who don't understand its original meaning are misinterpreting it and incorrectly expounding its usefulness. Newcomers are not grasping how it fits into the bigger picture. Be cautious.

dustingetz 15y ago
Care to elaborate?
- tumult 15y ago
  The title of this article, for example. The idea of this article is that functional programming is hard, because it forces you to think in a new way. But here, calling functional programming hard is just used to pat oneself on the back. Great, this article says you can map a function over a collection and then sum it. You don't need to think of yourself as some elite programmer that casts a shadow over procedural programmers. It's not true. Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas. It's not necessarily about map/reduce, monads, or whatever. Encode your ideas mostly as functions where possible. That's it. It's bad to say that functional programming is hard on purpose, or that it makes you a part of some elite cadre. Functional programming should be, and usually is, no harder than any other way to explicitly write down your ideas. The whole point is to make it more simple to express your ideas in a way that can be evaluated by a computer. Functional programming isn't hard. Programming is hard.
  - tptacek 15y ago
    I'm not expert enough to call you out on this, but isn't "function", the way it's used in "functional programming", working from a different and more strict definition of the word "function" that (say) a C programmer is used to? I don't know that you're wrong about this summary of FP, but it doesn't smell right to me.
    - tumult 15y ago
      It depends. A C function is actually a procedure: a list of statements that have some effect on the computer, and then (maybe) shove some return value through the stack at the end. A function in languages like Clean or Haskell or Clojure or Agda or Coq can only return values, and have no effect on the machine (like mutating memory). Of course, this construct is used only as a way to express ideas. The notion of a function that has no other effect on the machine is actually a lie. The time it takes to evaluate the function is a real effect. So is the memory it uses. It's not a perfect abstraction (none are) but for many types of problems, pure functions can work as a tool to help a programmer. Sorry, typed this on a phone, hard to edit.
    - profquail 15y ago
      That's about right. A "function" in functional programming is supposed to be just like the functions you remember from grade-school algebra class, e.g., f(x) = 2x + 5 If you look at that function, you'll notice that for any given value of 'x', the function always produces the same output value. For example, no matter how many times you try it, plugging in 3 for 'x' always returns 11. This means that f(x) is a "pure" function. The only difference between the trivial example with f(x) above, and say, Haskell, is that the functions you're working with in Haskell are much more complicated. Boil it down though, and they're still pure, mathematical functions nonetheless. Now, you can (should?) write purely functional programs in C if you follow the same principals. The main difference is that C doesn't force you do write your code this way, and since writing purely functional code can be a bit tedious, most people don't. This leads to impure functions in your code, like when you read a file from disk -- if the file is there, the function does one thing; if not, it may do something else (like crash). Since the output of an impure function can vary depending on when/where/why/how it's executed, it can be much harder to find bugs in it, since the code may compile and run just fine until the moment it doesn't. Anyway, that's the basic rundown on FP. I'm not an FP expert, so if I've missed anything, someone please correct me.
    - deleted 15y ago
      [deleted]
    - thurn 15y ago
      I agree. Minimizing state and side effects are at least as core to functional programming as "you should use lots of functions."
  - Spyro7 15y ago
    "Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas." Umm, no, that is not what functional programming is. Functional programming is, basically, programming without side-effects. A purely functional language will have variables that are completely immutable. This is a bit of a shift away from the way things are done in C or C++. Speaking just for myself, I started into the programming world with Java (not counting QBasic), and I am finding it incredibly hard to wrap my brain around the idea of functional programming. My understanding is that most programmers that have a background primarily working with non-functional languages have a challenging time initially grasping the concepts of functional programming. However, I would guess that a programmer that learns a functional programming style early on would probably have very little difficulty understanding non-functional constructs. For more information, I would like to point you towards some easy reading: * http://en.wikipedia.org/wiki/Side_effect_(computer_science) http://en.wikipedia.org/wiki/Side_effect_(computer_science) * http://learnyouahaskell.com/introduction#so-whats-haskell http://learnyouahaskell.com/introduction#so-whats-haskell Edit: To whoever down-voted me, I would appreciate some explanation of your views. The fact is that functional programming is not just using functions. The article plainly refers to functional programming languages and not simply using functions. There is a difference.
    - Cushman 15y ago
      I don't ninja downvote, but if I had to guess I'd say it's because if you're finding functional programming incredibly difficult, you maybe shouldn't be lecturing on what it is. As my cousin points out, it's true that it's easy to think of functions as just being macros in a language like C. If you call a function which doesn't have a return value, and which modifies some global state, that's not a "real" function, just a stored procedure. However, if you write a C function which doesn't modify global state, but simply takes an input and returns an output, as even novice programmers do all the time, hey presto— that's the functional paradigm! There's nothing mystical about it, and what the GP is saying is that telling people who have done this that functional programming is something different is fundamentally confusing.
      - Spyro7 15y ago
  - jodoherty 15y ago
    Like you said, functional programming isn't hard, but I think the problem is that learning a completely new language with an unfamiliar syntax and abstractions is hard, and trying to apply functional programming techniques in most current mainstream languages is equally hard. The fundamental language feature that makes true functional programming possible is first class functions, since that allows higher order functions and anonymous functions. The lack of that feature in most mainstream languages is why functional programming feels so foreign to most programmers. Sure, you can write functions without side effects, but making good use of them without polluting your namespace, explicitly passing around function pointers, or having lots of extra boilerplate code lying around is difficult in a lot of languages. That's constantly changing though. I think as more languages start adding support for higher order functions, even established languages like C++ and Java, we'll see more and more people using a functional style and less nonsense discussion about how "hard" it is, because it really isn't hard at all. Already, you see bits and pieces of functional Javascript code littered all over the Internet on a regular basis. In fact, I'm willing to bet that at some point in the future, functional programming techniques be considered easier and more natural than a purely imperative approach, simply because more programmers will have encountered it sooner in their programming careers and made effective use of it. It'll be an everyday occurrence to meet a programmer who uses anonymous functions for callbacks and commonly makes use of fold, reduce, and map instead of explicit loops and state variables. Meanwhile, meeting someone who knows what a pointer is or even how to manage heap memory will be a one in twenty event, and chances are that person will be an embedded developer who also knows how to write interrupt handlers and even a custom, deterministic memory allocator for real time applications.
dustingetz 15y ago
You know, I've learned something today! When some people talk about functional programming, they talk about monads and iterating with recursion and lambda calculus. Other people talking about functional programming mean using data-oriented abstractions, where functions operate on data in well-defined ways, to avoid state and interlocked dependencies[3]. I've been calling the latter a "functional style", but clearly there is ambiguity and people get turned off and say things like "we're using an OO language why would i want FP" in Avdi Grimm's talk "Confident Code"[2] he calls this style "narrative structure", compared to "haphazard structure"[4]. I like that; "functional" envokes all sorts of emotion about being hard to understand and unnecessary. "Narrative" or "confident" or "data-oriented" are more articulate, and don't evoke flame wars. Avdi's example (code screenshot) is the most articulate example of this I've yet seen. https://lh4.googleusercontent.com/-Cs-muD17ato/Tk6b1Rb9MwI/AAAAAAAAAeY/MTDO67H4r1c/s912/narrative-code-avdi-grimm.png https://lh4.googleusercontent.com/-Cs-muD17ato/Tk6b1Rb9MwI/A... And it's in ruby. Nothing hard here, but it meets a functional style per John D Cook's definition[1]: "OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts." "functional in the small and OO in the large" seems a good path. The Scala community seems to get this, and seems to me Scala is mainstreaming much quicker than any of the pure functional languages. [1] http://www.johndcook.com/blog/2010/11/03/object-oriented-vs-functional-programming/ http://www.johndcook.com/blog/2010/11/03/object-oriented-vs-... [2] http://avdi.org/talks/confident-code-2010-01-12/confident-code.html http://avdi.org/talks/confident-code-2010-01-12/confident-co... [3] http://www.dustingetz.com/how-to-become-an-expert-swegr http://www.dustingetz.com/how-to-become-an-expert-swegr [4] http://www.dustingetz.com/confident-code-vs-timid-code http://www.dustingetz.com/confident-code-vs-timid-code
- SoftwareMaven 15y ago
  functional in the small and OO in the large" seems a good path. That's what I like about Erlang as well. Once you recognize processes as your objects, this philosophy just flows out of the language.
  - deleted 15y ago
    [deleted]
joe_the_user 15y ago
I think you miss difference between OO and FP. It is paradoxical. Fifteen years ago, OO was this giant, over-sold piece of junk that was going to magically make random code piece. But, but it does/did have merits for ginormous software operations employing many, many mediocre programmers. It contains a simple metaphor and simple device for turning totally bad code into slightly less bad code, for allowing completely unrelated stuff to relate together in a half-assed way. OO isn't about giving programmers more power but allowing the power one programmer to interface with that of another (even perhaps another inferior programmer). FP is about power. You could anhilate whole galaxies with the power of a third order functional if your mind was strong enough to wrap itself around such a thing - from another link currently up: "Lisp's purpose in the programming language galaxy is to assist our most gifted fellow humans in thinking previously impossible thoughts, remember?" Essentially, neither Lisp nor FP nor Logic Programming exist to collect the multitude of junk that enterprises have and make it more sensible. ==> I am speaking "jocularly" here. I actually think collecting the junk of enterprises is a worthy activity. Large scale programming in a typical enterprise (not Google) requires you to make allowances for a multitude of human foibles and this can expand you as a human being and not just a genius. Just consider, there are geniuses who just produce "amazing stuff" for others to run after trying to understand, there are geniuses who explain to other geniuses and there are geniuses who explain to normal people. All have their place.
- dustingetz 15y ago
  "OOP ... contains a simple metaphor and simple device for turning totally bad code into slightly less bad code, for allowing completely unrelated stuff to relate together in a half-assed way." haha, nice. i don't think it's quite that cynical, hybrid OOP/FP languages like Scala seem to have a better industry record than pure functional languages, at least for the internet companies we hear all about. OO isn't inherently bad, and FP isn't inherently good, but knowing how to think in FP will certainly make us better engineers, and the "functional in the small, object-oriented in the large" seems to be gaining acceptance in elite circles.
  - thesz 15y ago
    Just for record. Type system for OOP was developed during some 25 years: http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%20Simula%20User%20%28ECOOP%20Prize%29.pdf http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%... Lambda calculus was introduced in 1936 and in 1948 it was given simple type system (along Fortran one, which, in turn, was introduced in 1958, ten years later). Year after Simula-67 was introduced, logician Hindley presented a polymorphic type system with type inference for lambda-calculus, which was later rediscovered by Milner and incorporated into ML in 1978. Simula-67 didn't have proper parametric polymorphism. I know no such examples before ML. Functional programming is based on logic and could be a basis for logic on its own. Consider Type Theory by Per Martin-Loef. Or even simpler extension of polymorphic type system fo lambda calculus: Haskell's type classes, where type represents theorem, and function text serves as a proof. OOP, on other hand, does not represent some simple kind of logic. I emphasize simple, because Luca Cardelli finally found some logic out there. So I think that OOP is inherently less useful that FP.
dramaticus3 15y ago
http://harmful.cat-v.org/software/OO_programming/ http://harmful.cat-v.org/software/OO_programming/ e.g. "The phrase "object-oriented" means a lot of things. Half are obvious, and the other half are mistakes." -- Paul Graham
- richcollins 15y ago
  I don't think pg really understands OO. He seems to associate it with boilerplate getters and setters ala Java. This is the best description that I've found: OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things - Alan Kay
  - dramaticus3 15y ago
    Quote fight "object-oriented design is the roman numerals of computing." -- Rob Pike And Rob shared an office with Bjarne for quite a while.
    - anon1385 15y ago
      OO advocates don't generally consider C++ to be a particularly OO language, so I don't see what Bjarne has to do with anything, you are just reinforcing the original point: critics of OOP are often criticising things that have little at all to do with the original ideas of OOP.
  - discreteevent 15y ago
    William Cook's response to Paul Graham's explanation for why Arc isn't especially object-oriented: http://wcook.blogspot.com/2011/04/paul-graham-on-objects-in-arc.html http://wcook.blogspot.com/2011/04/paul-graham-on-objects-in-...

by tumult 15y ago

dustingetz 15y ago

Care to elaborate?

tumult 15y ago
The title of this article, for example. The idea of this article is that functional programming is hard, because it forces you to think in a new way. But here, calling functional programming hard is just used to pat oneself on the back. Great, this article says you can map a function over a collection and then sum it. You don't need to think of yourself as some elite programmer that casts a shadow over procedural programmers. It's not true. Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas. It's not necessarily about map/reduce, monads, or whatever. Encode your ideas mostly as functions where possible. That's it. It's bad to say that functional programming is hard on purpose, or that it makes you a part of some elite cadre. Functional programming should be, and usually is, no harder than any other way to explicitly write down your ideas. The whole point is to make it more simple to express your ideas in a way that can be evaluated by a computer. Functional programming isn't hard. Programming is hard.
- tptacek 15y ago
  I'm not expert enough to call you out on this, but isn't "function", the way it's used in "functional programming", working from a different and more strict definition of the word "function" that (say) a C programmer is used to? I don't know that you're wrong about this summary of FP, but it doesn't smell right to me.
  - tumult 15y ago
    It depends. A C function is actually a procedure: a list of statements that have some effect on the computer, and then (maybe) shove some return value through the stack at the end. A function in languages like Clean or Haskell or Clojure or Agda or Coq can only return values, and have no effect on the machine (like mutating memory). Of course, this construct is used only as a way to express ideas. The notion of a function that has no other effect on the machine is actually a lie. The time it takes to evaluate the function is a real effect. So is the memory it uses. It's not a perfect abstraction (none are) but for many types of problems, pure functions can work as a tool to help a programmer. Sorry, typed this on a phone, hard to edit.
  - profquail 15y ago
    That's about right. A "function" in functional programming is supposed to be just like the functions you remember from grade-school algebra class, e.g., f(x) = 2x + 5 If you look at that function, you'll notice that for any given value of 'x', the function always produces the same output value. For example, no matter how many times you try it, plugging in 3 for 'x' always returns 11. This means that f(x) is a "pure" function. The only difference between the trivial example with f(x) above, and say, Haskell, is that the functions you're working with in Haskell are much more complicated. Boil it down though, and they're still pure, mathematical functions nonetheless. Now, you can (should?) write purely functional programs in C if you follow the same principals. The main difference is that C doesn't force you do write your code this way, and since writing purely functional code can be a bit tedious, most people don't. This leads to impure functions in your code, like when you read a file from disk -- if the file is there, the function does one thing; if not, it may do something else (like crash). Since the output of an impure function can vary depending on when/where/why/how it's executed, it can be much harder to find bugs in it, since the code may compile and run just fine until the moment it doesn't. Anyway, that's the basic rundown on FP. I'm not an FP expert, so if I've missed anything, someone please correct me.
  - deleted 15y ago
    [deleted]
  - thurn 15y ago
    I agree. Minimizing state and side effects are at least as core to functional programming as "you should use lots of functions."
- Spyro7 15y ago
  "Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas." Umm, no, that is not what functional programming is. Functional programming is, basically, programming without side-effects. A purely functional language will have variables that are completely immutable. This is a bit of a shift away from the way things are done in C or C++. Speaking just for myself, I started into the programming world with Java (not counting QBasic), and I am finding it incredibly hard to wrap my brain around the idea of functional programming. My understanding is that most programmers that have a background primarily working with non-functional languages have a challenging time initially grasping the concepts of functional programming. However, I would guess that a programmer that learns a functional programming style early on would probably have very little difficulty understanding non-functional constructs. For more information, I would like to point you towards some easy reading: * http://en.wikipedia.org/wiki/Side_effect_(computer_science) http://en.wikipedia.org/wiki/Side_effect_(computer_science) * http://learnyouahaskell.com/introduction#so-whats-haskell http://learnyouahaskell.com/introduction#so-whats-haskell Edit: To whoever down-voted me, I would appreciate some explanation of your views. The fact is that functional programming is not just using functions. The article plainly refers to functional programming languages and not simply using functions. There is a difference.
  - Cushman 15y ago
    I don't ninja downvote, but if I had to guess I'd say it's because if you're finding functional programming incredibly difficult, you maybe shouldn't be lecturing on what it is. As my cousin points out, it's true that it's easy to think of functions as just being macros in a language like C. If you call a function which doesn't have a return value, and which modifies some global state, that's not a "real" function, just a stored procedure. However, if you write a C function which doesn't modify global state, but simply takes an input and returns an output, as even novice programmers do all the time, hey presto— that's the functional paradigm! There's nothing mystical about it, and what the GP is saying is that telling people who have done this that functional programming is something different is fundamentally confusing.
    - Spyro7 15y ago
- jodoherty 15y ago
  Like you said, functional programming isn't hard, but I think the problem is that learning a completely new language with an unfamiliar syntax and abstractions is hard, and trying to apply functional programming techniques in most current mainstream languages is equally hard. The fundamental language feature that makes true functional programming possible is first class functions, since that allows higher order functions and anonymous functions. The lack of that feature in most mainstream languages is why functional programming feels so foreign to most programmers. Sure, you can write functions without side effects, but making good use of them without polluting your namespace, explicitly passing around function pointers, or having lots of extra boilerplate code lying around is difficult in a lot of languages. That's constantly changing though. I think as more languages start adding support for higher order functions, even established languages like C++ and Java, we'll see more and more people using a functional style and less nonsense discussion about how "hard" it is, because it really isn't hard at all. Already, you see bits and pieces of functional Javascript code littered all over the Internet on a regular basis. In fact, I'm willing to bet that at some point in the future, functional programming techniques be considered easier and more natural than a purely imperative approach, simply because more programmers will have encountered it sooner in their programming careers and made effective use of it. It'll be an everyday occurrence to meet a programmer who uses anonymous functions for callbacks and commonly makes use of fold, reduce, and map instead of explicit loops and state variables. Meanwhile, meeting someone who knows what a pointer is or even how to manage heap memory will be a one in twenty event, and chances are that person will be an embedded developer who also knows how to write interrupt handlers and even a custom, deterministic memory allocator for real time applications.

dustingetz 15y ago

You know, I've learned something today! When some people talk about functional programming, they talk about monads and iterating with recursion and lambda calculus. Other people talking about functional programming mean using data-oriented abstractions, where functions operate on data in well-defined ways, to avoid state and interlocked dependencies[3]. I've been calling the latter a "functional style", but clearly there is ambiguity and people get turned off and say things like "we're using an OO language why would i want FP" in Avdi Grimm's talk "Confident Code"[2] he calls this style "narrative structure", compared to "haphazard structure"[4]. I like that; "functional" envokes all sorts of emotion about being hard to understand and unnecessary. "Narrative" or "confident" or "data-oriented" are more articulate, and don't evoke flame wars. Avdi's example (code screenshot) is the most articulate example of this I've yet seen. https://lh4.googleusercontent.com/-Cs-muD17ato/Tk6b1Rb9MwI/AAAAAAAAAeY/MTDO67H4r1c/s912/narrative-code-avdi-grimm.png https://lh4.googleusercontent.com/-Cs-muD17ato/Tk6b1Rb9MwI/A... And it's in ruby. Nothing hard here, but it meets a functional style per John D Cook's definition[1]: "OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts." "functional in the small and OO in the large" seems a good path. The Scala community seems to get this, and seems to me Scala is mainstreaming much quicker than any of the pure functional languages. [1] http://www.johndcook.com/blog/2010/11/03/object-oriented-vs-functional-programming/ http://www.johndcook.com/blog/2010/11/03/object-oriented-vs-... [2] http://avdi.org/talks/confident-code-2010-01-12/confident-code.html http://avdi.org/talks/confident-code-2010-01-12/confident-co... [3] http://www.dustingetz.com/how-to-become-an-expert-swegr http://www.dustingetz.com/how-to-become-an-expert-swegr [4] http://www.dustingetz.com/confident-code-vs-timid-code http://www.dustingetz.com/confident-code-vs-timid-code

SoftwareMaven 15y ago
functional in the small and OO in the large" seems a good path. That's what I like about Erlang as well. Once you recognize processes as your objects, this philosophy just flows out of the language.
- deleted 15y ago
  [deleted]

joe_the_user 15y ago

I think you miss difference between OO and FP. It is paradoxical. Fifteen years ago, OO was this giant, over-sold piece of junk that was going to magically make random code piece. But, but it does/did have merits for ginormous software operations employing many, many mediocre programmers. It contains a simple metaphor and simple device for turning totally bad code into slightly less bad code, for allowing completely unrelated stuff to relate together in a half-assed way. OO isn't about giving programmers more power but allowing the power one programmer to interface with that of another (even perhaps another inferior programmer). FP is about power. You could anhilate whole galaxies with the power of a third order functional if your mind was strong enough to wrap itself around such a thing - from another link currently up: "Lisp's purpose in the programming language galaxy is to assist our most gifted fellow humans in thinking previously impossible thoughts, remember?" Essentially, neither Lisp nor FP nor Logic Programming exist to collect the multitude of junk that enterprises have and make it more sensible. ==> I am speaking "jocularly" here. I actually think collecting the junk of enterprises is a worthy activity. Large scale programming in a typical enterprise (not Google) requires you to make allowances for a multitude of human foibles and this can expand you as a human being and not just a genius. Just consider, there are geniuses who just produce "amazing stuff" for others to run after trying to understand, there are geniuses who explain to other geniuses and there are geniuses who explain to normal people. All have their place.

dustingetz 15y ago
"OOP ... contains a simple metaphor and simple device for turning totally bad code into slightly less bad code, for allowing completely unrelated stuff to relate together in a half-assed way." haha, nice. i don't think it's quite that cynical, hybrid OOP/FP languages like Scala seem to have a better industry record than pure functional languages, at least for the internet companies we hear all about. OO isn't inherently bad, and FP isn't inherently good, but knowing how to think in FP will certainly make us better engineers, and the "functional in the small, object-oriented in the large" seems to be gaining acceptance in elite circles.
- thesz 15y ago
  Just for record. Type system for OOP was developed during some 25 years: http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%20Simula%20User%20%28ECOOP%20Prize%29.pdf http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%... Lambda calculus was introduced in 1936 and in 1948 it was given simple type system (along Fortran one, which, in turn, was introduced in 1958, ten years later). Year after Simula-67 was introduced, logician Hindley presented a polymorphic type system with type inference for lambda-calculus, which was later rediscovered by Milner and incorporated into ML in 1978. Simula-67 didn't have proper parametric polymorphism. I know no such examples before ML. Functional programming is based on logic and could be a basis for logic on its own. Consider Type Theory by Per Martin-Loef. Or even simpler extension of polymorphic type system fo lambda calculus: Haskell's type classes, where type represents theorem, and function text serves as a proof. OOP, on other hand, does not represent some simple kind of logic. I emphasize simple, because Luca Cardelli finally found some logic out there. So I think that OOP is inherently less useful that FP.

dramaticus3 15y ago

http://harmful.cat-v.org/software/OO_programming/ http://harmful.cat-v.org/software/OO_programming/ e.g. "The phrase "object-oriented" means a lot of things. Half are obvious, and the other half are mistakes." -- Paul Graham

richcollins 15y ago
I don't think pg really understands OO. He seems to associate it with boilerplate getters and setters ala Java. This is the best description that I've found: OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things - Alan Kay
- dramaticus3 15y ago
  Quote fight "object-oriented design is the roman numerals of computing." -- Rob Pike And Rob shared an office with Bjarne for quite a while.
  - anon1385 15y ago
    OO advocates don't generally consider C++ to be a particularly OO language, so I don't see what Bjarne has to do with anything, you are just reinforcing the original point: critics of OOP are often criticising things that have little at all to do with the original ideas of OOP.
- discreteevent 15y ago
  William Cook's response to Paul Graham's explanation for why Arc isn't especially object-oriented: http://wcook.blogspot.com/2011/04/paul-graham-on-objects-in-arc.html http://wcook.blogspot.com/2011/04/paul-graham-on-objects-in-...