Ask HN: Does knowing the history of a programming language or technology matter? | Hacker News Reader

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

7 pointsnastygibbon7 comments

I had a disagreement with an experienced colleague today. I argued that following the changes and developments of a particular technology or language and learning about their history if you are new to them is helpful. It can give you an idea about why the language changed and for what reasons and the direction it was or is trying to move toward. He completely disagreed with me and asked me to name one example of where knowing about a change in the language was beneficial. I gave my answer but it didn't seem to convince him. What does HN think?

View on HN

Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it.

   --George Santayana, The Life of Reason.

The past is never dead. It's not even past.

   --William Faulkner, Requiem for a Nun.

Supporting older browsers.

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.

We are a product of our history - and the same goes with the community around any given technology, not to mention the technology itself. Understanding that history helps you to understand the mindset of the people who created the technology and why and how they designed it. Understanding that will in turn enable you to appreciate and utilize the strengths and weaknesses of said technology better.

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

In a lot of languages there is several different ways to do seemingly the same thing, and it often helps knowing the history to understand why they got added but also why they got replaced.

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...

When debugging environment-specific issues, knowing the recent changes to a language can save you a lot of time.

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.

It may be hard to come up with a direct and specific scenario that would convince your colleague, but I believe the more you know about a language, the more "enlightened" you become on it and are ultimately (albeit indirectly) better at it in the grand scheme.

uh, yeah? duh? In a language like ruby where there is frequent changes, its necessary to know where things are coming from and where they're going. The community itself is learning about what is and what is not a good idea, and its of course wise to learn that knowledge as well.

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.

Reply on news.ycombinator.com