[erlang-questions] Feedback for my first non-trivial Erlang program

[Paul Wolf]

Hi guys,

sorry for my late answer. I am very thankful for you engagement and
your answers, especially craig. I planned on working through them
properly before giving an answer, but I felt that this might take some
time and I don't want to withhold my response for so long.

Some things I want to emphasize:
- I understood from the beginning what (in theory) the problem with my
program was. I intentionally (and I hope that was clear from the
beginning) didn't try to solve it, because I feared that I solve those
thing the wrong and not idiomatic way (because of the lack of my
Erlang experience). I take that you're suggestions are the way to go.
- The main issues I anticipated were (as correctly identified by you as well):
(a) problematic tail recursion and
(b) log(k^n) runtime (b) for n>working units. Also the memory I think
would be bad, because k^n lists are build, if i am not mistaken.
(c) You mentioned something about refactoring. I am not 100% sure that
this is viable in terms of readability and performance. The fact that
remove/3 isn't used rather makes me think, that I have a bug somewhere
in the logic.
(d) The thing with counting down instead of up, I havent properly
understood yet, but I will have a proper look into that.
- Please excuse, that I didn't have the time to work through your
great answers yet in all detail
- This was primarily a learning excercise for me. I could have
programmed the same thing in Java in linear runtime, probably with a
similiar effort. As it seems, there is quite a lot to learn for me ;)
- Regarding (b): You suggested to cache results. This would be exactly
my approach, but as I stated before, I was worried, this is not the
right thing to do in a functional language: I was hoping/expecting
Erlang to might cache the results itself. My reasoning here is (more
abstract in terms of functional languages general and not Erlang in
specific) that functions are side effect free and two function calls
with the same parameter always returns the same result. Therefore I
sensed a possibility for optimisation Erlang doesn't seem to do. Do
you know how other functional languages behave in this regard?
- Regarding the macro/functions constant flavours: This is a
discussion you can have in many languages I guess and I don't feel to
interested in it. What sparked my interest however are the benchmarks
by Technion. Function performance might be "good enough", but I was
suprised, that the Erlang compiler has a real difference in runtime. I
was thinking, that my very simple constant functions would be the most
trivial thing to optimize away for the compiler. I have the overall
impression by now that the Erlang compiler optimisations are not very
strong. Can you support/oppose that impression? Also regarding the
same topic: I understand, that functions in guards are not allowed,
because they might have side-effects. But I also understand, that the
compiler (in theory) could check wether a function has sideeffects or
not?

Thank you again for all you're great answers so far. To be honest, I
was kind of suprised/overwhelmed by quality and quantity ;)


2015-12-17 3:19 GMT+01:00 Richard A. O'Keefe <ok@REDACTED>:
> On the subject of macros vs functions for constants,
> there is a third way.
> (There should be a fourth way.  Abstract patterns can
> do *so* many nice things...)
> For a constant that you don't want to use in a pattern
> or guard, you can declare a function and then tell the
> compiler to -inline it.
>
> My advice would be:
>  - If you want to name something that must appear
>    in a pattern or guard, you have no choice but to
>    use a macro.  (Until abstract patterns are
>    implemented.)
>  - Otherwise, always start by using plain functions.
>    Get the code working, then benchmark and profile it.
>    + If performance of these functions is OK, stop worrying.
>    + Try inlining and benchmark+profile again.
>  +++ It's generally better to try eliminating a calculation
>      than to micro-optimise it.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions