8 ms·

Computer science is not about computers; where does stuff like algorithms fit into this? What is a "true scottsman" of CS? Low level programmers? What about pe

Computer science is not about computers; where does stuff like algorithms fit into this? What is a "true scottsman" of CS? Low level programmers? What about people that have pioneered the theory of computer science? The likes of Karp, Valiant, Cook, Blum, Vazirani, Papdimitriou, Micali, Goldwasser, Goldreich, Shamir, Rivest and etc.? I doubt these people know the inner workings of computers, but they have revolutionized our view of what it means to compute. Increasingly today the underlying architecture, for most intents, is becoming irrelevant (to first order of magnitude). The biggest gains are not made from superoptimizing compilers, but from algorithmic efficiency. That doesn't figure anywhere in your curriculum. I think your curriculum would be great as an intro to computer architecture, or even as a series covering the topic, but I don't think it's an adequate introduction to computer science.

gravypod 10y ago
Theory is useless without implementation and implementation is nothing without an understanding of theory. Implementation and theory are in lockstep but by learning theory you will not necessarily know how to implement, or even really understand, the topics you have memorized. On the other hand it is necessitated by the concept of implementation that you on one hand understand the tools you are using to solve this problem and on the other have reached a point where you see why the tool is used. You can sit a person in front of a whiteboard all you want. Brainwash them about arrays, maps, matricies, trees and graphs and they have a high likely hood of coming out knowing nothing but verbatum what you have told them. Conversly you cannot sit a person in front of a computer, guide them through the exercises that I described, and expect the same as the student who once sat in front of the whiteboard. Trees grow from seeds and the best way to plant these seeds are not with an expo marker but, in my opinion, by bringing the student to a crossroads where they need to discover a concept on their own. This is a common tactic in game design: allow the player to discover new rules after you've taught them the basic foundation. After they understand the basic foundation of how they will be interacting with the machine I think that, with the guidance of the correct assignements in the notebook codesegment phase of the program, the student will be able to create these different routines and ideas on their own. Some such examples I will provide below: - Make some way that will allow you to find a number between two possitions in memory - Make a wrapper for this routine that will operate from a starting possition and an offset of the size - Make a way to find the distance between two points on an X, Y plane - Find a way to apply the same transformation in every item between two points in memory - Find a way to implement a way of storing data about an X, Y plane. For instance where a dot is on a section of graph paper - Make a subroutine that will allow you to store potentially infinite items in a collection. There are many ways to approch this but the three main ones are to: use a section of memory that is preallocated and reallocated when it is filled, make some way to daisy chain items of the list together possibly by wrapping them in in more data that will serve to aid your program, do the same as the daisy chain but allow the chain to coninue in more then one direction. Hint: this will probably need an init_<structure>, add_<structure>, remove_<structure>, free_<structure> This would take a long time but under the correct stimulating guidance the student will be able to seek out why they need these tools. These tasks should be presented after they've completed a project that someone in our position knows that the optimal way of solving the problem was not choosen and a more abstract and simple solution exists. These situations will present themselves often. I've possitioned myself to make these suggestions to my peers at my university who are having a very difficult time passing the classes we are in together. The people who need to see why AND how. I'll look at their work and say "how about try using X method of solving the problem and show me what you come up with" and when they come up with a solution I say "now try and make it a library. Remove it from your current solution and allow yourself to use it for further work on other projects". This changes the way they think about programing.
- keithly 10y ago
  Do you have a blog? You have some interesting ideas that would be good to explore in a longer form.
  - gravypod 10y ago
    I do it's https://blog.gravypod.com https://blog.gravypod.com but nothing interest is on it right now. I'd love to write more but I usually need a prompt on a topic that I've thought about. I try to keep my ideas to myself until I've formulated an argument for either side that is "sufficient" in my mind. I'd love to write about this in more detail and I'll definitely write about anything emailed to me if I'm able to formulate an idea either way. I'm heading home soon and write up something more detailed on this topic and why I feel this way on the topic of education.
