jimmy frasche | 1 Jan 01:38 2010
Picon

Re: Re: Style Sensitivity

On Thu, Dec 31, 2009 at 3:52 PM, Alex Combas <alex.combas@...> wrote:
> The only thing that is absurd is saying that this is in any way like a holy
> war.
> There needs to be a "holy war" version of Godwin's law.

http://www.outpost9.com/reference/jargon/jargon_23.html#TAG897

There also needs to be a brace/whitespace version.

Pete Wilson | 1 Jan 05:27 2010

Re: Proposal of channel stabilizer

I second this thought, wholeheartedly. I posted something by
'replying' to the digest list, so I suspect I've done harm (if only
through confusion), for which apologies.

Here's what I said (rephrased):

Semantics are very important. Go's major contribution to the universe
(from my point of view) is being a language with some chance of
adoption by an interesting number of folk which actually wraps
concurrency and communication into the language. This is terribly
important. Typing more than is theoretically possible through the use
of obscure merde like "generics" (could somebody explain to me exactly
what I get if these exist and what I have to pay to get them?) is many
levels of importance less important. We have automation tools to
handle repetitive crap.

The next most important thing is language scope. Stuff like C++ - with
its whatever-they-ares - libraries? object families? inheritances? eh?
- create a universe that is simply much too big to fit in an average
human brain - let alone the problem of fallacy of hierarchical
objects. Go is about as complex as it's worth getting. Don't pile more
merde in.

Syntactic stuff like semicolon rules is nice to get right(er). It's
fun to argue about. But it ain't substantive. Semantics and simplicity
is what matters. Don't lose it.

(usual 'just my 2c' disclaimer.)

-- Pete
(Continue reading)

Jessta | 1 Jan 06:09 2010
Picon

Re: Re: Style Sensitivity

This is awesome. The attempt to avoid endless discussions about
formatting by creating a standard format seems to have actually lead
to more of a discussion of formatting. But I guess it's better that
the discussion is here in the language mailing list, instead of in the
mailing list of every project that ever uses go for decades to come.

The semicolon change has resulted in the enforcement of the bracing
style that was already the standard in gofmt.
If you gofmt your code, then it will compile. Which to me seems
perfectly reasonable for the small minority that will be avoiding the
standard style. Just add gofmt'ing to your make file and forget about
it.

Myself, I've been having great trouble adapting to not putting ()
around my if,for statements, and I'm always putting semicolons at the
end of everything and forgetting the order of name and type in
variable declarations, but I believe given a few months of coding I'll
be used to it.

Since 99% of go code will be in the standard style is seems silly to
add extra hacks to the compiler parser just to accommodate a minority
of code. There are plenty of much more important things for the
developers and the community to worry about(generics,optimisations,
new GC, more library support etc.).

ps. I'd like the bike shed to be purple with pink poker dots because
it brings out my eyes.

- jessta

(Continue reading)

Tom Abernathy | 1 Jan 07:55 2010
Picon

Re: release.2009-12-22

I am totally at a loss to understand why you thin that recursion to
function literals is an important topic.
Why would someone define an function as a literal if they needed to
reference the function?
What advantage is gained by programming in this manner?
Is it a performance issue (speed or code size?) ?
Does is simplify the code? If so, how? For maintenance? For
reusability?

KenF | 1 Jan 09:03 2010
Picon

Happy New Year!

Happy New Year!

Best regards,

Ken Friedenbach

Nigel Backhufrst - I-E-A | 1 Jan 09:26 2010
Picon

Re: Re: Style Sensitivity

Hi Ben

On 31/12/2009 23:48, Ben Tilly wrote:
> On 12/31/09, Nigel<nigel@...>  wrote:
> [...]
>    
>>   In 1994 I did an experiment in which I had a the same code manually
>>   examined by different code examiners.  There were two versions of the
>>   code, one with aligned braces and the other with opening braces on the
>>   same line as the statement.  The code did contain flow logic errors.
>>   Where the braces were aligned 98% of the examinations picked up the
>>   error, however with non-aligned braces this dropped to 64%.  For this
>>   reason I would press for a change that will allow opening braces to be
>>   placed on the following line.
>>      
> I would love to have more details on this experiment.  Because if
> there is a demonstrable difference in ease of auditing code based on
> formatting style, I would change my own personal style in a heartbeat.
>
> In particular I would like to see details on any possible causes of
> the difference.  For instance it is very easy for me to believe that
> you'd get such a big jump in quality of inspections if the inspectors
> were used to one formatting style and were faced with inspecting code
> formatted with a different one.  But if your inspectors did worse in
> inspecting code formatted with a style they are used to writing, that
> would be strong evidence for that style being objectively inferior.
>
>    
The experiment was actually set up to assess the effectiveness of two 
different approaches to teaching Code Inspection standards for a SCP 
(Continue reading)

