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.
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.
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.
Just feels like you’re arguing that only short term memory matters. Have you never encountered a problem that became easy once you talked to someone with more background on the problem than you?
Why would you want to handicap yourself or your field by making it harder to “talk” to those a little bit further before you?
Your building is resting on their foundations whether you acknowledge it or not. They may have had a solution for the problem you’re facing.
> I've never used history to solve business problems.
As Knuth was trying to point out, history should be more than tables and time lines.
It should provide details of how important advances where made and how solutions to big problems where found.
And the reason being, since those historical details aren't being recorded, it's more than likely you are in fact solving business problems today using the same techniques discovered in the past, you just don't know it.
What I see is not over-emphasizing the importance of history but de-emphasizing it as a justification for present day sufficiency.
If you don't like the term, use another one. But without history you're bound to cargo cult computer science where what you have to do next is plan your sprint. Why do you need a sprint anyway? You might never know if you need a sprint any more if you don't know what problem was it supposed to fix.
You don't use history to solve the problems. You use history to find when people were fighting similar problems. Then, you link that to when other people solved still similar problems. And you look for what changed between, to see if you can leverage that.
At the junior programmer levels yes that can be true. At the principal engineer levels it’s not true. At that level you have to invent new ways of doing things when existing ways don’t cut it. Looking into the past is super charging.
none of my statements goes against learning history.
I probably don't do as much as I could/should... but I am a successful programmer who has never needed "history" to understand basic programming principles.
I seem to consider history and good engineering to be different topics while everyone else seems to think you can't understand Big O, YAGNI, SOLID, the difference between Functional Programming and Procedural programing, etc, etc, etc without understanding the history of how assembly turned into c...
Because History is interesting... but not needed to be a good engineer and a good programmer.
The disdain for history as an expression of you not knowing how to code wordpress is strange considering that, as you allude to, you don't know the latter.
You may want to think whether learning wordpress is the same with learning history of html at decade level.
Since you're publicly exposing your thoughts, let me tell you that what you are doing is expressing your ignorance and being proud of it. You may want to drop the second part.
I've not shown any disdain for history or an inability to code wordpress... in fact, I've said the opposite: I like history and simply don't need it to code.
I don't need to know history to code html, php, javascript, etc. I've a very successful programmer without using the "history' of programming in any shape or form.
"expressing your ignorance" or... I'm simply expressing that I'm a successful programmer who's never used "history" in a decade+ of programming...
You may want to reevaluate "ignorance" as you make claims that you can't support (IE: "disdain" for history and "can't code wordpress" - again, neither statements I've made). Reread my comments.
recap of them: I like history. I don't need history to code wordpress or windows services.
I was not entirely fair to you when trying to make my point. In fact I could see this exact argument of yours coming up and ignored it completely.
What I want to say is that there are entire domains of competence that are irrelevant to a large degree to doing the day's job. Knowing history of computing will not necessary help in making a better program in a way that can be noticed.
But history of computing is closely related to computing. Unlike for example history of knitting. Although neither will make you a better programmer now, the first has much better chance at that than the second (although we don't exactly know that).
Thus, when someone downplays the importance of history of programming to improving a programmer's mastery, I see it as touting ignorance at not seeing the connections between the two: self sufficiency, arrogance of ego being trapped by the light of today's fads, pop culture that doesn't care about the past or the future.
I mean, at a conceptual level, knowing history is important in the "ignorance of history will lead to repeated history" line of thinking - and I don't disagree. ... and knowing why decisions were made can help determine which tools to use (IE: Why use static typing or duck typing and when to use the other... or when to use procedural programming, async, functional, etc...)
Maybe it's a combination of you "projecting" and me not being clear. And trying to discuss what could be deep conversations in a little more than a twitter tag of 140 chars.
I'm personally a .Net Developer and while I do stick with the latest versions (IE: .Net Core), I also have enough experience to know the past (IE: ADO vs Entity Frameworks). I was trained in school on a mainframe (IBM DB2 with RPG and SQL). I'm not trying to stick with the latest "hotness" as most of MY work is actually done via Windows Services, API interactions and moving files around - definitely not the latest fad. With that said, I am working on using good tools to get my job done faster/better - IE: CI/CD pipelines to automate builds, testing, deployment, etc. Tools that didn't exist 5 years ago could be the latest fad but I don't think that's what you are suggesting.
I'm more worried about learning different things (IE: Functional, procedural, async, parallel, etc) than I am worried about "history" of those. When I pick up a programming book, I'm less worried about the "Microsoft created version 1 in 2000 and version 2 in 2005 and..." and more concerned about do's, do not's, best practices, etc.
Maybe it's my personality and the way I "deemphasize" history... it's not that I think it's unimportant... I just think that it's more important to focus on other things. Learning some history along the way is good and fun but it's never been my focus and I've never used what I consider "history" in an interview or a job on a day to day. Maybe that's rubbing people the wrong way lol
> 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.