Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
What are good programming habits to you? –  LennyProgrammers Feb 19 '11 at 8:46
11  
This is a topic for a holy war. –  delnan Feb 19 '11 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 Feb 19 '11 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 Feb 19 '11 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 Feb 20 '11 at 17:14
show 14 more comments

9 Answers 9

up vote 17 down vote accepted

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.

share|improve this answer
1  
+1 for maintain. –  Loki Astari Feb 19 '11 at 14:31
add comment

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.

share|improve this answer
    
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 Dec 21 '11 at 10:39
    
I fail to see what the lack of implicit type casting has to do with the syntax of a language. –  dan_waterworth Jul 20 '12 at 16:57
    
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. –  Zippoxer Jul 20 '12 at 21:37
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
add comment

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?".

share|improve this answer
    
I don't get it. –  Mark Feb 19 '11 at 22:18
2  
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 Feb 19 '11 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 Feb 19 '11 at 23:05
2  
Ah... but this question was never really about dynamic typing :) –  Mark Feb 20 '11 at 17:08
    
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 Feb 20 '11 at 17:10
show 5 more comments

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.

share|improve this answer
    
+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. Feb 19 '11 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 Feb 19 '11 at 16:26
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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()>;

with

  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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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