Time to encourage meaningful type parameter names? Discuss

PS: Isn't this another -debatey topic?

--
Tony Morris

Tony,
Hi, thanks for the contribution. I'm always aware, when I post topics like this, that perhaps they should be in scala-debate. I try to run my ideas through a filter, which roughly speaking, asks
1) Am I proposing an EASY solution (such as simply lengthening type variable names).2) Does this address a serious perceived problem with Scala (such as the corporate perception that Scala is "too complex")3) Am I proposing something that is closed-ended,in the sense that it will not devolve into (somewhat :-) ) infinite debates over detail. In other words, am I presenting people with an easy choice? The goal of this last point is to avoid flame wars and indefinite posts back to the same subject. Such topics should definitely be in scala-debate.4) Does this address something that I, still a Scala novice, have found to be a genuine problem and believe would be a genuine problem in the broader world. I admit this is a subjective judgement, I do the best I can :-).
I am using myself as a proxy for a "new Scala user". I want Scala to succeed, so I believe that Scala problems that are SERIOUS problems for new users should be discussed in a mainstream group such as scala-user, not in a peripheral group such as scala-debate. I run the above filter on the posts I make to try to ensure that my posts are appropriate to the general Scala user community.
Finally, I monitor the responses to my posts to ensure that I do not generate a useless bunch of messages with no final agreement. For example,I recently asked what the top needs are for Scala to succeed in the enterprise. Obviously there was not complete agreement on this, but a good Eclipse IDE (with the implication that the current Eclipse IDE is till not satisfactory) was a strong result. This was not a surprise, but provides continuing empirical feedback as to what is needed in the Scala ecosystem, which I believe to be valuable.
Sorry for the long answer, but I wanted to explain my rationale for doing what I'm doing. Feel free to post counterarguments.
Cheers,Ken

On Thursday, November 17, 2011 6:51:01 AM UTC-6, 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.

Always there must be balance, young friend. (Yoda waves his light-saber).
OK, a number of people have recommended scala-debate as the proper forum for such ideas. I regard that as the "graveyard of ideas", and I try to put a lot of consideration into what I post so that I don't post about either minor or too-difficult-to-fix ideas. So what is the proper forum to someone who is novice/intermediate to Scala, and wants to post real concerns about the language that, by their own experience, could cause Scala to fail or do poorly? I would suggest that at the moment, there is not an adequate feedback mechanism from the real world as to what Scala needs to do to succeed.
And yes, I want to to succeed. I'm put a lot of time into it already, dagnabit!
Ken

On Thursday, November 17, 2011 6:51:01 AM UTC-6, 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.

Always there must be balance, young friend. (Yoda waves his light-saber).
OK, a number of people have recommended scala-debate as the proper forum for such ideas. I regard that as the "graveyard of ideas", and I try to put a lot of consideration into what I post so that I don't post about either minor or too-difficult-to-fix ideas. So what is the proper forum to someone who is novice/intermediate to Scala, and wants to post real concerns about the language that, by their own experience, could cause Scala to fail or do poorly? I would suggest that at the moment, there is not an adequate feedback mechanism from the real world as to what Scala needs to do to succeed.
And yes, I want to to succeed. I'm put a lot of time into it already, dagnabit!
Ken

Switched responses to -debate.

I think you're using the wrong criteria for -debate vs. -user.  -user is good for things that users care about and which they can employ.  -debate is good for things which need to be discussed and perhaps cannot be employed by users (because e.g. they're changes to the core library, and most users don't recompile their own core library).

On Thu, Nov 17, 2011 at 3:11 PM, Ken McDonald <ykkenmcd@gmail.com> wrote:

1) Am I proposing an EASY solution (such as simply lengthening type variable names).

If it's a proposal for users to use longer type variable names, yes, it's easy.
 

2) Does this address a serious perceived problem with Scala (such as the corporate perception that Scala is "too complex")

It is _related to_ that discussion, I agree, but it is not obvious that it is a _solution_, nor that -users who really just want to give and receive information on how to use Scala would be widely interested.
 

3) Am I proposing something that is closed-ended,in the sense that it will not devolve into (somewhat :-) ) infinite debates over detail. In other words, am I presenting people with an easy choice? The goal of this last point is to avoid flame wars and indefinite posts back to the same subject. Such topics should definitely be in scala-debate.

The topic doesn't pass this criteron.  There is a significant component here that is normally addressed subjectively ("I like long names"), which makes for long debates.  Perhaps you were unaware that long names were disliked by a non-negligible number of people, at least for certain use cases; that's understandable and forgivable.
 

4) Does this address something that I, still a Scala novice, have found to be a genuine problem and believe would be a genuine problem in the broader world. I admit this is a subjective judgement, I do the best I can :-).

It addresses it, but may go the wrong way.  A giant incomprehensible block of text and symbols is no more comprehensible if replaced by an even more giant block (where text and/or symbols have been replaced with longer versions).

Another possible solution is to have a set of links on every collections class to useful resources: "Understanding Collection Types", "Collection Performance", "How to Extend a Collection", etc..

You might then start wishing That were named CB (C meaning "some collection" and B meaning--well, the same B as before), and CanBuildFrom was named Cbf:

  def ++[B >: A](elem: B)(implicit cbf: Cbf[Seq[A],B,CB])

Isn't that easy?  You take Seq[A], add a B to it, and get a CB?*

  def ++[NewElementType >: ExistingType](elem: NewElementType)(implicit cbf: CanBuildFrom[Seq[ExistingType],NewElementType,NewCollectionType])

It's self documenting, yes, but the flow of content has almost entirely been obscured.

Now, in the face of poor documentation, one may wish for the latter form since the type signature is a form of documentation.  (Not a very _good_ form of documentation, but it at least gets you thinking in some of the appropriate directions, while brief version may, to the uninitiated, motivate no thinking at all except WTF?)

But the solution is not to obscure program flow with long type names.  The solution is to provide easily accessible documentation.  If you know what it means, look at it and, presto! all the relevant information leaps out at you in a compact way.  If you don't know what it means, read the documentation, and presto! you can work your way through what is going on.
 

I am using myself as a proxy for a "new Scala user". I want Scala to succeed, so I believe that Scala problems that are SERIOUS problems for new users should be discussed in a mainstream group such as scala-user, not in a peripheral group such as scala-debate.

I appreciate your initiative in bringing up these issues.  But you have to keep in mind as a new user that while your perspective may reflect common problems of new users, your solutions may or may not be the best ones simply because you--thus far--lack the expertise necessary to appreciate the value of other solutions.  So even if your post elicited a whole bunch of "yeah!" and "+1" replies from other users, it wouldn't necessarily follow that your solution was a good one, or that further discussion on -user would lead to a good solution.  It _would_ mean that there was a major source of difficulty out there that should be addressed.

I think the solution is documentation, as I've argued, but I _don't_ think it is obvious that all Scala users really want to listen to and take part in that discussion.

  --Rex

* The downside of CB, of course, is that it makes you imagine that the collection _must_ have something to do with B.  For the majority of CanBuildFrom instances, this is true.  As far as the type constraints go, though, A could be String, B could be Option[Option[Boolean]],  and CB _could_ be Int.  In this sense, "That" is more honest.

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

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.

You're self-evidently not a normal programmer. You care about types and correctness, but normal programmers care about writing the code and think about types afterwards, if at all. I am also not a normal programmer - I care a lot about performance, correctness and scoping/visibility. I've worked with and taught lots of normal programmers, and neither of us are that.  

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.

You've demonstrated no adverse practical implications of using informative names for type parameters - you've just appealed to their existence. Making bare assertions like this is fallacious. Can you show me, using Graph[N, E] as an example where we make incorrect assumptions about it if we think of N as Node and E as Edge, instead of an anonymous [A, B]? 

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.

They become nodes or edges by virtue of their role in the graph. I'm not sure what other possible meaning there is to a node/edge in this context. It's a role they play, not something intrinsic to them. This role still needs naming, and the type parameter is the only place to name it.

Matthew

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

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

"No true Scotsman" fallacy, please try again.

