Time to encourage meaningful type parameter names? Discuss

On Sun, Nov 20, 2011 at 4:10 PM, Tony Morris <tonymorris@gmail.com> wrote:

Therefore, all you have done is invited me to trust you over the mechanical verifier (I don't),

Why not? You frequently ask us to trust you and take your word for it rather than completing your explanation. :)

On 21/11/11 18:35, Naftoli Gugenheim wrote:
> On Sun, Nov 20, 2011 at 4:10 PM, Tony Morris wrote:
>
>> Therefore, all you have done is invited me to trust you over the
>> mechanical verifier (I don't),
>
> Why not? You frequently ask us to trust you and take your word for it
> rather than completing your explanation. :)
>
Yeah, just as soon as I get done on the hard hard fringe of category theory.

Btw, I think my point (which is that parametricity doesn not
necessarily imply that meaninful names break semantics) is still
valid. "first" was a special case since it has only one (normal form)
inhabitant, but it still applies to a lot of other functions.

Now I'm not especially advocating for such names, I have no opinion on
that matter, I'm just saying invoking parametricity to make the point
that universally quantified type variable names should not convey any
meaning is IMO bogus.

Paul

On Mon, Nov 21, 2011 at 09:35, Naftoli Gugenheim wrote:
>
>
> On Sun, Nov 20, 2011 at 4:10 PM, Tony Morris wrote:
>>
>> Therefore, all you have done is invited me to trust you over the
>> mechanical verifier (I don't),
>
> Why not? You frequently ask us to trust you and take your word for it rather
> than completing your explanation. :)
>

Nobody invoked parametricity as the argument. To be honest, I'm quite
tired of explaining the same thing over and over. Believe what you will,
even if you just make it up. Indulge, go for seconds.

On 21/11/11 18:58, Paul Brauner wrote:
> Btw, I think my point (which is that parametricity doesn not
> necessarily imply that meaninful names break semantics) is still
> valid. "first" was a special case since it has only one (normal form)
> inhabitant, but it still applies to a lot of other functions.
>
> Now I'm not especially advocating for such names, I have no opinion on
> that matter, I'm just saying invoking parametricity to make the point
> that universally quantified type variable names should not convey any
> meaning is IMO bogus.
>
> Paul
>
> On Mon, Nov 21, 2011 at 09:35, Naftoli Gugenheim wrote:
>>
>> On Sun, Nov 20, 2011 at 4:10 PM, Tony Morris wrote:
>>> Therefore, all you have done is invited me to trust you over the
>>> mechanical verifier (I don't),
>> Why not? You frequently ask us to trust you and take your word for it rather
>> than completing your explanation. :)
>>

You're such a drama queen :) I didn't know you before this thread
(though I knew scalaz) but now I will for sure remember your name.

