Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?

Subject: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
From: Pierre Morcello (pmorcell-cppfrance_at_[hidden])
Date: 2009-09-10 20:44:35

Answer to Christian Schaldetsh;

>> "This position you have that some of us are arguing emotively and others
reasonably seems somewhat arbitrary. "

Sorry, I was refering to comments or claims inside some answers, not to people, sincerly. (source :"I am surprised to find so many comments like..."). In the case of your answer, I was too lazy to answer you sooner on the facts that you presented, but I was also feeling very uneasy with your logic. I am sorry you had to re-wrote your answer because of my lack of answer. If it seems arbitrary, then I will explain why things could not discussed anymore, because of the way you presented them. I will also present my point of view on your presentation/answer.

>> "I claimed that the style supported/encouraged by 'Breakable' is archaic.."
You seem to think that archaic is bad. Well, as a matter of fact there is no logic telling you that something archaic is bad : do you think everything new is good ? You see, this is not good for a discussion.

>>>"We have ways to do that in C++ using RIAA and exceptions. We also have
Boost.ScopedExit."  "refactoring to use a new function is applicable - or, it can be argued, suggested. The argument against this seems to be that adding more functions makes the code less readable. At this point, we diverge and I claim that it is about style in that case."

There are 2 points here. 
First point is something like "we already have very good technologies to do that". I agree that RAII, exceptions and functions are a very handy set of tools to do handle conditional branching. Unfortunately, this is not enough to jump to the conclusion : to go from city A to city B, I can take the car, the plane or the train. If
it is Paris -> New York I will prefer the plane, if it is Paris ->
Strasbourg, I will prefer the train. So for each very good technology
there may be a slightly different usage, even if the aim is globally
the same. In the current case, I don't see in your point why the presence of the other technology should make Breakable not more appropriate in some cases. How I am supposed to answer when I do not understand your logic? 

Second point is something like (correct me if I am wrong) "Breakable can be seen as a somewhat equivalent to function. I claim functions are as much readable as Breakable. As a consequence, it is all about style."
I did, in a previous answer, gives some other reason in my opinion to prefer Breakable in some case : productivity, simplicity and maintanability. As you code less, there are less prone to some errors. As there are less lines, you can follow more code in one glimpse. As you do not need to carefully choose a function name, but instead may use a traditionnal comment, or consider the code trivial, you don't spend time looking for it (you won't introduce doubt in the head of the maintainer of the code). You also do not need to maintain the changes to function prototypes, and also to maintain precondition and post condition tests in the function. This simplicity is understandable by most people. These are facts that I see, and this was good material if you wanted to argue (ex of sentence you could have written : "I would not use precondition tests in that case ..." ).

Then concerning readability only, you seem to evaluate readability magically without explaining your selection criteria. At least I tried the best I could to present some facts, and you just stepped over them without reason. How am I supposed to answer to such points? So, I supposed it was better not to answer.

I am very new to these forums, and I try my best to do things readable and understandable for people. Even now I am often misunderstood. But if I were justifying my proposition like you judged it, how could we ever find the solution to the dilemma ? I hope you understand why I was so uneasy with your answer.

I am ok to change my mind on any subject (including the Breakable of course), as long as you are enough logical to prove me you are right (or I am wrong :-)).

In all cases, I appreciate the efforts you made to explain your point of view a second time. I will, on my side, try to make myself clearer when I say something that could be ambiguous 

I apology if anyone else felt it as a personnal attack, this was absolutely not intended. 
I hope this is clearer and closed.

Now on the other elements of your answer :

>>"it could be said to support old Win32 coding style, or old DirectX
coding style, but these are terrible things to want to support!" 

>>>"I think that 'Breakable' encourages bad style."
Do you mean that it would always be "bad style" ( <=> Breakable is never useful / is always bad) ? 
Or do you mean that it can be misused too easily ?

Best regards,

Pierre Morcello

--- En date de : Mer 9.9.09, Christian Schladetsch <christian.schladetsch_at_[hidden]> a écrit :

De: Christian Schladetsch <christian.schladetsch_at_[hidden]>
Objet: Re: [boost] [Boost.Breakable] Any interest in a Boost Breakable library?
À: boost_at_[hidden]
Date: Mercredi 9 Septembre 2009, 16h24

Hi Pierre,

This position you have that some of us are arguing emotively and others
reasonably seems somewhat arbitrary. I claimed that the style
supported/encouraged by 'Breakable' is archaic. It is so because it is very
branchy and used for trapping error conditions and providing cleanup code.
We have ways to do that in C++ using RIAA and exceptions. We also have
Boost.ScopedExit.

In all cases where Breakable is used, refactoring to use a new function is
applicable - or, it can be argued, suggested. The argument against this
seems to be that adding more functions makes the code less readable. At this
point, we diverge and I claim that it is about style in that case. If this
is not 'factual' enough of an argument, I am at a loss.

I don't think Breakable adds anything of real value, and I personally would
never use it. As a lead programmer in the games industry, I also would not
let anyone in my team use it. Yes, it could be said to support old Win32
coding style, or old DirectX coding style, but these are terrible things to
want to support! Anyone that has ever read the DX SDK sample code realises
that it is madness to use the raw APIs directly. We wrap them in smart
objects and use those. We don't use them as is.

