Automatic source code formatting bug.

"Bill Schwab" <[hidden email]> wrote in message
news:c2iel2$jg0$[hidden email]...
> > Just to be clear.  My objection to the RB's reformatting is not, and
never
> has
> > been, that it formats the code "wrongly" -- that's not the issue at all.
>
> Likewise.  It moves comments to the point that efforts to communicate with
> myself and others are thwarted at best, and can become flatly misleading.
> Unit tests are wonderful, but they are not magic, and do not guarantee a
> quality product.

That is the only problem I have with it, that it moves comments.  I was once
helping someone refactor a really messy method, it was so messy in fact that
it needed a lot of in-line comments to explain what was happening.  I think
I used the "extract method" feature once, and it threw all the comments to
the top of the method.  I can accept its formatting, and sometimes really
appreciate that.  I just wish the comments would stay where they are.  I
suppose they could be included in the parse tree and preserved just like
code.

Chris

Chris,

> > Likewise.  It moves comments to the point that efforts to communicate
with
> > myself and others are thwarted at best, and can become flatly
misleading.
> > Unit tests are wonderful, but they are not magic, and do not guarantee a
> > quality product.
>
> That is the only problem I have with it, that it moves comments.

I could think up some others, but it's the show-stopper.


> I was once
> helping someone refactor a really messy method, it was so messy in fact
that
> it needed a lot of in-line comments to explain what was happening.  I
think
> I used the "extract method" feature once, and it threw all the comments to
> the top of the method.

One could argue that the need for the comments disappears with the
refactoring, and there is some truth in that.  My concern is over problems
that do not have obvious solutions, as well as code that evolves over time.


> I can accept its formatting, and sometimes really
> appreciate that.  I just wish the comments would stay where they are.  I
> suppose they could be included in the parse tree and preserved just like
> code.

That would help a lot.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:c2j0hb$neu$[hidden email]...
> Chris,
>
> > > Likewise.  It moves comments to the point that efforts to communicate
> with
> > > myself and others are thwarted at best, and can become flatly
> misleading.
> > > Unit tests are wonderful, but they are not magic, and do not guarantee
a
> > > quality product.
> >
> > That is the only problem I have with it, that it moves comments.
>
> I could think up some others, but it's the show-stopper.

If you really consider this to be a "show-stopper" (an exaggeration of a
cosmetic issue in my book, but our opinions obviously differ), then you have
two choices: a) Stop using the formatter (which implies not using the
Refactoring Engine either), or b) Fix it, either individually or in concert
with other individuals for whom this is a concern. To coin a phrase, one
would have to be "barking mad" to dispense with automated refactoring
support, so that leaves (b) as the only realistic option. Personally I won't
be working on it, and since (AFAIK) Don & John care even less about it than
I do, I wouldn't expect them to devote any more of their personal time to it
either.

I've made this suggestion in response to similar carping before*, but it
seems that everyone has either chosen option (a), or stopped worrying about
it. Having used the formatter as the basis of a formatter for a rules
processing language, I know that the handling of comments can be improved.
It isn't terribly easy, but it is possible. I don't believe it is possible
to handle every case in the way a user might expect, since it is only
possible to make an educated guess as to which node in the parse tree a
comment relates, but certainly one could keep comments embedded in a cascade
within a reformatted cascade (for example).

Regards

Blair

*From
http://groups.google.com/groups?q=Dolphin+formatter+blair&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=3ecdeed5%241%40news.totallyobjects.com&rnum=1

"[The most important thing about the formatter ]for me is that it frees me
from having to
waste thinking energy on just how code should be formatted. Like you I
sometimes don't particularly like the results, but I don't care about that
anymore because it is at least consistent, and the brain quickly learns to
recognise a consistent form. I no longer get into "formatting paralysis",
and concentrate completely on the codes function rather than its layout.
Also I know that no one format will satisfy all readers of the code, so
careful manual formatting to my own taste is really not worth the effort.
Likewise I can view/reformat others code in that same format without wasting
time and risking RSI. Actually it is this which motivated the "auto-format"
option. The idea is that the underlying format of the source code really
doesn't matter, and that each user should be able to display it in some
reasonable approximate to their own preferred style. Of course one's
preferred style might not be supported by the configurable formatter, but it
is open to modification/subclassing/replacement if this is really that
important to you. I'm sure even the comment handling could be sorted (or at
least improved upon) by someone who care about it enough :-).

