6 ms·

I heard somewhere that a computer science degree is actually a history degree in how we have solved problems in the past. Programming is a creative problem solv

by haney 8y ago

I heard somewhere that a computer science degree is actually a history degree in how we have solved problems in the past. Programming is a creative problem solving process, but certain problems took decades to solve and it’s only by knowing the history that people are able to resolve some of these hard problems. Don’t beat yourself up for not knowing all of history and give yourself a break for not being able to immediately solve problems that took dedicated researchers their whole careers in the early days of computing.

samfisher83 8y ago
Knowing things like binary trees, heaps, B-trees, queues etc. are not history. They are fundamental to writing applications. Using one data structure or a particular sort method will make your application much faster. Supposed you have had a billion elements to sort, but you knew every element in that array is between 1-100. I mean a bucket sort would be much much faster than using a quick sort.
- peterwwillis 8y ago
  > They are fundamental to writing applications. That's funny, I must not have written any applications in the past 14 years. (Seriously though, I read one algorithms book when I was 16, and used those algorithms approximately... five times... in the past decade and a half)
  - 6nf 8y ago
    It's certainly good if you know how trees and linked lists are implemented, but as you point out most app devs are working on a higher level of abstraction. All of that nitty gritty implementation details are already available to application developers in convenient, well tested wrappers. You can easily go through your entire career without ever having to worry about how doubly-linked lists or B-Trees actually work.
    - anyfoo 8y ago
      > most app devs are working on a higher level of abstraction. Until they don't, because for some reason the abstraction cannot be applied in a particular scenario (or actually could be, but it's not understood), or just does not scale anymore.
  - anyfoo 8y ago
    Serious question: How do you know that in the applications that you have written in the past 14 years, there aren't any spots that could be considerably improved in runtime behavior and cost? I remember being a programmer before studying formal computer science, I definitely wrote some slow and bad code that I just didn't know could be much better, and/or simpler.
    - edflsafoiewq 8y ago
      How do you ever know that there aren't spots that can't be considerably improved? Does it matter that much? Any inefficiency apparently wasn't bad enough to stop it being shipped. I actually struggle more with not treating every problem like some algorithmic puzzle to be solved in one pass with O(1) extra memory and just writing stupid, slow, straight-forward code.
    - topkai22 8y ago
      This remains a serious problem on my team- Over half my team members don’t have CS degrees. They get an enormous amount done, but there is often a perf or maintainability cost. I have no intention of swapping them out because they ultimately provide enormous value, but it’s noticeable.
      - peterwwillis 8y ago
        Is it the algorithmic efficiency that's the problem, or the ability to scale the application? I've seen things some people wouldn't believe. mod_perl 1.4 on Apache 2.0 handling 350,000 hps dynamic traffic on twenty archaic 1U's. Five tiers of caching, serialized objects on local disks, NFS in production. C-beams glittering in the dark near the Tannhäuser gate. Who cares about inefficiency if it scales?
        anyfoo 8y ago
        Putting aside the damage that issues with correctness can cause, the problem is exactly that if you e.g. wrote something that grows with n^2 instead of n log n, you cannot scale by "brute force" anymore, as the inefficiency very quickly outgrows the amount of resources you can add. Seriously, your thinking that "algorithmic inefficiency" can be countered by "scaling" is almost proving the point. CS is by far not just about runtime complexity, but it's one thing that can bite you. Also, all the components you mentioned were likely written, at least in significant parts, by people knowledgeable about computer science.
- edflsafoiewq 8y ago
  You are, in this case, better off just using the ultimate bucket sort: shove it into a histogram. hist = [0]*100 for x in xs: hist[x-1] += 1 Epsilon algorithmic knowledge required.
- haney 8y ago
  My point wasn’t that they aren’t important, just that the OP didn’t need to feel bad about not learning about them yet. It was meant more to point out that learning the history of how other people solved problems can inform the way we approach new challenges, but that everything was unknown before it was discovered.
- PeterisP 8y ago
  I believe that parent's point is that knowing things like binary trees, heaps, B-trees, queues is exactly like knowing history - in the example problem you give, you're not supposed to invent a solution and design an algorithm, you're supposed to know the (many!) historical approaches to historical problem, know their properties so that you can pick the most appropriate one, and directly use these methods (invented by others, studied by you) as-is instead of inventing your own solution from the basics.
