In Python and JavaScript, semi-colons are optional.

In PHP, quotes around array-keys are optional ($_GET[key] vs $_GET['key']), although if you omit them it will first look for a constant by that name. It also allows 2 different styles for blocks (colon, or brace delimited).

I'm creating a programming language now, and I'm trying to decide how strict I should make it. There are a lot of cases where extra characters aren't really necessary and can be unambiguously interpreted due to priorities, but I'm wondering if I should still enforce them or not to encourage consistency.

What do you think?

Okay, my language isn't so much a programming language as a fancy templating language. Kind of a cross between Haml and Django templates. Meant to be used with my C# web framework, and supposed to be very extensible.

  • 22
    This is a topic for a holy war.
    – user7043
    Commented Feb 19, 2011 at 11:35
  • 1
    Pythonistas discourage the use of semicolons. Frankly, I am not sure if they are needed at all - only to allow multiple statements per line, which can be totally avoided without suffering. So ... I am in favor of stricter languages. However, sometimes you can enforce things outside of a language with code analysis tools, such as StyleCop.
    – Job
    Commented Feb 19, 2011 at 17:21
  • 1
    The quotes for PHP array keys are not optional. They were in PHP2, but later versions auto-defined constants then. They are disallowed in basic string interpolation "..$_GET[raw].." however.
    – mario
    Commented Feb 19, 2011 at 19:42
  • 1
    @Ralph: the rules are a bit more complicated. It's correct to write "xx$_GET[raw]xx" -- If you start to use curly braces, then the key must be enclosed "xx{$_GET['raw']}xx" in quotes. If curly braces are used then the ordinary PHP parser checks it and the stringent syntax applies. It's just for "$_GET[x]" that the key is treated as raw string, and that's also a strict rule, PHP would parse error on "$_GET['x']".
    – mario
    Commented Feb 20, 2011 at 17:14
  • 2
    @mario: The very fact that we're even having this conversation means there's some ambiguity and confusion in the way array keys are handled. It seems inside strings, it's unambiguous but inconsistent (you can't use quotes when already in a string, unless you use curly braces, then you have to, but outside you should). And outside strings, in "normal" PHP...well, it does weird crap like that.
    – mpen
    Commented Feb 20, 2011 at 19:49

11 Answers 11


Different types of languages have different uses, so the answer to this question really depends on what your going to be using it for.

For example, Perl is a very loose language, and I find it very useful for writing quick fixup or number crunching scripts. For solid robust projects I use C#.

You need to get the balance right for the target useage. The more strict it is, the longer you need to spend writing the code, but you get greater robustness, reusability, and easier to maintain.


What I look for in a programming language (as opposed to a scripting language) is consistency and strong typing.

In current programming languages it is possible to omit the semicolon for instance in certain places without becoming ambiguous (the last expression in a {} block is one). If a programming language allows you to omit characters in these cases, a programmer now has an extra problem; on top of the general language syntax she now has to know in which cases it is allowed to omit parts of the syntax too.

This extra knowledge is no problem for the programmer writing the code, but it becomes a burden to anyone who has to interpret existing code at a later point in time (including the original author after a while).

Your PHP example opens the possibility for subtle bugs in a program when the constant key would be added in the same context. The compiler has no way of knowing that is not what was meant, so the problem only becomes apparent at runtime instead of compile time.

  • 1
    Agree, you should limit possibilities for developpers : more possibilites => need to think more (should i proceed this way or that way) => less time to do actual work
    – Kemoda
    Commented Dec 21, 2011 at 10:39
  • I fail to see what the lack of implicit type casting has to do with the syntax of a language. Commented Jul 20, 2012 at 16:57
  • 5
    Also, when you read $_GET[key] you know nothing. You end up grepping the whole project just to know whether key is a constant or not. Such thing saves 0.5 seconds of writing and takes 20 seconds to read.
    – Zippo
    Commented Jul 20, 2012 at 21:37
  • If your language gives you options without distinction, the coding-style - whether codified or not - tends to standardize on one of them... Commented Aug 31, 2017 at 16:00

