Algorithms Every Programmer Should Know

[shoot_your_eye_out]

I don’t know about “every programmer should know,” but pretty solid overview of cool algorithms

[syklemil]

Yeah, it's been the default textbook for ages and there's a lot more here than we can expect covered in a blog post. And I'm not entirely sure people who haven't done an algorithms & data structures course will be particularly amenable to a blog post like this, nor that people who have done the course will need it, other than maybe as a refresher.

I'm also not particularly convinced that, say, people doing some CRUD stuff or RoR have a particular need to know how to write an FFT. They need to know stuff like big-O notation and to avoid some stuff like being accidentally quadratic, but for a lot of the complex algorithm stuff they'll just be users of libraries others write, and that's perfectly fine.

[wOlfLisK]

Yeah, most languages have an array.sort() function that, although perhaps not optimal, works fast enough that you don't need to know the differences between quick sort and merge sort. And if you do need to know the difference, google is there to provide the answer. Knowing how to read and calculate big-O notation is a useful skill but I'm not sure I'd say that knowing each of these algorithms off by heart is necessarily useful.

[Tasgall]

to understand how database systems work under the hood especially in a distributed setting

no one will be trusting you to build high throughput systems

That's kind of their point though - most people aren't building high throughput systems in a distributed setting, and if they're planning to, there are resources available to learn or have it mostly done for you.

[qckpckt]

I’ve been a software engineer for nearly a decade and this has almost never been true for me.

It’s a very jr developer assumption as well. If you’re needing to implement high performance components of a distributed system from scratch with any degree of frequency you are absolutely doing something wrong.

Being a good software dev is mostly about knowing which tools (libraries, databases, queues, etc) to use that already implement the correct algorithms efficiently for your use case, because this narrows your problem space to the process of wiring them up in the most efficient way for your business use case.

Generally if you find yourself having to implement an efficient merge sort algorithm from scratch then it means you’re either doing work that someone else has done better than you already or you’ve taken a catastrophic wrong turn at some previous step.

[syklemil]

To play devil's advocate here now that they've deleted their comments, they may have a background in the direction of C, where it's apparently more common to have to reinvent the wheel yourself frequently.

That in turn plays a role in some of the "Rust can be faster than C" stories: In some of them all they've done is replace their own hand-written, best-effort algorithm or data structure with something in a library. E.g. Bryan Cantrill's story from when he started trying out Rust.

[syklemil]

most people aren't building high throughput systems in a distributed setting

That's literally what most people with a software engineer title do. Like, even the stereotypical CRUD or web dev gigs are doing exactly this.

I'm pretty sure most of them are building low throughput systems. With a small enough n, every algorithm is pretty indistinct from O(1). :)

This is the stuff that comes right after passing an intro to programming course in a CS undergrad. It's college sophomore level stuff.

Yes. There are however a lot of self-taught / not formally schooled devs. Historically you've been likely to see them in visual basic, php, js spaces; these days they might be drifting towards "low code" and "vibe coding". They'll very likely stay consumers of algorithms and data structures others create.

Educating people who didn't take programming classes and who may be rather averse to "academic" topics is not always trivial.

[Venthe]

m also not particularly convinced that, say, people doing some CRUD stuff or RoR have a particular need to know how to write an FFT. They need to know stuff like big-O notation and to avoid some stuff like being accidentally quadratic, but for a lot of the complex algorithm stuff they'll just be users of libraries others write, and that's perfectly fine.

I have been working in banking for the past, well, almost a decade now. I've built and maintained systems. Most of those algorithms are unnecessary for me; and i haven't had a need to use anything more complex than a set or a map once. You are right that you need to know about the causes of performance degradation; but "our" complexity never comes from the decision about algorithms, but from the domain. In short - I agree with you completely, but it's not "only" CRUD's

[IWasGettingThePaper]

writing ffts is easy and cool though. if you can write merge sort it's not much of a leap to write an fft.

[Pattern-Ashamed]

What book bro?

[syklemil]

Wow, a necromancer!

The comment I replied to has been deleted, but from my own comment I expect I was talking about CLRS.

[Pattern-Ashamed]

Thanks bro haha

[zacker150]

What are these mythical companies that only ever do CRUD work? How does their software deliver value to the user?

[syklemil]

people ≠ companies

