Re: SproutMethod.pdf

From: Costin Cozianu (c_cozianu_at_hotmail.com)
Date: 11/20/03

  • Next message: Hasta: "Re: Why refactoring is better" 
    Date: Wed, 19 Nov 2003 22:05:06 -0800

    Ron Jeffries wrote:

    > On Wed, 19 Nov 2003 19:13:54 -0800, Costin Cozianu <c_cozianu@hotmail.com>
    > wrote:
    >
    >
    >>Yep, that's the reason why hardly any project these days is under 1000
    >>files (tiny little files I might add), with tens of thousands of 5 line
    >>methods. People are refactoring their asses into tiny little pieces, yet
    >>I hardly see somebody around these days who knows how to search for an
    >>invariant in a loop.
    >>
    >>Guys, will you please stop writing, and try to read more ?
    >
    >
    > Costin, unless my memory is failing even more than I realize, one of my advanced
    > degrees is in computer science, and the other is in mathematics. I've spent
    > literally years proving things -- yet I have never found those techniques to be
    > consistently useful in the kind of software I'm actually called upon to write.
    >
    > Do you actually use proof-based and mathematical techniques day in and day out
    > in your software development work? If so, I would truly like to know more about
    > what you work on and how you do it. I really don't see how to get that material
    > to be applicable to what most of us do.
    >

    Not day in and day out, not at all. However often enough to find them
    useful and to find the lack of consideration for mathematical aspects of
    programming very troubling indeed. Please read more into what I write
    than a plea for proof driven design.

    For example, the armies of unqualified programmers are illusioned about
    these refactoring thingies and OO voodoos, to the point that they
    literally forget that they have to make a transformation from Point A to
    Point B. It even shows on your latest article on bowling :) Common, if
    you were Dijkstra's student he'd have looked upon you disapprovingly:
    what the hell do you waste so many lines of code for ? The Frame classes
    and the whole OO aparatus can only be make points at "artistic
    impression". Nobody seemed to be concerned anymore with keeping the LOC
    low, anymore as long as you can keep methods in 5 lines or less. So more
    or less, the classical basis of programming: how to write loops, how to
    avoid bad control flow structures, how to maintain invariants is lost.
    The lack of a mathematical "coolness" (in Miles Davis kind of way), can
    also be seen and quantified in the design disaster of many OO
    frameworks, that are designed based on just a "OO hunch" with no clear
    objective measure of what there is to look for in a good design.

    But where do I use proofs ? I do not use proofs per se, as they are too
    expensive and I don't have IDE support, I'm too lazy bun to do it
    otherwise. However, I believe that for the critical portions of my code
    I can aquit myself of Dijkstra's "proof obligation" : be *able* to proof
    that the program meets the required properties. And when the design is
    driven by the need to meet specific properties, it will be much cleaner

    Sometimes I wished I could avoid that, but in the end I still can't.

    For example I'd be extremely grateful if you or anybody else would spare
    me the pain for the next project. So give me a messaging framework that
    can support out of the box:

    - send data between Java to .NET as painlessly as possible.
    - have soft real time characteristic, meaning if I have the message with
    high priority, it should arrive from point A to point B not much longer
    than if I'd have had a twisted cable between them, that is regardless of
    what other traffic is clogging the channels
    - have a separate streaming interface for bulk data
    - be able to optimize bulk data broadcast (for example if transmitting
    from point A, over the internet to point B1 B2 B3 on the same intranet,
    the 100MBs should traverse the internet exactly once.
    - Be able to tunnel over HTTP(S) when needed. Do that also in reverse.
    Meaning: instead of a client pushing/polling data to/from the server in
    an HTTP request, the server should be able to push data to the client
    - Preserve ACID characteristics for messages marked as such (i.e.
    survive network failures, users tripping over the power cable, etc
    - Oh, yes. Integrate with a good enough security infrastructure so that
    no moron can inject messages between any 2 points

    Again if anybody can recommend something for real, (meaning more than
    vendor whitepapers to document te above) I'd be extremely grateful.

    Now given the state of the art in CS, this kind of thing should have
    existed a decade ago (everything minus C# and Java). As far as I know,
    it isn't there, so I have to improvise.

    Can you conceive of meeting the above requirements without a
    mathematically driven approach ?

    Best,
    Costin

  • Next message: Hasta: "Re: Why refactoring is better"

    Relevant Pages

    • Re: SproutMethod.pdf
      ... Design Paterns book) (i.e. through Factories, ... Refactoring and the other techniques that I write about are in fact ... security and other essential features were lost on the ... > I know how to write good programs sometimes, using mathematics, but as you point ...
      (comp.object)
    • Re: SproutMethod.pdf
      ... >programming very troubling indeed. ... >also be seen and quantified in the design disaster of many OO ... However, I find, as I gather you do, that the applicability of the techniques ... I know how to write good programs sometimes, using mathematics, but as you point ...
      (comp.object)
    • Re: lisp - low permutations explanation of code managability
      ... XP and test-first programming, which typically focus on object-oriented programming. ... What I've read of XP tells me not to do a Big Upfront Design ... from the process of refactoring. ... My understanding is that you first write the test cases, and then try to change the code to make the whole test suite work fine again. ...
      (comp.lang.lisp)
    • Re: OO Design induces an existential crisis
      ... Although refactoring and xp practices have good reasons of existance ... If you have the competency to design a component ... I enjoy programming, take it seriously, and by general ...
      (comp.object)
    • Re: Future tools should do less building and more analyzing
      ... will have on the current design and implementation, ... Some methods, many advocated as part of Extreme Programming for example, ... What I think many miss is that refactoring no less applies to *requirements ... keep an entire code base coherent and consistent, ...
      (borland.public.delphi.non-technical)