Every place where there's some ambiguity, the compiler needs to have some way to guess what the programmer really meant. Every time this happens, there's the chance that the programmer really meant something different, but didn't have the ambiguity-resolution rule down.

Writing logically correct code is hard enough already. Adding syntactical ambiguities may seem "friendly" on the surface, but it's an open invitation to introduce new, unexpected, hard-to-debug bugs into the codebase. Bottom line, be as strict as possible.

From your example, you mentioned that semicolons are optional in Python and JavaScript. For Javascript, at least, this is not entirely true. Semicolons are just as required in JS as they are in any other C family language. But the JavaScript parser is required by the language specification to insert missing semicolons under certain circumstances. This is widely regarded as a very bad thing because it tends to get your intentions wrong and screw up your code.


The answer to how loose you should make your language is equal to the answer of the question said in an Texas accent "How lucky do you feel, punk?".

  • I don't get it.
    – mpen
    Commented Feb 19, 2011 at 22:18
  • 4
    My bad attempt at a joke was that dynamic typing might bite you as the systems grow bigger and bigger, especially when adding inexperienced developers to the mix. In my experience systems of any value tend to grow bigger and bigger and have an increasing number of developers developing them. Having "Find all usages of symbol" or "Rename all" or "Safe Delete" or "Find errors in solution" then, is absolutely invaluable. Dynamic typing in the limited sense that VB is late-bound and does extensive type-coercion has caused many bugs in at current gig.
    – Henrik
    Commented Feb 19, 2011 at 23:02
  • Ergo, if you feel lucky about your project, for example lucky to have good and experienced devs, or lucky in terms of writing correct code; you may use dynamic typing.
    – Henrik
    Commented Feb 19, 2011 at 23:05
  • 2
    Ah... but this question was never really about dynamic typing :)
    – mpen
    Commented Feb 20, 2011 at 17:08
  • 1
    Ah, very true Raplh. I just tend to think of dynamic languages as more loose as they usually are more loose. You are right though.
    – Henrik
    Commented Feb 20, 2011 at 17:10

Everyone wouldn't have to work so hard for coding consistency if the languages didn't have so much variation. We don't like it when users make requests that unnecessarily increase complexity, so why should be ask that of our development languages?

  • +1: I totally agree. I do not see why principles like KISS and YAGNI should not apply to language design.
    – Giorgio
    Commented Aug 31, 2017 at 21:54

My personal preference is for the ability to have just enough strictness to catch my typos, but with as little extra boilerplate as possible. I talk about this issue at http://www.perlmonks.org/?node_id=755790.

That said, you're designing your language for yourself. You should make it be whatever you want it to be.

  • +1: ...The ability to have just enough strictness to catch my typos, but with as little extra boilerplate as possible. - Yes. Are you familiar with Anders Hejlsberg's plan for C#? He's making a conscious decision to emphasize "essence over ceremony". channel9.msdn.com/Blogs/matthijs/…
    – Jim G.
    Commented Feb 19, 2011 at 15:59
  • @jim-g: Thanks for the thought. I am not familiar with much of anything about C#. I have not worked in the Microsoft world for many, many years.
    – btilly
    Commented Feb 19, 2011 at 16:26

I like my languages to do what I mean. Generally that leans pretty hard towards loose. I also would like to be able to tag "strict" on an element or block to be able to debug/analyze that limited area.


I generally tend to fall on to the side of "What would make it easier for me as a programmer". Of course that can mean more than one thing. In Javascript there is almost no type checking, which works great until you hit a weird bug. On the other hand in Haskell there is a lot of type checking which puts more of the work up front but clobbers some classes of bugs.

To be honest I would check out a bunch of languages to see what they do and try to find a niche that none of them hit!

I don't think there is one obvious right way to do it, or at least if there is its not something people have found a consensus on yet. So by creating languages with different type systems we are learning.

Good luck.


