Re: Code conventions
Jon Scott Stevens wrote: on 1/10/02 1:16 AM, GOMEZ Henri [EMAIL PROTECTED] wrote: LOL! Are you taking these guys seriously? =;o) No, since Jon didn't participate to the thread ;) I heard that if you shorten the names of your variables and methods down to single letters, the execution speed increases by a factor relative to the amount of space saved in your .java files... :-) execution no, but it does reduce classloading time... of course, that's not enough of a reason to do it anyway :) -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. [EMAIL PROTECTED] Friedrich Nietzsche -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Stefano Mazzocchi wrote: Jon Scott Stevens wrote: on 1/10/02 1:16 AM, GOMEZ Henri [EMAIL PROTECTED] wrote: LOL! Are you taking these guys seriously? =;o) No, since Jon didn't participate to the thread ;) I heard that if you shorten the names of your variables and methods down to single letters, the execution speed increases by a factor relative to the amount of space saved in your .java files... :-) execution no, but it does reduce classloading time... of course, that's not enough of a reason to do it anyway :) If there is a performance benefit from the above, it sounds like a natural for the optimize switch of a java compiler. I wouldn't do it in code I write. I've seen enough obfuscated code maintaining other's perl scripts. ;-) Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
LOL! Are you taking these guys seriously? =;o) No, since Jon didn't participate to the thread ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
on 1/10/02 1:16 AM, GOMEZ Henri [EMAIL PROTECTED] wrote: LOL! Are you taking these guys seriously? =;o) No, since Jon didn't participate to the thread ;) I heard that if you shorten the names of your variables and methods down to single letters, the execution speed increases by a factor relative to the amount of space saved in your .java files... :-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 9 Jan 2002, Andrew C. Oliver wrote:
Date: 09 Jan 2002 00:07:00 -0500
From: Andrew C. Oliver [EMAIL PROTECTED]
Reply-To: Jakarta General List [EMAIL PROTECTED]
To: general at jakarta [EMAIL PROTECTED]
Subject: Re: Code conventions
It's only two little lines extra to include the {}'s,
Yeah, but those two lines will make my code run slower.
Don't you know?
The less space your source code takes, the less space
your class file will take.
And smaller classes run faster.
It must be true - 90% of people I've worked with seem
to live by that principle.
Add to that the fact that if it was hard to write, it should be hard to
read...
:)
Someone told me if you use a really small font like courier 6pt then
you don't even need an optimizing compiler.
Thanks to this conversation, I finally did think of a good reason to use
braces on a separate line (which I detest, but that's just me) -- if your
manager judges you on how many lines of code you write, you get two free
lines for every if statement.
:-)
-Andy
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Tim Vernum wrote:
It's only two little lines extra to include the {}'s,
Yeah, but those two lines will make my code run slower.
Don't you know?
The less space your source code takes, the less space
your class file will take.
And smaller classes run faster.
Well, I could be wrong, but if i remember it well, the same compiler produces the same
object code no matter the number of spaces, newlines, and tabs are between tokens,
statements, and so. They are not important for object code, just for readability.
Compiler could take a bit (quite bit) more to compile a file, but once the class is
generated, the result object file should be the same.
(Forgive me if i am wrong)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
LOL!
Are you taking these guys seriously?
=;o)
Have fun,
Paulo
-Original Message-
From: Carlos Alonso Vega [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 09, 2002 8:31 PM
To: Jakarta General List; [EMAIL PROTECTED]
Subject: Re: Code conventions
Tim Vernum wrote:
It's only two little lines extra to include the {}'s,
Yeah, but those two lines will make my code run slower.
Don't you know?
The less space your source code takes, the less space
your class file will take.
And smaller classes run faster.
Well, I could be wrong, but if i remember it well, the same
compiler produces the same object code no matter the number of
spaces, newlines, and tabs are between tokens, statements, and
so. They are not important for object code, just for readability.
Compiler could take a bit (quite bit) more to compile a file, but
once the class is generated, the result object file should be the same.
(Forgive me if i am wrong)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
snip/ :) Someone told me if you use a really small font like courier 6pt then you don't even need an optimizing compiler. Thanks to this conversation, I finally did think of a good reason to use braces on a separate line (which I detest, but that's just me) -- if +1 your manager judges you on how many lines of code you write, you get two free lines for every if statement. What is absolutely scary is I've worked at places where I would not have been the least bit surprised. I'd find that easier to conform to than a standardized IDE (which I've been in numerous places that did). :-) -Andy Craig -- eat POI its good http://poi.sourceforge.net - all those Hawaiians can't be wrong. The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Tim Vernum wrote:
It's only two little lines extra to include the {}'s,
Yeah, but those two lines will make my code run slower.
Don't you know?
The less space your source code takes, the less space
your class file will take.
And smaller classes run faster.
Well, I could be wrong, but if i remember it well, the same compiler
produces the same
object code no matter the number of spaces, newlines, and tabs are
between tokens,
statements, and so. They are not important for object code, just for
readability.
Compiler could take a bit (quite bit) more to compile a file, but once
the class is
generated, the result object file should be the same.
(Forgive me if i am wrong)
What about if you set the font size really small? LOL
-Andy
--
eat POI its good http://poi.sourceforge.net - all those Hawaiians can't
be wrong.
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On Wednesday, January 9, 2002, at 03:34 PM, Andrew C. Oliver wrote: What about if you set the font size really small? LOL -Andy Perhaps Microsoft just has their font size set really big. :) -Kurt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Hi folks, what about micro-printed on-screen code, watched through glasses? faster? or slower? JAVA is a myst Kurt Schrader wrote: On Wednesday, January 9, 2002, at 03:34 PM, Andrew C. Oliver wrote: What about if you set the font size really small? LOL -Andy Perhaps Microsoft just has their font size set really big. :) -Kurt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
It's only two little lines extra to include the {}'s,
Yeah, but those two lines will make my code run slower.
Don't you know?
The less space your source code takes, the less space
your class file will take.
And smaller classes run faster.
It must be true - 90% of people I've worked with seem
to live by that principle.
--
NOTICE
This e-mail and any attachments are confidential and may contain copyright material of
Macquarie Bank or third parties. If you are not the intended recipient of this email
you should not read, print, re-transmit, store or act in reliance on this e-mail or
any attachments, and should destroy all copies of them. Macquarie Bank does not
guarantee the integrity of any emails or any attached files. The views or opinions
expressed are the author's own and may not reflect the views or opinions of Macquarie
Bank.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
-Original Message-
From: Tim Vernum [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 08, 2002 5:12 PM
To: 'Jakarta General List'
Subject: RE: Code conventions
It's only two little lines extra to include the {}'s,
Yeah, but those two lines will make my code run slower.
Don't you know?
The less space your source code takes, the less space
your class file will take.
And smaller classes run faster.
It must be true - 90% of people I've worked with seem
to live by that principle.
How about having your code with a nice format. Then running it through a
utility that strips all formatting and makes the source file compact, and
then compile that.
This would make the code-format-promoting people happy, and also the
need-for-speed-at-every-cost people.
I remember somewhere looking at a utility like this once... but don't know
where.
Just a thought.
Ylan Segal.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/8/02 8:53 AM, Endre Stølsvik [EMAIL PROTECTED] wrote:
On Fri, 4 Jan 2002, Geir Magnusson Jr. wrote:
| My question is what are the consequences to forcing me to do #2 when #1 is
| perfectly acceptable throughout the professional world?
That syntax is so bleedin' ugly that I would suspect you were a novice not
knowing how to code.. ;)
PROFESSIONALS don't code using really, really ugly standards...
No, they consult the coding manual from the technology vendor.
:D
if (something)
{
Some block;
}
That's so ugly I have a hard time parsing it.
The _only_ way which is worse, is:
if (something)
{
Some block;
}
How is is possible to devise such a _fantastically_ ugly way of writing a
block? I have a hard time trying to _write_ that example there. It is so
utterly incredible. I have to go through it, parsing all such code char by
char, hitting the del key until a { appears after the if clause..!
;)
I'm glad that you put your own health and well-being on the line, assuming
the risks for your compatriots, by actually typing if blocks different from
your usual. Since you did it in the context of an Apache public discussion,
you may apply for funding from the ASF for counseling and therapy, but
remember the out of network co-pay.
But then, on a serious note, the un-enclosed block like this
if (something)
this;
else
that;
is a bit dangerous.
I think it can be very dangerous, especially in a multi-programmer
environment. (Seriously...)
If you start, kind of mindlessy, to play around with
the code there, you all of a sudden insert a line extra after the that
part, thinking that it will execute only in the else part. Which, of
course, it won't, as it executes all the time..
It's only two little lines extra to include the {}'s, IF you of course
don't use the really ugly standard, or worse, the _fantastically_ ugly
standard, mentioned above.
if (something) {
this;
}
else {
that;
}
Foul! Heathen! Gaak!
You could, if the this and that parts were very small, do this
if (something) { this; }
else { that; }
Ug! Please stop! I beg you.
Or prettify that as
if (something) { this; }
else { that; }
Hey! You stole my code :)
but now you're really moving along the edge..
:)
| On your resume, I see that you were terminated for cause at Sun?
|
| Yes, I created too many classes with the opening brace on a separate
| line...
WHAT? You DARE coming in here, wasting my time, being an
opening-brace-on-separate-line-ASSHOLE? You get the f*** outta here!!
---
GUARDS! - Could you please shove this thing into the incer... Erhm, I
meant; show this ... person ... to the door?
LOL
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech. - Benjamin Franklin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/8/02 6:12 PM, Tim Vernum [EMAIL PROTECTED] wrote:
It's only two little lines extra to include the {}'s,
Yeah, but those two lines will make my code run slower.
Don't you know?
The less space your source code takes, the less space
your class file will take.
And smaller classes run faster.
It must be true - 90% of people I've worked with seem
to live by that principle.
Add to that the fact that if it was hard to write, it should be hard to
read...
:)
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
It's only two little lines extra to include the {}'s,
Yeah, but those two lines will make my code run slower.
Don't you know?
The less space your source code takes, the less space
your class file will take.
And smaller classes run faster.
It must be true - 90% of people I've worked with seem
to live by that principle.
Add to that the fact that if it was hard to write, it should be hard to
read...
:)
Someone told me if you use a really small font like courier 6pt then
you don't even need an optimizing compiler.
-Andy
--
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
* Paulo Gaspar [EMAIL PROTECTED] wrote: | | It could even happen in the USA and it is quite dangerous to think | otherwise (because then you are not alert). Well, I would argue that it is happening in the US now with the new military courts. -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote: Let's all take a moment to review: http://www.godwinslaw.com/ Amusing but not very pertinent to the discussion. No one exchanged accusations of Nazism. Although I recognize that your goal was probably to diffuse the tension. As things stand today, the Jakarta project is a loose assembly of subprojects united by a common license, a common web site and a common PMC. Here is what http://jakarta.apache.org/site/roles.html has to say on the Project Management Committee (PMC): This committee is the official managing body of the Jakarta Project and is responsible for setting overall project direction. The PMC currently follows a non-interventionist policy. Its actions in the past year have been limited to accepting or rejecting new subprojects which is inadequate for setting the overall project direction, the stated goal of the PMC. The inability of the PMC to take initiative stems from the Apache voting process where every member has a veto power. This limits the decision power of the PMC to consensual decisions only. The Jakarta PMC is averse of discussing things in private in fear that its legitimacy might be challenged. IMHO, if the legitimacy of the PMC is challenged, let the challenger wait and suffer until the next PMC elections. I believe the next elections are scheduled for February or March 2002. The current system of veto based voting might be appropriate for development but is inappropriate for managing large projects like Jakarta. Either we admit it and act now or watch Jakarta become SourceForge-elite, an assembly of excellent projects but with no common purpose. Jakarta does not have a benevolent dictator where the puck stops. Recognizing this fact, we either: 1) Elect a PMC with real power, power to intervene and take painful decisions, until the next elections. 2) Instate a system based on referendum, where the public can directly intervene in making laws. By public, I mean developers with commit rights. To avoid voting on trivialities, a referendum would require the support of at least five committers to acquire the valid status. After a possible but short delay, a valid referendum is submitted to popular vote. The result of the vote determines whether the referendum is accepted or rejected. An accepted referendum becomes law of the land. To avoid keeping voting on the same issue time and again, a wait period of 12 months is necessary between two referenda on the same or nearly the same issue. 3) Keeps things as they are and hope for the best. Regards, Ceki -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/4/02 6:43 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
If some particular codebase under the Jakarta umbrella consistently
chose to take actions which were inconsistent with the Apache mission,
then I'm confident that the PMC would swiftly act to disolve this code
base. I am not aware of this being done before, so it would be
uncharted territory, but I'm sure we would find a way. And that way
would not require 100% consensus.
In my mind, the willful insertion of newlines in direct contradiction
to the Code Conventions for the Java Programming Language does not
rise to this level.
This analysis sums up the current state of affairs. As long as you are
in and do not commit murder, you are free to do whatever you like,
regardless of the consequences of your actions. Murder is defined as
not adopting or infringing on the Apache Software License.
Is this how we want Jakarta to be? If not, what can be done?
I don't see what the negative consequences for community are when I do
something like
if ( condition )
{
statement;
}
versus
if ( condition ) {
statement;
}
or
if ( condition )
statement;
Other than I made my code is more readable :)
My question is what are the consequences to forcing me to do #2 when #1 is
perfectly acceptable throughout the professional world? We are going to
look like a bunch of PHB's if we do this. Someone's is then going to write
the utility JU (Jakarta Uglifier).
I realize that some of this is simply a matter of taste, and people don't
think that #1 above is more readable than #2. I'm just trying to figure out
why this personal style decision in what is in many ways an artistic
endevour constitutes a risk to the community. Note that I don't advocate a
coding free for all - I also understand that with multiple developers, some
'workmanlike' ('workpersonlike'?) standards are important.
Aside : does Sun use deviation from coding standards as an actionable HR
issue? ;)
On your resume, I see that you were terminated for cause at Sun?
Yes, I created too many classes with the opening brace on a separate
line...
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
We will be judged not by the monuments we build, but by the monuments we
destroy - Ada Louise Huxtable
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Geir Magnusson Jr. wrote: For those of us (like me) that don¹t get it, can we do a quick review why deviation from the One True But Sometimes Really Ugly Coding Standard as defined by Sun Microsystems is such a threat to the ongoing health of Jakarta? And if the above isn't really the problem, but just an example, can we talk a bit about what the problems are? I believe it is reasonable to expect that a given codebase will follow a common convention. This is especially important in a ASF product, since we expect that the product will maintained over a long period of time by many different individuals. I fully support the idea that each codebase is entitled to its own conventions. I also fully support the idea that having defined conventions, we should follow them. I think the status quo is just fine, but we do have to remember to watch each other's backs, and remind people to use the conventions expected within each codebase. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/4/02 7:23 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: At 06:46 04.01.2002 -0500, you wrote: On 1/4/02 6:04 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: Jakarta does not have a benevolent dictator where the puck stops. Recognizing this fact, we either: [SNIP] 3) Keeps things as they are and hope for the best. For those of us (like me) that don¹t get it, can we do a quick review why deviation from the One True But Sometimes Really Ugly Coding Standard as defined by Sun Microsystems is such a threat to the ongoing health of Jakarta? And if the above isn't really the problem, but just an example, can we talk a bit about what the problems are? Deviation from the One True But Sometimes Really Ugly Coding Standard as defined by Sun Microsystems is *not* a threat to the ongoing health of Jakarta. It is just an example, albeit a symbolic one. Whew ;) The threat is to Jakarta's *nature* and it comes from our indecisiveness. Real problems I see is 1) lack of focus, I too worry about this. A lot. I don't know what to do about it yet. 2) duplication between projects, Too many damn loggers - thank goodness sun is providing us with on via JSR-47. I am sure that the Code Conventions will be followed to the letter too. (You know I'm kidding - I'm a huge log4j fan, but that one was *just* too easy...) Seriously, I don't know if that is a problem, as I think it drives development. We have two web frameworks, Turbine and Struts, and they are different in current implementation, and as far as I understand it, different in evolutionary roadmap. I think this is good and healthy. We have regexp and ORO. I always use ORO for the Perl stuff. No other comments. We have repetition in commons/commons-sandbox, which I think is great. Those are the top level ones. It's clear that there is repetition within projects (the database connection pools being my canonical example) but that too seems to be evidence of exploring the solution space rather than pure wheel re-invention (although there is some of that...) I think (and only 'I thin') the only thing we can do about this, as you can't mandate what project communities decide to work on, is to ensure that the top level projects remain clear in scope, and encourage cross-project cooperation and sharing, which I think the Commons was intended in part to do. 3) lack of common procedures for doing things. Mixed feelings, as this tends to be personal taste, and leads to operational totalitarianism which I think stifles innovation. There is something to be said for common build procedures, but with ant and a little documentation, it generally isn't a big deal I've found. Are these perceived as problems by others or is it just my imagination? -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 06:57 04.01.2002 -0500, you wrote:
On 1/4/02 6:43 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
If some particular codebase under the Jakarta umbrella consistently
chose to take actions which were inconsistent with the Apache mission,
then I'm confident that the PMC would swiftly act to disolve this code
base. I am not aware of this being done before, so it would be
uncharted territory, but I'm sure we would find a way. And that way
would not require 100% consensus.
In my mind, the willful insertion of newlines in direct contradiction
to the Code Conventions for the Java Programming Language does not
rise to this level.
This analysis sums up the current state of affairs. As long as you are
in and do not commit murder, you are free to do whatever you like,
regardless of the consequences of your actions. Murder is defined as
not adopting or infringing on the Apache Software License.
Is this how we want Jakarta to be? If not, what can be done?
I don't see what the negative consequences for community are when I do
something like
if ( condition )
{
statement;
}
versus
if ( condition ) {
statement;
}
or
if ( condition )
statement;
Other than I made my code is more readable :)
My question is what are the consequences to forcing me to do #2 when #1 is
perfectly acceptable throughout the professional world? We are going to
look like a bunch of PHB's if we do this. Someone's is then going to write
the utility JU (Jakarta Uglifier).
I realize that some of this is simply a matter of taste, and people don't
think that #1 above is more readable than #2. I'm just trying to figure out
why this personal style decision in what is in many ways an artistic
endevour constitutes a risk to the community. Note that I don't advocate a
coding free for all - I also understand that with multiple developers, some
'workmanlike' ('workpersonlike'?) standards are important.
All excellent points. I don't have any good answers, just more
questions.
Yes, by imposing strict code conventions there is a real danger of
acting like a PHB. Yes, code conventions infringe on artistic freedom
and might even curtail creativity.
The debate about code conventions is just an excuse to ask the
following question, and it is a question:
Do we want to instate rules for the good of the larger community?
We keep saying that Jakarta is not SourceForge. How can this be if
each project can act totally independently?
Aside : does Sun use deviation from coding standards as an actionable HR
issue? ;)
On your resume, I see that you were terminated for cause at Sun?
Yes, I created too many classes with the opening brace on a separate
line...
Remember the scene where Lisa, from the Simpons, is thrown out of
music class even of she plays her sax beautifully. We all emphasize
with Lisa's view. However, what would you do if you were in the
teacher's shoes?
Questions, questions...
--
Ceki Gülcü - http://qos.ch
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/4/02 7:56 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
At 06:57 04.01.2002 -0500, you wrote:
On 1/4/02 6:43 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
If some particular codebase under the Jakarta umbrella consistently
chose to take actions which were inconsistent with the Apache mission,
then I'm confident that the PMC would swiftly act to disolve this code
base. I am not aware of this being done before, so it would be
uncharted territory, but I'm sure we would find a way. And that way
would not require 100% consensus.
In my mind, the willful insertion of newlines in direct contradiction
to the Code Conventions for the Java Programming Language does not
rise to this level.
This analysis sums up the current state of affairs. As long as you are
in and do not commit murder, you are free to do whatever you like,
regardless of the consequences of your actions. Murder is defined as
not adopting or infringing on the Apache Software License.
Is this how we want Jakarta to be? If not, what can be done?
I don't see what the negative consequences for community are when I do
something like
if ( condition )
{
statement;
}
versus
if ( condition ) {
statement;
}
or
if ( condition )
statement;
Other than I made my code is more readable :)
My question is what are the consequences to forcing me to do #2 when #1 is
perfectly acceptable throughout the professional world? We are going to
look like a bunch of PHB's if we do this. Someone's is then going to write
the utility JU (Jakarta Uglifier).
I realize that some of this is simply a matter of taste, and people don't
think that #1 above is more readable than #2. I'm just trying to figure out
why this personal style decision in what is in many ways an artistic
endevour constitutes a risk to the community. Note that I don't advocate a
coding free for all - I also understand that with multiple developers, some
'workmanlike' ('workpersonlike'?) standards are important.
All excellent points. I don't have any good answers, just more
questions.
Yes, by imposing strict code conventions there is a real danger of
acting like a PHB. Yes, code conventions infringe on artistic freedom
and might even curtail creativity.
The debate about code conventions is just an excuse to ask the
following question, and it is a question:
Do we want to instate rules for the good of the larger community?
I think yes, but the prepositional phrase for the good of the larger
community is going to be the trouble spot... Historically always has :)
We keep saying that Jakarta is not SourceForge. How can this be if
each project can act totally independently?
Because they really can't act *totally* independently, additional projects
can't be formed (and abandoned) ad hoc by 'outsiders', there is indeed peer
pressure (as well mechanical things like Gump) that enforce some
consistency, and lots of cross pollenation. I mean, Jon is everywhere ;)
From my personal experience, I do think of it as one big community but
different 'departments'. I talk to people from many of the subprojects when
I need something or have a question, and I certainly feel welcome and like
it's one big group.
Another thought I have on this is that we are sort of like sourdough bread
made with a starter :) We add new projects, but it's (usually) initiated,
championed and/or participated in by someone steeped in the Apache/Jakarta
'gestalt', so the traditions and practices continue.
Aside : does Sun use deviation from coding standards as an actionable HR
issue? ;)
On your resume, I see that you were terminated for cause at Sun?
Yes, I created too many classes with the opening brace on a separate
line...
Remember the scene where Lisa, from the Simpons, is thrown out of
music class even of she plays her sax beautifully. We all emphasize
with Lisa's view. However, what would you do if you were in the
teacher's shoes?
(I thought you were going to the scene : Lisa, get away from that Jazz
man! )
Well, that's the difference between the teacher having to do something about
it, and Principal Skinner listening in over the intercom and getting Lisa to
leave Within the community, the community is the teacher, and can
legislate itself (modulo Principal Skinner, of course...)
Questions, questions...
:)
--
Ceki Gülcü - http://qos.ch
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Now what do we do?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On Fri, 4 Jan 2002 23:07, Ted Husted wrote: Geir Magnusson Jr. wrote: For those of us (like me) that dont get it, can we do a quick review why deviation from the One True But Sometimes Really Ugly Coding Standard as defined by Sun Microsystems is such a threat to the ongoing health of Jakarta? And if the above isn't really the problem, but just an example, can we talk a bit about what the problems are? I believe it is reasonable to expect that a given codebase will follow a common convention. This is especially important in a ASF product, since we expect that the product will maintained over a long period of time by many different individuals. I fully support the idea that each codebase is entitled to its own conventions. I also fully support the idea that having defined conventions, we should follow them. I think the status quo is just fine, but we do have to remember to watch each other's backs, and remind people to use the conventions expected within each codebase. Thats nice for some codebases but not appropriate for all. For instance the Ant codebase has got to have at least 10-15 different styles (probably way way way more) because 70% of code is not written by the committers but by members of community who have their own particular tastes. It is is largely up to the committers to decide whether to restyle the files and that really has not greatly impacted the quality of ant. However other codebases have much more rigourous conventions that are followed precisely. Its up to the developers what they want to do. -- Cheers, Pete --- It is easy to dodge our responsibilities, but we cannot dodge the consequences of dodging our responsibilities. -Josiah Stamp --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On Fri, 4 Jan 2002 22:04, Ceki Gülcü wrote: 1) Elect a PMC with real power, power to intervene and take painful decisions, until the next elections. -1 power would be abused and misused. If power is what you want you are not going to get it by donning a skippy badge but earning it through respect. 2) Instate a system based on referendum, where the public can directly intervene in making laws. By public, I mean developers with commit rights. yay - popularity contests! That would be sooo much fun. To avoid keeping voting on the same issue time and again, a wait period of 12 months is necessary between two referenda on the same or nearly the same issue. And maybe we should elect a committee to determine whether issues are too similar and they can break apart into sub-committees to determine the viability of holding a referendum to determine if two issues are dissimilar enough that another referendum could be held for the issue. 3) Keeps things as they are and hope for the best. things as they are are for the best. People do things because they see that it is the right thing to do for them - which usually means it is technically the right thing. Sometimes it takes time (it took me 1.5 years to convince one apache person of something) but most things work out better in the end. At times it is infuriating when someone else is doing something stupid but forcing them to change is not the answer - for one you may be wrong, if not you are probably going to cause resentment - not something healthy for the community. -- Cheers, Pete - First, we shape our tools, thereafter, they shape us. - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Peter Donald wrote: Thats nice for some codebases but not appropriate for all. For instance the Ant codebase has got to have at least 10-15 different styles (probably way way way more) because 70% of code is not written by the committers but by members of community who have their own particular tastes. It is is largely up to the committers to decide whether to restyle the files and that really has not greatly impacted the quality of ant. However other codebases have much more rigourous conventions that are followed precisely. Its up to the developers what they want to do. Agreed. I'm simply saying that, moving forward, the Ant PMC member should encourage the subproject to stick to the default convention, or declare one of their own. If we had been more careful about this sooner, then perhaps the Ant codebase would not be host to so many diverse styles. I agree that any change has to be made by a Committer to the subproject, but reserve our right to nag. If the Committers want to ignore us they can, but that doesn't mean we should go quietly into the night. I personally believe these things don't happen because people are bloody-minded, they happen because people are unaware, and we haven't been watching each other's back. In the meantime, I do suggest we go with rule #1 - Adhere to the style of the original. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 08:01 04.01.2002 -0500, Geir Magnusson Jr. wrote: The debate about code conventions is just an excuse to ask the following question, and it is a question: Do we want to instate rules for the good of the larger community? I think yes, but the prepositional phrase for the good of the larger community is going to be the trouble spot... Historically always has :) We keep saying that Jakarta is not SourceForge. How can this be if each project can act totally independently? Because they really can't act *totally* independently, additional projects can't be formed (and abandoned) ad hoc by 'outsiders', there is indeed peer pressure (as well mechanical things like Gump) that enforce some consistency, and lots of cross pollenation. I mean, Jon is everywhere ;) From my personal experience, I do think of it as one big community but different 'departments'. I talk to people from many of the subprojects when I need something or have a question, and I certainly feel welcome and like it's one big group. That's a good description. Another thought I have on this is that we are sort of like sourdough bread made with a starter :) We add new projects, but it's (usually) initiated, championed and/or participated in by someone steeped in the Apache/Jakarta 'gestalt', so the traditions and practices continue. The reasons for which projects get accepted or rejected is an important subject in itself. Remember the scene where Lisa, from the Simpons, is thrown out of music class even of she plays her sax beautifully. We all emphasize with Lisa's view. However, what would you do if you were in the teacher's shoes? (I thought you were going to the scene : Lisa, get away from that Jazz man! ) Oh, yes, then she (Maggie) turns to the to the Jazz man and says: Nothing personal, I just fear the unfamiliar. How true, how succinct. Well, that's the difference between the teacher having to do something about it, and Principal Skinner listening in over the intercom and getting Lisa to leave Within the community, the community is the teacher, and can legislate itself (modulo Principal Skinner, of course...) Amusingly enough that episode starts with Bart writing on the chalkboard: I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! Regards, Bart. -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 00:55 05.01.2002 +1100, you wrote: On Fri, 4 Jan 2002 22:04, Ceki Gülcü wrote: 1) Elect a PMC with real power, power to intervene and take painful decisions, until the next elections. -1 power would be abused and misused. If power is what you want you are not going to get it by donning a skippy badge but earning it through respect. Power can and is abused. Knives can and do cut through flesh. Knives can also be used to cut bread. I have no problem delegating legislative power to the members of parliament as long as its members were elected for a limited length term in fair and square elections. 2) Instate a system based on referendum, where the public can directly intervene in making laws. By public, I mean developers with commit rights. yay - popularity contests! That would be sooo much fun. Who is talking about popularity contest? What popularity contest? To avoid keeping voting on the same issue time and again, a wait period of 12 months is necessary between two referenda on the same or nearly the same issue. And maybe we should elect a committee to determine whether issues are too similar and they can break apart into sub-committees to determine the viability of holding a referendum to determine if two issues are dissimilar enough that another referendum could be held for the issue. Laugh all you want. Referenda are great. Ask any Swiss citizen. 3) Keeps things as they are and hope for the best. things as they are are for the best. People do things because they see that it is the right thing to do for them - which usually means it is technically the right thing. Sometimes it takes time (it took me 1.5 years to convince one apache person of something) but most things work out better in the end. At times it is infuriating when someone else is doing something stupid but forcing them to change is not the answer - for one you may be wrong, if not you are probably going to cause resentment - not something healthy for the community. I really don't like paying taxes but I do. I would be great to live in the Bahamas, drink cocktails and fornicate day in day out. -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 00:57 05.01.2002 +1100, you wrote: On Fri, 4 Jan 2002 23:23, Ceki Gülcü wrote: The threat is to Jakarta's *nature* and it comes from our indecisiveness. Real problems I see is 1) lack of focus, Dont see this as a problem. Each project is usually focused on its dowmain and the overall project has a sort of scope. Personally I would have no problem widening scope of jakarta to include virtually any java project, serverside, clientside, frameworks, products, etc but not everyone thinks this is a great idea ;) No, some people would not like to see Jakarta widen its scope and they would -1 any steps in that direction. However, it is certainly possible that a majority of Jakarta committers would be amenable to the idea. In the system I am suggesting, you would propose the idea, have four other committers support it, and then launch a vote on the subject. If it were adopted then the scope of Jakarta would be widened and nobody would be able to do anything about it, not me, not Ted, not even Jon. Widening the scope of Jakarta is not necessarily a bad idea. Your ideas are not all bad. (Don't get me wrong, there are not always good either.) 2) duplication between projects, diversity aids evolution though preferably it would be intra rather than inter project duplicity. However the PMC has historically not seen that as desirable due to advertising. duplicity - noun, plural duplicities 1. a. Deliberate deceptiveness in behavior or speech. b. An instance of deliberate deceptiveness; double-dealing. 2. The quality or state of being twofold or double. I have read and reread your comment. It just does not make any sense. 3) lack of common procedures for doing things. This is the one possible issue I see. However I only see it as a problem for the external interface between projects. Mainly this involves things like release naming cconventions, targets in ant files, location of intermediate and destination files in a build. It really is irrelevent to outsiders what indent style is used, whether anakia or stylebook is used yadda yadda. So I +1 on suggesting standards for external parts of project, -1 for forcing it Indeed, that seems to be the consensus. -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
Aside : does Sun use deviation from coding standards as an actionable HR issue? ;) On your resume, I see that you were terminated for cause at Sun? Yes, I created too many classes with the opening brace on a separate line... I don't know about sun, but we would certainly warn employees about repeated infringements, and that *is* the start of a process which can end in dismissal for persistently deviating from code standards. I expect the same process here could lead to a commiter being disenfranchised (what is the correct verb?) if their deviation was sufficiently persistent, what you have to hope is that we have enough intelligence to respond to the first warning. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
Ceci wrote: The inability of the PMC to take initiative stems from the Apache voting process snip The current system snip is inappropriate for managing large projects like Jakarta. snip I agree with this, I've only been a commiter since the end of last summer, and have been surprised that while the web site says.. This committee is the official managing body of the Jakarta Project and is responsible for setting overall project direction. It does not appear very pro-active in this role. I've been subscribed to this list out of curiosity about what the PMC do, to keep a finger on the pulse as it were, and apart from the discussions about new projects and the current rash of opinion on code standards there seems to be little traffic discussing overall project direction Perhaps thats because the direction is not changing, are the goals of the project still the same, are the subprojects all still moving steadily forward? They seem to be, and this would be a good reason for not interfering, after all there are no deadlines except those imposed by individual projects and few imperatives of the kind which, in the commercial world, need to be enforced by PM's. we either: 1) Elect a PMC with real power, power to intervene and take painful decisions, until the next elections. In a democracy (and I *know* apache isn't that) we elect from amongst ourselves representatives whom we charge with making decisions on our behalf, for that to make any sense we have to give them the authority to make those decisons and bind ourselves to them, anything else is just posturing. 2) Instate a system based on referendum, where the public can directly intervene in making laws. By public, I mean developers with commit rights. Always contentious, referenda are un-democratic in that they imply that the fundamental assertion of democracy (that we elect people to represent us) is flawed. IMHO (as this whole spiel is) referenda would therefore render the PMC irrelevant. However consensus decisions are *much* harder to achieve in larger groups, it would be un-realistic to expect every commiter to spend time giving every vote serious consideration, and so I favour a PMC where the elected members have made a commitment to considering the issues. 3) Keeps things as they are and hope for the best. Unless the goals of the project have changed, or unless a significant change is needed to either the goals or the nature of the project the existing system should continue to work, perhaps Ceci's comments stem from a feeling that change is needed of the kind only changes in PM can accomodate. If so what's wrong? and why won't the current system be able to deliver the changes needed? d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 10:32 04.01.2002 -0500, you wrote: For reasons that are unknown to me, none of the e-mail that I have sent over the last few days has made it out to the mailing lists. For all I know, at some point in the distant future, it will all be unleashed and make little sense out of context. :-( Anyway, it looks like e-mail that I send now gets through so let me take advantage of it while I can... Ceki Gülcü wrote: If some particular codebase under the Jakarta umbrella consistently chose to take actions which were inconsistent with the Apache mission, then I'm confident that the PMC would swiftly act to disolve this code base. I am not aware of this being done before, so it would be uncharted territory, but I'm sure we would find a way. And that way would not require 100% consensus. In my mind, the willful insertion of newlines in direct contradiction to the Code Conventions for the Java Programming Language does not rise to this level. This analysis sums up the current state of affairs. As long as you are in and do not commit murder, you are free to do whatever you like, regardless of the consequences of your actions. Murder is defined as not adopting or infringing on the Apache Software License. All I am saying is that adopting a different set of coding conventions should not be a federal crime. I totally agree. Jakarta effectively is a federation of states, each with the power to adopt their own conventions. I do have great sympathy for Jon's point that those subprojects that have not taken the time or effort to document their standards do a great disservice to themselves and us all. Ditto. Real problems I see is 1) lack of focus, 2) duplication between projects, 3) lack of common procedures for doing things. Let me start with #2. Did you realize that the Tomcat project can service HTTP requests? Gasp! Lets get them to rip this code out as Apache has a little known HTTPD project which owns this mission. Not. I see where you are heading. This instance of duplication of effort is well known and essentially sanctioned by the board. Allowing people to fork and pursue their own vision is part of the essence what makes open source different then the centrally planned economies that one often finds in big corporate software development projects. Well put. Re: focus. What do ant and httpd have in common? The purpose of Apache is not to build a single product or family of products. The purpose is to propagate an open methodology centered around community base development. Quality or integration or unity of purpose are often useful by-products, but not the central goal. Couldn't agree more. Re: lack of common procedures. I will grant you that this is an area that we can always improve on. You have made a number of references to a benevolent dictator implying that the existence of such would be an improvement over the current state of affairs. If that is the case, then I am not that person. I prefer to educate or cajole or nag over dictating. Gump is a prime example. (Note: in the case of a federal crime mentioned above, I would not hesitate to initiate action to remove a committer or even an entire code base). Gump is a prime example indeed. Masterfully done. As an example related back to this subject line, I would not be in favor of a tool which rejects commits that don't conform to a particular style. I also would not be in favor of a tool which post-processes commits to retrofit a particular style. I would be in favor of a tool which reviews commits and informs you of issues that it determines. At the moment, Jon serves this purpose. ;-) I will not instigate revolution! I will not instigate revolution! Be forewarned that the Apache tradition is to allow people with enough fire in their belly to tackle a particular problem that is important to them the freedom to do so. If the problems you see are something that you feel need tackling and the only effective way in which this can be accomplished is for you to become the Jakarta PMC chair, then I could certainly arrange for an election to take place. I can't guarantee the results of the election or the success of your quest, but I can do my part to enable you to pursue your goals. Think about this for a while, and let me know if this is a path you wish to pursue. I have thought about for about 30 seconds and the answer is no, non, nein, nyet. Thanks, but no thanks. You don't want me as chairman. Trust me. I hope that was clear enough to dispel any misconceptions. If not, I'll be sure to repeat it again the next time the question comes up. We have been lucky to have you serve as PMC chair. I do not wish to offend anyone but I can't think of anyone else better qualified than Sam. If I were to draw list of preferences for chair my name would not be second after Sam, not the third, not the fourth... Coming back to your point of the propagation of an open methodology centered around
RE: Code conventions
Hi, skip/ Any democratic system is imperfect and hence flawed. Hitler was elected democratically although he soon moved to dismantle the system that brought him to power. D'oh, that damn Godwin's Law! Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler because the other so called democratic parties like Volkspartei and Socialist where so quarreled that they were unable to form a strong coalition to kick this asshole out and preserve my country from this dark 15 years. Therefore the current Reichspräsident Hindenburg called Hitler for the new Reichskanzler, because the existing Parlament was to weak. After his dead '35 Hitler began with the so called Gleichschaltung. Hitler slowly destroyed the democratic system, but he was *never* elected democratic!! skip/ Gerhard -- Black holes were created when God divided by zero. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
Gerhard, Is it fair and accurate to say that he came to power within the bounds and rules of a democratic system? At 17:58 04.01.2002 +0100, you wrote: Hi, skip/ Any democratic system is imperfect and hence flawed. Hitler was elected democratically although he soon moved to dismantle the system that brought him to power. D'oh, that damn Godwin's Law! Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler because the other so called democratic parties like Volkspartei and Socialist where so quarreled that they were unable to form a strong coalition to kick this asshole out and preserve my country from this dark 15 years. Therefore the current Reichspräsident Hindenburg called Hitler for the new Reichskanzler, because the existing Parlament was to weak. After his dead '35 Hitler began with the so called Gleichschaltung. Hitler slowly destroyed the democratic system, but he was *never* elected democratic!! skip/ Gerhard -- Black holes were created when God divided by zero. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
In the process Hitler and his gang played a surprisingly high number of dirty tricks. Surprising at least for a non German, since we only get an overview of the WW2 history. Since I work in Germany I have the benefit of the many documentaries about the Nazi era played on TV (history is not forgotten here). I am often quite surprised about how twisted and sophisticated some of those tricks and strategies were. BTW, a lot of those strategies involve scaring and distracting the people with some fictional or real enemy. Have fun, Paulo -Original Message- From: Gerhard Froehlich [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 5:59 PM Hi, skip/ Any democratic system is imperfect and hence flawed. Hitler was elected democratically although he soon moved to dismantle the system that brought him to power. D'oh, that damn Godwin's Law! Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler because the other so called democratic parties like Volkspartei and Socialist where so quarreled that they were unable to form a strong coalition to kick this asshole out and preserve my country from this dark 15 years. Therefore the current Reichspräsident Hindenburg called Hitler for the new Reichskanzler, because the existing Parlament was to weak. After his dead '35 Hitler began with the so called Gleichschaltung. Hitler slowly destroyed the democratic system, but he was *never* elected democratic!! skip/ Gerhard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
I am sure Gerhard can give a better answer, but IMHO he abused a lot the system. The truth is that it can happen anywhere if people are not very alert and ready to fight for their rights. It could even happen in the USA and it is quite dangerous to think otherwise (because then you are not alert). Have fun, Paulo -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 6:14 PM Gerhard, Is it fair and accurate to say that he came to power within the bounds and rules of a democratic system? At 17:58 04.01.2002 +0100, you wrote: Hi, skip/ Any democratic system is imperfect and hence flawed. Hitler was elected democratically although he soon moved to dismantle the system that brought him to power. D'oh, that damn Godwin's Law! Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler because the other so called democratic parties like Volkspartei and Socialist where so quarreled that they were unable to form a strong coalition to kick this asshole out and preserve my country from this dark 15 years. Therefore the current Reichspräsident Hindenburg called Hitler for the new Reichskanzler, because the existing Parlament was to weak. After his dead '35 Hitler began with the so called Gleichschaltung. Hitler slowly destroyed the democratic system, but he was *never* elected democratic!! skip/ Gerhard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
Hi, Gerhard, Is it fair and accurate to say that he came to power within the bounds and rules of a democratic system? Yes and it should remind us, that the democratic system is very imperfect! Even in the USA. A powerful President with deep influence can slowly become more and more powerful until the Parliament is meaningless. And when the country simultaneously is in a deep recession then gnade uns gott. IMO: politics == process howto get more power and control! And a democratic system don't saves us for persons, which want to use this power evil. It just makes the process more bureaucratic. And that's the trick. But you can't compare the democratic system of 1932 with our systems in 2002! But take look on Austria and Jörg Haider. If you are a German native Speaker you should read the current discussion on about bilingual street shields http://derstandard.at/. But don't let this dicussion become political! IMHO politics sucks ;) Gerhard a lightwighted anarchist ;) - I don't suffer from insanity. I enjoy every minute of it. - At 17:58 04.01.2002 +0100, you wrote: Hi, skip/ Any democratic system is imperfect and hence flawed. Hitler was elected democratically although he soon moved to dismantle the system that brought him to power. D'oh, that damn Godwin's Law! Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler because the other so called democratic parties like Volkspartei and Socialist where so quarreled that they were unable to form a strong coalition to kick this asshole out and preserve my country from this dark 15 years. Therefore the current Reichspräsident Hindenburg called Hitler for the new Reichskanzler, because the existing Parlament was to weak. After his dead '35 Hitler began with the so called Gleichschaltung. Hitler slowly destroyed the democratic system, but he was *never* elected democratic!! skip/ Gerhard -- Black holes were created when God divided by zero. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Peter Donald wrote: So I +1 on suggesting standards for external parts of project, -1 for forcing it uh, I jumped in the middle of a where to place the curly brace code format pissing contest, how cool. For those of you who weren't around, we had the first resolution of this (what later became condensed into the current PMC directives) around 1997 on the jserv-dev mail list. (Jon, remember that?) Sure, it would be cool to have a clear code convention (or a language like Python that more or less doesn't even compile if you don't follow the right conventions) or a benevolent dictator (that used the convention you like!). Unfortunately, we don't have any of those, so the resolution was: most of the java source code out there (well, it was 1997, you know!) used the Sun coding conventions so we started from there, but we decided to be tollerant on *cultural* differences. And *cultural* differences include: editor used, favorite OS, favorite mail client, favorite browser, favorite native language, favorite ice cream flavor... :) Sure, there should be *compromises* and there are some that are very useful and understandable (the use of english as the language, no HTML in email, nice quoting, polite messages, support for old browsers, no ice cream attached to email) and some that are more subject to personal judgement (local variable names, curly brace location, tab vs. space, how many spaces for a tab). When no objective result can be reached, discussions become religious wars. I'd follow Sam suggestions: let's be tollerant. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. [EMAIL PROTECTED] Friedrich Nietzsche -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On Thu, 3 Jan 2002 00:24, Sam Ruby wrote: Let's all take a moment to review: http://www.godwinslaw.com/ If some particular codebase under the Jakarta umbrella consistently chose to take actions which were inconsistent with the Apache mission, then I'm confident that the PMC would swiftly act to disolve this code base. I am not aware of this being done before, so it would be uncharted territory, but I'm sure we would find a way. And that way would not require 100% consensus. In my mind, the willful insertion of newlines in direct contradiction to the Code Conventions for the Java Programming Language does not rise to this level. Got to love that site ! -- Cheers, Pete --- | If you turn on the light quickly enough, | |you can see what the dark looks like.| --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On Thu, 3 Jan 2002 00:34, Conor MacNeill wrote: Ted Husted wrote: Peter, I hope you and yours are well. The Australian Black Christmas is all over the morning news here. The smoke is pretty thick here right now even in the city suburbs. Having all your windows shut up when the outside temperature is in the mid thirties isn't fun. Of course, we are better off than those who live on the edge of the bush. yer - I have seen the burns and some of the projected burns and it would be horrible to live in any of those areas. Anyway, Ted, I'm sure Peter isn't too concerned, he is about 800 km away, in Melbourne. We do like their helicopter though. Actually I was in the heart of sydney (darling harbour/belmain/parramatta) until just before new year ;) Had to return to melb though as asthma was playing up due to the smoke. The scary part is some of my companies software is being used to manage the resource deployment up there ... crossing fingers that nothing breaks ;) -- Cheers, Pete The two secrets to success: 1- Don't tell anyone everything. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On Wed, 2 Jan 2002 08:58, Ceki Gulcu wrote: At 07:39 02.01.2002 +1100, Peter Donald wrote: Hi, This is not something that should have been brought up on the PMC list - it should be discussed on general. Peter I do not need your permission to bring up a subject on the PMC list. Its not the purpose of the PMC list. If someone asks how to configure tomcat on the general mailing list they would get a similar redirect. It was uncourteous of you to forward my message to the general list without permission. It was uncourteous of you to misuse the PMC mailing list - you should no better than to do that. If you had read my proposal carefully you would have seen that my proposal was to reach agreement on the PMC list first and than consult with the wider jakarta community. You got it all backwards. Consult with the committers. The PMC is irrelevent for this type of discussion - the developers are the ones to decide and PMC only steps in when there is legal or similar issues arise. Again, my proposal required al least two thirds majority of jakarta committers in order for the conventions to be adopted. Your right - it should be obvious that the preferences of that one third are not important. -- Cheers, Pete --- I don't suffer from insanity. I enjoy every minute of it. --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 19:23 02.01.2002 +1100, you wrote: On Wed, 2 Jan 2002 08:58, Ceki Gulcu wrote: At 07:39 02.01.2002 +1100, Peter Donald wrote: Hi, This is not something that should have been brought up on the PMC list - it should be discussed on general. Peter I do not need your permission to bring up a subject on the PMC list. Its not the purpose of the PMC list. If someone asks how to configure tomcat on the general mailing list they would get a similar redirect. It was uncourteous of you to forward my message to the general list without permission. It was uncourteous of you to misuse the PMC mailing list - you should no better than to do that. Let us not confuse courtesy and your intolerance, shall we? If you had read my proposal carefully you would have seen that my proposal was to reach agreement on the PMC list first and than consult with the wider jakarta community. You got it all backwards. Consult with the committers. The PMC is irrelevent for this type of discussion - the developers are the ones to decide and PMC only steps in when there is legal or similar issues arise. Again, my proposal required al least two thirds majority of jakarta committers in order for the conventions to be adopted. Your right - it should be obvious that the preferences of that one third are not important. While you are at it, call me dictator, call me tyrant. Your remark reminds me of the following paragraph from the Green Book. Political struggle that results in the victory of a candidate with 51 per cent of the votes leads to a dictatorial governing body disguised as a false democracy, since 49 per cent of the electorate is ruled by an instrument of governing they did not vote for, but had imposed upon them. This is dictatorship. -- The Green Book, Muammar Al Qathafi For full text and the final solution to the problems of any community, refer to http://www.geocities.com/Athens/8744/readgb.htm The Green Book can be summarized as, War is peace. Freedom is slavery. Ignorance is strength. -- 1984, George Orwell I am so happy I don't live in Libya. Regards, Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Guys, Let's just clarify that any proposals, even proposals to make proposals, should go to General. The private PMC business should be reserved for extremely sensitive matters, usually involving site security. If we mis-post something to a private list, we should give the original poster a clear opportunity to move the thread to the public list, and continue the discussion there, or let the matter drop. Peter, I hope you and yours are well. The Australian Black Christmas is all over the morning news here. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Ted Husted wrote: Peter, I hope you and yours are well. The Australian Black Christmas is all over the morning news here. The smoke is pretty thick here right now even in the city suburbs. Having all your windows shut up when the outside temperature is in the mid thirties isn't fun. Of course, we are better off than those who live on the edge of the bush. Anyway, Ted, I'm sure Peter isn't too concerned, he is about 800 km away, in Melbourne. We do like their helicopter though. Conor :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Let's all take a moment to review: http://www.godwinslaw.com/ If some particular codebase under the Jakarta umbrella consistently chose to take actions which were inconsistent with the Apache mission, then I'm confident that the PMC would swiftly act to disolve this code base. I am not aware of this being done before, so it would be uncharted territory, but I'm sure we would find a way. And that way would not require 100% consensus. In my mind, the willful insertion of newlines in direct contradiction to the Code Conventions for the Java Programming Language does not rise to this level. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 07:39 02.01.2002 +1100, Peter Donald wrote: Hi, This is not something that should have been brought up on the PMC list - it should be discussed on general. Peter I do not need your permission to bring up a subject on the PMC list. It was uncourteous of you to forward my message to the general list without permission. If you had read my proposal carefully you would have seen that my proposal was to reach agreement on the PMC list first and than consult with the wider jakarta community. On Tue, 1 Jan 2002 20:28, Ceki Gülcü wrote: Conventions are a matter of taste and habit. Some are and some are designed to force programmers to implement things in particular ways and indirectly force good programming habits. Each subproject can indeed adopt and publish a convention of its own. However, most projects with the exception of Turbine and Velocity did not publish conventions. (Please correct me if I am wrong.) Avalon has one ... based on an earlier version of Turbines. I am not suggesting that we jettison the code and fire the committers, that would be pointy-haired. no but you are suggesting that the people who actually do the work no longer get to have a say in how they write code. Thats not pointy-haired at all! As soon as I see my first jakarta paycheck I will happily change over. You are saying the individual first collectivity second. How about collectivity first and the individual second? If it was a legitimate concern then maybe we could do something about it. About the only thing I can think of that we would want to change is when people use conventions like a_class_name anObject = ...; anObject.do_something(); And that is mainly due to the fact that it effects people outside the project aswell. However I don't think any of the jakarta projects use those conventions and I am not going to be the one to force anyone to change if they do. Again, my proposal required al least two thirds majority of jakarta committers in order for the conventions to be adopted. You nor I alone, do we represent a two thirds majority. However, a two thirds majority represents the will of the community. If that is contested as seems to be the case here, then the only remaining possibility is that there is no community but a loose gathering of unruly individuals. Regards, Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
