I can agree that this should be a special view that falls back to link if it doesn't find a rule or view to override it.  I would like to find a solution that you think belongs in the standard mods, but if not we can have a clean optional mod.  If you just get a contextual cardname from a rule, and if when you expand the contextual name, you get a URI card (or any card with this special view, I guess), you get the magic.

---

Hmm, in general, what do you think about 'rule for a view' as described here? In principle, it would not actually need a codename or any code, so wagneerable (Will that be cardable now?). Maybe a Cardtype: View such that if *my_view is a View, and *my_view+*default_view => link, and URI+*type+*my_view -> _self, and Quote+*type+*my_view -> +reference, etc.

 

Then if URI implements the view 'external_link', I can do what I want with just this feature on the base URI cardtype. (we'd add the rules for the View card *external_link (which I guess has to be a Setting card, or maybe a descendant of that type)).

---

I think we mentioned that this is "cardable" already, right? (I kind of like that term, though it's a little more ambiguous, since code is technically part of the cards, too). You could make a link_or_uri+*right+*structure card and then give it a different rule for URI's, Quotes, etc. Then you can just make your queries append "link or uri" to your cards, and voila.

 

This kind of pattern is very common, and is actually much more powerful than the "rule as a view" thing, because the values of those cards can be any content, not just views.

---

It might be great to explore interface ideas for making that kind of pattern easier to discover, use, and manage.

 

I also ultimately think it would be great if views all had associated cards (post-namespaces, perhaps?). And that they could be managed in this way. That could provide a ton of power. But the "rule as a view" thing sounds like a whole lot of solution for not much problem.

---

For me, the ambiguity is similar with wagneering, and we resolve it by convention. You could use "cardable" in a more general way, but I think we should define it conventionally as what can be done by changing the cards in the deck.

I did forget about that solution, but it really is a different thing, right? What I mean is that the virtual card sets based solution can work for many use cases, and as you say, it is more general, so we aren't talking this-or-that, but this-and-that. I know we don't want to put more complexity in the view space than we need to, but this is more a question about whether it is generally good or bad to even consider this as something that could be cardable. Can cardiacs create a view and use it without any code at all? Not now, but ever?

I guess in the short term I can make URI+reference+*type_plus_right -> {{_left}} I would be able to generally append +reference and view as content to get

a list of external references.

Is it really true that the virtual + card vs. adding a view are pretty equivalent? Seems like maybe they can be pushed that way, but there are still warts, but I'm not really sure.

---

> The ambiguity is similar with wagneering

There's less ambiguity with wagneerable, because "wagneering" specifically refers to working with cards, not code (and a Wagneer is someone who does that). It sounds like there's the most enthusiasm around "Cardist" for replacing "Wagneer" as a noun, but that doesn't really work as a verb. "Carding" is possible but not super appealing. We could use "deal", but that would make wagneers into dealers, which would be a step backwards :). Encard? Cardify? Cardfig... Shark? Oooh, we could make "sharking" our main noun/verb. Sharkable.

If we went that route, Cardist could be more about design, and Cardiac could be more about enthusiasm :)

 

> Is it really true that the virtual + card vs. adding a view are pretty equivalent?

Yes and no. You can certainly achieve a lot of things that way, and we make *heavy* use of these patterns. but you do end up have to deal with the fact that when you do "mycard+virtual variant", you often have to have a lot of explicit "_left" calls whenever you need to refer back to mycard. I think I'd agree that it's a bit warty.

 

> Can cardiacs create a view and use it without any code at all? Not now, but ever?

 

As I was trying to say, I do think in the long term it would be cool if there were more integration between views and cards/structures. I think I'm increasingly understanding your "rule as view" proposal, thanks to the examples. I wouldn't have gotten it based on the wording, so perhaps I'll restate your idea here in case anyone else is trying to understand it. 

Basically, Gerry is proposing that we might be able to define views in cards. Like rule definitions, view definitions would be set-based. So something like:

Set+Setting = (Standard Rule)
Set+View = (View Rule)

 

If I create a "View Rule", like URI+*type+*my_view, then I can do thinks like {{my uri | *my_view}} and the content of *my view will be treated much like a standard view definition. The parens in the examples are to indicated that neither Rule nor View Rule is a cardtype.

I would immediately tweak some parts of the proposal. For example, you wrote:

*my_view+*default_view => link

 

1. the name should just be *all+*my view!
2. the content should be {{_self | link}} 

Similarly, where you said "URI+*type+*my_view -> _self" , the content should really be {{_self | core }}. With that in mind, the proposal seems a lot more powerful and less idiosyncratic to me.

 

~~~~

 

At this point, it's probably worth stepping back a bit to distinguish between "structure" and "view" and start contemplating best practices for how the two systems would complement each other. It's worth calling back to mind that you can have (1) structure rules, which effectively define the default content of a given card, and (2) structure directives (eg {{mycard|structure:cardname}}), which override the default content.

The main contrast between views and structures is that structures only change content (and can be used with any view), whereas a view determines how any/all the parts of a card (name, type, content, etc) will be seen and wrapped.

As I think about this, it occurs to me that it's possible that View Rules might obviate the need for structure directives (and improve them by making them set-based). For example, instead of doing:

{{mycard|open; structure:mystructure}}

You would just do:

{{mycard | myview}}

 

...but for this to be identical, we'd need for "myview" to have the equivalent of {{mystructure|open}} in it.

This approach does have a few costs; the most obvious one is that you can't independently set the view and structure.  But I don't think that comes up much, which would mean that the simplicity is probably more benefit than cost. I generally favor making it so that nests have very few arguments; we've worked very hard to keep those minimal. It's also theoretically simpler: a given card has only one current content but can have many views. (structure directives pollute that a bit).

I still think it would be preferable if all these views were defined in a separate namespace, but once we support that, this could be a very cool way to go.  In fact, if we go this route, it occurs to me that we could possibly replace *structure (a standard rule) with *raw (a view rule). I'd be shocked if there weren't a lot of questions to work out there, but there's a natural fit there.

 

One major thing to be considered: how do we handle different formats in all this? In MoFoS, the same view can be different in different formats. View Rules would really need to follow that pattern. Eg Set+Format+View.

 

---

Good discussion. You're right that I didn't really need the default_view thing, just use the *all set to define the fallback view.

On the terminology, I'm not disputing your proposals, just saying that the ambiguity (or not) is by definition/convention. The only reason wagneerable is less ambiguous is familiarity with the conventional use. I was wondering where you got the shark words, but remembered card shark (although I think the term is typically 'sharp').

Not sure how cardable is meaningfully different that nouning cardify as cardifyable and it's shorter.

I'm not sure how we would want to handle Format with view rules, I suspect it would be rare that we would need that use case. Isn't the main variation in formats in the variations that contain the core content. My example using links would hopefully build on standard link formatting which is already varied by format. It is something to think about with the proposal.

---

"sharp" is more common in UK (and implies cheating). "shark" is more common in US.

 

re cardable, I disagree that "the only reason wagneerable is less ambiguous is familiarity with the conventional use". That really misses the point, imo. Obviously we can define "cardable" however we want, but we need to think less like programmers and more like teachers. For something to be intuitive, it needs to fit in nicely with other terms we know. Cardable is less clear than wagneerable because wagneerable fits a constellation of concepts with the 'wagneer' root with an unambiguous definition. "Cardable" lacks this and is thus more likely to encounter confusion, even if we firmly define it.

 

In other words, once I've defined "wagneer" (which itself is made easier to remember because of its connection to "engineer"), "wagneerable" is easy to guess. The same is not true of "cardable". In fact, "wagneerable" is much less common of a term than "wagneer" (verb or noun).

 

It's worth hammering in this point, because there's a recurring theme of treating people a little bit too much like computers. You can't just define your variables and expect people to remember them; you've got to consider their cognitive context.

---

I think both imply cheating, although that implication may be stronger in one case.

I agree that it is important. I think we just have different perspectives on what interpretation is more "natural" in some sense. Ultimately that is a matter of what usage actually occurs "in the wild", but we can start things off better by our own usage.

---

BTW, while I agree that a 'convention' has to be as natural as possible, the point is that this is a domain language (jargon). The larger point you are making is that we have several audiences and we don't want to confuse any of them.

The truth is that for those who don't know the jargon, the distinction isn't even something they know or care about. We could say "card cardable" or "code cardible" to be explicit, but most of the time that is clear from context (if the context is meaningful such that you might care). The in-card vs. in-code distinction is really more about operations and packaging than any deep logical distinction. We could even support very open decks where ruby code that would be in modules now could be in cards. It is an operational concern to make sure they update cleanly, and maybe limit when a reload can happen or even trip it manually, and there are security implications as well. Cardists should understand this distinction, but readers and editors won't know or care.

---

http://grammarist.com/usage/card-shark-card-sharp/ (looks like you're right. "shark" can imply cheating but not as often/strongly as "sharp".

 

I'm confident that if we field-tested this, "cardable" would cause new Cardists a lot more confusion. And in defense of cardable, you're introducing a lot of concepts that would cause even more confusion.

 

> "the point is that this is a domain language (jargon)".

 

That's not *the* point. It's *a* point. It's also part of marketing, community identity, etc. I'm trying to tell you that names matter, and names aren't just unassigned variables. You're acting like we have a tabula rasa here. We do not. We want to build a real community out of real people, and no person is a blank slate.

 

My experience, which I don't intend as an insult (and you're obviously welcomed to disagree with), is that when you (specifically) attempt to teach Wagn to others, they end up more confused than if they just explored on their own. Even in Wagn Circle calls, most people appear to have no idea what you're talking about whenever you speak, and it becomes my job to figure out whether to translate or whether to avoid the topic because it's too deep for the group. IMO, this is because, while you have made a very deep study of Wagn, you have not yet made much study of how to teach it. I've been studying how people learn this and having a lot of success at communicating both its value and how things work.

 