Blair,

> If you really consider this to be a "show-stopper"

I do, and I wish more people did.

> (an exaggeration of a
> cosmetic issue in my book, but our opinions obviously differ),

Clearly.

>then you have
> two choices: a) Stop using the formatter (which implies not using the
> Refactoring Engine either),

Which is what I have done.  I don't go quite as far as Chris; I greatly
enjoy the parts of the RB that do not need to rewrite source code.  I also
use it on "new" code that hasn't built up the kind of history-revealing
comments that have bailed me out of many ugly situations (both technical and
political/legal).


> or b) Fix it, either individually or in concert
> with other individuals for whom this is a concern. To coin a phrase, one
> would have to be "barking mad" to dispense with automated refactoring
> support, so that leaves (b) as the only realistic option. Personally I
won't
> be working on it, and since (AFAIK) Don & John care even less about it
than
> I do, I wouldn't expect them to devote any more of their personal time to
it
> either.

You are clearly not alone, but as more and more of Smalltalk systems becomes
un(der) documented, we will be in a really poor position to create new
users.

I will close by revisiting my example of an eXtreme Programmer seeking a
job.  Immagine explaining to a potential employer that you: (1) boldly make
last minute changes; (2) don't generally comment code; (3) leave it all to
"testing" (albeit automated) to catch bugs; (4) BTW, you are going to hire
my pair programming partner too, right?  Obviously I'm putting it strongly
to make a point, but I think there is room for debate here.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> I will close by revisiting my example of an eXtreme Programmer
> seeking a job.  Immagine explaining to a potential employer that you:
> (1) boldly make last minute changes; (2) don't generally comment
> code; (3) leave it all to "testing" (albeit automated) to catch bugs;
> (4) BTW, you are going to hire my pair programming partner too,
> right?  

Oh come on now, this just appears to be more FUD, this time being
spread about eXtreme Programming. It seems that XP is something that
you don't practise because you don't believe in the tenets involved.
Now that's fair enough (each to his own and all that) but the above
paragraph make no sense to me and just succeeds in casting doubt into
the minds of potential XP newbies. Here is my take on what you say
above:

Ok, so you are an XP programmer seeking a job, then there are two
disctinct scenarios; the employer already practises XP or is keen to
start, or the employer uses more traditional methods and may be
resistant to change. In the first case, I would say that explaining the
above* to an XP employer would make them heartily embrace you and
welcome you onto their team, probably without a second interview.

In the latter case, where your potential employer has yet to see the
light you would naturally use a more tactful approach (I always think
it is best to use "tact" in an interview situation if one is to achieve
best results). I would say:

(1) That I am used to creating large test suites to give as much
coverage of an application as possible. The benefit of this is that I
can catch more bugs before release that if I rely on compiler errors
alone and I also then have a reliable method of telling whether any
maintenance change has broken existing functionality.

(2) This testing framework then gives me the confidenced to make "bold
last minute changes" to the software (after all, when under pressure
what developer has not done this in the past, and typically been
punished by releasing a buggy piece of untested software).

(3) Similarly, the testing framework also allows me to "refactor" the
code between releases to ensure that the codebase does not "age"
prematurely. At this point I would waffle on about refactoring seeming
to me to be like "annealing" both increasing the strength and
malleablity of software.

(4) I would then explain that the testing mentality could be expanded
should the company wish to adopt Test Driven Development. The
advantages would be improved specification of required changes, reduced
need for comments (which, in past experience, often don't get updated
to match code changes), faster coding, and most importantly - knowing
when to stop. Still, I would understand if the company was not willing
take such bold steps just yet.

(5) Of course, I might mention that to go completely other practises
(such as pair programming) would be beneficial but I would also point
out that this would not typically require the hiring of twice as many
programmers, if only because development/training/mentoring times under
this way of working will likely be much reduced.

*Your comment (4) is not what XP recommends at all. One doesn't go
around with a lifelong "XP buddy" who needs to be hired together with
you. Normally you will work with different partners at different times
so that experience is spread around the team.

> Obviously I'm putting it strongly to make a point, but I
> think there is room for debate here.

