View elm-touch-and-measure.js
This script touches each elm file
And recopiles it, then stores the time taken
const r = require("ramda")
const dir = "./src/Elm"
const fs = require("fs")
const childProcess = require('child_process')
const async = require('async')
View elm-elmi-timestamps.js
This script compares timestamp of elmi files
To try getting files that take a long time to compile
But this attempt has proven very useful
var fs = require("fs")
var path = require("path")
var dir = "./elm-stuff/build-artifacts/0.18.0/Versent/stax/1.0.0/";

Register Element

First you will need document-register-element

yarn add document-register-element

Add script to register elements


Exceptions are surprising

Given something like this:

proc sub(): string {.raises: [OSError].} =
    raise newException(OSError, "OS")

proc main() =
View interactor.rb
class DoSomething
->(user:) { dep, user: user).call
def initialize(dep:, user:)
@dep = dep
@user = user
View cloudSettings

This is an example reusable element I made for our application

My current API is not great as it requires a lot of boilerplate to hook init, state, update and view.

But in summary this library requires:

  • Some configuration
  • App state: Some state that the application manages e.g. currently selected thing
  • Hidden state: Some state that the component cares about, that can be hidden from the app

This is an example reusable element I made for our application

It is an input field with auto suggestions.

This element needs three pieces of state:

  • List of things to search for
  • Current selected thing
  • And the query the user is typing (At the moment this is in "hidden" state)

Extreme is very vague. I assume you are comparing JS vs Elm / PureScipt.

You get a lot more than purity i.e. robust, speed of development, confidence.

You give up less than you say.

Convenience: Depends on what are you used to, Haskell, PS can be have a lot of 'convenience' after you learn them. Is just different type.


Haskell dev writes some Elm, concludes that the language should be avoided. Writes an article about it.

JS developer then reads and thinks, oh Elm is bad, I better stick to JS then.

We just made a huge disservice to the programming community. That article might be right in several things (how the lack of Typeclasses hurts expressiveness), but it totally missed the point of Elm.

As an industry we want to move to more robust languages. Haskell has been around for many year, but we are still mostly using mediocre programming languages. Haskell is great but it has a huge learning curve, so people don't adopt it.