why not optional python syntax?

[DusanB]

One of the most annoying things for significant minority of people in
modern programming is C++ like syntax. You can find it in many
languages (C++, Java, PHP) but, it doesn't necessarily make it good.
Yes, I know many people like it (for a while I did, too) but I feel it
is pointless. Pythonic syntax makes sense, because since everyone
indent lines anyway, why not use something everyone does already in
language? How many times code refused to compile because we forgot
semicolon somewhere?

Therefore, I propose:

if there is line of code in the beginning of file that says something
like:
--syntax: python--

Compiler shall process code as python syntax. We could have other
people's favorite syntaxes (Delphi, JavaScript etc) too. Processing
syntax seems like the easiest part of compiler to make to me anyway.
Language features would still work exactly the same.

regards,

Dusan

[Dennis H]

Well with the new semicolon rules you won't have to worry about
leaving off a semicolon. =) Anyway, a big problem I see with your
suggestion is that it'll make it a bit harder to read other people's
Go code, which might fracture the community, somewhat. In addition,
it'll make the gofmt situation a bit more complicated as it'll have to
support other syntax types... Besides, Go's syntax isn't that bad, to
be honest. For what it's worth, I'm against the proposal.

[Federico G. Benavento]

you can't thrust something you can't see

--
Federico G. Benavento

[Andrew Gerrand]

How does one express a Go type signature in a Python syntax? Pointers?
Channels? Go-routines? Function definitions? The :=
declare-and-initialize construct?

The syntax of Go exists principally to support its specific
feature-set. Beyond that, its "one formatting scheme to rule them all"
approach (see: gofmt) is a key design feature.

Shoe-horning the language into another syntax seems like a lot of
messy work, and - to an extent - a solution in search of a problem.

See the Language Design FAQ for more insight:
http://golang.org/doc/go_lang_faq.html#different_syntax

On Mon, Dec 14, 2009 at 12:07 PM, DusanB <dben...@gmail.com> wrote:
> How many times code refused to compile because we forgot
> semicolon somewhere?

Often enough, but such errors are easy to find and fix. I have had
more trouble correcting tabs-vs-spaces indentation issues while
collaborating on Python code than I have with wayward semicolons.
Additionally, semicolons are now optional in Go.

Cheers,
Andrew

[ziyu_huang]

No, language doesn't need to be indent for human readable, always.
Think about java-script.Many js library become smaller when it compress
(actually just remove indent, the whitespace).
Go could be good script language when it mature enough, IMO. Size
does matter on internet. I think python make mistake on this.
(Ya, it's good for human readable, I totally agree).

[Qtvali]

On Dec 14, 4:27 am, Dennis H <arctic...@gmail.com> wrote:
> Well with the new semicolon rules you won't have to worry about
> leaving off a semicolon. =)  Anyway, a big problem I see with your
> suggestion is that it'll make it a bit harder to read other people's
> Go code, which might fracture the community, somewhat.  In addition,
> it'll make the gofmt situation a bit more complicated as it'll have to
> support other syntax types...  Besides, Go's syntax isn't that bad, to
> be honest.  For what it's worth, I'm against the proposal.

I personally think that if gofmt exists, it could just convert things
into one syntax or another. This feature could be included in
versioning system. I have thought the same thing about different
languages (but given up this thought as it would not make sense with
variable names etc.), but now think that certain syntactical things
could be solved by this. If gofmt was built-in to versioning syntax
and cleaned code on commit (or didn't accept uncleaned code), then it
would probably be possible to just show the code to different people
in different ways.

But it can be a complex case to express every one-line code part etc.
in pythonic syntax, also there is some meaning in having control over
each character.

I think python syntax:
* Looks cleaner and connects syntax rules with style rules
* Doesn't allow many nested blocks easily (gets to one-character
indent) - anyway, there are some people unable to orient themselves in
many nested blocks because of some brain disorder or smth. even if
they are good programmers; at least someone told me that.
* Doesn't take away the freedom of style if we have gofmt anyway

[Russ Cox]

Gofmt is not going to become a magic grab bag of
syntaxes. It's hard enough to format one syntax well,
and it's bad enough that gofmt currently has two syntaxes.
We want to go back to one, not up to three.

If Python syntax is so important, perhaps you'd be
interested in using Python instead? http://python.org/

Russ

[Steven Blenkinsop]

Fake syntax = fake features. Just imagine, you'd need a separate
debugger for each possible syntax, and many other tools. You might as
well have different languages. I don't see whats wrong with Go's
current syntax to be honest. Its simple and straight forward. I
personally like semicolons, but since they're going, going, gone, I
don't see what the complaint is against it.

[DusanB]

Well if semicolons are gone, then it's not as bad as I thought and Go
will look more like JavaScript than C++. I can live with that :)

Thanks to you all for contributing,

Dusan

[Dethe Elza]

On Dec 13, 7:12 pm, Qtvali <qtv...@gmail.com> wrote:
> I personally think that if gofmt exists, it could just convert things
> into one syntax or another.

gofmt exists for formatting Go syntax. If you want to write a
formatter that can convert between Go syntax and Python (or Python-
like) syntax, that would be an interesting exercise and perhaps a
useful contribution to this thread (especially if it recurs as often
as I expect it will).

That way the Go syntax and gofmt remain the canonical way to write Go
programs, but folks could (at least experimentally) work with the
alternate syntax without requiring any changes to Go. Which is how
experimental feature requests should work, really.

--Dethe

[Qtvali]

Package of Go is still the best place for implementing/prototyping
those - works on both compilers and is easier to change. Because Go is
better than C, it's clear.

> --Dethe