4 ms·

I like history but how is history going to get me a functional game released or land a job interview? I don't need to know about DARPA to create a wordpress pa

I like history but how is history going to get me a functional game released or land a job interview? I don't need to know about DARPA to create a wordpress page or a C# Windows Service...

Sharlin 6y ago
The GP is talking about (future) researchers in particular. Still, there’s a tremendous historical myopia among practicing software engineers as well, leading us as a field to reinvent old ideas in new clothes every ten years or so.
- wernercd 6y ago
  Researchers might have more use for history... but day to day, in the field, programmers? not so much. I would think it's the difference between math researchers and accountants... You don't need to know history to balance a check book.
  - tremon 6y ago
    Programmers in the field have little use for computer science in general. You don't need to know anything about cyclomatic complexity when assembling a shiny javascript widget. Until you do, of course. At which point it's clear you should've known about it years ago.
    - wernercd 6y ago
      cyclomatic complexity and computer science isn't history. Not sure where the disconnect is because at no point have I said you shouldn't learn how to do your job correctly - and understanding Big O, SOLID, YANGI, etc are all important to know... but have nothing to do with history. So again... history isn't needed to be a good engineer. And being a good engineer and KISS programming is possible without understanding 100 years of history.
  - Sharlin 6y ago
    The difference is that the way to balance a check book doesn't change every five years, or these days more like every year. Maybe if programmers knew a bit more about history, they wouldn't need to reinvent it so often and could be more like accountants. But programmers don't want to be accountants, they want to use new and shiny things even when it's not the pragmatic choice, even when it would be better engineering to understand things in a broader context, to understand the history behind these "new" (actually old) things.
    - wernercd 6y ago
      Accounting has been around for hundreds of years. The reason it doesn't change? Because it's not a "new" field. Same for stuff like construction and cooking... stuff that's been around a very long time has become rather stable and of course it isn't going to be "reinvented every five years". > when it would be better engineering again... I don't need to understand history to understand Big O and which algorithm to use in the right circumstances or when procedural programming is proffered to functional. At no point in my career have I ever NEEDED history to decide which library to use, which sorting algorithm is suitable and how to create functional apis or windows services. History is nice to know... but still 100% not needed at any stage of the process. I'm not sure where the disconnect is because I like history... I like learning about American history, world history, programming history... but none of that has ever been relevant in any of my jobs when it comes to day to day decisions and projects. "don't reinvent the wheel" is a separate topic and while I can agree that many things get reinvented - computers are still a very young industry compared to stuff like accounting and architecture.
- andi999 6y ago
  So what? Sometimes ideas have to be reinvented, maybe this time they succeed. There could be two reasons why old ideas (talking about Software here) didnt succeed, one is Hardware wasnt capeable, the other is 'they didnt cross the chasm' - both might be different now (third option, the idea is bad, then one shouldnt do it again of course).
  - Sharlin 6y ago
    You're still assuming a linear model of history. My point was that history is cyclical, the same trends come and go. Static vs dynamic typing. Thin client vs thick client. Local vs distributed. Key-value vs relational. Monolithic vs micro*. And so on. Yes, sometimes these have to do with changing requirements or hardware capabilities, but more often they're just about a new generation wanting shiny new things rather than boring old things. Except that the shiny new things were the boring old things of the previous iteration. Many ideas of the yesteryear were not bad or even infeasible, indeed they were successfully put into real-world use. Until the tide changed and they became unfashionable for whatever reason. And then they became fashionable again, but without a view of the history there's little synthesis of ideas, little learning from past experiences beyond the current cycle.
    - jonjacky 6y ago
      This cycle was called the "Wheel of Reincarnation" in this 1968 paper by Myer and Sutherland about display processors. http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...
mikewarot 6y ago
The optimization bottleneck you're fighting against in the game might have been solved 50 years ago, if you don't know history, you don't have a complete toolkit of all the good tools. There are good reasons to learn assembler, basic, forth, lisp, smalltalk, pascal, c, c++, python, java, etc. even if you don't use them on a regular basis.
- wernercd 6y ago
  I don't need history to know algorithms... so "that was solved 50 years ago" doesn't teach me how to build a balanced node tree or actually matter if I simply know to use sort library method A instead of B. > good reasons to learn Of course... but none of that needs HISTORY to use effectively. Knowing functional programing, procedural, async, etc, etc, etc... I can know all of that without needing to know history. One doesn't need the other.
  - fooker 6y ago
    History is not just about time — what happened when. An equally important part is the ordering and the reasons something happened. You can know how to write simple programs in all paradigms, but fail to understand what to use when. You might have memorized a long list of algorithms but not understand the trade-offs involved in choosing one. Of course history is not the only way to understand this, but it is definitely one good method.
    - wernercd 6y ago
      Well like I said... I enjoy history. but. I've never used history to solve business problems. They are related and good to know... but I don't need to know history to flip burgers, run a business or plan my next sprint. I'm not arguing history is unimportant or good to know or even possibly useful just to have ideas of what to do - or what not to do... I'm just arguing it's importance is over-emphasized.
      - ballenf 6y ago