- thethirdone 10y ago
  > Theory is useless without implementation and implementation is nothing without an understanding of theory. I feel that you greatly misunderstand why theory is important. It is not just something to be memorized to aid in implementation. It is useful and interesting in its own rite. CS Theory is Mathematics and like mathematics can be pursued simply with the goal of better understanding. An understanding of Turing Machines and computability is a good example for this. Generally knowing that there exist uncomputable functions is of little practical use as you are exceeding unlikely to encounter one in implementation. Similarly understanding turing machines well is not useful as they compute in a very different way compared to current computers. However, from a purely theoretical standpoint it is critical to know that there exist uncomputable functions. > You can sit a person in front of a whiteboard all you want. Brainwash them about arrays, maps, matricies, trees and graphs and they have a high likely hood of coming out knowing nothing but verbatum what you have told them The same could be said for teaching implementation. Thoughtless memorization is rarely useful in any field. You can instead have them discover the theory like they would discover an understanding of implementation you advise. Much of the theory of CS is not particularly hard to work out yourself if you are given the right hints. For example, an approach to teaching sorting algorithms could start by asking students to devise an algorithm to sort a list, and then have them compare algorithms and devise a way to evaluate which ones are the best and in which ways. Then after their progress slows introduce ideas like big O to help them further develop their ideas. The sorts taught in introductory algorithms classes are not very hard to understand (or design), and with the idea of big O in hand the introductory analysis in within reach of the student. However, I agree that teaching programming in general from learning the rules to interact with tyeh computer and building up abstraction is often the right path for many students. Personally, it was not a great start for me (I started with C; not exactly the lowest level, but lower than most CS courses nowadays). I would have preferred to learn more theory earlier in my learning, and that is not easy to do when you are focused only on the code and not on the ideas behind the code that are universal.
kazinator 10y ago
> Increasingly today the underlying architecture, for most intents, is becoming irrelevant ... amidst cries from a handful of lunatics who insist we shouldn't be using linked lists any more because they don't use the L1 cache very well compared to arrays.
- gravypod 10y ago
  In some contexts this optimizations make no sense. In others you'd be laughed out of the office for suggesting that you should use a linked list. You'd be shitcanned before you got back to your office. In the same sense if you're in a python shop doing web development and you say "EVERYONE we need to STOP using python and write ALL of our HTTP code in C! We'll be able to optimize the hell out of it and probably save 10K of memory per request! That's HUGE!" you would also in tern be shitcanned before you finished the sentence. If you take that same exact mentality and bring it to a company that builds realtime systems that do DSP and maybe even handle some user interaction in an embeded form facter and you say "EVERYONE! I've found that if we replace our current memory allocator with a circular buffer and pre-allocate everything in an SRAM we can get power-off tolerance AND allow ourselves to make use of all of our memory while not even needing to WASTE the cyles on freeing our memory! We'll save on the oders of 1ms over 50actions! That's a HUGE boon for our batter life!" you'd walk out the head of the office. Saving 500ns, 100 bytes, or even improving something on that scale no matter what it is in contect is huge. The problem boils down to one thing. For the embeded systems people saving 1MS may be on the oder of 20% of their runtime. For the python shop saving 10K of memory is probably on the oder of sub-00.001% of their memory usage. It is all about context. (Disclaimer: I have changed from LL to arrays in some applications because it made a measurable improvement to the speeds of my systems.)
  - qwertyuiop924 10y ago
    Yep. Totally. Also, if you're working in an HLL, know how LL is implemented in your PL. Because even in Lisp, not all LLs are created equal, and even if you create them the same way, they don't necessarily have the same perf characteristics. For instance, because Haskell, ML, and the other functional languages don't allow datastructure mutation, they can CDR-code all their lists, something Lisp does as well (which is why list literals created with QUOTE cannot be modified, IIRC). This collpses the linked list structure into something resembling an array, increasing cache response time. Additional conses will be allocated separately, but this will still increase efficiency.
peterkelly 10y ago
You need both.
- Ar-Curunir 10y ago
  I agree, and the good computer science programs take this approach.