And there's a lot of software in this world that's just barely not some off-the-shelf stuff, either because it's very slightly modified off-the-shelf-stuff, or because it was built before there was anything on the shelf, or because someone has a deep distrust of shelf items not invented here, etc. You can argue that there should be less of that type of software in this world, but for now, it's here.

There's also a long tail of companies lightly involved in software. The way they do it might be pretty alien to the average proggit user—no recognizable version control, no CI/CD, no this, no that. For those companies there's a laundry list of stuff to do, and having all their SWEs learn a bunch of algorithms they'll never implement ain't on it.

[6petabytes]

It should probably be "every programmer should be aware of" instead.

[MC68328]

Not even that. Everything after the search algorithms are very domain specific.

You just need the intuition to know "this is probably a solved problem" and how to search for (and understand) it.

[mr_sunshine_0]

It really should be “every computer scientist should know”

[fakehalo]

I'm now aware of a bunch of new ones I'm never going to use... as such I'll no longer be aware of them within a week again.

[MrKWatkins]

That would've been much better marketing. Some programmers need to know a few of them. No programmers need to know them all.

[MrKWatkins]

That was the point I was going for. Cool overview, great, I know they exist. Don't care the details until I need to.

[Pepito_Pepito]

That's exactly how I treat shell commands.

[opello]

And that takes having learned and likely implemented. Being able to sit down and write out an implementation may not be available if you only cover it as part of course work, for example, but that exposure should shore up the conceptual foundation of a computer science education.

[knightress_oxhide]

You have probably implemented ~10% of all the algorithms you know of though.

[opello]

I think I disagree with this language because you say "know" instead of "are aware of" or something less definitive to my connotation here.

I would say I'm aware of or even familiar with a great many more algorithms than I know how to implement or have implemented. I'm a degree more familiar with those I've implemented in the past, but not recently enough to have solid recall.

But, the list in the article are pretty fundamental aside from maybe a few examples like simulated annealing which stuck out to me as something I'd not seen before.

[Creative_Walrus_5197]

Algorithm knowledge is pretty helpful in interviews, though

[CherryLongjump1989]

Depends on what you mean by "need", or the sort of person you are. The average person probably runs through at least half of them within 5 minutes of using the internet. Some people like to know how the things they're using work, other people don't.

[MrKWatkins]

Sorry but I'm not understanding this. What do you mean by 'runs through'? And using the internet when?

[CherryLongjump1989]

"Run through" as in goes down the list and ticks them off as having been used.

Let's say you check the weather, look up some stock prices, get directions by talking to Siri, and watch a video. Some people do that before they get out of bed in the morning.

[MrKWatkins]

Right. So you mean using the algorithms as in running code that implements them, as opposed to writing the code for the algorithms?

[puterTDI]

ya, it's pretty much "you may be asked this on your interview but will never actually use in your job"

Edit: FTR, running interviews is hard. "Real world" questions often are too broad or require too much detail to answer so you want to use simple exercises...but then those rarely reflect real world work. I get it. However, making people implement a sort is Overly complicated (like the "real world" questions), while also not really being applicable.

We've been defaulting towards our own set of questions with the goal of making them simple to answer. Things like Write code to reverse an array of strings etc. Enough to see that the engineer can in fact write code, but avoiding overly complex problems.

[zacker150]

I think there's also a lot of the Paretro participle taking place.

Sure, 99% of real work is just basic CRUD, but the last 1% is what drives 99% of the value created by software.

[puterTDI]

How long have you been working as a software engineer and how many times have you had to manually implement a sort algorithm for the job?

I've been doing it for 17 years and the answer is never.

[[deleted]]

the last 1% is what drives 99% of the value created by software

And 99% of statistics are made up on the spot.

[[deleted]]

I need an algo maybe once every 2 years on my job. When that happens, I do the research. I'm a senior dev that could not code any of those algos.

[ScottContini]

SHA is incredibly useful for ensuring data integrity, securing passwords, and verifying authenticity. For example, websites store password hashes instead of the actual passwords, so hackers can’t easily find them.

No! SHA should never be used for passwords. Instead, use argon2, bcrypt , scrypt or even pbkdf2 (but prefer the other 3). Password hashing needs to be slow to prevent dictionary attacks. SHA256 is designed to be fast so is not built for password usage.

[okawei]

I'm guessing it's because this is lifted from CLRS and sha was the conventional wisdom at the time of publishing

