[seek-dev] Re: [kepler-dev] Query Builder Code Review
Rod Spears
rods at ku.edu
Mon Aug 16 07:19:47 PDT 2004
Bertram wrote: "Kepler is really Ptolemy ++ X"
I think another way to view this would be that Ptolemy is a "toolkit"
for Kepler. For the most part, Kepler's code is completely separate from
Ptolemy's.
Rod
Bertram Ludaescher wrote:
>>>>>>"RS" == Rod Spears <rods at ku.edu> writes:
>>>>>>
>>>>>>
>RS>
>RS> Sorry, I completely disagree. Writing software is certainly not the same
>RS> as publishing academic papers, and I think it is a fascinating thought
>
>... one of the major differences being that you can actually do
>something with software ;-)
>
>Yes, they are different, but there is value to both and the difference
>is not as large as you may think. In some (life science) domains,
>publishing a paper is almost tantamount to uploading a dataset (having
>the experimental data, information about the protocol etc). The paper
>really just means to cut down a bunch of trees to produce paper that
>holds the long list of authors (all the students, postdocs, and last
>not least the lab director/PI ;-), plus of course the reputation of
>the journal -- which ultimately comes from the community itself.
>
>I like the idea of publishing working software alongside with the
>academic paper. Just as biologists are being forced to back up their
>claims and experiment outcomes by uploading/linking their data to
>known repositories (eg PDB) before the paper can get published in a
>certain journal, some branches of the computing world might think
>along similar lines. This will not apply to every branch of CS, but
>for some it might make sense
>
>RS> that Open Source could/should be considered a published work (sounds
>RS> like a discussion for another day).
>
>yeah
>
>
>As for the discussions on the coding style: I think I can see were
>both sides are coming from. I've heard developers say that the PTII
>coding style rules are quite non-standard and that may very well be.
>(even taking into account that there are different standards).
>
>At the same time we should remember that Kepler is really Ptolemy ++ X
>where X are the various wild ideas that we come up with in the context
>of scientific workflows. There is certainly great value in staying
>close to Ptolemy and having some (or many) things picked up as part of
>Ptolemy. We have seen by now several examples were work and ideas from
>Kepler directly or indirectly influenced Ptolemy thinking and led to
>code being produced in Ptolemy.
>
>So while you might not write Ptolemy code directly, writing more or
>less Ptolemy "conformant" Kepler code will increase the chance of
>Ptolemites (or Keplerites who think like Ptolemites... the
>intersection is not empty) looking at the code, providing feedback, or
>even incorporating it.
>
>But by the nature of things, we will not always agree.
>If the cost for developers is really too high (let's quantify that) to
>adopt those rules, then maybe we have to live with the suboptimal
>solution of having two styles (please not more than that..).
>
>Concurring with Edward in his follow up, I think the real challenge is
>not in the coding style (hey, aren't there tools that "fix" at least
>the layout style or create different "views")?
>
>It's in the abstractions that we devise (e.g. via semantic
>types.. making Shawn a Keplerite soon, or the original Ptolemy idea of
>separating actors from directors, or having composite actors, or
>having mobile code etc etc) it's these abstractions and new ones that
>will help organize actors into meaningful libraries that work together
>at the level the scientist (or the engineer) find useful..
>
>Bertram
>
>RS> The reality of Open Source software is that if you put a lot of rules in
>RS> place you begin to limit the contributions, and that can be both good
>RS> and bad. There is certainly a desired level of quality and certainly
>RS> rules enforce that etc. etc. It was always a very difficult line to
>RS> walk; that is, to encourage contributions and then figure out "how" to
>RS> accept good work that may not fit exactly into the place it needs to fit.
>RS>
>RS> For example on Mozilla, the lack of every single file, module and/or
>RS> line of code looking exactly the same was never a problem for anyone
>RS> contributing to the project (I can't say it hurt productivity or the
>RS> quality of the code).
>RS>
>RS> This discussion and it is one I have had over and over, reminds me of
>RS> the great commercial software dilemma: Would a software engineer rather
>RS> write:
>RS> 1) A perfectly engineered piece of software with no bugs, that doesn't
>RS> sell a dime.
>RS> 2) A rather odd piece of software with some questionable design and
>RS> architectural decisions that sells millions of copies.
>RS>
>RS> Certainly when writing commercial code, productivity ranks up there with
>RS> quality and all the other important aspects of creating great software.
>RS> I have seen this over and over again at the start of every project. The
>RS> engineers wrangle over coding style for weeks, nobody can agree but with
>RS> the higher levels of a style guide and in the end everyone gets worn
>RS> down and tired of the discussion. And then everyone writes their code
>RS> adhering to those general guidelines. I have yet to work on a commercial
>RS> project where the style guide for coding was dictated to the engineers.
>RS>
>RS> But Kepler (with contributions from SEEK) is not a commercial project.
>RS> So I guess I am at a loss to what its true priorities should be. My
>RS> priorities from the beginning have always been to create something that
>RS> people will actually use. To reach that goal I want to be as productive
>RS> as possible.
>RS>
>RS> In my personal opinion the Ptolemy style guide is quite unique and so
>RS> completely different than any other style guide I have used, that I find
>RS> it cramping my style (pun intended). So I did what I did for the sake of
>RS> getting my work done in a timely manner. (I could argue that because I
>RS> used a style guide that is more comfortable to myself, the quality of my
>RS> code is higher than if I struggled to "think" about my code as others
>RS> "think" about their code)
>RS>
>RS> I stand by what I said earlier about a general style guide with module
>RS> ownership and adapting to the style of the owner. It just seems odd that
>RS> I need to adapt to Ptolemy's style guide (which is basically what
>RS> Kepler's style guide is) and I doubt I will ever change a line of
>RS> Ptolemy code. Of course if I did, I would be more than happy to adhere
>RS> to its style completely.
>RS>
>RS> Rod
>RS>
>RS>
>RS> Edward A Lee wrote:
>RS>
>
>
>>>I would not take lightly making exceptions to the coding style...
>>>Do it once, and everyone will feel free to do it, and you will not
>>>have a coding style anymore...
>>>
>>>If you are publishing an academic paper, the editors of the journal
>>>or conference proceedings get to decide on formatting issues. You
>>>may have strong preferences about font, layout, reference styles,
>>>header styles, etc., but you are not given a choice. Should that
>>>be changed? I don't think so...
>>>
>>>Open source software should be viewed as form of publication.
>>>The same principle should apply.
>>>
>>>Edward
>>>
>>>At 01:29 PM 8/12/2004 -0500, Rod Spears wrote:
>>>
>>>
>>>
>>>>I agree that we should have a more "formal" meeting about our Kepler
>>>>coding standards. And I agree that one style does not fit all.
>>>>
>>>>But I still think we need to have some way to distinguish the scope
>>>>of a variable from its prefix. If folks don't like what I have
>>>>proposed then pick something, but it can be rather confusing without
>>>>a prefix (as I have found when reading some of the current code).
>>>>
>>>>As a suggestion consider this:
>>>>On Mozilla we had a general set of guidelines, which most us
>>>>followed, but not everyone unfortunately. Of coarse, we could never
>>>>agree on the curly brace issue, but we did a fairly good job on
>>>>deciding on file names, interface file names, method argues, class
>>>>data member names, and global names.
>>>>
>>>>The other overriding rule (especially because we had the notion of
>>>>module ownership), was that you were to always make attempt to follow
>>>>the coding standard of the files(s) you were working in.
>>>>
>>>>Meaning those who spent a lot of time in their modules had a little
>>>>more flexibility in the style for those files, thus making it easier
>>>>and more natural for those developers. Then, if by chance, you found
>>>>yourself making changes to other people's code, you adapted to their
>>>>style. The obvious idea was that you probably weren't going to be
>>>>doing a lot of editting in other peoples code. Which, as it turns
>>>>out, was pretty much true.
>>>>
>>>>I don't expect to be editting much if any Ptolemy code, etc. And it
>>>>wouldn't make a lot of sense for someone to spend much time in the QB
>>>>trying to fix a bug when I should probably be the fixing it.
>>>>
>>>>I think there is an economies of scale thing in here somewhere ;-)
>>>>
>>>>(Besides, outside of variable naming conventions, a lot of code can
>>>>be reformatted with Eclipse or other tools)
>>>>
>>>>Rod
>>>>
>>>>
>>>>Edward A Lee wrote:
>>>>
>>>>
>>>>
>>>>>At 11:17 AM 8/12/2004 -0500, Rod Spears wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Also, there seems to be some varying feelings and opinions about
>>>>>>the coding style for Kepler. My approach which I am sure differs
>>>>>>from Kepler is as follows:
>>>>>>
>>>>>>1) All method arguments start with a lowercase "a"
>>>>>>2) All class data members all start with "m" (unless they are final)
>>>>>>3) All local variables have no prefix.
>>>>>>
>>>>>>It is my belief that you should always be able to look at a
>>>>>>variable in the code and understand it's scope. I disagree with the
>>>>>>approach where both the method arguments and the local variables
>>>>>>have no prefix and are often distinguished by a "this.", which is
>>>>>>rather verbose at times.
>>>>>>
>>>>>>
>>>>>While I think these are valid points,
>>>>>I would like to make a case for following the coding style anyway...
>>>>>
>>>>>There is no coding style that will appeal to everyone (I guarantee it).
>>>>>The benefits of having a uniform coding style, however, far outweigh
>>>>>_any_ benefits you might derive from any particular coding style.
>>>>>
>>>>>So, I would suggest that the discussion needs to be:
>>>>>
>>>>>1) What changes should be made to the uniform coding style?
>>>>>2) Who's going to do the work to convert the existing code base
>>>>>to conform with any changes in the coding style?
>>>>>
>>>>>Number 2 suggests that changes had better have pretty compelling
>>>>>reasons... I don't find the above reasons compelling enough...
>>>>>(nor are they consistent: What if I name a local variable "model"?
>>>>>Is it a class data member?).
>>>>>
>>>>>I think the concerns addressed by this proposal are adequately
>>>>>addressed by keeping methods short and by choosing readable
>>>>>names for variables that a compositions of full words and clearly
>>>>>define the role of the variable.
>>>>>
>>>>>Edward
>>>>>
>>>>>
>>>>>
>>>>>------------
>>>>>Edward A. Lee, Professor
>>>>>518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>>>>>phone: 510-642-0455, fax: 510-642-2739
>>>>><mailto:eal at eecs.Berkeley.EDU>eal at eecs.Berkeley.EDU,
>>>>>http://ptolemy.eecs.berkeley.edu/~eal
>>>>>
>>>>>
>>>>
>>>>--
>>>>Rod Spears
>>>>Biodiversity Research Center
>>>>University of Kansas
>>>>1345 Jayhawk Boulevard
>>>>Lawrence, KS 66045, USA
>>>>Tel: 785 864-4082, Fax: 785 864-5335
>>>>
>>>>
>>>------------
>>>Edward A. Lee, Professor
>>>518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>>>phone: 510-642-0455, fax: 510-642-2739
>>>eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>>>
>>>
>>>
>RS>
>RS>
>RS> --
>RS> Rod Spears
>RS> Biodiversity Research Center
>RS> University of Kansas
>RS> 1345 Jayhawk Boulevard
>RS> Lawrence, KS 66045, USA
>RS> Tel: 785 864-4082, Fax: 785 864-5335
>RS>
>RS> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>RS> <html>
>RS> <head>
>RS> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
>RS> <title></title>
>RS> </head>
>RS> <body bgcolor="#ffffff" text="#000000">
>RS> Sorry, I completely disagree. Writing software is certainly not the
>RS> same as publishing academic papers, and I think it is a fascinating
>RS> thought that Open Source could/should be considered a published work
>RS> (sounds like a discussion for another day).<br>
>RS> <br>
>RS> The reality of Open Source software is that if you put a lot of rules
>RS> in place you begin to limit the contributions, and that can be both
>RS> good and bad. There is certainly a desired level of quality and
>RS> certainly rules enforce that etc. etc. It was always a very difficult
>RS> line to walk; that is, to encourage contributions and then figure out
>RS> "how" to accept good work that may not fit exactly into the place it
>RS> needs to fit.<br>
>RS> <br>
>RS> For example on Mozilla, the lack of every single file, module and/or
>RS> line of code looking exactly the same was never a problem for anyone
>RS> contributing to the project (I can't say it hurt productivity or the
>RS> quality of the code).<br>
>RS> <br>
>RS> This discussion and it is one I have had over and over, reminds me of
>RS> the great commercial software dilemma: Would a software engineer rather
>RS> write:<br>
>RS> 1) A perfectly engineered piece of software with no bugs, that doesn't
>RS> sell a dime.<br>
>RS> 2) A rather odd piece of software with some questionable design and
>RS> architectural decisions that sells millions of copies.<br>
>RS> <br>
>RS> Certainly when writing commercial code, productivity ranks up there
>RS> with quality and all the other important aspects of creating great
>RS> software. I have seen this over and over again at the start of every
>RS> project. The engineers wrangle over coding style for weeks, nobody can
>RS> agree but with the higher levels of a style guide and in the end
>RS> everyone gets worn down and tired of the discussion. And then everyone
>RS> writes their code adhering to those general guidelines. I have yet to
>RS> work on a commercial project where the style guide for coding was
>RS> dictated to the engineers.<br>
>RS> <br>
>RS> But Kepler (with contributions from SEEK) is not a commercial project.
>RS> So I guess I am at a loss to what its true priorities should be. My
>RS> priorities from the beginning have always been to create something that
>RS> people will actually use. To reach that goal I want to be as productive
>RS> as possible. <br>
>RS> <br>
>RS> In my personal opinion the Ptolemy style guide is quite unique and so
>RS> completely different than any other style guide I have used, that I
>RS> find it cramping my style (pun intended). So I did what I did for the
>RS> sake of getting my work done in a timely manner. (I could argue that
>RS> because I used a style guide that is more comfortable to myself, the
>RS> quality of my code is higher than if I struggled to "think" about my
>RS> code as others "think" about their code)<br>
>RS> <br>
>RS> I stand by what I said earlier about a general style guide with module
>RS> ownership and adapting to the style of the owner. It just seems odd
>RS> that I need to adapt to Ptolemy's style guide (which is basically what
>RS> Kepler's style guide is) and I doubt I will ever change a line of
>RS> Ptolemy code. Of course if I did, I would be more than happy to adhere
>RS> to its style completely.<br>
>RS> <br>
>RS> Rod<br>
>RS> <br>
>RS> <br>
>RS> Edward A Lee wrote:<br>
>RS> <blockquote
>RS> cite="mid5.1.0.14.2.20040813044645.0284aaa8 at mho.eecs.berkeley.edu"
>RS> type="cite"><br>
>RS> I would not take lightly making exceptions to the coding style...
>RS> <br>
>RS> Do it once, and everyone will feel free to do it, and you will not
>RS> <br>
>RS> have a coding style anymore...
>RS> <br>
>RS> <br>
>RS> If you are publishing an academic paper, the editors of the journal
>RS> <br>
>RS> or conference proceedings get to decide on formatting issues. You
>RS> <br>
>RS> may have strong preferences about font, layout, reference styles,
>RS> <br>
>RS> header styles, etc., but you are not given a choice. Should that
>RS> <br>
>RS> be changed? I don't think so...
>RS> <br>
>RS> <br>
>RS> Open source software should be viewed as form of publication.
>RS> <br>
>RS> The same principle should apply.
>RS> <br>
>RS> <br>
>RS> Edward
>RS> <br>
>RS> <br>
>RS> At 01:29 PM 8/12/2004 -0500, Rod Spears wrote:
>RS> <br>
>RS> <blockquote type="cite">I agree that we should have a more "formal"
>RS> meeting about our Kepler coding standards. And I agree that one style
>RS> does not fit all.
>RS> <br>
>RS> <br>
>RS> But I still think we need to have some way to distinguish the scope of
>RS> a variable from its prefix. If folks don't like what I have proposed
>RS> then pick something, but it can be rather confusing without a prefix
>RS> (as I have found when reading some of the current code).
>RS> <br>
>RS> <br>
>RS> As a suggestion consider this:
>RS> <br>
>RS> On Mozilla we had a general set of guidelines, which most us followed,
>RS> but not everyone unfortunately. Of coarse, we could never agree on the
>RS> curly brace issue, but we did a fairly good job on deciding on file
>RS> names, interface file names, method argues, class data member names,
>RS> and global names.
>RS> <br>
>RS> <br>
>RS> The other overriding rule (especially because we had the notion of
>RS> module ownership), was that you were to always make attempt to follow
>RS> the coding standard of the files(s) you were working in.
>RS> <br>
>RS> <br>
>RS> Meaning those who spent a lot of time in their modules had a little
>RS> more flexibility in the style for those files, thus making it easier
>RS> and more natural for those developers. Then, if by chance, you found
>RS> yourself making changes to other people's code, you adapted to their
>RS> style. The obvious idea was that you probably weren't going to be doing
>RS> a lot of editting in other peoples code. Which, as it turns out, was
>RS> pretty much true.
>RS> <br>
>RS> <br>
>RS> I don't expect to be editting much if any Ptolemy code, etc. And it
>RS> wouldn't make a lot of sense for someone to spend much time in the QB
>RS> trying to fix a bug when I should probably be the fixing it.
>RS> <br>
>RS> <br>
>RS> I think there is an economies of scale thing in here somewhere ;-)
>RS> <br>
>RS> <br>
>RS> (Besides, outside of variable naming conventions, a lot of code can be
>RS> reformatted with Eclipse or other tools)
>RS> <br>
>RS> <br>
>RS> Rod
>RS> <br>
>RS> <br>
>RS> <br>
>RS> Edward A Lee wrote:
>RS> <br>
>RS> <blockquote type="cite">At 11:17 AM 8/12/2004 -0500, Rod Spears
>RS> wrote:
>RS> <br>
>RS> <blockquote type="cite">Also, there seems to be some varying
>RS> feelings and opinions about the coding style for Kepler. My approach
>RS> which I am sure differs from Kepler is as follows:
>RS> <br>
>RS> <br>
>RS> 1) All method arguments start with a lowercase "a"
>RS> <br>
>RS> 2) All class data members all start with "m" (unless they are final)
>RS> <br>
>RS> 3) All local variables have no prefix.
>RS> <br>
>RS> <br>
>RS> It is my belief that you should always be able to look at a variable in
>RS> the code and understand it's scope. I disagree with the approach where
>RS> both the method arguments and the local variables have no prefix and
>RS> are often distinguished by a "this.", which is rather verbose at times.
>RS> <br>
>RS> </blockquote>
>RS> <br>
>RS> While I think these are valid points,
>RS> <br>
>RS> I would like to make a case for following the coding style anyway...
>RS> <br>
>RS> <br>
>RS> There is no coding style that will appeal to everyone (I guarantee it).
>RS> <br>
>RS> The benefits of having a uniform coding style, however, far outweigh
>RS> <br>
>RS> _any_ benefits you might derive from any particular coding style.
>RS> <br>
>RS> <br>
>RS> So, I would suggest that the discussion needs to be:
>RS> <br>
>RS> <br>
>RS> 1) What changes should be made to the uniform coding style?
>RS> <br>
>RS> 2) Who's going to do the work to convert the existing code base
>RS> <br>
>RS> to conform with any changes in the coding style?
>RS> <br>
>RS> <br>
>RS> Number 2 suggests that changes had better have pretty compelling
>RS> <br>
>RS> reasons... I don't find the above reasons compelling enough...
>RS> <br>
>RS> (nor are they consistent: What if I name a local variable "model"?
>RS> <br>
>RS> Is it a class data member?).
>RS> <br>
>RS> <br>
>RS> I think the concerns addressed by this proposal are adequately
>RS> <br>
>RS> addressed by keeping methods short and by choosing readable
>RS> <br>
>RS> names for variables that a compositions of full words and clearly
>RS> <br>
>RS> define the role of the variable.
>RS> <br>
>RS> <br>
>RS> Edward
>RS> <br>
>RS> <br>
>RS> <br>
>RS> <br>
>RS> ------------
>RS> <br>
>RS> Edward A. Lee, Professor
>RS> <br>
>RS> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>RS> <br>
>RS> phone: 510-642-0455, fax: 510-642-2739
>RS> <br>
>RS> <a class="moz-txt-link-rfc2396E" href="mailto:eal at eecs.Berkeley.EDU"><mailto:eal at eecs.Berkeley.EDU></a><a class="moz-txt-link-abbreviated" href="mailto:eal at eecs.Berkeley.EDU">eal at eecs.Berkeley.EDU</a>,
>RS> <a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/~eal">http://ptolemy.eecs.berkeley.edu/~eal</a>
>RS> <br>
>RS> </blockquote>
>RS> <br>
>RS> <br>
>RS> --
>RS> <br>
>RS> Rod Spears
>RS> <br>
>RS> Biodiversity Research Center
>RS> <br>
>RS> University of Kansas
>RS> <br>
>RS> 1345 Jayhawk Boulevard
>RS> <br>
>RS> Lawrence, KS 66045, USA
>RS> <br>
>RS> Tel: 785 864-4082, Fax: 785 864-5335
>RS> <br>
>RS> </blockquote>
>RS> <br>
>RS> ------------
>RS> <br>
>RS> Edward A. Lee, Professor
>RS> <br>
>RS> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>RS> <br>
>RS> phone: 510-642-0455, fax: 510-642-2739
>RS> <br>
>RS> <a class="moz-txt-link-abbreviated" href="mailto:eal at eecs.Berkeley.EDU">eal at eecs.Berkeley.EDU</a>, <a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/~eal">http://ptolemy.eecs.berkeley.edu/~eal</a>
>RS> <br>
>RS> <br>
>RS> </blockquote>
>RS> <br>
>RS> <br>
>RS> <div class="moz-signature">-- <br>
>RS> <table>
>RS> <tbody>
>RS> <tr>
>RS> <td
>RS> style="border: 1px solid gray; font-size: 8pt; font-family: arial,sans-serif;">Rod
>RS> Spears<br>
>RS> Biodiversity Research Center<br>
>RS> University of Kansas<br>
>RS> 1345 Jayhawk Boulevard<br>
>RS> Lawrence, KS 66045, USA<br>
>RS> Tel: 785 864-4082, Fax: 785 864-5335<br>
>RS> </td>
>RS> </tr>
>RS> </tbody>
>RS> </table>
>RS> </div>
>RS> </body>
>RS> </html>
>
>
--
Rod Spears
Biodiversity Research Center
University of Kansas
1345 Jayhawk Boulevard
Lawrence, KS 66045, USA
Tel: 785 864-4082, Fax: 785 864-5335
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20040816/ab1fe40e/attachment.htm
More information about the Kepler-dev
mailing list