You indeed more or less stick to the point and adhere to some
reasoning discipline when arguing but all your emails end with
something like "i refuse to be bullied" when no-one's "bullying" you,
or "I hope it makes sense to somebody" as if you were the only one on
this mailing list who has a clue. No wonder people react to your
emails in passionate ways. For instance, I was trying to make a polite
(maybe wrong) point and you answer with a somewhat condescendant ("I'm
quite tired of explaining the same thing over and over") when you
could have said "sorry, I think you're wrong, here is why:" or just
have ignored my email if you were "tired".

Sorry if I misread you on parametricity.

Paul

On Mon, Nov 21, 2011 at 10:24, Tony Morris wrote:
> Nobody invoked parametricity as the argument. To be honest, I'm quite
> tired of explaining the same thing over and over. Believe what you will,
> even if you just make it up. Indulge, go for seconds.
>
> On 21/11/11 18:58, Paul Brauner wrote:
>> Btw, I think my point (which is that parametricity doesn not
>> necessarily imply that meaninful names break semantics) is still
>> valid. "first" was a special case since it has only one (normal form)
>> inhabitant, but it still applies to a lot of other functions.
>>
>> Now I'm not especially advocating for such names, I have no opinion on
>> that matter, I'm just saying invoking parametricity to make the point
>> that universally quantified type variable names should not convey any
>> meaning is IMO bogus.
>>
>> Paul
>>
>> On Mon, Nov 21, 2011 at 09:35, Naftoli Gugenheim wrote:
>>>
>>> On Sun, Nov 20, 2011 at 4:10 PM, Tony Morris wrote:
>>>> Therefore, all you have done is invited me to trust you over the
>>>> mechanical verifier (I don't),
>>> Why not? You frequently ask us to trust you and take your word for it rather
>>> than completing your explanation. :)
>>>
>
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

You're such a drama queen. I was just trying to respond in an
informative way. I really am quite tired of it, so I invited you to
humour yourself and perhaps me too. Comedy is much more interesting than
taking this ridiculous topic seriously innit?

Sure, those few doing the bullying were hiding behind a cloak of
pleasant demeanour and a few others even fell for it. I bet you didn't.

Sorry if I misread you on the invitation to join in on a joke.

On 21/11/11 19:46, Paul Brauner wrote:
> You're such a drama queen :) I didn't know you before this thread
> (though I knew scalaz) but now I will for sure remember your name.
>
> You indeed more or less stick to the point and adhere to some
> reasoning discipline when arguing but all your emails end with
> something like "i refuse to be bullied" when no-one's "bullying" you,
> or "I hope it makes sense to somebody" as if you were the only one on
> this mailing list who has a clue. No wonder people react to your
> emails in passionate ways. For instance, I was trying to make a polite
> (maybe wrong) point and you answer with a somewhat condescendant ("I'm
> quite tired of explaining the same thing over and over") when you
> could have said "sorry, I think you're wrong, here is why:" or just
> have ignored my email if you were "tired".
>
> Sorry if I misread you on parametricity.
>
> Paul
>
> On Mon, Nov 21, 2011 at 10:24, Tony Morris wrote:
>> Nobody invoked parametricity as the argument. To be honest, I'm quite
>> tired of explaining the same thing over and over. Believe what you will,
>> even if you just make it up. Indulge, go for seconds.
>>
>> On 21/11/11 18:58, Paul Brauner wrote:
>>> Btw, I think my point (which is that parametricity doesn not
>>> necessarily imply that meaninful names break semantics) is still
>>> valid. "first" was a special case since it has only one (normal form)
>>> inhabitant, but it still applies to a lot of other functions.
>>>
>>> Now I'm not especially advocating for such names, I have no opinion on
>>> that matter, I'm just saying invoking parametricity to make the point
>>> that universally quantified type variable names should not convey any
>>> meaning is IMO bogus.
>>>
>>> Paul
>>>
>>> On Mon, Nov 21, 2011 at 09:35, Naftoli Gugenheim wrote:
>>>> On Sun, Nov 20, 2011 at 4:10 PM, Tony Morris wrote:
>>>>> Therefore, all you have done is invited me to trust you over the
>>>>> mechanical verifier (I don't),
>>>> Why not? You frequently ask us to trust you and take your word for it rather
>>>> than completing your explanation. :)
>>>>
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>

Guys, what is this? Third grade?

On Mon, Nov 21, 2011 at 11:08 AM, Tony Morris <tonymorris@gmail.com> wrote:

You're such a drama queen. I was just trying to respond in an
informative way. I really am quite tired of it, so I invited you to
humour yourself and perhaps me too. Comedy is much more interesting than
taking this ridiculous topic seriously innit?

Sure, those few doing the bullying were hiding behind a cloak of
pleasant demeanour and a few others even fell for it. I bet you didn't.

Sorry if I misread you on the invitation to join in on a joke.


On 21/11/11 19:46, Paul Brauner wrote:
> You're such a drama queen :) I didn't know you before this thread
> (though I knew scalaz) but now I will for sure remember your name.
>
> You indeed more or less stick to the point and adhere to some
> reasoning discipline when arguing but all your emails end with
> something like "i refuse to be bullied" when no-one's "bullying" you,
> or "I hope it makes sense to somebody" as if you were the only one on
> this mailing list who has a clue. No wonder people react to your
> emails in passionate ways. For instance, I was trying to make a polite
> (maybe wrong) point and you answer with a somewhat condescendant ("I'm
> quite tired of explaining the same thing over and over") when you
> could have said "sorry, I think you're wrong, here is why:" or just
> have ignored my email if you were "tired".
>
> Sorry if I misread you on parametricity.
>
> Paul
>
> On Mon, Nov 21, 2011 at 10:24, Tony Morris <tonymorris@gmail.com> wrote:
>> Nobody invoked parametricity as the argument. To be honest, I'm quite
>> tired of explaining the same thing over and over. Believe what you will,
>> even if you just make it up. Indulge, go for seconds.
>>
>> On 21/11/11 18:58, Paul Brauner wrote:
>>> Btw, I think my point (which is that parametricity doesn not
>>> necessarily imply that meaninful names break semantics) is still
>>> valid. "first" was a special case since it has only one (normal form)
>>> inhabitant, but it still applies to a lot of other functions.
>>>
>>> Now I'm not especially advocating for such names, I have no opinion on
>>> that matter, I'm just saying invoking parametricity to make the point
>>> that universally quantified type variable names should not convey any
>>> meaning is IMO bogus.
>>>
>>> Paul
>>>
>>> On Mon, Nov 21, 2011 at 09:35, Naftoli Gugenheim <naftoligug@gmail.com> wrote:
>>>> On Sun, Nov 20, 2011 at 4:10 PM, Tony Morris <tonymorris@gmail.com> wrote:
>>>>> Therefore, all you have done is invited me to trust you over the
>>>>> mechanical verifier (I don't),
>>>> Why not? You frequently ask us to trust you and take your word for it rather
>>>> than completing your explanation. :)
>>>>
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>


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

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Oh come on, this thread has become the joke. Too complex, switching to guns.

On 21/11/11 20:51, √iktor Ҡlang wrote:
> Guys, what is this? Third grade?
>
> On Mon, Nov 21, 2011 at 11:08 AM, Tony Morris wrote:
>
>> You're such a drama queen. I was just trying to respond in an
>> informative way. I really am quite tired of it, so I invited you to
>> humour yourself and perhaps me too. Comedy is much more interesting than
>> taking this ridiculous topic seriously innit?
>>
>> Sure, those few doing the bullying were hiding behind a cloak of
>> pleasant demeanour and a few others even fell for it. I bet you didn't.
>>
>> Sorry if I misread you on the invitation to join in on a joke.
>>
>>
>> On 21/11/11 19:46, Paul Brauner wrote:
>>> You're such a drama queen :) I didn't know you before this thread
>>> (though I knew scalaz) but now I will for sure remember your name.
>>>
>>> You indeed more or less stick to the point and adhere to some
>>> reasoning discipline when arguing but all your emails end with
>>> something like "i refuse to be bullied" when no-one's "bullying" you,
>>> or "I hope it makes sense to somebody" as if you were the only one on
>>> this mailing list who has a clue. No wonder people react to your
>>> emails in passionate ways. For instance, I was trying to make a polite
>>> (maybe wrong) point and you answer with a somewhat condescendant ("I'm
>>> quite tired of explaining the same thing over and over") when you
>>> could have said "sorry, I think you're wrong, here is why:" or just
>>> have ignored my email if you were "tired".
>>>
>>> Sorry if I misread you on parametricity.
>>>
>>> Paul
>>>
>>> On Mon, Nov 21, 2011 at 10:24, Tony Morris wrote:
>>>> Nobody invoked parametricity as the argument. To be honest, I'm quite
>>>> tired of explaining the same thing over and over. Believe what you will,
>>>> even if you just make it up. Indulge, go for seconds.
>>>>
>>>> On 21/11/11 18:58, Paul Brauner wrote:
>>>>> Btw, I think my point (which is that parametricity doesn not
>>>>> necessarily imply that meaninful names break semantics) is still
>>>>> valid. "first" was a special case since it has only one (normal form)
>>>>> inhabitant, but it still applies to a lot of other functions.
>>>>>
>>>>> Now I'm not especially advocating for such names, I have no opinion on
>>>>> that matter, I'm just saying invoking parametricity to make the point
>>>>> that universally quantified type variable names should not convey any
>>>>> meaning is IMO bogus.
>>>>>
>>>>> Paul
>>>>>
>>>>> On Mon, Nov 21, 2011 at 09:35, Naftoli Gugenheim
>> wrote:
>>>>>> On Sun, Nov 20, 2011 at 4:10 PM, Tony Morris
>> wrote:
>>>>>>> Therefore, all you have done is invited me to trust you over the
>>>>>>> mechanical verifier (I don't),
>>>>>> Why not? You frequently ask us to trust you and take your word for it
>> rather
>>>>>> than completing your explanation. :)
>>>>>>
>>>> --
>>>> Tony Morris
>>>> http://tmorris.net/
>>>>
>>>>
>>>>
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>

+1

On 19 November 2011 18:33, Josh Suereth <joshua.suereth@gmail.com> wrote:

People ascribe names to abstract things all the time.   When I say "fire", I may be referring to all my experiences of fire as an abstract concept.  Your mind interrupts it and ascribes the aspects of fire that it knows to the words I am using.
The same is true with names.  To Say that the more abstract a thing, the less important the name is BOGUS, bunk.   WHY oh why to we ascribe silly names to abstract concepts like:
Monad MonoidEigenvectorNullspacemonomorphismJacobian
My opinion is that the more abstract a concept, usually the longer or sillier the name (probably because they're named after the person who first *described* the abstract concept).
You see, if I give something a name and a description, I can start using the name in place of the description.   This is what language is all about. 
Graph[N,V] may be poor, but Graph[NodeData,VertixData] doesn't seem poor to me at all.  Again, I can come up with a class Graph where these names make a *lot* of sense.
Even in the case of "def equals(that: Any): Boolean", we still use "that" or "rhs" instead of "x" or "y", Where "that" refers to "something that is not htis" and "rhs" refers to the right-hand-side of an expression.   These words connote *meaning* and only as much meaning as needed to determine what the variable is doing.

trait TypeFunctor {  type F[x]   def map[X, Y](f: X => Y): F[X] => F[Y]}
To those who don't understand the concepts of functors, these names are pretty poor.  However, if I *document* the concepts I'm using.
/** A type functor is a mapping between two categories of types.   A functor can take any type in the first category and  * map it onto a second category (of still types).  */ trait TypeFunctor {  /** This type constructor is used to map any type from the initial category (of all possible types) into another category    * (that may or may not consist of all types).   * @tparam X  The type to be mapped into the new category    * @return  The type in the second category.   */   type F[X]  /**   *  This method takes  a type morphism (an arrow between points A and B in the initial category.      *  Note: A morphism in types is a function that can convert elements of type A into type B).   *  The type morphism is mapped it into the new category defined by the functor.    *  defined by this functor.   *   *  @tparam A  The initial type of the input morphism.    *  @tparam B  The final type of the input morphism   *  @param f  The morphism (function) that can map elements of type A into type B    *  @returns  A morphism that can take values in the mapped category of this functor.   */   def map[A, B](f: A => B): F[A] => F[B]}
NOW, I've given *descriptions* to my abstract types.   Now when people see "A" and "B" in the context of the class, there's a bit of meaning attached to the names, which are accurate.   When I use "F[?]" in later code, I've defined what F is in my source code, so users can understand it.
Scalaz is the *most* disappointing library in the scala ecosystem due to it's lack of documentation and poor naming choice.  If you wish others to understand an abstract concept, you need to provide a description for that concept.   Until you do so, it's just meaningless gibberish.  Scalaz *still* suffers from this, despite good efforts from some.  Claiming that abstract concepts are "lessened' through good names and documentation is bunk, bogus and disappointing to find.
One *could* argue that the source code is the description used for the name.  I could use this excuse to have horrible names throughout my codebase, even if a well known name was available and would help ease someone's ability to learn the concepts in my library.   I don't buy it.
So, as in all things, *naming* is difficult.   A poor name can convey the *wrong* meaning.   However, conveying *no* meaning is perhaps just as poor.   If you're going to use an abstract name (like X or A) for something, please document a description if possible.    If the variable has no meaning to be conveyed, then why is it in your source code?
Even non-english words like "Oooga Booga" convey some meaning.
- Josh


On Sat, Nov 19, 2011 at 4:46 AM, Philippe Lhoste <PhiLho@gmx.net> wrote:

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.

Hi,

2011/11/20 Kenneth McDonald <ykkenmcd@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. If a person doesn't understand Key/Value (or K/V) because they don't know what a Map is, then they need to find out what a Map is. The issue you're raising in this case isn't with the naming of the type parameters, but that the entire concept modelled by the Map isn't known to the user. Once they understand the Map abstraction, it's much easer for a normal programmer to look at signatures with the type parameters Key/Value (or K/V) than A/B and associate this back to the Map abstraction. Normal people find names and mnemonics easier to remember than random letters. We can find any amount of published literature that demonstrates this experimentally, and probably also papers that specifically dissect out what sub-population this doesn't hold for (hint - this sub-population is not over-represented in that which is also your average programmer, certainly not to the point that you can discard using informative names in APIs aimed at average programmers).

Again, I disagree. At some point I may have to look it up, but basically, it takes no more cognitive processing to understand "Value" as "Value" than it does to understand "V" as "Value". Probably even less. Whereas if you insist on using V as Value, where does that leave the poor graph programmer who would like to use V as Vertex?

I agree with you. I was drawing the distinction between using V or Value as opposed to B for Value. The distinction between using a mnemonic vs a full name is comparatively small compared to using an intentionally meaningless letter. However, I'd agree with you that personally I'd prefer to see the full name.  

The assumption that _your_ domains and ranges should command single-char status is false and harmful.

Agreed, especially if they leak out of my API.
Matthew 

Ken 

--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle University mailto: turingatemyhamster@gmail.comgchat: turingatemyhamster@gmail.com msn: matthew_pocock@yahoo.co.ukirc.freenode.net: drdozerskype: matthew.pocock tel: (0191) 2566550mob: +447535664143

On 20/11/2011 16:25, Josh Suereth wrote:
> [...] So, I,M,O are infinitely better names than A,B,C. I can denote
> more meaning through documentation or through different names. Scalaz
> is an easy library to poke at here because it has a lot of abstract
> concepts that require lots or documentation (scaladocs most likely
> linking to external papers an Wikipedia articles) for the types to
> have definitions in folks heads.
>
> The same issue existed, e.g. in SBT. You need to know to read the
> user's guide wiki to learn how things work. Its documentation does
> not target scaladoc users. That's less frustrating from a build
> tool, but still frustrating. Scalaz is a library. It's custom
> behavior to use scaladocs to learn libraries in Scala. Assuming
> otherwise is silly.
>
> Expect documentation patches from me for the scalaz I use.
>

For what it may worth, I to would love to see in Scalaz's scaladoc
reference to good paper and resources about the implemented concept,
even if it's not anything else. I spent (literally) days to try to
understand some of the scalaz concepts, most of the time reading
not-so-useful papers for sometimes finding the one really helpful. I
mean, you Scalaz people, have a really deep knowledge of that ecosystem,
and it would be very helpful if you could help newcomers finding there
way in that jungle.

On 2011-11-17 13:42:08 -0600, Tony Morris said:

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

Hmm. Why did you choose "c"?

Which one would ease the cognitive burden on the user as they continue
reading the "....." part:

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

or

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

If you agree it is the former, then we are just left with "what string
will make it easier for that user to associate my variable with a Car
... c? ca? car? aCar?).

Personally, I would be OK with

Map[K,V]

IF whenever I looked it up (e.g. in IDE, docs, auto-completion etc.) I
saw something that also said "K is the Key type, and V is the Value
type". Then the short K and V work quite nicely.

But not Map[A,B].

It might be nice if the IDE hover-overs, when they support scaladoc again, also supported the @tparam docs for type parameters....

On Wed, Nov 30, 2011 at 1:16 PM, Sophie <itsme213@hotmail.com> wrote:

On 2011-11-17 13:42:08 -0600, Tony Morris <tmorris@tmorris.net> said:

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.

Hmm. Why did you choose "c"?

Which one would ease the cognitive burden on the user as they continue reading the "....." part:

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

or

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

If you agree it is the former, then we are just left with "what string will make it easier for that user to associate my variable with a Car ... c? ca? car? aCar?).

Personally, I would be OK with
       
       Map[K,V]

IF whenever I looked it up (e.g. in IDE, docs, auto-completion etc.) I saw something that also said "K is the Key type, and V is the Value type". Then the short K and V work quite nicely.

But not Map[A,B].

I chose c because it first pooped into my head. If some other variable name replaced it, then readability is unaffected.

However, the point was to demonstrate that the compulsion to name type variables in ways that they are not, while pretending (even insisting) otherwise is proactively unhelpful and also results in a contradiction and subsequent inconsistency.

On Dec 1, 2011 4:16 AM, "Sophie" <itsme213@hotmail.com> wrote:

On 2011-11-17 13:42:08 -0600, Tony Morris <tmorris@tmorris.net> said:

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.

Hmm. Why did you choose "c"?

Which one would ease the cognitive burden on the user as they continue reading the "....." part:

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

or

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

If you agree it is the former, then we are just left with "what string will make it easier for that user to associate my variable with a Car ... c? ca? car? aCar?).

Personally, I would be OK with
       
       Map[K,V]

IF whenever I looked it up (e.g. in IDE, docs, auto-completion etc.) I saw something that also said "K is the Key type, and V is the Value type". Then the short K and V work quite nicely.

But not Map[A,B].

On Wed, Nov 30, 2011 at 11:48 AM, Tony Morris <tmorris@tmorris.net> wrote:

I chose c because it first pooped into my head.

This must have been very unpleasant.
-- Cédric

2011/11/30 Cédric Beust ♔ <cedric@beust.com>

On Wed, Nov 30, 2011 at 11:48 AM, Tony Morris <tmorris@tmorris.net> wrote:

I chose c because it first pooped into my head.

This must have been very unpleasant.

:-)
 -- Martin 

On 2011-11-30 13:48:43 -0600, Tony Morris said:

>
> I chose c because it first pooped into my head. If some other variable name
> replaced it, then readability is unaffected.

I politely but emphatically disagree. Formal meaning (or lack of it) is
quite different from cognitive burden. Human brains are not computers
or compilers. Programming, especially the bit around trying to grok
unfamiliar code, is about much more than formal symbol table lookup.

Otherwise the entire code obfuscation industry would be spectacularly
redundant :-)

The real question is, can a human obfuscate code better than a machine?  I think so.
My favorite read from my C++ days:http://www.stateslab.org/HowToWriteUnmaintainableCode-Green00.html

On Wed, Nov 30, 2011 at 9:08 PM, Sophie <itsme213@hotmail.com> wrote:

On 2011-11-30 13:48:43 -0600, Tony Morris <tmorris@tmorris.net> said:

I chose c because it first pooped into my head. If some other variable name
replaced it, then readability is unaffected.

I politely but emphatically disagree. Formal meaning (or lack of it) is quite different from cognitive burden. Human brains are not computers or compilers. Programming, especially the bit around trying to grok unfamiliar code, is about much more than formal symbol table lookup.

Otherwise the entire code obfuscation industry would be spectacularly redundant :-)

The original (and updated) work is here http://mindprod.com/jgloss/unmain.html

On 11/30/2011 09:21 PM, Josh Suereth wrote:

9H80uARwD0E4Qe_ZfTA [at] mail [dot] gmail [dot] com" type="cite">The real question is, can a human obfuscate code better than a machine?  I think so.
My favorite read from my C++ days: http://www.stateslab.org/HowToWriteUnmaintainableCode-Green00.html

On Wed, Nov 30, 2011 at 9:08 PM, Sophie <itsme213 [at] hotmail [dot] com" rel="nofollow">itsme213@hotmail.com> wrote:

On 2011-11-30 13:48:43 -0600, Tony Morris <tmorris [at] tmorris [dot] net" target="_blank" rel="nofollow">tmorris@tmorris.net> said:

I chose c because it first pooped into my head. If some other variable name
replaced it, then readability is unaffected.

I politely but emphatically disagree. Formal meaning (or lack of it) is quite different from cognitive burden. Human brains are not computers or compilers. Programming, especially the bit around trying to grok unfamiliar code, is about much more than formal symbol table lookup.

Otherwise the entire code obfuscation industry would be spectacularly redundant :-)