Scala debate is not just for meaningless discussions.  I'm sending this to scala-user so folks understand.

If you want to open a discussion on an idea, scala-debate is perfect for this.  If you have a question on using scala, scala-user is good.

The original email seemed to either be a scala-debate discussion or a scala-internals suggestion.   In either case don't think moving to scala-debate means you're being "silenced".  We just want a place to record these discussions that isn't jumbled with questions like "why doesn't Foo compile"

On Nov 17, 2011 3:11 PM, "Ken McDonald" <ykkenmcd@gmail.com> wrote:

PS: Isn't this another -debatey topic?

--
Tony Morris

Tony,
Hi, thanks for the contribution. I'm always aware, when I post topics like this, that perhaps they should be in scala-debate. I try to run my ideas through a filter, which roughly speaking, asks
1) Am I proposing an EASY solution (such as simply lengthening type variable names).2) Does this address a serious perceived problem with Scala (such as the corporate perception that Scala is "too complex") 3) Am I proposing something that is closed-ended,in the sense that it will not devolve into (somewhat :-) ) infinite debates over detail. In other words, am I presenting people with an easy choice? The goal of this last point is to avoid flame wars and indefinite posts back to the same subject. Such topics should definitely be in scala-debate. 4) Does this address something that I, still a Scala novice, have found to be a genuine problem and believe would be a genuine problem in the broader world. I admit this is a subjective judgement, I do the best I can :-).
I am using myself as a proxy for a "new Scala user". I want Scala to succeed, so I believe that Scala problems that are SERIOUS problems for new users should be discussed in a mainstream group such as scala-user, not in a peripheral group such as scala-debate. I run the above filter on the posts I make to try to ensure that my posts are appropriate to the general Scala user community.
Finally, I monitor the responses to my posts to ensure that I do not generate a useless bunch of messages with no final agreement. For example,I recently asked what the top needs are for Scala to succeed in the enterprise. Obviously there was not complete agreement on this, but a good Eclipse IDE (with the implication that the current Eclipse IDE is till not satisfactory) was a strong result. This was not a surprise, but provides continuing empirical feedback as to what is needed in the Scala ecosystem, which I believe to be valuable.
Sorry for the long answer, but I wanted to explain my rationale for doing what I'm doing. Feel free to post counterarguments.
Cheers,Ken

On 11/18/2011 08:16 AM, Matthew Pocock wrote:

CAHQS_ezL+6AuQPkrwjcQE9VhO9YPQ1HVQBh+NC27rmkFd5qr6w [at] mail [dot] gmail [dot] com" type="cite">

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

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.

You're self-evidently not a normal programmer. You care about types and correctness, but normal programmers care about writing the code and think about types afterwards, if at all. I am also not a normal programmer - I care a lot about performance, correctness and scoping/visibility. I've worked with and taught lots of normal programmers, and neither of us are that.

Come on mate, you can't expect me to accept this. There is no such thing as a "normal programmer." Of course I care about correctness (and therefore types), so does almost every programmer I know -- some just pay lip service to the idea and/or fumble around in the dark -- we all do to some extent.

It is not as if there is some trade; "I am a correctness guy while that other guy is a performance guy" -- WTF kind of nonsense is that? Sounds like something I might see on a recruiters website.

CAHQS_ezL+6AuQPkrwjcQE9VhO9YPQ1HVQBh+NC27rmkFd5qr6w [at] mail [dot] gmail [dot] com" type="cite">  

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.

You've demonstrated no adverse practical implications of using informative names for type parameters - you've just appealed to their existence. Making bare assertions like this is fallacious. Can you show me, using Graph[N, E] as an example where we make incorrect assumptions about it if we think of N as Node and E as Edge, instead of an anonymous [A, B]?

You have named things Node/Edge. This is not a big deal *except you believe that your type parameters have something to do with graph nodes and edges*. You are absolutely wrong. It is not much of a leap to work out what adverse practical implications will happen from there -- you've just got to work out that you are wrong.

CAHQS_ezL+6AuQPkrwjcQE9VhO9YPQ1HVQBh+NC27rmkFd5qr6w [at] mail [dot] gmail [dot] com" type="cite">

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.

They become nodes or edges by virtue of their role in the graph. I'm not sure what other possible meaning there is to a node/edge in this context. It's a role they play, not something intrinsic to them. This role still needs naming, and the type parameter is the only place to name it.

I am not asking you to show me the existence of one (just one, only one) operation that supports your claim for no reason. It's because I know you will fail and it's not just that you will fail, but you will learn why you will fail. Then you will learn why you are wrong, then you will learn what adverse practical implications I allude to.

You're not going to get anywhere by dividing programmers into "us" and "them", unless you accept the division "people who are wrong about one thing" and "people who are not", but of course, this alone leads nowhere.

CAHQS_ezL+6AuQPkrwjcQE9VhO9YPQ1HVQBh+NC27rmkFd5qr6w [at] mail [dot] gmail [dot] com" type="cite">

Matthew

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

--
Dr Matthew Pocock Integrative Bioinformatics Group, School of Computing Science, Newcastle University mailto: turingatemyhamster [at] gmail [dot] com" target="_blank" rel="nofollow">turingatemyhamster@gmail.com gchat: turingatemyhamster [at] gmail [dot] com" target="_blank" rel="nofollow">turingatemyhamster@gmail.com msn: matthew_pocock [at] yahoo [dot] co [dot] uk" target="_blank" rel="nofollow">matthew_pocock@yahoo.co.uk irc.freenode.net: drdozer skype: matthew.pocock tel: (0191) 2566550 mob: +447535664143

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

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

You have named things Node/Edge. This is not a big deal *except you believe that your type parameters have something to do with graph nodes and edges*.

I honestly have no idea what you're driving at. def nodes: Set[Node] is semantically meaningful for a graph as Graph[Node, Edge]. def nodes: Set[Edge] is wrong. def incidentEdges(n: Node): Set[Edge] means something, and the type names are meaningful. The operations *define* what it is to be a graph node and edge. It's a role, not a type. There's no operation to perform on Node or Edge, only operations on Graph[Node, Edge].  

You are absolutely wrong. It is not much of a leap to work out what adverse practical implications will happen from there -- you've just got to work out that you are wrong.

Show me the mistake I'm encouraged to make by thinking of graphs over nodes and edges modelled by the type parameters Node and Edge that I would not make naming these parametrized types A, B.  Matthew

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

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

On 11/18/2011 09:22 AM, Matthew Pocock wrote:

CAHQS_ezbPaYikyKQkTkmKdbZ4iX+aSuFsMqDxokBbLZnOxdJuQ [at] mail [dot] gmail [dot] com" type="cite">
On 17 November 2011 23:11, Tony Morris <tonymorris [at] gmail [dot] com" rel="nofollow">tonymorris@gmail.com> wrote:

You have named things Node/Edge. This is not a big deal *except you believe that your type parameters have something to do with graph nodes and edges*.

I honestly have no idea what you're driving at. def nodes: Set[Node] is semantically meaningful for a graph as Graph[Node, Edge]. def nodes: Set[Edge] is wrong. def incidentEdges(n: Node): Set[Edge] means something, and the type names are meaningful. The operations *define* what it is to be a graph node and edge. It's a role, not a type. There's no operation to perform on Node or Edge, only operations on Graph[Node, Edge].

You keep referring to data types.

Show me *operations* that use these type variables in a way that you claim has a context that exists.

class Graph[Node, Edge] {
  .. this bit
}

CAHQS_ezbPaYikyKQkTkmKdbZ4iX+aSuFsMqDxokBbLZnOxdJuQ [at] mail [dot] gmail [dot] com" type="cite">  

You are absolutely wrong. It is not much of a leap to work out what adverse practical implications will happen from there -- you've just got to work out that you are wrong.

Show me the mistake I'm encouraged to make by thinking of graphs over nodes and edges modelled by the type parameters Node and Edge that I would not make naming these parametrized types A, B.

You're misrepresenting what I already told you is the mistake. Shall I repeat it?

