One of my professors says "the syntax is the UI of a programming language", languages like Ruby have great readability and it's growing, but we see a lot of programmers productive with C\C++, so as programmers does it really matter that the syntax should be acceptable?

I would love to know your opinion on that.

Disclaimer: I'm not trying to start an argument. I thought this is a good topic of discussion.

Update: This turns out to be a good topic. I'm glad you are all participating in it.

  • 16
    Hmm, this seems to assume that the C/C++ syntax is bad? Certainly some elements of C++ templates are ugly, but as far as languages go (historically), C/C++ is still very, very readable.
    – Macneil
    Commented Dec 26, 2010 at 18:29
  • 2
    well i know many programmers who will disagree on that , mostly from the ruby community though , its more readable than lisp as far as i can tell :) Commented Dec 26, 2010 at 18:44
  • 9
    Was it a theoretical course? Remember: professors are often some of the worst programmers. They have no idea what it is like out there in the wild.
    – Job
    Commented Dec 26, 2010 at 19:51
  • 2
    Readability is in the eye of the beholder :).
    – MAK
    Commented Dec 27, 2010 at 3:37
  • 8
    Good syntax cannot make a miserable language better. But miserable syntax can make a good language worse ;)
    – Dario
    Commented Dec 27, 2010 at 12:29

18 Answers 18


Yes it does. If you're in doubt, take APL, or J, or Brainfuck, or even plain and simple Lisp or Forth, and try to understand any not entirely trivial program on it. Then compare to e.g. Python.

Then compare the same Python (or Ruby, or even C#) to things like Cobol or VB6.

I'm not trying to say that hairy syntax is bad and natural-language-like syntax is good in all circumstances. But obvoiusly syntax does make a huge difference. All in all, everything you can write in the most beautiful programming language you can also write as a Turing machine program — but you usually don't want to, do you?

  • 26
    Lisp is definitely understandable. Commented Dec 26, 2010 at 20:31
  • 68
    +1 for including Lisp in the list of unreadable languages.
    – asmeurer
    Commented Dec 27, 2010 at 3:16
  • 68
    -1 for including Lisp in the list of unreadable languages. Commented Dec 27, 2010 at 3:29
  • 29
    Programming in general is unreadable to the uninitiated. As are music notation and architectural floorplans. (= X Y) is just as readable as X == Y, to someone who knows how to read. Commented Dec 27, 2010 at 16:08
  • 6
    I loved APL, and unless the code was intentionally written to obfuscate (very easy to do), it was quite easy to read. The power of the syntax was that you could program algorithms in 2 or 3 lines of APL code that would require dozens or hundreds of lines of C, Fortran, or COBOL. The conciseness and power of a language like APL is important to this discussion because trying to read through hundreds of code lines of another language can be just as frustrating as deciphering obscure elements of APL.
    – oosterwal
    Commented Jan 31, 2011 at 23:17

In practice I think it does matter. Readability has already been discussed above. Another issue might be how many keystrokes are neded to express an idea/algotithm? Yet another issue is how easy it is for simple typos to be hard for the human eye to catch, and how much mischief they can cause.

I've also found it useful in some contexts to analyze, and/or to generate fragments of code via another computer program. The difficulty of parsing the language, and/or generating correct code then directly impacts how much effort is required to create/maintain such tools.

  • Great observation about typos that are easy to distinguish.
    – user8685
    Commented Dec 26, 2010 at 20:28
  • 7
    But in theory there is no difference between theory and practice.
    – Job
    Commented Dec 27, 2010 at 1:02

I believe your professor is referring to Syntactic sugar.

Syntactic sugar is a computer science term that refers to syntax within a programming language that is designed to make things easier to read or to express, while alternative ways of expressing them exist.

So what your professor is implying, is that whatever code/syntax written in one programming language, can be expressed in other languages just the same-- or even the same language.

Robert Martin, pulling from Structured Programming theorem, abstracted what programmers fundamentally do with programming languages at his keynote at RailsConf 2010: Robert Martin (youTube video, see after 14 minute mark, although I recommend the whole thing):

  • Sequence (assignment)
  • Selection (if statements)
  • Iteration (do-loops)

That is all programmers do, from one programming language to another, just in a different syntax or user interface (UI). This is what I'm guessing your professor was getting at, if he/she is speaking abstractly about programming languages.

So in essence, syntax doesn't matter. But if you want to be specific, then obviously certain languages and syntax are better suited for certain tasks than others, whereby you could argue that syntax matters.

  • Would you call C just a syntactic sugar for assembler? Commented Dec 26, 2010 at 20:23
  • 1
    I would. But I claim syntax matters. ;) Commented Dec 26, 2010 at 20:39
  • 3
    "...Robert Martin abstracted what programmers fundamentally do..." Robert Martin? Robert Martin?? You might actually want to consider this paper: C. Böhm, G. Jacopini, "Flow diagrams, Turing Machines and Languages with only Two Formation Rules", Comm. of the ACM, 9(5): 366-371,1966. which is usually credited as the source of the 'Structured Program Theorem'. en.wikipedia.org/wiki/Structured_program_theorem
    – leed25d
    Commented Dec 26, 2010 at 21:46
  • @lee25d I didn't mean to credit Uncle Bob as the originator of the abstraction, but as the source where I heard it recently (and linked to). But thank you for the link, I will update my answer to reflect your link.
    – spong
    Commented Dec 27, 2010 at 3:09
  • The Wikipedia piece linked above does not quite understand the history of the "Structured Programming theorem". The idea predated Bohm & Jacopini. Bohm & Jacopini's contribution was showing that it WAS a theorem, not just a conjecture, i.e., they provided a rigorous formal proof. Commented Dec 27, 2010 at 18:45

