Why do concurrent languages tend to have more complicated syntax?

Question

This is a question that's been on my mind for a while. Recently I've been checking out concurrent languages like Haskell or Go or Erlang.

From my point of view, they have huge benefit in performance as opposed to languages like C++ or Python because of the way they handle functions in parallel.

My question is: Why is the syntax for languages like C++ or Python so much different (and IMO simpler) from those of concurrent languages, even though most concurrent languages are executed on runtime (and therefore they have more possibility in simplifying the syntax)?

Here is an example, consider Go's sqrt:

// Package newmath is a trivial example package.
package newmath

// Sqrt returns an approximation to the square root of x.
func Sqrt(x float64) float64 {
    z := 1.0
    for i := 0; i < 1000; i++ {
        z -= (z*z - x) / (2 * z)
    }
    return z
}

Now for the Python counterpart (ported this myself based on the Sqrt example from Go):

def Sqrt(x):
 z = 1.0
 for i in Range(0, 1000):
  z -= (z*z-x/2*z)
  return z

Now as you can see go has a syntax like ":=" for assignment, If you take a more complicated examples, the syntax will look more like what I am trying to point out.

And Go is just the least "weird-looking" language. If you consider Erlang it's looking even weirder:

%% qsort:qsort(List)
%% Sort a list of items
-module(qsort).     % This is the file 'qsort.erl'
-export([qsort/1]). % A function 'qsort' with 1 parameter is exported (no type, no name)

qsort([]) -> []; % If the list [] is empty, return an empty list (nothing to sort)
qsort([Pivot|Rest]) ->
    % Compose recursively a list with 'Front' for all elements that should be before 'Pivot'
    % then 'Pivot' then 'Back' for all elements that should be after 'Pivot'
    qsort([Front || Front <- Rest, Front < Pivot])
    ++ [Pivot] ++
    qsort([Back || Back <- Rest, Back >= Pivot]).

Parts that caught my eye were "++ [] ++", '<-' and '->'

I am convinced these languages look like this for a reason, but I can't help but think: Can't it be simpler? Why are concurrent languages like this? Why if they use a runtime like Python and JavaScript, are they still type-safe?

I know type-safe languages have an advantage of their own to not mix up variable types, but still, there's gotta be somebody who made a concurrent language that didn't have type-safety, if possible right?

It seems like almost all concurrent languages have one thing in common: a bigger list of possible / valid syntax.

I hope I've explained my question well enough.

Answer 1

You're a little confused about terminology and what factors are relevant, as people mentioned in the comments. Let me just address the syntax of Erlang, which is a functional language.

It has more operators because it does more. It needs a ++ because it was already using + for something else. It uses ++ instead of a word like concat because the language was intended to favor conciseness. For example, the code:

[Front || Front <- Rest, Front < Pivot]

Requires the following code in C++ (copied from here):

int partition(int* input, int p, int r)
{
    int pivot = input[r];

    while ( p < r )
    {
        while ( input[p] < pivot )
            p++;

        while ( input[r] > pivot )
            r--;

        if ( input[p] == input[r] )
            p++;
        else if ( p < r )
        {
            int tmp = input[p];
            input[p] = input[r];
            input[r] = tmp;
        }
    }

    return r;
}

Although the same code in python using list comprehensions is just barely longer:

[front for front in rest if front < pivot]

Because of immutability and lack of side effects in functional programming, certain methods of processing lists have been adopted which make it easier. This includes pattern matching and destructuring. You might want to do some research on those, but my point is in order to gain the expressiveness and conciseness that things like pattern matching provide, you have to accept more complexity in your syntax.

Also keep in mind that C++ and python seem more natural largely because you learned them first. If you had learned erlang first, then C++ and python's syntax would seem limiting and excessively verbose.

Answer 2

It sounds like your observations about syntax are merely preferences, so let me make some observations of my own.

First of all, let me state equivocally that syntax does matter. The simplest syntax of all is Lisp:

(defun fib (n)
  (if (< n 2)
    n
    (+ (fib (- n 1)) (fib (- n 2)))))

Because code is essentially data in Lisp, lisp can understand code written in lisp, which makes writing a parser for Lisp in Lisp (or in any other language, for that matter) an almost trivial exercise. Lisp is widely regarded as a language where problems can be solved from the ground-up, in problem domains that would ordinarily be resistant to coding solutions (especially in domains where requirements are constantly changing). Lisp is a very expressive language, and at the end of the day, syntax is the way we express ourselves in a language. It is not, however, regarded as the most readable of languages (all those parentheses).

---

Programmers typically fall into one of two camps, syntax-wise: those that prefer a more English-like code representation, and those that prefer a more symbolic, mathematic-style code representation. The syntax of the language itself will be shaped, in large part, by the goals of the language.

For example, C is basically a high-level assembly language. It uses the syntax that it does, in large part, because it maps well to underlying assembly instructions. It has no need for lofty concepts like natural-language translation, preferring to map closer to the metal. Many languages that came after C adopted the brace structure and other syntax idiosyncracies because C had already done it. C is in the "symbolic" camp.

unsigned int fib_rec(unsigned int n) {
    if (n == 0) {
        return 0;
    } 
    if (n == 1) {
        return 1;
    }
    return fib_rec(n - 1) + fib_rec(n - 2);
}

Some languages, however, like Python, prefer to work at higher levels of abstraction and seek to be closer to the language used by humans. These languages will prefer things like significant whitespace, because it produces less clutter between the words than braces. Python is in the "English-like" camp.

def F(n):
    if n == 0: return 0
    elif n == 1: return 1
    else: return F(n-1)+F(n-2)

---

I was a Visual Basic programmer for years, and so was in the English-like camp, until I learned C#. I now prefer the better precision and less ambiguity that C# offers; I think in terms of what I need the computer to do, and C# seems to maps more closely to that. I like the fact that you can line up blocks of code in braces. I like that certain things are expressed more succinctly in C#. But the capabilities of VB.NET and C# are nearly identical, so the choice between those two languages really does come down to personal preference.