realo 10y ago
Maybe I am too old, but from my vantage point, "Computer Science" and "Algorithmic Science" are really two entirely separate fields. Computer Science is exactly what the OP talks about: computers, CPUs, implementation details, hardware, plumbing, etc... One needs actual hardware on the table to work this out. Imperfect hardware, with latencies, clock issues, etc... THAT is true computer science, IMHO, and is very near Electrical Engineering. On the other hand, Algorithmic Science really is an applied form of mathematics. One does not actually _need_ a computer to design, understand, invent algorithms. A brain, paper and pen are enough. Those are two different sciences, and I suspect very few people are actually great (world class) in both simultaneously. It is futile to imagine that a single school curriculum would adequately form people in those two very different topics. I could add that where I work, we have in-house the two kinds of people: a couple of mathematicians for the (amazing algorithms) and a few very picky low-level programmers who actually implement the algorithms with blazing fast, hand-crafted code. The two groups would never dream of doing the other's job.
- jventura 10y ago
  > Computer Science is exactly what the OP talks about: computers, CPUs, implementation details, hardware, plumbing, etc... One needs actual hardware on the table to work this out. Imperfect hardware, with latencies, clock issues, etc... THAT is true computer science, IMHO, and is very near Electrical Engineering. It really depends on what sources you base your concepts on. I would say that, for instance, what you mention is more closely related to "computer engineering" than "computer science". For instance, in [0]: "Thus CS is closer to the underlying theory of computation, with its roots in mathematics, and CEN is closer to the design of physical devices (...) Of the three great divisions in computing, namely theory, software and hardware, to a first approximation theory goes with CS, hardware with CEN, and software with both (...)" In my country, our technical schools and most universities provide what we call "informatics engineering" (engenharia informática), which has a bit of CS (in terms of basic concepts, algorithms, abstract data types, etc.), CE (some low level electronic stuff) and Software Engineering (Programming, OOP, Web Programming, Logic/functional programming, etc.). [0] http://www.eng.buffalo.edu/undergrad/academics/degrees/cs-vs-cen http://www.eng.buffalo.edu/undergrad/academics/degrees/cs-vs...
