DEV Community: John Pavlick

For lack of a better name, I’m calling it “The Module Pattern”.

John Pavlick — Wed, 27 Mar 2024 02:24:49 +0000

The Module Pattern is a pattern I've discovered in Elm for dealing with some of the inconveniences of nested TEA¹. As an added bonus, it can make component-type modules a little more straightforward to implement.

Note: I don’t recommend building an application entirely out of nested TEA. In fact, I recommend nesting TEA as infrequently as possible; but sometimes it seems to be inevitable - as much as again when you’re working on a large codebase that isn’t entirely yours. Handle with care, proceed with caution, terms and restrictions may apply, see store for details, something something California okay anyway moving on.

People tend to nest TEA when they "want components"; a common scenario is that a codebase will include a form module - let's call it Form - that has some parameterized types and is designed to be "hosted" within another module (usually a "page"). The intent of the author of the Form module was that, while a form is inherently stateful, that state should be opaque, and any interactions with the form's state should be mediated through its own view and update functions, and then mapped back to the host module.

So let's imagine that we have our Form module, and let's imagine that we want to add a form to a module called Signup, that describes a signup flow. You'd expect to run into something like this:

Form

module Form exposing (Model, Msg, view, update, init)

import Html exposing (Html)

type Model = Model ...

view : Model -> Html msg
view model =
    ...

init : ( Model, Cmd Msg )
init =
    ...

type Msg
    = ...

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    ...

Signup

module Signup exposing (Model, Msg, view, update, init)

import Html exposing (Html)

type Model =
    Model
        { formModel : Form.Model
        ...
        }

view : Model -> Html msg
view ( Model model ) =
    Html.div []
        [ Form.view model.formModel
            |> Html.map GotFormMsg
        ...
        ]

init : ( Model, Cmd Msg )
init =
    Form.init
        |> (\(formModel, formCmd) ->
                ( Model
                    { formModel = formModel
                    , ...
                    }
                , Cmd.batch
                    [ Cmd.map GotFormMsg formCmd
                    , ...
                    ]
                )
           )

type Msg
    = GotFormMsg Form.Msg