Well there is always a case to be made for putting something strongly
but there is a difference between strength and exageration I think.
Similarly, there is always room for debate to isolate the strength or
weakness of a point or points; hence this rejoinder.

Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> where your potential employer has yet to see the light [of XP]
> you would naturally use a more tactful approach [...]

Not wanting to get into the XP debate (I've already said all I want to say),
but if you were *actually* looking for a job then you'd be well advised to stop
talking after point (3).

If points (4) and (5) come out at all then make *sure* it's in a context where
it doesn't come across as if you expect prospective employers to change their
working patterns to suit you.

That comes *after* you've got the job ;-)

    -- chris

Andy,

> Oh come on now, this just appears to be more FUD,

Given the time that I have spent using, advocating, and fighting for
Smalltalk in general and Dolphin in particular, I think you are on really
thin ground.


> this time being

It appears that you are accusing me of being a serial FUDer.  I am sorry you
think that is the case.  You could not be more wrong.


> spread about eXtreme Programming. It seems that XP is something that
> you don't practise because you don't believe in the tenets involved.

No, I believe in the parts, but I consider the whole to be quite dangerous.
Taken to its logical conclusion, it could lead to systems that are all but
undocumented.  Much worse, it plays into the fears of those I am trying to
sell on Smalltalk and systems built with it.


> Now that's fair enough (each to his own and all that) but the above
> paragraph make no sense to me

I doubt it, because...

> and just succeeds in casting doubt into
> the minds of potential XP newbies.

That is the point - hopefully that newbie will read and think.


> Ok, so you are an XP programmer seeking a job, then there are two
> disctinct scenarios; the employer already practises XP or is keen to
> start, or the employer uses more traditional methods and may be
> resistant to change. In the first case, I would say that explaining the
> above* to an XP employer would make them heartily embrace you and
> welcome you onto their team, probably without a second interview.

Perhaps, but given the number of times I've had people suggest that I
"mainstream" my software by using some "standard language like C#", the more
I see the need to take the battle to those who don't already grasp the value
of dynamic languages.  Not only is XP too much for the people I have in
mind, but they will see the negative consequences (and there are some) as a
reason (or excuse) to reject a Smalltalk project.


I'm not sure that no compiler errors buys very much, but otherwise it's a
good point.


> (2) This testing framework then gives me the confidenced to make "bold
> last minute changes" to the software (after all, when under pressure
> what developer has not done this in the past, and typically been
> punished by releasing a buggy piece of untested software).

Which is precisely why it will scare the DLL out of most people.


> (3) Similarly, the testing framework also allows me to "refactor" the
> code between releases to ensure that the codebase does not "age"
> prematurely. At this point I would waffle on about refactoring seeming
> to me to be like "annealing" both increasing the strength and
> malleablity of software.

I largely agree, and would make better use of the RB were it not for the
concerns that I've already raised.



> (4) I would then explain that the testing mentality could be expanded
> should the company wish to adopt Test Driven Development. The
> advantages would be improved specification of required changes, reduced
> need for comments (which, in past experience, often don't get updated
> to match code changes),

No question about that.  However, they do eventually get updated, and it is
the internal "journaling" kinds of comments (the ones the RB scatters with
abandon) that are the most useful in my experience.  After a while, a chain
of month/year dated items can turn into a very useful record.



Of course, but what I wrote is pretty close to what an interviewer will
hear.  Your hypothetical newbie should consider that _before_ the interview.


> Similarly, there is always room for debate to isolate the strength or
> weakness of a point or points; hence this rejoinder.

For which thanks.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Andy,
>
> > where your potential employer has yet to see the light [of XP]
> > you would naturally use a more tactful approach [...]
>
> Not wanting to get into the XP debate (I've already said all I want to
say),
> but if you were *actually* looking for a job then you'd be well advised to
stop
> talking after point (3).
>
> If points (4) and (5) come out at all then make *sure* it's in a context
where
> it doesn't come across as if you expect prospective employers to change
their
> working patterns to suit you.
>
> That comes *after* you've got the job ;-)

I know your comments are partly tongue in cheek Chris, but I'm going to
respond on Andy's behalf on this one since I expect that he will be too
modest to do so: Andy was formerly the Technical Director of a medium sized
company. Should he ever be entering the employment market again (long may
that not be necessary), for any position at his level the interviewer would
absolutely expect the candidate to be someone capable of both initiating
change and making it happen. Any company that didn't expect its executive
directors (VPs and above in US parlance) to do that would probably not be
worthy of consideration.