- 10y ago
asimpletune 10y ago
Advances in algorithms are a fundamental starting point, but I think it's a common mistake to conflate the efficiency of an algorithm in the abstract sense to how those benefits are manifested in the applied sense. While true, all things held equal a new algorithm will advance the field, providing "gains" as you said, but it's false to assume that algorithms are more important than understand computer architecture, full stop. A simple example is dijkstra's algorithm vs bellman ford. Sure, in the abstract sense, the greed algorithm wins. However, it would be wrong to assume that dijkstra's algorithm is faster than bellman ford, because it's not. That's because dijkastra's algorithm doesn't parallelize as well, where as bellman ford parallelizes very well (and by "well" I mean it exploits the architecture - in a sense has "mechanical sympathy"). You end up creating very exotic data structures that are good for caching and stealing work from unused threads. There are many other examples, check out matrix matrix multiplication if your interested. I'm not making the argument that one is more important than the other, but I think it's a bit reductive to say algorithm only matter because there are so many examples of where computer architecture matters more (and vice versa). Another way to say what I mean is that ultimately reality matters. > The likes of Karp, Valiant, Cook, Blum, Vazirani, Papdimitriou, Micali, Goldwasser, Goldreich, Shamir, Rivest and etc.? I doubt these people know the inner workings of computers, but they have revolutionized our view of what it means to compute. Um, why would you think that they don't understand the inner workings of computers? Is that just your intuition or is that based on some practical knowledge? I'm not saying I know the answer (I haven't quizzed them), but since we're guessing here I'm going to say that they probably know a lot about the inner workings of computer - and there's no harm in us mortals trying to do the same. They probably don't know like specific things about how intel's branch prediction works or anything like that, but as a general concept, the inner workings of computers is pretty fundamental stuff and is very helpful to know, along with algorithms.
- gravypod 10y ago
  >common mistake to conflate the efficiency of an algorithm in the abstract sense to how those benefits are manifested in the applied sense > While true, all things held equal a new algorithm will advance the field, providing "gains" as you said > but it's false to assume that algorithms are more important than understand computer architecture, full stop I wish there were two like buttons. I have nothing to add that you haven't said better then I could have.
wfunction 10y ago
> What about people that have pioneered the theory of computer science? The likes of Karp, Valiant, Cook, Blum, Vazirani, Papdimitriou, Micali, Goldwasser, Goldreich, Shamir, Rivest and etc.? > I doubt these people know the inner workings of computers ...wha...? This is so ridiculous of a claim that I can't even think of how to respond...
- joatmon-snoo 10y ago
  >> I doubt these people know the inner workings of computers > ...wha...? This is so ridiculous of a claim that I can't even think of how to respond... GP probably means that while these pioneers might be aware of, might have tinkered with the nuances of processor design and syscalls and nitty-gritty details of TLB's and interrupts and stuff that, say, a kernel-level or SSD firmware guy might deal with regularly, it's highly unlikely that they would know their way around these like they know their way around the algorithms that they deal with on a regular basis, which exist at a much higher level of abstraction. Take everything with a grain of salt.
  - wfunction 10y ago
    > GP probably means that while these pioneers might be aware of, might have tinkered with the nuances of processor design and syscalls and nitty-gritty details of TLB's and interrupts and stuff that, say, a kernel-level or SSD firmware guy might deal with regularly, it's highly unlikely that they would know their way around these like they know their way around the algorithms that they deal with on a regular basis, which exist at a much higher level of abstraction. I think you missed my point. What I'm saying is there's a world of difference between "X knows B better than A" and "X doesn't know A [very well]". When you're talking about world-class experts who are at the forefront of research in their fields, if you work in the same discipline, there's a pretty damn good chance they're more of an expert at your work area than you are. (I'm obviously assuming "you" here are not the world-class expert in your area. "You" are just a generic but respectable engineer in your area of work.) I think what you (& the OP) need to realize is that there's a HUGE and crucial difference between being, say, "rusty" on something (e.g. because you're not doing it on a day-to-day basis, or because it's someone else's system and obviously you can't magically know how it was designed a priori), and not having enough prior expertise such that your ramp-up time would be low enough to be negligible, should you ever need to touch that thing at some point. You need to realize, these folks have done so much work that they even get rusty on their own research topics after a few years. That doesn't mean they stop being experts on their topics. On top of that, they still keep up with their colleagues' research in other related areas... which, mind you, are likely to be more advanced than what you're doing. Chances are if they spent a day or two reviewing other stuff, they'd be as good (or even better) experts on them than they were originally, quite likely better than you (again, generic "you" here, as above).

gravypod 10y ago

Theory is useless without implementation and implementation is nothing without an understanding of theory. Implementation and theory are in lockstep but by learning theory you will not necessarily know how to implement, or even really understand, the topics you have memorized. On the other hand it is necessitated by the concept of implementation that you on one hand understand the tools you are using to solve this problem and on the other have reached a point where you see why the tool is used. You can sit a person in front of a whiteboard all you want. Brainwash them about arrays, maps, matricies, trees and graphs and they have a high likely hood of coming out knowing nothing but verbatum what you have told them. Conversly you cannot sit a person in front of a computer, guide them through the exercises that I described, and expect the same as the student who once sat in front of the whiteboard. Trees grow from seeds and the best way to plant these seeds are not with an expo marker but, in my opinion, by bringing the student to a crossroads where they need to discover a concept on their own. This is a common tactic in game design: allow the player to discover new rules after you've taught them the basic foundation. After they understand the basic foundation of how they will be interacting with the machine I think that, with the guidance of the correct assignements in the notebook codesegment phase of the program, the student will be able to create these different routines and ideas on their own. Some such examples I will provide below: - Make some way that will allow you to find a number between two possitions in memory - Make a wrapper for this routine that will operate from a starting possition and an offset of the size - Make a way to find the distance between two points on an X, Y plane - Find a way to apply the same transformation in every item between two points in memory - Find a way to implement a way of storing data about an X, Y plane. For instance where a dot is on a section of graph paper - Make a subroutine that will allow you to store potentially infinite items in a collection. There are many ways to approch this but the three main ones are to: use a section of memory that is preallocated and reallocated when it is filled, make some way to daisy chain items of the list together possibly by wrapping them in in more data that will serve to aid your program, do the same as the daisy chain but allow the chain to coninue in more then one direction. Hint: this will probably need an init_<structure>, add_<structure>, remove_<structure>, free_<structure> This would take a long time but under the correct stimulating guidance the student will be able to seek out why they need these tools. These tasks should be presented after they've completed a project that someone in our position knows that the optimal way of solving the problem was not choosen and a more abstract and simple solution exists. These situations will present themselves often. I've possitioned myself to make these suggestions to my peers at my university who are having a very difficult time passing the classes we are in together. The people who need to see why AND how. I'll look at their work and say "how about try using X method of solving the problem and show me what you come up with" and when they come up with a solution I say "now try and make it a library. Remove it from your current solution and allow yourself to use it for further work on other projects". This changes the way they think about programing.

