[erlang-questions] Process scope variable
Jesper Louis Andersen
jesper.louis.andersen@REDACTED
Thu Feb 19 16:06:07 CET 2015
On Thu, Feb 19, 2015 at 3:53 PM, Imants Cekusins <imantc@REDACTED> wrote:
> I tried writing in the traditional way. It took me too long. In
> waterfall style, this could work for me. But I do not work in
> waterfall style. Very, very agile - slow agile, so far.
>
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?
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.
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.
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.
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.
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.
If you could pick between fast and wrong agile and slow and correct agile,
what do you choose?
--
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150219/2aa6dcbf/attachment.htm>
More information about the erlang-questions
mailing list