On 2011-11-20 05:22:49 -0600, Tony Morris said:

> How many people do you suspect I have entered a discussion on some
> matter and said, "Listen carefully, you haven't even bothered to think
> about this matter.

Tony,

Your phrasing may be telling.

... "you haven't even bothered to think about this matter" is not a
good way to get better buy-in for your ideas and work. If you said it
to me, I would be insulted, no matter how you rationalize it post-hoc.
If you want better buy-in, communicate more like a peer would, even if
you are more knowledgeable in your field. Most of those who have not
even "bothered to think about this matter" have, in fact, thought quite
hard about other things related to the problems they solve.

... "you haven't even bothered to think about this matter" is quite
different from telling someone they are wrong about something. I am
sure you can recognize that.

I am new to this community, have just heard of scalaz, and am already
taken aback by the tone of some discussions.

On 12/01/2011 12:08 PM, Sophie wrote:
> On 2011-11-30 13:48:43 -0600, Tony Morris said:
>
>>
>> I chose c because it first pooped into my head. If some other
>> variable name
>> replaced it, then readability is unaffected.
>
> I politely but emphatically disagree. Formal meaning (or lack of it)
> is quite different from cognitive burden. Human brains are not
> computers or compilers. Programming, especially the bit around trying
> to grok unfamiliar code, is about much more than formal symbol table
> lookup.
>
> Otherwise the entire code obfuscation industry would be spectacularly
> redundant :-)
>
>