keithly 10y ago
Do you have a blog? You have some interesting ideas that would be good to explore in a longer form.
- gravypod 10y ago
  I do it's https://blog.gravypod.com https://blog.gravypod.com but nothing interest is on it right now. I'd love to write more but I usually need a prompt on a topic that I've thought about. I try to keep my ideas to myself until I've formulated an argument for either side that is "sufficient" in my mind. I'd love to write about this in more detail and I'll definitely write about anything emailed to me if I'm able to formulate an idea either way. I'm heading home soon and write up something more detailed on this topic and why I feel this way on the topic of education.
thethirdone 10y ago
> Theory is useless without implementation and implementation is nothing without an understanding of theory. I feel that you greatly misunderstand why theory is important. It is not just something to be memorized to aid in implementation. It is useful and interesting in its own rite. CS Theory is Mathematics and like mathematics can be pursued simply with the goal of better understanding. An understanding of Turing Machines and computability is a good example for this. Generally knowing that there exist uncomputable functions is of little practical use as you are exceeding unlikely to encounter one in implementation. Similarly understanding turing machines well is not useful as they compute in a very different way compared to current computers. However, from a purely theoretical standpoint it is critical to know that there exist uncomputable functions. > You can sit a person in front of a whiteboard all you want. Brainwash them about arrays, maps, matricies, trees and graphs and they have a high likely hood of coming out knowing nothing but verbatum what you have told them The same could be said for teaching implementation. Thoughtless memorization is rarely useful in any field. You can instead have them discover the theory like they would discover an understanding of implementation you advise. Much of the theory of CS is not particularly hard to work out yourself if you are given the right hints. For example, an approach to teaching sorting algorithms could start by asking students to devise an algorithm to sort a list, and then have them compare algorithms and devise a way to evaluate which ones are the best and in which ways. Then after their progress slows introduce ideas like big O to help them further develop their ideas. The sorts taught in introductory algorithms classes are not very hard to understand (or design), and with the idea of big O in hand the introductory analysis in within reach of the student. However, I agree that teaching programming in general from learning the rules to interact with tyeh computer and building up abstraction is often the right path for many students. Personally, it was not a great start for me (I started with C; not exactly the lowest level, but lower than most CS courses nowadays). I would have preferred to learn more theory earlier in my learning, and that is not easy to do when you are focused only on the code and not on the ideas behind the code that are universal.

kazinator 10y ago

> Increasingly today the underlying architecture, for most intents, is becoming irrelevant ... amidst cries from a handful of lunatics who insist we shouldn't be using linked lists any more because they don't use the L1 cache very well compared to arrays.

