Ask HN: Does knowing the history of a programming language or technology matter?

   --George Santayana, The Life of Reason.

   --William Faulkner, Requiem for a Nun.

It is impossible to properly support older browsers, which your users will be using whether you think they will or not, without knowing a good history of CSS, HTML, and Javascript such that you know what browser had what bug with what feature and what the expected behavior will be for that browser such that you have fallbacks or workarounds in place to support that browser.

Not a major problem if you only support evergreen browsers - but you will be incapable of supporting older browsers without being familiar with the history.

Or for Javascript - ES6 code could make your code far more maintainable, lowering your technical debt, but you'll need to transpile it down to ES5 to work in current browsers. So knowing where the language is heading is important.

Not all languages/software maintain backward compatibility. What if you are using an API that is going to undergo a major change and completely break everything you are doing? Being able to plan for that change and update your API could be the difference between your business shuttering or remaining operational.

One good example: the Unix philosophy. Unix originated back in the 70s, with slow, expensive time-sharing computers, many of which still used printing teletypes. Any text output was expensive in that it used ink and paper and took a long time. Therefore the principle of silence was born: if a program doesn't need to say anything, it shouldn't. See also the principles of smallness and modularity - each program should do one (and only one) thing well, but it should be easy to combine different programs to suit one's needs. You simply couldn't run any very large programs back then, and later on it turned out that chaining several together was actually a pretty good design principle anyway. (For more details, see ESR's "The Art of Unix Programming".) Knowing this history will help one appreciate the philosophy, understanding the philosophy will help one write good programs for that context.

Second example: take the Python language. Its community places a prime on "pythonicness" (http://blog.startifact.com/posts/older/what-is-pythonic.html), a set of guidelines/rules/principles that strongly influence the evolution of the language. Knowing what is and what is not pythonic helps one write better, cleaner Python code, as it enables one to use the language as it is intended.

tl;dr: knowing the history and culture surrounding a technology enables you to use it as it was intended

Concurrency in C#/.Net is a good example. There is three[0] or more ways of doing concurrency, and without understanding the history, it seemingly doesn't make sense. C++ is another good example, in particular in C++14, it is important to understand C++11 to port code, but also understand why some things are done differently in C++14 (rather than just knowing that they simply are).

[0] https://msdn.microsoft.com/en-us/library/hh156548%28v=vs.110...

There have been many times (in my experience) where a project's production, staging, and localhost environments may be running slightly different versions of a language/interpreter. When something goes wrong somewhere, being able to recall the unique properties / idiosyncrasies of their environment can help you debug very quickly.

Now, is it important to know the nitty gritty details of who created the language and in who's garage? I think that is more trivia. But how the language itself has evolved is important to understand.