Let me be clear. I find the compulsion for names (alone) less
objectionable than naming things as they are not.

What is happening here, on this thread, on other threads in the past, is
that these three things are happening FAR FAR more than is being
acknowledged:

1) Naming things as they are not, then parading this as some kind of
virtue, and wondering why I respond with, "no thanks, won't be buying
one of those today."
2) Drawing fallacious conclusions from names (then wondering why the
program does not work?).
3) Drawing correct conclusions from names that could have been arrived
at using more rigorous and reliable methods (that is, the fact that the
conclusion holds is a coincidence, not a consequence).

It is these three things that provoke my objection and until it is
acknowledged that this happens far more than is realised, then I am
going to take the hard line: please stop doing this and expecting (at
least) me to consider the merits of any of this. And it's not because of
some utopian ideal; it's because of the practical implications of doing
these three things -- the consequences are distracting at best.

As for naming type parameters, well, it's just got all a bit out of hand
innit? Exactly, humans are not computers or compilers; so why are we
doing these crazy things again? I don't see the point in stating the
obvious -- I was required to know what a human is in order to achieve my
psychology education.

On Thu, Dec 1, 2011 at 3:44 AM, Sophie <itsme213@hotmail.com> wrote:

On 2011-11-20 05:22:49 -0600, Tony Morris <tonymorris@gmail.com> said:

How many people do you suspect I have entered a discussion on some
matter and said, "Listen carefully, you haven't even bothered to think
about this matter.

Tony,

Your phrasing may be telling.

... "you haven't even bothered to think about this matter" is not a good way to get better buy-in for your ideas and work. If you said it to me, I would be insulted, no matter how you rationalize it post-hoc. If you want better buy-in, communicate more like a peer would, even if you are more knowledgeable in your field. Most of those who have not even "bothered to think about this matter" have, in fact, thought quite hard about other things related to the problems they solve.

... "you haven't even bothered to think about this matter" is quite different from telling someone they are wrong about something. I am sure you can recognize that.

I am new to this community, have just heard of scalaz, and am already taken aback by the tone of some discussions.

You are absolutely right. Phrasing like this are is out of place on the scala-lists.
 -- Martin

On 12/01/2011 06:08 PM, martin odersky wrote:

Ei_3zjq7gw8jqGssPynZdw_39xq6wQ [at] mail [dot] gmail [dot] com" type="cite">

On Thu, Dec 1, 2011 at 3:44 AM, Sophie <itsme213 [at] hotmail [dot] com" rel="nofollow">itsme213@hotmail.com> wrote:

On 2011-11-20 05:22:49 -0600, Tony Morris <tonymorris [at] gmail [dot] com" target="_blank" rel="nofollow">tonymorris@gmail.com> said:

