> do { ... } while <cond> is the only construct I some times miss, but then
> again, it occurs fairly rarely in my code, so for now I'm rather happy to
> just rewrite it in another style.
When I programmed in C, I found it pretty rare to use do...while.
These days I think of it more as a special case of:
for {
statements1
if cond {
break
}
statements2
}
where either statements1 and statements2 may be empty. I find it
almost as common to have both non-empty (not representable with
do...while) as to have statements2 empty and statements1 present.
I like the way things are tbh.
On 3 May 2018 at 16:06, Jesper Louis Andersen
<jesper.louis.ander...@gmail.com> wrote:
> The reason is simply that good syntax is a really hard problem which
> incorporates both tech and people.
>
> In principle, you can get away with very few things in a language before it
> is turing complete. It is enough to have eg 'WHILE <cond> do <stmts>' where
> stmts can form a block of statements. Or just have recursion, in which case
> you need no looping construct at all.
>
> In practice, convenience has it that people often add additional syntax,
> albeit it seems to me that imperative languages generally have opted on the
> side of having multiple loop constructs, whereas the functional side has
> done away with recursion, more or less. This is mostly a stylistic argument
> as things blend in the end: most modern compilers use SSA, which can be seen
> as a variant of implementing all loops as recursion. And vice versa,
> recursion is often implemented via tail call optimization: which implements
> a loop as a goto. It is just dependent on the glasses you wear, really.
>
> What is really going on is that you strike a delicate balance by adding more
> syntax:
>
> * Is the new construct going to be able to convey information (Ian's
> if/switch example - they are often used differently, which makes the reader
> know what follows).
> * Is the new construct going to add cognitive load on readers?
> * Is the new construct going to make it harder to learn the language as
> there are more information to take in?
> * Will the new construct add considerable expressive power in the form of a
> more succinct style?
> * Will it introduce a new class of common errors in programs?
> * Will the new construct interfere with existing syntactical groups in ways
> that makes the program harder to understand?
> * Will the semantics be clear? Will it take readers longer time to grasp
> what is going on?
> * Is it backwards compatible? How many code bases will it affect?
>
> People will not answer these questions the same, so a good solution must
> attempt the impossible, which is to cater to everyone's desires. This is why
> it is so hard to change syntax. It is also why one must accept a compromise:
> you can't have everything you want in a language, and you have to make
> certain sacrifices along the way. But it is still fair if people write to
> look for support for their preferences. Perhaps not in Go, but then another
> language might cater to you more and also pick up the suggestions.
>
> do { ... } while <cond> is the only construct I some times miss, but then
> again, it occurs fairly rarely in my code, so for now I'm rather happy to
> just rewrite it in another style.
>
> On Thu, May 3, 2018 at 3:46 PM <prades.m...@gmail.com> wrote:
>>
>> Can anybody point me to a single discussion on golang-nuts that led to a
>> significant syntax change? These threads are akin to bike shedding thus a
>> waste of time.
>>
>> Adding while provide nothing of value in a language that supports basic
>> looping. And for those who compare if and switch arguing it is equivalent,
>> you can't do type switches with an if statement.
>>
>> This is discussion is going nowhere.
>>
>> --
>> 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.
>
> --
> 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.
--
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.
