Time to encourage meaningful type parameter names? Discuss

There is a startling improvement in the readability of your modified
method signature.

On Wed, Nov 16, 2011 at 1:53 PM, Ken McDonald wrote:
> Now consider the following type signature:
>
> flatMap [B, That] (f: (A)
> => GenTraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]): That
>
> How about this
>
> flatMap [resultElementType, resultType] (f: (inputElementType)
> => GenTraversableOnce[resultElementType])(implicit bf: CanBuildFrom[List[inputElementType],
> resultElementType, resultType]): resultType
>

On Wed, Nov 16, 2011 at 16:53, Ken McDonald wrote:
> This comes from thinking about the alleged complexity of Scala (others'
> arguments have convinced me it is a real problem in the corporate world), my
> own experiences as I start to penetrate a little bit of the "inner core" of
> Scala, and most of all, trying to be productive and ask, "Are there simple
> ways to mitigate the complexity problem?" (Assuming you believe it is a
> problem.)
> First, consider the following method:
> def someMeaningfulName(x: Int, y: String, z: Long) {...}
> I don't know about you, but I have never worked in an environment where this
> would be considered acceptable code (unless x, y, and z actually had special
> meaning in the problem space). I think it's a given that good software
> engineering demands meaningful variable names, both internal and visible.
> Now consider the following type signature:
>
> flatMap [B, That] (f: (A)
> => GenTraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]): That
>
> There are three type parameters, A, B, and That. None are meaningful. Due to
> the fortunate inclusion of f: in the type, it's fairly easy to figure out
> the meanings of A and B. We can finally figure out the meaning of That when
> we reach the end of the line, at which point we need to reread the entire
> line to put everything together. (OK, you may not. I do, and I submit that
> most programmers will need to do so once or more.)
> In fairness, there was a valid reason for using one-char type param back
> when type params were new; the declarations were simply (usually container
> classes), and the one-char rule made it obvious what was a type param and
> what was an actual type. Note the above def'n has already violated the
> one-char rule, without really adding value.
> How about this
>
> flatMap [resultElementType, resultType] (f: (inputElementType)
> => GenTraversableOnce[resultElementType])(implicit bf: CanBuildFrom[List[inputElementType],
> resultElementType, resultType]): resultType
>
> This is much more verbose, but to someone unaccustomed to Scala collections,
> it is also much clearer. I've taken the liberty of using initial lowercase
> to denote a parameter rather than an actual type; I believe this is illegal,
> but I simply wanted to show how things could be made more readable.
> If you're an experienced Scala user, this may not seem a big deal, just
> extra characters. Consider the process of reading the type signature from
> left to right, understanding as we go:
> flatMap [B, That]
>
> vs.
> flatMap [resultElementType, resultType]
>
> The second has immediate meaning. The first does not.
> The example I chose was mid-level in complexity--it is as the top of what a
> Scala novice should encounter, but nowhere near as complex as one might
> encounter in Scala internals or scalaz.
> I believe that encouraging meaninful type parameter names would help the
> perceived "Scala complexity" problem in two ways. First, it makes the more
> complex "beginner's" Scala signatures more immediately understandable to
> beginners. Second, it make intellectually sophisticated Scala code more
> acceptable to the mainstream by making it more readable.

While this sounds reasonable, the more, let's say, "abstract"
abstractions are not particularly prone to good names, because they do
not refer to particulars.

Consider, for instance a Monad[M[_]], or a method that _takes_ a monad
"m" as argument. What is the type A of M[A] such that exists
Monad[M[_]]? It is not the "element type", because that really works
for collections that contains thing. If you apply it to a continuation
monad, it doesn't make much sense. And what do you call "m" except
"monad"?

This always remind me of something that I witnessed at college. As the
teacher explained some abstract concept in linear algebra, the class
was very quiet. Some student then decided enough was enough and
decided to try to get something more concrete out of the teacher. The
dialog went pretty much like this:

- Professor, I'm having trouble understanding this. Could you give as
an example?
- This _is_ an example.
- No, I mean, could you give an example with numbers?
- Oh, ok. Assume you have three numbers, a, b, and c...

To be honest, I glaze over when I see the second signature but not the first.

On Wed, Nov 16, 2011 at 10:53 AM, Ken McDonald wrote:
> This comes from thinking about the alleged complexity of Scala (others'
> arguments have convinced me it is a real problem in the corporate world), my
> own experiences as I start to penetrate a little bit of the "inner core" of
> Scala, and most of all, trying to be productive and ask, "Are there simple
> ways to mitigate the complexity problem?" (Assuming you believe it is a
> problem.)
> First, consider the following method:
> def someMeaningfulName(x: Int, y: String, z: Long) {...}
> I don't know about you, but I have never worked in an environment where this
> would be considered acceptable code (unless x, y, and z actually had special
> meaning in the problem space). I think it's a given that good software
> engineering demands meaningful variable names, both internal and visible.
> Now consider the following type signature:
>
> flatMap [B, That] (f: (A)
> => GenTraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]): That
>
> There are three type parameters, A, B, and That. None are meaningful. Due to
> the fortunate inclusion of f: in the type, it's fairly easy to figure out
> the meanings of A and B. We can finally figure out the meaning of That when
> we reach the end of the line, at which point we need to reread the entire
> line to put everything together. (OK, you may not. I do, and I submit that
> most programmers will need to do so once or more.)
> In fairness, there was a valid reason for using one-char type param back
> when type params were new; the declarations were simply (usually container
> classes), and the one-char rule made it obvious what was a type param and
> what was an actual type. Note the above def'n has already violated the
> one-char rule, without really adding value.
> How about this
>
> flatMap [resultElementType, resultType] (f: (inputElementType)
> => GenTraversableOnce[resultElementType])(implicit bf: CanBuildFrom[List[inputElementType],
> resultElementType, resultType]): resultType
>
> This is much more verbose, but to someone unaccustomed to Scala collections,
> it is also much clearer. I've taken the liberty of using initial lowercase
> to denote a parameter rather than an actual type; I believe this is illegal,
> but I simply wanted to show how things could be made more readable.
> If you're an experienced Scala user, this may not seem a big deal, just
> extra characters. Consider the process of reading the type signature from
> left to right, understanding as we go:
> flatMap [B, That]
>
> vs.
> flatMap [resultElementType, resultType]
>
> The second has immediate meaning. The first does not.
> The example I chose was mid-level in complexity--it is as the top of what a
> Scala novice should encounter, but nowhere near as complex as one might
> encounter in Scala internals or scalaz.
> I believe that encouraging meaninful type parameter names would help the
> perceived "Scala complexity" problem in two ways. First, it makes the more
> complex "beginner's" Scala signatures more immediately understandable to
> beginners. Second, it make intellectually sophisticated Scala code more
> acceptable to the mainstream by making it more readable.
> OK, that's it. Discuss :-)
>
> Thanks,
> Ken
>

