6 ms·
Most of those you'd consume in library form. Most programmers shouldn't be writing their own lists, hash maps, b-trees, sort algorithms, etc. Or generally reinv
by jillesvangurp 3y ago
Most of those you'd consume in library form. Most programmers shouldn't be writing their own lists, hash maps, b-trees, sort algorithms, etc. Or generally reinvent wheels. It's nice to understand how this stuff works and have a notion of complexity and other limitations. But, mostly we're just sticking things together that already works.
I've dabbled a bit over the years with reinventing wheels like this and it's fun. and of course I had an algorithms course when I did my CS degree, 30 years ago. But, I can't say I spend a lot of time obsessing about algorithm implementations. I mostly just use them in library form; just like everybody else.
- chasd00 3y agoOne thing about learning algorithms from scratch is you learn how to measure code in terms of various resource costs (cpu, men, I/O). Being able to understand the cost of a given code block is very valuable.
- zerkten 3y agoIt doesn't seem that people actually learn those things in many cases. I encounter programmers fairly regularly who struggle to grasp CPU vs memory vs I/O trade-offs and have no mastery of tools for measuring them. This is unfortunate because the tools can often be a cheat code. It's painful to see people fixate on one possible cause without going to fundamentals and making a proper assessment. These people all pass the traditional programming interview filters for algorithms.
- jdthedisciple 3y agoSrsly With technology moving faster than ever, I believe we need to cultivate more acceptability for simply using existing stuff while rudimentarily understanding how it works, obviously ...
- jmaker 3y agoSometimes the general purpose implementations just don’t cut it, depending on the data access patterns, the hardware, etc., neither do they exhibit sufficient tuning capabilities. Sometimes people find out how embarrassingly inefficient a stdlib implementation under the hood is.
- gchamonlive 3y agoThat is probably right for most jobs in the industry. But it is not always so. You can use these algorithms in side projects (I did so for Go for instance, because it didn't have sets implemented and wanted to understand the language better). Or maybe you lust for a career in the gaming industry, which yes have their own engines ready to use, but you might have to do optimisations of your own. Or work with SOC and embedded systems. Maybe you would like to work with Linux core tools one day. I think there is a broader world than that of the common jobs in the silicon valley.
- j1elo 3y agoGo still doesn't have Set types. The usual thing to do is using a map of your type to either an empty struct, or maybe a bool, if I got that correctly (have only been using Go for a couple months so far) Did you implement your own Set type and primitive functions?
- porridgeraisin 3y agoMost languages implement sets using maps. The only major difference you can optimise for is the fact that in majority usage, keys in maps are likely to exist, whereas sets are used for membership checks. Bar that, you can just as well use a map with a dummy value.
- zogrodea 3y agoCan you give a reference for that? It sounds very unlikely to me, although I've only read/gone through two relevant standard library implementations: F# and OCaml. Neither of them use dummy values as you suggest. They have similar implementations (both are AVL trees) but sets really do contain only one value while maps contain two. I would be surprised if many other languages did as you suggest.
- djur 3y agoPython, Ruby, Perl. Languages where hashmaps are a builtin.
- vrnvu 3y agoWhile I agree with using libraries and not reinventing the wheel, we should not ignore the fact that the latest sorting algorithms introduced in Go, C, CPP, and Rust, if I’m not mistaken, were introduced between 2020 and 2022. New algorithms and data structures are refined almost every year to adapt to new hardware and specifications. A good engineer must understand the hardware, the data, and the algorithm.
- mythhabit 3y agoAnd 99.999% of all SDE do not need to implement these algorithms. Or ever understand them. And those that do, should seek that knowledge of their specific circumstance when the need arises.
- vrnvu 3y ago99.999% of all SWE don’t know that algorithms and data structures evolve. How can you they choose the right library? That was my point.
- mythhabit 3y agoThey know (I hope), but it is completely irrelevant for the vast majority of work they do. And if it becomes relevant with the use of profiling, they can dive down in the details.
- qsort 3y agoIf they come in a library or as part of the language, that's an even better reason why you should understand how they work. If you live in a world where a line of code assigns a variable or dereferences a pointer or emits adds and imuls, you can probably get what's happening just looking at the code. If each line of code manipulates complex structures, sends queries to the database, interfaces with the network etc, you'd better know what you're doing and you'd better know it well.
- jmaker 3y agoDepends strongly on how you define “know”-in that context I perceive it as referring to having or gaining some basic conceptual comprehension of the concept or algorithm, particularly in order to eschew reinventing the wheel in a squared shape, and thereby unnecessarily exhibiting exponential complexity. It also depends on your field of work. “Knowing” of them would tell one where to look and how to think.
- nazgul17 3y agoI think for anything more complicated than (maybe) sorting, appreciating the subtleties in these algorithms goes a long way in helping you decide when to use them vs not.
- elric 3y agoI don't think anyone is suggesting that every programmer implements their own list every time they use a list. But it's useful to have an understanding of how common data structures work, how basic algorithms operate, and what kind of things are out there. Writing software is much easier when you know that things like B-Trees exist or how breadth-first search works. How do you know where to find things like this in your library if you don't even know they exist?
- LabMechanic 3y agoYep, following rules like "never ever use goto" or "use design patterns and OOP everywhere" makes no sense, if (typical) software development itself is not exact. Some folks mix up software development with being super precise and mathematical, but it's not that exact. So do repeat yourself, if the alternative is not worthwhile. As a concrete example, I don't need to download an engine (such as Unreal/Unity) to make a retro-styled 3D game. All I need are software rendering algorithms, SDL2 and maybe Rust. That's it.
- gwbas1c 3y ago> I don't think anyone is suggesting that every programmer implements their own list every time they use a list. But it's useful to have an understanding of how common data structures work, how basic algorithms operate, and what kind of things are out there. And, when you need to optimize or handle special cases on critical paths, you may end up needing to implement these algorithms yourself. Case in point: I once lead development of a major competitor to Dropbox. We couldn't use "off the shelf" queues and lists to manage upload and downloads, because there were too many special cases. I also had to implement my own immutable collections (until a library was released and we switched to it.) But otherwise, 99% of the product used off-the-shelf list and queues under the hood.
- mehdix 3y agoIn order to consume such algorithmus in any form, one should first know whether such algorithms exist at all. Moreover they should be able to figure out which one applies to their problem best.
- lr1970 3y ago> Most programmers shouldn't be writing their own lists, hash maps, b-trees, sort algorithms, etc. Or generally reinvent wheels. Of course one should not reinvent the wheels. But understanding tricks and idioms used in these algorithms are useful elsewhere and in general helps you grow as a programmer.
- dizzydes 3y agoI figured the point was learning a mental model of the solution or how it was arrived at, so this can be reused as a template for different problems. As an aside, for non-programming mental models I found the Personal MBA by Josh Kaufman to be fantastic. Its title and marketing cheapen it a bit but the content is on point, extracting the best reusable patterns from graduate business education.
- vmfunction 3y agoLikewise, most algorithms and data structures is to give the developer an idea how expensive it is to run. And these are often the things that people who studied CS has an edge over the self-taught ppl. However, I have too not written those things since college a long time ago.
- volleygman180 3y agoUnderstanding time & space complexity is tablestakes for many software engineer roles. It sounds naive to think that self-taught ppl would lack that knowledge
- Arainach 3y agoOne person's "naive" is another's "statistical conclusion after having worked with enough self-taught or bootcamp-educated people". There are some good self-taught devs and a select few bootcamp-educated devs in the same sense that there are a few unwarped 2x4s available at your local Home Depot - the fact that the exceptions exist does not disprove that the majority are not worth your time.
- layer8 3y agoThat’s why the title is “should know”, and not “should reimplement by themselves for production use all the time”. As the book description says, “This book will help you not only to develop the skills to select and use an algorithm to tackle problems in the real world but also to understand how it works.” Note “select”, “use”, and “understand”, not “write“.
- foofie 3y agoHonest question: what's the point of knowing trivia on data structures and algorithms if you will never implement those or even be aware you're using them or not? In the real world you pick containers based on their traits, and you aren't bothered about how they're implemented under the hood.
- layer8 3y agoIt helps to make informed decisions, for example regarding memory locality, and it helps when they don’t perform as expected or required. It’s also difficult to get a good understanding of the properties of algorithms and data structures if you’ve never looked at how they are implemented under the hood. Learning how algorithms and data structures are implemented is probably the best way to learn the general principles. And then there’s also some algorithms, like for example topological sorting, that are typically implemented as part of application-specific code, not by use of an existing stock implementation. When you know nothing about implementations, you might not notice that the code you’re writing happens to actually be an instance of a well-known algorithm or data structure.
- chuckadams 3y agoI wouldn’t classify it as trivia to know the big-O complexity of an algorithm or to have some idea of the worst-case behaviors you may run into (like inserting already sorted data into a binary tree). You don’t need to memorize the source code, but you should at least be able to visualize the boxes and arrows in your head. That said, this particular book is an expensive way to line your birdcage, and it should be an O(1) decision to reject it. Shame that ORA put their name on this trash.
- blantonl 3y agoI'm going to somewhat agree with your assertion, because I'm one of those developers that builds my business by simply plugging what are essentially legos together and googling stackoverflow solutions to my architecture problems. However, a small anecdote. I recently obtained my pilots license, and one of the things you'll quickly learn in aviation is that there is a massive amount of information that you are required to learn that you will almost certainly never need, except possibly for that one moment in 1000 hours of flying when something happens in the air, and you simply can't pull over to the side of the road. Developers who have an understanding of the how -and- why when they are required to solve a problem vs just plugging a library in will have a much better career developing solutions and leading teams that do exceptional work. Back to my anecdote about aviation, understanding the "how -and- why" could mean life or death.
- foofie 3y ago> (...) there is a massive amount of information that you are required to learn that you will almost certainly never need, except possibly for that one moment in 1000 hours of flying when something happens in the air, (...) I don't think this logic applies to software development in general and algorithms in particular. When you need to roll out a b-tree from scratch, just crack open a book and read up. The worst thing it can happen is that somr acceptance test fails and you roll back a change. That is hardly a life-or-death scenario. The word "soft" in "software" has meaning.
- thruway516 3y agoGp's point is about how there are many things worth learning even if you can't immediately see how they will be useful, and not about urgency or timing. Sure you can pick up a book and learn about b-trees if you have to but you might not even know that a b-tree is what you need in a particular problem if you never learnt it in the first place. Most algorithmic problems in the wild don't present themselves cleanly with a signpost saying 'this is an X algorithm problem'
- andsoitis 3y ago> When you need to roll out a b-tree from scratch, just crack open a book and read up. How would you know you need to use (or implement) a B-Tree in your solution VS some other data structure?
- wmeredith 3y agoEven if you’re not trying to reinvent them, understanding how wheels work is useful.
- synergy20 3y agoyou must be able to code them manually for new jobs,leetcode style,though
- brightball 3y agoStill good to know how they work. Helps with mental modeling. “Reinventing wheels is how we get better wheels.” - Source Unknown
- hintymad 3y ago> Most of those you'd consume in library form It seems having great libraries is both a blessing and a curse to software engineers. On one hand, we get to build increasingly more powerful systems with these libraries without being bogged down by re-inventing the wheels -- some of which are nearly impossible to implement anyway, such as BLAS. On the other hand, it seems a waste of time to spend years studying the fundamental algorithms and data structures -- or in a narrow view our CS background is not necessarily a moat for us nor a foundation for us to build our expertise on. Of course, a lucky or talented few can build their careers on deepening their CS background, but many of us end up spending majority of time integrating various libraries and systes.