Regards

Blair

"Bill Schwab" <[hidden email]> wrote in message
news:c2l2qd$t3g$[hidden email]...
> Blair,
>
> > If you really consider this to be a "show-stopper"
>
> I do, and I wish more people did.

Why? So that they are put off using the RB (of course not, I am sure you
wouldn't want that), or so that they are motivated to fix it? Bearing in
mind that the RBs formatters are becoming the de facto standard for
Smalltalk (being used in VW, Dolphin, and, I presume, Squeak), there ought
already to be enough of a population to whom this is a sufficient irritation
that they are prepared to invest some of the time they can save by using the
RB in helping address the issues. I think it a great shame that anyone would
consider this a show-stopper, and I am concerned about that because it (or
the expression of that viewpoint as it might be interpreted by the
uninitiated, even if that is not the intent) might prevent someone from
benefiting from this fantastic tool by putting them off before they have
even tried it.
and
> political/legal).
>

OK, so assuming that you accept some level of auto-formatting of your code
(which Chris does not, as I understand it), let's be more constructive and
try and identify the specific situations where the formatter does move
comments. Even better let's come up with some test cases. If we can do this
then I think it far more likely that a fix might happen. Even without a fix
it might help people to know how they modify their commenting style to
workaround the problem until a fix is forthcoming - presumably the precise
position of the comment matters less than that it is clearly associated with
a particular syntactic element, so if you have to put if before that element
rather than after it (for example) in order to ensure that it remains
associated with that element then that would be acceptable in the short
term.

Let's also distinguish between what was and what is; since John Brant made
some changes to the formatter code (which were released with 5.1 as I
recall) its handling of comments did significantly improve, and it is
somewhat of an exaggeration to say or imply that it now throws comments
around in a completely arbitrary fashion even if it did that in an earlier
version. I certainly haven't seen it move method level comments incorrectly,
so I presume we are only concerned with in-line comments?

A normal in-line comment (i.e. some text on the line preceding the
statement) will normally be preserved in my experience. A couple of specific
cases I know about where it gets things wrong are these:

1) Any in-line comment in a cascade will be moved to the end of the
statement, regardless of where it appears.
2) A comment before the first statement in the method, which gets moved up
to become a method level comment, even where there is an existing method
comment and some temporary variables are declared.

>
> > or b) Fix it, either individually or in concert
> > with other individuals for whom this is a concern. To coin a phrase, one
> > would have to be "barking mad" to dispense with automated refactoring
> > support, so that leaves (b) as the only realistic option. Personally I
> won't
> > be working on it, and since (AFAIK) Don & John care even less about it
> than
> > I do, I wouldn't expect them to devote any more of their personal time
to
> it
> > either.
>
> You are clearly not alone, but as more and more of Smalltalk systems
becomes
> un(der) documented, we will be in a really poor position to create new
> users.

I won't comment on that because I think it is well covered in the XP
literature.

>
> I will close by revisiting my example of an eXtreme Programmer seeking a
> job.  Immagine explaining to a potential employer that you: (1) boldly
make
> last minute changes; (2) don't generally comment code; (3) leave it all to
> "testing" (albeit automated) to catch bugs; (4) BTW, you are going to hire
> my pair programming partner too, right?  Obviously I'm putting it strongly
> to make a point, but I think there is room for debate here.

I don't see how this is relevant to this particular thread, but as you say
it is certainly worth of debate.

Regards

Blair

Blair,

