6 ms·

Honest 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 no

by foofie 3y ago

Honest 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 ago
It 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 ago
I 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.
- foofie 3y ago
  > I 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). It's trivia, and more often than not it's completely useless trivia. Big-O complexity refers to asymptotic complexity which is only theoretically met with very large datasets which are already in the realm of a RDBMS. Until that point, performance is far more sensitive to cache locality and other implementation details. This means that all those trivia numbers don't even match with real world data you get from your own performance tests. So what's the point of wasting time memorizing trivia that doesn't even match real-world observations?
  - vlovich123 3y ago
    Big-o of various data structures is typically trivia not worth remembering but it’s also easy to remember for the most common data structures. For all the other data structure operations it up. But there’s a lot more to data structures than big-O and implementing it yourself is one way to expose yourself to those details (eg cache locality or other things). Crossing abstraction layers requires an understanding of what’s above and below an abstraction. It’s not trivial to have that knowledge and know how to apply it effectively. It also is not relegated to RDBMS. It can come up when dealing with as few as 1M elements. For example, look up the Rockstar long loading time bug that applied an n^2 algorithm accidentally to something like a few thousand or hundred thousand elements. But you seem to be pretty into the ignorance is a virtue mantra so not sure there’s any point in engaging further.
    - edgyquant 3y ago
      Big O notation is a description of algorithmic complexity, not “data structures” and it definitely isn’t trivia. One of the two biggest pain points I’ve dealt with with new devs (even experienced ones) is that they ignore time complexity and write god awful slow code. (The other is adding network requests, eg database calls, in loops)
      - randomdata 3y ago
        No, it is definitely trivia. You can just as easily look it up on an as-needed basis. Whether or not developers choose to observe time complexity is orthogonal.
        edgyquant 3y ago
        Look up what? If I ask a dev the time complexity of a function they’ve just written, what are you expecting them to lookup? They should be able to tell me on the spot and we can discuss if it’s optimal
        3y ago
bbor 3y ago
A much shorter, less amazing answer: it’s hard to know what you don’t know! This sort of background knowledge is exactly what big tech claims to look for in applicants, because it comes up in tiny little ways at unexpected times.
yes_man 3y ago
Whatever you work in, chances are you run into situations where you need to choose between multiple solutions, optimize things or generally find out why things aren’t optimal. Your needs are always your needs, and if you are informed about how different tradeoffs compare, it helps to understand how they work. To keep things more substantial, consider facing issues storing data at your company. Maybe the nature of your data flow causes constant slowness, because your B-Tree indices are being constantly rebalanced on writes. You knew this because you understand how B-Trees work and you also know LSM trees might be a better data structure for your needs. And so what I mean is that understanding the big blocks you use in high level often requires understanding data structures and algorithms, even though you don’t need to implement them
alkonaut 3y ago
I think implementing some data structures like hash tables, lists and trees is the best way to get a feel for when one is suitable and what their traits actually are apart from just “has O(1) insert”. You can accomplish the same by lots of use, benchmarking, studying their source code etc too. But implementing at least to me is the quick and fun way of developing this gut feeling. It’s also not that rare to suddenly have the need to implement something you’d usually find in a library because you need some unique variation of an algorithm/data structure. Whether this is truly fun I guess depends on where you are on the developer spectrum. I’d much rather develop low level libraries than app code so any chance I get is just a great opportunity to dig into the low level stuff.
- deleted 3y ago
  [deleted]