afarrell 6y ago
> how is history going to land me a job interview Step 1. Go to software conference. Step 2. Get into hallway track conversation where a historical anecdote and its lessons are relevant. Step 3. Say things that prompt y'all to have insight and establish trust that you're thoughtful about how to build software.
- wernercd 6y ago
  > Step 1. Show 10+ years of experience > Step 2. Never talk about history because I don't need history to solve business problems with programming > Step 3. Make 6 figures. An anecdotal example made up about talking at some conference with big words won't provide business value and isn't useful in day to day problem solving. So again... 99% of programmers won't ever use the history of DARPA and the birth of the internet to land a job.
  - enriquto 6y ago
    This thread is about computer science, not specifically programming.
  - afarrell 6y ago
    I this is the first time I've seen the same person simultaneously assert that: 1. What really matters is delivering business value. 2. Networking at conferences and talking about the social context of technology is useless.
juliendorra 6y ago
I won’t try to give a list of examples of how historical knowledge is useful for a developer, but just compare this statement with different fields: An architect will learn about the history of hundreds of buildings at school. A product designer like a designer designing chairs, knows about the history of chairs, has dozens of example of chairs in their mind. That developers strive to be so a-historical is a sad state of affairs. It makes the whole field naive and stuck in a perpetual present. But digital art and web design are in the same mode too, so it’s something about the whole digital fields. The only exception is game design, where it’s considered important and valued to learn about old games, play them, understand how they worked.
Shorel 6y ago
If you ever need to read something in one of Knuth's books, that's useful history for you. I know because I was looking how to efficiently generate power sets and eventually the only good answer was in TAoCP!!! So the answer is: history, the kind of history full of technical details that Knuth argues for, is extremely useful for our profession. It is the empty, pop history, made without algorithm descriptions and full of only anecdotes what you are thinking about? Knuth argues against that!
- taeric 6y ago
  I'm intrigued which method you are referencing. If I recall, he goes through many. :)

I like history but how is history going to get me a functional game released or land a job interview? I don't need to know about DARPA to create a wordpress page or a C# Windows Service...

Sharlin 6y ago

The GP is talking about (future) researchers in particular. Still, there’s a tremendous historical myopia among practicing software engineers as well, leading us as a field to reinvent old ideas in new clothes every ten years or so.

wernercd 6y ago
Researchers might have more use for history... but day to day, in the field, programmers? not so much. I would think it's the difference between math researchers and accountants... You don't need to know history to balance a check book.
- tremon 6y ago
  Programmers in the field have little use for computer science in general. You don't need to know anything about cyclomatic complexity when assembling a shiny javascript widget. Until you do, of course. At which point it's clear you should've known about it years ago.
  - wernercd 6y ago
    cyclomatic complexity and computer science isn't history. Not sure where the disconnect is because at no point have I said you shouldn't learn how to do your job correctly - and understanding Big O, SOLID, YANGI, etc are all important to know... but have nothing to do with history. So again... history isn't needed to be a good engineer. And being a good engineer and KISS programming is possible without understanding 100 years of history.
- Sharlin 6y ago
  The difference is that the way to balance a check book doesn't change every five years, or these days more like every year. Maybe if programmers knew a bit more about history, they wouldn't need to reinvent it so often and could be more like accountants. But programmers don't want to be accountants, they want to use new and shiny things even when it's not the pragmatic choice, even when it would be better engineering to understand things in a broader context, to understand the history behind these "new" (actually old) things.
  - wernercd 6y ago
    Accounting has been around for hundreds of years. The reason it doesn't change? Because it's not a "new" field. Same for stuff like construction and cooking... stuff that's been around a very long time has become rather stable and of course it isn't going to be "reinvented every five years". > when it would be better engineering again... I don't need to understand history to understand Big O and which algorithm to use in the right circumstances or when procedural programming is proffered to functional. At no point in my career have I ever NEEDED history to decide which library to use, which sorting algorithm is suitable and how to create functional apis or windows services. History is nice to know... but still 100% not needed at any stage of the process. I'm not sure where the disconnect is because I like history... I like learning about American history, world history, programming history... but none of that has ever been relevant in any of my jobs when it comes to day to day decisions and projects. "don't reinvent the wheel" is a separate topic and while I can agree that many things get reinvented - computers are still a very young industry compared to stuff like accounting and architecture.