I would suggest that a good programming language should have strict rules, which implementations would be expected to enforce consistently, but the rules should be written in such fashion so as to be helpful. I would further suggest that one should consider designing a language to avoid cases where the "Hamming distance" between two substantially-different programs is only one. Obviously one can't achieve such a thing with numeric or string literals (if a programmer who meant 123 instead types 1223 or 13, the compiler can't very well know what the program meant). On the other hand, if language were to use := for assignment and == for equality comparison, and not use a single = for any legal purpose, then would greatly reduce the possibilities both for accidental assignments which were supposed to be comparisons, and accidental do-nothing comparisons which were supposed to be assignments.

I would suggest that while there are places where it is useful for compilers to infer things, such inference is often most valuable in the simplest cases, and less valuable in the more complicated cases. For example, allowing the replacement of:

  Dictionary<complicatedType1,complicatedType2> item =
    new Dictionary<complicatedType1, complicatedType2()>;


  var item = new Dictionary<complicatedType1, complicatedType2()>;

does not require any complicated type inference, but makes the code vastly more readable (among other things, using the more verbose syntax only in scenarios where it's needed, e.g. because the type of the storage location doesn't precisely match the type of the expression creating it, will help call extra attention to places that may require it).

One major difficulty of attempting more sophisticated type inference is that ambiguous situations may arise; I would suggest that a good language should allow a programmer to include information to the compiler could use to either resolve such ambiguities (e.g. by regarding some typecasts as preferable to others), determine that they don't matter (e.g. because even though two possible overloads may execute different code, the programmer has indicated that they should behave identically in those cases where either could be used), or flag those (and only those) which cannot be handled in either of the above ways.


To me, readability is most important.

To someone experienced with the language, a code fragment's meaning should be clear without having to analyze the context deeply.

The language should be able to flag mistakes as often as possible. If every random sequence of characters makes a syntactically correct program, that's not helpful. And if variables are automatically created the first time they are used, then misspelling client as cleint will not give you a compile error.

Besides the syntax, the language should have a clearly-defined semantics, and maybe that's even harder than deciding on a decent syntax...

Good examples:

  • In Java, "1" is a string, 1 is an int, 1.0 is a double, and 1L is a long. One look and you know what it is.

  • In Java, = is the assignment. It assigns the value for primitive types and the reference for reference types. It never copies complex data or compares.

  • In Java, calling a method needs parentheses und this way is clearly distinguished from variables - so, if there's no parenthesis, you don't need to search for a method definition, it's just reading data.

Bad examples:

  • In Java, a symbol like client can be nearly anything: a package path element, a class or interface name, an inner class name, a field name, a method name, a local variable, and even more. It's up to the user to introduce or obey naming conventions or not.

  • In Java, the dot . is over-used. It can be separator within the package name, separator between package and class, separator between outer and inner class, connector between instance expression and method to be invoked on the instance, and many more.

  • In many languages, the curly braces of the if blocks are optional, leading to nasty mistakes if someone adds one more statement to the (not really existing) block.

  • Infix operators: sometimes I have to stop at a numerical expression and think hard what it means, step-by-step. We are all used to write math expressions in infix notation like a * b / c * d + e. Most of the time we remember the precedence of multiplication and division over addition and subtraction (but did you realize that we're not dividing by c*d, but dividing only by c and then multiplying by d?). But there are so many additional infix operators with their own precedence rules and in some languages overloading that it's hard to keep track. Maybe enforcing the use of parentheses had been a better approach...

  • You've mostly talked about ambiguity, but there can be multiple ways of doing the same thing without creating ambiguity. Maybe we can have two multiplication operators, * and ×. Both 5*3 and 5×3` mean the same thing, and an experienced programmer knows exactly what they mean without having to look around at surrounding context. The problem, however, is that there's now two ways of doing the same thing and someone might swap between them throughout the program. I believe this is what I was more concerned about when I asked the question.
    – mpen
    Commented Aug 31, 2017 at 20:59

You might consider an analogy with natural language. In email, are you a Grammar Nazi? Or are you okay with some grammatical errors, such as split infinitives, missing conjunctions, or misplaced modifiers. The answer boils down to personal preference.

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