Discussion
Algorithms with TypeScript
BloodAndCode: this is great timing for me — i actually have an algorithms & data structures course this semester. seeing implementations in typescript instead of the usual pseudo-code or java/python is really nice. makes it much easier to actually run the code and play with the ideas while learning. curious — did writing this in typescript change how you approached any of the classic structures? some of them feel a bit awkward with generics in certain languages.
jsontwikkeling: Great to hear that. I actually think TypeScript is very fit for the purpose, even better than Python (lacks types) or Java (bulkier).Type signatures document contracts directly: export function rabinKarp(text: string, pattern: string): number[] Clear that it takes two strings and returns match positions. No separate explanation needed.Interfaces model return types and ADTs cleanly: export interface ShortestPathResult<T> { dist: Map<T, number>; parent: Map<T, T | undefined>; } export function dijkstra<T>(graph: Graph<T>, source: T): ShortestPathResult<T> It's also lightweight, flexible, has familiar C-like syntax, and unlike pseudocode — you can actually run everything.Re: generics feeling awkward — in TypeScript they feel pretty natural. The type inference helps a lot, you rarely need to spell out type parameters at call sites.
BloodAndCode: that makes sense. the type signatures as documentation point is actually really nice — being able to see the contract immediately is a big plus compared to a lot of pseudocode examples in textbooks. i also like the idea that everything is runnable. a lot of algorithm books show the idea but you rarely get something you can directly execute and experiment with.will definitely try some of the implementations while studying this semester.
orkunk: Interesting observation.One thing I’ve noticed while building internal tooling is that LLM coding assistants are very good at generating infrastructure/config code, but they don’t really help much with operational drift after deployment.For example, someone changes a config in prod, a later deployment assumes something else, and the difference goes unnoticed until something breaks.That gap between "generated code" and "actual running environment" is surprisingly large.I’ve been experimenting with a small tool that treats configuration drift as an operational signal rather than just a diff. Curious if others here have run into similar issues in multi-environment setups.