CAHQS_ezbPaYikyKQkTkmKdbZ4iX+aSuFsMqDxokBbLZnOxdJuQ [at] mail [dot] gmail [dot] com" type="cite">   Matthew

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

--
Dr Matthew Pocock Integrative Bioinformatics Group, School of Computing Science, Newcastle University mailto: turingatemyhamster [at] gmail [dot] com" target="_blank" rel="nofollow">turingatemyhamster@gmail.com gchat: turingatemyhamster [at] gmail [dot] com" target="_blank" rel="nofollow">turingatemyhamster@gmail.com msn: matthew_pocock [at] yahoo [dot] co [dot] uk" target="_blank" rel="nofollow">matthew_pocock@yahoo.co.uk irc.freenode.net: drdozer skype: matthew.pocock tel: (0191) 2566550 mob: +447535664143

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

Received and understood.
Ken

> 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.

Granted, but fairly minor (I think) in that I'm trying to encourage discussion about the deeper utility of meaningful names.
Ken 

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).

Sorry Tony, but from a software engineering/maintainability point of view the statement that "type variable names contain no context" is just as crazy as (and no crazier than) the statement that "program variable names contain no context".  Code is intended to be used in a context, not matter how general (but as a general point, usually not too general). Names identify and anchor that context. This is _incredibly_ important to reusable software.
Ken

On Thursday, November 17, 2011 12:45:56 PM UTC-6, Rex Kerr wrote:

On Thu, Nov 17, 2011 at 7:56 AM, Matthew Pocock <turingate...@gmail.com> wrote:

On 17 November 2011 12:11, Tony Morris <tonym...@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.
 

I disagree completely. To you, these extra characters may be unneeded but harmless; to another, they may be vital. This is nothing more than that argument as to whether the loop counter should be n or loopCounter; IMHO, it should clearly be the latter (assuming you must do imperative programming.)
Why the freak are people so opposed to a few extra characters that don't even interfere with reading speed? (Humans read in phrases and words not in characters.)  just don't get it.
Ken 

On 11/18/2011 10:57 AM, Kenneth McDonald wrote:

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).

Sorry Tony, but from a software engineering/maintainability point of view the statement that "type variable names contain no context" is just as crazy as (and no crazier than) the statement that "program variable names contain no context".  Code is intended to be used in a context, not matter how general (but as a general point, usually not too general). Names identify and anchor that context. This is _incredibly_ important to reusable software.
Ken

I will just point out the incredible weakness in your argument. Appealing to "that is crazy" cannot be taken seriously. No need to apologise -- it's not as if this is unusual.

Please think. You will hopefully then realise the transparency of your position. Do you honestly think you are portraying the limit of the depth of introspective thought on this matter? That I have somehow overlooked your constantly repeated position? There is some incredible deep insight being missed in this superficial mode of reasoning? Please allow me to apologise.

Think about the subject please, honestly and thoroughly.

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

>>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). Using A,B,C and so on is a way to force the API user to know his tool, to understand it, and to RTFDocumentation - of course yes, you'd better document your code if it uses >>abstract {type names} or value names. 
I don't normally condemn things out of hand, but this is simply the worst idea I've ever encountered in Comp. Sci. Literally, over 20 years of experience. Why not require that every function name be the min number of characters to uniquely represent it--that will certainly force programmers to read the f&*ckin API.
Where the h%^ll did this idea come from?
Ken

> Where the h%^ll did this idea come from?
You wonder where one-letter identifiers are constantly coming from ? Just go to arxiv.org and open any random math paper. 
You won't see any identifiers longer than 3 characters, but they are doing pretty good job with them for the last couple hundred of years :-)



On Thu, Nov 17, 2011 at 5:14 PM, Kenneth McDonald <ykkenmcd@gmail.com> wrote:

>>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). Using A,B,C and so on is a way to force the API user to know his tool, to understand it, and to RTFDocumentation - of course yes, you'd better document your code if it uses >>abstract {type names} or value names. 
I don't normally condemn things out of hand, but this is simply the worst idea I've ever encountered in Comp. Sci. Literally, over 20 years of experience. Why not require that every function name be the min number of characters to uniquely represent it--that will certainly force programmers to read the f&*ckin API.
Where the h%^ll did this idea come from?
Ken

On Thursday, November 17, 2011 1:59:55 PM UTC-6, Tony Morris wrote:

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.

Tony, you are not an the same galactic quadrant as a normal programmer. If I were a hiring manager evaluating you, I would put checks beside "brilliant", "highly productive", and some other related checkboxes, and then put in "reason for decline": "Not able to work effectively as part of a normal team."
Maybe I'm wrong. But everything I've seen about you on the net indicates both that you are probably worth about 10 normal programmers, and at the same time the code you produce would be completely unsupportable.
Ken

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]

-- Erik

I think I actually posted something about this in my original post. One of my points was (If I recall), are we not past the point where single-char type params are valuable?
Ken 

On 11/18/2011 11:20 AM, Kenneth McDonald wrote:

On Thursday, November 17, 2011 1:59:55 PM UTC-6, Tony Morris wrote:

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.

Tony, you are not an the same galactic quadrant as a normal programmer. If I were a hiring manager evaluating you, I would put checks beside "brilliant", "highly productive", and some other related checkboxes, and then put in "reason for decline": "Not able to work effectively as part of a normal team."

You're just making more shit up dude. How on earth do you know this? I can absolutely guarantee you this wouldn't happen -- I have never got anywhere near this far in an interview with someone who holds these narrow-minded views.

Here is a funny story. I was once asked to "reverse a list in any programming language." The interview was for C# programming.

I said, "fold left with cons flipped beginning with nil" and I scribbled it in haskell. Here is the equivalent scala:

_.foldLeft(Nil)((a, b) => b :: a)

The interviewer went all ballistic with his departure from reality like you have done. I walked out. You narrow-minded interviewers think you have me on the ropes -- you don't. I won't be bullied like this.

Maybe I'm wrong. But everything I've seen about you on the net indicates both that you are probably worth about 10 normal programmers, and at the same time the code you produce would be completely unsupportable.
Ken

You say "completely unsupportable", yet you fail to recognise that this is a property of you, not the code and there is nothing I can do to the code to change it. The very idea that appeasing mediocrity yields some sort of pay-off is perpetuated only by mediocres -- good luck with that, but it's bullshit.

I especially love the quality of arguments presented for your position so far.

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

On Nov 17, 5:29 pm, Tony Morris wrote:

> Here is a funny story. I was once asked to "reverse a list in any
> programming language." The interview was for C# programming.
>
> I said, "fold left with cons flipped beginning with nil" and I scribbled
> it in haskell. Here is the equivalent scala:
>
> _.foldLeft(Nil)((a, b) => b :: a)

aList.reverse

When do I start? 8^)

Tony, I look forward to your book. I hope to learn a lot from it. But your really are "Sheldon" from "The Big Bang Theory", and I no longer consider it worthwhile to respond to your comments. The story you told about being asked how to to reverse a list in an interview, and your response to the interviewer, only reinforce to me (and I suspect others) how completely off the charts you are. (That's not intended as a compliment or an insult, or perhaps it's intended as both--you choose.)
Farewell,Ken

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 16.11.2011 20:12, schrieb Donald McLean:
> 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
>>
>

So the resultType is a collection, a wrapper, some meta-type, we focus
on, but we could as well focus on the first param:

flatMap [OType, OWrapper] (f: (IType) => GenTraversableOnce [OType])
(implicit bf: CanBuildFrom [List [IType], OType, OWrapper]): OWrapper

is I/O common enough to be used for IN and OUT parameters? Since those
param types are always types, the word `type` is a bit of a redundancy,
isn't it? Let's try dropping it:

flatMap [O, OWrapper] (f: (I) => GenTraversableOnce [O])
(implicit bf: CanBuildFrom [List [I], O, OWrapper]): OWrapper

reversing the initial step, it would look like this (OE:= OutElement):

flatMap [OE, O] (f: (I) => GenTraversableOnce [OE])
(implicit bf: CanBuildFrom [List [I], OE, O]): O