This comes from thinking about the alleged complexity of Scala (others' arguments have convinced me it is a real problem in the corporate world), my own experiences as I start to penetrate a little bit of the "inner core" of Scala, and most of all, trying to be productive and ask, "Are there simple ways to mitigate the complexity problem?" (Assuming you believe it is a problem.)
First, consider the following method:
def someMeaningfulName(x: Int, y: String, z: Long) {...}
I don't know about you, but I have never worked in an environment where this would be considered acceptable code (unless x, y, and z actually had special meaning in the problem space). I think it's a given that good software engineering demands meaningful variable names, both internal and visible.
Now consider the following type signature: flatMap [B, That] (f: (A) ⇒ GenTraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]): That

Yes, a good teacher should be able to give good examples of any
abstract concept, and the first examples shown should be as simple as
possible and contain as few extraneous complications as possible,
preferably none. Human minds are not compilers, but some teachers seem
to think they are. Our thinking tends to start in concrete terms and
progress to generalization and abstraction, not the other way around.

I recall an undergraduate class that I took many years ago in
classical control theory. The instructor would write equations and
talk about damping, natural frequency, etc. I didn't have too much
problem with it, but at least one person in particular didn't seem to
have a clue what he was talking about. She ended up getting into a
nasty spat with him. All he had to do was to give a few simple
examples and explain what the terms meant *physically*, as opposed to
*mathematically*. But apparently his mode of thinking was so abstract
that it did not occur to him.

Take a look at the IEEE Transactions on Automatic Control sometime for
some extreme examples of this kind of thinking. It tends to be very
abstract and mathematical with few practical examples of how the
concepts can be applied. Some of the authors almost seem to consider
practical applications and examples to be trivial and beneath their
dignity to spend time on -- an excercise left for the student.

--Russ P.

On Nov 16, 11:18 am, Daniel Sobral wrote:
> On Wed, Nov 16, 2011 at 16:53, Ken McDonald wrote:
> > This comes from thinking about the alleged complexity of Scala (others'
> > arguments have convinced me it is a real problem in the corporate world), my
> > own experiences as I start to penetrate a little bit of the "inner core" of
> > Scala, and most of all, trying to be productive and ask, "Are there simple
> > ways to mitigate the complexity problem?" (Assuming you believe it is a
> > problem.)
> > First, consider the following method:
> > def someMeaningfulName(x: Int, y: String, z: Long) {...}
> > I don't know about you, but I have never worked in an environment where this
> > would be considered acceptable code (unless x, y, and z actually had special
> > meaning in the problem space). I think it's a given that good software
> > engineering demands meaningful variable names, both internal and visible.
> > Now consider the following type signature:
>
> > flatMap [B, That] (f: (A)
> > => GenTraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]): That
>
> > There are three type parameters, A, B, and That. None are meaningful. Due to
> > the fortunate inclusion of f: in the type, it's fairly easy to figure out
> > the meanings of A and B. We can finally figure out the meaning of That when
> > we reach the end of the line, at which point we need to reread the entire
> > line to put everything together. (OK, you may not. I do, and I submit that
> > most programmers will need to do so once or more.)
> > In fairness, there was a valid reason for using one-char type param back
> > when type params were new; the declarations were simply (usually container
> > classes), and the one-char rule made it obvious what was a type param and
> > what was an actual type. Note the above def'n has already violated the
> > one-char rule, without really adding value.
> > How about this
>
> > flatMap [resultElementType, resultType] (f: (inputElementType)
> > => GenTraversableOnce[resultElementType])(implicit bf: CanBuildFrom[List[inputElementType],
> > resultElementType, resultType]): resultType
>
> > This is much more verbose, but to someone unaccustomed to Scala collections,
> > it is also much clearer. I've taken the liberty of using initial lowercase
> > to denote a parameter rather than an actual type; I believe this is illegal,
> > but I simply wanted to show how things could be made more readable.
> > If you're an experienced Scala user, this may not seem a big deal, just
> > extra characters. Consider the process of reading the type signature from
> > left to right, understanding as we go:
> >      flatMap [B, That]
>
> > vs.
> >      flatMap [resultElementType, resultType]
>
> > The second has immediate meaning. The first does not.
> > The example I chose was mid-level in complexity--it is as the top of what a
> > Scala novice should encounter, but nowhere near as complex as one might
> > encounter in Scala internals or scalaz.
> > I believe that encouraging meaninful type parameter names would help the
> > perceived "Scala complexity" problem in two ways. First, it makes the more
> > complex "beginner's" Scala signatures more immediately understandable to
> > beginners. Second, it make intellectually sophisticated Scala code more
> > acceptable to the mainstream by making it more readable.
>
> While this sounds reasonable, the more, let's say, "abstract"
> abstractions are not particularly prone to good names, because they do
> not refer to particulars.
>
> Consider, for instance a Monad[M[_]], or a method that _takes_ a monad
> "m" as argument. What is the type A of M[A] such that exists
> Monad[M[_]]? It is not the "element type", because that really works
> for collections that contains thing. If you apply it to a continuation
> monad, it doesn't make much sense. And what do you call "m" except
> "monad"?
>
> This always remind me of something that I witnessed at college. As the
> teacher explained some abstract concept in linear algebra, the class
> was very quiet. Some student then decided enough was enough and
> decided to try to get something more concrete out of the teacher. The
> dialog went pretty much like this:
>
> - Professor, I'm having trouble understanding this. Could you give as
> an example?
> - This _is_ an example.
> - No, I mean, could you give an example with numbers?
> - Oh, ok. Assume you have three numbers, a, b, and c...
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

While this sounds reasonable, the more, let's say, "abstract"
abstractions are not particularly prone to good names, because they do
not refer to particulars.

To be honest, I glaze over when I see the second signature but not the first.

. Long names hurt eyes.

D.

I recommend applying the same heuristics you use for any names. The more concrete the concept, the more concrete the name should be..

Sent from my iPad

On Nov 16, 2011, at 2:18 PM, Daniel Sobral wrote:

> On Wed, Nov 16, 2011 at 16:53, Ken McDonald wrote:
>> This comes from thinking about the alleged complexity of Scala (others'
>> arguments have convinced me it is a real problem in the corporate world), my
>> own experiences as I start to penetrate a little bit of the "inner core" of
>> Scala, and most of all, trying to be productive and ask, "Are there simple
>> ways to mitigate the complexity problem?" (Assuming you believe it is a
>> problem.)
>> First, consider the following method:
>> def someMeaningfulName(x: Int, y: String, z: Long) {...}
>> I don't know about you, but I have never worked in an environment where this
>> would be considered acceptable code (unless x, y, and z actually had special
>> meaning in the problem space). I think it's a given that good software
>> engineering demands meaningful variable names, both internal and visible.
>> Now consider the following type signature:
>>
>> flatMap [B, That] (f: (A)
>> => GenTraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]): That
>>
>> There are three type parameters, A, B, and That. None are meaningful. Due to
>> the fortunate inclusion of f: in the type, it's fairly easy to figure out
>> the meanings of A and B. We can finally figure out the meaning of That when
>> we reach the end of the line, at which point we need to reread the entire
>> line to put everything together. (OK, you may not. I do, and I submit that
>> most programmers will need to do so once or more.)
>> In fairness, there was a valid reason for using one-char type param back
>> when type params were new; the declarations were simply (usually container
>> classes), and the one-char rule made it obvious what was a type param and
>> what was an actual type. Note the above def'n has already violated the
>> one-char rule, without really adding value.
>> How about this
>>
>> flatMap [resultElementType, resultType] (f: (inputElementType)
>> => GenTraversableOnce[resultElementType])(implicit bf: CanBuildFrom[List[inputElementType],
>> resultElementType, resultType]): resultType
>>
>> This is much more verbose, but to someone unaccustomed to Scala collections,
>> it is also much clearer. I've taken the liberty of using initial lowercase
>> to denote a parameter rather than an actual type; I believe this is illegal,
>> but I simply wanted to show how things could be made more readable.
>> If you're an experienced Scala user, this may not seem a big deal, just
>> extra characters. Consider the process of reading the type signature from
>> left to right, understanding as we go:
>> flatMap [B, That]
>>
>> vs.
>> flatMap [resultElementType, resultType]
>>
>> The second has immediate meaning. The first does not.
>> The example I chose was mid-level in complexity--it is as the top of what a
>> Scala novice should encounter, but nowhere near as complex as one might
>> encounter in Scala internals or scalaz.
>> I believe that encouraging meaninful type parameter names would help the
>> perceived "Scala complexity" problem in two ways. First, it makes the more
>> complex "beginner's" Scala signatures more immediately understandable to
>> beginners. Second, it make intellectually sophisticated Scala code more
>> acceptable to the mainstream by making it more readable.
>
> While this sounds reasonable, the more, let's say, "abstract"
> abstractions are not particularly prone to good names, because they do
> not refer to particulars.
>
> Consider, for instance a Monad[M[_]], or a method that _takes_ a monad
> "m" as argument. What is the type A of M[A] such that exists
> Monad[M[_]]? It is not the "element type", because that really works
> for collections that contains thing. If you apply it to a continuation
> monad, it doesn't make much sense. And what do you call "m" except
> "monad"?
>
> This always remind me of something that I witnessed at college. As the
> teacher explained some abstract concept in linear algebra, the class
> was very quiet. Some student then decided enough was enough and
> decided to try to get something more concrete out of the teacher. The
> dialog went pretty much like this:
>
> - Professor, I'm having trouble understanding this. Could you give as
> an example?
> - This _is_ an example.
> - No, I mean, could you give an example with numbers?
> - Oh, ok. Assume you have three numbers, a, b, and c...
>

- because they will appear repeatedly across your code when you write generic methods / traits, and it's already painful to write them in single letters
- because they should be capitalised to distinguish them from values, and hence they appear with visual contrast to class names which are also capitalized
- because they are read along with their carriers. e.g. `List[A]` obviously is a list of elements, where variable `a` has no meaning.

On 17 Nov 2011, at 01:09, Ken McDonald wrote:

> . Long names hurt eyes.
>
> D.
>
> So long variable names hurt eyes?
>
> This is a serious question. Why are long variable names good, and long type parameter names bad?
>
> Ken
>
>
>

- because they will appear repeatedly across your code when you write generic methods / traits, and it's already painful to write them in single letters
- because they should be capitalised to distinguish them from values, and hence they appear with visual contrast to class names which are also capitalized
- because they are read along with their carriers. e.g. `List[A]` obviously is a list of elements, where variable `a` has no meaning.

On 17 Nov 2011, at 01:09, Ken McDonald wrote:

> . Long names hurt eyes.
>
> D.
>
> So long variable names hurt eyes?
>
> This is a serious question. Why are long variable names good, and long type parameter names bad?
>
> Ken
>  
>  
>

On 17 Nov 2011, at 03:08, Ken McDonald wrote:

> - IDEs mean you do not have to type the full name every time.

( i type variable names and type names preferably without an autocompletion popup showing. )

> - ??? I don't understand your second objection.

T Abstract Type Member
Class Class
value value

easy to distinguish.

List[List[A]] - -> List a class, A a generic type parameter -- a list of a list of elements (A). simple
List[elemType] -> woopa, gotta realize there are square brackets here and no parentheses

> - I think in this point you're arguing for me rather than against me. List[A] may be "obviously" bet a set of elements, but my whole point was that _as type signatures have become more complex_, the "single-char type parameter" convention has lost validity. As for variable 'a' has no meaning: Show me one example, _anywhere_ of a variable that has _no_ meaning. Maybe in Prolog, but that's arguable.

def add( elem: A ) // yes
def add( a: Elem ) // no

why would you juggle around inside the method body with 'a' when you can have 'elem' which is clear.

here some code i'm just writing in this moment:

