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.