The question is, which abbreviation is strong enough to be identified
easily, and used often enough to get used to it. By now, I learned
following conventions:

* T: used for Type in its abstract beauty, very useful if there is only
one type parameter.
* M: the almighty Monad or something, the Monad deals with
* A, B, C, ...: Actors in the order of their appearance.

I think some conventions might help, but meanwhile I prefer short - very
short - names for type parameters, because I'm a bit used to it. If I
see Some[A, B, That, C], I immediately suspect A, B and C to be
Type-Parameters, but `That` not so much. `That` ist nearly as
informative as `Something` or `Yaknow` - isn't it?

And I think there is no silver bullet naming scheme. In some context, I
and O might have strong associations coupled with them, so that they get
confusing there.

> The story you told about being asked how to to reverse a list in an interview, and your response to the interviewer, only reinforce to me (and I suspect others) how completely off the charts you are
No, its the other way round. If you think that walking away after the interviewer rejects correct answer is inappropriate response, I'm pretty sure there are lots of people here happy to be off your charts.



On Thu, Nov 17, 2011 at 6:47 PM, Kenneth McDonald <ykkenmcd@gmail.com> wrote:

Tony, I look forward to your book. I hope to learn a lot from it. But your really are "Sheldon" from "The Big Bang Theory", and I no longer consider it worthwhile to respond to your comments. The story you told about being asked how to to reverse a list in an interview, and your response to the interviewer, only reinforce to me (and I suspect others) how completely off the charts you are. (That's not intended as a compliment or an insult, or perhaps it's intended as both--you choose.)
Farewell,Ken

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.11.2011 11:46, schrieb Matthew Pocock:

comparing these alternatives:

>> 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 ]
>> }

my impression is, that the second alternative is better understandable,
while reading the first time, when you have to understand what is going
on at all. But the first alternative is better readable when you started
working a bit with it, and only need to look up specific details.

It might look better in both cases, if you place the blanks correctly:
outside of the parentheses:

>> 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]
>> }

which is, how it is done in book setting with 500 years of experience in
readability.

Back to the topic: I think this is not something which is subjective or
something based on faith or taste. If you have to read the whole
trait-definition, because it is new for you, you're reading slowly,
token by token, and long lines with line breaks in them aren't
disturbing. But if you later look it up, and try to search something
with the eyes, they fly over the line, and are looking for the
structure, which is much better to get, if there are short and compact
structures.

Which would correspondent with beginners, preferring the second
approach, and people more used to the language preferring the first.

