<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 19, 2015 at 3:53 PM, Imants Cekusins <span dir="ltr"><<a href="mailto:imantc@gmail.com" target="_blank">imantc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3xi" class="a3s" style="overflow:hidden">I tried writing in the traditional way. It took me too long. In<br>
waterfall style, this could work for me. But I do not work in<br>
waterfall style. Very, very agile - slow agile, so far.</div></blockquote></div><br>The balance between ease of writing and subtle errors in the program is harsh and rough. You can write the program faster, but also risk introducing more bugs. What do you choose?</div><div class="gmail_extra"><br></div><div class="gmail_extra">In general, if you can split computation from effect, then do so. Refactoring is easier in such a program and it only commits to a choice as late as possible, when it commits to the effects.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Threading state around and keeping track of small updates all the time doesn't split the computation and effect and as such it is pretty bad functional style. It is also hard to refactor. You need pure functions to ease quick development and testing without having to worry about state updates and such.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Some planning helps: keep the parameter order consistent in your code. Inverting the data flow is often useful. FP is data-flow oriented programming, so you need to spend time on it. Imperative code is control-flow oriented, so you can't adapt the flow from a typical imperative style.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Experience helps too. Some times, threading state is unavoidable and it really is the best way to describe the function. Other times, another flow is better.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Another axis: implicit state all have the same problem, be it Haskell State monads, process dictionaries, 'a ref cells in ML, global variables, or an object field in Java. They hide information for the reader of the code and relies on them figuring out implicit variable relationship on their own. You can perhaps write the code faster, but the next reader is hampered by the implicit passing of state. Which introduces bugs.</div><div class="gmail_extra"> <br>If you could pick between fast and wrong agile and slow and correct agile, what do you choose?<br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>