0:00 / 0:00
#apl#codebloat#softwarecomplexity
Programming Obesity: A Code Health Epidemic by Aaron W Hsu #FnConf19
ConfEngine
14K subscribers • 19 videos on Hallway
- Recommended by 1 person: 1 on Lobsters.
- Presented by Aaron W Hsu
- An opinion. It argues one side of a question engineers disagree on.
Intermediate. Assumes working knowledge.
4.5K views6 years ago1 recommendation
Software designTools and practiceSimplicity and complexityPerformance and optimization
Aaron W Hsu argues against the growing complexity and bloat in modern software, advocating for simpler, more predictable code.
Programs are getting fat. They're becoming slow. They're taking up more computing resources. They're getting harder to maintain and more complex from the ground up. Layer upon layer of sophistication is causing us to lose our ability to predict what software will do. Where's that bug? Why is everything going so slowly? Am I even using the right data structures? Where's that important point in the documentation again? What's happened to us? In this meta-dive into the nature of our approach to programming, we will explore some of the dangers of our current approaches to programming and the how/why of our current programming obesity problem. We will look at real case studies and see just how bad the situation can be. But we will also explore how we can battle these sources of obesity. In this passionate plea for code that we can gain control over again, we will look at examples of how we can return to a state of high-performance on all levels, from code size to code scalability. We will look at the principles that can help us to reach leaner, more efficient, more usable, less buggy code. We will hopefully find some light at the end of the tunnel, and how we can change our outlook on programming to push ourselves towards code that benefits not only ourselves, but also those that will come after us. More details: confengine.com/functional-conf-2019/proposal/12362 Conference Link: functionalconf.comWhy it's here
1 person recommends thisWhat people say. Recommended as a thought-provoking critique of modern software complexity and a defense of minimalist programming paradigms.
Moments people linked to
u/arcfidein r/ProgrammingLanguages • Mentions
On “Aaron Hsu - Do Programming Language Features Deliver on their Promises”
I've had some people ask or observe some similar things in this talk. For clarity, I'll point to longer discussions I've had on various points that I've made in this talk:
**Structured Programming**:
Episode 197: 🇬🇧 Algorithms & Tersity with Aaron Hsu · codereport/adsp2 · Discussion #96 · GitHub
and the follow-up: Tacit Talk Episode 27: Tersity with Aaron Hsu and Jon Smith
**Static Types:** Does APL Need a Type System? by Aaron W Hsu at #FnConf18
**Pointers and GC:** Programming Obesity: A Code Health Epidemic by Aaron W Hsu #FnConf19
u/ar-nelsonin r/ProgrammingLanguages • Mentions
On “Tree-walking interpreters and cache-locality”
I've been applying this exact strategy in a Scheme compiler and interpreter that I'm building. I'm using a tree-vector approach, as described in this video. I got a ~2x speedup over an earlier pointer-based implementation in the initial parsing and static analysis steps (which is less than I expected). I don't have a working interpreter yet, so time will tell if it will be decently performant, but I expect it to be much faster than an average tree-walking Scheme interpreter, since Lisps in general are the worst case of cache nonlocality because they're all linked lists.