Glean 拾遗
Recent picks

3picks · chronological

09-22

What Color is Your Function?

Using an invented language where every function is either red or blue, the author shows what function coloring really means: red functions are asynchronous. Red can only be called from red, calls need special syntax, and some core library functions are red-only. The root cause is async IO: you must unwind the entire C callstack back to the event loop, so callbacks, promises, async-await and generators all end up manually reifying the callstack on the heap via a CPS transform. Async-await fixes rule four but not the split: sync functions return values, async ones return Future/Task wrappers that still need awaiting. Go, Lua and Ruby avoid coloring entirely by suspending whole goroutines, coroutines or fibers instead of returning. C# escapes the same way by using threads. Java, notably, never had the problem.

journal.stuffwithstuff.com · 20 min · Concurrency · Essay · JavaScript
09-22

Long Names Are Long

Working on Dart at Google, Bob Nystrom sits on the second layer of code review: the "readability" pass that checks style, idioms and documentation rather than behavior. What he sees there is identifiers that are far too long. Names can be too short, but the pendulum has swung — names over 60 characters dwarf the operations performed on them, force line breaks, and push authors toward nested expressions instead of locals. His four guidelines: drop words the type already implies (nameString → name, holidayDateList → holidays); drop words that don't disambiguate, tested by asking whether the name still means the same thing without them; drop words the surrounding class or method already supplies (AnnualHolidaySale.promote, not promoteHolidaySale); and drop filler like manager, data, state or engine. A deliberately awful waffle example is trimmed step by step from DeliciousBelgianWaffleObject down to Waffle.garnish.

journal.stuffwithstuff.com · 9 min · Code · Code Review · Programming Languages
09-14

My Principles for Building Software

A practitioner's list of principles for building software, most aimed at making systems simpler: make invalid states unrepresentable, enforce data consistency, design data before code, measure before trading away simplicity. The appendix shows what inconsistency costs — split two Boolean variables x and y that must stay equal into separate databases and the data gains two more states, leaving the toggle function with no correct answer. The author argues consistency is the most undervalued property in software engineering and that most bugs are data failing an expectation. Other principles: avoid trading local simplicity for global complexity (smaller services often do this), don't optimize without measurement, keep code consistent even when the consistent thing isn't the "correct" thing, and learn concepts — the relational model, algebraic data types, borrow checking — rather than surface details of React or Kubernetes. Aimed at backend and data engineers weighing service splits and schema design.

kevinmahoney.co.uk · 9 min · Database · Programming Languages · Software Engineering