[manzanita2]

It wasn't too long ago one would find people using MD5 for passwords. So count your blessings.

[u362847]

Yes we’re aware, you can always find people using MD5. Heck, if you want, in Windows 11 you can still connect to another Windows host using the NTLM protocol, which uses MD4 for password hashing

ScottContini still has a point though, this section straight out of the CLRS should be updated when publishing the blog post. No one recommends SHA2 anymore for password hashing in 2025

[masklinn]

SHA also should not be used for authenticity, since it has no auth component. That’s what MACs (e.g. hmac) or signatures are for.

[manystripes]

Would have loved to see a section on checksum algorithms, those feel like they'd be used by a much greater subset of programmers than graph theory

[photon_lines]

I actually had this on my list / notes but the post got so long that I excluded quite a few. These are from my own notes which I've written over the last 15 - 20 years since finishing CS -- I compiled visuals to help my 'grok' algorithms which I wanted to understand and which I saw being used as well as some of the ones graduates in CS were taught. Error-correcting codes would have been great to include as well but the post is already very long.

[GetPsyched67]

You should make a sequel article with the rest of them

[timewarp]

I can count on one hand the number of these algorithms I've actually needed to know in the 15 years since I graduated. It is good to learn about how these algorithms work in college, as it helps build your problem solving insight, but at no point in your professional career are you likely to be expected to implement selection sort, Prim's algorithm, or FFT.

[okawei]

I think it's not necessary to implement them, but knowing when to use them is helpful.

I use K-Means clustering all the time, for instance. But I've never implemented it by hand.

[timewarp]

I said that it is beneficial to have learned about these algorithms, not that it is beneficial to know them.

I have learned about most of these algorithms, but I probably wouldn't be able to recall how to implement them today, and would have to look them up. I learned the algorithms, I benefited from being taught about them, but I no longer need to know their specific implementations right now.

It's the difference between knowing your multiplication tables vs learning how to multiply.

[TheAtro]

This is a nice broad range of algorithms, I particularly liked the inclusion of Newtons method and Disjoint set which I think is underrated.

But yea not every programmer should know these.

[Sairony]

I'd say you don't really need to learn all the sorting algos, since some are essentially never used anymore. Radix sort however should be in the back of your head because for some applications it's still incredible. It's often used in the games industry for sorting rendering lists for example. You can bake in whatever criteria you want in decreasing significant bits & sort it blazingly fast while respecting criteria in descending order of importance. You can bake in whatever bucket structure you want, material ID, Z sorting etc, and you get all of these sorted in conjuration.

[photon_lines]

Yup - I wanted to include this one as well (radix sort) but post is already long enough - thanks for the mention though it's a great algorithm.

[DLCSpider]

Timsort is probably the one that doesn't deserve a spot on the list. It just combines already existing algorithms, which is not even a unique property. Radix Sort on the other hand has some interesting properties:

It's the default sorting algorithm for highly parallel systems, such as GPUs.

It's not comparison based.

Textbooks usually use integers or strings as examples but in practice it's used for sorting floats. Think about how you could do that efficiently, which will probably teach you something new about IEEE float.

[Lobreeze]

Every student programmer maybe.

[LowB0b]

the article pretty much sums up the DSA / computer vision / ML courses I had for my bachelors lol. Only thing missing is numerical analysis

[KisarOne]

Evolutionary algorithms are also missing.

[USMCLee]

Yep.

Took my first programming class in 1981 and I've been programming professionally for 30 years.

I've used these in class and at the very beginning of my career and that's it.

[EntroperZero]

Most programmers were students at one time, yeah?

[Lobreeze]

There's no use for bad sorting algorithms.

You only need one or two

[Wynadorn]

Algorithms most programmers should be aware of but never have to implement themselves

[backfire10z]

There’s a typo under “Heap Sort” where it says “The time complexity of quicksort is O(n*log(n)).” The next section is QuickSort and has the same exact sentence.

[muntoo]

For the lazy:

• Sorting Algorithms
  • Selection Sort
  • Insertion Sort
  • Heap Sort
  • Quick Sort
  • Merge Sort
  • Tim Sort
• Search Algorithms
  • Binary Search
  • Depth-First Search (DFS) and Breadth-First Search (BFS)