update : Msg -> Model -> ( Model, Cmd Msg )
update msg (Model model) =
    case msg of
        GotFormMsg formMsg ->
            Form.update formMsg model.formModel
                |> (\( formModel, formCmd ) ->
                    ( Model { model | formModel = formModel }  
                    , Cmd.map GotFormMsg formCmd
                   )

Let's look at all of the plates we just had to boil:

We had to call Html.map once, and Cmd.map twice
We had to destructure the result of Form.init and Form.update and map them to our host module's init and update
When we mapped, we had to map to GotFormMsg three times

And this is a trivial example; what if we had to pass outside params to Form.init, but not to Form.update? What if Form.view and Form.update both needed access to a Session that was defined outside of Signup, that needed to be handed in? Bucket-brigading dependency params around to multiple callsites in the same module can quickly become exhausting.

Moreover - what if Form was one of those super-cool modules that had a Config type that was constructed applicatively, with a dozen exposed functions to manage its various options - and then another score of exposed functions to actually implement bits and pieces of the module?

And finally - for every module within which you choose to implement Form, you have to do all of these mapping motions over and over and over again. As Form grows, if the parameters required to construct it and implement it change, you have to change every single callsite where every MVU touchpoint is accessed, in every single module that uses Form.

Oh, and I know that I just said “And finally -“ - but one more thing - maybe the worst thing? - there’s no clear delineation between “the parts of this module that are related to interop with another module”, and “the parts of this module that are actually dealing with business / domain logic”. In fact, it may be the case as this application grows, that your inter-module communication gets woven throughout the rest of your domain logic, sprinkled in haphazardly catch-as-catch-can - and it can become remarkably hard to disentangle, later on down the line.

Now comes the Module Pattern. The idea is that you can create a type that represents your "module" - really, your model / view / update - and expose that; by parameterizing a function that "initializes" your module, you can pass in all of those mapping params in one centralized place.

Let's do it for Form:

Form

module Form exposing (Model, Msg, Module, init)

import Html exposing (Html)

type alias Module msg model =
    { view : model -> Html msg
    , update : Msg -> model -> ( model, Cmd msg )
    , init : ( Model, Cmd msg )
    }

init :
    { toModel : model -> Model -> model
    , fromModel : model -> Model 
    , toMsg : Msg -> msg
    } -> Module msg model
init { toModel, fromModel, toMsg } =
    { view =
        \model ->
            view (fromModel model)
                |> Html.map toMsg
    , update =
        \msg model ->
            update msg (fromModel model)
                |> ( \( formModel, formCmd ) ->
                    ( toModel model formModel
                    , Cmd.map toMsg formCmd
                    )
    , init =
        Tuple.mapSecond GotFormMsg init_
    }


type Model = Model ...

view : Model -> Html msg
view model =
    ...

type Msg
    = ...

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    ...

So what does that do for our callsites in Signup?

Signup

module Signup exposing (Model, Msg, view, update, init)

import Html exposing (Html)

type Model =
    Model
        { formModel : Form.Model
        ...
        }

formModule : Form.Module Msg Model
formModule =
    Form.init
        { toModel =
            \(Model model) formModel ->
                Model { model | formModel = formModel }
        , fromModel =
            \( Model { formModel } ) -> formModel
        , toMsg = GotFormMsg
        }

view : Model -> Html msg
view ( Model model ) =
    Html.div []
        [ formModule.view model
        ...
        ]

init : ( Model, Cmd Msg )
init =
    ( Model { formModel = Tuple.first formModule.init, ... }
    , Cmd.batch [ Tuple.second formModule.init, ... ]
    )


type Msg
    = GotFormMsg Form.Msg

update : Msg -> Model -> ( Model, Cmd Msg )
update msg (Model model) =
    case msg of
        GotFormMsg formMsg ->
            formModule.update formMsg (Model model)

It's nice, it's simple, and it gives you some extra leverage:

You know for certain what interfaces you need to satisfy in order to successfully interop with Form - if something is a parameter to Form.init, now, you absolutely must have it in-scope to be able to create a Form.
You can think in terms of "the module that you're in" all of the time, unless you're implementing init - your Form module's view and update can be written in terms of Form, and your Signup's view and update can be written in terms of Signup.
You can repeat this pattern virtually everywhere, so other developers in your codebase will always know that to implement a module, you always start at init and expect a Module msg model that they can use to represent that module's data and behaviors, without having to think too hard about how to map data into and out of it.
You can centralize all of your module’s initialization, the definition of all of its required dependencies and interfaces, and its interop all in one place; as your application grows, your init will only change as requirements for inter-module communication change, and the rest of your module will only change as business / domain requirements change.

Note, too, that you don't have to return a view from your module initialization; you can return data - a function that takes an event and returns HTML, so that you can implement (for instance) form submission via any kind of onClick-able element - or maybe just a list of values of a type that your module is creating, so that you can render them however you want.

In my humble opinion, the less frequently you feel as though you need nested state in an Elm application, the better your life is going to be; but if you must do it, this seems to be the cleanest way to go about it.

“Nested TEA” is a common pattern in Elm development, where “TEA” - The Elm Architecture, also known as Model-View-Update - is used as the primary abstraction for organizing the overall application. Nested TEA is so-called because most major parts of the application are segmented off into their own modules / module namespaces, with internal model / view / update types and functions that are “nested” inside of other models, other views, and other updates. Whether or not this is actually the best way to build Elm applications may be up for debate; but the fact remains that this is a popular style, and that if you’re a working Elm developer, you will likely get paid actual money to deal with it. ↩

Record Type Alias Combinators: A Public Service Announcement

John Pavlick — Mon, 18 Dec 2023 05:23:51 +0000

I've been trying and failing to write this essay for well over a week, so I'm going to start by unburying the lede and we'll take it from there:

I've figured out how to leverage Elm's type system in such a way so as to allow for the creation of record type aliases that create a constraint against the constructors that a given record type alias must expose. Sort of like... record type alias combinators.

These record type aliases can be composed to expose a set of chained, nested "builders" for a type; and they can be implemented for any type.

I'm doing my best here; perhaps a smarter and kinder soul than I, can explain my own discovery to me a little better, and if any of you can do that, please do - but here's what I'm getting at - you can generalize and combine properties on record type aliases.

Imagine that you're building a new design system. From scratch. You just finished reading Refactoring UI¹, and you're 100% ready to "limit your choices" and "define systems in advance" and "pick five colors that you like but don't call them by their names, call them some semantic thing like Primary or Danger or whatever".

Color's easy. We'll start there. You know the drill: from the void, conjure a type; give it named constructors; map them to a value:

type Color
    = Primary
    | Secondary
    | Success
    | Danger
    | Warning
    | Info
    | Light
    | Dark


colorToAttr : Color -> Html.Attribute msg
colorToAttr color =
    Attr.style "background-color" <|
        case color of
            Primary ->
                "#0d6efd"

            Secondary ->
                "#6c757d"

            Success ->
                "#198754"

            Danger ->
                "#dc3545"

            Warning ->
                "#ffc107"

            Info ->
                "#0dcaf0"

            Light ->
                "#f8f9fa"

            Dark ->
                "#212529"

Hey, alright - now we can just use our Color type to create attrs. Easy.

Wait, hold on - incoming Slack message - Product wants to know:

You're building this design system around light mode and dark mode, right?

Okay okay, nothing we can't handle:

type DisplayMode
    = LightMode
    | DarkMode


modedColorToAttr : DisplayMode -> Color -> Html.Attribute msg
modedColorToAttr displayMode color =
    case displayMode of
        LightMode ->
            colorToAttr color

        DarkMode ->
            Attr.style "background-color" <|
                case color of
                    Primary ->
                        "#0d6efd"

                    Secondary ->
                        "#6c757d"

                    Success ->
                        "#198754"

                    Danger ->
                        "#dc3545"

                    Warning ->
                        "#ffc107"

                    Info ->
                        "#0dcaf0"

                    Light ->
                        "#f8f9fa"

                    Dark ->
                        "#212529"

There we go. These colors will work for....... buttons.

Definitely not for backgrounds. Or for lighter variants. Sigh. Time to start building up a bunch of types. With parameters. Zipping around everywhere.

Drowning in a pile of types, again.

I mean, I guess we could just do it in CSS... right? CSS sucks, but it's a known quantity of suck, and the designers know it, and... I guess we'll never have a fully-specified design system.

But what if there was another way? What if there was a way to create tighter constraints, that didn't require developers using a design system to pass around types?

What if there was a way, as the gardener-in-chief of a design system, to create generic kinds of specifications, and compose them together?

What do I always say, on this website?

We're better. And we can do better. LFG.

Designing a System to Design Design Systems

Here's the trick - we have to start thinking in terms of creating generic specifications for these design system elements.

For instance - what if we could generalize over the idea of a color palette - over the choices between Primary, Secondary, Danger, etc - and then generalize over the choices between Background and Font and Border - and compose them together, and still have some type safety, and implement different things differently at each call site, while still leaning on the compiler?

You people have got to check this out. Let's build a type. You wanna build a type? Let's build a type, let's do it.²

type Hue
    = Primary
    | Secondary
    | Danger

So far, nothing out of the ordinary, right? I mean, let's call it Hue instead of Color - Color is a bigger idea - let's save it for something bigger.

type Target
    = Background
    | Font


type Opacity
    = Op100
    | Op70
    | Op30


type Accent
    = Normal
    | Subtle


type Color
    = Color Target Opacity Accent Hue

"John, it seems like we're drowning under a pile of types again--"

Let me cook. I know you know how to make a type. This is all setup, and if you want to enable this kind of flexibility in your design system - you're going to have to specify it. And you're going to specify it eventually, regardless - but if you don't specify it on purpose, you'll specify it on accident. We have a word for that, but I can't remember what it's called.³

type alias AllHues builder =
    { primary : builder
    , secondary : builder
    , danger : builder
    }

A type alias? You're repeating the names of the constructors as properties? And assigning them to a type parameter?

I am. And quickly now, I'm going to do it again for the others:

type alias AllTargets builder =
    { background : builder
    , font : builder
    }


type alias AllOpacities builder =
    { op100 : builder
    , op70 : builder
    , op30 : builder
    }


type alias AllAccents builder =
    { normal : builder
    , subtle : builder
    }

So what did we just do, there?

For every value in the constructor of the Color type, we specified the possible constructors as a record type alias with a type parameter.

And a type parameter can be anything. Even a function. But it truly can be anything - what good is AllHues if the values for primary, secondary, and danger are open?

Let's make them concrete by providing an implementation - a function that, for each record property, supplies a value that matches that property:

allHues : (Hue -> builder) -> AllHues builder
allHues toBuilder =
    { primary = toBuilder Primary
    , secondary = toBuilder Secondary
    , danger = toBuilder Danger
    }


allTargets : (Target -> builder) -> AllTargets builder
allTargets toBuilder =
    { background = toBuilder Background
    , font = toBuilder Font
    }


allOpacities : (Opacity -> builder) -> AllOpacities builder
allOpacities toBuilder =
    { op100 = toBuilder Op100
    , op70 = toBuilder Op70
    , op30 = toBuilder Op30
    }


allAccents : (Accent -> builder) -> AllAccents builder
allAccents toBuilder =
    { normal = toBuilder Normal
    , subtle = toBuilder Subtle
    }

Do you see it, yet?

Try this: what happens if we just call one of these functions?

If we were going to do that, what kind of function would we pass in as the (a -> builder) parameter?

Let's try identity - can't hurt:

allHues_ =
    allHues identity

Let the compiler infer the type.

What type is it?

Oh, it's an AllHues Hue.

What happens if we access a property on that value?

someHue =
    allHues_.primary

It's... a Hue?

So, all of the props on allHues_ are Hues. That's not too surprising - but that was just with passing in identity.

We could pass in... other functions... couldn't we? And then each property on allHues_ would be - a Hue, applied to some function.

Check this out - check out this type:

type alias AllColors builder =
    AllTargets (AllOpacities (AllAccents (AllHues builder)))

It's.......

An AllTargets builder, where builder is
- An AllOpacities builder, where builder is
  - An AllAccents builder, where builder is
    - An AllHues builder.

What if we made the final builder concrete?

type alias ColorBuilder =
    AllColors Color

And provided an implementation?

colorBuilder : ColorBuilder
colorBuilder =
    allTargets
        (\target ->
            allOpacities
                (\opacity ->
                    allAccents
                        (\accent ->
                            allHues
                                (\hue ->
                                    Color target opacity accent hue
                                )
                        )
                )
        )

What... what is this thing?

It's a set of constraints with a concrete implementation that builds up successive, nested applications of values on a function.

Now that you have a single, unambiguous implementation of a Color type that describes all of the colors and their variations - you can build a renderer for that type; and that renderer can be the single source-of-truth for all of the values that it supports:

colorToAttr : Color -> Html.Attribute msg
colorToAttr (Color target opacity accent hue) =
    let
        targetFragment : String
        targetFragment =
            case target of
                Background ->
                    "background-color"

                Font ->
                    "color"

        opacityFragment : String
        opacityFragment =
            case opacity of
                Op100 ->
                    String.fromFloat 1.0

                Op70 ->
                    String.fromFloat 0.7

                Op30 ->
                    String.fromFloat 0.3

        rgbFragment : String
        rgbFragment =
            case ( accent, hue ) of
                ( Normal, Primary ) ->
                    "13, 110, 253"

                ( Normal, Secondary ) ->
                    "108, 117, 125"

                ( Normal, Danger ) ->
                    "220, 53, 69"

                ( Subtle, Primary ) ->
                    "207, 226, 255"

                ( Subtle, Secondary ) ->
                    "226, 227, 229"

                ( Subtle, Danger ) ->
                    "241, 174, 181"
    in
    Attr.style targetFragment <| String.concat [ "rgba(", rgbFragment, ", ", opacityFragment, ")" ]

So that's all well and good and pretty cool - but you may be thinking:

Won't typing out long dotted strings get sort of tiresome? Is there any value to having a call site that looks like Html.div [ colorBuilder.background.op100.normal.secondary ] [...?

We can go deeper. Check this out - let's create a type alias that makes the builder parameter for AllHues concrete to a function of type String -> Html msg, which is incidentally the type signature of Html.text:

type alias TextColorBuilder msg =
    AllHues (String -> Html msg)


textColorBuilder : TextColorBuilder msg
textColorBuilder =
    allHues
        (\hue string ->
            Html.span
                [ Color Font Op100 Normal hue
                    |> colorToAttr
                ]
                [ Html.text string ]
        )


type alias AllTexts msg =
    { unstyled : String -> Html msg
    , withColor : TextColorBuilder msg
    }


text : AllTexts msg
text =
    { unstyled = Html.text
    , withColor = textColorBuilder
    }

So now we can:

dangerousHello : Html msg
dangerousHello =
    text.withColor.danger "Hello, dangerously!"

Well would you look at that!

Guess what else - we can use the builder type parameter to represent a "builder-pattern" function, so that we can use the output of one of our All*s functions to apply a value to a wrapped configuration type:

type Button msg
    = Button { color : Color, onClick : Maybe msg, label : String }


type alias ButtonBuilder msg =
    Button msg -> Button msg


new : { onClick : Maybe msg, label : String } -> Button msg
new { onClick, label } =
    Button { color = colorBuilder.background.op100.normal.primary, onClick = onClick, label = label }


with :
    { opacity : AllOpacities (ButtonBuilder msg)
    , secondary : ButtonBuilder msg
    , danger : ButtonBuilder msg
    }
with =
    { opacity =
        allOpacities
            (\opacity (Button config) ->
                Button
                    { config
                        | color =
                            (\(Color target _ accent hue) ->
                                Color target opacity accent hue
                            )
                                config.color
                    }
            )
    , secondary =
        \(Button config) ->
            Button
                { config
                    | color =
                        (\(Color target opacity accent _) ->
                            Color target opacity accent Secondary
                        )
                            config.color
                }
    , danger =
        \(Button config) ->
            Button
                { config
                    | color =
                        (\(Color target opacity accent _) ->
                            Color target opacity accent Danger
                        )
                            config.color
                }
    }


view : Button msg -> Html msg
view (Button { color, onClick, label }) =
    Html.button
        [ Maybe.map Html.Events.onClick onClick
            |> Maybe.withDefault (Attr.class "")
        , colorToAttr color
        ]
        [ Html.text label ]

You see that? Did you see that?

We decided that one of our constraints for our Button element in our design system was that we could adjust the opacity - so we exposed that via the AllOpacities builder record type alias constraint, and made its builder type parameter a ButtonBuilder msg -
Which gives us the flexibility to expose the record-alias dot-accessor "picker" for our opacity value - and then apply that value to a function that updates our Button msg value!

Check out a call site:

sortaTranslucentDangerButton : Html msg
sortaTranslucentDangerButton =
    new { onClick = Nothing, label = "If you push this button, nothing will happen" }
        |> with.opacity.op30
        |> with.danger
        |> view

There's still so, so much more that can be done with this paradigm - but let's talk about some things that I've found already:

You can specify dot-accessor "builders" for constructors on types, for any type - and then compose them together
If you're using the LSP, you get on-dot autocomplete - which makes for a great developer experience with nice call sites
By leveraging record type aliases as a sort of "namespacing" - you can put more types and values into the same module without having to smurf⁴, or cut a new module to avoid smurfing
You can defunctionalize core parts of an application - for instance, the design system - and separate the call site composition from the implementation - which allows you to colocate related behaviors
You can expose All*s builder record type aliases and all*s builder functions from a module while keeping all constructors totally opaque - which gives you a finer degree of control over module opacity, especially since...
Properties in a record type alias don't have to be 1:1 with constructors for a type that it's providing an implementation for

If anybody wants to play with this - there's an Ellie at this footnote⁵.

In closing: I'm over the moon about having figured out how to do this. I'm still struggling to explain it in the abstract, but I think that the biggest key to the question of "what exactly is this Thing" is that its implementation is isomorphic to the design of elm/url⁶, which the main guy Wolfgang⁷ pointed out while I was trying to explain it to him the other day.

Un/fortunately, I think that I'm going to have more to say on this as I play with it more and get deeper into it. I'm not sure if anybody else has "discovered" this technique yet, but please @ me on X⁸ or in Elm Slack if you'd like to discuss this further or if you have any additional insight.

https://www.refactoringui.com/ ↩
NB: I'm going to shorten up these types so that my writing doesn't get buried in a fully-fledged design system - which don't get me wrong, I'd love to create - but I need to get this essay done first. I've been putting it off for nearly two weeks now, and people are starting to Ask Questions. ↩
I just remembered: it's called CSS. ↩
"Smurfing" is jargon for the practice of adding information to a name in order to disambiguate it from other "things" in a given namespace that have similar semantics but a different implementation. For instance - imagine that all of the code from Html.Events was in the same module as Html.Attributes - how would you know which was an event, and which was an attribute? You could prefix all of the event attributes with event - i.e., eventOnClick, eventOnInput, etc - but that would be noisy and repetitive, so it's best avoided when possible. ("Smurfing" is so-called after the popular cartoon "The Smurfs", wherein most characters have the word Smurf in their names - i.e., "Papa Smurf", "Lazy Smurf", "Brainy Smurf", "AccursedUnutterablePerformIO Smurf".) ↩
https://ellie-app.com/pMGzWB8GLjca1 ↩
https://foldp.com/blog/elm-url.html ↩
https://twitter.com/wolfadex ↩
https://twitter.com/lambdapriest ↩

On Ideology

John Pavlick — Sun, 12 Feb 2023 22:06:08 +0000

Programming languages all implicity include an ideology - a set of core ideas and philosophies - that serve as a sort of conceptual framework for the choices that are made when one is using a given langauge to create a piece of software.

An absence of a clearly-defined ideology is still an ideology; in that case, the ideology is, "anything goes". We have seen how this sort of ideology has worked out, over time and at scale; no examples need to be given. Ultimately, in a language community and ecosystem with no clearly-defined ideology, contributors tend to add their own ideas about "how things could work well" and create frameworks, tooling, scaffolding; in doing so, they are creating an ideology.

For some programming language communities, the tools are an intentional byproduct of an ideology refined and followed to its logical conclusions. This is not always the case - and whether or not it is the case is certainly not some sort of value judgment. Some languages exist as an intersection of "what it was possible to do with computers at the time" and "what seemed most ergonomic, given the constraints".

Elm is most certainly not a member of the latter set. In my experience, and as evidenced most recently by the latest round of handwaving-freakoutery on the orange website¹, this results in surprise and dismay for those unaccustomed to confronting a programming language's ideology head-on; as much as again, when it is contra to their own ideals.

The Elm ecosystem's design decisions - notoriously, the decision to disallow kernel code in 0.19 - function as a set of constraints to enforce the author's ideology on the system as a whole. Many have voiced an opinion that this was not only "wrong" - as in, "not technically correct", but also "wrong", as in "immoral".

Some of Elm's promises and guarantees are literally impossible to realize without this sort of constraint. Should people, such as the author of Elm, be explicity discouraged from creating these constraints, simply because "that's what the people and community want"?

Was it morally wrong for the author of Elm to remove that functionality? Put another way: was there a moral imperative for him to continue to support a feature set that went against his ideology?

What is the moral weight of public opinion?

Is there ever a moral imperative for an Open Source engineer to "listen to the community", regardless of whether or not doing so goes against their personal convictions for how the thing that they've made should function?

There are some types of systems that can only exist in a certain form when they are the product of one, or few minds. Should those systems not be permitted to exist?

What do you value?

https://news.ycombinator.com/item?id=34746161 ↩

LETWW, Part 2: "Regular expressions are quite confusing and difficult to use."

John Pavlick — Tue, 19 Apr 2022 05:24:42 +0000

Previously on Learning Elm The Wrong Way:

Learning Elm the Wrong Way: A Series (Probably)

I'm back, everybody, and I've got more sins to atone for. Buckle up.

The choice to use Elm was a decision made with the rationale that I've employed to make most major decisions in my life so far - by the seat of my pants, with hopes for the best. I'd never studied functional programming, and I'd never owned a whole product before end-to-end; but the client wanted what they wanted, and I was their best hope, so I did what I had to do.

We were not happy, then; those were simpler times.¹

Anyway. I remember the first time I reached for Elm's regular expressions library. I remember reading Evan's helpful "nag screen" on the elm/regex package docs:

Generally speaking, it will be easier and nicer to use a parsing library like elm/parser instead of this.

"Hmm. Alright. I like 'nicer' and I like 'easier'." I clicked over to the docs for elm/parser.

Regular expressions are quite confusing and difficult to use. This library provides a coherent alternative that handles more cases and produces clearer code.

I was sitting there, on my front porch, in the brutal, early-morning Michigan summer sun - all sixty-nine degrees of its feeble fury - and I thought: "Oh boy! If these people think that regex is hard... I'm gonna be so good at this. I'm the God of regex." And it was true - early on in my career, I'd heard that programmers despised and struggled with regex, so I'd made it my business to use Vim only ever and study regex diligently. And, y'know, I was... not half-bad.

Smash cut to:

point : Parser Point
point =
  succeed Point
    |. symbol "("
    |. spaces
    |= float
    |. spaces
    |. symbol ","
    |. spaces
    |= float
    |. spaces
    |. symbol ")"

... and, record-scratch.

"Huh. Well, looks like I'll be using regex today, after all."

Some time passed, and I "learned" how to use decoders; except, I didn't really learn how to use decoders, I just fumbled around with them enough to get work done.² Decode.Pipeline was particularly nice; I wasn't sure what it was doing with all of those |>s, but it clicked on a visual level: "this is some sort of a pipeline, and every Thing that Happens in this pipeline goes into my value".

One day, someone in Elm Slack said something along the lines of, "Yeah, Parser's just like Decode.Pipeline". I looked at Parser again. I read the docs again. My brain did that thing that it does when it not only does not Understand, but also does not Understand why it does not Understand - and promptly powered down.

If you've made it this far, here's a tip: Learn to identify the difference between "I don't understand this", and "I don't understand why I don't understand this", and format your questions accordingly. You'll get further, faster.

More time passed. Years, actually. I made a few more attempts at trying to learn how Parser worked, but every time I made it around to the docs, I was seized by that same feeling of unfamiliarity and confusion. But along the way, I learned something that seemed, at the time, to be unrelated.

I had finally decided to try elm-review³, and I chose to use Elm Slack regular SiriusStarr's review config as a starting point for my own⁴. I was intrigued by some of the rules that were enforced; one of them yelled at me for the way that I was using Decode.Pipeline to decode some JSON into a type alias. It turns out that there's a rule that prohibits you from using a type alias as a constructor!⁵ This means that given a type alias:

type alias Point =
    { x : Int
    , y : Int
    }

You're prohibited from ever calling it like so:

origin : Point
origin = Point 0 0

Instead, you must:

origin : Point
origin = { x = 0, y = 0 }

Which meant that a decoder as follows, was invalid:

pointDecoder : Decoder Point
pointDecoder =
    Decode.succeed Point
        |> Pipeline.required "x" Decode.int
        |> Pipeline.required "y" Decode.int

And that instead, you must:

pointDecoder : Decoder Point
pointDecoder =
    Decode.succeed (\x y -> { x = x, y = y }) 
        |> Pipeline.required "x" Decode.int
        |> Pipeline.required "y" Decode.int

"Well that's pretty verbose, but I get it. Since the type alias is a positional constructor, you could get yourself out of whack if you passed in multiple same-typed arguments out of order, so this forces you to be a little more explicit about what goes where."

"Oh. And I guess that means that I can put any function after the Decode.succeed in a pipeline, and that the Decoder will be a Decoder for whatever type that function outputs; this follows from knowing that a type alias is just a positional constructor for a record."

I didn't realize it, but I was getting closer to unlocking the mysteries of the Parser.

Earlier this week, I was refactoring some code from the project that I mentioned at the beginning of this post. It's been through a lot over the years, as have I, but the client still loves it - and I've learned a lot from stubbornly fixing things over the years, rather than throwing everything out and starting over. I found a branch of my main update function where I was taking a string value, using regex to split it based on a delimiter, and doing a bunch of nonsense to verify that the string contained two and only two pieces after splitting; that they were both integers; etc.

"Man. This looks like a great place to stick a Parser. If only I understood them."

"Maybe this time will be different." You said that the last time. "Yeah, but I'm a little smarter now." We'll see about that, won't we?"

I pulled up the docs. I saw the |. and the |=, and I panicked and froze. But this time, I tried something new.

I pulled up Martin Janiczek's Ellie Catalog⁶, and typed in parser. Bingo: https://ellie-app.com/f2smkjHfN26a1

As soon as I saw the code in the Ellie, without even running it - I recognized what had kept me from ever understanding before, and then I immediately understood the code.

My prior lack of understanding was due to a mental disconnect between the two true sentences, "record type aliases come with implicit constructors"⁷ and "all constructors are functions".

You see, most of my application development experience has been in csharp. In csharp, we don't have type aliases or anything like that, but we do have classes. Classes have a type, and types have a type (and the type of a type is a type called Type, obviously). After marinating for over a decade in a type system where type names are "special" and have to be invoked only in certain special-case contexts (with operators like typeof(), or as function signatures) - I couldn't see what was literally right in front of my eyes:

Type names, just like everything else in Elm, are Not Special. They're constructors for a value.

And this was obscured for so long, because when I saw

Parser.succeed Point
    |= ...

I didn't see "a function (Parser.succeed) taking another function as an argument (Point) and then passing it values collected from a parsing operation" - I saw "Parser.succeed for a Special Type Name".

So from this spiraling diatribe (spiral-tribe?⁸), three lessons:

Great pains have been taken to ensure that everything with Elm is internally consistent; if you don't understand one Thing, that's based on another Thing - there's a good chance that you don't understand the "another Thing" as well as you think you do.

and

Never be afraid to re-visit ideas that you didn't understand the first time around. You're smarter now.

and

Nothing in this language is special; everything is a function with zero or more arguments. If you don't understand something, try to think about how it could be a function with zero or more arguments, and what that might mean.

Never did hear back about the yacht job⁹. Oh well. More yachts in the sea, I suppose.

https://www.youtube.com/watch?v=BO_ZmDETR98 ↩
To everyone in Elm Slack that's ever explained decoders to me - had to have been upwards of 20 times until y'all wore a groove in my smooth brain to give the information a place to live - thank you so much. ↩
Spreading the gospel of how and why elm-review is important falls outside of the scope of this post; but for the love of God, if you don't know about elm-review, learn about elm-review. All hail Jeroen. https://github.com/jfmengels/elm-review ↩
https://github.com/SiriusStarr/elm-review-rules ↩
https://elm.dmy.fr/packages/lue-bird/elm-no-record-type-alias-constructor-function/latest/ ↩
https://janiczek-ellies.builtwithdark.com/ ↩
After I posted this, lue helpfully pointed out some instances where a type alias is not actually a constructor for a value - you can read more about this here: https://elm.dmy.fr/packages/lue-bird/elm-no-record-type-alias-constructor-function/latest/ ↩
https://sp23.org/ ↩
https://dev.to/jmpavlick/hungary-for-the-power-a-closer-look-at-hungarian-notation-282d ↩

Hungary for the Power: A Closer Look at Hungarian Notation

John Pavlick — Sun, 13 Feb 2022 07:33:04 +0000

Few concepts within the Global Programming Mindshare are as universally-reviled as Hungarian notation. Everybody Knows that it's completely unnecessary, aesthetically displeasing, and considered harmful¹. If you're not familiar, the idea is generally interpreted as follows:

Hungarian notation is a naming convention that adds a prefix to each variable name, so as to encode its type in its name.

And it's generally accepted that examples look like this:

string str_firstName;

int i_ageInYears;

bool b_enabled;

Most people are happy to dismiss this immediately; to consign it to the trashbin of Universally Acknowledged Bad Programming Thoughts, right along with GOTO and Internet Explorer 8. And at first glance, it's not hard to see why; programmers are, by virtue, lazy. There's no compelling reason to annotate a variable's type by encoding it in its name - that's what we have compilers for! If you're dumb enough to type int result = firstName + ageInYears;, you deserve whatever abuse you get from your compiler. It should be obvious that those two things are probably not the Same Kind of Thing. Right?

You'd probably think so, but I'm nothing if not the sworn enemy of "What Everyone Knows"; so come now, let us reason together.

I'm going to start by quoting the whitepaper, because it doesn't seem like anybody else has read it.

...the concept of "type" in this context is determined by the set of operations that can be applied to a quantity. The test for type equivalence is simple: could the same set of operations be meaningfully applied to the quantities in questions? If so, the types are thought to be the same. If there are operations that apply to a quantity in exclusion of others, the type of the quantity is different.

Note that the above definition of type (which, incidentally, is suggested by languages such as SIMULA and Smalltalk) is a superset of the more common definition, which takes only the quantity's representation into account. Naturally, if the representations of x and y are different, there will exist some operations that could be applied to x but not y, or the reverse.²

"The whitepaper", as it happens, was written by one Charles Simonyi. You may not have heard of him, but you're no doubt familiar with his work; he is the mind behind Microsoft Word and Microsoft Excel³. He's probably on a yacht right now⁴, and he is almost definitely smarter than you are.

Regardless, I'm hard-pressed to think of a more correct definition for a type. Most software developers I've talked to think that a "type" is a "thing" like an int, a string, or a bool, that defines a set of operations over a given category of values; and while they're not wrong⁵, I can't say that they're right, either - because that's too broad a definition. "What's an ocean?" "Oh, it's a thing you can drown in." Sure, it's not a false statement; but by that reasoning, I have an ocean in my bathroom.

If you don't understand why this is a big deal, let's outline a simple example. There's a difference, you know, between an int value storing someone's age, and an int value storing a for loop's index value. The compiler doesn't know about it, because if you try to multiply someone's age by an iterator's index, as long as they're both ints, the compiler will be happy; but will your program be correct?

Just because an operation is possible, that doesn't mean that it's correct.

So anyway - Simonyi goes on to suggest some naming conventions to give programmers the tools to help themselves avoid this footgun - to make the representations of x and y different, so as to discourage performing valid-but-nonsensical operations to them.

Let's look at another example - let's think about Microsoft Excel for a moment. In a spreadsheet, your two most important primitives are "Row" and "Column". If you needed to implement a spreadsheet in C, you'd probably start by defining a multi-dimensional array - rows of columns - to hold your data, with a cell represented by the the data stored at the coordinate of the indices for the row and the column. Since you can access an item in an array by its index, this means that you can write a function with a signature like void clearCellData(int rowIndex, int columnIndex). And it's great - but what happens when you transpose your inputs for the row and column? What happens when you write a function void clearRow(int rowIndex) but you accidentally pass in a column index? The compiler is as pleased as ever, and you won't even get an error at runtime (unless it's for a null reference) - but you've deleted every cell in the wrong row.⁶

If you'd been careful to follow Hungarian Notation as outlined in the whitepaper, you'd be much less likely to make that mistake; if every int representing a "Row" was prefixed with row_, and if every int representing a "Column" was prefixed with col_, you'd be much less likely to call clearRow(col_selected). And that, my friends, is the pragmatism behind the reasoning for Hungarian Notation. Nowhere in the whitepaper will you find mention of prefixing strings with str_ and ints with i_, solely on the basis that they're strings and ints.

Well now, that certainly doesn't sound so bad, does it?

The trouble, it seems, is that everybody else got it wrong.

Spend enough time⁷ researching Hungarian Notation, and you'll come across the name Charles Petzold. This particular Charles was also an Important Programmer at Microsoft, and in his book "Programming Windows", he explains it thusly:

Many Windows programmers use a variable-naming convention known as "Hungarian Notation," in honor of the
legendary Microsoft programmer Charles Simonyi. Very simply, the variable name begins with a lowercase letter or letters that denote the data type of the variable. For example, the sz prefix in szCmdLine stands for "string terminated by zero." The h prefix in hInstance and hPrevInstance stands for "handle;" the i prefix in iCmdShow stands for "integer."⁸

And that's it! That's his whole statement on the topic. Huh. I guess Other Charles didn't read the whitepaper. Unfortunately, this is the version of the idea that has found widespread adoption. The important difference here is that the idea behind Hungarian Notation concerns itself with semantics, not with the way that the data is handled by the compiler or its output.

If you've been following along, you'll note that earlier, I didn't say, "The naming convention was the reasoning behind Hungarian Notation"; that was merely the pragmatism that drove it. The reasoning behind Hungarian notation should be familiar to every Elm developer that's ever been force-fed Richard Feldman talks in the Elm Slack: making impossible states impossible⁹.

The goal was never to make sure that you knew that an int was an int; it was to give you better tools to restrict your program in such a way that it only ever performed computations that were semantically valid.

Wait, so you're certainly not suggesting...

... that you go out and prefix all of your program's values with semantic information? Well, it certainly couldn't hurt - but in the forty-plus years that have passed since these ideas were introduced, we've built better tools and thought about these problems a lot more. We're better, and we can do better.

We have Elm, and Elm has custom types, and with custom types we can implement domain-specific types as easily as we can breathe. The Elm Patterns book briefly outlines this in the section about Type Blindness¹⁰, and Joel Quenneville has an excellent demonstration of the pattern applied at this footnote's link¹¹, but I'll summarize it here.

In the context of our earlier example - given that we had a two-dimensional array that we needed to access by its indices¹², we could wrap the Int values with custom types, like so:

type RowIndex = RowIndex Int

type ColIndex = ColIndex Int

All of a sudden, we have compile-time verification for our program's semantics.

We can keep going! Wrapping primitives means that we have to unwrap them (i.e., some form of (\(RowIndex index) -> index)) when we need to use the primitive value, which is a little extra work - but it's worth it, because now we have to think a little harder about what kinds of operations we're going to need to perform on our values. We have now shifted into the realm of considering our program's semantics, which means that we are now motivated to write functions to use our values. Consider:

nextRowIndex : RowIndex -> RowIndex
nextRowIndex (RowIndex index) =
    RowIndex (index + 1)

prevRowIndex : RowIndex -> RowIndex
prevRowIndex (RowIndex index)
    RowIndex (index - 1)

Now, if we accidentally pass a ColIndex to nextRowIndex - we won't get back a semantically-incorrect value - our code won't compile. You won't get that with a function signature that uses all primitives, such as nextRowIndex : Int -> Int.

This is powerful. By including a value's semantics in the definition of the type used to store and refer to that value, we can use our compiler to verify our program's correctness - and with Elm, we have the tools to do just that. This, truly, is the spirit in which Hungarian Notation was developed and presented; and that spirit lives on, every time an Elm developer writes type Dollar = Dollar Int.

In conclusion, Elm is Hungarian Notation. Thank you for your time. No - stop - where are you going? I thought we were FRIENDS

Oh, and Mr. Simonyi, if you need an Elm developer on that yacht, Microsoft has my number on file from the number of times they've coerced me into giving it to them; call me anytime.

http://catb.org/jargon/html/C/considered-harmful.html ↩
https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-6.0/aa260976(v=vs.60)#type-calculus ↩
https://en.wikipedia.org/wiki/Charles_Simonyi#Microsoft ↩
https://en.wikipedia.org/wiki/Charles_Simonyi#Personal_life ↩
https://rationalwiki.org/wiki/Not_even_wrong ↩
The Joel talks about this, here, and his prose is much nicer than mine: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ - but he still misses the point that I intend to make in this essay. I'm getting close to it, I promise. ↩
Five minutes, max ↩
The top search result for "charles petzold programming windows online" was this sketchy public Google Drive Link, which you may download at your own risk and peril: https://docs.google.com/file/d/0B73JwvIHVHaiSFdpekJCOUdoeE0/view?resourcekey=0-JFez95uS9jETJQdFGKY_1w ↩
https://www.youtube.com/watch?v=IcgmSRJHu_8 ↩
https://sporto.github.io/elm-patterns/basic/type-blindness.html ↩
https://thoughtbot.com/upcase/videos/domain-specific-types-in-elm ↩
I know that accessing an array's value by index isn't very Elm-y, but it fits the illustration; assume that it's for interop with some dirty old Javascript, if that makes you feel better ↩

"You can't do nested record updates in Elm."

John Pavlick — Fri, 28 Jan 2022 05:08:39 +0000

At least, not in an intuitive way. It's one of the first pain-points that a new developer runs into when getting started with the language.

Given:

type alias Model =
    { person : Person
    }

type alias Person =
    { firstName : String
    , lastName : String
    }

... the natural thing to try when writing an update function looks like this:

update msg model =
    case msg of
        UpdatedFirstName firstName ->
            { model | person =
              { model.person |
                  firstName = firstName
              }
            }

The compiler won't like it, and neither will you; this is not The Way.

The natural next step always looks something like this:

update msg model =
    case msg of
        UpdatedFirstName firstName ->
            let
                currentPerson = model.person

                updatedPerson =
                    { currentPerson | firstName = firstName }
            in
            { model | person = updatedPerson }

But we're better. We can do better. Follow me.

Elm is a really, really simple language. Everything in the language follows a set of internally-consistent semantics; I find that when something does not work as I'd expect it to, it means that my expectations are wrong, which means that my mental model of the language is incomplete or wrong. (NB: people that claim to design systems that "work just like you'd expect them to" - how can they make that claim? Who is this subset of people for whom these things work exactly as they'd expect them to; and are they even the right subset of people to optimize for?¹)

A few weeks ago, one of those Elm Lightbulbs fell neatly into its socket and I noticed one of Elm's guiding principles:

Functions go on the left. Parameters go on the right.

(Yes, I'm aware of |>; do you know how a mirror works?)

This seems obvious enough, but it has interesting implications, not all of which are immediately apparent. Everybody knows that if you have an a and you want to turn it into a b, all you have to do is put a function to the left of a that turns it into b - so you write a function, and call it:

aToB : a -> b

aToB valueA

But what if you only need to use it once? Why not just write a lambda?

(\a -> b) valueA

But you already knew that, and I still haven't addressed the elephant in the room. You probably knew, too, that you can write a lambda that takes a value and returns a record.

So why haven't I seen this before?

update msg model =
    case msg of
        UpdatedFirstName firstName ->
            { model |
                person =
                    (\p ->
                        { p | firstName = firstName }
                    ) model.person
            }

"Wow, John. Neat party trick. But -"

You're right. This isn't a silver bullet. Sometimes, you should just write a function that does this for you. Some people use a builder pattern², so they can do neat stuff like this:

update msg model =
    case msg of
        UpdatedFirstName firstName ->
            { model | person =
                model.person
                    |> withUpdatedFirstName firstName
            }

withUpdatedFirstName : String -> Person -> Person
withUpdatedFirstName firstName =
    (\person -> { person | firstName = firstName } )

But you don't always need to reach for a builder pattern, when all you need to do is update a nested record once in your update function.

Besides, that's really not even what this little essay was about, in the first place:

As a beginner or intermediate Elm developer, if you get the sense that "there must be a better way to do this" - there probably is. Go look for it, and don't stop looking until you find it.

That's all. Good night, take care.

Update / edit: I posted this on the Elm Slack³ last night, and Jeroen Engels was kind enough to read though this, detail some errata, and suggest some improvements. I'm just going to quote him, here:

I think one of the options I end up going for in the end, is to have a separate function to update Person, in a separate Person module where the Person type is opaque. That's I think usually where you get the most benefits and it feels least cumbersome (if you already have the opaque type), and I think it would be valuable to mention it here.

Opaque types are beyond the scope of this post⁴, but Charlie Koster does a great job of explaining them, here, for anyone interested.

Love or hate DHH, this document is still relevant: https://rubyonrails.org/doctrine - Ctrl+F "surprise" to get to the relevant section. ↩
https://sporto.github.io/elm-patterns/basic/builder-pattern.html ↩
http://elmlang.herokuapp.com/ ↩
Because I don't feel qualified to explain them, and because my schtick is "saving beginners from themselves" and "atoning for my sins"; I still have much to learn. ↩

Learning Elm the Wrong Way: A Series (Probably)

John Pavlick — Sat, 15 Jan 2022 07:33:19 +0000

Hi, I'm John, and a few months ago I decided that I've been doing this for too long to be this bad at it.

I've been an Elm developer since 2018, and the story is really only important to me¹ (there's enough self-aggrandizing on the Internet² these days) so I'll leave it out - but it's taken me a remarkably long time to feel as if I have any real command of the language and its tooling / ecosystem.

Some of the Best & Brightest on the Elm Slack have been kindly tolerating my ineptitude for some years now, and now that I know about classList and can hang out in #beginners and field easy questions, it's time to take the next logical step: start a dev blog.

Learning by example is well and good, but most of the truly important things I've learned have been by counter-example. What-to-do is nowhere near as poignant on its own, as it is when contrasted with what-not-to-do. And I'm an expert at what-not-to-do. Unfortunately, I've had to find these poignant counter-examples on my own. I'm here today to 1) confess my sins, and 2) show you how not to be like me. I've got enough sins for which to seek absolution that this will likely be a series, but let's dive in now. If you want to learn Elm the wrong way, start by following the headline-sized point below, don't read anything else, and... I'll see you in #beginners.

