3 ms·

This is a horrible stance and this is repeated like broken record. Please stop saying this? A good software engineer should know (1) a suitable data structure t

This is a horrible stance and this is repeated like broken record. Please stop saying this? A good software engineer should know (1) a suitable data structure to solve the problem in hand (2) algorithms that have certain asymptotic characteristic that makes most sense for the problem (what assumptions can you make). "Premature optimization is the root of all evil" can be used for and only for "optimization". Choosing the right data structure is never an optimization, it's a design choice. You can't just start coding everything with a linked list and then optimize bottlenecks, that's just not how it works.

pjmlp 8y ago
As you say "A good software engineer should know a suitable data structure to solve the problem in hand". So I expect a good software engineer on my team to be able to design a data structure where the fact that a linked list is being used doesn't hinder to change it afterwards to an array, a B-Tree or what have you. Without changing a single line of client code I might add. Such good software engineer will certainly had attended an algorithms and data structures class on their CS degree and be aware of architecture designs based on Abstract Data Types. Yes, even in C with its flaky translation units instead of proper module systems, it is possible to implement Abstract Data Types application architectures, which any good software engineer can easily tackle. And for those that aspire to reach that level, here are a few examples. "Algorithms + Data Structures = Programs" by Niklaus Wirth, 1st edition is Modula-2, the 2nd in Oberon "Introduction to Algorithms" by Thomas Cormen, Clifford Stein, Ronald Rivest, Charles Leiserson "Abstract data types and Modula-2: a worked example of design using data abstraction" by Richard Mitchell "Abstract Data Types in Modula-2" by Rachel Harrison "Abstract Data Types and Algorithms" by Azmoodeh, Manoochchr
- gnulinux 8y ago
  Your comment still doesn't make sense, even though you decided to choose a certain ADS and then latee decide on the implementation later based on empirical performance data, this is still not unusual. For (1) this is not how people write C. There are ADS libraries in C with which you wouldn't need need to use any DS that you can't change but this is not a usual way to write C code. This will also come with the overhead of pointer indirection and worse cache performance since all your objects will be void* stored in the DS (unless you m4 or macro generate your DS with all datatypes. This is what linux does for example, and I sometimes use this technique too, but this hardly the usual way to write C code). And (2) usually complex problems require special enough datastructures that it doesn't make much sense talk about ADSs. Everyone can code basic foobar with List interface then decide to use ArrayList or LinkedList based on performance. It's more interesting when the programmer decides to use a set, a hash map, a bloom filter etc to solve the problem as any other type wouldn't make sense.
  - pjmlp 8y ago
    We will have to agree to disagree, then. Sofware quality and meeting delivery SLAs should trump micro-optimizing cache access per code line. So if SLAs define 100ms per access, no need to go crazy making everything under 5ms. Thankfully, the Linux foundation has another view on the matter. https://www.youtube.com/watch?v=XfNt6MsLj0E https://www.youtube.com/watch?v=XfNt6MsLj0E

pjmlp 8y ago

As you say "A good software engineer should know a suitable data structure to solve the problem in hand". So I expect a good software engineer on my team to be able to design a data structure where the fact that a linked list is being used doesn't hinder to change it afterwards to an array, a B-Tree or what have you. Without changing a single line of client code I might add. Such good software engineer will certainly had attended an algorithms and data structures class on their CS degree and be aware of architecture designs based on Abstract Data Types. Yes, even in C with its flaky translation units instead of proper module systems, it is possible to implement Abstract Data Types application architectures, which any good software engineer can easily tackle. And for those that aspire to reach that level, here are a few examples. "Algorithms + Data Structures = Programs" by Niklaus Wirth, 1st edition is Modula-2, the 2nd in Oberon "Introduction to Algorithms" by Thomas Cormen, Clifford Stein, Ronald Rivest, Charles Leiserson "Abstract data types and Modula-2: a worked example of design using data abstraction" by Richard Mitchell "Abstract Data Types in Modula-2" by Rachel Harrison "Abstract Data Types and Algorithms" by Azmoodeh, Manoochchr

gnulinux 8y ago
Your comment still doesn't make sense, even though you decided to choose a certain ADS and then latee decide on the implementation later based on empirical performance data, this is still not unusual. For (1) this is not how people write C. There are ADS libraries in C with which you wouldn't need need to use any DS that you can't change but this is not a usual way to write C code. This will also come with the overhead of pointer indirection and worse cache performance since all your objects will be void* stored in the DS (unless you m4 or macro generate your DS with all datatypes. This is what linux does for example, and I sometimes use this technique too, but this hardly the usual way to write C code). And (2) usually complex problems require special enough datastructures that it doesn't make much sense talk about ADSs. Everyone can code basic foobar with List interface then decide to use ArrayList or LinkedList based on performance. It's more interesting when the programmer decides to use a set, a hash map, a bloom filter etc to solve the problem as any other type wouldn't make sense.
- pjmlp 8y ago
  We will have to agree to disagree, then. Sofware quality and meeting delivery SLAs should trump micro-optimizing cache access per code line. So if SLAs define 100ms per access, no need to go crazy making everything under 5ms. Thankfully, the Linux foundation has another view on the matter. https://www.youtube.com/watch?v=XfNt6MsLj0E https://www.youtube.com/watch?v=XfNt6MsLj0E