How many people do you suspect I have entered a discussion on some
matter and said, "Listen carefully, you haven't even bothered to think
about this matter.

Tony,

Your phrasing may be telling.

... "you haven't even bothered to think about this matter" is not a good way to get better buy-in for your ideas and work. If you said it to me, I would be insulted, no matter how you rationalize it post-hoc. If you want better buy-in, communicate more like a peer would, even if you are more knowledgeable in your field. Most of those who have not even "bothered to think about this matter" have, in fact, thought quite hard about other things related to the problems they solve.

... "you haven't even bothered to think about this matter" is quite different from telling someone they are wrong about something. I am sure you can recognize that.

I am new to this community, have just heard of scalaz, and am already taken aback by the tone of some discussions.

You are absolutely right. Phrasing like this are is out of place on the scala-lists.
 -- Martin

For those who are more interested in whether or not the statement is true, as opposed to any possible offence it may cause, it can have profoundly successful results -- successful in that we may then immediately discard all the wasteful social constructs and honour only those constructs that exist to serve a useful purpose conducive to the common goal. It is these high-prognosis cases that I am interested in and although you may not get to see these results first-hand, I assure you that these people are watching right now.

Ultimately, it saddens me that the discarding such useless and superficial pandering "is out of place on the scala lists", only because, and I believe I speak for others too, I am acutely aware of the detrimental impact it has. I wish we could have more useful disagreements -- with useful outcomes -- than these silly ones, which in my opinion, are very short-sighted.

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

On Thu, Dec 1, 2011 at 4:01 AM, Tony Morris <tonymorris@gmail.com> wrote:

For those who are more interested in whether or not the statement is true, as opposed to any possible offence it may cause, it can have profoundly successful results

What about those who are interested in whether or not the statement is true, but are also concerned about whether it is presented offensively _especially_ when one could have made the same point without as great a probability of causing offense?
 

-- successful in that we may then immediately discard all the wasteful social constructs and honour only those constructs that exist to serve a useful purpose conducive to the common goal.

I don't actually think that they're wasteful.  You're just not analyzing the social situation deeply enough.  It is, for most people at least, very easy to judge whether interactions are hostile or supportive.  It is much harder to analyze whether something is true or not.  When performing something hard, it is beneficial to be in a situation where other people are likely to help, and the best way to judge that _on average_ is whether the environment is supportive or not.  So, if you act in a way that is typically interpreted as hostile, you should expect that pragmatic people will at best ignore what you say--you've already given them a strong indication that finding out whether what you say is true or not is going to be made extra-difficult.

Now, once people all know each other well, it's more acceptable to drop some of the standard social practices that convey good intent.  And even when people don't know each other well, there can occasionally be other social clues that the situation is not what one would expect ("Why do people seem so supportive of that guy who appears to be a jerk?  Maybe I'm reading the situation wrong....").
 

It is these high-prognosis cases that I am interested in and although you may not get to see these results first-hand, I assure you that these people are watching right now.

Maybe the list exists to do things other than cover these high-prognosis cases.  No reason you can't have both, if you're careful.
 

Ultimately, it saddens me that the discarding such useless and superficial pandering "is out of place on the scala lists", only because, and I believe I speak for others too, I am acutely aware of the detrimental impact it has.

Discarding the "useless and superficial pandering" also has sizable detrimental impacts, which some people are also acutely aware of.
 

I wish we could have more useful disagreements -- with useful outcomes -- than these silly ones, which in my opinion, are very short-sighted.

The best way to have more useful disagreements is to carefully choose language such that the focus is on the disagreement and does not provoke "silliness".  Because, as I have outlined above, tone *does* in fact serve a useful purpose, especially for those who are not already intimately familiar with the list.

It's entirely possible to both adhere to typical standards of politeness and yet convey strong disagreement with someone's position.  In fact, I would argue that this is preferable in most situations, because you can easily get silliness of the other sort: one person agreeing with another because someone of higher apparent social standing acts knowledgeable yet hostile towards them, and the other feels that they had better submit not because of the strength of their arguments but because of the strength of their social standing.  That's a silly reason to believe something, isn't it?  Sometimes it is necessary to induce a bit of tension in order to get people to reconsider their assumptions, but it's easy to overdo it.

  --Rex

P.S. An example of how to/not to express disagreement:
  Hostile - "Your statements demonstrate your complete ignorance of..."
  Useful (firm) - "I strongly disagree; consider that..."
  Useful (nice) - "I have a different perspective; ..."
  Pandering - "Thank you so much for sharing your experience!..."

Tony -
Your statements, both now and in the past, are usually interpreted as being hostile or insulting.  Whether or not this is your inention is beside the point.  Statements like "Listen carefully, you haven't even bothered to think
about this matter"  will almost *almost always* be interpreted as offensive in the U.S. 
For your own sake, please learn from past experience and try to use language the gets your point across without emotional baggage.
For the sake of this list, I ask you to refrain from emails of this nature.  I don't want to have to personally moderate all the email you generate on here, but you're not leaving me with many other options.
- Josh

On Thu, Dec 1, 2011 at 11:07 AM, Rex Kerr <ichoran@gmail.com> wrote:

On Thu, Dec 1, 2011 at 4:01 AM, Tony Morris <tonymorris@gmail.com> wrote:

For those who are more interested in whether or not the statement is true, as opposed to any possible offence it may cause, it can have profoundly successful results

What about those who are interested in whether or not the statement is true, but are also concerned about whether it is presented offensively _especially_ when one could have made the same point without as great a probability of causing offense?
 

