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.
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)
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)
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?
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)
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)
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)
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)
RSS Feed1922 | |
|---|---|
2898 | |
2962 | |
3409 | |
3866 | |
2618 | |
2496 | |
3240 | |
3415 | |
2206 | |
2862 | |
2375 | |
2484 | |
3167 | |
3718 | |
2914 | |
1995 | |
1975 | |
2158 | |
2274 | |
1796 | |
1614 | |
1981 | |
2270 | |
2238 | |
1648 | |
1557 | |
1654 | |
1188 | |
1561 | |
1950 | |
1510 | |
1541 | |
1633 | |
1516 | |
1381 | |
1413 | |
1964 | |
1564 | |
1260 | |
1412 | |
2930 | |
3775 |
