- It is easier on the eye, especially when somone else has to read through & understand it

- I find it quicker to code

That said there are some aspects where C-style is superior - so a combination of the 2 might work well! Invent your own "mash up" style (as long as it is not too confusing).

Also, whitespace based indentation works in Python because Python statements tend to be fairly short. (The python indentation rules are easily understood.) Haskell layout has been somewhat more difficult to understand (at least for me). I have been writing Haskell code and usually it works, but there have been problems due to failure to indent when I should'v, which were incredibly confusing to debug.

In python, it's hard to fuck it up: after a colon, you always newline and indent.

But what about:

    if True: print "Yep"

if True: print("Yep")

Some features of Python are only really meant to be used at interactive prompts, like import STAR ( I can't write star?)

virtual const std::string& getCommand() const throw() { return m_command ; }

For example, I recently needed to do some Run-Length Encoding:

    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 tyrant:
    divide(); conquer()

Indentation-as-a-divider is definitely easer on the eye than curly braces. But C-stlye has some handy bits and pieces to pick up (expecially on the OOP side of things - and also in the type-setting; though that has improved in python)

I find superlong indented blocks in Python a bit awkward, although can't explain why. When I look at a long class definition, for example, it just begs to be closed with end or "}". Small blocks though look definitely better without the block braces.

I'm thinking about introducing an optional end and leaving it to the taste of a programmer. Not sure yet.

    def something:
        alpha()
        omega()
    #end

  def something:
    ...
  end def

I can't say I'm a fan, but at least you'd be making it mean something if you did that.

(Also: why make it optional at that point? Seems like it should be required for simplicity's sake)

It would be nice, however, to have some optional verification mechanism that allowed you to stay minimalist for as long as you wish, and to use closing tags for verification and/or aesthetical reasons - for example, when closing a superlong block.

My point with braces is that you dont have to indent the code then - which is dangerous :)

I have inherited a couple of PHP and C projects that have taken weeks just to indent to be readable - before i can even begin to work on them! (admittedly that is more of a PHP problem). Forced indentation makes definite that everything is obvious: addign curly braces is purely asthetic IMO :D

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

Multi-line lambdas aren't such a must-have. You can always use named functions. So, Python's syntax doesn't mean you can't do something, just that you have to give it a name if it's going to be multi-line rather than being anonymous. Plus, if you really care that much, just make multi-line lambdas an exception. Heck, look through the proposals people have made for Python to have multi-line lambdas. You can make multi-line lambdas that really fit with the Python syntax (in my opinion).

So, don't make lambda the deciding factor between Python and C syntax.

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.

Just don't use tabs, ever. If you have whitespace problems you can simply grep for tab characters and remove them.

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 agree that typing code isn't as fast as typing English (because of all the non-standard characters we have to use []{}()/\~ and so on) but you could help to minimise this gap.

You can definitely improve upon it, though -- the syntax for anonymous functions is a bit cumbersome, in particular. The Lua syntax was deliberately kept tiny to reduce the memory footprint on embedded systems, so some things like switch/case statements are missing, but your language likely won't have the same constraint.

Also, you might want to get an interpreter working 100% first before writing the compiler, as it will be easier to make changes to smooth out emergent quirks in the language. Just a suggestion.

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.

    x = 1
    y = 2

    x = 1; y = 2

    x = 1 y = 2

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

The reason that python has problems with multi-line lambdas is that python lambdas are not like other python functions. The "body" of a python lambda is an expression while the body of other python functions is an indented statement block, with an implicit "return None" for fall through, requiring an explicit "return" for some other value.

Your lambdas could be like other functions. Or, horrors, you could define two forms, "anonymous" and "expression", where "expression" is like python lambdas and "anonymous" defines an anonymous function whose body is just like other function bodies (ie multi-line, requiring explicit "return" s).

do-while/until may pose bigger problems.

   CLIKE

   def factorial(x) {
      return ( x<=2 ? 
         1 : 
         n*factorial(n-1) );
   }

   PYTHONLIKE

   printf(factorial(10))  # note ';' not needed

So I'd recommend going all Python or mixing Python plus some kind of multi-line lambda support.

If your users are independent web developers then python-style would make sense. If you are aiming at more corporate-comfortable programmers, braces are de rigeur.

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

I would say that as long as it's either easy to create syntax highlighting or the community gets some excellent syntax highlighters, it doesn't matter which way you go.

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')

2. Built-in multithreading:

  proc1() && proc2() && finish_sem

3. You can do

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

  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

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

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

I like how easy python tends to be to read, but I dislike the fact that editors' autoindentation can not possibly work without adding otherwise gratuitous pass statements.

->

::

>>

<<

__ugly__

"People" are getting over it all the time. Lisp is back, baby! Don't miss the elegance train.