gravypod 10y ago
In some contexts this optimizations make no sense. In others you'd be laughed out of the office for suggesting that you should use a linked list. You'd be shitcanned before you got back to your office. In the same sense if you're in a python shop doing web development and you say "EVERYONE we need to STOP using python and write ALL of our HTTP code in C! We'll be able to optimize the hell out of it and probably save 10K of memory per request! That's HUGE!" you would also in tern be shitcanned before you finished the sentence. If you take that same exact mentality and bring it to a company that builds realtime systems that do DSP and maybe even handle some user interaction in an embeded form facter and you say "EVERYONE! I've found that if we replace our current memory allocator with a circular buffer and pre-allocate everything in an SRAM we can get power-off tolerance AND allow ourselves to make use of all of our memory while not even needing to WASTE the cyles on freeing our memory! We'll save on the oders of 1ms over 50actions! That's a HUGE boon for our batter life!" you'd walk out the head of the office. Saving 500ns, 100 bytes, or even improving something on that scale no matter what it is in contect is huge. The problem boils down to one thing. For the embeded systems people saving 1MS may be on the oder of 20% of their runtime. For the python shop saving 10K of memory is probably on the oder of sub-00.001% of their memory usage. It is all about context. (Disclaimer: I have changed from LL to arrays in some applications because it made a measurable improvement to the speeds of my systems.)
- qwertyuiop924 10y ago
  Yep. Totally. Also, if you're working in an HLL, know how LL is implemented in your PL. Because even in Lisp, not all LLs are created equal, and even if you create them the same way, they don't necessarily have the same perf characteristics. For instance, because Haskell, ML, and the other functional languages don't allow datastructure mutation, they can CDR-code all their lists, something Lisp does as well (which is why list literals created with QUOTE cannot be modified, IIRC). This collpses the linked list structure into something resembling an array, increasing cache response time. Additional conses will be allocated separately, but this will still increase efficiency.

peterkelly 10y ago

You need both.

Ar-Curunir 10y ago
I agree, and the good computer science programs take this approach.

realo 10y ago

Maybe I am too old, but from my vantage point, "Computer Science" and "Algorithmic Science" are really two entirely separate fields. Computer Science is exactly what the OP talks about: computers, CPUs, implementation details, hardware, plumbing, etc... One needs actual hardware on the table to work this out. Imperfect hardware, with latencies, clock issues, etc... THAT is true computer science, IMHO, and is very near Electrical Engineering. On the other hand, Algorithmic Science really is an applied form of mathematics. One does not actually _need_ a computer to design, understand, invent algorithms. A brain, paper and pen are enough. Those are two different sciences, and I suspect very few people are actually great (world class) in both simultaneously. It is futile to imagine that a single school curriculum would adequately form people in those two very different topics. I could add that where I work, we have in-house the two kinds of people: a couple of mathematicians for the (amazing algorithms) and a few very picky low-level programmers who actually implement the algorithms with blazing fast, hand-crafted code. The two groups would never dream of doing the other's job.

jventura 10y ago
> Computer Science is exactly what the OP talks about: computers, CPUs, implementation details, hardware, plumbing, etc... One needs actual hardware on the table to work this out. Imperfect hardware, with latencies, clock issues, etc... THAT is true computer science, IMHO, and is very near Electrical Engineering. It really depends on what sources you base your concepts on. I would say that, for instance, what you mention is more closely related to "computer engineering" than "computer science". For instance, in [0]: "Thus CS is closer to the underlying theory of computation, with its roots in mathematics, and CEN is closer to the design of physical devices (...) Of the three great divisions in computing, namely theory, software and hardware, to a first approximation theory goes with CS, hardware with CEN, and software with both (...)" In my country, our technical schools and most universities provide what we call "informatics engineering" (engenharia informática), which has a bit of CS (in terms of basic concepts, algorithms, abstract data types, etc.), CE (some low level electronic stuff) and Software Engineering (Programming, OOP, Web Programming, Logic/functional programming, etc.). [0] http://www.eng.buffalo.edu/undergrad/academics/degrees/cs-vs-cen http://www.eng.buffalo.edu/undergrad/academics/degrees/cs-vs...
10y ago

asimpletune 10y ago