Ignore / Fear The Runtime

So you did https://guide.elm-lang.org/, and you're aware that "Elm is a functional language that transpiles to Javascript and has its own runtime". Great! Now, if you want to do things the wrong way: never ever think about the runtime, ever again.

To be fair, this isn't wholly advice without merit; the runtime stays out of your way. My background is in data / reporting - I thought, "Oh, good. A runtime. Like when I smash F5 on SQL Server and it runs my query. Like dotnet. Like the JVM."

But there's a difference that wasn't apparent to me when I got started - since Elm is event-driven, you don't call the runtime; the runtime calls YOU. I'll say it again:

The runtime calls you!

Remember when you copied and pasted this block of code into elm reactor and fiddled with everything around it until your app compiled? I do!

main : Program () Model Msg
main =
    Browser.sandbox
        { init = initialModel
        , view = view
        , update = update
        }

"Ah. A main function. Seems right."

The problem with main is that by the numbers, it's not a function that you write often; you set it up, and it's good. The Code is Good, and you don't touch the Code when it is Good; and so you proceed to not think very hard about it for a few years.

At a high level, the difference between public static void main() and main : Program () Model Msg is that, in the case of the latter, you are telling a program that already exists which three specific functions it's going to call, to handle very specific parts of your application domain.

Elm's main function has more in common with dependency injection - with services.AddSingleton<IEmailProxy, EmailProxy>();, than it does with public static void main(). Our old friend psvm() will execute any old code that we sling in there; in contrast, Elm's runtime only knows that it's going to get messages (from the DOM, from ports, and from HTTP responses); that it's going to render HTML; and that it's going to have to start up your application for the first time. The particulars of what it does in those situations are what the code that you are writing actually does, and do those things and those things only it must (no side effects, remember?). And this brings me to my next point:

