gampleman

module Parallel exposing
    ( Data(..), Parallel, OneOf
    , succeed, appendCmd, appendTask, append, map2
    , andThen
    , Msg, init, run, update
    , Parallel1, Parallel2, Parallel3, Parallel4, Sequential
    )

{-| Allows easily running tasks/cmd in parallel without manually needing to manage messages.

gampleman

module FunctionFuzzers exposing (func1, func2, func3)

import Bitwise
import Expect
import Fuzz exposing (Fuzzer)
import Random
import Shrink
import Test exposing (..)
import Test.Runner

gampleman

Fuzz testing ideas

Elm gets one thing amazingly right (which is unusual in most ecosystems) in that it has in its "default" testing tool built in support for property based testing¹. This is a huge step forward since it makes property testing something easily reachable for by the average engineer without needing yet another dependency and boilerplate to set it up and so on.

However, there are a number of things we could do to make fuzz testing more effective and in that way make testing more effective.

Effectivness of PBT

Footnotes

1. The one thing it gets amazingly wrong is calling it fuzz testing. Sigh. Fuzz testing is the practice of trying to find inputs that will crash your program or make it behave in unexpected ways. Fuzzers in Elm aren't even trying, for instance float fuzzers don't send in NaN or -Infinity or even -0. Int fuzzers don't send in fractional numbers maquarading as floats. String fuzzers don't send in snippets that might trigger bugs in elm-parser. ↩

gampleman

Design your own Runtime

By Jakub Hampl

The Elm Architecture is one of the great innovations Elm brought to the software industry. But one of the questions that often comes up is how to scale it up for bigger applications. In this article I want to show various ideas that allow you to enhance the Elm architecture to make developing larger applications easier.

But first, we should discuss the Runtime. Elm, as a programming language is completely pure

gampleman

module Main exposing (main)
{-| This is the demo of how this looks in a super simple blog.

This is paradoxical, since I don't really consider a blog to be the thing
you should build as a SPA, since it clearly has multiple pages.
But as a stretch it works.
-}


import Html exposing (Html)

gampleman

module Example exposing (main)

import Svg exposing (svg, stroke, fill, path, pattern, viewBox, rgb255)
import Svg.Path as Path

funnyRed = 
    rgb255 200 20 70

drawing = 
    svg [ viewBox 0 0 400 400 ] 

gampleman

A Critique of elm-explorations/webgl

Critique may sound negative, but it's not. I think the aproach has great potential, but there is a lot to do. What I'm attempting to do here is to offer a perspective on the current implementation noting some gaps in capabilities as well as some of the strengths of the library in hope that this will be helpful building out the future of graphics programming in Elm.

Strong points and how they could be further improved

Compile time checking

gampleman

On using Functions in Msg or Model in Elm

In Elm, you are discouraged to use function values in either the Model or Msg parts of the Elm Architecture.

As far as I can tell, there are two main reasons for this:

1. The model should be a description of the application state, not the processes that manipulate it. Similarly, the messages should describe the changes to an application, not implement them.

2. A more technical reason is that in Elm we cannot equate functions (this causes a runtime error, ouch!) nor can we

gampleman

module Collection
    exposing
        ( Collection
        , isEmpty
        , length
        , head
        , tail
        , take
        , drop
        , slice

gampleman

module Main exposing (main)

import MyHtml exposing (program, text, a, onClick, div)


type Msg
    = Inc
    | Dec