
Ask HN: Why does programming language syntax vary? - tomrod
I&#x27;ve spent time learning Python, R, Matlab, and a few of the traditional languages (C, Fortran, a few others. However, I&#x27;m no kind of language expert by any means! One thing that has confused me while learning languages is that while the conceptual ideas of a language, like control flow, stay the same between languages, syntax is varied and changes a lot.<p>I see the amount of effort that goes into development of languages and am surprised at the duplication effort that is required.<p>Will we ever arrive to a point where syntax between languages is constant, and the compiler is what changes? Where a computer science course can point to an example of a while statement--and that while statement is valid anywhere?
======
nostrademons
Two reasons:

1.) Programming languages are made by and for humans, and human preferences
vary. A programming language is effectively a user interface for programmers;
just like GUIs are never exactly the same (though there is some convergence),
programming language syntax is never exactly the same.

2.) Syntax is surprisingly dependent upon semantics. For example, take Swift.
If the last argument to a function is a closure, you can write it outside the
trailing paren, like this:

    
    
      let result = myArray.map { element in
         let x = element.doSomething()
         callSomethingElse(x, element)
      }
    

Can you imagine this working with Python syntax?

    
    
      result = map(myArray) lambda element:
        x = element.doSomething()
        callSomethingElse(x, element)
    

That's even taking some creative license with indentation; it's unclear how
you would even express this without multi-line lambdas, which were never
introduced because they interact with the indentation-sensitive syntax in
funny ways. As a result, it's pretty common to define collection operations,
event handlers, or new control structures in terms of trailing closures in
Swift. It would make no sense in Python or Java.

