Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md #24

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,12 +25,12 @@ usuallyTrue =

In each of these defines _how_ to generate random values. The most interesting case is `usuallyTrue` which generates `True` 80% of the time and `False` 20% of the time!

Now look at this [working example](https://guide.elm-lang.org/effects/random.html) to see a `Generator` used in an application.
Now look at [Numbers](https://elm-lang.org/examples/numbers), [Card](https://elm-lang.org/examples/cards) and [Positions](https://elm-lang.org/examples/positions) to see three examples of a `Generator` used in an application.


## Mindset Shift

If you are coming from JavaScript, this package is usually quite surprising at first. Why not just call `Math.random()` and get random floats whenever you want? Well, all Elm functions have this “same input, same output” guarantee. That is part of what makes Elm so reliable and easy to test! But if we could generate random values anytime we want, we would have to throw that guarantee out.
If you are coming from JavaScript, this package is usually quite surprising at first. Why not just call `Math.random()` and get random floats whenever you want? Well, all Elm functions have this “same input, same output” guarantee. Having no "side effects" is what makes Elm so reliable and easy to test! But if we could generate random values anytime we want, we would have to throw that guarantee out.

So instead, we create a `Generator` and hand it to the Elm runtime system to do the dirty work of generating values. We get to keep our guarantees _and_ we get random values. Great! And once people become familiar with generators, they often report that it is _easier_ than the traditional imperative APIs for most cases. For example, jump to the docs for [`Random.map4`](Random#map4) for an example of generating random [quadtrees](https://en.wikipedia.org/wiki/Quadtree) and think about what it would look like to do that in JavaScript!

Expand Down