On Tue, Jan 01, 2013 at 04:57:05PM -0700, Marcus G. Daniels wrote: > On 1/1/13 3:18 PM, Ondřej Bílka wrote: > >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.
A better example is that you have c code where at several places is code for inserting element into sorted array and using that array. What should you do. CS course taugth us to use red-black tree there. Right? Well not exactly. When one looks how is this code used it discovers that first occurence is shortest path problem so radix heap is appropriate. Second does not use ordering so hash table is more appropriate. Third periodicaly generates webpage from sorted data so keeping new data in separate buffer and calling sort from generating routine looks best. Finally fourth, original contains a comment: /* Used to find closest value to given value. Profiling shown this accounted to 13% of time. As updates are rare (not changed in previous year) using more sophisticated structures than binary search is counterproductive.*/ > Hmm, yeah. I've done that, but I've also recognized it and undone > it, or added parameters to types and/or reworked the combinators to > deal with both treatments. That one is even looking for combinators > seems to me to show that the Haskell programmer is inclined to > resist functional fixedness... That depends. Combinators also make you think into terms of combinators. You will get same problem. In general important point here is to have basis a set of primitives that are quite unlikely to get split into parts. But then you can also reinvent forth. > > Marcus > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc -- Just type 'mv * /dev/null'. _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