-- successful in that we may then immediately discard all the wasteful social constructs and honour only those constructs that exist to serve a useful purpose conducive to the common goal.

I don't actually think that they're wasteful.  You're just not analyzing the social situation deeply enough.  It is, for most people at least, very easy to judge whether interactions are hostile or supportive.  It is much harder to analyze whether something is true or not.  When performing something hard, it is beneficial to be in a situation where other people are likely to help, and the best way to judge that _on average_ is whether the environment is supportive or not.  So, if you act in a way that is typically interpreted as hostile, you should expect that pragmatic people will at best ignore what you say--you've already given them a strong indication that finding out whether what you say is true or not is going to be made extra-difficult.

Now, once people all know each other well, it's more acceptable to drop some of the standard social practices that convey good intent.  And even when people don't know each other well, there can occasionally be other social clues that the situation is not what one would expect ("Why do people seem so supportive of that guy who appears to be a jerk?  Maybe I'm reading the situation wrong....").
 

It is these high-prognosis cases that I am interested in and although you may not get to see these results first-hand, I assure you that these people are watching right now.

Maybe the list exists to do things other than cover these high-prognosis cases.  No reason you can't have both, if you're careful.
 

Ultimately, it saddens me that the discarding such useless and superficial pandering "is out of place on the scala lists", only because, and I believe I speak for others too, I am acutely aware of the detrimental impact it has.

Discarding the "useless and superficial pandering" also has sizable detrimental impacts, which some people are also acutely aware of.
 

I wish we could have more useful disagreements -- with useful outcomes -- than these silly ones, which in my opinion, are very short-sighted.

The best way to have more useful disagreements is to carefully choose language such that the focus is on the disagreement and does not provoke "silliness".  Because, as I have outlined above, tone *does* in fact serve a useful purpose, especially for those who are not already intimately familiar with the list.

It's entirely possible to both adhere to typical standards of politeness and yet convey strong disagreement with someone's position.  In fact, I would argue that this is preferable in most situations, because you can easily get silliness of the other sort: one person agreeing with another because someone of higher apparent social standing acts knowledgeable yet hostile towards them, and the other feels that they had better submit not because of the strength of their arguments but because of the strength of their social standing.  That's a silly reason to believe something, isn't it?  Sometimes it is necessary to induce a bit of tension in order to get people to reconsider their assumptions, but it's easy to overdo it.

  --Rex

P.S. An example of how to/not to express disagreement:
  Hostile - "Your statements demonstrate your complete ignorance of..."
  Useful (firm) - "I strongly disagree; consider that..."
  Useful (nice) - "I have a different perspective; ..."
  Pandering - "Thank you so much for sharing your experience!..."

I vote for a [scala-learning] where sharing ideas trumps all other agendas.

On Dec 2, 2011 3:10 AM, "Josh Suereth" <joshua.suereth@gmail.com> wrote:

Tony -
Your statements, both now and in the past, are usually interpreted as being hostile or insulting.  Whether or not this is your inention is beside the point.  Statements like "Listen carefully, you haven't even bothered to think
about this matter"  will almost *almost always* be interpreted as offensive in the U.S. 
For your own sake, please learn from past experience and try to use language the gets your point across without emotional baggage.
For the sake of this list, I ask you to refrain from emails of this nature.  I don't want to have to personally moderate all the email you generate on here, but you're not leaving me with many other options.
- Josh

On Thu, Dec 1, 2011 at 11:07 AM, Rex Kerr <ichoran@gmail.com> wrote:

On Thu, Dec 1, 2011 at 4:01 AM, Tony Morris <tonymorris@gmail.com> wrote:

For those who are more interested in whether or not the statement is true, as opposed to any possible offence it may cause, it can have profoundly successful results

What about those who are interested in whether or not the statement is true, but are also concerned about whether it is presented offensively _especially_ when one could have made the same point without as great a probability of causing offense?
 

-- successful in that we may then immediately discard all the wasteful social constructs and honour only those constructs that exist to serve a useful purpose conducive to the common goal.

I don't actually think that they're wasteful.  You're just not analyzing the social situation deeply enough.  It is, for most people at least, very easy to judge whether interactions are hostile or supportive.  It is much harder to analyze whether something is true or not.  When performing something hard, it is beneficial to be in a situation where other people are likely to help, and the best way to judge that _on average_ is whether the environment is supportive or not.  So, if you act in a way that is typically interpreted as hostile, you should expect that pragmatic people will at best ignore what you say--you've already given them a strong indication that finding out whether what you say is true or not is going to be made extra-difficult.

Now, once people all know each other well, it's more acceptable to drop some of the standard social practices that convey good intent.  And even when people don't know each other well, there can occasionally be other social clues that the situation is not what one would expect ("Why do people seem so supportive of that guy who appears to be a jerk?  Maybe I'm reading the situation wrong....").
 

It is these high-prognosis cases that I am interested in and although you may not get to see these results first-hand, I assure you that these people are watching right now.

Maybe the list exists to do things other than cover these high-prognosis cases.  No reason you can't have both, if you're careful.
 

Ultimately, it saddens me that the discarding such useless and superficial pandering "is out of place on the scala lists", only because, and I believe I speak for others too, I am acutely aware of the detrimental impact it has.

Discarding the "useless and superficial pandering" also has sizable detrimental impacts, which some people are also acutely aware of.
 

I wish we could have more useful disagreements -- with useful outcomes -- than these silly ones, which in my opinion, are very short-sighted.

The best way to have more useful disagreements is to carefully choose language such that the focus is on the disagreement and does not provoke "silliness".  Because, as I have outlined above, tone *does* in fact serve a useful purpose, especially for those who are not already intimately familiar with the list.