poulsbohemian 8y ago
>history degree in how we have solved problems in the past. I like that, that's a cool way to think about it. I've often thought it should be called "computational" science or maybe "skills in logical problem solving." Regardless of whether one pursues a career in software, a computer science degree is really good at teaching a person how to think.
- evancox100 8y ago
  Djikstra called it "computing science"

by haney 8y ago

samfisher83 8y ago

Knowing things like binary trees, heaps, B-trees, queues etc. are not history. They are fundamental to writing applications. Using one data structure or a particular sort method will make your application much faster. Supposed you have had a billion elements to sort, but you knew every element in that array is between 1-100. I mean a bucket sort would be much much faster than using a quick sort.

peterwwillis 8y ago
> They are fundamental to writing applications. That's funny, I must not have written any applications in the past 14 years. (Seriously though, I read one algorithms book when I was 16, and used those algorithms approximately... five times... in the past decade and a half)
- 6nf 8y ago
  It's certainly good if you know how trees and linked lists are implemented, but as you point out most app devs are working on a higher level of abstraction. All of that nitty gritty implementation details are already available to application developers in convenient, well tested wrappers. You can easily go through your entire career without ever having to worry about how doubly-linked lists or B-Trees actually work.
  - anyfoo 8y ago
    > most app devs are working on a higher level of abstraction. Until they don't, because for some reason the abstraction cannot be applied in a particular scenario (or actually could be, but it's not understood), or just does not scale anymore.
- anyfoo 8y ago
  Serious question: How do you know that in the applications that you have written in the past 14 years, there aren't any spots that could be considerably improved in runtime behavior and cost? I remember being a programmer before studying formal computer science, I definitely wrote some slow and bad code that I just didn't know could be much better, and/or simpler.
  - edflsafoiewq 8y ago
    How do you ever know that there aren't spots that can't be considerably improved? Does it matter that much? Any inefficiency apparently wasn't bad enough to stop it being shipped. I actually struggle more with not treating every problem like some algorithmic puzzle to be solved in one pass with O(1) extra memory and just writing stupid, slow, straight-forward code.
  - topkai22 8y ago
    This remains a serious problem on my team- Over half my team members don’t have CS degrees. They get an enormous amount done, but there is often a perf or maintainability cost. I have no intention of swapping them out because they ultimately provide enormous value, but it’s noticeable.
    - peterwwillis 8y ago
      Is it the algorithmic efficiency that's the problem, or the ability to scale the application? I've seen things some people wouldn't believe. mod_perl 1.4 on Apache 2.0 handling 350,000 hps dynamic traffic on twenty archaic 1U's. Five tiers of caching, serialized objects on local disks, NFS in production. C-beams glittering in the dark near the Tannhäuser gate. Who cares about inefficiency if it scales?
      - anyfoo 8y ago
        Putting aside the damage that issues with correctness can cause, the problem is exactly that if you e.g. wrote something that grows with n^2 instead of n log n, you cannot scale by "brute force" anymore, as the inefficiency very quickly outgrows the amount of resources you can add. Seriously, your thinking that "algorithmic inefficiency" can be countered by "scaling" is almost proving the point. CS is by far not just about runtime complexity, but it's one thing that can bite you. Also, all the components you mentioned were likely written, at least in significant parts, by people knowledgeable about computer science.
edflsafoiewq 8y ago
You are, in this case, better off just using the ultimate bucket sort: shove it into a histogram. hist = [0]*100 for x in xs: hist[x-1] += 1 Epsilon algorithmic knowledge required.
haney 8y ago
My point wasn’t that they aren’t important, just that the OP didn’t need to feel bad about not learning about them yet. It was meant more to point out that learning the history of how other people solved problems can inform the way we approach new challenges, but that everything was unknown before it was discovered.
PeterisP 8y ago
I believe that parent's point is that knowing things like binary trees, heaps, B-trees, queues is exactly like knowing history - in the example problem you give, you're not supposed to invent a solution and design an algorithm, you're supposed to know the (many!) historical approaches to historical problem, know their properties so that you can pick the most appropriate one, and directly use these methods (invented by others, studied by you) as-is instead of inventing your own solution from the basics.

poulsbohemian 8y ago

>history degree in how we have solved problems in the past. I like that, that's a cool way to think about it. I've often thought it should be called "computational" science or maybe "skills in logical problem solving." Regardless of whether one pursues a career in software, a computer science degree is really good at teaching a person how to think.

evancox100 8y ago
Djikstra called it "computing science"