One key issue here is introducing new concepts at a tractable pace. One of the first concepts that we introduce is that "you can do things with Wagn that usually you have to be a coder to do." Then we put ONE TERM on that meme (Wagneer) and we slowly start connecting ideas to it.

 

> "The in-card vs. in-code distinction is really more about operations and packaging than any deep logical distinction."

 

Well there are two important (and different) distinctions that we really need to make and have not made well. One is whether a given task is possible to do by editing cards alone. (which IS a deep logical distinction). Another is whether a task is approachable to a non-coder (a bit more vague, but still a helpful guide). There's a lot of overlap, but your theoretical (though formerly supported) ruby cards reveal the difference. If cardable is more like the former (editable in cards) and wagneerable is more like the latter (approachable to a noncoder), then ruby cards would be cardable but not wagneerable.

 

To me, the term that we need more vitally is the latter. And, perhaps more vitally than that, we need the verb. I hope you won't just keep pretending these are non-issues. I use "wagneer" as a verb all the time, and I'm telling you that it helps.

 

Decktor? (I hardly know her)

---

In case I haven't been clear, I think you are largely right about most of this. I'm not just taking the other side to have an argument, I'm being persuaded in some cases. In other cases we are clarifying by including more detail. I don't think they are non-issues, I just don't think we have the language very settled yet. I like some things, don't like others, and I will really miss some of the good ones we'll have to leave behind.

