On Saturday, September 21, 2013 at 7:04:09 AM UTC-7, Michael Daconta wrote:
>
> As you can see, the code has semi-colons in each required location. So, I
> ask you - why is the above code illegal?
>
Why is breaking the speed limit illegal? On many roads, it is set
arbitrarily low because that's the way the neighbors want it, with no
evidence that it makes anyone safer. In the case of Go, the spec defines it
that way, that's why it is illegal. If you've ever written bash scripts,
you likely know there are some very weird choices in that language too.
That doesn't keep people from using it.
> All I've heard so far, is that "it is because the automatic insertion of
> semi-colons requires this stupid behavior". Given the above code should
> require NO automatic insertion of semi-colons - why the stupid behavior?
>
Calling the behavior stupid will not win anyone over to your side.
> As for the folks on the thread saying "get over it" - sorry, I would turn
> the question back to you and say - why are you blindly accepting something
> so foolish? There are things in a programming language that MUST be
> enforced, this should not be one of them.
>
I've spent several decades programming. Brace style has never affected my
ability to code effectively, and I've always needed to be flexible, in
order to adopt to the tastes of the people I work with. So in that sense,
it doesn't matter. Indeed, given a choice, I mostly prefer something that
conserves on vertical space, since the view in my editor is a critical
constraint, thus preferring to have braces on the same line. Python goes
one step further and eliminates both braces, which is a step too far, for
me. Entirely a personal preference, from what I can tell. As for having Go
enforce a particular format, it turns out to be very valuable, because it
means that looking at diffs in source control never has the problem of
showing just changes to spaces, and you can look at anyone else's code, and
see the exact same style. THAT was a very valuable design choice.
As for accepting something so foolish, *every* language has design
trade-offs. I do not accept them blindly, but accept them deliberately.
> So, either the language designers must admit their language is poorly
> designed,
>
Nope - they just made a design trade-off that you happen to disagree with.
> or they need to fix the problem!
>
The Go community seems to be *very* pragmatic, and evidence driven. The
language doesn't have features unless their needed. Can you define and
demonstrate the problem? Can you show the brace style gets in the way of
effective Go programming? If you can come up with relevant evidence, then
you probably stand a chance of convincing people that the language at least
needs to allow for braces on the next line, even if it isn't the default.
Given that the industry has been chasing this question for decades, though,
I don't think you'll find the evidence.
> Ignoring the problem or flippantly asserting there is no problem,
>
The language designers used their combined decades of experience and made a
choice. The community has accepted this design trade-off. Whereas, you
assert there is a problem, but provide no data. That's the source of the
skepticism.
> is the worst thing they can do as it goes against the very reasons you
> design a new language for in the first place.
>
On the contrary, they made the language to suit their needs, and their
background. Your mileage may vary.
Eric.
>
> - Mike
>
> On Saturday, September 21, 2013 9:49:42 AM UTC-4, Rémy Oudompheng wrote:
>>
>> Compiler laziness is a minor argument. Humans must also understand
>> semicolon insertion rules, justifying the choice of simple rules.
>>
>> The choice of a standard formatting also makes the use of grep easier.
>>
>>
>> 2013/9/21, Michael Daconta <michael...@gmail.com>:
>> > I assume you say this with tongue-in-cheek; however, I cannot believe
>> this
>> > design decision was made. For something to borrow so liberally from C
>> only
>> >
>> > to enforce "one-true" bracing style is frankly ridiculous.
>> > When someone has coded for a long time using their favorite bracing
>> style,
>> > the numerous hours of frustration to learn this new language become not
>> > worth it. Just due to inadvertent, habitually return to a bracing
>> style
>> > the language designers deemed improper - which, in fact, is actually
>> due to
>> >
>> > the laziness of their compiler. I believe they could improve the
>> compiler
>> > to correct this. So, while I could write my own compiler for this -
>> there
>> > is actually an easier solution, just ignore this language until the
>> > language designers do the right thing. And if not, ignore it all
>> together.
>> >
>> > Though I like many features of the language from looking at the "go
>> tour",
>> > I can take it or leave it.
>> >
>> > While I new this post could be flame bait, I actually had to post it
>> > because I was so shocked that Google would make such a foolish error.
>> > Really, lose adoption over compiler laziness? Give me a break...
>> >
>> > - Mike
>> >
>> > On Saturday, September 21, 2013 12:45:58 AM UTC-4, Dave Cheney wrote:
>> >>
>> >> I, For One, welcome the One True Brace style.
>> >>
>> >> On Sat, Sep 21, 2013 at 11:58 AM, Michael Daconta
>> >> <michael...@gmail.com <javascript:>> wrote:
>> >> > Hi Go fans,
>> >> >
>> >> > I frankly was shocked to learn that a program like:
>> >> >
>> >> > package main;
>> >> >
>> >> > import "fmt";
>> >> >
>> >> > func main()
>> >> > {
>> >> > fmt.Printf("hello, world!\n");
>> >> > }
>> >> >
>> >> > ... is currently illegal in go with the error:
>> >> >
>> >> > # command-line-arguments
>> >> > .\hello.go:6: syntax error: unexpected semicolon or newline before {
>> >> >
>> >> > From reading the newsgroups, I see that this is illegal due to the
>> >> automatic
>> >> > insertion of semi-colons; however, what if I added my own
>> semi-colons
>> >> into
>> >> > the code as in the above. From a language perspective the above
>> should
>> >> >
>> >> be
>> >> > legal Go code. To me, it seems like a hack for convenience (making
>> >> > semi-colons optional) has forced a K&R style on everyone.
>> >> > For me, this is a show-stopper. Frankly, I am surprised that Google
>> >> would
>> >> > enforce a coding style (K&R) while saying that "go fmt" frees you
>> from
>> >> > worrying about divergent coding styles. Sorry, google - you cannot
>> have
>> >> >
>> >> it
>> >> > both ways. Unless the Allman-style code above is illegal in the
>> >> language
>> >> > (which makes no sense from a language semantics point of view) - get
>> the
>> >> >
>> >> > compiler to accept it. Period.
>> >> >
>> >> > Yes, I know I can write my own translator - but why? Heck, I can
>> just
>> >> stick
>> >> > with Java...
>> >> >
>> >> > C'mon Google, when trying to pitch a new language, you can (and
>> should)
>> >> >
>> >> do
>> >> > better than this...
>> >> >
>> >> > - Mike
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> Groups
>> >> > "golang-nuts" group.
>> >> > To unsubscribe from this group and stop receiving emails from it,
>> send
>> >> an
>> >> > email to golang-nuts...@googlegroups.com <javascript:>.
>> >> > For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to golang-nuts...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