> Why? So that they are put off using the RB (of course not, I am sure you
> wouldn't want that), or so that they are motivated to fix it?

My goal is to avoid what I consider to be a risk to the long term health of
Smalltalk systems.  That would be better served via a fix, but failing that
it seems wise to "get the newbies thinking", and hopefully to get the
not-so-newbies to rethink what might happen several years and many
refactorings from now.


> Bearing in
> mind that the RBs formatters are becoming the de facto standard for
> Smalltalk (being used in VW, Dolphin, and, I presume, Squeak), there ought
> already to be enough of a population to whom this is a sufficient
irritation

That is all the more likely if _somebody_ (and I take arrows as well as the
next guy) points out some potential problems, as unpopular as the effort
might be at first.


> that they are prepared to invest some of the time they can save by using
the
> RB in helping address the issues.

I could be wrong, but until recently, I got the sense that you were
completely disinterested in helping, and almost ridiculing the thought
process.  Now you're asking for unit tests, which is progress.


> I think it a great shame that anyone would
> consider this a show-stopper, and I am concerned about that because it (or
> the expression of that viewpoint as it might be interpreted by the
> uninitiated, even if that is not the intent) might prevent someone from
> benefiting from this fantastic tool by putting them off before they have
> even tried it.

There is another way to view this.  One of the best aspects of XP is "plan
only as much as needed".  Dynamic languages make that possible.  However,
one cannot completely throw out all configuration management with it, and I
see that as an unintended consequence of XP.



> OK, so assuming that you accept some level of auto-formatting of your code

I can live with it :)   Actually, I put in a fair amount of effort to
building a couple of different formatters, with the intent of doing just
that.  The configurable formatter failed to offer some options that I
wanted, and I had a race going between a home grown hack and a subclass of
the configurable formatter it.  However, the comments were not correctly
located in the parse tree, and the customizations broke with the next
release, so I settled for using the non-rewriting refactorings "only".  When
roughing in new code, I often use the RB because it does not contain
comments that need special treatment.


> (which Chris does not, as I understand it),

Unless he has changed his mind.  IIRC, at our last correspondence, he was
uninstalling the RB.


> let's be more constructive and
> try and identify the specific situations where the formatter does move
> comments.

Sounds great.


> Even better let's come up with some test cases.

Sounds even better.


> If we can do this
> then I think it far more likely that a fix might happen. Even without a
fix
> it might help people to know how they modify their commenting style to
> workaround the problem until a fix is forthcoming - presumably the precise
> position of the comment matters less than that it is clearly associated
with
> a particular syntactic element, so if you have to put if before that
element
> rather than after it (for example) in order to ensure that it remains
> associated with that element then that would be acceptable in the short
> term.

That was part of my initial attempt at coexistence with the RB.  There would
of course be some risk to code that does not meet the convention, but that
can be managed.  Ideally, it would be nice to have some kind of flag raised
when something can't be handled.

I'm thinking back a while here, but one fairly distressing thing was
cascades.  IIRC, comments within the cascade were moved above the receiver.
The results were unreadable, and arguably misleading in some cases.
Certainly, it hobbled the attempt to show what happened when.


> Let's also distinguish between what was and what is; since John Brant made
> some changes to the formatter code (which were released with 5.1 as I
> recall) its handling of comments did significantly improve, and it is
> somewhat of an exaggeration to say or imply that it now throws comments
> around in a completely arbitrary fashion even if it did that in an earlier
> version. I certainly haven't seen it move method level comments
incorrectly,
> so I presume we are only concerned with in-line comments?

That was the most critical problem.  I will take another look.


> A normal in-line comment (i.e. some text on the line preceding the
> statement) will normally be preserved in my experience. A couple of
specific
> cases I know about where it gets things wrong are these:
>
> 1) Any in-line comment in a cascade will be moved to the end of the
> statement, regardless of where it appears.

That's bad.  It sounds better than it was, but it will still hobble my
"notes to self" that have saved me on many occaisions.


> 2) A comment before the first statement in the method, which gets moved up
> to become a method level comment, even where there is an existing method
> comment and some temporary variables are declared.

That's almost as bad.  One might work around it by creating a method comment
when it does not exist, though I would rather see a predictable association
between the comment and the line below it (or whatever convention makes
sense).  As I said above, "legacy code" will have trouble, as would new code
written to the standard should the standard change.  My hunch is that
comments should go with the next line/statement/etc..


> > > or b) Fix it, either individually or in concert
> > > with other individuals for whom this is a concern. To coin a phrase,
one
> > > would have to be "barking mad" to dispense with automated refactoring
> > > support, so that leaves (b) as the only realistic option. Personally I
> > won't
> > > be working on it, and since (AFAIK) Don & John care even less about it
> > than
> > > I do, I wouldn't expect them to devote any more of their personal time
> to
> > it
> > > either.

We've come a long way.  But hopefully you can see why my first thought was
not to spend time writing test cases.  Perhaps Chris will conspire with me
to create some???



> I don't see how this is relevant to this particular thread, but as you say
> it is certainly worth of debate.

