«

On 6/26/2012 6:20 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> markspace wrote:
>>>> bilsch wrote:
>>>>> Many things are because I mimic what I see in other programs... I
>>>>> hope I can finish this project without understanding threads
>>>>
>>>>
>>>> Yeah, that's an issue. When teaching someone, is it better to let them
>>>> do it the simplest, but wrong, way? Or should you teach them to write
>>>> code they don't understand, but promise too "explain it later?"
>>>>
>>>> I'm actually in the latter camp at the moment. I'd rather see you copy
>>>> and paste good code, than let you get into the habit of writing bad code
>>>> that you feel you understand. It a style of learning thing, more than a
>>>> programming thing, but I think it's better to get you into the habit of
>>>> looking at correct code now, so it doesn't seem strange when you see the
>>>> correct version later.
>>>>
>>>> OTOH, it's not going to adversely effect your small programs. The
>>>> chance of you hitting a threading error in such a small program is
>>>> virtually nil. Just be aware that: 1. the code really is wrong, and 2.
>>>> you'll have to learn threads eventually.
>>>
>>> They've already hit a threading error.
>>>
>>> How is that "virtually nil" chance?
>>
>> Usually "hit [by] an error" means actually impacted by the error.
>>
>> I did not see any case of such.
>
> Have you run the OP's code?
>
> On a multi-processor system?

I had not.

Now I have.

I expect OP to have too.

The chance of actually getting a problem by starting
the GUI in main thread instead of event thread is pretty
small.

Otherwise the wrong way of doing it would not have
been used for so many years.

Arne

Arne Vajhøj wrote:
> Lew wrote:
>> Arne Vajhøj wrote:
>>> Lew wrote:
>>>> markspace wrote:
>>>>> bilsch wrote:
>>>>>> Many things are because I mimic what I see in other programs... I
>>>>>> hope I can finish this project without understanding threads
>>>>>
>>>>>
>>>>> Yeah, that's an issue. When teaching someone, is it better to let them
>>>>> do it the simplest, but wrong, way? Or should you teach them to write
>>>>> code they don't understand, but promise too "explain it later?"
>>>>>
>>>>> I'm actually in the latter camp at the moment. I'd rather see you copy
>>>>> and paste good code, than let you get into the habit of writing bad code
>>>>> that you feel you understand. It a style of learning thing, more than a
>>>>> programming thing, but I think it's better to get you into the habit of
>>>>> looking at correct code now, so it doesn't seem strange when you see the
>>>>> correct version later.
>>>>>
>>>>> OTOH, it's not going to adversely effect your small programs. The
>>>>> chance of you hitting a threading error in such a small program is
>>>>> virtually nil. Just be aware that: 1. the code really is wrong, and 2.
>>>>> you'll have to learn threads eventually.
>>>>
>>>> They've already hit a threading error.
>>>>
>>>> How is that "virtually nil" chance?
>>>
>>> Usually "hit [by] an error" means actually impacted by the error.
>>>
>>> I did not see any case of such.
>>
>> Have you run the OP's code?
>>
>> On a multi-processor system?
>
> I had not.
>
> Now I have.
>
> I expect OP to have too.
>
> The chance of actually getting a problem by starting
> the GUI in main thread instead of event thread is pretty
> small.
>
> Otherwise the wrong way of doing it would not have
> been used for so many years.

Not so. Those many years, Swing programs were running on single-
processor machines for the most part. Cache coherency and such
issues were non-existent. Nowadays many machines are multi-processor
and thread bugs are more likely to be visible.

If it were so safe, then it wouldn't be "the wrong way of doing it".

You are expressing the great bad approach to the concurrency problem:
"I don't see a problem in the last two or three times I ran the program,
therefore there is no problem."

This is the attitude that foments so many concurrency bugs.

Concurrency bugs by nature are intermittent, unpredictable and
inconsistent. Your test proves nothing except that you have fallen into
a classic trap.

OP: Don't learn the wrong way. Learn the right way. The fact you don't
see a bug in the first two or dozen times you run the program means
nothing with concurrency issues.

Rule for Swing: DO GUI ACTIONS ONLY ON THE EDT!

That's that.

--
Lew

Gene Wirchenko wrote:
> Lew wrote:
>> It is best to use the Java Coding Conventions or something very close.
>>
>> There are a couple of very limited acceptable variations from those
>> conventions.
>
> That is your religion.

Bullshit. That is my observation.

The Java Coding Conventions have been in play since 1999. I have
worked in many Java shops. All had coding standards. Mostly they
adhere to the official conventions, but all accepted or required certain
slight variations, pretty much consistently from one to the next.

Why would you say such a thing?

--
Lew

