C-style vs. Python-style syntax: which one would you prefer for your next programming language?

Something like

  if tyrant:
    divide(); conquer()

is possible. Mixing curly braces with Python-style though wouldn't be very nice, I think.

    (defun indent-buffer ()
      "Indent entire buffer"
      (interactive)
        (indent-region (point-min) (point-max) nil))

    def something:
        alpha()
        omega()
    #end

  def something:
    ...
  end def

how about take a page from haskell style syntax, which allows both inferring the block structure from indentation, but also always it to be explicitly denoted at well?

    import Control.Arrow
    import Data.List
    
    encodeRLE :: (Eq a) => [a] -> [(Int, a)]
    encodeRLE = map (length &&& head) . group
    
    decodeRLE :: [(Int, a)] -> [a]
    decodeRLE = concatMap (uncurry replicate)

    if True: print "Yep"

The not too confusing part is especially important. It is very difficult to cut features down and very easy to build them up. Simplicity is king.

I think you are making 2 good points here.

First, we went through transition from begin...end to {...} and it porbably wasn't as painful for conservative folks as it is now when going from {...} to indentaion. So one question for a language designer is to whether target conservative public or not.

Second, mixing two styles when, for example, generating markup makes Python a burden. They don't go well together. You have to focus on two things: what your code is doing and proper indentation at the same time, while with C-style languages you worry only about the code. Oh, and the "isolate code from markup" concept hasn't been proven to be effective in all situations. So another decision to be made is to whether the language is going to be used on the Web.

I developed a relatively large web app with Python. Python's meaningful whitespace is the primary reason I no longer use python.

When one is working on a server, the editing tools are sometimes limited and they thus can make seeing the whitespace hard. In another, smaller, Python project, we had whitepace errors that appeared and disappeared like ghosts. Even if you have tools that make seeing everything easy now doesn't that you will have them later, on another system - especially, sooner or later spaces and tabs will get confused and be invisible.

I haven't programmed in C for years but the meaning of C programs is still obvious at a glance to me. After being away from python for a couple of years, the meaning of python program is opaque to due to the meaningful whitespace syntax. I know I could pick python up again if I tried but this indicates to me that python's syntax is not as natural as what Steve McConnell calls block structure. The end of a block is just as important to find as the start and so should be just as visible.

Writing one-line functions is, if anything, easier in Ruby than in Python.

Oh, and a syntax that requires as comments to show a normal program constructs is broken virtually by definition.

I can understand the appeal of the syntax. The syntax indeed appealed to me at one time and I enjoyed the rest of the language. But I think ultimately meaningful whitespace just does not work and will confined python to being a niche language.

I'm hoping to finilize the spec after this discussion, once a decision is made.

Three important features of the language that probably make it distinct are:

1. You can do something like:

  http_request('google.com') >> parse_headers() >>
    decode_chunks() >> decompress() >> tempfile('tmp')

where elements of the pipe chain are special functions that run as if they were separate threads or subprocesses. In fact they aren't. This is implemented without involving threads or even seperate stacks. Similar to the way you play with processes in the UNIX shell, only you do it within your program.

2. Built-in multithreading:

  proc1() && proc2() && finish_sem

which allows the compiler to analyze which parts of the program need thread safety.

3. You can do

  each c in customers:
    c.name + ' from ' + c.country >> std

and in case "customers" were marked as persistent in the declaration, this statement is translated to an SQL query for you. I'm not planning to implement this in the first iteration though. Hoping to polish the language itself before I can start building the "SQL killer" for it.

It has

  each i in list: ...
  each i in generator: ...
  each i in 0..9: ... # where 0..9 is a set, but this 
                      # construct is optimized down
                      # to a plain incremental loop

or in case I choose C style:

  each (i = list) ...
  each (i = generator) ...
  each (i = 0..9) ...

    >>> if x = y:
      File "<stdin>", line 1
        if x = y:
             ^
    SyntaxError: invalid syntax

Thanks for your suggestions. Yes, I checked Lua of course, it's neat, but as I said elsewhere, the if ... end syntax is not considered because I find it slightly less appealing than C and Python.

As for interpreter vs. compiler, I thought about this. One approach is to build a simple VM-based system with the entire language infrastructure in place (fundamental types, minimal standard library), which is not much harder than to write an interpreter with the same infrastructure. Then start fine-tuning the VM itself and possibly thinking about the JIC. The original compiler code, which is not the biggest part of your system, is left almost intact in this case.

As opposed to the "interpreter - first" approach, where you will be throwing away some significant portions of your code once you start writing the real compiler. I thought it would be a waste of time. Interpreters and compilers are too different in almost every respect.

Lua actually has a very odd syntax in that statements don't have to be separated by any particular whitespace.

    x = 1
    y = 2

and

    x = 1; y = 2

and

    x = 1 y = 2

are all equivalent.

I actually don't mind this. I've never encountered a situation where this style makes the meaning of the code undecidable.

Because people can't get over Lisp's lack of syntax. On the other hand, TCL is also a homoiconic language, which can support Lisp style macros and it too lacks popularity with the general programming community... I don't get it.

Interestingly though, those who used Python extensively in web apps aren't very happy with it, at least because of the problem of mixing indentations and markup - see discussions above. On the other hand, Python is successfully making it into the corporate world, which is obvious from job boards. Which is probably because Python's modularity and clean OO-ness plays well with the hierarchical culture of commercial vendors.

No, this is a tough question. I still don't know.