On 11/18/2011 12:47 PM, Kenneth McDonald wrote:
> Tony, I look forward to your book. I hope to learn a lot from it. But
> your really are "Sheldon" from "The Big Bang Theory", and I no longer
> consider it worthwhile to respond to your comments. The story you told
> about being asked how to to reverse a list in an interview, and your
> response to the interviewer, only reinforce to me (and I suspect
> others) how completely off the charts you are. (That's not intended as
> a compliment or an insult, or perhaps it's intended as both--you choose.)
>
> Farewell,
> Ken
Yes, because a very straight-forward and efficient answer is totally
off-the-charts.

By the way, you have a huge selection bias. There really do exist people
who would also give a sensible answer to the question, and also endure
foolishness on behalf of the interviewer.

I suppose we should name our type variables then, because you are not
off the charts amirite?

On 11/18/2011 01:13 PM, Artem Khodyush wrote:

CAPtAsdiRb371NnZfDOTKxrni4khstWsuZdvJCm3ZTCEShuNqZA [at] mail [dot] gmail [dot] com" type="cite">
> The story you told about being asked how to to reverse a list in an interview, and your response to the interviewer, only reinforce to me (and I suspect others) how completely off the charts you are
No, its the other way round. If you think that walking away after the interviewer rejects correct answer is inappropriate response, I'm pretty sure there are lots of people here happy to be off your charts.

Oh woops, now there are two of us!

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

On Nov 17, 7:13 pm, Artem Khodyush wrote:
> > The story you told about being asked how to to reverse a list in an
>
> interview, and your response to the interviewer, only reinforce to me (and
> I suspect others) how completely off the charts you are
>
> No, its the other way round. If you think that walking away after the
> interviewer rejects correct answer
> is inappropriate response, I'm pretty sure there are lots of people here
> happy to be off your charts.

Based on the information given I'd say that walking away in disgust is
not necessarily the best move in all such cases. What if it's a great
company but the interviewer just happens to be a jerk? I can't imagine
that interviewers are always the top talent at any company. What if
you really need the job? Wouldn't it make more sense to politely
explain the correctness of your answer to the interviewer?

--Russ P.

> What if it's a great company but the interviewer just happens to be a jerk? > I can't imagine that interviewers are always the top talent at any company.
Well it of course depends on how high (or low) you value yourself. But if the company tolerates people who don't behave professionally when doinginterviews (are being jerks, in other words), that's not a good sign.


On Thu, Nov 17, 2011 at 7:40 PM, Russ P. <russ.paielli@gmail.com> wrote:

On Nov 17, 7:13 pm, Artem Khodyush <green...@gmail.com> wrote:
> > The story you told about being asked how to to reverse a list in an
>
> interview, and your response to the interviewer, only reinforce to me (and
> I suspect others) how completely off the charts you are
>
> No, its the other way round. If you think that walking away after the
> interviewer rejects correct answer
> is inappropriate response, I'm pretty sure there are lots of people here
> happy to be off your charts.

Based on the information given I'd say that walking away in disgust is
not necessarily the best move in all such cases. What if it's a great
company but the interviewer just happens to be a jerk? I can't imagine
that interviewers are always the top talent at any company. What if
you really need the job? Wouldn't it make more sense to politely
explain the correctness of your answer to the interviewer?

--Russ P.

On 11/18/2011 12:47 PM, Kenneth McDonald wrote:
> Tony, I look forward to your book. I hope to learn a lot from it. But
> your really are "Sheldon" from "The Big Bang Theory", and I no longer
> consider it worthwhile to respond to your comments. The story you told
> about being asked how to to reverse a list in an interview, and your
> response to the interviewer, only reinforce to me (and I suspect
> others) how completely off the charts you are. (That's not intended as
> a compliment or an insult, or perhaps it's intended as both--you choose.)
>
> Farewell,
> Ken

PS: you might also like to know that your pseudo-psychological analysis,
likely influenced by pop culture while simultaneously having nothing to
do with reality, has real-life adverse impact on others. Just so you
know; something to think about, if you're into that. Thinking that is.
Try it.

On 11/18/2011 01:40 PM, Russ P. wrote:
> On Nov 17, 7:13 pm, Artem Khodyush wrote:
>>> The story you told about being asked how to to reverse a list in an
>> interview, and your response to the interviewer, only reinforce to me (and
>> I suspect others) how completely off the charts you are
>>
>> No, its the other way round. If you think that walking away after the
>> interviewer rejects correct answer
>> is inappropriate response, I'm pretty sure there are lots of people here
>> happy to be off your charts.
> Based on the information given I'd say that walking away in disgust is
> not necessarily the best move in all such cases. What if it's a great
> company but the interviewer just happens to be a jerk? I can't imagine
> that interviewers are always the top talent at any company. What if
> you really need the job? Wouldn't it make more sense to politely
> explain the correctness of your answer to the interviewer?
>
> --Russ P.

Walking away due to poor prognosis of making sense is distinct to
walking away in disgust.

It's not always emotional dude, promise. Sometimes it's just what makes
a bit of fucking sense.

On 11/18/2011 01:40 PM, Russ P. wrote:
> On Nov 17, 7:13 pm, Artem Khodyush wrote:
>>> The story you told about being asked how to to reverse a list in an
>> interview, and your response to the interviewer, only reinforce to me (and
>> I suspect others) how completely off the charts you are
>>
>> No, its the other way round. If you think that walking away after the
>> interviewer rejects correct answer
>> is inappropriate response, I'm pretty sure there are lots of people here
>> happy to be off your charts.
> Based on the information given I'd say that walking away in disgust is
> not necessarily the best move in all such cases. What if it's a great
> company but the interviewer just happens to be a jerk? I can't imagine
> that interviewers are always the top talent at any company. What if
> you really need the job? Wouldn't it make more sense to politely
> explain the correctness of your answer to the interviewer?
>
> --Russ P.

I should note that I did, in fact, explain how the solution works, but
when you are up against people who have difficulty divorcing themselves
from the idea of making up stupid shit and resort to unintentional
bullying in order to give themselves the illusion of the legitimacy of
their position, you must make a prognostic assessment about the
effectiveness of continuing.

Many interviewers think they have some kind of upper-hand by virtue of
being the interviewer. They don't; it's an illusion. I certainly don't
want to be working with immutable idiocy or bullies.

Knowledge is not for everyone. Pick your battles.

On Thu, Nov 17, 2011 at 7:13 PM, Artem Khodyush <greenkaa@gmail.com> wrote:

No, its the other way round. If you think that walking away after the interviewer rejects correct answer is inappropriate response

We lack context to determine if the answer was correct. If the question specified that the answer should be provided in a language other than Haskell, then the answer is indeed incorrect.
At any rate, the interviewer should certainly not go ballistic over this, acknowledge that the answer is technically correct and then press on for the candidate to write it again in one of the expected languages.
I would certainly walk out of any interview where the interviewer goes ballistic on me, regardless of the topic being discussed, but then again, I'm not surprised to hear (again) this anecdote coming from Tony.
-- Cédric

 

On Thu, Nov 17, 2011 at 8:02 PM, Kenneth McDonald <ykkenmcd@gmail.com> wrote:

On Thursday, November 17, 2011 12:45:56 PM UTC-6, Rex Kerr wrote:

On Thu, Nov 17, 2011 at 7:56 AM, Matthew Pocock <turingate...@gmail.com> wrote:

On 17 November 2011 12:11, Tony Morris <tonym...@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.
 

I disagree completely. To you, these extra characters may be unneeded but harmless; to another, they may be vital.

Anyone who doesn't know that graphs are made up of nodes and edges should stay far, far away from a graph library until they take some graph theory.
 

This is nothing more than that argument as to whether the loop counter should be n or loopCounter; IMHO, it should clearly be the latter (assuming you must do imperative programming.)

Yes, this is very similar.  The extra ten characters are just visual clutter.  Which is easier to understand at a glance:
  for (n <- 1 to 10) a(n+1) = a(n) + a(n-1)
or
  for (n <- 1 to 10) a(loopCounter+1) = a(loopCounter) + a(loopCounter-1)
 

Why the freak are people so opposed to a few extra characters that don't even interfere with reading speed?

Because they do interfere with reading speed.  I'm not reading "loopCounter" alone, I'm reading a(n+1).  Instead of reading the whole operation, like a*b + c, in one go, I have to parse each word.

I don't object out of some fit of pique.  I object because it gets in the way of grasping the concept quickly, both visually and conceptually.  It's like touch-typing.  You could argue that the keyboard should be laid out ABCDEFG... because it's so much easier for people who look at the keys.  Also, people don't type words, they type letters, so what's the big deal about using one finger at a time?

There is a place for longer variable names, but I don't think index variables or generic types (which serve a similar role) are the place.

  --Rex

On 11/18/2011 02:05 PM, Cédric Beust ♔ wrote:

tL6-wOfskFQYAW+UjRm_cZGobSWMgiYi2g [at] mail [dot] gmail [dot] com" type="cite">
On Thu, Nov 17, 2011 at 7:13 PM, Artem Khodyush <greenkaa [at] gmail [dot] com" rel="nofollow">greenkaa@gmail.com> wrote:

No, its the other way round. If you think that walking away after the interviewer rejects correct answer is inappropriate response

We lack context to determine if the answer was correct. If the question specified that the answer should be provided in a language other than Haskell, then the answer is indeed incorrect.
At any rate, the interviewer should certainly not go ballistic over this, acknowledge that the answer is technically correct and then press on for the candidate to write it again in one of the expected languages.
I would certainly walk out of any interview where the interviewer goes ballistic on me, regardless of the topic being discussed, but then again, I'm not surprised to hear (again) this anecdote coming from Tony.
--  Cédric

 

The context, as originally stated, was to reverse a list in any programming language.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.11.2011 15:47, schrieb Matthew Pocock:
> Hi,
>
> Agreed. I have type parameters rendered in italic and type alases as
> italic+bold in intellij idea. I'm not a fan of Christmas-tree highlighting,
> but this seems to help.

+1 for Christmas-tree highlighting :) (let's abbr. it to CTH).

Maybe we should start a feature request for jline, for CTH in the REPL.

On Thu, Nov 17, 2011 at 11:22:38PM +0000, Matthew Pocock wrote:
> Show me the mistake I'm encouraged to make by thinking of graphs over nodes
> and edges modelled by the type parameters Node and Edge that I would not
> make naming these parametrized types A, B.

I don't want to put words in Tony's mouth but I will try to explain
what I think he is getting at.

Let's say you've written a class like so:

class DirectedGraph[Node, Edge](nodes:Set[Node], edges:Set[Edge]) {
...
def hasEdge(src:Node, dst:Node): Boolean = ...
}

(You could argue that you only need the edges in the constructor... it
doesn't really make a difference for this example.)

The point is, how do you implement hasEdge? Clearly we know that any
type representing an edge in a directed graph needs to store two nodes:
a source and a destination. But our type parameter allows us to pass
*any* type as "Edge". Graph[Int, Int] is a seemingly valid type (the
type system permits it and it would compile) but I don't see any
obvious way to use Int as an edge, especially with a totally
independent Node type parameter.

If you are stubborn and want to keep using type params but get things
working I think you'll find yourself using context bounds and doing
something like this:

trait Node
trait Edge[NodeType <: Node] {
val src:NodeType
val dst:NodeType
def equiv(src2:NodeType, dst2:NodeType) = src == src2 && dst == dst2
}
class Graph[NodeType <: Node, EdgeType <: Edge[NodeType]](nodes:Set[NodeType], edges:Set[EdgeType]) {
...
def hasEdge(src:NodeType, dst:NodeType): Boolean = {
edges.filter(_.equiv(src, dst)).isEmpty
}
}

...or something like this.

The point is that the whole example of a graph with type parameters for
nodes and edges is totally confused. Generic type parameters are
defined or explicated by the constraints put on them. "Node" and "Edge"
are useful descriptors for the constraints that make guarantees about
node/edge behavior (for example, the type which guarantees that edges
have a src node and dst node). I have a hard time imagining someone
seeing "NodeType <: Node" and finding it less confusing than something
like "T <: Node".

In the graph case, the type parameter doesn't really give you anything
over a normal OO graph example. If anything, a type parameter should be
used to give nodes a "payload" (e.g. a number, a string, and object)
that is stored in the graph. Here's a naive example of what I mean:

case class Node[T](payload:T)
case class Edge[T](src:Node[T], dst:Node[T])
case class Graph[T](nodes:Set[T], edges:Set[T]) {
def hasNode(node:Node[T]) = nodes.contains(node)
def hasEdge(src:Node[T], dst:Node[T]) = edges.contains(Edge(src, dst))
...
}

Since graphs are a data structure for storing data (like List) it makes
sense to me that you'd want to define Graph[T], not Graph[N, E]. I
think this is why Tony was asking you to provide the graph
implementation--because once you start it quickly seems incoherent.
Maybe you imagined something other than the examples I provided--I
can't imagine it making sense, but maybe I have missed the point
instead.

There are lots of examples of OO graph implementations as well as a
Scala implementation using inner types, so it should be easy to compare
those to an approach using something like Graph[Node, Edge].

Hope this was helpful. I'm certainly not saying either of my
implementations is the "only way to do it" but I think this is the
point that Tony and others were trying to make.

Guys,  it seems The utility of this discussion has declined.   Let's refrain from bloodying noses by continuing in the current vein.

I'll throw something out there.

Type parameters *are parameters *  just like method parameters.   If you think method parameters require a certain naming style, it is probably worthwhile to use this on type parameters.

If a type parameter looks like a class/type, that's similar to a method parameter looking like a member / term.   Notice the adjustments to the unofficial style guide for this.

On Nov 17, 2011 11:39 PM, "Stefan Wagner" <hirnstrom@arcor.de> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.11.2011 15:47, schrieb Matthew Pocock:
> Hi,
>
> Agreed. I have type parameters rendered in italic and type alases as
> italic+bold in intellij idea. I'm not a fan of Christmas-tree highlighting,
> but this seems to help.

+1 for Christmas-tree highlighting :) (let's abbr. it to CTH).

Maybe we should start a feature request for jline, for CTH in the REPL.

- --

Tschööö--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7F4PMACgkQQeATqGpDnRoELQCfezBzGfJJXzN6smxmSJM9ud0x
0OIAn3ztlqT82q4L9syY5Xh4n8lPn2j3
=2sEO
-----END PGP SIGNATURE-----

> Type parameters *are parameters *  just like method parameters
Yes and no. Method parameters have a type, type parameterscan have constraints but often don't.
A type parameter without constraints is like a method parameter of type 'Any'. When you are trying to assign meaningful names  to them you end up doing something like
def substring(str: Any, startPos: Any, endPos: Any)
which is good indicator that you are doing something wrong.


On Thu, Nov 17, 2011 at 8:55 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Guys,  it seems The utility of this discussion has declined.   Let's refrain from bloodying noses by continuing in the current vein.

I'll throw something out there.

Type parameters *are parameters *  just like method parameters.   If you think method parameters require a certain naming style, it is probably worthwhile to use this on type parameters.

If a type parameter looks like a class/type, that's similar to a method parameter looking like a member / term.   Notice the adjustments to the unofficial style guide for this.

On Nov 17, 2011 11:39 PM, "Stefan Wagner" <hirnstrom@arcor.de> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.11.2011 15:47, schrieb Matthew Pocock:
> Hi,
>
> Agreed. I have type parameters rendered in italic and type alases as
> italic+bold in intellij idea. I'm not a fan of Christmas-tree highlighting,
> but this seems to help.

+1 for Christmas-tree highlighting :) (let's abbr. it to CTH).

Maybe we should start a feature request for jline, for CTH in the REPL.

- --

Tschööö--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7F4PMACgkQQeATqGpDnRoELQCfezBzGfJJXzN6smxmSJM9ud0x
0OIAn3ztlqT82q4L9syY5Xh4n8lPn2j3
=2sEO
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.11.2011 23:16, schrieb Matthew Pocock:

> You're self-evidently not a normal programmer. You care about types and
> correctness, but normal programmers care about writing the code and think
> about types afterwards, if at all.

Then I'm not a normal programmer too. You can't seriously think, that
paramters match for 'normal' programmers accidentally, do you?

> They become nodes or edges by virtue of their role in the graph. I'm not
> sure what other possible meaning there is to a node/edge in this context.
> It's a role they play, not something intrinsic to them. This role still
> needs naming, and the type parameter is the only place to name it.

That makes much more sense than to me, than the first paragraph.
Although - if Tony rejects such claims, my experience so far tells me,
that he does so with good reason.

Last year, I tried to solve the 99-scala-puzzles, which contained a
section of interesting tree-puzzles. As a *normal* programmer, who
didn't study informatics, I wasn't bored, because I hadn't much to do
with trees before, while programming. To solve the puzzles, I didn't
needed an Edge-class/-trait. My key element was a trait LR, which was
named LeftRight in the beginning, but I used it so often, that I rapidly
shortened the name to LR.
With l: Option[LR] and r: Option[LR] I defined the methods 'depth',
'preorder', 'inorder' and 'postorder', but while implementing, most of
the intermediate LRs vanished to nowhere. I didn't have an Edge, but a
case class Node and Leaf and object Node.

My abstract classs Tree extended LR, but used LR very rarely.

The complicated thing about it was the inheritance question; the
signature was:

abstract class TTree [+T <% Ordered[T]] extends LR { /...
and part of time I found myself in wild experimenting, how to make that
... compile. There are some T and U which could have been named PAYLOAD
or ELEMENT or E, but T seemed appropriate as well, and after T, there
comes U. Now I look at them, and they have no meaning, beside being the
content, which is put into that Tree.

LR is of course something like a Node, but I use it as a trait, not as a
type declaration. In the end, it is only the payload, which is encoded
by a Type-identifier (T, U) which has nearly no meaning.

It is like the Banana in the List of Bananas - the Banana doesn't help
in understanding the List.

Type parameters have kinds.  Method parameters have types.   I don't see any value to your logic.

This is like saying if I accept a method of type Any,  then its name is meaningless.

On Nov 18, 2011 12:15 AM, "Artem Khodyush" <greenkaa@gmail.com> wrote:

> Type parameters *are parameters *  just like method parameters
Yes and no. Method parameters have a type, type parameterscan have constraints but often don't.
A type parameter without constraints is like a method parameter of type 'Any'. When you are trying to assign meaningful names  to them you end up doing something like
def substring(str: Any, startPos: Any, endPos: Any)
which is good indicator that you are doing something wrong.


On Thu, Nov 17, 2011 at 8:55 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Guys,  it seems The utility of this discussion has declined.   Let's refrain from bloodying noses by continuing in the current vein.

I'll throw something out there.

Type parameters *are parameters *  just like method parameters.   If you think method parameters require a certain naming style, it is probably worthwhile to use this on type parameters.

If a type parameter looks like a class/type, that's similar to a method parameter looking like a member / term.   Notice the adjustments to the unofficial style guide for this.

On Nov 17, 2011 11:39 PM, "Stefan Wagner" <hirnstrom@arcor.de> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.11.2011 15:47, schrieb Matthew Pocock:
> Hi,
>
> Agreed. I have type parameters rendered in italic and type alases as
> italic+bold in intellij idea. I'm not a fan of Christmas-tree highlighting,
> but this seems to help.

+1 for Christmas-tree highlighting :) (let's abbr. it to CTH).

Maybe we should start a feature request for jline, for CTH in the REPL.

- --

Tschööö--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7F4PMACgkQQeATqGpDnRoELQCfezBzGfJJXzN6smxmSJM9ud0x
0OIAn3ztlqT82q4L9syY5Xh4n8lPn2j3
=2sEO
-----END PGP SIGNATURE-----

On 18 November 2011 04:55, Erik Osheim <erik@plastic-idolatry.com> wrote:

On Thu, Nov 17, 2011 at 11:22:38PM +0000, Matthew Pocock wrote:
> Show me the mistake I'm encouraged to make by thinking of graphs over nodes
> and edges modelled by the type parameters Node and Edge that I would not
> make naming these parametrized types A, B.

 

Let's say you've written a class like so:

 class DirectedGraph[Node, Edge](nodes:Set[Node], edges:Set[Edge]) {
   ...
   def hasEdge(src:Node, dst:Node): Boolean = ...
 }

(You could argue that you only need the edges in the constructor... it
doesn't really make a difference for this example.)

The point is, how do you implement hasEdge?

Well, you can't with that concrete implementation of a directed graph. You could, however, implement it with:

class DirectedGraph[Node, Edge](nodes: Set[Node], edges: Map[Edge, (Node, Node)]) {
  ...
}

If you model the graph like this, the nodes and edges can be any type, as it is the graph instance that is entirely responsible for storing the graph's topology. I'm not claiming that this is an efficient, or even a desirable way to represent a directed graph, but it will work. All queries about the topology must be answered by refering to the Graph instance. Different graphs over the same node and edge instances may return different answers, just as the question: who is your mother? is different for different people. Having topology associated directly with nodes or edges would be like having a Map implementation where the key knew its value.
 

Clearly we know that any
type representing an edge in a directed graph needs to store two nodes:
a source and a destination.

Usually, I want to be able to generate many graphs over the same node and edge instances (or perhaps unique node/edge labels?). So, let's re-write the above type to reflect the labelled nature of the graph and introduce some qua types:

class DirectedGraph[NodeLabel, EdgeLabel](...) {
  type Node = { ... some operations that capture the enclosing graph instance, so we can say e.g. node.incidentEdges
                       def label: NodeLabel
                     }
  type Edge = { ... some operations that capture the enclosing graph instance, so we can say e.g. edge.from, edge.to
                       def label: EdgeLabel
                    }
}

It's personal preference as to if you like working with the qua instances or always operate via the graph.
 

If you are stubborn and want to keep using type params but get things
working I think you'll find yourself using context bounds and doing
something like this:

 trait Node
 trait Edge[NodeType <: Node] {
   val src:NodeType
   val dst:NodeType
   def equiv(src2:NodeType, dst2:NodeType) = src == src2 && dst == dst2
 }
 class Graph[NodeType <: Node, EdgeType <: Edge[NodeType]](nodes:Set[NodeType], edges:Set[EdgeType]) {
   ...
   def hasEdge(src:NodeType, dst:NodeType): Boolean = {
    edges.filter(_.equiv(src, dst)).isEmpty
   }
 }

...or something like this.

Yeah, I've seen this a lot. It's nasty. I've never managed to make any API like this scale to large datasets or many persistent operations.

Hope this was helpful. I'm certainly not saying either of my
implementations is the "only way to do it" but I think this is the
point that Tony and others were trying to make.

Then I think the point was lost due to mutual incomprehension - I had assumed the graph was modeled as a type-class where instances of this type-class contained all the knowledge about the topology of the graph and no knowledge is stored directly on the nodes or edges.

Matthew
 

That's odd - Map[A, B] extends A => B. Thinking about K's and V's might have blinded you to that fact

Date: Thu, 17 Nov 2011 19:59:41 +0000
Subject: Re: [scala-debate] Re: [scala-user] Time to encourage meaningful type parameter names? Discuss
From: turingatemyhamster@gmail.com

The Map data structure is intrinsically associated with the concept of a data structure that represents some key instances drawn from a key set conforming to a Key type that 'map to' some value instances drawn from a value set/bag conforming to a Value type

On Fri, Nov 18, 2011 at 10:31 AM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

That's odd - Map[A, B] extends A => B. Thinking about K's and V's might have blinded you to that fact

Why did you choose A and B there?  A and B don't scream out "function" to me.  Function1 uses T1 and R.  Map[K,V] extends K => V is equally informative.  If you had Map[T1,R], that might provoke some serious head-scratching--T1?  R?  What?  Why are they named _that_ way instead of something obvious or utterly generic?

But the real drawback is that the fraction of time you care that Map extends Function1 is small compared to the fraction of the time that you care where the key is and where the value is.

It's not like names have no point at all.  We forget things; if we always remembered, we wouldn't need type checking.  Otherwise, we could just declare

abstract class A[B] {
  def b[C](c: B => C): A[C]
  def e(f: B): B
  def g[D](h: D)(i: B => D): D
}

which one can figure out uses for by pondering the type signatures.  Just because one can take the opposite approach of overly-long and overly-specific names and end up with something even more atrocious (to my mind):

abstract class WrapperForSomethingThatMayNotExist[TypeOfThingThatMayNotExist] {
  def transformWithFunctionIfPresent(
    transformerFunction: TypeOfThingThatMayNotExist => TypeToTransformTo
  ): WrapperForSomethingThatMayNotExist[TypeToTransformTo]
  def getWrappedObjectIfPresentOrDefaultIfNot(
    defaultValue: TypeOfThingThatMayNotExist
  ): TypeOfThingThatMayNotExist
  def getTransformedValueIfThingExistsOrDefaultIfNot[TypeOfThingToTransformToOrReturn] (
    defaultValue: TypeOfThingToMapToOrReturn
  ) (
    transformerFunction: TypeOfThingThatMayNotExist => TypeOfThingToTransformToOrReturn
  ): TypeOfThingToTransformToOrReturn
}

does not mean that meaningless names are ideal.

Compact but mnemonically useful names are the way to go.

  --Rex
 

Date: Thu, 17 Nov 2011 19:59:41 +0000
Subject: Re: [scala-debate] Re: [scala-user] Time to encourage meaningful type parameter names? Discuss
From: turingatemyhamster@gmail.com

The Map data structure is intrinsically associated with the concept of a data structure that represents some key instances drawn from a key set conforming to a Key type that 'map to' some value instances drawn from a value set/bag conforming to a Value type

On 17.11.2011 15:03, √iktor Ҡlang wrote:
> "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

Since it's convention to have type names start with an upper case
letter, and variables (and function parameters) with a lower case
letter, and type parameters being one or two or maybe three upper case
letters, a quick glance at the above would lead me (at least) to think
that Node and Edge are types instead of type parameters. And since that
doesn't make sense in the context, there might be some initial cognitive
dissonance - at least there was for me. :)

I think

trait Graph[nodeType, edgeType]

is more readable.

Knut Arne Vedaa

On Thu, Nov 17, 2011 at 9:53 AM, Knut Arne Vedaa <kavedaa@gmail.com> wrote:

I think

trait Graph[nodeType, edgeType]

is more readable.

Argh, now they look like regular variables, not something to do with types!

trait Graph[NODE, EDGE]

is visually annoying, but the intent should be unambiguous.

  --Rex

> This is like saying if I accept a method of type Any,  then its name is meaningless.
Yes it is meaningless because you can't do anything meaningful with Any. To beginwith, there aren't that many useful methods that take Any. Let's look at one:
 override def equals(that: Any) = that match { ...
 } 

Note how it's immediately begins with the code that figures out at run time what 'that' means, and you can make a good guess what the code doesbased on the method name, but parameter name is utterly irrelevant.
The same goes for unconstrained type parameters - there are alwaysbetter and explicit ways to express their meaning than encoding it innames and hoping for people to follow conventions.


 , exceptfor calling methods like equals, toString, and hashCode, defined by mistake in the root object. In fact, ideally there should't be any value of type Any mentioned in statically checked program.
Types, on the other hand, 
On Fri, Nov 18, 2011 at 5:55 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Type parameters have kinds.  Method parameters have types.   I don't see any value to your logic.

This is like saying if I accept a method of type Any,  then its name is meaningless.

On Nov 18, 2011 12:15 AM, "Artem Khodyush" <greenkaa@gmail.com> wrote:

> Type parameters *are parameters *  just like method parameters
Yes and no. Method parameters have a type, type parameterscan have constraints but often don't.
A type parameter without constraints is like a method parameter of type 'Any'. When you are trying to assign meaningful names  to them you end up doing something like
def substring(str: Any, startPos: Any, endPos: Any)
which is good indicator that you are doing something wrong.


On Thu, Nov 17, 2011 at 8:55 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Guys,  it seems The utility of this discussion has declined.   Let's refrain from bloodying noses by continuing in the current vein.

I'll throw something out there.

Type parameters *are parameters *  just like method parameters.   If you think method parameters require a certain naming style, it is probably worthwhile to use this on type parameters.

If a type parameter looks like a class/type, that's similar to a method parameter looking like a member / term.   Notice the adjustments to the unofficial style guide for this.

On Nov 17, 2011 11:39 PM, "Stefan Wagner" <hirnstrom@arcor.de> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.11.2011 15:47, schrieb Matthew Pocock:
> Hi,
>
> Agreed. I have type parameters rendered in italic and type alases as
> italic+bold in intellij idea. I'm not a fan of Christmas-tree highlighting,
> but this seems to help.

+1 for Christmas-tree highlighting :) (let's abbr. it to CTH).

Maybe we should start a feature request for jline, for CTH in the REPL.

- --

Tschööö--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7F4PMACgkQQeATqGpDnRoELQCfezBzGfJJXzN6smxmSJM9ud0x
0OIAn3ztlqT82q4L9syY5Xh4n8lPn2j3
=2sEO
-----END PGP SIGNATURE-----

Oops sorry I send almost finished draft - please ignore the last paragraph whichstarts with a comma and does not make sense anyway.

On Fri, Nov 18, 2011 at 9:25 AM, Artem Khodyush <greenkaa@gmail.com> wrote:

> This is like saying if I accept a method of type Any,  then its name is meaningless.
Yes it is meaningless because you can't do anything meaningful with Any. To beginwith, there aren't that many useful methods that take Any. Let's look at one:
 override def equals(that: Any) = that match { ...
 } 

Note how it's immediately begins with the code that figures out at run time what 'that' means, and you can make a good guess what the code doesbased on the method name, but parameter name is utterly irrelevant.
The same goes for unconstrained type parameters - there are alwaysbetter and explicit ways to express their meaning than encoding it innames and hoping for people to follow conventions.


 , exceptfor calling methods like equals, toString, and hashCode, defined by mistake in the root object. In fact, ideally there should't be any value of type Any mentioned in statically checked program.
Types, on the other hand, 
On Fri, Nov 18, 2011 at 5:55 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Type parameters have kinds.  Method parameters have types.   I don't see any value to your logic.

This is like saying if I accept a method of type Any,  then its name is meaningless.

On Nov 18, 2011 12:15 AM, "Artem Khodyush" <greenkaa@gmail.com> wrote:

> Type parameters *are parameters *  just like method parameters
Yes and no. Method parameters have a type, type parameterscan have constraints but often don't.
A type parameter without constraints is like a method parameter of type 'Any'. When you are trying to assign meaningful names  to them you end up doing something like
def substring(str: Any, startPos: Any, endPos: Any)
which is good indicator that you are doing something wrong.


On Thu, Nov 17, 2011 at 8:55 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Guys,  it seems The utility of this discussion has declined.   Let's refrain from bloodying noses by continuing in the current vein.

I'll throw something out there.

Type parameters *are parameters *  just like method parameters.   If you think method parameters require a certain naming style, it is probably worthwhile to use this on type parameters.

If a type parameter looks like a class/type, that's similar to a method parameter looking like a member / term.   Notice the adjustments to the unofficial style guide for this.

On Nov 17, 2011 11:39 PM, "Stefan Wagner" <hirnstrom@arcor.de> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.11.2011 15:47, schrieb Matthew Pocock:
> Hi,
>
> Agreed. I have type parameters rendered in italic and type alases as
> italic+bold in intellij idea. I'm not a fan of Christmas-tree highlighting,
> but this seems to help.

+1 for Christmas-tree highlighting :) (let's abbr. it to CTH).

Maybe we should start a feature request for jline, for CTH in the REPL.

- --

Tschööö--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7F4PMACgkQQeATqGpDnRoELQCfezBzGfJJXzN6smxmSJM9ud0x
0OIAn3ztlqT82q4L9syY5Xh4n8lPn2j3
=2sEO
-----END PGP SIGNATURE-----

Thanks for this clear explanation. You convinced me to change an
implementation from Graph[V] to Graph[T]. Even though I don't attempt
an implementation like the one you describe below (Graph[V, E]), I did
often consider V as a vertex instead of the *data that is stored in a
vertex*. It shows in my implementation.

Peace. Michael

On Thu, Nov 17, 2011 at 8:55 PM, Erik Osheim wrote:
> On Thu, Nov 17, 2011 at 11:22:38PM +0000, Matthew Pocock wrote:
>> Show me the mistake I'm encouraged to make by thinking of graphs over nodes
>> and edges modelled by the type parameters Node and Edge that I would not
>> make naming these parametrized types A, B.
>
> I don't want to put words in Tony's mouth but I will try to explain
> what I think he is getting at.
>
> Let's say you've written a class like so:
>
>  class DirectedGraph[Node, Edge](nodes:Set[Node], edges:Set[Edge]) {
>    ...
>    def hasEdge(src:Node, dst:Node): Boolean = ...
>  }
>
> (You could argue that you only need the edges in the constructor... it
> doesn't really make a difference for this example.)
>
> The point is, how do you implement hasEdge? Clearly we know that any
> type representing an edge in a directed graph needs to store two nodes:
> a source and a destination. But our type parameter allows us to pass
> *any* type as "Edge". Graph[Int, Int] is a seemingly valid type (the
> type system permits it and it would compile) but I don't see any
> obvious way to use Int as an edge, especially with a totally
> independent Node type parameter.
>
> If you are stubborn and want to keep using type params but get things
> working I think you'll find yourself using context bounds and doing
> something like this:
>
>  trait Node
>  trait Edge[NodeType <: Node] {
>    val src:NodeType
>    val dst:NodeType
>    def equiv(src2:NodeType, dst2:NodeType) = src == src2 && dst == dst2
>  }
>  class Graph[NodeType <: Node, EdgeType <: Edge[NodeType]](nodes:Set[NodeType], edges:Set[EdgeType]) {
>    ...
>    def hasEdge(src:NodeType, dst:NodeType): Boolean = {
>     edges.filter(_.equiv(src, dst)).isEmpty
>    }
>  }
>
> ...or something like this.
>
> The point is that the whole example of a graph with type parameters for
> nodes and edges is totally confused. Generic type parameters are
> defined or explicated by the constraints put on them. "Node" and "Edge"
> are useful descriptors for the constraints that make guarantees about
> node/edge behavior (for example, the type which guarantees that edges
> have a src node and dst node). I have a hard time imagining someone
> seeing "NodeType <: Node" and finding it less confusing than something
> like "T <: Node".
>
> In the graph case, the type parameter doesn't really give you anything
> over a normal OO graph example. If anything, a type parameter should be
> used to give nodes a "payload" (e.g. a number, a string, and object)
> that is stored in the graph. Here's a naive example of what I mean:
>
>  case class Node[T](payload:T)
>  case class Edge[T](src:Node[T], dst:Node[T])
>  case class Graph[T](nodes:Set[T], edges:Set[T]) {
>    def hasNode(node:Node[T]) = nodes.contains(node)
>    def hasEdge(src:Node[T], dst:Node[T]) = edges.contains(Edge(src, dst))
>    ...
>  }
>
> Since graphs are a data structure for storing data (like List) it makes
> sense to me that you'd want to define Graph[T], not Graph[N, E]. I
> think this is why Tony was asking you to provide the graph
> implementation--because once you start it quickly seems incoherent.
> Maybe you imagined something other than the examples I provided--I
> can't imagine it making sense, but maybe I have missed the point
> instead.
>
> There are lots of examples of OO graph implementations as well as a
> Scala implementation using inner types, so it should be easy to compare
> those to an approach using something like Graph[Node, Edge].
>
> Hope this was helpful. I'm certainly not saying either of my
> implementations is the "only way to do it" but I think this is the
> point that Tony and others were trying to make.
>

On 18/11/2011 01:57, Kenneth McDonald wrote:
> Sorry Tony, but from a software engineering/maintainability point of
> view the statement that "type variable names contain no context" is just
> as crazy as (and no crazier than) the statement that "program variable
> names contain no context". Code is intended to be used in a context, not
> matter how general (but as a general point, usually not too general).
> Names identify and anchor that context. This is _incredibly_ important
> to reusable software.

I have to disagree, at least partially, here. Some software is highly
reusable just because they don't have a context...
I barely know Scalaz, mostly from what I have read here and there, but
my understanding is that it is very abstract, disconnected from specific
domains ("business logic"). Yet people find it very useful, because they
mastered the mechanisms it offers, and find them very useful when
applied to *their* business logic.
Somehow, it seems like a kind of meta-programming, offering tools to be
used in a more specific domain.

I see this kind of tool as highly reusable, yet without identity.
Somehow, it is similar for the collection library.

Of course, you can still name (semi-)abstract stuff, like "the thing we
iterate on", "the type of the cumulated result" or such.
Of course, in some domains, the names can draw on the underlying theory:
nodes and edges in graph theory, key and values in data maps, and so on.
But overall, specific names can get in the way.

Perhaps what is missing from the Scala doc is context. Somehow, it lists
together several methods but description is short, context can be
missing, etc.

I don't think the tradition of one letter type names will go away, but
in a few entries of ScalaDoc I looked at, the types are (succinctly)
explained in the Scala doc itself. So even if the names aren't very
explicit, the doc is here.