I firmly believe that this is really about style. I think that 'Breakable'
encourages bad style. There are "better" ways to do what it does, via
application of known idioms.

In any case, I am repeating myself so I'll let it be. Thanks for the making
proposal.

Kind Regards,
Christian.

On Thu, Sep 10, 2009 at 9:34 AM, Pierre Morcello <
pmorcell-cppfrance_at_[hidden]> wrote:

> I am surprised to find so many comments like "it smells bad", "it is
> archaic", "this is all about style" because these are based on feelings and
> not facts. Feelings are fine when you are looking for a solution to a
> scientific problem, but not for judging results. Feelings can be easily
> twisted (by culture, experience ...), cannot be discussed sanely and can
> lead to wrong results. (ex: there is a general formula to factorize polynom
> of degree 1,2,3,4... the feeling tells there is also one for 5, but with
> facts it was proven to be impossible).
>
> As a consequence, I will not try to discuss such points. On the contrary,
> the lasts answers written by Robert Stewart are in my opinion a good base to
> discuss, because they are clear and describe facts.
>
> //--------------------
> At Robert Stewart,
>
> First, I would like to present my deepest apologies, because I did not
> forsee a copy/paste problem within my webmail that inserted "double return"
> in my lines. This made the presentation of the code different from what I
> intended to present, and also from my whole mail. It was supposed to be
> exactly as you rewrote it.
> Now on the differents things that were mentionned, I happen to find that I
> share your point of view on many aspects.
> 1/ we agree on the fact that writing a 'subclass' inside the function is a
> nice solution to many problems.
> sourcePM : "If the sub-part is very specific and 'middle-big', a local
> struct with methods is much nicer."
> sourceRS : "Even if the original code in question is in a member function,
> the other functions need not be so"
>
> 2/ we agree that we need to use at least assertions of not documented
> functions
> sourcePM : "Without these comments, I suppose I will also end asserting
> everything in the code I already already tested back in the 'parent'
> function."
> sourceRS : "For preconditions and postconditions of implementation detail
> functions, I rely on assertions.  Documentation can easily become dated and
> the maintainers can easily follow the assertion logic."
> On this case, I had forgotten the problem of maintanability of the
> documentation that you explain.
>
> 3/ we agree that the code of a Breakable is vertically structured and very
> homogeneously presented.
> sourceRS : "That is a nice benefit."
>
> 4/ I also agree with you that even if something is present in another
> language, there is no reason to accept it as a good thing.
>
> The discussion you had with Ilya Bobir on the variety of code in the C++
> world me think to my own case.
> I worked for video games industry and develops today mainly 'serious
> games', focussing on 3D algorithms and using computer vision systems (I also
> teach at phd level these techniques, and lead research projects at my job on
> these subjects). I worked on weaponary systems and I also have a tiny
> experience with ERP coding. The coding rules are completely differents for
> these worlds.
> What you describe is the 'perfect C++' seen in ERP coding and weaponary
> systems for example. In that case, the project is specified clearly before
> the start, and the people working on it do not change every monthes.
> In video games industry, on the contrary you have to tests a lot of
> differents algorithms to satisfy a feeling, or a changing story, changing
> specifications ... there are also many 'tricks' everywhere.
> Just have a look at the "crysis game" code source : many functions are more
> than 50 lines long with many special cases (I am referring to the C++ part
> available in the 'crysis mod sdk'). You might think they got stupid coders,
> but the truth is that they oriented their code in a way that allowed easy
> and quick changes. This was the "less worst case" for them.
>
> Specifying a local struct for a local function is most of the time ok as
> long its number of parameters does not change 10 times a day (sometimes
> more)..
> Optimising an algorithms is also simplier when you got visual access to its
> function easily. So 4 embbeded brackets happens regularly. Asserting things
> that were already tested just before in another functino is also quite nasty
> : you need to code more and maintain more code than what you really use..
> For this reason also, game coders do not hesitate to write longer function.
>
> Of course everybody would like to use beautiful code. But during the
> developments, it just keeps changing a lot.
>
> Now, the more I think of it, the more I realize that while the 'Breakable'
> idiom is extremely handy for such developpments, it may not really be for
> others.
> This is making me understand your point of view even more.
>
> //-------------------
> To Kenneth :
> You wrote : "there is a book titled "Analysis Patterns" by Martin Fowler"
> Thanks, I will see if I can find more information on this book.
>
>
> //--------------------
> To everyone:
> >From the differents exchanges, right now I notice :
> -> the good usage of the Breakable is not to be used everywhere, but only
> when in front of a specific function with embedded if / else that are not
> too long.
> -> I continue to think this a good idiom, handy in many case I witnessed in
> my work.
> -> many advices against the Breakable, but some exchanges were based on
> feelings, not facts
> -> some people happy with the idea/idiom, but not interested in a library
> because it is a one liner.
> -> some people interested if there is something more with it.
> -> some people interested in unnamed local function through a macro that
> could also returns value.
>
> As a consequence, I have no plan to submit to boost anything in that state.
> I will have time to take a look deeper on the suggestions next week
> (because I am on holidays).
>
> Don't hesitate to judge my proposition with facts, or propose/suggest with
> feelings :-).
>
> Thanks a lot to everyone who answered,
>
> Pierre Morcello
>
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost