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

https://news.ycombinator.com/item?id=397440

by mojuba • 18 years ago

13 68 18 years ago

news.ycombinator.com

I'm designing a new programming language with a few interesting features. I call it a "stream-oriented" language and it is supposed to be highly efficient by design, almost at the level of C/C++.

The spec is ready, I even started writing a compiler. Almost everything is decided, except one major thing: C-style syntax vs. Python-style.

I like both, to be honest. The first is familiar - well, painfully familiar. The second is incredibly clean and aesthetical, but can create purely syntactic obstacles to introducing important features, such like multi-line lambdas. In principle, the compiler can support both styles on per-file basis, if that makes any sense, but most likely it doesn't.

I'd be happy to hear your opinions. If you are a C/C++ programmer, would you consider a Python-style language as your next tool, provided it is as efficient as C? If you are a Python programmer, are you happy with the style? Is there anything that can be fixed or improved in it? Finally, if you are a Lisp, JavaScript or Ruby programmer, would you consider a Python-like language if it gave you some new possibilities?

(Lisp style is not considered, as this new language is not a dialect of Lisp and it doesn't unify code and data.)

ErrantX3• 18 years ago

As a multi language user I prefer the python style for the following reasons:

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

mojuba9• 18 years ago

Something like

  if tyrant:
    divide(); conquer()

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

ErrantX3• 18 years ago

Oh yeh I didnt mean that at all.

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)

newt03113• 18 years ago

That's valid python.

carterschonwald• 18 years ago

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?

FalconNL3• 18 years ago

Completely agree. The main reason for my preference is that one of the things I hate most in C-style languages is that one-line functions take up three or four lines (depending on whether or not you use K&R style). This greatly increases the amount of scrolling you have to do.

lincolnq• 18 years ago

I've found that I really don't like this, aesthetically (mixing nesting styles in code looks bad)

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.

newt03113• 18 years ago

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.

Zaak• 18 years ago

If you haven't already, take a look at Haskell syntax. It allows mixing indentation with braces. Parsing it is a bit harder of course, but I feel it really does provide the best of both worlds.

mdasen• 18 years ago

I really like Python's style.

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.

martythemaniak• 18 years ago

I haven't been coding Python that long, but so far multi-line lambdas are the only downside I've seen to the significant whitespace syntax.

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

davidw3• 18 years ago

I've used Python in the past and never once had problems with the 'whitespace thing'. However, I think it is limiting for things like templates where you want to sort of abuse the language and mix it up with text. Also, it seems to put lots of people off, and even if they're being a bit silly, it may be a consideration in terms of your goals of having the language adopted.

mojuba9• 18 years ago

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.

joe_the_user• 18 years ago

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.

lacker2• 18 years ago

When are your editing tools so limited you must use tabs mixed with spaces? That doesn't really make sense.

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

shaunxcode• 18 years ago

Honestly consider the smalltalk approach - particularly keyword parameters. The one thing I would do differently is use { and } for lambdas so you can use [ ] for arrays.

lisper• 18 years ago

Note that Python effectively has an open-brace (the colon) but no close-brace except for unindent. Personally, I hate this because if I'm in emacs and I hit the tab (autoindent) key the result may or may not be what I want. I personally use a programming style where I use a PASS statement as a close-brace so my code can always be safely autoindented without changing its semantics. But this is rather ugly. It would be better to have a less obnoxious but still backwards-compatible close-brace, like ## or maybe #> Some day I'll hack emacs-mode.elisp to support this.

windsurfer• 18 years ago

To me, it doesn't really matter. As long as whatever editor I'm using has a good syntax highlighter, adapting to the language is easy.

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.

time_management• 18 years ago

Even if you're not allowing macros and code-as-data, you may want to consider Lisp-style S-expressions. It doesn't take long to get used to the parentheses, especially given that good Lisp code uses indentation to such an extent that most of the parentheses "disappear" for a human reader.

qqq• 18 years ago

python except make the meaningful whitespace thing optional. make a way to disable it. it's a problem in some contexts.

Allocator2008• 18 years ago

Borland SilkTest (4-Test) uses indentation instead of brackets. Otherwise it is similar to c/c++. I don't know though. I still kind of like the curly brace, aesthetically speaking!

gsmaverick• 18 years ago

Care to share your language (spec, basic compiler, etc)

mojuba9• 18 years ago

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.

bkudria2• 18 years ago

Cool! Keep us updated, please!

lacker2• 18 years ago

Just make sure you have for loops that use Python style "for x in alist" syntax rather than C++ style "for i = 0; i < alist.size(); ++i" syntax.

mojuba9• 18 years ago

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

earthboundkid• 18 years ago

Here's my advice about the most important thing Python does:

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

Why is this important? Because it's such a damnably subtle bug. But what if people want to do something like if r = get_result(): r.do_something()? Make them write if r with r as get_result(): r.do_something() instead.

jcapote• 18 years ago

Whatever ruby uses...

silentbicycle2• 18 years ago

You might get some ideas from the Lua syntax (http://lua-users.org/wiki/SampleCode). It's a nice compromise between the Python and C syntaxes; despite not having syntactically-significant whitespace, it tends to look about as clear as Python, IMHO.

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.

mojuba9• 18 years ago

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.

jcromartie• 18 years ago

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.

silentbicycle2• 18 years ago

The main Lua book points out that such code is "ugly, but valid", and leaves it at that. It seems to me that "x, y = 1, 2" would be cleaner, if someone were determined to make it a one-liner.

rw2• 18 years ago

Why would you disallow macros in the Lisp style?

apgwoz• 18 years ago

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.

rw2• 18 years ago

You said: Because people can't get over Lisp's lack of syntax.

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

mhartl• 18 years ago

Having programmed in both Python and Ruby, I've come to appreciate Ruby's combination of clean syntax (no semicolons or curly braces) with a required end keyword (making it suitable as an embedded template language, among other things). Python only has the first, and it's (slightly) the poorer for it.

cosmo7• 18 years ago

The best answer isn't necessarily the right answer. You should consider which style is closest to your likely users and try to appeal to them.

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.

mojuba9• 18 years ago

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.

inklesspen• 18 years ago

That's funny; I've used Python extensively in webapps and I'm very happy with it. I use Mako for templating. http://www.makotemplates.org/

softbuilder• 18 years ago

May I make a suggestion? Instead of choosing one or the other, why not play with the syntax a bit? Pick one and try it out on a small but non-trivial task. Then make small changes and iterate. Maybe let some friends play with different flavors of it. This may take more work but the end result will probably be more genuinely useful and your language will probably find more users.

cabalamat• 18 years ago

Why not allow both? To resolve ambiguity, there could be keywords CLIKE and PYTHONLIKE which determine how the code is to be parsed from that point, e.g:

   CLIKE

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

   PYTHONLIKE

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

Incidently I'm writing a language that'll have C-like syntax which will then be compiled into Lisp-like intermediate code. The Lisp-like code will be available to the programmer, who will thus be able to inspect the syntax tree, write Lisp-like macros, etc. Furthermore, the programmer can embed the Lisp-like code inside normal code (like inserting assembler inside a C function).

riobard• 18 years ago

I'm a Python programmer. Definitely loved the indentation-based syntax -- so much cleaner and more readable than C-style syntax.

maw• 18 years ago

C style but where an error is thrown/compilation aborts/etc whenever inconsistent indentation is found.

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.

kentosi• 18 years ago

One point I want to raise is that of how fast the code is to type. If you can come up with an elegant syntax that doesn't require characters that need key-combinations ("Ctrl" + "[" for an open-brace, "Shift" + "9" for open-bracket, etc) then that would be awesome.

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.

anamax• 18 years ago

> can create purely syntactic obstacles to introducing important features, such like multi-line lambdas

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.

tedshroyer• 18 years ago

I don't have a syntax preference, but there are some things that I don't enjoy typing or reading.

__ugly__

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

Related Stories