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. On Nov 16, 2011 1:53 PM, "Ken McDonald" <ykken...@gmail.com> wrote:
> This comes from thinking about the alleged complexity of Scala (others' > arguments have convinced me it is a real problem in the corporate world), > my own experiences as I start to penetrate a little bit of the "inner core" > of Scala, and most of all, trying to be productive and ask, "Are there > simple ways to mitigate the complexity problem?" (Assuming you believe it > is a problem.)
> I don't know about you, but I have never worked in an environment where > this would be considered acceptable code (unless x, y, and z actually had > special meaning in the problem space). I think it's a given that good > software engineering demands meaningful variable names, both internal and > visible.
> Now consider the following type signature: > flatMap [B, That] (f: (A) => GenTraversableOnce[B])(implicit bf: > CanBuildFrom[List[A], B, That]): That > There are three type parameters, A, B, and That. None are meaningful. Due > to the fortunate inclusion of f: in the type, it's fairly easy to figure > out the meanings of A and B. We can finally figure out the meaning of That > when we reach the end of the line, at which point we need to reread the > entire line to put everything together. (OK, you may not. I do, and I > submit that most programmers will need to do so once or more.)
> In fairness, there was a valid reason for using one-char type param back > when type params were new; the declarations were simply (usually container > classes), and the one-char rule made it obvious what was a type param and > what was an actual type. Note the above def'n has already violated the > one-char rule, without really adding value.
> This is much more verbose, but to someone unaccustomed to Scala > collections, it is also much clearer. I've taken the liberty of using > initial lowercase to denote a parameter rather than an actual type; I > believe this is illegal, but I simply wanted to show how things could be > made more readable.
> If you're an experienced Scala user, this may not seem a big deal, just > extra characters. Consider the process of reading the type signature from > left to right, understanding as we go:
> flatMap [B, That]
> vs. > flatMap [resultElementType, resultType]
> The second has immediate meaning. The first does not.
> The example I chose was mid-level in complexity--it is as the top of what > a Scala novice should encounter, but nowhere near as complex as one might > encounter in Scala internals or scalaz.
> I believe that encouraging meaninful type parameter names would help the > perceived "Scala complexity" problem in two ways. First, it makes the more > complex "beginner's" Scala signatures more immediately understandable to > beginners. Second, it make intellectually sophisticated Scala code more > acceptable to the mainstream by making it more readable.
> On 17 November 2011 12:11, Tony Morris <tonymor...@gmail.com> wrote:
>> It is extremely important to pick meaningless names. The moment you >> project meaning is the moment you start making all those mistakes that >> we so often see.
> Many times the types are not devoid of meaning. Consider:
> trait Graph[A, B]
> vs
> trait Graph[N, E]
> vs
> trait Graph[Node, Edge]
> vs
> trait Graph[TheNodeType, TheEdgeType]
> Option 3 of these is (imao) optimal, as it clearly describes what role the > types play without using unnecessarily verbose names. If you're not > 'projecting meaning' on these two type parameters, you're not understanding > the API. I've no problem with List[A], as there's nothing much to tell > users about A. In a library like scalaz, consistent use of single-letter > type parameters goes a long way, but then you have things like what the > default letter should be for Monad vs Monoid.
> I'll bug out here, as I agree this should go to -debate until/unless it > results in an agreement to go through the core libs renaming things, in > which case I'd be happy to give up a 'documentation saturday' to helping > rename things.
This is exactly the mistake I refer to. Now define your operations on the data type. What do those operations (the important bits) say about nodes and edges? Exactly, nothing, nothing at all -- now you're stuck in a cognitive quagmire. Please allow me to politely decline your invitation.
[I'm now subscribed to scala-debate - sorry if you got this twice]
On 17 November 2011 13:13, Tony Morris <tonymor...@gmail.com> wrote:
> On 17/11/11 22:56, Matthew Pocock wrote: > > trait Graph[TheNodeType, TheEdgeType]
> This is exactly the mistake I refer to. Now define your operations on > the data type. What do those operations (the important bits) say about > nodes and edges?
There is no meaningful isomorphism that I can repeatedly apply to Graph[Node, Edge] to get a Graph[Edge, Node] and then apply again to get back to the original graph. The nodes and edges play distinct roles. Naming them after these roles is useful documentation for the user.
> Exactly, nothing, nothing at all
It tells me a great deal about the graph API. It doesn't tell me anything about the specific choices of concrete types for Node/Edge, but that is not what type parameter names are for. It tells me what role they play in the graph, which is what type parameter names are for.
> -- now you're stuck in > a cognitive quagmire. Please allow me to politely decline your invitation.
No, now I have a documented type, using nomenclature that people are used to, where people don't have to constantly look in 2 or 3 places to figure out if A or B is the type that represents an edge or if it is the type that represents a node. Most people are not compilers and find it easier if definitions can be understood with the minimum of needing to correlate terms with other definitions.
Honestly, I'm not getting what 'cognitive quagmire' I can fall into by calling the type in my graph that is being used for nodes Node rather than naming it A. It's a graph of nodes linked by edges ffs! We should be calling the node type Node and the edge type Edge. Anything else is obfuscation.
turingatemyhams...@gmail.com> wrote: > [I'm now subscribed to scala-debate - sorry if you got this twice]
> On 17 November 2011 13:13, Tony Morris <tonymor...@gmail.com> wrote:
>> On 17/11/11 22:56, Matthew Pocock wrote: >> > trait Graph[TheNodeType, TheEdgeType]
"The" can be dropped since it cannot be anything else. "Type" can be dropped since it can only be a type, you don't write: "val theThingVal = new Thing"
>> This is exactly the mistake I refer to. Now define your operations on >> the data type. What do those operations (the important bits) say about >> nodes and edges?
> There is no meaningful isomorphism that I can repeatedly apply to > Graph[Node, Edge] to get a Graph[Edge, Node] and then apply again to get > back to the original graph. The nodes and edges play distinct roles. Naming > them after these roles is useful documentation for the user.
>> Exactly, nothing, nothing at all
> It tells me a great deal about the graph API. It doesn't tell me anything > about the specific choices of concrete types for Node/Edge, but that is not > what type parameter names are for. It tells me what role they play in the > graph, which is what type parameter names are for.
>> -- now you're stuck in >> a cognitive quagmire. Please allow me to politely decline your invitation.
> No, now I have a documented type, using nomenclature that people are used > to, where people don't have to constantly look in 2 or 3 places to figure > out if A or B is the type that represents an edge or if it is the type that > represents a node. Most people are not compilers and find it easier if > definitions can be understood with the minimum of needing to correlate > terms with other definitions.
> Honestly, I'm not getting what 'cognitive quagmire' I can fall into by > calling the type in my graph that is being used for nodes Node rather than > naming it A. It's a graph of nodes linked by edges ffs! We should be > calling the node type Node and the edge type Edge. Anything else > is obfuscation.
On 17 November 2011 14:34, Philippe Lhoste <Phi...@gmx.net> wrote:
> On 17/11/2011 13:51, Josh Suereth wrote:
>> Yet another thread that probably belongs on scala-debate.
>> AND to answer with my opinion : I think using meaningful type parameter >> names can make >> sense, but there's a balance to be had.
> Yes. > When I discovered Scala, I was disconcerted, not to say "shocked", by > these one-letter type names. Looked like those old C programs where > developers valued conciseness over expressiveness. You know, lines like: if > (lh->v.u.s.aux == v->u.s.info)
Same here. I'd previously done a lot of Java and a few years of Haskell. I found much of the haskell libs to be impenetrable due to single-letter (and often non-mnemonic) type names, even after quite a while working with them.
> On the other hand, there can be some confusion between real types > (classes, etc.) and abstract types (those used in collections, not knowing > in advance what they would be); perhaps even potential clashes (?).
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.
Matthew
--
> Philippe Lhoste > -- (near) Paris -- France > -- http://Phi.Lho.free.fr > -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Dr Matthew Pocock Integrative Bioinformatics Group, School of Computing Science, Newcastle University mailto: turingatemyhams...@gmail.com gchat: turingatemyhams...@gmail.com msn: matthew_poc...@yahoo.co.uk irc.freenode.net: drdozer skype: matthew.pocock tel: (0191) 2566550 mob: +447535664143
> On Thu, Nov 17, 2011 at 2:58 PM, Matthew Pocock <turingatemyhams...@gmail.com> wrote:
>> [I'm now subscribed to scala-debate - sorry if you got this twice] >> On 17 November 2011 13:13, Tony Morris <tonymor...@gmail.com> wrote:
>>> On 17/11/11 22:56, Matthew Pocock wrote: >>> > trait Graph[TheNodeType, TheEdgeType]
> "The" can be dropped since it cannot be anything else. > "Type" can be dropped since it can only be a type, you don't write: "val theThingVal = new Thing"
> trait Graph[Node, Edge] <--- Looks great to me
Except you just killed Node and Edge as trait/class names. At the very least, I'd call them ANode and AnEdge.
> > On Thu, Nov 17, 2011 at 2:58 PM, Matthew Pocock < > turingatemyhams...@gmail.com> wrote:
> >> [I'm now subscribed to scala-debate - sorry if you got this twice] > >> On 17 November 2011 13:13, Tony Morris <tonymor...@gmail.com> wrote:
> >>> On 17/11/11 22:56, Matthew Pocock wrote: > >>> > trait Graph[TheNodeType, TheEdgeType]
> > "The" can be dropped since it cannot be anything else. > > "Type" can be dropped since it can only be a type, you don't write: "val > theThingVal = new Thing"
> > trait Graph[Node, Edge] <--- Looks great to me
> Except you just killed Node and Edge as trait/class names. At the very > least, I'd call them ANode and AnEdge.
Afaik C# prefixes type parameters with T and return type parameters with R ... but they also use I as a prefix for interfaces. The last holdout of Hungarian notation?
On Thu, Nov 17, 2011 at 13:35, Simon Ochsenreither
<simon.ochsenreit...@googlemail.com> wrote: > Afaik C# prefixes type parameters with T and return type parameters with R > ... but they also use I as a prefix for interfaces. The last holdout of > Hungarian notation?
You should see that Uncle Bob has to say about prefixing interfaces with I. Pretty funny! :-)
2011/11/17 Matthew Pocock <turingatemyhams...@gmail.com>
> Yes.... Wouldn't Map[K, V] or Map[Key, Value] be more self-explanatory? > Peace.
There will always be people to not catch [K,V] as [Key, Value], and others to not catch what is Key or Value because they just don't know what a Map is (let's say the hereby example is easier than the general case). 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. As for using longer names, I'd say as stated before : if your concepts are abstract (pure mathematics, categories, formal systems in computer science) then use abstract names. Else, just make sure it's not conflict-prone ... Graph[N,E] seems just fine to me, Graph[A,B] is also fine. Graph[Node,Edge] takes risk in conflicting with already defined types (as a Graph API user, I would be tempted to code """type Node = Container[SomeType, AnotherOne, ...]""").
All the above IMHO.
Alex
2011/11/17 Michael Schmitz <mich...@schmitztech.com>
turingatemyhams...@gmail.com> wrote: > On 17 November 2011 12:11, Tony Morris <tonymor...@gmail.com> wrote:
>> It is extremely important to pick meaningless names. The moment you >> project meaning is the moment you start making all those mistakes that >> we so often see.
> Many times the types are not devoid of meaning. Consider:
> trait Graph[A, B]
Bad. Now I have to remember whether your graphs have nodes first or edges first. I don't want to have to do that.
> trait Graph[N, E]
Good! Now I don't have to remember!
> trait Graph[Node, Edge]
Why all the extra letters? I already knew everything I needed to know.
> trait Graph[TheNodeType, TheEdgeType]
This is just mean.
Actually, these are all bad. Shouldn't it be
trait Graph[N <: Node, E <: Edge]
where Node and Edge are some traits that define the minimal possible interface required for something to be considered a node or an edge? Maybe even
trait Graph[N <: Node, E <: Edge[N]]
depending on the edge interface?
Now we can see why Graph[Node, Edge] is the wrong choice. You have labeled the types with _what you want_ without specifying that _they must be what you want_. The more you insist with your names that you will in fact put the correct thing in that slot, the less likely you are to make the compiler insist on your behalf, and therefore the more burden you are taking upon yourself.
This is why I think the sweet spot is [N,E]. You want _some_ mnemonic because you want to know for yourself (as well as the compiler knowing) that nodes come before edges. But [Node, Edge] is deceptive, and also steals the name Node and Edge away from what you probably really want (which are Node and Edge traits or classes).
On Thu, Nov 17, 2011 at 1:45 PM, Rex Kerr <icho...@gmail.com> wrote: > This is why I think the sweet spot is [N,E]. You want _some_ mnemonic > because you want to know for yourself (as well as the compiler knowing) that > nodes come before edges. But [Node, Edge] is deceptive, and also steals the > name Node and Edge away from what you probably really want (which are Node > and Edge traits or classes).
On Thu, Nov 17, 2011 at 01:45:56PM -0500, Rex Kerr wrote: > This is why I think the sweet spot is [N,E]. You want _some_ mnemonic > because you want to know for yourself (as well as the compiler knowing) > that nodes come before edges. But [Node, Edge] is deceptive, and also > steals the name Node and Edge away from what you probably really want > (which are Node and Edge traits or classes).
Agreed.
I find the single letter convention actually makes the use of generics more obvious to me and easier to reason about. If I had to figure out whether everything that looked like "Node" was a type parameter or a concrete type I would be sad. [1]
-- Erik
[1] Before Scala I had no background in languages that had type parameterization, so (as far as I can tell) I don't have an earlier attachment to this style.
i have almost never seen a case where a single letter or letter + number wasn't enough. if you use a class with type parameters, you use actual types. if you are inside the class having the class parameters, you have to take a deeper look anyway or are the author and should know enough already. taking a quick glance at the declaration won't slow you down.
> On Thu, Nov 17, 2011 at 7:56 AM, Matthew Pocock > <turingatemyhams...@gmail.com <mailto:turingatemyhams...@gmail.com>> > wrote:
> On 17 November 2011 12:11, Tony Morris <tonymor...@gmail.com > <mailto:tonymor...@gmail.com>> wrote:
> It is extremely important to pick meaningless names. The > moment you > project meaning is the moment you start making all those > mistakes that > we so often see.
> Many times the types are not devoid of meaning. Consider:
> trait Graph[A, B]
> Bad. Now I have to remember whether your graphs have nodes first or > edges first. I don't want to have to do that.
> trait Graph[N, E]
> Good! Now I don't have to remember!
> trait Graph[Node, Edge]
> Why all the extra letters? I already knew everything I needed to know.
> trait Graph[TheNodeType, TheEdgeType]
> This is just mean.
> Actually, these are all bad. Shouldn't it be
> trait Graph[N <: Node, E <: Edge]
> where Node and Edge are some traits that define the minimal possible > interface required for something to be considered a node or an edge? > Maybe even
> trait Graph[N <: Node, E <: Edge[N]]
> depending on the edge interface?
> Now we can see why Graph[Node, Edge] is the wrong choice. You have > labeled the types with _what you want_ without specifying that _they > must be what you want_. The more you insist with your names that you > will in fact put the correct thing in that slot, the less likely you > are to make the compiler insist on your behalf, and therefore the more > burden you are taking upon yourself.
> This is why I think the sweet spot is [N,E]. You want _some_ mnemonic > because you want to know for yourself (as well as the compiler > knowing) that nodes come before edges. But [Node, Edge] is deceptive, > and also steals the name Node and Edge away from what you probably > really want (which are Node and Edge traits or classes).
On Thu, Nov 17, 2011 at 11:01 AM, Erik Osheim <e...@plastic-idolatry.com> wrote: > On Thu, Nov 17, 2011 at 01:45:56PM -0500, Rex Kerr wrote: >> This is why I think the sweet spot is [N,E]. You want _some_ mnemonic >> because you want to know for yourself (as well as the compiler knowing) >> that nodes come before edges. But [Node, Edge] is deceptive, and also >> steals the name Node and Edge away from what you probably really want >> (which are Node and Edge traits or classes).
> Agreed.
> I find the single letter convention actually makes the use of generics > more obvious to me and easier to reason about. If I had to figure out > whether everything that looked like "Node" was a type parameter or a > concrete type I would be sad. [1]
> -- Erik
> [1] Before Scala I had no background in languages that had type > parameterization, so (as far as I can tell) I don't have an earlier > attachment to this style.
Write a few of your graph operations. Use the type parameters as if they were nodes or edges. Notice how you can't. The proposal is akin to projecting meaning onto universally quantified variables of a logical proposition. We say, paraphrased:
For all c such that c is an element of the set Cars...
Notice how we call the variable c, not car or any other particular meaning. Doing so would degrade readability to the extent that it may distract from the fact that this variable should contain no further context than its existence. The constraint of set membership is simply an application to an operation, no different to a list sort operation requiring ordering on its elements.
It is extremely important that type variable names contain no context (that is, call it what you want but I won't be projecting an imaginary context onto it). I am only motivated to point this out because one day someone is going to bring this point up IRL and I am going to have to deal with it. I don't want to; this elusive insight that I am apparently missing according to "the naming guys" is repeatedly shown to be a failed thesis and now it is crawling into the least welcome of places (type variables).
Please modify the thesis for practical purposes. On Nov 17, 2011 11:58 PM, "Matthew Pocock" <turingatemyhams...@gmail.com> wrote:
> [I'm now subscribed to scala-debate - sorry if you got this twice]
> On 17 November 2011 13:13, Tony Morris <tonymor...@gmail.com> wrote:
>> On 17/11/11 22:56, Matthew Pocock wrote: >> > trait Graph[TheNodeType, TheEdgeType]
>> This is exactly the mistake I refer to. Now define your operations on >> the data type. What do those operations (the important bits) say about >> nodes and edges?
> There is no meaningful isomorphism that I can repeatedly apply to > Graph[Node, Edge] to get a Graph[Edge, Node] and then apply again to get > back to the original graph. The nodes and edges play distinct roles. Naming > them after these roles is useful documentation for the user.
>> Exactly, nothing, nothing at all
> It tells me a great deal about the graph API. It doesn't tell me anything > about the specific choices of concrete types for Node/Edge, but that is not > what type parameter names are for. It tells me what role they play in the > graph, which is what type parameter names are for.
>> -- now you're stuck in >> a cognitive quagmire. Please allow me to politely decline your invitation.
> No, now I have a documented type, using nomenclature that people are used > to, where people don't have to constantly look in 2 or 3 places to figure > out if A or B is the type that represents an edge or if it is the type that > represents a node. Most people are not compilers and find it easier if > definitions can be understood with the minimum of needing to correlate > terms with other definitions.
> Honestly, I'm not getting what 'cognitive quagmire' I can fall into by > calling the type in my graph that is being used for nodes Node rather than > naming it A. It's a graph of nodes linked by edges ffs! We should be > calling the node type Node and the edge type Edge. Anything else > is obfuscation.
For normal programmers, names matter. Most people don't think in lambda calculus or category theory or first order predicate logic. These people need informative names.
Matthew
On 17 November 2011 19:42, Tony Morris <tmor...@tmorris.net> wrote:
> Write a few of your graph operations. Use the type parameters as if they > were nodes or edges. Notice how you can't. The proposal is akin to > projecting meaning onto universally quantified variables of a logical > proposition. We say, paraphrased:
> For all c such that c is an element of the set Cars...
> Notice how we call the variable c, not car or any other particular > meaning. Doing so would degrade readability to the extent that it may > distract from the fact that this variable should contain no further context > than its existence. The constraint of set membership is simply an > application to an operation, no different to a list sort operation > requiring ordering on its elements.
> It is extremely important that type variable names contain no context > (that is, call it what you want but I won't be projecting an imaginary > context onto it). I am only motivated to point this out because one day > someone is going to bring this point up IRL and I am going to have to deal > with it. I don't want to; this elusive insight that I am apparently missing > according to "the naming guys" is repeatedly shown to be a failed thesis > and now it is crawling into the least welcome of places (type variables).
> Please modify the thesis for practical purposes. > On Nov 17, 2011 11:58 PM, "Matthew Pocock" <turingatemyhams...@gmail.com> > wrote:
>> [I'm now subscribed to scala-debate - sorry if you got this twice]
>> On 17 November 2011 13:13, Tony Morris <tonymor...@gmail.com> wrote:
>>> On 17/11/11 22:56, Matthew Pocock wrote: >>> > trait Graph[TheNodeType, TheEdgeType]
>>> This is exactly the mistake I refer to. Now define your operations on >>> the data type. What do those operations (the important bits) say about >>> nodes and edges?
>> There is no meaningful isomorphism that I can repeatedly apply to >> Graph[Node, Edge] to get a Graph[Edge, Node] and then apply again to get >> back to the original graph. The nodes and edges play distinct roles. Naming >> them after these roles is useful documentation for the user.
>>> Exactly, nothing, nothing at all
>> It tells me a great deal about the graph API. It doesn't tell me anything >> about the specific choices of concrete types for Node/Edge, but that is not >> what type parameter names are for. It tells me what role they play in the >> graph, which is what type parameter names are for.
>>> -- now you're stuck in >>> a cognitive quagmire. Please allow me to politely decline your >>> invitation.
>> No, now I have a documented type, using nomenclature that people are used >> to, where people don't have to constantly look in 2 or 3 places to figure >> out if A or B is the type that represents an edge or if it is the type that >> represents a node. Most people are not compilers and find it easier if >> definitions can be understood with the minimum of needing to correlate >> terms with other definitions.
>> Honestly, I'm not getting what 'cognitive quagmire' I can fall into by >> calling the type in my graph that is being used for nodes Node rather than >> naming it A. It's a graph of nodes linked by edges ffs! We should be >> calling the node type Node and the edge type Edge. Anything else >> is obfuscation.
On 17 November 2011 18:34, Alex Repain <alex.rep...@gmail.com> wrote:
> 2011/11/17 Matthew Pocock <turingatemyhams...@gmail.com>
>> Yes.... Wouldn't Map[K, V] or Map[Key, Value] be more self-explanatory? >> Peace.
> There will always be people to not catch [K,V] as [Key, Value], and others > to not catch what is Key or Value because they just don't know what a Map > is (let's say the hereby example is easier than the general case).
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).
Are you seriously expecting me to buy this? That I, and others who aspire to get practical work done, are not "normal programmers", while you, and your buddies are? Is this how you justify your thesis to yourself? Sorry, but it's pretty transparent to me.
Do you not think I have worked with people who were once "naming guys"? They are wrong, so they tried every trick they had, like you are doing. They're not "naming guys" anymore.
Either demonstrate the point (an appeal to normality/abnormality exclusion is fallacious -- surely this is obvious) or work out that you're making a mistake with adverse practical implications. All you've got to do is use your Node/Edge type variables as if they were nodes or edges. Let me know when you have achieved this.
> For normal programmers, names matter. Most people don't think in lambda > calculus or category theory or first order predicate logic. These people > need informative names.
> Matthew
> On 17 November 2011 19:42, Tony Morris <tmor...@tmorris.net> wrote:
>> Write a few of your graph operations. Use the type parameters as if they >> were nodes or edges. Notice how you can't. The proposal is akin to >> projecting meaning onto universally quantified variables of a logical >> proposition. We say, paraphrased:
>> For all c such that c is an element of the set Cars...
>> Notice how we call the variable c, not car or any other particular >> meaning. Doing so would degrade readability to the extent that it may >> distract from the fact that this variable should contain no further context >> than its existence. The constraint of set membership is simply an >> application to an operation, no different to a list sort operation >> requiring ordering on its elements.
>> It is extremely important that type variable names contain no context >> (that is, call it what you want but I won't be projecting an imaginary >> context onto it). I am only motivated to point this out because one day >> someone is going to bring this point up IRL and I am going to have to deal >> with it. I don't want to; this elusive insight that I am apparently missing >> according to "the naming guys" is repeatedly shown to be a failed thesis >> and now it is crawling into the least welcome of places (type variables).
>> Please modify the thesis for practical purposes. >> On Nov 17, 2011 11:58 PM, "Matthew Pocock" <turingatemyhams...@gmail.com> >> wrote:
>>> [I'm now subscribed to scala-debate - sorry if you got this twice]
>>> On 17 November 2011 13:13, Tony Morris <tonymor...@gmail.com> wrote:
>>>> On 17/11/11 22:56, Matthew Pocock wrote: >>>>> trait Graph[TheNodeType, TheEdgeType] >>>> This is exactly the mistake I refer to. Now define your operations on >>>> the data type. What do those operations (the important bits) say about >>>> nodes and edges?
>>> There is no meaningful isomorphism that I can repeatedly apply to >>> Graph[Node, Edge] to get a Graph[Edge, Node] and then apply again to get >>> back to the original graph. The nodes and edges play distinct roles. Naming >>> them after these roles is useful documentation for the user.
>>>> Exactly, nothing, nothing at all
>>> It tells me a great deal about the graph API. It doesn't tell me anything >>> about the specific choices of concrete types for Node/Edge, but that is not >>> what type parameter names are for. It tells me what role they play in the >>> graph, which is what type parameter names are for.
>>>> -- now you're stuck in >>>> a cognitive quagmire. Please allow me to politely decline your >>>> invitation.
>>> No, now I have a documented type, using nomenclature that people are used >>> to, where people don't have to constantly look in 2 or 3 places to figure >>> out if A or B is the type that represents an edge or if it is the type that >>> represents a node. Most people are not compilers and find it easier if >>> definitions can be understood with the minimum of needing to correlate >>> terms with other definitions.
>>> Honestly, I'm not getting what 'cognitive quagmire' I can fall into by >>> calling the type in my graph that is being used for nodes Node rather than >>> naming it A. It's a graph of nodes linked by edges ffs! We should be >>> calling the node type Node and the edge type Edge. Anything else >>> is obfuscation.
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!