Andy did a fine job of standing up for XP.  But it's worth noting that not
all Technical Directors/VPs are as forward thinking as our mutual friend.
Likewise, many of those VPs remember peers who were fired over failed
projects.  The blame often centers on lack of documentation, run away bug
lists with bugs caught too late (by "testing" rather than developers), etc.
Most of them have no idea what dynamic laguages are, nor do they consider
that the failures they remember were likely due to the restrictions of
static languages, but I don't like seeing us play into their fears by (as
they see it) scoffing at documentation.

I agree that unit tests are the place to start.  I can't start this minute,
but will gladly work on them.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

you're sounding somewhat depressed ...

On Wed, 10 Mar 2004 08:46:46 -0500,
Bill Schwab <[hidden email]> wrote:
>> spread about eXtreme Programming. It seems that XP is something that
>> you don't practise because you don't believe in the tenets involved.
>
> No, I believe in the parts, but I consider the whole to be quite dangerous.
> Taken to its logical conclusion, it could lead to systems that are all but
> undocumented.  Much worse, it plays into the fears of those I am trying to
> sell on Smalltalk and systems built with it.
>

Not if you have a Customer on board who puts up a story "give me docs
for the api-programmer and the end user of this thing". This is
essential. But since the Customer has to pay for it, it's his decision,
whether he wants a "normal" written documentation.

>
> Perhaps, but given the number of times I've had people suggest that I
> "mainstream" my software by using some "standard language like C#", the more
> I see the need to take the battle to those who don't already grasp the value
> of dynamic languages.  Not only is XP too much for the people I have in
> mind, but they will see the negative consequences (and there are some) as a
> reason (or excuse) to reject a Smalltalk project.

This is a strong indicator for the *other* "change your organisation"
in my book.

>> (2) This testing framework then gives me the confidenced to make "bold
>> last minute changes" to the software (after all, when under pressure
>> what developer has not done this in the past, and typically been
>> punished by releasing a buggy piece of untested software).
>
> Which is precisely why it will scare the DLL out of most people.

As long as nobody talks about "last minute fixes", they seem to be okay
with management ... it's bringing this "weakness" into the daylight as
a strength to be proud of what scares the DLL out of them

Nice expression, BTW :-)

>> *Your comment (4) is not what XP recommends at all. One doesn't go
>> around with a lifelong "XP buddy" who needs to be hired together with
>> you. Normally you will work with different partners at different times
>> so that experience is spread around the team.
>
> Of course, but what I wrote is pretty close to what an interviewer will
> hear.  Your hypothetical newbie should consider that _before_ the interview.

another nail in the coffin ... interviewers hearing things that
programmers did not say.

Some weeks ago I had a talk with a potential customer about a software
project. I explained the "small iterations" approach we would like to
take, especially in the beginning of the project, because "we need to get
to know each other. You may find that we do not deliver the software you
expect us to, so you can get rid of us without any hassle." (nod, nod)
"We might find that we cannot communicate efficiently enough to enable
us to produce the software you want, so we can stop waisting our time."
(Eyes bulging a little bit here ...)

It might be of interest to note that we are right now in the middle of
the first iteration, so he was not totally scared off by this, er, blunt
speaking of me.

It might be different for employment interviews but I found it always
helpful to make it clear, that both participants want something the
other has. It's a money vs. brain power exchange and you don't want to
sell yourself too cheap.

Heads up, everywhere, take a deep breath, smile and off to work.

s.

Stefan Schmiedl wrote:

> As long as nobody talks about "last minute fixes", they seem to be okay
> with management ...

The phrase "optimise the temporal profile of risk vs. opportunity tradeoffs"
leaps to my mind at this point.

