Skip to content
Hallway
0:00 / 0:00

#elm#relationaldata#immutability

"Immutable Relational Data" by Richard Feldman

elm-conf

3.2K subscribers • 4 videos on Hallway

YouTube
  • Recommended by 2 people: 2 in engineering communities.
  • A classic. People kept recommending it from 2018 to 2024.
  • Presented by Richard Feldman
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

18K views8 years ago2 recommendations

Software designProgramming languagesDesign patternsSoftware architectureVue, Svelte, Angular and others

Richard Feldman explains why storing frontend state as flat, relational data is superior to nested hierarchical structures.

The uploader added no description.

Why it's here

2 people recommend this

What people say. Engineers recommend this talk for its practical advice on structuring application state relationally rather than hierarchically.

u/XzwordfeudzXin r/functionalprogramming • Recommends

On “On Not Drinking the FP Kool-Aid”

Also the ones by Richard Feldman are fantastic link to this video link to this video link to this video Very concrete and practical examples showing how we can build more robust software.
7View on Reddit

u/friedbricein r/haskell • Recommends

On “Nested field update”

> Is there a simple clean way to do nested record field update without lens? Short answer is "no." In fact, even `OverloadedRecordUpdate` is just a thin coat of sugar on top of lenses. Longer answer: flatter is better than nested, and relational is better than hierarchical. It might just be that your data model could use some tweaking. This video changed the way I look at how I store my data. link to this video
3View on Reddit

u/XzwordfeudzXin r/functionalprogramming • Recommends

On “Flipping the FP switch”

Looking through Richard Feldman's talks have helped me a lot link to this video link to this video link to this video What I noticed is that my approach to solving problems is always divide-and-conquer and writing my code bottom up. For me, recursion is easier to write about than for loops. Why? Because with recursion you start of with solving what you want to do with each item and you write that function. Afterwards you write the next function which applies the previous one to every element. So you have two separate problems and two separate functions, divide-and conquer.
2View on Reddit

u/friedbricein r/haskell • Recommends

On “design patterns”

"Design Patterns" in Haskell tend to be rather meta. I think this is because most Haskell code I run into in the wild is able to do its job with a minimal amount of fuss and ceremony. You need some code to compute some thing? Oh, okay, so write out the formula/rules/process for computing your thing, and that's your Haskell program. And that's kinda all there is to it, usually. It tends to be excruciatingly straightforward. You probably want to take a look at An Introduction to Elm and elm-flatris and then elm-spa-example to get an idea about what I'm talking about. If there is one overriding theme in FP that could be called a "design pattern," it's this: make invalid states unrepresentable…
2View on Reddit

u/XzwordfeudzXin r/haskell • Recommends

On “How to think functional?”

…en contain the database operation `getFromDatabase :: Key User -> IO (Maybe User)`, serialisation `toJson :: User -> Json.Value`, `fromJson :: Json.Value -> Maybe User` et.c. If you have a function in your module that doesn't take any of the types defined in that module as an argument then it probably does not belong there. A good talk on this is: link to this video Avoid nested records. There might a way you can structure your data instead so that it's flat, maybe using dictionaries and sets? A good talk on this is here: link to this video When I started off with functional programming I tried to group everything similar together. So I would put all serialisation in one module, all database operations in…
1View on Reddit