Grammar
LightBulbJoke := question answer;
question := "How many " ROLE "s do you need to change a light bulb?";
answer := NUMBER "." explanation;
explanation := (FUNNYCLICHÉ)+;

-----------------------

Example

Set
ROLE := "programmer"
NUMBER := "None"
FUNNYCLICHÉ := "It's a hardware problem."

giving
How many programmers do you need to change a light bulb? None. It's a hardware problem.

Now, maybe someone can come up with a 'perl' representation...

Here are a couple I had not heard before ...

How many people does it take to change an object-oriented light bulb?
Change it? Aw shucks, I was going to reuse it.

How many Lisp programmers does it take to change a light bulb?
Hmmm, I'm not sure, better find out....
Hmmm, I'm not sure, better find out....
Notes: LISP is a recursive programming language. One problem LISP programmers have to contend with is infinite recursion. (cf computer dictionary entry: recursion - see recursion) These lisp heads are usually research AI types and their standard answer is as in the punchline. It could be improved:
(((H)mmm,) (I'm ((not) sure, better))) (find (out))...

How many Object-Oriented Programmers does it take to change a lightbulb?

You shouldn't be changing the light bulb by hand. If you'd used Electric::Light instead of reinventing the wheel, the Electric::Light::Socket would have noticed the need for a new Electric::Light::Bulb object and instantiated it automatically. By rolling your own implementation, you're likely to get all kinds of edge cases wrong. Can your hand-rolled lightbulb-changing code correctly handle 240V 50Hz current and install the correct sized bulb for the room in question? What about 120V and 60Hz? What if the building's electrical system uses unicode? What if this is an embedded lightbulb running on a small flashlight system? Electric::Light handles all of these details correctly for you. By trying to do this stuff yourself, you're going to repeat every bug that's been ironed out of that module over the years. Will your hand-rolled implementation be tested by millions of people worldwide on dozens of platforms, from LED-based indicator lights all the way up to redundant arrays of airport beacons? No. Use Electric::Light or die.

And then you go to change a lightbulb of a high intensity discharge light, and find that Electric::Light does not support edison screw bulbs - only bayonet. So, you get involved and add support for Edison screw bulbs, including mini-sized, and complete the support, adding mini bayonet fittings. This was easy enough, and you contribute the code back. The patch is not accepted because the original author did not like your suggestion that the code wouldn't work on all light bulb fittings, and when he finally went to the effort of buying an "obscure" light fitting from a "specialist" store, the first case he tried it on - mini bayonet - didn't work due to a typo. You decide to use your modified version and forget the original author.

However, as you use the derived module more and more for a wide variety of purposes, you find that you need higher powered lights, so investigate supporting High Intensity Discharge lamps. But Electric::Light is missing the abstraction layer of a ballast, so cannot automatically determine what type of light to install. The assumption that you're using a simple mains light bulb is "hard-wired" (sorry) into the program. So, you try to modify the code to add the functionality, but the implementation is a poorly considered procedural mess and you start from scratch on the OO Electric::Lamp.

Your new implementation handles all sorts of high intensity discharges correctly - and the high-end lighting community is overwhelmed with satisfaction - but support for changing standard mains bulbs is never considered, because the new code supports HPS, LPS, Metal-Halide, Fluourescant and Neon lights correctly. This is achieved through a strict OO approach, each bulb exporting its required characteristics and performance values in a sensible fashion. What was previously a mine field of matching component specs to get the right transformer, ignitor, inductor, ballast and lamp combinations is now as easy as:

  my $light = new Electric::Lamp
                 (type => "HID",
                  bulb => "HPS",
                  power => "250W");

  $light->install($fitting);
[download]

Traditional, incandescant bulbs look so pale in comparison, that someone writes a Electric::Light::Bulb::Lamp that contains a fluourescant tube in the same original API, and while it costs you an extra 400% in startup time and takes marginally longer to light up, you saved 85% of the power bill, made the part last 10 times longer and hence increased the efficiency of the system.

Critics of Electric::Lamp say "that module sucks! It can't even change a simple lightbulb without installing the Electric::Lamp::Discharge, Electric::Lamp::Ignitor, Electric::Light::Ballast, and Electric::Lamp::Fluourescant modules! I even had to install the Electric::Transformer and Electric::Inductor modules, what on earth for? Not only that, but it takes 3 seconds to start up! What a waste of space!". Of course, as he does not run the module for the 5 years to see the real benefits, he keeps happily letting Electric::Light change every bulb every 6 months.

People with experience with professional lighting come along and ask him how to light up their stadium, and they are told; "Go to Electric::Light. It's all you ever need to light your house and beyond; it supports light bulbs up to 1 million Watts, in theory!". The module doesn't do anything like the scale that they need, so they end up getting a .NET contractor in instead, and pay them 10 times what they needed to, for a solution that's barely more efficient than your average fluourescant tube.

Ah, cynicism.

The lesson is, horses for courses.

$h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/."
."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";
[download]

Q: How many Object-Oriented Programmers does it take to change a lightbulb?

A: One. Using delegation.

$Fred->come_here_a_moment($PLEASE);
$Fred->change($that_faulty_bulb, $WILL_YOU);
$Fred->thank_you($YOU_MAY_GO_NOW);
[download]

I think it makes sense. To change a lightbulb procedurally, you would do something like $lightbulb = changelightbulb($lightbulb); whereas the oo way to do it would just be $lightbulb->change()

The whole idea behind "You're still thinking procedurally" is that rationally you are thinking of how to change a lightbulb so you can figure out how many programmers it takes when really, you shouldn't care how it happens, only that there is a method (change()) that takes care of that for you.

To me, the joke is a statement on the overuse of OO. You don't need to apply object principles to something as simple as changing a light bulb.

Shouldn't it just be something along the lines of:

$socket->bulb = new Lightbulb();
$socket->bulb = new Lightbulb(); #changed;
[download]

Or something of that nature, as the lightbulb isn't changing itself really, it's being replaced. At least in the "real world".

Yep. Unless you are writing a supply chain model that connects into your maintance department and electrical cost centers, in which case you are going to need to use the MyBossHasNoClueWhatHeIsAskingFor pattern.

More OO is all well and good except you eventually reach the point where all you can think in is creating more objects. And then performance goes to absolute Hell. OO in moderation rocks, but very few folks actually understand how to get there.

I know I have aborted (for-fun) projects because of OO design issues. I wanted everything perfect. The solution for me is to not embrace perfection and mix OO where applicable with procedural coding. OO can be used with data units, but there can still be functional/imperative constructs. So far, I'm having a lot more fun.

Professors that teach OO is the only way are really damaging the minds of their students. In some cases, OO solutions are intractible, in others they are great solutions. Chosing when and where to draw the line is the key to Software Design...something 85% (fn 1) of all software architects miss.

--- fn 1. 95.8% of all statistics are made up)

To me, the joke is a statement on the overuse of OO. You don't need to apply object principles to something as simple as changing a light bulb.

Well, more of a paradoxical overuse of OO. Our OO paradigm is supposed to help us model the real world in software, not the other way around.

That joke was not funny because it is out of date. A more 'trendy' version might be:

Q: How does an OO developer go about the refactoring process for a light bulb?

A: Although the developer had specced the lightbulb as a Singleton in Rational, acceptance testing had shown that the application should in fact be obtaining instances of LightBulb from a LightBulbFactory.

- or -

A: I'm not sure, but I know of developers in Bangalore who will do it for one-sixth of the cost.

Or perhaps,

Q: How many extreme programmers does it take to change a lightbulb?

A: Two.

For a start, that's not funny.

Q:How many Cody Pendants does it take to change a lightbulb?
A:That's not funny!

Abigail

$joke->destroy();
[download]

undef $joke;
[download]

The answer is, procedurally you would do "$light_bulb = ($light_bulb + 1)" or something, rather than, in O-O, "$light_bulb->change(1)"

The original answer about the message is OO and is well done. Messages are a SmallTalk thing. Your proposed solutions are, at least to SmallTalk fans, less OO than the original punchline. The first one is essentially non OO, just disguised by the class syntax. Much that is attributed to OO is really just procedural code with method scope and instance variables (call this "half-OO"). Few actually take the plunge to where it is meant to go.