3

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.

  • You may want to re-word the question. You're not asking why their syntaxes are different as much add you're asking why they are so complex. – DougM Apr 3 '14 at 19:56
  • Your question has some problems. Haskell is not a procedural language; it's a functional language. Why is execution on a runtime relevant? – Robert Harvey Apr 3 '14 at 19:59
  • := is used in Pascal too. It has the benefit of very obviously differentiating the "assignment" operator for the "equality" operator. In math, x = y never means "assign the value of y to x", it's a statement of equality. – KChaloux Apr 3 '14 at 20:03
  • Regarding type safety, it's totally orthogonal to functional languages (which is actually what you're talking about - not procedural languages). Lisp is often considered one of the first and most influential languages out there, and the majority of Lisp dialects are dynamically typed in a manner similar to Python. – KChaloux Apr 3 '14 at 20:06
  • 4
    It looks more complicated because you're comparing sqrt and qsort! – Dan May 20 '14 at 14:08
7

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.

  • Just out of curiousity: I know about "Because of immutability and lack of side effects in functional programming, certain methods of processing lists have been adopted which make it easier." - would that mean, that say if we would build a language that is similar to python, but doesnt have anything that allows you to use global variables, like classes, so you're only left with functions, you can have the same lack of side effects, and still have a cleaner syntax? – user125756 Apr 3 '14 at 20:40
  • That would mean that you have to write more code somtime but in the end the language is easier to understand right? It would be a nice balance between a general-purpose language like Python and a concurrent / functional language like erlang. – user125756 Apr 3 '14 at 20:42
  • I added a similar python example. Whether using words instead of symbols is 'cleaner' is mostly a matter of taste. Is shorter code cleaner or is more english-like code? Erlang's syntax may be more difficult to learn, but it isn't more difficult to read once you know it. Erlang programmers can look at that line and understand it pretty much right away, and will pronounce it in their heads like the python example. – Karl Bielefeldt Apr 3 '14 at 20:55
  • I guess it makes sense, I hope there will be a good oppurtunity soon for me to try a language like erlang. – user125756 Apr 3 '14 at 20:58
4

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.

  • Thanks for the explanation, I difference between python and C (symbolic and english-like) The thing I was thinking about is why concurrent (which seems to be a better word than procedural) languages seem all to have a more complicated syntax. – user125756 Apr 3 '14 at 20:33
  • 1
    Erlang might not be the best example. There are other "concurrent" languages that have simpler syntax. Haskell is viewed as hard to learn by some, but it has a relatively lightweight syntax. Fibonnaci in Haskell: fib 0 = 0 fib 1 = 1 fib n = fib (n-1) + fib (n-2) – Robert Harvey Apr 3 '14 at 20:36
  • 2
    I'd say there are actually 3 camps for syntax: mostly words (Python, Pascal, Ada), mostly symbols (Perl, Erlang) and mixed (C, Java). See Scala for a functional language with a C-like balance of symbols and words. – soru Apr 3 '14 at 20:42
  • I'd like to try a concurrent language (it will propably be Go), being from the Python, Java, or C camp this just jumped in my mind, thanks for the answers guys! – user125756 Apr 3 '14 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.