(Well, that *is* what we really mean, isn't it ?)

    -- chris

Stefan,

> you're sounding somewhat depressed ...

Thanks for the concern, but not to worry.


> Not if you have a Customer on board who puts up a story "give me docs
> for the api-programmer and the end user of this thing". This is
> essential. But since the Customer has to pay for it, it's his decision,
> whether he wants a "normal" written documentation.

I'm thinking more of intellectual property than shrink-wrapped software.  I
took the "job interview" approach because it is easier to describe in a
public forum.


> >
> > Perhaps, but given the number of times I've had people suggest that I
> > "mainstream" my software by using some "standard language like C#", the
more
> > I see the need to take the battle to those who don't already grasp the
value
> > of dynamic languages.  Not only is XP too much for the people I have in
> > mind, but they will see the negative consequences (and there are some)
as a
> > reason (or excuse) to reject a Smalltalk project.
>
> This is a strong indicator for the *other* "change your organisation"
> in my book.

Actually, my problem is to change "their organization" enough to license
things I create.


> another nail in the coffin ... interviewers hearing things that
> programmers did not say.

A good point, but the poor sap looking for a first job might be well advised
to think about it up front.


> It might be different for employment interviews but I found it always
> helpful to make it clear, that both participants want something the
> other has. It's a money vs. brain power exchange and you don't want to
> sell yourself too cheap.

Again, don't read too much into the example I chose; it was a convenient and
safe device to make a point.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

Since Blair has signed off for today and was kind enough to jump in and
post a reply on my behalf elsewhere in this thread I'll repay that
courtesy here...

> > that they are prepared to invest some of the time they can save by
> > using the RB in helping address the issues.
>
> I could be wrong, but until recently, I got the sense that you were
> completely disinterested in helping, and almost ridiculing the thought
> process.  Now you're asking for unit tests, which is progress.

I suspect you may have misconstrued what Blair is saying here. I'm sure
he'll correct me if I'm wrong but I still believe he is uninterested in
addressing this formatter issue with the RB (as am I). I think what he
was suggesting is that the creation of test cases should be the first
step towards any solution since they would greatly aid those members of
the community who may want to help with the code changes. Indeed, if
nothing else, the existance of test cases would map out the true scope
of the problem in an unequivocal way.

Why not start a thread, either in this group or c.l.s (since after all
it is a general issue with the RB not just limited to Dolphin) to see
if you can garner support from the community to (a) identify the real
scope of the comment problem with test cases and (b) fix the failing
tests?


Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> I think what he
> was suggesting is that the creation of test cases should be the first
> step towards any solution since they would greatly aid those members of
> the community who may want to help with the code changes. Indeed, if
> nothing else, the existance of test cases would map out the true scope
> of the problem in an unequivocal way.

Of course, and it should not be too difficult to illustrate it.


> Why not start a thread, either in this group or c.l.s (since after all
> it is a general issue with the RB not just limited to Dolphin) to see
> if you can garner support from the community to (a) identify the real
> scope of the comment problem with test cases and (b) fix the failing
> tests?

My vote (but I will gladly yield to Chris on this) would be to at least
start here.  We can always post the results to c.l.s, and since we are
archived more than one way, the discussion is open.  Details aside, it's an
excellent idea.  Chris?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

From: "Andy Bower" <[hidden email]>

> In the latter case, where your potential employer has yet to see the
> light you would naturally use a more tactful approach (I always think
> it is best to use "tact" in an interview situation if one is to achieve
> best results). I would say:
>
> (1) That I am used to creating large test suites to give as much
> coverage of an application as possible.

I've changed my mind about emphasizing this to an employer. If they're not
familiar with XP or TDD, they don't want you writing tests, they want you
writing code. Silly, but there it is. More impressive to such an employer
would be some way of showing that your methods (whatever they might be)
produce fewer bugs and quicker bug-free changes.

> (5) Of course, I might mention that to go completely other practises
> (such as pair programming) would be beneficial

Again, if the interviewer doesn't know about XP, I'd say mentioning
pair-programming was a sure way to end the meeting early. :)

"Bill Schwab" <[hidden email]> wrote in message
news:c2o7ej$ule$[hidden email]...
> Andy wrote:
...
> > Why not start a thread, either in this group or c.l.s (since after all
> > it is a general issue with the RB not just limited to Dolphin) to see
> > if you can garner support from the community to (a) identify the real
> > scope of the comment problem with test cases and (b) fix the failing
> > tests?
>
> My vote (but I will gladly yield to Chris on this) would be to at least
> start here.  We can always post the results to c.l.s, and since we are
> archived more than one way, the discussion is open.  Details aside, it's
an
> excellent idea.  Chris?

I suppose we can start a thread in this group first.  One important point
however: I think it would be best to leave out any discussion of XP in that
thread.  Personally I am neutral regarding XP.  It seems that some people
really feel strongly about it (both for and against), and I think it would
distract from the root issue.  I _think_ that regardless of our individual
development philosophies most people can agree that it would be an
improvement for the Refactoring engine to try to keep comments where it
finds them.  However for some people it would not be a significant
improvement, while to others it would be more significant.