It's entirely possible to both adhere to typical standards of politeness and yet convey strong disagreement with someone's position.  In fact, I would argue that this is preferable in most situations, because you can easily get silliness of the other sort: one person agreeing with another because someone of higher apparent social standing acts knowledgeable yet hostile towards them, and the other feels that they had better submit not because of the strength of their arguments but because of the strength of their social standing.  That's a silly reason to believe something, isn't it?  Sometimes it is necessary to induce a bit of tension in order to get people to reconsider their assumptions, but it's easy to overdo it.

  --Rex

P.S. An example of how to/not to express disagreement:
  Hostile - "Your statements demonstrate your complete ignorance of..."
  Useful (firm) - "I strongly disagree; consider that..."
  Useful (nice) - "I have a different perspective; ..."
  Pandering - "Thank you so much for sharing your experience!..."

On Thu, Dec 1, 2011 at 4:01 AM, Tony Morris <tonymorris@gmail.com> wrote:

I wish we could have more useful disagreements -- with useful outcomes -- than these silly ones, which in my opinion, are very short-sighted.

Cheers for acknowledging that it's just an opinion!

You don't have to vote --- go ahead and create it, there's nothing stopping you.

On Thu, Dec 1, 2011 at 5:05 PM, Tony Morris <tmorris@tmorris.net> wrote:

I vote for a [scala-learning] where sharing ideas trumps all other agendas.

On Dec 2, 2011 3:10 AM, "Josh Suereth" <joshua.suereth@gmail.com> wrote:

Tony -
Your statements, both now and in the past, are usually interpreted as being hostile or insulting.  Whether or not this is your inention is beside the point.  Statements like "Listen carefully, you haven't even bothered to think
about this matter"  will almost *almost always* be interpreted as offensive in the U.S. 
For your own sake, please learn from past experience and try to use language the gets your point across without emotional baggage.
For the sake of this list, I ask you to refrain from emails of this nature.  I don't want to have to personally moderate all the email you generate on here, but you're not leaving me with many other options.
- Josh

On Thu, Dec 1, 2011 at 11:07 AM, Rex Kerr <ichoran@gmail.com> wrote:

On Thu, Dec 1, 2011 at 4:01 AM, Tony Morris <tonymorris@gmail.com> wrote:

For those who are more interested in whether or not the statement is true, as opposed to any possible offence it may cause, it can have profoundly successful results

What about those who are interested in whether or not the statement is true, but are also concerned about whether it is presented offensively _especially_ when one could have made the same point without as great a probability of causing offense?
 

-- successful in that we may then immediately discard all the wasteful social constructs and honour only those constructs that exist to serve a useful purpose conducive to the common goal.

I don't actually think that they're wasteful.  You're just not analyzing the social situation deeply enough.  It is, for most people at least, very easy to judge whether interactions are hostile or supportive.  It is much harder to analyze whether something is true or not.  When performing something hard, it is beneficial to be in a situation where other people are likely to help, and the best way to judge that _on average_ is whether the environment is supportive or not.  So, if you act in a way that is typically interpreted as hostile, you should expect that pragmatic people will at best ignore what you say--you've already given them a strong indication that finding out whether what you say is true or not is going to be made extra-difficult.

Now, once people all know each other well, it's more acceptable to drop some of the standard social practices that convey good intent.  And even when people don't know each other well, there can occasionally be other social clues that the situation is not what one would expect ("Why do people seem so supportive of that guy who appears to be a jerk?  Maybe I'm reading the situation wrong....").
 

It is these high-prognosis cases that I am interested in and although you may not get to see these results first-hand, I assure you that these people are watching right now.

Maybe the list exists to do things other than cover these high-prognosis cases.  No reason you can't have both, if you're careful.
 

Ultimately, it saddens me that the discarding such useless and superficial pandering "is out of place on the scala lists", only because, and I believe I speak for others too, I am acutely aware of the detrimental impact it has.

Discarding the "useless and superficial pandering" also has sizable detrimental impacts, which some people are also acutely aware of.
 

I wish we could have more useful disagreements -- with useful outcomes -- than these silly ones, which in my opinion, are very short-sighted.

The best way to have more useful disagreements is to carefully choose language such that the focus is on the disagreement and does not provoke "silliness".  Because, as I have outlined above, tone *does* in fact serve a useful purpose, especially for those who are not already intimately familiar with the list.

It's entirely possible to both adhere to typical standards of politeness and yet convey strong disagreement with someone's position.  In fact, I would argue that this is preferable in most situations, because you can easily get silliness of the other sort: one person agreeing with another because someone of higher apparent social standing acts knowledgeable yet hostile towards them, and the other feels that they had better submit not because of the strength of their arguments but because of the strength of their social standing.  That's a silly reason to believe something, isn't it?  Sometimes it is necessary to induce a bit of tension in order to get people to reconsider their assumptions, but it's easy to overdo it.

  --Rex

P.S. An example of how to/not to express disagreement:
  Hostile - "Your statements demonstrate your complete ignorance of..."
  Useful (firm) - "I strongly disagree; consider that..."
  Useful (nice) - "I have a different perspective; ..."
  Pandering - "Thank you so much for sharing your experience!..."

On 02/12/11 17:54, Naftoli Gugenheim wrote:
> On Thu, Dec 1, 2011 at 4:01 AM, Tony Morris wrote:
>
>> **
>> I wish we could have more useful disagreements -- with useful outcomes --
>> than these silly ones, which in my opinion, are very short-sighted.
>>
> Cheers for acknowledging that it's just an opinion!
>
Yes, it makes me sound much more level-headed doesn't it? Now if only I
could water it down even more amirite?

Here is Haskell blog post encouraging long type variable names, http://softwaresimply.blogspot.com/2011/12/whats-in-name-lot.html. Provides an interesting perspective that mostly resonates with the opening post in this thread. Enjoy the read!