RHSeeger 3y ago
As a concrete example, it sometimes happens that I'm working on existing code trying to make it faster, because it just isn't up to it's task at the moment. Looking over the code, I can see that it has some code that does a LOT of lookups to see if something is in a collection. And I can see that the collection is using a linked list; which is horrible for lookups. This is something I can notice just browsing through the code because I _already_ know the implementation (and performance) details of a linked list. At this point, I can take a look at the rest of the code and see if there's some specific reason a linked list was chosen, or if it was just that the developer didn't put much thought into it. If there is a reason (order matters, etc), I can consider what other structures might _also_ suit that need, but also give faster lookups. And, because I know of a variety of data structures, how they're implemented, and what their characteristics are; coming up with some initial choices (or starting points) happens fairly rapidly. So yes, I could get all this done without knowing all that information. But it happens a LOT faster because I know it. I notice the issue faster. I have some starting points for options faster. Etc. Not having that information would not prevent me from doing my job. But having that information makes me _better_ at my job. Faster, more efficient, safer, etc.
- stinos 3y ago
  I came across concrete examples like this before, and solved them, so here's a slightly different take: I'm principally an engineer. In general it doesn't even matter what topic though obviously there are some which I know a lot more about because of experience. Programming is one of them. I don't have a CS degree, I've seen terms like b-tree a ton of times but couldn't even begin to explain what it is, you get the point. Now: the way I approach an example like this is similar to what you do, but the difference is that I'm merely aware there's a bunch of different containers out there which behave in different ways wrt lookup/add/remove/... and for the vast majority of them I have no clue about the implementation. I don't need such implementation knowledge to realize that another container might be the trick here. I also don't really need that knowledge to decide which container that eventually might be, nor to come to conlusions fast (since you're stressing that): that's a couple of minutes to lookup moreover the final decision stage will be through performance testing anyway, because measuring under actual usage is the only way I'll ever be convinced one is effectively better than the other. That's usually what is going to take time, not picking one out of x. In the extreme it might even be so that I'd first need to write a wrapper to then have a configurable container type just to be able to have people test it under different workload types, etc. Obviously I've been through this a couple of times and by doing so did become aware of main traits of various containers/algorithms/... and yes that will be somewhat faster in the decision process. Likewise there have been certain domains in which I did dig down all the way to the very bottom and obviously having to sort out problems in that domain will be faster for me. But in the end: for me personally 'x algorithms programmers should know' is useless. Job-dependent perhaps, on the other hand I've seen enough people struggle to come up with actual and practically useful software aspects exactly because they kept on getting lost in implementation details.
bazoom42 3y ago
It is much easier to remember the traits of data structures if you know how they are implemented.
- sidlls 3y ago
  Not really. There are two key traits one needs to memorize for general purpose programming: time and space complexity. Literally a “cheat sheet” with a list of order notations is sufficient to memorize.
  - vlovich123 3y ago
    Just because they are general and are relevant to almost every problem, doesn’t mean there aren’t traits you need to be aware of that might be relevant to your problem. It’s like the Microsoft Word problem. 10% of functionality is used by everyone (eg saving a file, opening a file, changing the font). Those are baseline “everyone should know this”. The remaining 90% is still valuable and used by distinct subsets of customers. If Microsoft started deprecating the long tail of features without careful cohort analysis they’d start losing swathes of customers. So for the most common operations of the most common structures I’d expect memorization of complexities just because of repetition of use (or deriving/guessing it from first principles cause it’s easy for the most common ones). But there’s much more traits and it would be important to understand that (eg what are the primary drivers of CPU time when accessing a hash map? An array? A linked list?).
    - sidlls 3y ago
      What you describe are relatively niche or uncommon uses of these algorithms and data structures. Further, the specific implementation details of a given algorithm become relevant in these contexts. Different implementations of a hashtable can lead to substantially different operational performance, and no textbook understanding (including the toy implementations performed as part of a CS curriculum, for example) of what a hashtable is will lead to the kind of understanding you discuss.
      - 3y ago
novagameco 3y ago
I think in C++ it can help to know how they're implemented under the hood just to be aware of when it's allocating heap memory
kolinko 3y ago
If you don't understand how they work, you may end up choosing a wrong container for the job (e.g. a list instead of a dictionary), and you will be tied to finding modules that do a specific job in a case when it would be trivial to just write something yourself. In many cases it will be impossible for you to write certain parts of code, or you will end up mashing random libraries together, ending up with a program that works 1000x too slow, instead of just writing a few lines of code that solves the issue. This is especially true for graphs/BFS/DFS and binary trees/search algorithms. Also, without training your understanding of basic algorithms, you may be unable to write a lots of code that goes beyond wrapping over basic libraries. Not to mention being able to write the libraries themselves.
deleted 3y ago
[deleted]
nonameiguess 3y ago
I think you're asking a far more general question than you realize about things like professional standards, bodies of knowledge, what is or should be considered canon or foundational, how a curriculum should be constructed, how training programs should work, whether or not specific careers should require licenses, how they should be given. This doesn't apply only to software developers. If you're going to end up being a vascular surgeon, do you really need to know or understand anything about physics and chemistry? Does a contract lawyer need to know anything about legal theory or criminal law? Should a prison warden study ethics and social theory? Should a homebuilder learn about materials science and Newtonian static dynamics? A skyscraper builder? A bridge builder? Where exactly lies the divide between researcher and implementer? Engineer and hacker? Engineer and technician? Technician and hobbyist? Should someone who is good enough to make something themselves that basically works on the happy path be allowed to advertise and sell what they create to others? Should that practice be regulated at all and, if so, how? Most professions have better, widely-agreed upon answers to these questions than software development because they have existed for longer. I would personally say there is definitely no answer to "what should all programmers know" other than at least one programming language along with its associated tooling and enough about a platform software can run on to deploy it. Beyond that, across the full spectrum of software lifecycle careers, I'd say we've started converging on somewhat of a hodgepodge depending on role and where the standards are coming from. IT technician type careers have various certifications coming from platform providers like Cisco, Redhat, and Microsoft, and industry groups like CompTIA. Corporate security gets things like CISSP. If you go to a university, majors in computer science will give you what we expect academics in the subject to know before they can run labs or teach, and software engineering majors some idea what we might expect team leaders in large software organizations to know about how more general engineering principles and practices get applied specifically to software. These tend to have a lot of commonality in terms of at least being familiar with the basics of operating systems and networking, information security, discrete math, data structures and algorithms, programming language paradigms and constructs, possibly some bit of how compilers and maybe processors work. Then you get what large and well-known employers expect implicitly from their interview and promotion processes. This seems to have also converged largely on at least including basic common programming language constructs, data structures and algorithms, and possibly some minutiae related to specific languages, toolchains, platforms, ecosystems, and possibly larger principles related to things like distributed systems, databases, how the Internet and web work, depending on the nature of the major product lines. No single person needs to know all of that, but if you do, you're probably reasonably well-prepared to understand the hows and whys of any well-known or largely-used software system. It definitely doesn't mean your daily life as a developer will ever involve directly using that knowledge any more than a practicing psychiatrist remembers and can recite the exact details of the Krebs cycle. But having to learn it still might help guard a bit against susceptibility to bullshit quackery from drugmakers trying to tell them a miracle cure can do something that is metabolically impossible.
yolo3000 3y ago
People will come up with their reasons, but the thing is that even if you do learn these algos once in your life, and implement all these structures, unless you use them often, you'll very likely forget them. I did a lot of them 20 years ago, but completely forgot.
vlovich123 3y ago
Depends on what you want to work on. But if you’re picking data structures without understanding the implementation details, then you’re not grokking the decision but instead comparing traits you happen to know about and ignoring the ones that aren’t explicitly thought to be called out. Basically the trait everyone things about is O(1) or not. But the design space for data structures is vast and CPUs they run on complex. Heck, sometimes the available abstractions are readily available just because it provides a simple general propose API that we’ve iterated in through trial and error over a long time. That doesn’t mean that design is actually optimal for your problem. Now in many problems you might not care. But there are definitely problems where you do start to care. All your answer is saying “I work at a very high level of abstraction” which is fine for you but there is real value in being able to cut through layers of abstraction (performance, bug hunting etc) and discarding that as trivia is myopic. It may not be valuable to you but it is valuable knowledge I’ve used countless times in my career. Think about ECS in games - that requires a knowledge of data structure that transcends big-O trait comparison to exploit CPU architecture for drastically better efficiency. You might ignore memory allocations but the under the hood allocations can be important in some cases to make sure they play friendly. Or understanding cache impact and why using a linked list may not be a great idea. Or when sorting+searching may make more sense than just searching. The more you know the better able you are to make effective decisions and people who work strictly in abstractions tend to be limited in their ability to solve problems that cross abstractions.
gwbas1c 3y ago
> 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? Because: 1: Sometimes you need to choose the algorithm, even if it's implemented for you. (Many languages provide many different kinds of collection types, varying on some small details that appear unimportant, until they are very important to your specific need or use case.) 2: Sometimes knowing details of the algorithm helps you avoid edge cases and other inefficient behavior. 3: Sometimes if you know the algorithm exists, you know what kind of library to search for, instead of reinventing the wheel.

by foofie 3y ago

layer8 3y ago

It 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 ago

I 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.

foofie 3y ago
> I 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). It's trivia, and more often than not it's completely useless trivia. Big-O complexity refers to asymptotic complexity which is only theoretically met with very large datasets which are already in the realm of a RDBMS. Until that point, performance is far more sensitive to cache locality and other implementation details. This means that all those trivia numbers don't even match with real world data you get from your own performance tests. So what's the point of wasting time memorizing trivia that doesn't even match real-world observations?
- vlovich123 3y ago
  Big-o of various data structures is typically trivia not worth remembering but it’s also easy to remember for the most common data structures. For all the other data structure operations it up. But there’s a lot more to data structures than big-O and implementing it yourself is one way to expose yourself to those details (eg cache locality or other things). Crossing abstraction layers requires an understanding of what’s above and below an abstraction. It’s not trivial to have that knowledge and know how to apply it effectively. It also is not relegated to RDBMS. It can come up when dealing with as few as 1M elements. For example, look up the Rockstar long loading time bug that applied an n^2 algorithm accidentally to something like a few thousand or hundred thousand elements. But you seem to be pretty into the ignorance is a virtue mantra so not sure there’s any point in engaging further.
  - edgyquant 3y ago
    Big O notation is a description of algorithmic complexity, not “data structures” and it definitely isn’t trivia. One of the two biggest pain points I’ve dealt with with new devs (even experienced ones) is that they ignore time complexity and write god awful slow code. (The other is adding network requests, eg database calls, in loops)
    - randomdata 3y ago
      No, it is definitely trivia. You can just as easily look it up on an as-needed basis. Whether or not developers choose to observe time complexity is orthogonal.
      - edgyquant 3y ago
        Look up what? If I ask a dev the time complexity of a function they’ve just written, what are you expecting them to lookup? They should be able to tell me on the spot and we can discuss if it’s optimal
        3y ago

