Does understanding history of a programming language help in understanding the language?

Question

Sometimes, the syntax of a language seems weird, I often think, why would someone make something like that, but definitely there is a reason and a history behind every aspect of a programming language.

Apart from being fascinating, It helps me remember the syntax and also the purpose that language solves.

Does knowing the background of languages like HTML & CSS (Okay, these are not programming-languages but still) JavaScript, C++, Objective C and even Java help in understanding the aspects of these languages?

Answer 1

That really depends on your learning style (and whether the language has an interesting history). What history can tell you:

• what motivated the initial design of the language, and what influences there were
• when newer features were introduced, what shortcomings were being addressed, and how (if at all) they changed idiomatic usage
• whether a given framework or library takes advantage of new language features and, conversely, whether it has a stable and long-term adoption base
• whether uptake is a result of good technological fit or clever marketing.

What history can't tell you:

• whether the designers got it right, either initially or during subsequent changes
• whether the current state reflects a language you want to use
• whether the current state corresponds to something you should use for your project.

Great examples of languages that have a history (whether or not you refer to it) include C++ and Java. In each case, when features were added to the language is documented, often along with why and whether users were already trying to solve a problem those new parts addressed.

Taking the example of C++ further, you can see that some additions to the standard came from third-party libraries like Boost. Also, Stroustrup's book does a good job of explaining the problems solved by the additions.

Answer 2

Some things may be interesting to know. The history itself isn't important, but understand the why is. This way, the next time you will use the syntax, you will think about the reasoning behind such syntax rather than trying to simply remember the syntax itself.

It's often easier to remember A and a logical way to go from A to B then from A to C, than remembering what B and C are.

Answer 3

Though history of computing and programming languages can be useful and interesting, I would argue that this is not much helpful, because new versions of a language try to fix old weird syntax. Take for instance how functions are declared in C (source: Function declaration: K&R vs ANSI):

// K&R syntax
int foo(a, p) 
    int a; 
    char *p; 
{ 
    return 0; 
}

// ANSI syntax
int foo(int a, char *p) 
{ 
    return 0; 
}

This is even more visible when comparing Fortran 77 and Fortran 90.

Answer 4

Martin Odersky opens his current presentation on Scala (at ScalaDays in NY and reprised on the West coast) with a history lesson.

What motivated the popularity of object-oriented programming? "I'm an old guy and remember this."

He suggests that Scala occupies an historical moment in the transition from an object-oriented to a functional paradigm, or as he would prefer, a confluence of these paradigms in Scala's hybrid style.

His theme is that there's more than one way to do it in Scala, and that this is a good thing because the choices you make, in everyday programming, are informed by historical practice. For example, whether you use combinators or a while loop; whether you extend a feature by subtyping or pattern matching to handle additional cases; or something as simple as whether you express an operation with a symbol (/: with the mnemonic of a falling domino) or name (foldLeft).

(One of his jokes is that /: seemed so cool but is obscure in practice; whereas ??? to mean "unimplemented" has immediate clarity for anyone looking at the code.)

History doesn't tell you that there is one right way to address a problem, but that there are two or three or nine. Odersky says -- echoing Knuth's famous edict about premature optimization -- that you mustn't worry about getting it right the first time, that in fact one of the perks of a hybrid style is that you get to experience the pleasure of improving an expression, optimizing for performance or clarity or what have you, not once, but several times. That's what makes programming fun!

For Scala, the tension between functional and imperative or object-oriented styles is not a battle to be won but an Auseinandersetzung, which is not Odersky's word but Heidegger's for the intimate love-hate relationship between two historical forces existing in close habitation.

Daniel Spiewak on the expression problem: http://vimeo.com/user18356272/review/66548717/3531875329

ScalaDays talks are soon to be released on parleys.com. http://parleys.com/channel/51ae1022e4b01033a7e4b6ca/presentations