Msgs happened in the past; getting their names right is important.

Hardest two problems, cache invalidation, naming, blah blah blah

You've already heard the quote, you already know that.

But you need to realize that when you declare the variants for your Msg type, that every time you process a Msg in update, you are processing the output of an action that already happened.

Since I came from an OO / imperative / procedural background, I brought what I had with me when I started learning this language. If I was writing a Windows Forms application, and I wanted btn_DoSomething to do something, I'd wire its click event-handler to a function DoSomething, and something would be done³. So in Elm:

button [ onClick DoSomething ] [ text "Do Something" ]

and

type Msg
    = DoSomething

and

case msg of
    DoSomething ->
        ( model, doSomething )

I regret to inform you that this is not the Way.

DoSomething means, "perform an action", and tells you nothing about how you got to the point in your program's execution where something was done. So if you choose to DoSomething, and something was done, what do you name your variant "for when something was done"?

Probably DoSomethingResult. But this is a function, in a functional language! "DoSomethingResult" is a name, a noun; and their kind are not welcome here⁴. Banish from your mind any thoughts that this is a silly hill to die on; we are programmers, we are talking about a programming language, and if you don't spend quite a bit of time thinking about the structure and interpretation⁵ of the language that you speak every day - you're going to have a bad time. Get interested in linguistics.