bbor 3y ago

A much shorter, less amazing answer: it’s hard to know what you don’t know! This sort of background knowledge is exactly what big tech claims to look for in applicants, because it comes up in tiny little ways at unexpected times.

yes_man 3y ago

Whatever you work in, chances are you run into situations where you need to choose between multiple solutions, optimize things or generally find out why things aren’t optimal. Your needs are always your needs, and if you are informed about how different tradeoffs compare, it helps to understand how they work. To keep things more substantial, consider facing issues storing data at your company. Maybe the nature of your data flow causes constant slowness, because your B-Tree indices are being constantly rebalanced on writes. You knew this because you understand how B-Trees work and you also know LSM trees might be a better data structure for your needs. And so what I mean is that understanding the big blocks you use in high level often requires understanding data structures and algorithms, even though you don’t need to implement them

alkonaut 3y ago

I think implementing some data structures like hash tables, lists and trees is the best way to get a feel for when one is suitable and what their traits actually are apart from just “has O(1) insert”. You can accomplish the same by lots of use, benchmarking, studying their source code etc too. But implementing at least to me is the quick and fun way of developing this gut feeling. It’s also not that rare to suddenly have the need to implement something you’d usually find in a library because you need some unique variation of an algorithm/data structure. Whether this is truly fun I guess depends on where you are on the developer spectrum. I’d much rather develop low level libraries than app code so any chance I get is just a great opportunity to dig into the low level stuff.