andi999 6y ago
So what? Sometimes ideas have to be reinvented, maybe this time they succeed. There could be two reasons why old ideas (talking about Software here) didnt succeed, one is Hardware wasnt capeable, the other is 'they didnt cross the chasm' - both might be different now (third option, the idea is bad, then one shouldnt do it again of course).
- Sharlin 6y ago
  You're still assuming a linear model of history. My point was that history is cyclical, the same trends come and go. Static vs dynamic typing. Thin client vs thick client. Local vs distributed. Key-value vs relational. Monolithic vs micro*. And so on. Yes, sometimes these have to do with changing requirements or hardware capabilities, but more often they're just about a new generation wanting shiny new things rather than boring old things. Except that the shiny new things were the boring old things of the previous iteration. Many ideas of the yesteryear were not bad or even infeasible, indeed they were successfully put into real-world use. Until the tide changed and they became unfashionable for whatever reason. And then they became fashionable again, but without a view of the history there's little synthesis of ideas, little learning from past experiences beyond the current cycle.
  - jonjacky 6y ago
    This cycle was called the "Wheel of Reincarnation" in this 1968 paper by Myer and Sutherland about display processors. http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...

mikewarot 6y ago

The optimization bottleneck you're fighting against in the game might have been solved 50 years ago, if you don't know history, you don't have a complete toolkit of all the good tools. There are good reasons to learn assembler, basic, forth, lisp, smalltalk, pascal, c, c++, python, java, etc. even if you don't use them on a regular basis.

wernercd 6y ago
I don't need history to know algorithms... so "that was solved 50 years ago" doesn't teach me how to build a balanced node tree or actually matter if I simply know to use sort library method A instead of B. > good reasons to learn Of course... but none of that needs HISTORY to use effectively. Knowing functional programing, procedural, async, etc, etc, etc... I can know all of that without needing to know history. One doesn't need the other.
- fooker 6y ago
  History is not just about time — what happened when. An equally important part is the ordering and the reasons something happened. You can know how to write simple programs in all paradigms, but fail to understand what to use when. You might have memorized a long list of algorithms but not understand the trade-offs involved in choosing one. Of course history is not the only way to understand this, but it is definitely one good method.
  - wernercd 6y ago
    Well like I said... I enjoy history. but. I've never used history to solve business problems. They are related and good to know... but I don't need to know history to flip burgers, run a business or plan my next sprint. I'm not arguing history is unimportant or good to know or even possibly useful just to have ideas of what to do - or what not to do... I'm just arguing it's importance is over-emphasized.
    - ballenf 6y ago

afarrell 6y ago

> how is history going to land me a job interview Step 1. Go to software conference. Step 2. Get into hallway track conversation where a historical anecdote and its lessons are relevant. Step 3. Say things that prompt y'all to have insight and establish trust that you're thoughtful about how to build software.

wernercd 6y ago
> Step 1. Show 10+ years of experience > Step 2. Never talk about history because I don't need history to solve business problems with programming > Step 3. Make 6 figures. An anecdotal example made up about talking at some conference with big words won't provide business value and isn't useful in day to day problem solving. So again... 99% of programmers won't ever use the history of DARPA and the birth of the internet to land a job.
- enriquto 6y ago
  This thread is about computer science, not specifically programming.
- afarrell 6y ago
  I this is the first time I've seen the same person simultaneously assert that: 1. What really matters is delivering business value. 2. Networking at conferences and talking about the social context of technology is useless.

juliendorra 6y ago

I won’t try to give a list of examples of how historical knowledge is useful for a developer, but just compare this statement with different fields: An architect will learn about the history of hundreds of buildings at school. A product designer like a designer designing chairs, knows about the history of chairs, has dozens of example of chairs in their mind. That developers strive to be so a-historical is a sad state of affairs. It makes the whole field naive and stuck in a perpetual present. But digital art and web design are in the same mode too, so it’s something about the whole digital fields. The only exception is game design, where it’s considered important and valued to learn about old games, play them, understand how they worked.

Shorel 6y ago

If you ever need to read something in one of Knuth's books, that's useful history for you. I know because I was looking how to efficiently generate power sets and eventually the only good answer was in TAoCP!!! So the answer is: history, the kind of history full of technical details that Knuth argues for, is extremely useful for our profession. It is the empty, pop history, made without algorithm descriptions and full of only anecdotes what you are thinking about? Knuth argues against that!

taeric 6y ago
I'm intrigued which method you are referencing. If I recall, he goes through many. :)