trait AssocEntry[ S <: Sys[ S ], A ] extends Entry[ S ] {
def value( implicit tx: S#Tx ) : A
def append( value: A )( implicit tx: S#Tx ) : AssocEntry[ S, A ]
def prepend( value: A )( implicit tx: S#Tx ) : AssocEntry[ S, A ]
}

versus

trait AssocEntry[ system <: Sys[ system ], element ] extends Entry[ system ] {
def value( implicit tx: system#transaction ) : element
def append( value: element )( implicit tx: system#transaction ) : AssocEntry[ system, element ]
def prepend( value: element )( implicit tx: system#transaction ) : AssocEntry[ system, element ]
}

honestly, i doubt anyone wants to either read or write it this way.

best, -sciss-

> - IDEs mean you do not have to type the full name every time.

( i type variable names and type names preferably without an autocompletion popup showing. )

> - ??? I don't understand your second objection.

T          Abstract Type Member
Class  Class
value   value

easy to distinguish.

List[List[A]]  -     -> List a class, A a generic type parameter -- a list of a list of elements (A). simple
List[elemType]  -> woopa, gotta realize there are square brackets here and no parentheses

> - I think in this point you're arguing for me rather than against me. List[A] may be "obviously" bet a set of elements, but my whole point was that _as type signatures have become more complex_, the "single-char type parameter" convention has lost validity. As for variable 'a' has no meaning: Show me one example, _anywhere_ of a variable that has _no_ meaning. Maybe in Prolog, but that's arguable.

def add( elem: A )    // yes
def add( a: Elem )    // no

why would you juggle around inside the method body with 'a' when you can have 'elem' which is clear.

here some code i'm just writing in this moment:

   trait AssocEntry[ S <: Sys[ S ], A ] extends Entry[ S ] {
      def value( implicit tx: S#Tx ) : A
      def append( value: A )( implicit tx: S#Tx ) : AssocEntry[ S, A ]
      def prepend( value: A )( implicit tx: S#Tx ) : AssocEntry[ S, A ]
   }

versus

   trait AssocEntry[ system <: Sys[ system ], element ] extends Entry[ system ] {
      def value( implicit tx: system#transaction ) : element
      def append( value: element )( implicit tx: system#transaction ) : AssocEntry[ system, element ]
      def prepend( value: element )( implicit tx: system#transaction ) : AssocEntry[ system, element ]
   }

honestly, i doubt anyone wants to either read or write it this way.

For me it makes it harder to visualize what the signature of the method actually is. When I look at flatMap, the signature 'A => M[B]' should be easy to see, and it isn't easy for me to see it in the verbose version. I would end up being dependent on the documentation to tell me what the method does, rather then just looking at the signature.

I have the same problem with java code that uses many long method names all jumbled together.

On 11/17/2011 01:33 PM, Derek Williams wrote:
>
> For me it makes it harder to visualize what the signature of the
> method actually is. When I look at flatMap, the signature 'A => M[B]'
> should be easy to see, and it isn't easy for me to see it in the
> verbose version. I would end up being dependent on the documentation
> to tell me what the method does, rather then just looking at the
> signature.
>
> I have the same problem with java code that uses many long method
> names all jumbled together.
>

What's wrong with this? Much easier to read:

FingWhatIsComingOffDaMonadEnvironment =>
FingWhatIsAMonadEnvironment[NewFingWhatTheMonadEnvironmentIsDefinedOver]

PS: Isn't this another -debatey topic?

here some code i'm just writing in this moment:

  trait AssocEntry[ S <: Sys[ S ], A ] extends Entry[ S ] {
     def value( implicit tx: S#Tx ) : A
     def append( value: A )( implicit tx: S#Tx ) : AssocEntry[ S, A ]
     def prepend( value: A )( implicit tx: S#Tx ) : AssocEntry[ S, A ]
  }

versus

  trait AssocEntry[ system <: Sys[ system ], element ] extends Entry[ system ] {
     def value( implicit tx: system#transaction ) : element
     def append( value: element )( implicit tx: system#transaction ) : AssocEntry[ system, element ]
     def prepend( value: element )( implicit tx: system#transaction ) : AssocEntry[ system, element ]
  }

honestly, i doubt anyone wants to either read or write it this way.

best, -sciss-

What's wrong with this? Much easier to read:
FingWhatIsComingOffDaMonadEnvironment =>
FingWhatIsAMonadEnvironment[NewFingWhatTheMonadEnvironmentIsDefinedOver]

--
Tony Morris
http://tmorris.net/

On 17 November 2011 05:03, Tony Morris <tonymorris@gmail.com> wrote:
 

What's wrong with this? Much easier to read:
FingWhatIsComingOffDaMonadEnvironment =>
FingWhatIsAMonadEnvironment[NewFingWhatTheMonadEnvironmentIsDefinedOver]

Names can be too short or too long. This goes for variables, defs, classes and parametrized types. Picking strawman long-names doesn't invalidate the principle of choosing informative names.
Matthew 

--
Tony Morris
http://tmorris.net/

--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle University mailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143

On 17 November 2011 05:03, Tony Morris <tonymorris@gmail.com> wrote:
 

What's wrong with this? Much easier to read:
FingWhatIsComingOffDaMonadEnvironment =>
FingWhatIsAMonadEnvironment[NewFingWhatTheMonadEnvironmentIsDefinedOver]

Names can be too short or too long. This goes for variables, defs, classes and parametrized types. Picking strawman long-names doesn't invalidate the principle of choosing informative names.
Matthew 

--
Tony Morris
http://tmorris.net/

--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle University mailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143

On 16/11/2011 19:53, Ken McDonald wrote:
> OK, that's it. Discuss :-)

Aren't this kind of thread, and the others you started, belonging more to scala-debate?
scala-user description states it is about "questions and discussions about the Scala
programming" (mm, is there an extra "the" or a missing "language"? the meaning isn't the
same...)
scala-debate is about "questions and suggestions around the future of Scala" among others.

In fact, most of these discussions end to scala-debate, but often late.

Perhaps I am too picky about these questions, maybe because I am moderator in some
forums... :-)

On 17/11/11 20:48, Matthew Pocock wrote:
> On 17 November 2011 05:03, Tony Morris wrote:
>
>
>> What's wrong with this? Much easier to read:
>>
>> FingWhatIsComingOffDaMonadEnvironment =>
>> FingWhatIsAMonadEnvironment[NewFingWhatTheMonadEnvironmentIsDefinedOver]
>>
>>
> Names can be too short or too long. This goes for variables, defs, classes
> and parametrized types. Picking strawman long-names doesn't invalidate the
> principle of choosing informative names.
>
> Matthew
>
>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>
It is extremely important to pick meaningless names. The moment you
project meaning is the moment you start making all those mistakes that
we so often see.

Yet another thread that probably belongs on scala-debate.

AND to answer with my opinion :  I think using meaningful type parameter names can make sense, but there's a balance to be had.

This comes from thinking about the alleged complexity of Scala (others' arguments have convinced me it is a real problem in the corporate world), my own experiences as I start to penetrate a little bit of the "inner core" of Scala, and most of all, trying to be productive and ask, "Are there simple ways to mitigate the complexity problem?" (Assuming you believe it is a problem.)
First, consider the following method:
def someMeaningfulName(x: Int, y: String, z: Long) {...}
I don't know about you, but I have never worked in an environment where this would be considered acceptable code (unless x, y, and z actually had special meaning in the problem space). I think it's a given that good software engineering demands meaningful variable names, both internal and visible.
Now consider the following type signature: flatMap [B, That] (f: (A) ⇒ GenTraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]): That
There are three type parameters, A, B, and That. None are meaningful. Due to the fortunate inclusion of f: in the type, it's fairly easy to figure out the meanings of A and B. We can finally figure out the meaning of That when we reach the end of the line, at which point we need to reread the entire line to put everything together. (OK, you may not. I do, and I submit that most programmers will need to do so once or more.)
In fairness, there was a valid reason for using one-char type param back when type params were new; the declarations were simply (usually container classes), and the one-char rule made it obvious what was a type param and what was an actual type. Note the above def'n has already violated the one-char rule, without really adding value.
How about this

flatMap [resultElementType, resultType] (f: (inputElementType) ⇒ GenTraversableOnce[resultElementType])(implicit bf: CanBuildFrom[List[inputElementType], resultElementType, resultType]): resultType
This is much more verbose, but to someone unaccustomed to Scala collections, it is also much clearer. I've taken the liberty of using initial lowercase to denote a parameter rather than an actual type; I believe this is illegal, but I simply wanted to show how things could be made more readable.
If you're an experienced Scala user, this may not seem a big deal, just extra characters. Consider the process of reading the type signature from left to right, understanding as we go:
     flatMap [B, That] 

vs.      flatMap [resultElementType, resultType]

The second has immediate meaning. The first does not.
The example I chose was mid-level in complexity--it is as the top of what a Scala novice should encounter, but nowhere near as complex as one might encounter in Scala internals or scalaz.
I believe that encouraging meaninful type parameter names would help the perceived "Scala complexity" problem in two ways. First, it makes the more complex "beginner's" Scala signatures more immediately understandable to beginners. Second, it make intellectually sophisticated Scala code more acceptable to the mainstream by making it more readable.
OK, that's it. Discuss :-)

Thanks,Ken

>
It is extremely important to pick meaningless names. The moment you
project meaning is the moment you start making all those mistakes that
we so often see.

--
Tony Morris
http://tmorris.net/

On 17/11/11 22:56, Matthew Pocock wrote:
> On 17 November 2011 12:11, Tony Morris wrote:
>
>> It is extremely important to pick meaningless names. The moment you
>> project meaning is the moment you start making all those mistakes that
>> we so often see.
>>
> Many times the types are not devoid of meaning. Consider:
>
> trait Graph[A, B]
>
> vs
>
> trait Graph[N, E]
>
> vs
>
> trait Graph[Node, Edge]
>
> vs
>
> trait Graph[TheNodeType, TheEdgeType]
>
> Option 3 of these is (imao) optimal, as it clearly describes what role the
> types play without using unnecessarily verbose names. If you're not
> 'projecting meaning' on these two type parameters, you're not understanding
> the API. I've no problem with List[A], as there's nothing much to tell
> users about A. In a library like scalaz, consistent use of single-letter
> type parameters goes a long way, but then you have things like what the
> default letter should be for Monad vs Monoid.
>
> I'll bug out here, as I agree this should go to -debate until/unless it
> results in an agreement to go through the core libs renaming things, in
> which case I'd be happy to give up a 'documentation saturday' to helping
> rename things.
>
> Matthew
>
>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>

This is exactly the mistake I refer to. Now define your operations on
the data type. What do those operations (the important bits) say about
nodes and edges? Exactly, nothing, nothing at all -- now you're stuck in
a cognitive quagmire. Please allow me to politely decline your invitation.

Yet another thread that probably belongs on scala-debate.

AND to answer with my opinion :  I think using meaningful type parameter names can make sense, but there's a balance to be had.

This comes from thinking about the alleged complexity of Scala (others' arguments have convinced me it is a real problem in the corporate world), my own experiences as I start to penetrate a little bit of the "inner core" of Scala, and most of all, trying to be productive and ask, "Are there simple ways to mitigate the complexity problem?" (Assuming you believe it is a problem.)
First, consider the following method:
def someMeaningfulName(x: Int, y: String, z: Long) {...}
I don't know about you, but I have never worked in an environment where this would be considered acceptable code (unless x, y, and z actually had special meaning in the problem space). I think it's a given that good software engineering demands meaningful variable names, both internal and visible.
Now consider the following type signature: flatMap [B, That] (f: (A) ⇒ GenTraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]): That
There are three type parameters, A, B, and That. None are meaningful. Due to the fortunate inclusion of f: in the type, it's fairly easy to figure out the meanings of A and B. We can finally figure out the meaning of That when we reach the end of the line, at which point we need to reread the entire line to put everything together. (OK, you may not. I do, and I submit that most programmers will need to do so once or more.)
In fairness, there was a valid reason for using one-char type param back when type params were new; the declarations were simply (usually container classes), and the one-char rule made it obvious what was a type param and what was an actual type. Note the above def'n has already violated the one-char rule, without really adding value.
How about this

flatMap [resultElementType, resultType] (f: (inputElementType) ⇒ GenTraversableOnce[resultElementType])(implicit bf: CanBuildFrom[List[inputElementType], resultElementType, resultType]): resultType
This is much more verbose, but to someone unaccustomed to Scala collections, it is also much clearer. I've taken the liberty of using initial lowercase to denote a parameter rather than an actual type; I believe this is illegal, but I simply wanted to show how things could be made more readable.
If you're an experienced Scala user, this may not seem a big deal, just extra characters. Consider the process of reading the type signature from left to right, understanding as we go:
     flatMap [B, That] 

vs.      flatMap [resultElementType, resultType]

The second has immediate meaning. The first does not.
The example I chose was mid-level in complexity--it is as the top of what a Scala novice should encounter, but nowhere near as complex as one might encounter in Scala internals or scalaz.
I believe that encouraging meaninful type parameter names would help the perceived "Scala complexity" problem in two ways. First, it makes the more complex "beginner's" Scala signatures more immediately understandable to beginners. Second, it make intellectually sophisticated Scala code more acceptable to the mainstream by making it more readable.
OK, that's it. Discuss :-)

Thanks,Ken

On 17/11/11 22:56, Matthew Pocock wrote:
> trait Graph[TheNodeType, TheEdgeType]

This is exactly the mistake I refer to. Now define your operations on
the data type. What do those operations (the important bits) say about
nodes and edges?

Exactly, nothing, nothing at all

[I'm now subscribed to scala-debate - sorry if you got this twice]
On 17 November 2011 13:13, Tony Morris <tonymorris@gmail.com> wrote:

On 17/11/11 22:56, Matthew Pocock wrote:
> trait Graph[TheNodeType, TheEdgeType]

This is exactly the mistake I refer to. Now define your operations on
the data type. What do those operations (the important bits) say about
nodes and edges?

There is no meaningful isomorphism that I can repeatedly apply to Graph[Node, Edge] to get a Graph[Edge, Node] and then apply again to get back to the original graph. The nodes and edges play distinct roles. Naming them after these roles is useful documentation for the user.  

Exactly, nothing, nothing at all

It tells me a great deal about the graph API. It doesn't tell me anything about the specific choices of concrete types for Node/Edge, but that is not what type parameter names are for. It tells me what role they play in the graph, which is what type parameter names are for.  

On 17/11/2011 13:51, Josh Suereth wrote:
> Yet another thread that probably belongs on scala-debate.
>
> AND to answer with my opinion : I think using meaningful type parameter names can make
> sense, but there's a balance to be had.

Yes.
When I discovered Scala, I was disconcerted, not to say "shocked", by these one-letter
type names. Looked like those old C programs where developers valued conciseness over
expressiveness. You know, lines like: if (lh->v.u.s.aux == v->u.s.info)

Then I read that's a tradition in computer science, so I get used to it...
But I still believe that some well chosen names can help.
Of course, you can put signatures like those mentioned, and be more explicit in the
documentation of the API, but indeed, that's two places to look for.

On the other hand, there can be some confusion between real types (classes, etc.) and
abstract types (those used in collections, not knowing in advance what they would be);
perhaps even potential clashes (?).
Ie. is a ResultElement (I agree with Viktor, the "Type" part is a bit redundant) a real,
application level type or some abstract type? Can I have a ResultElement class in my app.
without conflict?

Specialized APIs like Graph[Node, Edge] are more OK, I suppose. Not sure about conflicts,
again.

On 17/11/2011 13:51, Josh Suereth wrote:

Yet another thread that probably belongs on scala-debate.

AND to answer with my opinion : I think using meaningful type parameter names can make
sense, but there's a balance to be had.

Yes.
When I discovered Scala, I was disconcerted, not to say "shocked", by these one-letter type names. Looked like those old C programs where developers valued conciseness over expressiveness. You know, lines like: if (lh->v.u.s.aux == v->u.s.info)

On the other hand, there can be some confusion between real types (classes, etc.) and abstract types (those used in collections, not knowing in advance what they would be); perhaps even potential clashes (?).

On 17/11/2011 13:51, Josh Suereth wrote:

Yet another thread that probably belongs on scala-debate.

AND to answer with my opinion : I think using meaningful type parameter names can make
sense, but there's a balance to be had.

Yes.
When I discovered Scala, I was disconcerted, not to say "shocked", by these one-letter type names. Looked like those old C programs where developers valued conciseness over expressiveness. You know, lines like: if (lh->v.u.s.aux == v->u.s.info)

On the other hand, there can be some confusion between real types (classes, etc.) and abstract types (those used in collections, not knowing in advance what they would be); perhaps even potential clashes (?).

2011/11/17 √iktor Ҡlang
>
>
> On Thu, Nov 17, 2011 at 2:58 PM, Matthew Pocock wrote:
>>
>> [I'm now subscribed to scala-debate - sorry if you got this twice]
>> On 17 November 2011 13:13, Tony Morris  wrote:
>>>
>>> On 17/11/11 22:56, Matthew Pocock wrote:
>>> > trait Graph[TheNodeType, TheEdgeType]
>
> "The" can be dropped since it cannot be anything else.
> "Type" can be dropped since it can only be a type, you don't write: "val theThingVal = new Thing"
>
> trait Graph[Node, Edge] <--- Looks great to me

Except you just killed Node and Edge as trait/class names. At the very
least, I'd call them ANode and AnEdge.

--
Daniel C. Sobral

I travel to the future all the time.

2011/11/17 √iktor Ҡlang <viktor.klang@gmail.com>
>
>
> On Thu, Nov 17, 2011 at 2:58 PM, Matthew Pocock <turingatemyhamster@gmail.com> wrote:
>>
>> [I'm now subscribed to scala-debate - sorry if you got this twice]
>> On 17 November 2011 13:13, Tony Morris <tonymorris@gmail.com> wrote:
>>>
>>> On 17/11/11 22:56, Matthew Pocock wrote:
>>> > trait Graph[TheNodeType, TheEdgeType]
>
> "The" can be dropped since it cannot be anything else.
> "Type" can be dropped since it can only be a type, you don't write: "val theThingVal = new Thing"
>
> trait Graph[Node, Edge] <--- Looks great to me

Except you just killed Node and Edge as trait/class names. At the very
least, I'd call them ANode and AnEdge.

--
Daniel C. Sobral

I travel to the future all the time.

On 17 November 2011 12:11, Tony Morris <tonymorris@gmail.com> wrote:

>
It is extremely important to pick meaningless names. The moment you
project meaning is the moment you start making all those mistakes that
we so often see.

Many times the types are not devoid of meaning. Consider:
trait Graph[A, B]
vs
trait Graph[N, E]
vs
trait Graph[Node, Edge]
vs
trait Graph[TheNodeType, TheEdgeType]
Option 3 of these is (imao) optimal, as it clearly describes what role the types play without using unnecessarily verbose names. If you're not 'projecting meaning' on these two type parameters, you're not understanding the API. I've no problem with List[A], as there's nothing much to tell users about A. In a library like scalaz, consistent use of single-letter type parameters goes a long way, but then you have things like what the default letter should be for Monad vs Monoid.
I'll bug out here, as I agree this should go to -debate until/unless it results in an agreement to go through the core libs renaming things, in which case I'd be happy to give up a 'documentation saturday' to helping rename things.
Matthew

--
Tony Morris
http://tmorris.net/

--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle University mailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143

2011/11/17 √iktor Ҡlang :
>
>> > trait Graph[Node, Edge] <--- Looks great to me
>>
>> Except you just killed Node and Edge as trait/class names. At the very
>> least, I'd call them ANode and AnEdge.
>
> trait Graph[N/*ode*/, E/*dge*/]

Won't show up on Scaladoc, so what's the point? Nope, I still prefer
ANode and AnEdge. :-)

On Thu, Nov 17, 2011 at 13:35, Simon Ochsenreither
wrote:
> Afaik C# prefixes type parameters with T and return type parameters with R
> ... but they also use I as a prefix for interfaces. The last holdout of
> Hungarian notation?

You should see that Uncle Bob has to say about prefixing interfaces
with I. Pretty funny! :-)

We already have great entries in the scaladoc about type parameters.

http://www.scala-lang.org/api/current/index.html#scala.collection.Map

Peace. Michael

2011/11/17 Daniel Sobral :
> 2011/11/17 √iktor Ҡlang :
>>
>>> > trait Graph[Node, Edge] <--- Looks great to me
>>>
>>> Except you just killed Node and Edge as trait/class names. At the very
>>> least, I'd call them ANode and AnEdge.
>>
>> trait Graph[N/*ode*/, E/*dge*/]
>
> Won't show up on Scaladoc, so what's the point? Nope, I still prefer
> ANode and AnEdge. :-)
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

We already have great entries in the scaladoc about type parameters.

http://www.scala-lang.org/api/current/index.html#scala.collection.Map

Peace.  Michael


2011/11/17 Daniel Sobral <dcsobral@gmail.com>:
> 2011/11/17 √iktor Ҡlang <viktor.klang@gmail.com>:
>>
>>> > trait Graph[Node, Edge] <--- Looks great to me
>>>
>>> Except you just killed Node and Edge as trait/class names. At the very
>>> least, I'd call them ANode and AnEdge.
>>
>> trait Graph[N/*ode*/, E/*dge*/]
>
> Won't show up on Scaladoc, so what's the point? Nope, I still prefer
> ANode and AnEdge. :-)
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

Well, fair point with Map[K, V]--I'm with you there!

On Thu, Nov 17, 2011 at 10:21 AM, Matthew Pocock
wrote:
> Yes.... Wouldn't Map[K, V] or Map[Key, Value] be more self-explanatory?
> Peace.
>
> 2011/11/17 Michael Schmitz
>>
>> We already have great entries in the scaladoc about type parameters.
>>
>> http://www.scala-lang.org/api/current/index.html#scala.collection.Map
>>
>> Peace.  Michael
>>
>>
>> 2011/11/17 Daniel Sobral :
>> > 2011/11/17 √iktor Ҡlang :
>> >>
>> >>> > trait Graph[Node, Edge] <--- Looks great to me
>> >>>
>> >>> Except you just killed Node and Edge as trait/class names. At the very
>> >>> least, I'd call them ANode and AnEdge.
>> >>
>> >> trait Graph[N/*ode*/, E/*dge*/]
>> >
>> > Won't show up on Scaladoc, so what's the point? Nope, I still prefer
>> > ANode and AnEdge. :-)
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > I travel to the future all the time.
>> >
>
>
>
> --
> Dr Matthew Pocock
> Integrative Bioinformatics Group, School of Computing Science, Newcastle
> University
> mailto: turingatemyhamster@gmail.com
> gchat: turingatemyhamster@gmail.com
> msn: matthew_pocock@yahoo.co.uk
> irc.freenode.net: drdozer
> skype: matthew.pocock
> tel: (0191) 2566550
> mob: +447535664143
>

Yes.... Wouldn't Map[K, V] or Map[Key, Value] be more self-explanatory? Peace.

2011/11/17 Michael Schmitz <michael@schmitztech.com>

We already have great entries in the scaladoc about type parameters.

http://www.scala-lang.org/api/current/index.html#scala.collection.Map

Peace.  Michael


2011/11/17 Daniel Sobral <dcsobral@gmail.com>:
> 2011/11/17 √iktor Ҡlang <viktor.klang@gmail.com>:
>>
>>> > trait Graph[Node, Edge] <--- Looks great to me
>>>
>>> Except you just killed Node and Edge as trait/class names. At the very
>>> least, I'd call them ANode and AnEdge.
>>
>> trait Graph[N/*ode*/, E/*dge*/]
>
> Won't show up on Scaladoc, so what's the point? Nope, I still prefer
> ANode and AnEdge. :-)
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle University mailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143

On 17 November 2011 12:11, Tony Morris <tonymorris@gmail.com> wrote:

>
It is extremely important to pick meaningless names. The moment you
project meaning is the moment you start making all those mistakes that
we so often see.

Many times the types are not devoid of meaning. Consider:
trait Graph[A, B]

trait Graph[N, E]

trait Graph[Node, Edge]

trait Graph[TheNodeType, TheEdgeType]

On Thu, Nov 17, 2011 at 01:45:56PM -0500, Rex Kerr wrote:
> This is why I think the sweet spot is [N,E]. You want _some_ mnemonic
> because you want to know for yourself (as well as the compiler knowing)
> that nodes come before edges. But [Node, Edge] is deceptive, and also
> steals the name Node and Edge away from what you probably really want
> (which are Node and Edge traits or classes).

Agreed.

I find the single letter convention actually makes the use of generics
more obvious to me and easier to reason about. If I had to figure out
whether everything that looked like "Node" was a type parameter or a
concrete type I would be sad. [1]

On Thu, Nov 17, 2011 at 1:45 PM, Rex Kerr wrote:
> This is why I think the sweet spot is [N,E].  You want _some_ mnemonic
> because you want to know for yourself (as well as the compiler knowing) that
> nodes come before edges.  But [Node, Edge] is deceptive, and also steals the
> name Node and Edge away from what you probably really want (which are Node
> and Edge traits or classes).

+1

XXOWENR7hwgREM_0xA [at] mail [dot] gmail [dot] com" type="cite"> On Thu, Nov 17, 2011 at 7:56 AM, Matthew Pocock <turingatemyhamster [at] gmail [dot] com" rel="nofollow">turingatemyhamster@gmail.com> wrote:

On 17 November 2011 12:11, Tony Morris <tonymorris [at] gmail [dot] com" target="_blank" rel="nofollow">tonymorris@gmail.com> wrote:

>
It is extremely important to pick meaningless names. The moment you
project meaning is the moment you start making all those mistakes that
we so often see.

Many times the types are not devoid of meaning. Consider:
trait Graph[A, B]

Bad.  Now I have to remember whether your graphs have nodes first or edges first.  I don't want to have to do that.
 

trait Graph[N, E]

Good!  Now I don't have to remember!
 

trait Graph[Node, Edge]

Why all the extra letters?  I already knew everything I needed to know.
 

trait Graph[TheNodeType, TheEdgeType]

This is just mean.

Actually, these are all bad.  Shouldn't it be

trait Graph[N <: Node, E <: Edge]

where Node and Edge are some traits that define the minimal possible interface required for something to be considered a node or an edge?  Maybe even

trait Graph[N <: Node, E <: Edge[N]]

depending on the edge interface?

Now we can see why Graph[Node, Edge] is the wrong choice.  You have labeled the types with _what you want_ without specifying that _they must be what you want_.  The more you insist with your names that you will in fact put the correct thing in that slot, the less likely you are to make the compiler insist on your behalf, and therefore the more burden you are taking upon yourself.

This is why I think the sweet spot is [N,E].  You want _some_ mnemonic because you want to know for yourself (as well as the compiler knowing) that nodes come before edges.  But [Node, Edge] is deceptive, and also steals the name Node and Edge away from what you probably really want (which are Node and Edge traits or classes).

  --Rex

+1

On Thu, Nov 17, 2011 at 11:01 AM, Erik Osheim wrote:
> On Thu, Nov 17, 2011 at 01:45:56PM -0500, Rex Kerr wrote:
>> This is why I think the sweet spot is [N,E].  You want _some_ mnemonic
>> because you want to know for yourself (as well as the compiler knowing)
>> that nodes come before edges.  But [Node, Edge] is deceptive, and also
>> steals the name Node and Edge away from what you probably really want
>> (which are Node and Edge traits or classes).
>
> Agreed.
>
> I find the single letter convention actually makes the use of generics
> more obvious to me and easier to reason about. If I had to figure out
> whether everything that looked like "Node" was a type parameter or a
> concrete type I would be sad. [1]
>

Write a few of your graph operations. Use the type parameters as if they were nodes or edges. Notice how you can't. The proposal is akin to projecting meaning onto universally quantified variables of a logical proposition. We say, paraphrased:

For all c such that c is an element of the set Cars...

Notice how we call the variable c, not car or any other particular meaning. Doing so would degrade readability to the extent that it may distract from the fact that this variable should contain no further context than its existence. The constraint of set membership is simply an application to an operation, no different to a list sort operation requiring ordering on its elements.

It is extremely important that type variable names contain no context (that is, call it what you want but I won't be projecting an imaginary context onto it). I am only motivated to point this out because one day someone is going to bring this point up IRL and I am going to have to deal with it. I don't want to; this elusive insight that I am apparently missing according to "the naming guys" is repeatedly shown to be a failed thesis and now it is crawling into the least welcome of places (type variables).

Please modify the thesis for practical purposes.

[I'm now subscribed to scala-debate - sorry if you got this twice]
On 17 November 2011 13:13, Tony Morris <tonymorris@gmail.com> wrote:

On 17/11/11 22:56, Matthew Pocock wrote:
> trait Graph[TheNodeType, TheEdgeType]

This is exactly the mistake I refer to. Now define your operations on
the data type. What do those operations (the important bits) say about
nodes and edges?

There is no meaningful isomorphism that I can repeatedly apply to Graph[Node, Edge] to get a Graph[Edge, Node] and then apply again to get back to the original graph. The nodes and edges play distinct roles. Naming them after these roles is useful documentation for the user.  

Exactly, nothing, nothing at all

It tells me a great deal about the graph API. It doesn't tell me anything about the specific choices of concrete types for Node/Edge, but that is not what type parameter names are for. It tells me what role they play in the graph, which is what type parameter names are for.  

Write a few of your graph operations. Use the type parameters as if they were nodes or edges. Notice how you can't. The proposal is akin to projecting meaning onto universally quantified variables of a logical proposition. We say, paraphrased:

For all c such that c is an element of the set Cars...

Notice how we call the variable c, not car or any other particular meaning. Doing so would degrade readability to the extent that it may distract from the fact that this variable should contain no further context than its existence. The constraint of set membership is simply an application to an operation, no different to a list sort operation requiring ordering on its elements.

It is extremely important that type variable names contain no context (that is, call it what you want but I won't be projecting an imaginary context onto it). I am only motivated to point this out because one day someone is going to bring this point up IRL and I am going to have to deal with it. I don't want to; this elusive insight that I am apparently missing according to "the naming guys" is repeatedly shown to be a failed thesis and now it is crawling into the least welcome of places (type variables).

Please modify the thesis for practical purposes.

On Nov 17, 2011 11:58 PM, "Matthew Pocock" <turingatemyhamster@gmail.com> wrote:

[I'm now subscribed to scala-debate - sorry if you got this twice]
On 17 November 2011 13:13, Tony Morris <tonymorris@gmail.com> wrote:

On 17/11/11 22:56, Matthew Pocock wrote:
> trait Graph[TheNodeType, TheEdgeType]

This is exactly the mistake I refer to. Now define your operations on
the data type. What do those operations (the important bits) say about
nodes and edges?

There is no meaningful isomorphism that I can repeatedly apply to Graph[Node, Edge] to get a Graph[Edge, Node] and then apply again to get back to the original graph. The nodes and edges play distinct roles. Naming them after these roles is useful documentation for the user.  

Exactly, nothing, nothing at all

It tells me a great deal about the graph API. It doesn't tell me anything about the specific choices of concrete types for Node/Edge, but that is not what type parameter names are for. It tells me what role they play in the graph, which is what type parameter names are for.  

Are you seriously expecting me to buy this? That I, and others who
aspire to get practical work done, are not "normal programmers", while
you, and your buddies are? Is this how you justify your thesis to
yourself? Sorry, but it's pretty transparent to me.

Do you not think I have worked with people who were once "naming guys"?
They are wrong, so they tried every trick they had, like you are doing.
They're not "naming guys" anymore.

Either demonstrate the point (an appeal to normality/abnormality
exclusion is fallacious -- surely this is obvious) or work out that
you're making a mistake with adverse practical implications. All you've
got to do is use your Node/Edge type variables as if they were nodes or
edges. Let me know when you have achieved this.

On 18/11/11 05:50, Matthew Pocock wrote:
> Tony,
>
> For normal programmers, names matter. Most people don't think in lambda
> calculus or category theory or first order predicate logic. These people
> need informative names.
>
> Matthew
>
> On 17 November 2011 19:42, Tony Morris wrote:
>
>> Write a few of your graph operations. Use the type parameters as if they
>> were nodes or edges. Notice how you can't. The proposal is akin to
>> projecting meaning onto universally quantified variables of a logical
>> proposition. We say, paraphrased:
>>
>> For all c such that c is an element of the set Cars...
>>
>> Notice how we call the variable c, not car or any other particular
>> meaning. Doing so would degrade readability to the extent that it may
>> distract from the fact that this variable should contain no further context
>> than its existence. The constraint of set membership is simply an
>> application to an operation, no different to a list sort operation
>> requiring ordering on its elements.
>>
>> It is extremely important that type variable names contain no context
>> (that is, call it what you want but I won't be projecting an imaginary
>> context onto it). I am only motivated to point this out because one day
>> someone is going to bring this point up IRL and I am going to have to deal
>> with it. I don't want to; this elusive insight that I am apparently missing
>> according to "the naming guys" is repeatedly shown to be a failed thesis
>> and now it is crawling into the least welcome of places (type variables).
>>
>> Please modify the thesis for practical purposes.
>> On Nov 17, 2011 11:58 PM, "Matthew Pocock"
>> wrote:
>>
>>> [I'm now subscribed to scala-debate - sorry if you got this twice]
>>>
>>> On 17 November 2011 13:13, Tony Morris wrote:
>>>
>>>> On 17/11/11 22:56, Matthew Pocock wrote:
>>>>> trait Graph[TheNodeType, TheEdgeType]
>>>> This is exactly the mistake I refer to. Now define your operations on
>>>> the data type. What do those operations (the important bits) say about
>>>> nodes and edges?
>>>>
>>> There is no meaningful isomorphism that I can repeatedly apply to
>>> Graph[Node, Edge] to get a Graph[Edge, Node] and then apply again to get
>>> back to the original graph. The nodes and edges play distinct roles. Naming
>>> them after these roles is useful documentation for the user.
>>>
>>>
>>>> Exactly, nothing, nothing at all
>>>
>>> It tells me a great deal about the graph API. It doesn't tell me anything
>>> about the specific choices of concrete types for Node/Edge, but that is not
>>> what type parameter names are for. It tells me what role they play in the
>>> graph, which is what type parameter names are for.
>>>
>>>
>>>> -- now you're stuck in
>>>> a cognitive quagmire. Please allow me to politely decline your
>>>> invitation.
>>>>
>>> No, now I have a documented type, using nomenclature that people are used
>>> to, where people don't have to constantly look in 2 or 3 places to figure
>>> out if A or B is the type that represents an edge or if it is the type that
>>> represents a node. Most people are not compilers and find it easier if
>>> definitions can be understood with the minimum of needing to correlate
>>> terms with other definitions.
>>>
>>> Honestly, I'm not getting what 'cognitive quagmire' I can fall into by
>>> calling the type in my graph that is being used for nodes Node rather than
>>> naming it A. It's a graph of nodes linked by edges ffs! We should be
>>> calling the node type Node and the edge type Edge. Anything else
>>> is obfuscation.
>>>
>>> Matthew
>>>
>>>
>>>> --
>>>> Tony Morris
>>>> http://tmorris.net/
>>>>
>>>>
>>>>
>>>
>>> --
>>> Dr Matthew Pocock
>>> Integrative Bioinformatics Group, School of Computing Science, Newcastle
>>> University
>>> mailto: turingatemyhamster@gmail.com
>>> gchat: turingatemyhamster@gmail.com
>>> msn: matthew_pocock@yahoo.co.uk
>>> irc.freenode.net: drdozer
>>> skype: matthew.pocock
>>> tel: (0191) 2566550
>>> mob: +447535664143
>>>
>>>
>

2011/11/17 Matthew Pocock <turingatemyhamster@gmail.com>

Yes.... Wouldn't Map[K, V] or Map[Key, Value] be more self-explanatory? Peace.

There will always be people to not catch [K,V] as [Key, Value], and others to not catch what is Key or Value because they just don't know what a Map is (let's say the hereby example is easier than the general case).

All the above IMHO.

Alex

2011/11/17 Michael Schmitz <michael@schmitztech.com>

We already have great entries in the scaladoc about type parameters.

http://www.scala-lang.org/api/current/index.html#scala.collection.Map

Peace.  Michael


2011/11/17 Daniel Sobral <dcsobral@gmail.com>:
> 2011/11/17 √iktor Ҡlang <viktor.klang@gmail.com>:
>>
>>> > trait Graph[Node, Edge] <--- Looks great to me
>>>
>>> Except you just killed Node and Edge as trait/class names. At the very
>>> least, I'd call them ANode and AnEdge.
>>
>> trait Graph[N/*ode*/, E/*dge*/]
>
> Won't show up on Scaladoc, so what's the point? Nope, I still prefer
> ANode and AnEdge. :-)
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
>

--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle University mailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143

--
Alex REPAIN
ENSEIRB-MATMECA - student
TECHNICOLOR R&D - intern
BORDEAUX I      - master's student
SCALA           - enthusiast