Comments on: The Pokémon Problem: a new anti-pattern http://blog.palantirtech.com/2009/03/19/the-pokemon-problem/ Articles from the Engineering Group at Palantir Technologies Tue, 24 Jan 2012 09:51:18 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: John C. http://blog.palantirtech.com/2009/03/19/the-pokemon-problem/comment-page-1/#comment-186 John C. Tue, 07 Apr 2009 01:17:49 +0000 http://blog.palantirtech.com/?p=202#comment-186 I like to use the jargon to describe holes that could be plugged by a better API. For every type system there are bugs that it will not be able to catch and we call these leaks for the most part. So leaks are already named and don't need a new name. We cannot prevent potential leaks in the future, we may only fix leaks as they happen. The pokemon problem is when you have the ability to catch all of them. We are fixing bugs that haven't yet been written. I like to think of pokemon problems as places where you could use a language provided facility to stop these bugs from ever being written again. I like to use the jargon to describe holes that could be plugged by a better API. For every type system there are bugs that it will not be able to catch and we call these leaks for the most part.

So leaks are already named and don’t need a new name. We cannot prevent potential leaks in the future, we may only fix leaks as they happen. The pokemon problem is when you have the ability to catch all of them. We are fixing bugs that haven’t yet been written.

I like to think of pokemon problems as places where you could use a language provided facility to stop these bugs from ever being written again.

]]> By: Andrew Coleson http://blog.palantirtech.com/2009/03/19/the-pokemon-problem/comment-page-1/#comment-181 Andrew Coleson Tue, 24 Mar 2009 01:35:07 +0000 http://blog.palantirtech.com/?p=202#comment-181 Let me know if I'm going down the wrong path with this, but it seems like any common "bad coding practice" would fall under this anti-pattern. In the C world, typical memory leaks seem to fall under this quite easily (leading to macro'ing things like FREE to do a null-check, free, and set-null). Similarly in the C++ world, <a href="http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization" rel="nofollow">RAII</a> was created to handle some commonly-recurring memory leak patterns. (Of course, garbage collection is the giant-hammer solution to that subset of your pokemon problem space, leading to using Java in the first place..) Let me know if I’m going down the wrong path with this, but it seems like any common “bad coding practice” would fall under this anti-pattern.

In the C world, typical memory leaks seem to fall under this quite easily (leading to macro’ing things like FREE to do a null-check, free, and set-null). Similarly in the C++ world, RAII was created to handle some commonly-recurring memory leak patterns.

(Of course, garbage collection is the giant-hammer solution to that subset of your pokemon problem space, leading to using Java in the first place..)

]]>