I digress. This is a functional language; custom type variants are functions that are a constructor for their custom type; we need to give them names that are verbs. What's a good verb for receiving a result from a function yclept doSomething? I don't know, how about, GetDoSomethingResult? Close, but computer says "no"⁶.

The act of receiving a Msg is not something that will be done by your program; it is something that was done, in the past, by the runtime. Your Msg variants are event handlers for the return value of events that come from the runtime.

Who clicked that button? You did! (Who's a good doggy?) But the only way that the event "clicked a button" is any different from any of the other thousand events per second that you emit while using a web browser (scrolling, moving your mouse, clicking on a blank space) is that you told Elm's runtime to listen for that event, and that you could handle whatever result the runtime generated from processing that event.

So since the event that you want to handle happened in the past, and since it was done by somebody else - what should you call it? In this instance, I would call my variant GotDoSomethingResult. It's perfect! It tells us that the runtime already received our result from the doSomething function, and is ready to hand it over to us for further processing. Once you start reading packages, or other open-source projects, you'll see these patterns pop up - lots of Gots and Clickeds and Changeds.

Let's take what we've learned, and selectively refactor our application that we wrote earlier to use our new knowledge:

button [ onClick ClickedBtnDoSomething ] [ text "Do Something" ]

and

type Msg
    = ClickedBtnDoSomething
    | GotDoSomethingResult Result (Http.Error ())

and

case msg of
    ClickedBtnDoSomething ->
        ...

    GotDoSomethingResult result ->
        ...

When you talk about "getting" something, the Thing that you will Get is not yet in your possession, no matter how near the future may be wherein you have that Thing; but when you "Got" something, you can only ever speak of the action of your coming into its possession, in the past-tense. I brought up linguistics because when you start naming your Msgs (etc) in this way, it allows you to shift your thinking ever-so-slightly in a way that makes it a lot easier to reason about your application, its state, and why its behavior may or may not be as expected.

In conclusion, conclusions are hard and I could spill another thousand more keystrokes without actually adding anything else of substance to this post, so I'll stop now. If you're still here: thanks for reading along. If this helped you: there's lots more where this came from. Be sure to tune in next time (probably) for (a lot) more⁷.

The short version is, "I needed to learn Javascript but I really didn't want to do that thing" ↩
Are you supposed to capitalize "Internet"? I tried it both ways. Both feel weird. ↩
https://en.wikipedia.org/wiki/Politician%27s_syllogism ↩
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html (talk about an evergreen blogpost) ↩
The structure and interpretation of computer programs is, at its core, the structure and interpretation of a bunch of thoughts, both yours and those of others. Language enables thought and gives rise to consciousness; the structure and interpretation of computer programs is the structure and interpretation of thought, which is the structure and interpretation of language. Mind that I'm above my pay grade talking about these things, so whether you agree with me or not, go learn about them for yourself; and then it won't matter if I'm right - you will know. ↩
https://www.youtube.com/watch?v=zFl6p4D59AA ↩
And if this made you mad, @ me in the Elm Slack. Maybe calm down a little first, though. ↩