Helmar | 1 Jan 09:42 2010
Picon

Re: release.2009-12-22

Hi,

On Jan 1, 1:55 am, Tom Abernathy <tom.aberna...@...> wrote:
> I am totally at a loss to understand why you thin that recursion to
> function literals is an important topic.

why programming is important? I never had to program my mobile phone
to get it working. There always was software with it.

> Why would someone define an function as a literal if they needed to
> reference the function?

That function is always referenced - and be it by the pointer that
references the function.

> What advantage is gained by programming in this manner?
> Is it a performance issue (speed or code size?) ?
> Does is simplify the code? If so, how? For maintenance? For
> reusability?

About all of it. It's simpler to understand if you have a hint that
there is recursion involved (when reading the source you do not need
to remember what variable this func is assigned to and so on).
Also say you want to have an array or map of anonymous functions. If
one or more of these functions should be recursive, it's a not so nice
task to always have to define variables and keep track of what is what
and calls what. Say you also want to write a source code generator -
you are about to loose the ability to use recursion in such
environments. I have for something like a Postscript-like interpreter
things like
(Continue reading)

msw | 1 Jan 10:11 2010
Picon

Re: Style Sensitivity

Thank you for the detailed explanation you provided.

Unfortunately, post hoc data analysis is rightly avoided in such
experiments as (using standard significance tests) 1 out of 20
correlations found by such methods will be completely spurious. These
retrospective tests are often derisively called "shotgun analysis"
because they are almost guaranteed to yield some result when the issue
under test fails to generate the anticipated result: given enough
variables, the shotgun will hit something.

This does not imply that the effect doesn't exist, but neither does it
provide compelling support that it does. Such results can only inform
that a follow-on study explicitly testing new found correlation be
conducted.

(I say this having fruitlessly hunted the snark in a research program
conducted in my undergraduate days only to learn that my endeavors
were folly from the start.)

On Jan 1, 3:26 am, Nigel Backhufrst - I-E-A <ni...@...> wrote:
> I do not have the exact numbers to hand as the company ceased trading
> some eight years ago and the records no longer exist so far as I am
> aware. So far as I can recall just under three hundred people went
> through the code inspection course on a roughly fifty fifty split
> between those attending seminars and those doing the online course.  We
> found that the form of presentation actually made very little difference
> to things.  The braces result was not something we were looking at or
> particular interested in at the time of the experiment.  It was just
> something that came out of the analysis.

(Continue reading)

befelemepeseveze | 1 Jan 11:12 2010
Picon

Re: CGO question

Many thanks for the detailed info and Happy New Year.

befelemepeseveze | 1 Jan 11:37 2010
Picon

Re: release.2009-12-22

On 1 led, 09:42, Helmar <hel...@...> wrote:

> About all of it. It's simpler to understand if you have a hint that
> there is recursion involved (when reading the source you do not need
> to remember what variable this func is assigned to and so on).

Declaring a named function is more or less the same as once only
assigning a function literal to a (top level) variable of the same
name. Is it also simpler to not to need to remember the identifiers of
named functions?

> Also say you want to have an array or map of anonymous functions. If
> one or more of these functions should be recursive, it's a not so nice
> task to always have to define variables and keep track of what is what
> and calls what.

Why variables, why not the usual named functions? You can put those in
a map/vector too.

> Recursion is a basic programming facility and Go did a good job for
> named funcs. It simply missed the simple recursion of function
> literals (aka nonames) by concept as of now. Well, it might be I'm
> wrong and recursion is something completely useless.

I think that completely useless is to insist on using only function
literals in a situation where they can't do what you want instead of
creating named functions which would be IMO a pretty natural choice.
Also you get for free the recursion capabilities you would like to
have. I fully respect your right to choose your coding style, but for
me it's a very confusing one. And I don't think it's needed to extend
(Continue reading)


Gmane