[erlang-questions] Maze alternate example for Rosetta Code

[Bengt Kleberg]

Greetings,

The short story about why the Erlang program for maze generation looks 
like it does:
Historical reasons.

The long story:
I found Rosetta Code when I started to learn Python. After reading what 
I came there for I stayed, looking at tasks done in Erlang. They where 
very few.
Lots of the missing Erlang tasks could be done directly with a function 
in the standard library. So I added those. Then there where some who 
could be done easily with the standard library and a little glue. So I 
added those.
I found a table, sorted after which languages that had the most tasks 
done. Erlang was very low. I decided to add Erlang tasks until the table 
looked better.
At one time I did some backtracking tasks. That is not something that I 
have ever done during 30 years of professional programming. It was 
difficult.
Then came the maze solving task. To me it seemed much more natural to 
use parallel processes, instead of backtracking, to solve a maze. 
Directly after maze solving I did the maze generation. Having just used 
processes, I did it again. No example was very large so I did not notice 
the limitations.


bengt

On 02/14/2016 12:24 AM, ok@REDACTED wrote:
> For my own purposes, I have completed about 624 of the 780 Rosetta Code
> problems.  One issue with the Rosetta Code examples is that different
> authors have 'optimised' different things for different problems: brevity,
> clarity, speed, memory, minimised library use, maximised library use,...
> and there is no standard way for the authors to *tell* you what they were
> up to.  From personal experience, sometimes a solution's author is just
> trying to get *something* done quickly and is actively ignoring every
> other consideration.  You'll note that quite a lot of solutions are
> translations from other solutions: this is often a sign that the author
> was fed up and now wasn't even *trying* to produce idiomatic or efficient
> code.
>
> Sometimes the criteria are genuinely in conflict.  Let's take a
> simple example: left factorial.
>    0 to: n-1 detectSum: [:k | k factorial]
> is a direct and idiomatic transcription of the requirements.
>    n = 0 ifTrue: [0] ifFalse: [|x|
>      x := 1.
>      n-1 to: 1 by: -1 do: [:k | x := x*k+1].
>      x]
> is much less direct, but over the range of numbers considered in the
> problem it is an order of magnitude faster.
>
> What I'm saying is, don't be too quick to assume that the author of
> the existing Maze solution in Erlang didn't *know* about this or
> that feature of Erlang; maybe s/he was trying to produce something
> that could be understood by someone with a fairly basic knowledge
> of Erlang.  (Rosetta Code *is* a 'chrestomathy' meaning that the
> solutions shouldn't be *too* esoteric.)
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions