- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Scaladoc that is actually useful?
Mon, 2009-11-16, 19:27
#52
Re: Re: Scaladoc that is actually useful?
On Mon, Nov 16, 2009 at 11:44 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:
There is a whole class of routines that can be implemented by the JVM and are mathematically functions and terminate and so on, but which cannot be constructed using traditional type theory. So, for example, a function that tried to cast to the algebraic type T in Greg's example, and did convolution when it succeeded, and composition when it failed, would completely obey the type signature.
I've given examples of these things (which have also been ignored once I fixed the syntax errors, for no apparent reason).
If you restrict yourself to constructive type theory alone, and you do not concern yourself with issues like time to compute or memory taken, then it appears to me to be true that there exists a unique function with the type (A => B) => (B => C) => A => C.
Otherwise, if you do *not* restrict yourself to constructive type theory, but instead insist that *functions must take any object that matches their input types and always return something of the output type*, or you *care about the run-time performance of your code*, there are piles of counterexamples. Greg gave one on the performance/memory side. I'll give another:
def compose[A,B,C](f: A => B, g: B => C): A => C = { (a:A) => (g(f(a))) }
def shortcut[A,B,C](f: A => B, g: B => C): A => C = {
(a:A) => {
try { g( a.asInstanceOf[B] ) }
catch{ case _:ClassCastException => g(f(a)) }
}
}
val f: (String => Double) = (s:String) => (Math.sqrt(s.length.toDouble))
val g: (Double => Boolean) = (d:Double) => (d<2.0)
val h: (Double => Double) = (d:Double) => (-d)
println( compose(f,g)("Hi") + " versus " + shortcut(f,g)("Hi") )
println( compose(h,g)(2.5) + " versus " + shortcut(h,g)(2.5) )
In "shortcut" we don't bother using f if g already has the right type signature (i.e. f does not change the type, or we can coerce the type with asInstanceOf). (One could make this even more powerful in a VM without erasure, also.) Anyway, there are infinitely many other ways one could try to invent a b to pass to g, and as long as you catch the mistakes and resort to g(f(a)) when all else fails, the return will be in the set described by the type.
This suggests to me that you _at the very least_ need a "this function is consistent with constructive type theory" as a comment if, in fact, it is. And something more transparent, such as "generates the composite function g(f(_))" would be even better.
--Rex
Hi Meredith,
Moved to scala-debate.
Am I correct that there is only one *function* that inhabits that
signature? There may be many procedures that you can perform, but
looking at the input types and return type, and assuming there's no
null, is there another function that the procedure could compute?
There is a whole class of routines that can be implemented by the JVM and are mathematically functions and terminate and so on, but which cannot be constructed using traditional type theory. So, for example, a function that tried to cast to the algebraic type T in Greg's example, and did convolution when it succeeded, and composition when it failed, would completely obey the type signature.
I've given examples of these things (which have also been ignored once I fixed the syntax errors, for no apparent reason).
If you restrict yourself to constructive type theory alone, and you do not concern yourself with issues like time to compute or memory taken, then it appears to me to be true that there exists a unique function with the type (A => B) => (B => C) => A => C.
Otherwise, if you do *not* restrict yourself to constructive type theory, but instead insist that *functions must take any object that matches their input types and always return something of the output type*, or you *care about the run-time performance of your code*, there are piles of counterexamples. Greg gave one on the performance/memory side. I'll give another:
def compose[A,B,C](f: A => B, g: B => C): A => C = { (a:A) => (g(f(a))) }
def shortcut[A,B,C](f: A => B, g: B => C): A => C = {
(a:A) => {
try { g( a.asInstanceOf[B] ) }
catch{ case _:ClassCastException => g(f(a)) }
}
}
val f: (String => Double) = (s:String) => (Math.sqrt(s.length.toDouble))
val g: (Double => Boolean) = (d:Double) => (d<2.0)
val h: (Double => Double) = (d:Double) => (-d)
println( compose(f,g)("Hi") + " versus " + shortcut(f,g)("Hi") )
println( compose(h,g)(2.5) + " versus " + shortcut(h,g)(2.5) )
In "shortcut" we don't bother using f if g already has the right type signature (i.e. f does not change the type, or we can coerce the type with asInstanceOf). (One could make this even more powerful in a VM without erasure, also.) Anyway, there are infinitely many other ways one could try to invent a b to pass to g, and as long as you catch the mistakes and resort to g(f(a)) when all else fails, the return will be in the set described by the type.
This suggests to me that you _at the very least_ need a "this function is consistent with constructive type theory" as a comment if, in fact, it is. And something more transparent, such as "generates the composite function g(f(_))" would be even better.
--Rex
Mon, 2009-11-16, 19:27
#53
Re: Scaladoc that is actually useful?
Meredith Gregory writes:
>
>
> Dear Ricky,Are you saying that you take as your definition of a function a
mathematical relation? So, for you the product space, A x B is the same as the
function space A =>B? Here's a relation { (a, 1), (a, 2) }. Is this a function
in your view?Best wishes,--greg
> On Mon, Nov 16, 2009 at 9:25 AM, Ricky Clarkson
wrote:"(mathematics) a
mathematical relation such that each element of a
> given set (the domain of the function) is associated with an element
> of another"
Meredith,
Just dropped in to point out that while function implies mathematical relation,
mathematical relation does not imply function.
A circle is a conic section with an eccentricity of 0. Am I saying that my
definition of a circle is a conic section? A hyperbola is a conic section. Am I
saying that a hyperbola is a circle?
Runar
Mon, 2009-11-16, 19:47
#54
Re: Re: Scaladoc that is actually useful?
Dear Rex,
Interesting examples!
For me one of the positive things that came out of the debate was thinking about the possibility of a shift in basis in terms of the representation of function. The "silly" example i gave before has a more serious counterpart if we think about different internal representations of function. For example, we can use a SECD-style representation or even further out we could imagine a representation of function that followed this chain of encodings
This is not just a theoretical construct, but might have practical benefit for someone like Ian Clarke who is looking at different ways to organize mobile computation but wants to restrict the programming model to just functions instead of processes.
There are lots of different possible internal representations, but the reason i mention these two is that the representation of composition is pretty different and has really different complexity characteristics. Specifically, composition in the Sangiorgi-style encoding of the lambda calculus turns into a parallel composition that might be subject to blocking input (again, think about the Internet as your computer).
So, the question i've be mulling over is whether we can associate measures to a change of basis (read change of internal representation of function) that we could observe in an effect system.
Best wishes,
--greg
On Mon, Nov 16, 2009 at 10:07 AM, Rex Kerr <ichoran@gmail.com> wrote:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
Interesting examples!
For me one of the positive things that came out of the debate was thinking about the possibility of a shift in basis in terms of the representation of function. The "silly" example i gave before has a more serious counterpart if we think about different internal representations of function. For example, we can use a SECD-style representation or even further out we could imagine a representation of function that followed this chain of encodings
- core representation of π-calculus processes, call it Core-π
- Sangiorgi-style encoding of lambda calculus into π-calculus by factoring through a higher order π-calculus, call it HOπ, and then compiling higher order π-terms to ordinary π-calculus terms
This is not just a theoretical construct, but might have practical benefit for someone like Ian Clarke who is looking at different ways to organize mobile computation but wants to restrict the programming model to just functions instead of processes.
There are lots of different possible internal representations, but the reason i mention these two is that the representation of composition is pretty different and has really different complexity characteristics. Specifically, composition in the Sangiorgi-style encoding of the lambda calculus turns into a parallel composition that might be subject to blocking input (again, think about the Internet as your computer).
So, the question i've be mulling over is whether we can associate measures to a change of basis (read change of internal representation of function) that we could observe in an effect system.
Best wishes,
--greg
On Mon, Nov 16, 2009 at 10:07 AM, Rex Kerr <ichoran@gmail.com> wrote:
On Mon, Nov 16, 2009 at 11:44 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:Hi Meredith,
Moved to scala-debate.
Am I correct that there is only one *function* that inhabits that
signature? There may be many procedures that you can perform, but
looking at the input types and return type, and assuming there's no
null, is there another function that the procedure could compute?
There is a whole class of routines that can be implemented by the JVM and are mathematically functions and terminate and so on, but which cannot be constructed using traditional type theory. So, for example, a function that tried to cast to the algebraic type T in Greg's example, and did convolution when it succeeded, and composition when it failed, would completely obey the type signature.
I've given examples of these things (which have also been ignored once I fixed the syntax errors, for no apparent reason).
If you restrict yourself to constructive type theory alone, and you do not concern yourself with issues like time to compute or memory taken, then it appears to me to be true that there exists a unique function with the type (A => B) => (B => C) => A => C.
Otherwise, if you do *not* restrict yourself to constructive type theory, but instead insist that *functions must take any object that matches their input types and always return something of the output type*, or you *care about the run-time performance of your code*, there are piles of counterexamples. Greg gave one on the performance/memory side. I'll give another:
def compose[A,B,C](f: A => B, g: B => C): A => C = { (a:A) => (g(f(a))) }
def shortcut[A,B,C](f: A => B, g: B => C): A => C = {
(a:A) => {
try { g( a.asInstanceOf[B] ) }
catch{ case _:ClassCastException => g(f(a)) }
}
}
val f: (String => Double) = (s:String) => (Math.sqrt(s.length.toDouble))
val g: (Double => Boolean) = (d:Double) => (d<2.0)
val h: (Double => Double) = (d:Double) => (-d)
println( compose(f,g)("Hi") + " versus " + shortcut(f,g)("Hi") )
println( compose(h,g)(2.5) + " versus " + shortcut(h,g)(2.5) )
In "shortcut" we don't bother using f if g already has the right type signature (i.e. f does not change the type, or we can coerce the type with asInstanceOf). (One could make this even more powerful in a VM without erasure, also.) Anyway, there are infinitely many other ways one could try to invent a b to pass to g, and as long as you catch the mistakes and resort to g(f(a)) when all else fails, the return will be in the set described by the type.
This suggests to me that you _at the very least_ need a "this function is consistent with constructive type theory" as a comment if, in fact, it is. And something more transparent, such as "generates the composite function g(f(_))" would be even better.
--Rex
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
Mon, 2009-11-16, 19:47
#55
Re: Re: Scaladoc that is actually useful?
Dear Runar,
Agreed! That's one of the very things i was hoping to get Ricky to clarify. i couldn't tell from his note if he was saying that he took as function a relation or a relation in which there are no pairs of pairs of the form (a,b), (a,c). That leaves aside questions about computability and the relationship of computability to observation and typing. There are lots and lots of sets of pairs with this property that have no representation in a computer. Are we to take these as functions? How are they related to types? How are they related to observations? How are these notions related to what we, as mere programmers who are simply trying to earn a living and write quality code, should and should not write in documentation?
Best wishes,
--greg
On Mon, Nov 16, 2009 at 10:22 AM, Runar Bjarnason <runarorama@gmail.com> wrote:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
Agreed! That's one of the very things i was hoping to get Ricky to clarify. i couldn't tell from his note if he was saying that he took as function a relation or a relation in which there are no pairs of pairs of the form (a,b), (a,c). That leaves aside questions about computability and the relationship of computability to observation and typing. There are lots and lots of sets of pairs with this property that have no representation in a computer. Are we to take these as functions? How are they related to types? How are they related to observations? How are these notions related to what we, as mere programmers who are simply trying to earn a living and write quality code, should and should not write in documentation?
Best wishes,
--greg
On Mon, Nov 16, 2009 at 10:22 AM, Runar Bjarnason <runarorama@gmail.com> wrote:
Meredith Gregory <lgreg.meredith@...> writes:
>
>
> Dear Ricky,Are you saying that you take as your definition of a function a
mathematical relation? So, for you the product space, A x B is the same as the
function space A =>B? Here's a relation { (a, 1), (a, 2) }. Is this a function
in your view?Best wishes,--greg
> On Mon, Nov 16, 2009 at 9:25 AM, Ricky Clarkson
<ricky.clarkson@gmail.com> wrote:"(mathematics) a
mathematical relation such that each element of a
> given set (the domain of the function) is associated with an element
> of another"
Meredith,
Just dropped in to point out that while function implies mathematical relation,
mathematical relation does not imply function.
A circle is a conic section with an eccentricity of 0. Am I saying that my
definition of a circle is a conic section? A hyperbola is a conic section. Am I
saying that a hyperbola is a circle?
Runar
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
Mon, 2009-11-16, 21:57
#56
Re: Re: Scaladoc that is actually useful?
They are not observably distinguishable under extensional equivalence.
Can you imagine if I'd said that up front? Yeah I'd be the "theorist"
from that "faction", which is rather ignorant given the facts, but I
digress. This is the kind of balance I must maintain with the few who
like learning, the few from whom I'd be preaching to the choir and the
many who resent learning from the Scala community. Perhaps it's an error
to start where I did or perhaps it's an error to even attempt it on the
mailing list. I didn't expect such blatant dishonesty, poor
comprehension and failure to understand such a basic fact, which is very
well documented (I won't bother posting the proof or the paper --
because none of you read it right?).
I haven't even proposed an argument, merely stated an absolute,
provable, proven, falsifiable, unfalsified, absolute, undeniable,
you-look-like-holocaust-deniers,
yes-evolution-is-supported-by-a-mountain-of-evidence fact that has been
misrepresented repeatedly. I'm flabbergasted that so many programmers
cannot grasp this, but on the other hand, I'm not really. But I am even
more flabbergasted that it came from you Greg.
I know a lot of you care about how you to appear to others (I don't give
a flying fish -- I'm more interested in reality), so I might inform you
that there are lots of people laughing at the ignorance of a basic fact
by the Scala community right now. They have far less sympathy than I do
Tue, 2009-11-17, 00:07
#57
Re: Re: Scaladoc that is actually useful?
Dear Tony,
If i put words in your mouth, then i humbly apologize. i thought you were saying something about only needing the type signatures as documentation. My first note said i found the position troubling and thought you would correct it. i guess the thread spun out of control. Anyway, we are in agreement.
As for avoiding technical language -- you know where i stand. i use it when i feel it
Best wishes,
--greg
On Mon, Nov 16, 2009 at 12:50 PM, Tony Morris <tonymorris@gmail.com> wrote:
If i put words in your mouth, then i humbly apologize. i thought you were saying something about only needing the type signatures as documentation. My first note said i found the position troubling and thought you would correct it. i guess the thread spun out of control. Anyway, we are in agreement.
As for avoiding technical language -- you know where i stand. i use it when i feel it
- clarifies a point that must be clarified
- provides a portal to someone who wants a way in
Best wishes,
--greg
On Mon, Nov 16, 2009 at 12:50 PM, Tony Morris <tonymorris@gmail.com> wrote:
They are not observably distinguishable under extensional equivalence.
Can you imagine if I'd said that up front? Yeah I'd be the "theorist"
from that "faction", which is rather ignorant given the facts, but I
digress. This is the kind of balance I must maintain with the few who
like learning, the few from whom I'd be preaching to the choir and the
many who resent learning from the Scala community. Perhaps it's an error
to start where I did or perhaps it's an error to even attempt it on the
mailing list. I didn't expect such blatant dishonesty, poor
comprehension and failure to understand such a basic fact, which is very
well documented (I won't bother posting the proof or the paper --
because none of you read it right?).
I haven't even proposed an argument, merely stated an absolute,
provable, proven, falsifiable, unfalsified, absolute, undeniable,
you-look-like-holocaust-deniers,
yes-evolution-is-supported-by-a-mountain-of-evidence fact that has been
misrepresented repeatedly. I'm flabbergasted that so many programmers
cannot grasp this, but on the other hand, I'm not really. But I am even
more flabbergasted that it came from you Greg.
I know a lot of you care about how you to appear to others (I don't give
a flying fish -- I'm more interested in reality), so I might inform you
that there are lots of people laughing at the ignorance of a basic fact
by the Scala community right now. They have far less sympathy than I do
Tue, 2009-11-17, 09:47
#58
RE: Re: Scaladoc that is actually useful?
Tony -
You have taken this way too far. The contents of your last email are pretty disgraceful.
May I remind you that the original poster on the thread made a point about the general lack of documentation in scala. You responded with an obscure point about *one single function's type signature*, did not clarify that you were only talking about that one function and neither did it clarify that you were talking about it in the purely functional sense, as opposed to the scala method sense.
Your response as you intended it was hence almost completely irrelevant to the original question - as you did not clarify your terms, plenty misunderstood what you were saying. It has taken others to come to this thread to educate as by that stage you had degenerated into passive-aggressive abuse.
Chris
> Date: Tue, 17 Nov 2009 06:50:39 +1000
> From: tonymorris@gmail.com
> To: lgreg.meredith@gmail.com
> CC: ricky.clarkson@gmail.com; dmclean62@gmail.com; scala-user@listes.epfl.ch
> Subject: Re: [scala-user] Re: Scaladoc that is actually useful?
>
> They are not observably distinguishable under extensional equivalence.
> Can you imagine if I'd said that up front? Yeah I'd be the "theorist"
> from that "faction", which is rather ignorant given the facts, but I
> digress. This is the kind of balance I must maintain with the few who
> like learning, the few from whom I'd be preaching to the choir and the
> many who resent learning from the Scala community. Perhaps it's an error
> to start where I did or perhaps it's an error to even attempt it on the
> mailing list. I didn't expect such blatant dishonesty, poor
> comprehension and failure to understand such a basic fact, which is very
> well documented (I won't bother posting the proof or the paper --
> because none of you read it right?).
>
> I haven't even proposed an argument, merely stated an absolute,
> provable, proven, falsifiable, unfalsified, absolute, undeniable,
> you-look-like-holocaust-deniers,
> yes-evolution-is-supported-by-a-mountain-of-evidence fact that has been
> misrepresented repeatedly. I'm flabbergasted that so many programmers
> cannot grasp this, but on the other hand, I'm not really. But I am even
> more flabbergasted that it came from you Greg.
>
> I know a lot of you care about how you to appear to others (I don't give
> a flying fish -- I'm more interested in reality), so I might inform you
> that there are lots of people laughing at the ignorance of a basic fact
> by the Scala community right now. They have far less sympathy than I do
> -- I'm not laughing.
>
> Meredith Gregory wrote:
> > Dear Ricky,
> >
> > i have responded to this argument repeatedly. i'm not sure why people
> > are not getting this. Tony's argument is blatantly false. There are
> > countably infinitely many inhabitants of the type (A => B) => (B => C)
> > => A => C. They are observably distinguished by running time and space
> > consumption. Here is one infinite subset of that set: for each k in
> > the natural numbers we have
> >
> > Compose_k( f, g ) = { ( x ) => { var d = computeKthDigitOfPi( k ); g(
> > f( x ) ) } : (A => B) => (B => C) => A => C
> >
> > There are lots more infinite subsets where that one came from. The
> > differences in complexity are not just manifest by silliness of the
> > kind above. There are materially relevant differences that have to do
> > with the internal representation of function and evaluation.
> >
> > Beyond that, consider the following function
> >
> > // provided A, B, C <: T with T supporting a certain algebraic structure
> > Convolution_tau( f, g ) = { ( t ) => { integrate( f( t ) * g( tau - t
> > ), posInf, negInf ) } } : (A => B) => (B => C) => A => C
> >
> > For the subset of types supporting a certain algebraic structure --
> > i.e. we restrict the universe of quantification in the original
> > theorem -- this is a useful example of a way of getting functions from
> > pairs of functions that is not a composition. Convolution is a useful
> > notion that arises in physical sciences as well as in computation.
> >
> > The important point in all of this is that Scala's type system doesn't
> > see certain aspects of computation that are still materially relevant
> > to working programmers. The stuff that falls into this category can
> > make practically useful documentation.
> >
> > Best wishes,
> >
> > --greg
> >
> > On Mon, Nov 16, 2009 at 6:53 AM, Ricky Clarkson
> > <ricky.clarkson@gmail.com <mailto:ricky.clarkson@gmail.com>> wrote:
> >
> > I put it to you that my wife, who has never[1] programmed in her life,
> > will be able to tell what the signature we have been discussing means.
> > She might need it rephrasing, as she's not familiar with Scala's
> > syntax. Here's how I might rephrase it:
> >
> > There's a converter called f. It takes in a value of type A, and
> > returns a value of type B.
> > There's a converter called g. It takes in a value of type B, and
> > returns a value of type C.
> >
> > If I have f and g, and a value of type A, how would I get a value
> > of type C?
> >
> > We might draw boxes on paper too, I don't know yet.
> >
> > I don't mind pandering to morons, to use your terms, not least as I am
> > one in many contexts. I'm not dismissing anyone. I see no harm in
> > documenting signatures, even obvious ones, but I don't see it as
> > necessary. It's ok to me if Scala cannot be used in organisations
> > that place so much emphasis on documenting obvious things, rather than
> > having their staff understand fundamental concepts. Note that I'm not
> > even a committer though, and neither is Tony, to my knowledge. If
> > you're unhappy with the documentation, I've never heard of a
> > documentation-adding patch being rejected.
> >
> > [1] I got her doing a little bit of Scheme a couple of years ago, just
> > to keep her awake in a boring job. She picked Ruby after I showed her
> > code snippets from 13 languages, so she'll be learning that (as will
> > I) soon.
> >
> > 2009/11/16 Donald McLean <dmclean62@gmail.com
> > <mailto:dmclean62@gmail.com>>:
> > > While there seems to be a strong "let us not pander to the morons"
> > > faction, please keep in mind that many of the people that you are so
> > > casually dismissing do have real power to prevent the adoption of
> > > Scala in their organizations. Failure to provide Scaladoc that is
> > > genuinely useful to people like me who are reasonably bright and
> > > competent developers but not strong theorists is a potentially fatal
> > > mistake. The Scala community will not, in many cases, get a second
> > > chance to prove that their product is NOT a toy dreamed up by
> > > insufferable academic elitists.
> > >
> > > On Mon, Nov 16, 2009 at 8:27 AM, Ricky Clarkson
> > > <ricky.clarkson@gmail.com <mailto:ricky.clarkson@gmail.com>> wrote:
> > >>> I agree with you, Andrew, and disagree with Tony, in that English
> > >>> documentation must be associated with the signature above to
> > describe the
> > >>> semantics of the function. If one has a mathematical
> > inclination then
> > >>> perhaps some sort of formal specification language could be
> > used (Z?).
> > >>> However the interface needed by the compiler is not sufficient
> > to describe
> > >>> the function's (possibly complex and non-obvious) internal
> > operation.
> > >>
> > >> Where possible, the function should be simple and obvious, and
> > types
> > >> should be sufficient to describe it. As I said in another post, I
> > >> agree with Tony, except that a good English description is required
> > >> wherever one departs from the simple, obvious implementation.
> > > --
> > > Family photographs are a critical legacy for
> > > ourselves and our descendants. Protect that
> > > legacy with a digital backup and recovery plan.
> > >
> > > Join the photo preservation advocacy Facebook group:
> > >
> > http://www.facebook.com/home.php?ref=logo#/group.php?gid=148274709288
> > >
> >
> >
> >
> > --
> > Ricky Clarkson
> > Java and Scala Programmer, AD Holdings
> > +44 1565 770804
> > Skype: ricky_clarkson
> > Google Talk: ricky.clarkson@gmail.com
> > <mailto:ricky.clarkson@gmail.com>
> > Google Wave: ricky.clarkson@googlewave.com
> > <mailto:ricky.clarkson@googlewave.com>
> >
> >
> >
> >
> > --
> > L.G. Meredith
> > Managing Partner
> > Biosimilarity LLC
> > 1219 NW 83rd St
> > Seattle, WA 98117
> >
> > +1 206.650.3740
> >
> > http://biosimilarity.blogspot.com
>
> --
> Tony Morris
> http://tmorris.net/
>
>
New! Receive and respond to mail from other email accounts from within Hotmail Find out how.
You have taken this way too far. The contents of your last email are pretty disgraceful.
May I remind you that the original poster on the thread made a point about the general lack of documentation in scala. You responded with an obscure point about *one single function's type signature*, did not clarify that you were only talking about that one function and neither did it clarify that you were talking about it in the purely functional sense, as opposed to the scala method sense.
Your response as you intended it was hence almost completely irrelevant to the original question - as you did not clarify your terms, plenty misunderstood what you were saying. It has taken others to come to this thread to educate as by that stage you had degenerated into passive-aggressive abuse.
Chris
> Date: Tue, 17 Nov 2009 06:50:39 +1000
> From: tonymorris@gmail.com
> To: lgreg.meredith@gmail.com
> CC: ricky.clarkson@gmail.com; dmclean62@gmail.com; scala-user@listes.epfl.ch
> Subject: Re: [scala-user] Re: Scaladoc that is actually useful?
>
> They are not observably distinguishable under extensional equivalence.
> Can you imagine if I'd said that up front? Yeah I'd be the "theorist"
> from that "faction", which is rather ignorant given the facts, but I
> digress. This is the kind of balance I must maintain with the few who
> like learning, the few from whom I'd be preaching to the choir and the
> many who resent learning from the Scala community. Perhaps it's an error
> to start where I did or perhaps it's an error to even attempt it on the
> mailing list. I didn't expect such blatant dishonesty, poor
> comprehension and failure to understand such a basic fact, which is very
> well documented (I won't bother posting the proof or the paper --
> because none of you read it right?).
>
> I haven't even proposed an argument, merely stated an absolute,
> provable, proven, falsifiable, unfalsified, absolute, undeniable,
> you-look-like-holocaust-deniers,
> yes-evolution-is-supported-by-a-mountain-of-evidence fact that has been
> misrepresented repeatedly. I'm flabbergasted that so many programmers
> cannot grasp this, but on the other hand, I'm not really. But I am even
> more flabbergasted that it came from you Greg.
>
> I know a lot of you care about how you to appear to others (I don't give
> a flying fish -- I'm more interested in reality), so I might inform you
> that there are lots of people laughing at the ignorance of a basic fact
> by the Scala community right now. They have far less sympathy than I do
> -- I'm not laughing.
>
> Meredith Gregory wrote:
> > Dear Ricky,
> >
> > i have responded to this argument repeatedly. i'm not sure why people
> > are not getting this. Tony's argument is blatantly false. There are
> > countably infinitely many inhabitants of the type (A => B) => (B => C)
> > => A => C. They are observably distinguished by running time and space
> > consumption. Here is one infinite subset of that set: for each k in
> > the natural numbers we have
> >
> > Compose_k( f, g ) = { ( x ) => { var d = computeKthDigitOfPi( k ); g(
> > f( x ) ) } : (A => B) => (B => C) => A => C
> >
> > There are lots more infinite subsets where that one came from. The
> > differences in complexity are not just manifest by silliness of the
> > kind above. There are materially relevant differences that have to do
> > with the internal representation of function and evaluation.
> >
> > Beyond that, consider the following function
> >
> > // provided A, B, C <: T with T supporting a certain algebraic structure
> > Convolution_tau( f, g ) = { ( t ) => { integrate( f( t ) * g( tau - t
> > ), posInf, negInf ) } } : (A => B) => (B => C) => A => C
> >
> > For the subset of types supporting a certain algebraic structure --
> > i.e. we restrict the universe of quantification in the original
> > theorem -- this is a useful example of a way of getting functions from
> > pairs of functions that is not a composition. Convolution is a useful
> > notion that arises in physical sciences as well as in computation.
> >
> > The important point in all of this is that Scala's type system doesn't
> > see certain aspects of computation that are still materially relevant
> > to working programmers. The stuff that falls into this category can
> > make practically useful documentation.
> >
> > Best wishes,
> >
> > --greg
> >
> > On Mon, Nov 16, 2009 at 6:53 AM, Ricky Clarkson
> > <ricky.clarkson@gmail.com <mailto:ricky.clarkson@gmail.com>> wrote:
> >
> > I put it to you that my wife, who has never[1] programmed in her life,
> > will be able to tell what the signature we have been discussing means.
> > She might need it rephrasing, as she's not familiar with Scala's
> > syntax. Here's how I might rephrase it:
> >
> > There's a converter called f. It takes in a value of type A, and
> > returns a value of type B.
> > There's a converter called g. It takes in a value of type B, and
> > returns a value of type C.
> >
> > If I have f and g, and a value of type A, how would I get a value
> > of type C?
> >
> > We might draw boxes on paper too, I don't know yet.
> >
> > I don't mind pandering to morons, to use your terms, not least as I am
> > one in many contexts. I'm not dismissing anyone. I see no harm in
> > documenting signatures, even obvious ones, but I don't see it as
> > necessary. It's ok to me if Scala cannot be used in organisations
> > that place so much emphasis on documenting obvious things, rather than
> > having their staff understand fundamental concepts. Note that I'm not
> > even a committer though, and neither is Tony, to my knowledge. If
> > you're unhappy with the documentation, I've never heard of a
> > documentation-adding patch being rejected.
> >
> > [1] I got her doing a little bit of Scheme a couple of years ago, just
> > to keep her awake in a boring job. She picked Ruby after I showed her
> > code snippets from 13 languages, so she'll be learning that (as will
> > I) soon.
> >
> > 2009/11/16 Donald McLean <dmclean62@gmail.com
> > <mailto:dmclean62@gmail.com>>:
> > > While there seems to be a strong "let us not pander to the morons"
> > > faction, please keep in mind that many of the people that you are so
> > > casually dismissing do have real power to prevent the adoption of
> > > Scala in their organizations. Failure to provide Scaladoc that is
> > > genuinely useful to people like me who are reasonably bright and
> > > competent developers but not strong theorists is a potentially fatal
> > > mistake. The Scala community will not, in many cases, get a second
> > > chance to prove that their product is NOT a toy dreamed up by
> > > insufferable academic elitists.
> > >
> > > On Mon, Nov 16, 2009 at 8:27 AM, Ricky Clarkson
> > > <ricky.clarkson@gmail.com <mailto:ricky.clarkson@gmail.com>> wrote:
> > >>> I agree with you, Andrew, and disagree with Tony, in that English
> > >>> documentation must be associated with the signature above to
> > describe the
> > >>> semantics of the function. If one has a mathematical
> > inclination then
> > >>> perhaps some sort of formal specification language could be
> > used (Z?).
> > >>> However the interface needed by the compiler is not sufficient
> > to describe
> > >>> the function's (possibly complex and non-obvious) internal
> > operation.
> > >>
> > >> Where possible, the function should be simple and obvious, and
> > types
> > >> should be sufficient to describe it. As I said in another post, I
> > >> agree with Tony, except that a good English description is required
> > >> wherever one departs from the simple, obvious implementation.
> > > --
> > > Family photographs are a critical legacy for
> > > ourselves and our descendants. Protect that
> > > legacy with a digital backup and recovery plan.
> > >
> > > Join the photo preservation advocacy Facebook group:
> > >
> > http://www.facebook.com/home.php?ref=logo#/group.php?gid=148274709288
> > >
> >
> >
> >
> > --
> > Ricky Clarkson
> > Java and Scala Programmer, AD Holdings
> > +44 1565 770804
> > Skype: ricky_clarkson
> > Google Talk: ricky.clarkson@gmail.com
> > <mailto:ricky.clarkson@gmail.com>
> > Google Wave: ricky.clarkson@googlewave.com
> > <mailto:ricky.clarkson@googlewave.com>
> >
> >
> >
> >
> > --
> > L.G. Meredith
> > Managing Partner
> > Biosimilarity LLC
> > 1219 NW 83rd St
> > Seattle, WA 98117
> >
> > +1 206.650.3740
> >
> > http://biosimilarity.blogspot.com
>
> --
> Tony Morris
> http://tmorris.net/
>
>
New! Receive and respond to mail from other email accounts from within Hotmail Find out how.
Tue, 2009-11-17, 09:57
#59
RE: Re: Scaladoc that is actually useful?
Apologies for posting in wrong thread
From: oxbow_lakes@hotmail.com
To: tonymorris@gmail.com; lgreg.meredith@gmail.com
CC: ricky.clarkson@gmail.com; dmclean62@gmail.com; scala-user@listes.epfl.ch
Subject: RE: [scala-user] Re: Scaladoc that is actually useful?
Date: Tue, 17 Nov 2009 08:40:58 +0000
.ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Verdana;} Tony -
You have taken this way too far. The contents of your last email are pretty disgraceful.
May I remind you that the original poster on the thread made a point about the general lack of documentation in scala. You responded with an obscure point about *one single function's type signature*, did not clarify that you were only talking about that one function and neither did it clarify that you were talking about it in the purely functional sense, as opposed to the scala method sense.
Your response as you intended it was hence almost completely irrelevant to the original question - as you did not clarify your terms, plenty misunderstood what you were saying. It has taken others to come to this thread to educate as by that stage you had degenerated into passive-aggressive abuse.
Chris
> Date: Tue, 17 Nov 2009 06:50:39 +1000
> From: tonymorris@gmail.com
> To: lgreg.meredith@gmail.com
> CC: ricky.clarkson@gmail.com; dmclean62@gmail.com; scala-user@listes.epfl.ch
> Subject: Re: [scala-user] Re: Scaladoc that is actually useful?
>
> They are not observably distinguishable under extensional equivalence.
> Can you imagine if I'd said that up front? Yeah I'd be the "theorist"
> from that "faction", which is rather ignorant given the facts, but I
> digress. This is the kind of balance I must maintain with the few who
> like learning, the few from whom I'd be preaching to the choir and the
> many who resent learning from the Scala community. Perhaps it's an error
> to start where I did or perhaps it's an error to even attempt it on the
> mailing list. I didn't expect such blatant dishonesty, poor
> comprehension and failure to understand such a basic fact, which is very
> well documented (I won't bother posting the proof or the paper --
> because none of you read it right?).
>
> I haven't even proposed an argument, merely stated an absolute,
> provable, proven, falsifiable, unfalsified, absolute, undeniable,
> you-look-like-holocaust-deniers,
> yes-evolution-is-supported-by-a-mountain-of-evidence fact that has been
> misrepresented repeatedly. I'm flabbergasted that so many programmers
> cannot grasp this, but on the other hand, I'm not really. But I am even
> more flabbergasted that it came from you Greg.
>
> I know a lot of you care about how you to appear to others (I don't give
> a flying fish -- I'm more interested in reality), so I might inform you
> that there are lots of people laughing at the ignorance of a basic fact
> by the Scala community right now. They have far less sympathy than I do
> -- I'm not laughing.
>
> Meredith Gregory wrote:
> > Dear Ricky,
> >
> > i have responded to this argument repeatedly. i'm not sure why people
> > are not getting this. Tony's argument is blatantly false. There are
> > countably infinitely many inhabitants of the type (A => B) => (B => C)
> > => A => C. They are observably distinguished by running time and space
> > consumption. Here is one infinite subset of that set: for each k in
> > the natural numbers we have
> >
> > Compose_k( f, g ) = { ( x ) => { var d = computeKthDigitOfPi( k ); g(
> > f( x ) ) } : (A => B) => (B => C) => A => C
> >
> > There are lots more infinite subsets where that one came from. The
> > differences in complexity are not just manifest by silliness of the
> > kind above. There are materially relevant differences that have to do
> > with the internal representation of function and evaluation.
> >
> > Beyond that, consider the following function
> >
> > // provided A, B, C <: T with T supporting a certain algebraic structure
> > Convolution_tau( f, g ) = { ( t ) => { integrate( f( t ) * g( tau - t
> > ), posInf, negInf ) } } : (A => B) => (B => C) => A => C
> >
> > For the subset of types supporting a certain algebraic structure --
> > i.e. we restrict the universe of quantification in the original
> > theorem -- this is a useful example of a way of getting functions from
> > pairs of functions that is not a composition. Convolution is a useful
> > notion that arises in physical sciences as well as in computation.
> >
> > The important point in all of this is that Scala's type system doesn't
> > see certain aspects of computation that are still materially relevant
> > to working programmers. The stuff that falls into this category can
> > make practically useful documentation.
> >
> > Best wishes,
> >
> > --greg
> >
> > On Mon, Nov 16, 2009 at 6:53 AM, Ricky Clarkson
> > <ricky.clarkson@gmail.com <mailto:ricky.clarkson@gmail.com>> wrote:
> >
> > I put it to you that my wife, who has never[1] programmed in her life,
> > will be able to tell what the signature we have been discussing means.
> > She might need it rephrasing, as she's not familiar with Scala's
> > syntax. Here's how I might rephrase it:
> >
> > There's a converter called f. It takes in a value of type A, and
> > returns a value of type B.
> > There's a converter called g. It takes in a value of type B, and
> > returns a value of type C.
> >
> > If I have f and g, and a value of type A, how would I get a value
> > of type C?
> >
> > We might draw boxes on paper too, I don't know yet.
> >
> > I don't mind pandering to morons, to use your terms, not least as I am
> > one in many contexts. I'm not dismissing anyone. I see no harm in
> > documenting signatures, even obvious ones, but I don't see it as
> > necessary. It's ok to me if Scala cannot be used in organisations
> > that place so much emphasis on documenting obvious things, rather than
> > having their staff understand fundamental concepts. Note that I'm not
> > even a committer though, and neither is Tony, to my knowledge. If
> > you're unhappy with the documentation, I've never heard of a
> > documentation-adding patch being rejected.
> >
> > [1] I got her doing a little bit of Scheme a couple of years ago, just
> > to keep her awake in a boring job. She picked Ruby after I showed her
> > code snippets from 13 languages, so she'll be learning that (as will
> > I) soon.
> >
> > 2009/11/16 Donald McLean <dmclean62@gmail.com
> > <mailto:dmclean62@gmail.com>>:
> > > While there seems to be a strong "let us not pander to the morons"
> > > faction, please keep in mind that many of the people that you are so
> > > casually dismissing do have real power to prevent the adoption of
> > > Scala in their organizations. Failure to provide Scaladoc that is
> > > genuinely useful to people like me who are reasonably bright and
> > > competent developers but not strong theorists is a potentially fatal
> > > mistake. The Scala community will not, in many cases, get a second
> > > chance to prove that their product is NOT a toy dreamed up by
> > > insufferable academic elitists.
> > >
> > > On Mon, Nov 16, 2009 at 8:27 AM, Ricky Clarkson
> > > <ricky.clarkson@gmail.com <mailto:ricky.clarkson@gmail.com>> wrote:
> > >>> I agree with you, Andrew, and disagree with Tony, in that English
> > >>> documentation must be associated with the signature above to
> > describe the
> > >>> semantics of the function. If one has a mathematical
> > inclination then
> > >>> perhaps some sort of formal specification language could be
> > used (Z?).
> > >>> However the interface needed by the compiler is not sufficient
> > to describe
> > >>> the function's (possibly complex and non-obvious) internal
> > operation.
> > >>
> > >> Where possible, the function should be simple and obvious, and
> > types
> > >> should be sufficient to describe it. As I said in another post, I
> > >> agree with Tony, except that a good English description is required
> > >> wherever one departs from the simple, obvious implementation.
> > > --
> > > Family photographs are a critical legacy for
> > > ourselves and our descendants. Protect that
> > > legacy with a digital backup and recovery plan.
> > >
> > > Join the photo preservation advocacy Facebook group:
> > >
> > http://www.facebook.com/home.php?ref=logo#/group.php?gid=148274709288
> > >
> >
> >
> >
> > --
> > Ricky Clarkson
> > Java and Scala Programmer, AD Holdings
> > +44 1565 770804
> > Skype: ricky_clarkson
> > Google Talk: ricky.clarkson@gmail.com
> > <mailto:ricky.clarkson@gmail.com>
> > Google Wave: ricky.clarkson@googlewave.com
> > <mailto:ricky.clarkson@googlewave.com>
> >
> >
> >
> >
> > --
> > L.G. Meredith
> > Managing Partner
> > Biosimilarity LLC
> > 1219 NW 83rd St
> > Seattle, WA 98117
> >
> > +1 206.650.3740
> >
> > http://biosimilarity.blogspot.com
>
> --
> Tony Morris
> http://tmorris.net/
>
>
New! Receive and respond to mail from other email accounts from within Hotmail Find out how.
Add other email accounts to Hotmail in 3 easy steps. Find out how.
From: oxbow_lakes@hotmail.com
To: tonymorris@gmail.com; lgreg.meredith@gmail.com
CC: ricky.clarkson@gmail.com; dmclean62@gmail.com; scala-user@listes.epfl.ch
Subject: RE: [scala-user] Re: Scaladoc that is actually useful?
Date: Tue, 17 Nov 2009 08:40:58 +0000
.ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Verdana;} Tony -
You have taken this way too far. The contents of your last email are pretty disgraceful.
May I remind you that the original poster on the thread made a point about the general lack of documentation in scala. You responded with an obscure point about *one single function's type signature*, did not clarify that you were only talking about that one function and neither did it clarify that you were talking about it in the purely functional sense, as opposed to the scala method sense.
Your response as you intended it was hence almost completely irrelevant to the original question - as you did not clarify your terms, plenty misunderstood what you were saying. It has taken others to come to this thread to educate as by that stage you had degenerated into passive-aggressive abuse.
Chris
> Date: Tue, 17 Nov 2009 06:50:39 +1000
> From: tonymorris@gmail.com
> To: lgreg.meredith@gmail.com
> CC: ricky.clarkson@gmail.com; dmclean62@gmail.com; scala-user@listes.epfl.ch
> Subject: Re: [scala-user] Re: Scaladoc that is actually useful?
>
> They are not observably distinguishable under extensional equivalence.
> Can you imagine if I'd said that up front? Yeah I'd be the "theorist"
> from that "faction", which is rather ignorant given the facts, but I
> digress. This is the kind of balance I must maintain with the few who
> like learning, the few from whom I'd be preaching to the choir and the
> many who resent learning from the Scala community. Perhaps it's an error
> to start where I did or perhaps it's an error to even attempt it on the
> mailing list. I didn't expect such blatant dishonesty, poor
> comprehension and failure to understand such a basic fact, which is very
> well documented (I won't bother posting the proof or the paper --
> because none of you read it right?).
>
> I haven't even proposed an argument, merely stated an absolute,
> provable, proven, falsifiable, unfalsified, absolute, undeniable,
> you-look-like-holocaust-deniers,
> yes-evolution-is-supported-by-a-mountain-of-evidence fact that has been
> misrepresented repeatedly. I'm flabbergasted that so many programmers
> cannot grasp this, but on the other hand, I'm not really. But I am even
> more flabbergasted that it came from you Greg.
>
> I know a lot of you care about how you to appear to others (I don't give
> a flying fish -- I'm more interested in reality), so I might inform you
> that there are lots of people laughing at the ignorance of a basic fact
> by the Scala community right now. They have far less sympathy than I do
> -- I'm not laughing.
>
> Meredith Gregory wrote:
> > Dear Ricky,
> >
> > i have responded to this argument repeatedly. i'm not sure why people
> > are not getting this. Tony's argument is blatantly false. There are
> > countably infinitely many inhabitants of the type (A => B) => (B => C)
> > => A => C. They are observably distinguished by running time and space
> > consumption. Here is one infinite subset of that set: for each k in
> > the natural numbers we have
> >
> > Compose_k( f, g ) = { ( x ) => { var d = computeKthDigitOfPi( k ); g(
> > f( x ) ) } : (A => B) => (B => C) => A => C
> >
> > There are lots more infinite subsets where that one came from. The
> > differences in complexity are not just manifest by silliness of the
> > kind above. There are materially relevant differences that have to do
> > with the internal representation of function and evaluation.
> >
> > Beyond that, consider the following function
> >
> > // provided A, B, C <: T with T supporting a certain algebraic structure
> > Convolution_tau( f, g ) = { ( t ) => { integrate( f( t ) * g( tau - t
> > ), posInf, negInf ) } } : (A => B) => (B => C) => A => C
> >
> > For the subset of types supporting a certain algebraic structure --
> > i.e. we restrict the universe of quantification in the original
> > theorem -- this is a useful example of a way of getting functions from
> > pairs of functions that is not a composition. Convolution is a useful
> > notion that arises in physical sciences as well as in computation.
> >
> > The important point in all of this is that Scala's type system doesn't
> > see certain aspects of computation that are still materially relevant
> > to working programmers. The stuff that falls into this category can
> > make practically useful documentation.
> >
> > Best wishes,
> >
> > --greg
> >
> > On Mon, Nov 16, 2009 at 6:53 AM, Ricky Clarkson
> > <ricky.clarkson@gmail.com <mailto:ricky.clarkson@gmail.com>> wrote:
> >
> > I put it to you that my wife, who has never[1] programmed in her life,
> > will be able to tell what the signature we have been discussing means.
> > She might need it rephrasing, as she's not familiar with Scala's
> > syntax. Here's how I might rephrase it:
> >
> > There's a converter called f. It takes in a value of type A, and
> > returns a value of type B.
> > There's a converter called g. It takes in a value of type B, and
> > returns a value of type C.
> >
> > If I have f and g, and a value of type A, how would I get a value
> > of type C?
> >
> > We might draw boxes on paper too, I don't know yet.
> >
> > I don't mind pandering to morons, to use your terms, not least as I am
> > one in many contexts. I'm not dismissing anyone. I see no harm in
> > documenting signatures, even obvious ones, but I don't see it as
> > necessary. It's ok to me if Scala cannot be used in organisations
> > that place so much emphasis on documenting obvious things, rather than
> > having their staff understand fundamental concepts. Note that I'm not
> > even a committer though, and neither is Tony, to my knowledge. If
> > you're unhappy with the documentation, I've never heard of a
> > documentation-adding patch being rejected.
> >
> > [1] I got her doing a little bit of Scheme a couple of years ago, just
> > to keep her awake in a boring job. She picked Ruby after I showed her
> > code snippets from 13 languages, so she'll be learning that (as will
> > I) soon.
> >
> > 2009/11/16 Donald McLean <dmclean62@gmail.com
> > <mailto:dmclean62@gmail.com>>:
> > > While there seems to be a strong "let us not pander to the morons"
> > > faction, please keep in mind that many of the people that you are so
> > > casually dismissing do have real power to prevent the adoption of
> > > Scala in their organizations. Failure to provide Scaladoc that is
> > > genuinely useful to people like me who are reasonably bright and
> > > competent developers but not strong theorists is a potentially fatal
> > > mistake. The Scala community will not, in many cases, get a second
> > > chance to prove that their product is NOT a toy dreamed up by
> > > insufferable academic elitists.
> > >
> > > On Mon, Nov 16, 2009 at 8:27 AM, Ricky Clarkson
> > > <ricky.clarkson@gmail.com <mailto:ricky.clarkson@gmail.com>> wrote:
> > >>> I agree with you, Andrew, and disagree with Tony, in that English
> > >>> documentation must be associated with the signature above to
> > describe the
> > >>> semantics of the function. If one has a mathematical
> > inclination then
> > >>> perhaps some sort of formal specification language could be
> > used (Z?).
> > >>> However the interface needed by the compiler is not sufficient
> > to describe
> > >>> the function's (possibly complex and non-obvious) internal
> > operation.
> > >>
> > >> Where possible, the function should be simple and obvious, and
> > types
> > >> should be sufficient to describe it. As I said in another post, I
> > >> agree with Tony, except that a good English description is required
> > >> wherever one departs from the simple, obvious implementation.
> > > --
> > > Family photographs are a critical legacy for
> > > ourselves and our descendants. Protect that
> > > legacy with a digital backup and recovery plan.
> > >
> > > Join the photo preservation advocacy Facebook group:
> > >
> > http://www.facebook.com/home.php?ref=logo#/group.php?gid=148274709288
> > >
> >
> >
> >
> > --
> > Ricky Clarkson
> > Java and Scala Programmer, AD Holdings
> > +44 1565 770804
> > Skype: ricky_clarkson
> > Google Talk: ricky.clarkson@gmail.com
> > <mailto:ricky.clarkson@gmail.com>
> > Google Wave: ricky.clarkson@googlewave.com
> > <mailto:ricky.clarkson@googlewave.com>
> >
> >
> >
> >
> > --
> > L.G. Meredith
> > Managing Partner
> > Biosimilarity LLC
> > 1219 NW 83rd St
> > Seattle, WA 98117
> >
> > +1 206.650.3740
> >
> > http://biosimilarity.blogspot.com
>
> --
> Tony Morris
> http://tmorris.net/
>
>
New! Receive and respond to mail from other email accounts from within Hotmail Find out how.
Add other email accounts to Hotmail in 3 easy steps. Find out how.
To your list i would add something like a reference to context with -- if possible -- links to background information. As i mentioned in a previous post often times we employ algorithms that are really part of a family of algorithms. i used as example the GARCH or VAR families, but of course there are many, many many examples of this. When we provide some context like that it helps people who know the domain to quickly ascertain approximate good uses and potential caveats. It also provides people who don't know the domain a way in to develop a sense of how best to use the code.
Best wishes,
--greg
On Mon, Nov 16, 2009 at 9:47 AM, Johannes Rudolph <johannes.rudolph@googlemail.com> wrote:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com