It also sounds like there have been real improvements in the handling of
comments.  Our anecdotal experience may not be as valid anymore.  So it
probably is a good idea to collect a set of situations where comment
handling is currently non-ideal.  Then we can think about ways of improving
the handling.

Whoever comes up with an example first can start the thread, others can
chime in with additional examples.

Chris

Mark,


My post was in response to Bill's clearly exaggrated scenario of an
eXtreme Programmer looking for a job. What I wrote was what *I* would
do if I found myself in a typical interview situation. It may not be a
suitable approach for everyone but I always consider an interview to be
a two-way process. In effect I am interviewing the company and
management just as much as they are interviewing me and I would still
consider this to be the case no matter how lowly a position I was
seeking. Hence, if I were an XP programmer attending an interview (the
original scenario) I would also be aiming to see if the company would
be compatible with my ideals and work processes (i.e. would I be happy
working there). Of course if I was on the bread-line and desperate for
work at any costs these issues would likely go out of the window.

I do know, however, that in any job hunting situation I would not be
bluntly:

>> explaining to a potential employer that you: (1) boldly make
>> last minute changes; (2) don't generally comment code; (3) leave it
all to
>> "testing" (albeit automated) to catch bugs; (4) BTW, you are going
to hire
>> my pair programming partner too, right?  

To do so would be a fault in my interviewing technique rather than
programming methodology.

Best regards,


Andy Bower
Dolphin Support
www.object-arts.com

On Wed, 10 Mar 2004 17:13:56 -0500,
Bill Schwab <[hidden email]> wrote:
> Stefan,
>
>> you're sounding somewhat depressed ...
>
> Thanks for the concern, but not to worry.

ok, self delete: worry.

In that case, I'd recommend a separate notebook with dates, written with
pen, crossed out white space etc.

>>
>> This is a strong indicator for the *other* "change your organisation"
>> in my book.
>
> Actually, my problem is to change "their organization" enough to license
> things I create.

Always carry a small sample with you showing how you can interface with
the rest of the world. One of the most impressive in this regard is a
small piece of code ripped out of Forth Inc.'s Swift Forth samples:

Creating a DLL:

: SQ ( n -- n**2 )   DUP * ;
AS Square 1 EXPORT: SQ
PROGRAM CALC.DLL

Using a DLL:

LIBRARY CALC.DLL
1 IMPORT: Square
: TEST   3 Square .  ;

It's not important for the other to understand what's going on here,
it's important to show that interfacing a) can be done b) in both directions
with c) very little effort.

>
> Again, don't read too much into the example I chose; it was a convenient and
> safe device to make a point.

another nail in the coffin ... me reading things you did not write :-)

s.
--
Stefan Schmiedl
+-------------------------------+----------------------------------------+
|Approximity GmbH               | EDV-Beratung Schmiedl                  |
|http://www.approximity.com     | Am Bräuweiher 4, 93499 Zandt, Germany  |
|mailto:[hidden email]  | Tel. (09944) 3068-98, Fax -97          |
+-------------------------------+----------------------------------------+

Stefan,

> It's not important for the other to understand what's going on here,
> it's important to show that interfacing a) can be done b) in both
directions
> with c) very little effort.

That is excellent advice that doesn't quite fit in my situation, only
because we go much further than code samples.  The reality of external
interfacing should be clear (to anyone who is willing to see it) from the
systems we have running at present.  The _real_ problem is the "why don't
you recode that in ..." reaction.  I don't think I need to list the reasons
to leave it in Smalltalk, at least not in this forum :)  Nor do I need to
explain that the recoded result, if it worked at all, could easily turn out
to be slower, and certainly less mutable.

So how did we get from a bug in the parser/formatter to this conversation?
Among other reasons, I see a few of the stated reasons why "we can't use
that funny language" being amplified by unintended consequences of XP.  Most
of their stated reasons are FUD and excuses, but lurking under that is a
warning to the wise.


> > Again, don't read too much into the example I chose; it was a convenient
and
> > safe device to make a point.
>
> another nail in the coffin ... me reading things you did not write :-)

Another word for that is reading between the lines.  As you can see, there
was something to be found, but not quite what you thought.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]