Yes, there are many points here, I acknowledged that your about teaching and marketing are probably more critical in some ways. As language, it is jargon, a private language, that's a technical point I was making about the status of the kind of usage we are talking about. And I'm totally agreeing with you that the considerations you raise are important as we design this language. At this point I'm not sure what usages are on the table to replace common wagn derived terms. Yes, I really like that wagneer is a noun and verb.

On card vs. code. I think you miss my point. I get that as a practical matter, it is extremely important what you can and can't do strictly in cards. What I'm saying is that where that line gets drawn is ultimately arbitrary. We could put anything that now goes in modules into cards. If/when we move the line to include more stuff (a great recent example is adding machine cards which moves a lot of front-end stuff to cards). That's a perfect example of something that is not particularly wagneerable, but is cardable.

I think that is a point of agreement and a very good thing to be clear on those two things. I guess I was conflating them a bit. Well, there is a scale from simple stuff that's just past editing to more advanced wagneering, and I always assumed that at the advanced end, we are overlapping with development. But if you were editing cards, I always assumed you were doing wagneering. I think it would be great to have a word for each of these, but we still don't have a really good fit for the replacement for wagneer, right?

Decktor is very funny, but it has lots of problems. Although, maybe. I guess you can verb 'doctor' (and by analogy decktor) like engineer.