On 6/26/2012 7:44 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Arne Vajhøj wrote:
>>>> Lew wrote:
>>>>> markspace wrote:
>>>>>> bilsch wrote:
>>>>>>> Many things are because I mimic what I see in other programs... I
>>>>>>> hope I can finish this project without understanding threads
>>>>>>
>>>>>>
>>>>>> Yeah, that's an issue. When teaching someone, is it better to let them
>>>>>> do it the simplest, but wrong, way? Or should you teach them to write
>>>>>> code they don't understand, but promise too "explain it later?"
>>>>>>
>>>>>> I'm actually in the latter camp at the moment. I'd rather see you copy
>>>>>> and paste good code, than let you get into the habit of writing bad code
>>>>>> that you feel you understand. It a style of learning thing, more than a
>>>>>> programming thing, but I think it's better to get you into the habit of
>>>>>> looking at correct code now, so it doesn't seem strange when you see the
>>>>>> correct version later.
>>>>>>
>>>>>> OTOH, it's not going to adversely effect your small programs. The
>>>>>> chance of you hitting a threading error in such a small program is
>>>>>> virtually nil. Just be aware that: 1. the code really is wrong, and 2.
>>>>>> you'll have to learn threads eventually.
>>>>>
>>>>> They've already hit a threading error.
>>>>>
>>>>> How is that "virtually nil" chance?
>>>>
>>>> Usually "hit [by] an error" means actually impacted by the error.
>>>>
>>>> I did not see any case of such.
>>>
>>> Have you run the OP's code?
>>>
>>> On a multi-processor system?
>>
>> I had not.
>>
>> Now I have.
>>
>> I expect OP to have too.
>>
>> The chance of actually getting a problem by starting
>> the GUI in main thread instead of event thread is pretty
>> small.
>>
>> Otherwise the wrong way of doing it would not have
>> been used for so many years.
>
> Not so. Those many years, Swing programs were running on single-
> processor machines for the most part. Cache coherency and such
> issues were non-existent. Nowadays many machines are multi-processor
> and thread bugs are more likely to be visible.
>
> If it were so safe, then it wouldn't be "the wrong way of doing it".
>
> You are expressing the great bad approach to the concurrency problem:
> "I don't see a problem in the last two or three times I ran the program,
> therefore there is no problem."
>
> This is the attitude that foments so many concurrency bugs.
>
> Concurrency bugs by nature are intermittent, unpredictable and
> inconsistent. Your test proves nothing except that you have fallen into
> a classic trap.

????

I pointed out that you were wrong in claiming that OP had
already been hit by the error.

There were no indication that he had in host post. And
in fact the likelihood of being hit by problem even on multi
core is pretty slim.

I did not suggest that OP should ignore the problem.

I did not suggest that running the code with no problem meant
that the code was OK.

In fact it was you that suggested running the code.

So if there is somebody here that believes running the
code without problems indicates something then it must be you.

Arne

On 6/26/2012 7:26 PM, Gene Wirchenko wrote:
> On Tue, 26 Jun 2012 14:34:13 -0700 (PDT), Lew <>
> wrote:
>> Gene Wirchenko wrote:
>>> bilsch wrote:
>>>> advise is appreciated and noted. I know my indentation is wrong - it is
>>>> something I'll have to work on. I hope I can finish this project without
>>>
>>> Adopt an indentation style whether it is your own and one that
>>> you see that you are comfortable with. Consistent indenting can help
>>> you catch errors.
>>
>> It is best to use the Java Coding Conventions or something very close.
>>
>> There are a couple of very limited acceptable variations from those
>> conventions.
>
> That is your religion.

It is the recommendation from the inventors of the language.

And it is by far the most widely used coding convention from Java.

Facts not religion.

Arne

On 6/26/2012 10:18 PM, Arne Vajhøj wrote:
> On 6/26/2012 7:26 PM, Gene Wirchenko wrote:
>> On Tue, 26 Jun 2012 14:34:13 -0700 (PDT), Lew <>
>> wrote:
>>> Gene Wirchenko wrote:
>>>> bilsch wrote:
>>>>> advise is appreciated and noted. I know my indentation is wrong -
>>>>> it is
>>>>> something I'll have to work on. I hope I can finish this project
>>>>> without
>>>>
>>>> Adopt an indentation style whether it is your own and one that
>>>> you see that you are comfortable with. Consistent indenting can help
>>>> you catch errors.
>>>
>>> It is best to use the Java Coding Conventions or something very close.
>>>
>>> There are a couple of very limited acceptable variations from those
>>> conventions.
>>
>> That is your religion.
>
> It is the recommendation from the inventors of the language.
>
> And it is by far the most widely used coding convention from Java.
>
> Facts not religion.

State-sponsored religion is still religion

All things said and done, though, it's a very good idea to follow those
guidelines unless you have extremely compelling reasons not to.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

On Tue, 26 Jun 2012 16:47:37 -0700 (PDT), Lew <>
wrote:

>Gene Wirchenko wrote:
>> Lew wrote:
>>> It is best to use the Java Coding Conventions or something very close.
>>>
>>> There are a couple of very limited acceptable variations from those
>>> conventions.
>>
>> That is your religion.
>
>Bullshit. That is my observation.
>
>The Java Coding Conventions have been in play since 1999. I have
>worked in many Java shops. All had coding standards. Mostly they
>adhere to the official conventions, but all accepted or required certain
>slight variations, pretty much consistently from one to the next.
>
>Why would you say such a thing?