deleted 3y ago
[deleted]

RHSeeger 3y ago

As a concrete example, it sometimes happens that I'm working on existing code trying to make it faster, because it just isn't up to it's task at the moment. Looking over the code, I can see that it has some code that does a LOT of lookups to see if something is in a collection. And I can see that the collection is using a linked list; which is horrible for lookups. This is something I can notice just browsing through the code because I _already_ know the implementation (and performance) details of a linked list. At this point, I can take a look at the rest of the code and see if there's some specific reason a linked list was chosen, or if it was just that the developer didn't put much thought into it. If there is a reason (order matters, etc), I can consider what other structures might _also_ suit that need, but also give faster lookups. And, because I know of a variety of data structures, how they're implemented, and what their characteristics are; coming up with some initial choices (or starting points) happens fairly rapidly. So yes, I could get all this done without knowing all that information. But it happens a LOT faster because I know it. I notice the issue faster. I have some starting points for options faster. Etc. Not having that information would not prevent me from doing my job. But having that information makes me _better_ at my job. Faster, more efficient, safer, etc.

stinos 3y ago
I came across concrete examples like this before, and solved them, so here's a slightly different take: I'm principally an engineer. In general it doesn't even matter what topic though obviously there are some which I know a lot more about because of experience. Programming is one of them. I don't have a CS degree, I've seen terms like b-tree a ton of times but couldn't even begin to explain what it is, you get the point. Now: the way I approach an example like this is similar to what you do, but the difference is that I'm merely aware there's a bunch of different containers out there which behave in different ways wrt lookup/add/remove/... and for the vast majority of them I have no clue about the implementation. I don't need such implementation knowledge to realize that another container might be the trick here. I also don't really need that knowledge to decide which container that eventually might be, nor to come to conlusions fast (since you're stressing that): that's a couple of minutes to lookup moreover the final decision stage will be through performance testing anyway, because measuring under actual usage is the only way I'll ever be convinced one is effectively better than the other. That's usually what is going to take time, not picking one out of x. In the extreme it might even be so that I'd first need to write a wrapper to then have a configurable container type just to be able to have people test it under different workload types, etc. Obviously I've been through this a couple of times and by doing so did become aware of main traits of various containers/algorithms/... and yes that will be somewhat faster in the decision process. Likewise there have been certain domains in which I did dig down all the way to the very bottom and obviously having to sort out problems in that domain will be faster for me. But in the end: for me personally 'x algorithms programmers should know' is useless. Job-dependent perhaps, on the other hand I've seen enough people struggle to come up with actual and practically useful software aspects exactly because they kept on getting lost in implementation details.

bazoom42 3y ago

It is much easier to remember the traits of data structures if you know how they are implemented.

sidlls 3y ago
Not really. There are two key traits one needs to memorize for general purpose programming: time and space complexity. Literally a “cheat sheet” with a list of order notations is sufficient to memorize.
- vlovich123 3y ago
  Just because they are general and are relevant to almost every problem, doesn’t mean there aren’t traits you need to be aware of that might be relevant to your problem. It’s like the Microsoft Word problem. 10% of functionality is used by everyone (eg saving a file, opening a file, changing the font). Those are baseline “everyone should know this”. The remaining 90% is still valuable and used by distinct subsets of customers. If Microsoft started deprecating the long tail of features without careful cohort analysis they’d start losing swathes of customers. So for the most common operations of the most common structures I’d expect memorization of complexities just because of repetition of use (or deriving/guessing it from first principles cause it’s easy for the most common ones). But there’s much more traits and it would be important to understand that (eg what are the primary drivers of CPU time when accessing a hash map? An array? A linked list?).
  - sidlls 3y ago
    What you describe are relatively niche or uncommon uses of these algorithms and data structures. Further, the specific implementation details of a given algorithm become relevant in these contexts. Different implementations of a hashtable can lead to substantially different operational performance, and no textbook understanding (including the toy implementations performed as part of a CS curriculum, for example) of what a hashtable is will lead to the kind of understanding you discuss.
    - 3y ago

novagameco 3y ago

I think in C++ it can help to know how they're implemented under the hood just to be aware of when it's allocating heap memory

kolinko 3y ago

If you don't understand how they work, you may end up choosing a wrong container for the job (e.g. a list instead of a dictionary), and you will be tied to finding modules that do a specific job in a case when it would be trivial to just write something yourself. In many cases it will be impossible for you to write certain parts of code, or you will end up mashing random libraries together, ending up with a program that works 1000x too slow, instead of just writing a few lines of code that solves the issue. This is especially true for graphs/BFS/DFS and binary trees/search algorithms. Also, without training your understanding of basic algorithms, you may be unable to write a lots of code that goes beyond wrapping over basic libraries. Not to mention being able to write the libraries themselves.

deleted 3y ago

[deleted]

nonameiguess 3y ago

I think you're asking a far more general question than you realize about things like professional standards, bodies of knowledge, what is or should be considered canon or foundational, how a curriculum should be constructed, how training programs should work, whether or not specific careers should require licenses, how they should be given. This doesn't apply only to software developers. If you're going to end up being a vascular surgeon, do you really need to know or understand anything about physics and chemistry? Does a contract lawyer need to know anything about legal theory or criminal law? Should a prison warden study ethics and social theory? Should a homebuilder learn about materials science and Newtonian static dynamics? A skyscraper builder? A bridge builder? Where exactly lies the divide between researcher and implementer? Engineer and hacker? Engineer and technician? Technician and hobbyist? Should someone who is good enough to make something themselves that basically works on the happy path be allowed to advertise and sell what they create to others? Should that practice be regulated at all and, if so, how? Most professions have better, widely-agreed upon answers to these questions than software development because they have existed for longer. I would personally say there is definitely no answer to "what should all programmers know" other than at least one programming language along with its associated tooling and enough about a platform software can run on to deploy it. Beyond that, across the full spectrum of software lifecycle careers, I'd say we've started converging on somewhat of a hodgepodge depending on role and where the standards are coming from. IT technician type careers have various certifications coming from platform providers like Cisco, Redhat, and Microsoft, and industry groups like CompTIA. Corporate security gets things like CISSP. If you go to a university, majors in computer science will give you what we expect academics in the subject to know before they can run labs or teach, and software engineering majors some idea what we might expect team leaders in large software organizations to know about how more general engineering principles and practices get applied specifically to software. These tend to have a lot of commonality in terms of at least being familiar with the basics of operating systems and networking, information security, discrete math, data structures and algorithms, programming language paradigms and constructs, possibly some bit of how compilers and maybe processors work. Then you get what large and well-known employers expect implicitly from their interview and promotion processes. This seems to have also converged largely on at least including basic common programming language constructs, data structures and algorithms, and possibly some minutiae related to specific languages, toolchains, platforms, ecosystems, and possibly larger principles related to things like distributed systems, databases, how the Internet and web work, depending on the nature of the major product lines. No single person needs to know all of that, but if you do, you're probably reasonably well-prepared to understand the hows and whys of any well-known or largely-used software system. It definitely doesn't mean your daily life as a developer will ever involve directly using that knowledge any more than a practicing psychiatrist remembers and can recite the exact details of the Krebs cycle. But having to learn it still might help guard a bit against susceptibility to bullshit quackery from drugmakers trying to tell them a miracle cure can do something that is metabolically impossible.

yolo3000 3y ago

People will come up with their reasons, but the thing is that even if you do learn these algos once in your life, and implement all these structures, unless you use them often, you'll very likely forget them. I did a lot of them 20 years ago, but completely forgot.

vlovich123 3y ago

Depends on what you want to work on. But if you’re picking data structures without understanding the implementation details, then you’re not grokking the decision but instead comparing traits you happen to know about and ignoring the ones that aren’t explicitly thought to be called out. Basically the trait everyone things about is O(1) or not. But the design space for data structures is vast and CPUs they run on complex. Heck, sometimes the available abstractions are readily available just because it provides a simple general propose API that we’ve iterated in through trial and error over a long time. That doesn’t mean that design is actually optimal for your problem. Now in many problems you might not care. But there are definitely problems where you do start to care. All your answer is saying “I work at a very high level of abstraction” which is fine for you but there is real value in being able to cut through layers of abstraction (performance, bug hunting etc) and discarding that as trivia is myopic. It may not be valuable to you but it is valuable knowledge I’ve used countless times in my career. Think about ECS in games - that requires a knowledge of data structure that transcends big-O trait comparison to exploit CPU architecture for drastically better efficiency. You might ignore memory allocations but the under the hood allocations can be important in some cases to make sure they play friendly. Or understanding cache impact and why using a linked list may not be a great idea. Or when sorting+searching may make more sense than just searching. The more you know the better able you are to make effective decisions and people who work strictly in abstractions tend to be limited in their ability to solve problems that cross abstractions.

gwbas1c 3y ago

> 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? Because: 1: Sometimes you need to choose the algorithm, even if it's implemented for you. (Many languages provide many different kinds of collection types, varying on some small details that appear unimportant, until they are very important to your specific need or use case.) 2: Sometimes knowing details of the algorithm helps you avoid edge cases and other inefficient behavior. 3: Sometimes if you know the algorithm exists, you know what kind of library to search for, instead of reinventing the wheel.