yakshaving_jgton Hacker News • Recommends
On “Code colocation is king”
Just stick everything in the same file until it actually hurts. This presentation0 gets it right. 0: link to this video
0:00 / 0:00
#elm#codeorganization#prematureabstraction
Elm Europe 2017 - Evan Czaplicki - The life of a file
Elm Europe
2.5K subscribers • 3 videos on Hallway
- Recommended by 6 people: 4 on Hacker News, 1 on Lobsters and 1 curated list.
- A classic. People kept recommending it from 2019 to 2026.
- Presented by Evan Czaplicki
- An opinion. It argues one side of a question engineers disagree on.
Intermediate. Assumes working knowledge.
71K views9 years ago6 recommendations
Software designProgramming languagesSimplicity and complexityRefactoring and legacy codeSoftware architecture
Evan Czaplicki discusses how code files grow over time and argues against premature abstraction, recommending keeping code in a single file until it hurts.
The uploader added no description.Why it's here
6 people recommend thisWhat people say. Highly recommended as a classic talk on code organization, simplicity, and avoiding premature refactoring.
gabigrinon Hacker News • Recommends
On “Clean your codebase with basic information theory”
Great read, as always! The combination of the Elm reference and "coarsely structure codebases around CPU timelines and dataflow" statement reminded me of this great talk by Evan Czaplicki (Elm creator): link to this video
programming-talkscurated list on GitHubRecommends
Under “Elm”
The life of a file 00:47:01 by **Evan Czaplicki** (2017)
hombre_fatalon Hacker News • Recommends
On “38% of bugs at Airbnb could have been prevented by using types”
Premature extraction can solidify premature abstractions and create pressure against reabstraction. The creator of Elm has a talk that mentions this: link to this video
myaccountonhnon Hacker News • Recommends
On “Thoughts on Go vs. Rust vs. Zig”
There are a lot of lectures/speeches by the creator of elm and Richard Feldman that talk about how to think "functionally" Here is one about how to structure a project (roughly) link to this video I also think looking at the source code for elm and its website, as well as the elm real world example help a lot.
u/matsumonkiein r/haskell • Mentions
Is there any compelling reasons why our code is split into multiple files ?
Not really related to Haskell but I was watching this video [video explaining how we don't always have to split our code in multiple files even when the number of lines grows too much.
It made me think, why do we actually need to split our code at all ? Can't we program everything in a single file ? I know it sounds stupid but I could only come with a few compelling reasons why multiple files is better than a single one:
1. You can have module restriction, only export/import what is needed (hide internal machinery)
2. code can be reused when created as a library
3. It's easier to deal with when you work with a t…
u/mutablestatesucksin r/typescript • Mentions
On “Where do you guys keep your types”
I put everything that’s logically related together until it’s bothering me, the abstraction/pattern is obvious by then.
Also I let files grow large, FP and static types allow you to do that, watch this great talk by evan: link to this video
I find creating too many files to be pure annoyance with no benefit, people tend to try to organize too much before realizing the actual structure of their program, which you usually do later down the road due to the iterative nature of software development.
u/friedbricein r/haskell • Mentions
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…
u/fokot2in r/scala • Mentions
On “Project structure: Are lots of small files always better?”
This is video about Elm exactly about your question but I love it [video
u/XzwordfeudzXin r/haskell • Mentions
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…