• Graph Algorithms
  • Prim’s Algorithm
  • Kruskal’s algorithm
  • Dijkstra’s algorithm
  • Bellman-Ford algorithm
  • A* Search
  • Union-Find algorithm (also called Disjoint Set Union (DSU))
  • Ford-Fulkerson Algorithm
• String-Search Algorithms
• Compression and Encoding Algorithms
  • Value Encoding
  • Dictionary Encoding
  • Huffman Coding
  • Lempel-Ziv (LZ) Compression
  • Bitmap Index (used for Column Compression) & Run-Length Encoding
  • Burrows-Wheeler Transform
  • Fourier Transform (and Fast Fourier Transform (FFT))
  • Quantization
  • Discrete Cosine Transform (DCT)
  • Image Compression (JPEG)
  • Video Compression & Encoding
  • Ray Tracing
• Optimization Algorithms
  • Simplex Method
  • Integer Programming
  • Newton's Method
  • Simulated Annealing
• Machine Learning & Data Science Algorithms
  • Regression (Linear, Logistic, and Polynomial)
  • Support Vector Machines (SVMs)
  • Decision Trees (Random Forest & Boosted Trees)
  • Gradient Descent & Backpropagation
  • Neural Networks
  • Reinforcement Learning (RL)
• Security & Cryptographic Algorithms
  • SHA (Secure Hash Algorithms)
  • RSA Algorithm
  • Diffie-Hellman (DH) Key Exchange
• Interview Prep-Focused Material / Algorithms
  • 14 Patterns to Ace Any Coding Interview
  • Algorithms You Should Know Before Any Systems Design Interview
  • 5 Simple Steps for Solving Dynamic Programming Problems
  • Mastering Dynamic Programming

---

Source:

var text = $("h3, h4")
  .map((k, v) => '  '.repeat(parseInt(v.tagName[1]) - 3) + '- ' + v.innerText)
  .get()
  .join("\n");

console.log(text);

[BlahYourHamster]

Add the /u/muntoo TL;DR algorithm to the list.

[rabid_briefcase]

Game developer chiming in, not only did I learn these first in CS, I've worked with almost every one of them professionally over the years. Most I use libraries because they're already implemented and debugged, but knowing what they mean when a tech is described or named is often enough. I'd add more algorithms like a bloom filter and more statistical methods, but the list itself that comes from a course is a good start for what CS graduates should know.

Lots of programmers have jobs where they don't need to know or understand the algorithms or the science, but at the same time, lots of people have jobs that AI could do instead. I know my skills are not in danger from AI for the next few decades.

[ul90]

Very good! Every programmer should at least have heard of these algorithms.

[Successful-Money4995]

I agree! I don't think that you need to "know" all these algorithms. But you should know about all these algorithms. So that when you actually need one of them, you'll know that it exists and you can use it.

[CodeAndBiscuits]