Advances in algorithms are a fundamental starting point, but I think it's a common mistake to conflate the efficiency of an algorithm in the abstract sense to how those benefits are manifested in the applied sense. While true, all things held equal a new algorithm will advance the field, providing "gains" as you said, but it's false to assume that algorithms are more important than understand computer architecture, full stop. A simple example is dijkstra's algorithm vs bellman ford. Sure, in the abstract sense, the greed algorithm wins. However, it would be wrong to assume that dijkstra's algorithm is faster than bellman ford, because it's not. That's because dijkastra's algorithm doesn't parallelize as well, where as bellman ford parallelizes very well (and by "well" I mean it exploits the architecture - in a sense has "mechanical sympathy"). You end up creating very exotic data structures that are good for caching and stealing work from unused threads. There are many other examples, check out matrix matrix multiplication if your interested. I'm not making the argument that one is more important than the other, but I think it's a bit reductive to say algorithm only matter because there are so many examples of where computer architecture matters more (and vice versa). Another way to say what I mean is that ultimately reality matters. > The likes of Karp, Valiant, Cook, Blum, Vazirani, Papdimitriou, Micali, Goldwasser, Goldreich, Shamir, Rivest and etc.? I doubt these people know the inner workings of computers, but they have revolutionized our view of what it means to compute. Um, why would you think that they don't understand the inner workings of computers? Is that just your intuition or is that based on some practical knowledge? I'm not saying I know the answer (I haven't quizzed them), but since we're guessing here I'm going to say that they probably know a lot about the inner workings of computer - and there's no harm in us mortals trying to do the same. They probably don't know like specific things about how intel's branch prediction works or anything like that, but as a general concept, the inner workings of computers is pretty fundamental stuff and is very helpful to know, along with algorithms.

gravypod 10y ago
>common mistake to conflate the efficiency of an algorithm in the abstract sense to how those benefits are manifested in the applied sense > While true, all things held equal a new algorithm will advance the field, providing "gains" as you said > but it's false to assume that algorithms are more important than understand computer architecture, full stop I wish there were two like buttons. I have nothing to add that you haven't said better then I could have.

wfunction 10y ago

> What about people that have pioneered the theory of computer science? The likes of Karp, Valiant, Cook, Blum, Vazirani, Papdimitriou, Micali, Goldwasser, Goldreich, Shamir, Rivest and etc.? > I doubt these people know the inner workings of computers ...wha...? This is so ridiculous of a claim that I can't even think of how to respond...

joatmon-snoo 10y ago
>> I doubt these people know the inner workings of computers > ...wha...? This is so ridiculous of a claim that I can't even think of how to respond... GP probably means that while these pioneers might be aware of, might have tinkered with the nuances of processor design and syscalls and nitty-gritty details of TLB's and interrupts and stuff that, say, a kernel-level or SSD firmware guy might deal with regularly, it's highly unlikely that they would know their way around these like they know their way around the algorithms that they deal with on a regular basis, which exist at a much higher level of abstraction. Take everything with a grain of salt.
- wfunction 10y ago
  > GP probably means that while these pioneers might be aware of, might have tinkered with the nuances of processor design and syscalls and nitty-gritty details of TLB's and interrupts and stuff that, say, a kernel-level or SSD firmware guy might deal with regularly, it's highly unlikely that they would know their way around these like they know their way around the algorithms that they deal with on a regular basis, which exist at a much higher level of abstraction. I think you missed my point. What I'm saying is there's a world of difference between "X knows B better than A" and "X doesn't know A [very well]". When you're talking about world-class experts who are at the forefront of research in their fields, if you work in the same discipline, there's a pretty damn good chance they're more of an expert at your work area than you are. (I'm obviously assuming "you" here are not the world-class expert in your area. "You" are just a generic but respectable engineer in your area of work.) I think what you (& the OP) need to realize is that there's a HUGE and crucial difference between being, say, "rusty" on something (e.g. because you're not doing it on a day-to-day basis, or because it's someone else's system and obviously you can't magically know how it was designed a priori), and not having enough prior expertise such that your ramp-up time would be low enough to be negligible, should you ever need to touch that thing at some point. You need to realize, these folks have done so much work that they even get rusty on their own research topics after a few years. That doesn't mean they stop being experts on their topics. On top of that, they still keep up with their colleagues' research in other related areas... which, mind you, are likely to be more advanced than what you're doing. Chances are if they spent a day or two reviewing other stuff, they'd be as good (or even better) experts on them than they were originally, quite likely better than you (again, generic "you" here, as above).