Because you keep harping about it. Perish the thought that
someone use something else workable.

Sincerely,

Gene Wirchenko

On Tue, 26 Jun 2012 22:18:28 -0400, Arne Vajhøj <>
wrote:

>On 6/26/2012 7:26 PM, Gene Wirchenko wrote:
>> On Tue, 26 Jun 2012 14:34:13 -0700 (PDT), Lew <>
>> wrote:
>>> Gene Wirchenko wrote:
>>>> bilsch wrote:
>>>>> advise is appreciated and noted. I know my indentation is wrong - it is
>>>>> something I'll have to work on. I hope I can finish this project without
>>>>
>>>> Adopt an indentation style whether it is your own and one that
>>>> you see that you are comfortable with. Consistent indenting can help
>>>> you catch errors.
>>>
>>> It is best to use the Java Coding Conventions or something very close.
>>>
>>> There are a couple of very limited acceptable variations from those
>>> conventions.
>>
>> That is your religion.
>
>It is the recommendation from the inventors of the language.
>
>And it is by far the most widely used coding convention from Java.
>
>Facts not religion.

So it is the most common religion. Big deal.

My coding conventions are cross-language as much as I can make
them.

Sincerely,

Gene Wirchenko

Gene Wirchenko wrote:
> Arne Vajhøj wrote:
>
> > Gene Wirchenko wrote:
> >> Lew wrote:
> >>> Gene Wirchenko wrote:
> >>>> bilsch wrote:
> >>>>> advise is appreciated and noted. I know my indentation is wrong - it is
> >>>>> something I'll have to work on. I hope I can finish this project without
> >>>>
> >>>> Adopt an indentation style whether it is your own and one that
> >>>> you see that you are comfortable with. Consistent indenting can help
> >>>> you catch errors.
> >>>
> >>> It is best to use the Java Coding Conventions or something very close..
> >>>
> >>> There are a couple of very limited acceptable variations from those
> >>> conventions.
> >>
> >> That is your religion.
> >
> >It is the recommendation from the inventors of the language.
> >
> >And it is by far the most widely used coding convention from Java.
> >
> >Facts not religion.
>
> So it is the most common religion. Big deal.
>
> My coding conventions are cross-language as much as I can make
> them.

You calling the conventions a "religion" neither invalidates nor diminishes
the value of the official conventions.

Your pitch for unconventional conventions violates the spirit and purpose
of the conventions, which is to provide a common basis for the community
to communicate their source code.

Your overtly anti-social and self-aggrandizing approach is not suitable
for playing nicely with others. Be less snarky about the choice to go with
the industry standards, please. I know it makes you feel all important and
powerful and all, but it doesn't serve those wishing to learn how best to
be *professional* Java programmers.

--
Lew

On Wed, 27 Jun 2012 11:42:04 -0700 (PDT), Lew <>
wrote:

[snip]

>You calling the conventions a "religion" neither invalidates nor diminishes
>the value of the official conventions.

I do not contest the value of the official conventions. I do say
that they are not the only conventions that can be used.

The official conventions (or any others for that matter) are a
religion when they are shoved on people regardless of the situation.

Your disdain for different conventions "neither invalidates nor
diminishes the value of" different conventions.

>Your pitch for unconventional conventions violates the spirit and purpose
>of the conventions, which is to provide a common basis for the community
>to communicate their source code.

My conventions are intended for me. Since I do not use only one
language, I want conventions that work across many languages. If I
work in a different environment, I will code according to what
conventions there are insofar as it does not endanger the quality of
my code.

Anyone who has difficulty reading my code is invited to learn
programming.

>Your overtly anti-social and self-aggrandizing approach is not suitable
>for playing nicely with others. Be less snarky about the choice to go with

No, *your* overtly anti-social and self-aggrandising approach is
not suitable. I gave up on Java, partly because the language making
certain things that I need awkward to do and partly because of the
snarking.

I remember posting one example of code that I was having trouble
with. It was short and simple and I detailed what I was having
trouble with. One of you Java religion twits responded that I was not
using the standard variable-naming convention and did not reply at all
to my problem. This sort of abuse happened too many times for me to
care much about the Java community or its standards.

I follow this newsgroup still because there are some good
technical discussions. I hope to never have to code in Java again.

>the industry standards, please. I know it makes you feel all important and

I state that I have my preferences. If you want to use the
official conventions, go ahead. I have never snarked anyone for doing
so.

>powerful and all, but it doesn't serve those wishing to learn how best to
>be *professional* Java programmers.

It does nothing of the sort for me. Making up things about me
may help you snark me yet again, but it does little for your point. If
learning how to best use Java depends so heavily on the official
conventions, Java is in horrible danger. An example of this is the
official documentation which is very poor and rates a D for its
incompleteness.

Sincerely,

Gene Wirchenko