Context. I'm looking at designing a small language with a textual syntax. It will be used by Business Analysts to define system requirements - so technically aware but not deep techies.

Given a background in programming I've been immersed in C-style syntax for so many years that I can't look at it objectively. Compared to the SGML style prevalent today in other contexts (HTML, XML) I view 'C style' as a model of clarity. However I've seen various comments in various places alluding to shortcomings. I know there can be practical issues (e.g. determinism for parsing) but that's not what I'm interested in here.

Specifically, I'd like to understand any usability shortcomings of C style. By 'C style' I mean the curly brace delimited blocks, parameters-in-parentheses etc. look of the C language.

Any suggestions / references to papers / articles describing problems and (preferably) alternative solutions would be much appreciated.

Python style is very readable, I find: C-style but with no semicolons and indentation-based blocks rather than curly braces (which are practically always accompanied by correct indentation, anyway).
–
Chris MorganAug 21 '11 at 13:17

3 Answers
3

What you are trying to create is a Domain-Specific Language. The rationale behind this kind of (programming) language is: keep the syntax as simple as possible, while simple refers to "human readable", by removing all non-needed features.

Difficulties of C-Syntax

What makes C-Syntax hard to write:

Missing trailing ;. I saw many beginners curse on this one.

Missing } or ).

The concept of pointers (you probably won't need this one)

Variable scopes

copy-by-value vs. references

If you take a small subset of language features, it will make the code both easier to read and to write (as long as it is consistent).

Example

Let's say, the code needs to express that Process A is dependent on Process B.

In the second example, the "coder" doesn't even need to know the concept of parameters!

Technical Complexity does influence usability

In the end, what may be at least as important: a decent compiling/debugging environment, error messages that help to solve the actual problem, etc. And because of the technical difficulty of parsing C, its compiler often throws errors that are only faintly related to the real cause. So a simple syntax will help here, too.

Thanks, very useful response. I hadn't factored in the importance of the environment (IDE/compiler) in the usability equation but that was a glaring ommission on my part. Much appreciated.
–
sfinnieAug 19 '11 at 11:38

One of the problems with C-style syntax is that it's not easy to find out (without a decent editor that is) which } or ) pairs with which, so you need whitespace for clarity. (A problem that was even more visible in LISP, which people have called Lots of Irritating Silly Parentheses). A </body> tag is much more clear: it ends the <body>.

For a historic overview of programming languages and the concepts introduced (and why) I'd recommend Robert W Sebesta's book 'Concepts of programming languages'. It includes the earlier programming languages and explains why they have evolved into what we know now.

Thanks. Good point about the matching tags; tradeoff I suppose is that they introduce visual noise. As per @giraff's reply it highlights importance of the environment in the equation. Hadn't come across Sebesta's book before, thanks for that.
–
sfinnieAug 19 '11 at 11:40

Others have mentioned the difficulties in C syntax, to which I can only add:

The * operator in declarations (adds confusion with multiplication and has weird precedence rules that leads to oddities like int*foo,bar; declaring a pointer and a direct variable, and to the WTF that is function pointer syntax. Not to mention: Why didn't they just use longer syntax like "address of foo" etc.

The sparse naming of identifiers and commands in the standard library, instead of more modern, verbose and readable syntax.

The weird type-promotion rules (char -> int, float -> double)

The weird way of specifying the data type of a number (1ULL etc.).

The inconsistent way in which arrays are pointers in some declarations and not in others.

The inconsistent way how sizeof() looks like a function, is an operator, and sometimes returns the size of the pointer variable, and sometimes the actual size of an array, but only when it's a local variable. OK, that's getting into semantics.

The for-loop. I've memorized it after coding in C for decades, but is that the most arbitrary and confusing syntax or what? Semicolons inside a command?

The comma operator. Not only a parameter separator, but also a way to string together several expressions, but only return the last one. And if you have a keyboard that has ; and , on the same key (like German), a very common source of typos. Think int foo = 13, gSomething = 14; where you meant to write int foo = 13; gSomething = 14;

You asked for alternate solutions:

I would suggest you take a look at English-like programming languages like Inform 7, LiveCode (and its predecessor HyperTalk), as well as AppleScript. While AppleScript's underlying model (with data types you must conform to but can't declare) is too technical, the way it defines syntax in a freeform way makes for very readable code.

Essentially, you can just write English sentences from a small subset of English. This means it doesn't understand every English sentence, but once you see a script, it is immediately obvious what it does, and it invites copy-and-paste programming, where you see code that does almost what you want and simply modify it.

AppleScript also had a "recording" facility where you could do something and its editor would write down the corresponding script, which, again, you could then modify easily by trial and error, even.

However, in any way, stick to simple constructs, and leave away "clever" constructs like chaining assignments like x = y = 4; They'll at best confuse non-geeks, at worst make unintentional typos compile.

Of course, if you want something easy and you're not married to using text, why not look at a UI like you can see it in Apple's Automator or the Scratch programming language? You can save it behind the scenes in a text form, but having a UI on top to build the expressions and letting the user drag-and-drop the common commands right from the documentation or a window full of snippets will make it much easier to learn for the casual coder who maybe codes 3 times a year and has another job the rest of the time.