On Tue, Jan 01, 2013 at 09:12:07PM +0100, Loup Vaillant-David wrote:
> On Mon, Dec 31, 2012 at 04:36:09PM -0700, Marcus G. Daniels wrote:
> > On 12/31/12 2:58 PM, Paul D. Fernhout wrote:
> > 2. The programmer has a belief or preference that the code is easier
> > to work with if it isn't abstracted. […]
This depends lot on context. On one end you have pile copypasted of visual 
basic code that could be easily refactored into tenth of its size.
On opposite end of spectrum you have piece of haskell code where
everything is abstracted and each abstraction is wrong in some way or
another. 

Main reason of later is functional fixedness. A haskell programmer will see a
structure as a monad but then does not see more apropriate abstractions.

This is mainly problematic when there are portions of code that are very
similar but only by chance and each requires different treatment. You
merge them into one function and after some time this function ends with
ten parameters.

> 
> I have evidence for this poisonous belief.  Here is some production
> C++ code I saw:
> 
>   if (condition1)
>   {
>     if (condition2)
>     {
>       // some code
>     }
>   }
> 
> instead of
> 
>   if (condition1 &&
>       condition2)
>   {
>     // some code
>   }
> 
> -----
> 
>   void latin1_to_utf8(std::string & s);
> 
Let me guess. They do it to save cycles caused by allocation of new
string.
> instead of
> 
>   std::string utf8_of_latin1(std::string s)
> or
>   std::string utf8_of_latin1(const std::string & s)
> 
> -----
> 
> (this one is more controversial)
> 
>   Foo foo;
>   if (condition)
>     foo = bar;
>   else
>     foo = baz;
> 
> instead of
> 
>   Foo foo = condition
>           ? bar
>           : baz;
> 
> I think the root cause of those three examples can be called "step by
> step thinking".  Some people just can't deal with abstractions at all,
> not even functions.  They can only make procedures, which do their
> thing step by step, and rely on global state.  (Yes, global state,
> though they do have the courtesy to fool themselves by putting it in a
> long lived object instead of the toplevel.)  The result is effectively
> a monster of mostly linear code, which is cut at obvious boundaries
> whenever `main()` becomes too long ("too long" generally being a
> couple hundred lines.  Each line of such code _is_ highly legible,
> I'll give them that.  The whole however would frighten even Cthulhu.
> 
> Loup.
> _______________________________________________
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc

-- 

The electricity substation in the car park blew up.
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Reply via email to