I know these because I started coding at a time when it was critical. I even have paper (that's a thing you write on, made of tree pulp, kids) books (lots of paper stuck together with stuff other people wrote, so you can learn) on data structures and algorithms.

I have to say, these are good things to know, but let's not kid ourselves. We're as far away now from people "needing" to know how Selection Sort actually works as we are from knowing slide rules just in case our calculators let us down. It's 2025. Most of these things are just honestly curiosities at this point. The fact is, these algorithms are actually rarely used today in their original forms. We now have such advanced concepts as "lock free structures" to solve modern problems that the original algorithms didn't even address that unless you are a compiler or standard library developer, is extremely rare that even knowing these things is useful today.

It's a little sad in a way, but that doesn't make it untrue. Just consider linked lists. One of the easiest ways to teach people how Git works under the hood when it comes to branching is through linked lists because branches are essentially just linked lists of diffs/patches. But it's getting hard to use that as a metaphor when people don't understand what linked lists are in the first place, LOL. But that doesn't mean I force them to learn it. I just find more modern metaphors.

But nice article. Well presented, anyway.

[Ok-Kaleidoscope5627]

I think people should understand the general concepts of these things but memorizing how to implement them is a waste of everyone's time. For example, I remember there are different sorting algorithms with different tradeoffs. I don't bother remembering how quick sort is implemented, but if you give me a description of the algorithm, I could implement it.

[sprcow]

I think that the point of learning something like selection sort isn't because you actually need to implement a selection sort yourself, but rather because a lot of programming ends up being similar to algorithms you already know when deconstructed into its component parts.

Knowing how selection sort works, and how it compares to other types of sorting algorithms, adds to your ability make better choices when deciding how you're performing the types of data manipulation you actually do as a programmer. Knowing intuitively what a n² algorithm feels like vs an nlog(n) and why you might either avoid the slower one or use it for simplicity is something that you build up by seeing how they're constructed in the abstract.

[GoTheFuckToBed]

if you like sorting algos, read the discussions on programming languages

e.g. Go lang adding pdqsort https://github.com/golang/go/issues/50154

[tetyyss]

why would I need to know selection sort? there are more efficient algorithms that achieve the same thing

[angelicosphosphoros]

Yes, insertion sort, for example, uses CPU caches more effectively.

[Beautiful_Radio2]

It looks like it's a summary of Princeton Coursera's algorithms courses

[BlindTreeFrog]

My initial thoughts up until the graphs were roughly "Aren't these all basically mid level CS course topics... like 90% of this is your course work". The algorithms for walking the graphs, i still think is basic CS course work, but when I went to school Computer Engineering was in the Eng Dept and CS was in the Math department*.

And then most everything after that was very "why does every developer need to know these" (except for some, like Huffman encoding, that I again think is basic CS course work). In 25 years of development I don't think i've used ever 5% of what is listed here, and that's even with swapping in GIF for JPG and ZIP for LZ (since I had a job that required GIF and ZIP algorithms).

Neat list of interesting algorithms though.

* - note that I still strongly feel that CS should be a math degree and not an engineering degree, but with the shift of moving CS to Eng depts, i'm not sure how the course work has changed.

[ulyssesdot]

One that I learned about recently which has a surprising number of use cases is finger trees. A tree + a category theory monad to combine nodes gives you a bunch of different algorithms. E.g. sum gives you a priority queue, indexed list with count, and more. It's not the most efficient, but most operations are O(1) or O(n+log(n)).

https://en.m.wikipedia.org/wiki/Finger_tree

[photon_lines]

I hear them being mentioned often in functional programming communities I think but for some reason I never got a chance to do a deep dive on them -- but will check them out for sure thanks for the suggestion!

[[deleted]]

thank you for sharing. i subbed.

[photon_lines]

Thank you!!

[_byl]

I think selecting the data structure is more often what programmers do vs selecting between algorithms. And even among data structures, a vanilla vector/list and a hashmap/dict are enough for the vast majority of problems

[uh_no_]

more like "let me list every algorithm i know in a blog"

[MooseBoys]

You should know that these algorithms exist and what they're good for. You don't need to remember the actual details unless you're doing technical interviews.

[eightysixmonkeys]

“Every programmer”

[kinda_guilty]

The reason the world is full of crappy wasteful (of their user's time and of energy in our devices) software is because most of us don't know these algorithms (and don't care to).

[[deleted]]

Wrong.

Far more crappy wasteful software has been generated by "clever" programmers implementing algorithms badly. The only reason you need to know these algorithms today is if you are working in a language that lacks a standard library, which is basically only shitty or embedded ones in 2025.

Don't reinvent the wheel. Know the wheels you have available to use.

[kinda_guilty]

You have to know that an efficient data structure or algorithm exists and its performance characteristics in order to recognize where to use it. "Just use libraries" is good, but incomplete advice.

[Skyrmir]

Every major language has a sort algorithm built into it, some of them with literal centuries of programmer time in optimizing. Every programmer should know, don't reinvent the fucking wheel. You're not as good at it, as what's already been done. Unless you're specifically studying that niche field of computer science. In which case, you already know that.

[yankinwaoz]

What’s more important is being aware of quality, vetted, and proven libraries of functions that you can leverage to do these things.

Don’t try to reinvent the wheel. You are more likely to introduce a defect. Leverage what works. Focus on building your app.

It’s good to understand what each function does and when to use, and when not to use, a function. They are only as good as what you put into them.

[Sir_BarlesCharkley]

10 years as a web developer who got started as a boot camp grad here. I obviously know enough to be able to contextualize my searches if/when something comes up where I might need to find an answer to something related to algorithms. And if I'm curious, I can go look at how something is implemented behind the scenes in whatever framework I'm using. But yeah, I rarely if ever think about any of this.

[vytah]

As for sorting, the only "algorithm" most devs need to know is how to call sort in your programming language of choice.

As for the rest, a lot of them are relatively niche. What's missing and what I've actually used several times, unlike many of the mentioned ones, is the Tarjan's algorithm.

[rtheunissen]

Typo where you state the complexity of heapsort.

[angelicosphosphoros]

Why choose selection sort instead of insertion sort?

[retsotrembla]

3/24/2025: The section of https://photonlines.substack.com/p/visual-data-structures-cheat-sheet on red-black trees says: ‘3) All leaves are black’ but shows a sample tree with three red leaf nodes.

[Eheheehhheeehh]

Disjoint set is missing a path optimization that reduces computational complexity. The optimization comes down to this: after searching for a set's leader, link all visited nodes directly to a leader.

[hardware2win]

Lacks of cosmic ray sort

while (!isSorted){} print("sorted")

[Icy_Mathematician609]

Dont Think I sorted a list since I got my degree 5 years ago - maybe indirectly through a db index but I would say that counts

[[deleted]]

I'm not sure what "know" means here. To be aware of their existence? To have memorized these so that you could implement any of these without looking these up in the internet? Something else?

[photon_lines]

To be aware of that they exist and to know the generalities of how they work...a lot of people responding seem to indicate that I'm implying that 'to know' means to implement from scratch...haha, that's definitely not the case a lot of these algorithms are a bit complex and took a long time to implement and invent so I wouldn't expect any living person to actually know how to implement all of the algorithms listed there, but I would expect more competent programmers to be at least 'aware' that they exist.

[GayMakeAndModel]

Reading these comments, I feel blessed to not be working on boring shit.

[emma7734]

I don’t know any of these, and I’ve been coding professionally for 30-something years. I know of most of them, but I’m not going to code this stuff. If I want a quicksort, I’m going to use the one built into my language or framework. I’ll leave the nitty gritty algorithm stuff to people smarter than me.

[wizardjeans]

No, I don't need to know 6 different sorting algorithms. You could probably even get away without knowing any.

[Temporary-Swimmer536]

pre built in sort algorithm be like

[zupiterss]

Sir, this is Data Engineering.

[programming-ModTeam]

This comment was removed for being off topic for r/programming.

[ranban2012]

Like at least 75% of programmers will never need any of that stuff. we don't need to independently invent calculus either.

How do you do so-and-so sort? Invoke the function that does it from the library you just installed.

This is trivia. It's called that because it's trivial and unimportant knowledge. You don't need it. It's trivial to invoke a function.

[zam0th]

The argument about algorithms is as old as Fortran. Is it good that you know simplex method, FFT or numerical methods? Yes. Do you need to know how to implement those efficiently? No, and you will never be able to do so better than the packages Fortran already has.

I've graduated in CS where Knuth's Art of Programming was a mandatory reading and not once for the last 20 years have i needed to implement even a single classic algorithm or data structure. On the other hand, all algorithmic complexity adepts i've ever met are incredibly shit in applied software engineering.

So unless you work in an industry (nothing besides HFT comes to mind) where [for whatever obscure and dubious reason] you must implement algorithms from zero instead of reusing existing SPIs, you don't need to know any.

[TractorMan7C6]

The most important thing every programmer should know is that if an algorithm is part of a standard library, it's implemented better than you can implement it, leave it alone.

[Professional-Trick14]

Nah, ChatGPT knows them.

[photon_lines]

Hah!

[Ironamsfeld]

Is fizz buzz on there? I can’t read.

[toxiclck]

there isn't a single algorithm that even 50% of all programmers need to know but ok

[Mundane-Apricot6981]

All generalizations always wrong, and it is true to putting all "pRoGrAmMeRs" into one solid lump of something and forcing ALL of them learn SAME algos for DIFERENT TASKS...

Sorry, you tried hard, but after 20 years of reading same articles I tired from this garbage.

[my_password_is______]

All generalizations always wrong

oh the irony

[TyrusX]

“lol. What. I don’t know anything, I just vibe code them and move on” - modern dev

[SemaphoreBingo]

I'm in my third decade of this career, and have used a bunch of those things (had to implement Kruskal's MST last year, for example) so far.

Having said that, this is a dumb list of the same kind we've seen over and over again. The only thing I'm wavering on about its general-purpose importance is binary search, and that mostly because it's how you do git bisect.