Intro

A few stories today cluster around the same theme: modest technical shifts that change everyday workflows. Some are developer-facing (how we write and train code), others are practical tools that nudge behavior (how we walk or bike in a city). Short reads up front, then two longer looks that matter if you care about tooling, efficiency, or surprising product design.

In Brief

Competitive Programmer's Handbook (2018) [pdf]

Why this matters now: Antti Laaksonen’s Competitive Programmer’s Handbook provides a concise, battle-tested algorithms primer useful for engineers prepping for interviews or leveling up problem-solving skills today.

The free PDF edition resurfaced in a Hacker News thread as a go-to resource: compact, dense, and practical. Readers praised it as a "mind gym" — not because it’s novel, but because it forces deliberate, hard thinking on core algorithms that still show up in interviews and production debugging. If you want concentrated practice on foundations rather than surface-level tutorials, this is an efficient place to spend focused study time.

Key takeaway: The book rewards deliberate practice; treat it like mental sparring rather than light reading.

Why Common Lisp is now the best programming language

Why this matters now: Vivien Henz’s essay argues Common Lisp’s REPL/image model is uniquely suited to an LLM-assisted development loop, making live edits and domain-specific languages far easier to iterate.

The post at vivienhenz.com sparked the usual Lisp evangelism but also a practical thread: with LLMs writing code quickly, the bottleneck is edit‑run‑debug latency. Common Lisp’s interactive image, hot-swapping, and macro facilities give a different feedback model than file-compile-run cycles. Commenters pointed out similar benefits are available in other fast-feedback environments (Clojure, smalltalk-ish systems, or modern REPLs), but the piece is a useful provocation: language ergonomics matter more than raw syntax when models write boilerplate.

"LLMs write code really fast, and that changes a lot," as the author puts it — the claim is less about nostalgia and more about how developer workflows should adapt.

Deep Dive

Dust: Pretraining Transformers Without Backpropagation

Why this matters now: The Dust research page proposes derivative-free pretraining for transformers, which—if practical—would change assumptions about parallelism, hardware, and how we assign credit in deep models.

Dust’s central claim is provocative: instead of relying on gradients computed by backprop, you can use zeroth‑order or search-based methods to discover useful weights or activation adjustments. On paper, that opens interesting use-cases—training in black‑box simulators, massively parallel search across hardware that doesn’t favor sequential gradient passes, or hybrid workflows where gradients are unavailable or expensive.

But there’s a well-worn counterpoint in the HN discussion: for smooth, high‑dimensional objectives, gradients are extremely informative. Derivative‑free methods historically fall behind in sample and compute efficiency. One commenter pointed to a proved complexity gap between gradient and derivative‑free convex optimization; in plain terms, you often need vastly more evaluations if you throw away gradients. Practically, that means Dust will need to show wins in one of a few narrow ways:

  • substantially lower wall‑clock time on realistic hardware,
  • much lower energy use at comparable quality, or
  • unique applicability (domains where gradients are impossible).

What could make Dust useful in the real world? Two plausible paths: first, use Dust as a proposal generator that seeds good activation/weight directions, then consolidate with backprop; second, pair it with novel hardware that can evaluate many perturbations in parallel at much lower cost than a gradient pass. The HN thread also suggested hybrid training regimes—coarse, zeroth‑order exploration followed by gradient refinement—could be a sweet spot.

"Derivative‑free methods historically lose on efficiency and scaling," summarizes the skeptical view, but commenters still found clever hybrid roles where Dust-style ideas could plug in.

If you’re an ML engineer: watch for benchmarks that report wall‑clock time, peak memory, and energy per quality point—those numbers matter more than parameter counts. If you’re an ML researcher: Dust is a good reminder that rethinking credit assignment is fertile ground, but follow-up work must clear the practical efficiency bar.

Find the flattest route between any two points in SF

Why this matters now: flattensf.com turns high-resolution lidar into route choices, letting walkers and cyclists trade distance for reduced climbing with a single slider.

Technically it’s delightful: the app computes routes client-side over ~160k street segments using USGS 1 m lidar and OpenStreetMap data, then shows the Pareto frontier between shortest and flattest. The slider isn’t just UI polish—it's an explicit presentation of the distance-versus-climb trade-off, e.g., "a foot of climb costs X feet of walking," which reframes navigation as a continuous optimization rather than a single metric.

Practical caveats from the discussion are worth keeping in mind. High-resolution digital elevation models are excellent, but they differ: digital terrain models (DTM) try to represent bare ground elevation, while digital surface models (DSM) include objects like buildings and trees. Routing over DSM can give odd results in tightly built areas. Bike-specific concerns also came up—cargo e-bikes or heavily loaded bikes have different comfort thresholds for grade than road bikes, so a universal "flat" slider can’t capture all rider preferences.

Still, FlattenSF shows how accessible datasets (lidar + OSM) can change everyday decisions. It’s a small reminder that better data + a clear interface can tilt behavior—cyclists might choose longer but less exhausting routes, city planners can visualize where grade-reduction interventions would help, and commuters might re-evaluate which streets feel "close" in actual effort terms.

The tool is a compact demo of how high-resolution elevation data can change everyday navigation decisions in a famously hilly city.

Closing Thought

Small shifts in tooling or data often yield outsized everyday wins: whether it’s an experimental training method that challenges backprop’s monopoly, a map that quantifies effort not just distance, or languages and books that reshape feedback loops. Pay attention less to hype and more to where the friction actually sits—runtime feedback, compute cost, or user effort—and you’ll spot the changes that matter before they become obvious.

Sources