Yes and no.

There are a couple different aspects to syntax.

  • readability
  • expressivity
  • parsability

Readability has already been mentioned.

Expressivity is an interesting case. I'm going to use function-passing as an example, because it's sort of an inflection point of semantic/syntactic pain.

Let's take C++ for example. I can create a first-order function after this fashion:

class funcClass
  int operator()(int);
funcClass fun;

void run_func(funcClass fun)

This particular idiom is commonly used in Stepanov's Elements of Programming.

On the other hand, I can mimic it in Common Lisp with something like this:

(defun myfunc() )

(defun run_func(fun)

Or, in Perl -

   sub myfunc

   sub run_func
      my $func = shift;
      $func->();          #syntax may be a little off.

Or, in Python -

def myfunc():

def run_func(f):

These all have - essentially - the same semantic content, although the C++ example carries some type metadata. Which language expresses the idea of passing a higher-order function the best? Common Lisp barely makes a syntactical variation. C++ requires a class to be created just to 'carry' the function. Perl is pretty straightforward about making some level of differentiation. So is Python.

Which approach best suits the problem domain? Which approach best can express the thoughts in your head with the least 'impedance mismatch'?

Parsability is - in my mind- a big deal. In particular, I refer to the ability of the IDE to parse and chop the language without making errors. Reformatting is useful. Token-delimited languages tend to parse well - ruby/c/pascal, etc.

Consider though - major systems of all sorts have been created with every serious language to solve real-world issues. Although syntax is a barrier to express some things, it is a work-around-able barrier. Turing equivalence and all that.


Syntax does matter, and I can give you two supporting examples: Dylan, which is a Lisp with a more conventional syntax, and Liskell, which is Haskell with Lisp-like syntax. In each case, a variant of the language was proposed that had exactly the same semantics, but radically different syntax.

In the case of Dylan, it was thought that dropping s-expressions in favor of something more conventional would help attract a wider range of programmers. It turned out that syntax wasn't the only thing preventing programmers from using Lisp.

In the case of Liskell, it was thought that using s-expressions would allow for easier use of macros. It turned out that macros really aren't necessary in Haskell, so that experiment didn't work either.

Here's the thing: if syntax didn't matter to anybody, neither experiment would have been tried.

  • 2
    Dylan was too little, too late over other languages. What it had in its favor couldn't make up for that. We can no more assume it's a failure of syntax than it was a failure in naming.
    – Macneil
    Commented Dec 26, 2010 at 21:15
  • @Macneil: You're right about the too little, too late thing. Dropping the Lisp syntax was just the final nail in the coffin. I don't think it was the main reason for Dylan's failure, but I'm not sure how to re-word the answer to best reflect that. Commented Dec 26, 2010 at 23:26
  • Interesting, I didn't know they had the Lisp syntax in an earlier version... Was that when it was named Ralph? The Newton Message Pad was originally going to have Dylan at its core. 15 years later, we have iOS with Objective-C at the core, the lesser language of the two, IMHO.
    – Macneil
    Commented Dec 27, 2010 at 0:40
  • I don't remember the exact details about when Dylan lost s-expressions. I've been lurking on comp.lang.lisp for a long time, and remember the topic coming up in one of their periodic flamewars over parentheses. Commented Dec 27, 2010 at 13:34
  • Dylan predates Java, and I don't suppose there were many C++ way back then. Commented Feb 1, 2011 at 0:04

Syntax definitely matters, although you tend to notice it more when it's unintuitive and encourages bugs. For example, the infamous "world's last bug" joke:

if (AlertCode = RED)
  • 3
    +1: Interesting, I've never seen (or acknowledged) this infamous "world's last bug" joke. But I can see how, depending on the syntax of a language (or actually even semantics), the result of that pseudo-code could be anything. Given the semantic angle as well, this can really be chalked up to classic case of cultural miscommunication. Commented Dec 26, 2010 at 23:06
  • This is why you should use Yoda conditionals, i.e. if(RED = AlertCode) should never compile because RED is constant (or should be!)
    – Malfist
    Commented Dec 27, 2010 at 16:35
  • 4
    @Malfist: And thus we see that bad syntax leads to even worse syntax to compensate. Yoda conditionals are ugly and hard to read because they're not the way people think of the associated concept. My point was more like "this is (one of many reasons) why you should avoid the C family whenever possible." Commented Dec 27, 2010 at 17:04
  • 1
    Well, fortunately, that code has two bugs. Sure, it'll always enter the conditional, but in there, it's just getting a reference to the LaunchNukes procedure, and never invoking it. Crisis averted!
    – munificent
    Commented Dec 27, 2010 at 19:23
  • 3
    Depends on what RED is. If it's 0, then LaunchNukes() would never be called.
    – dan04
    Commented Jan 7, 2011 at 9:58

The answer might be in separating what "matters" into computer factors and human factors. There are a lot of human factors in syntax:

  • Readability
  • Succinctness
  • Maintainability
  • Pedagogy
  • Error prevention
  • Appropriateness for the purpose -- is it a REPL language, a script language or a large systems language?

As far as the computer is concerned, the only issue of syntax is whether or not there are ambiguities that need to be resolved, and how much time it takes to tokenize/parse the code upon compile/interpret -- and it's only in the case of the latter where the overhead of parsing is a significant issue.

That might be why you'll always get a "yes and no" answer to this question -- because there's two aspects to it.


Without syntax, we would not have a common "template" from which to communicate, at a human level, the intent of a block of code. Syntax provides a common framework from which compilers can be standardized; methods can be shared; maintenance can be simplified.

  • Why was my answer down-voted?
    – IAbstract
    Commented Feb 3, 2011 at 20:31

I think what really matters is API access, and availability of low-level functionality (like memory control and locking) when needed. Most other languages come with these features included. Problem is, when you need additional functionality you often have to use a language like C to implement it. And it is cumbersome interfacing C with the language you are using.

For everything except web development (and math) I've found that C/C++ is still THE language of an operating system and an application. It's what is supported most of the time for true multi-threaded, preforming, cross-platform application development. And the syntax of C is okay. Just very simple and relatively verbose. Amazing Syntax doesn't really matter that much. Power and API availability does We all need to interface with other people's code (which is most of the time written in C or its derivitives).

  • I have no qualms with C, but the ML/Haskell crowd would probably have something to say regarding threading. Commented Dec 27, 2010 at 1:38
  • +1 for "API access": I think this can even be more important than language features.
    – Giorgio
    Commented Nov 19, 2012 at 12:52

Syntax definitely matters. It's terrifically valuable if the language syntax is flexible enough to allow you to create a convenient and readable Domain-Specific Language for your application. If you doubt this, just imagine doing algebra problems in prosaic Latin, as it was done before the 18th century, or imagine doing calculus without the now familiar Leibniz notation. Sure, a calculus text is unreadable to a novice, but with practice we can use calculus and the Leibniz notation to quickly solve a class of problems that required pages of mathematics with classical methods. Programming is just another bit of mathematics. A convenient notation, close to the problem domain, can make an enormous difference in productivity.

  • DSLs are not all about syntax sugar. Semantics is a much more valuable part. It is ok to design eDSLs that won't add anything to an existing syntax.
    – SK-logic
    Commented Nov 16, 2011 at 8:41
  • @SK: sure, but semantics is under the complete control of the programmer. Syntax is constrained by the base language. We can build convenient DSLs within Groovy and other languages, but not so much in Java. Commented Nov 16, 2011 at 16:25

Here is a program that computes the faculty of 6:


The syntax is minimal:

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I' 

There seems to be a common belief that syntax is what makes a language difficult. As so often with commonly held believes, exactly the opposite is true.

Note that LISP syntax is only readable (if at all) because it has a lot more syntax than the above. So, if LISP fans tells you that "syntax doesn't matter", ask them to be consequent and try SKI calculus. They will have to admit that a bit syntax is not so bad after all.

  • I can not understand the down vote. This is a really insightful answer. +1
    – scravy
    Commented Feb 24, 2016 at 11:17

I don't think it matters beyond personal preference. All things (performance, capabilities, etc) being equal then I can see why one would put greater weight on a language syntax but choosing to pass over the performance of languages like c/c++ or any other language better suited for the job simply because of syntax would seem like a bad idea all around.

  • 6
    How about "time to market", "cost to benefit", etc.?
    – Job
    Commented Dec 26, 2010 at 19:52

Yes, syntax matters, although really only for readability. Compare:

for i in range(10):

(Yeah that's Python) with


(Yeah, that's a language I just made up) Both would do exactly the same thing, in the same way, but the syntax is different, and Python is easier to read. So yes, syntax definitely matters. Even "syntactical sugar" matters.

 def year(self):
     return self._date.year

Is easier to read than

 def year(self):
     return self._date.year
 year = property(year)

Yep, sure.

If you wanna initiate a big flame, ask the folks, where they put the opening bracet in C-like languages. I mean

void foo() {
  // blah


void foo()
  // blah

or even VS

void foo() 
{ // blah

And this is just the same language! Also, ask them about spaces, where they place them (function name and bracet, operators etc.).

1000 answers are guaranteed!

  • i dont want to initiate a flame & so far i've got good responses & i thank them all for participating & increasing my knowledge & i bet other people found this helpful Commented Dec 27, 2010 at 10:38

Syntax does matter. However in this day and age I'd say it matters almost entirely because of readability and not really in terms of the amount of keystrokes needed. Why?

  • Unless you're really writing something that simple, if the number of keys you press is the limiting factor in writing a program then you're either really, really crap at typing or think much, much too quickly.
  • All decent IDEs these days have a large number of shortcuts that mean you don't need to actually type out all the characters you're using most of the time.

That said, if it's too verbose then it can get to the point where it affects readability. I'd prefer to see something like:

foreach(String in stringList)


for every String that's in the list as referenced by the stringlist variable

...any day!


Syntax matters to those who are learning it, the lower the barrier to entry the more popular the language might be initially. But if the language is difficult or impossible to express your self richly and succinctly it will start to wither in popularity.

Very terse and opaque ( Perl ) is just as bad as overly verbose and wordy ( AppleScript ).

There needs to be a balance, lower barrier to entry, high productivity and easy maintenance.


Another thing to consider is that programming languages with nicer syntax are easier to parse, thus making the compiler easier to write, faster, and less prone to bugs.

  • 4
    Umm ... 10000 SLOC of parse.y in Ruby disagree. There is a reason why every single one of the 7 current-or-soon production-ready Ruby implementation uses the same parser, and every single Ruby implementation that has ever tried to develop their own parser has failed. Commented Dec 27, 2010 at 3:03
  • 1
    And then there was the infamous ADA language. Along with the language spec there were 100 programs that had to run correctly to certify the compiler. There were some really subtle things about the syntax. To make a long story short, EVERY early ADA compiler built flunked a couple of these programs. And it wasn't a simple matter of fixing a bug, but they needed to start over from scratch. Even though it had massive government support (all DOD contracts mandated ADA), it died a miserable death. Commented Dec 27, 2010 at 4:19

To put it simply: syntax as such doesn't matter. The semantics you can express through it matter.

  • 5
    As an excercise, write a complex parser in C, and then a device driver in Haskell. Did syntax help you? Then do the other way around, strictly preserving the semantics of both programs.</irony>
    – 9000
    Commented Dec 26, 2010 at 19:59
  • 1
    @9000: I've seen a couple of device drivers in Haskell. I couldn't see anything particularly wrong with them. Care to elaborate? Commented Dec 27, 2010 at 3:05
  • 2
    @9000, given how hard it is to get device drivers right in C i am not sure you have chosen a good example.
    – user1249
    Commented Dec 27, 2010 at 10:55
  • 1
    @9000: That was exactly my point. The concrete nature of a syntactic construct doesn't matter, it is what you express with it. A programming language with Haskell's exact syntax, but that uses a different evaluation strategy will make lots of Haskell perform awfully or even get stuck in infinite loops. When it comes to syntactic constructs (or broader: language features), it is not their concrete syntax that matters, but their semantics, i.e. what you can express with them.
    – back2dos
    Commented Dec 27, 2010 at 11:51
  • @9000, it won't be a problem to write a parser in a Haskell with C-like syntax (or a driver, using C with a Haskell-like syntax).
    – SK-logic
    Commented Nov 16, 2011 at 8:44

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