[[:en:Category:If Templates]] [[:en:Category:Boolean Templates]]
Check out some of the code in them, too, but make sure you haven't eaten first.
The perpetrators of this l33tn3ss are trying to gut [[:en:WP:AUM]] by consensus, because everyone knows database performance and computer science in general can be determined by voting. Or maybe it can't.
What would the Stupid Mediawiki Tricks in these things do to the database and the cache structure? If it's as bad as I suspect it would, could some of you please stop by [[:en:WT:AFD]] and describe reality to them?
- d.
"David Gerard" fun@thingy.apana.org.au wrote in message news:439A1430.5050100@thingy.apana.org.au...
[[:en:Category:If Templates]] [[:en:Category:Boolean Templates]]
Check out some of the code in them, too, but make sure you haven't eaten first.
The perpetrators of this l33tn3ss are trying to gut [[:en:WP:AUM]] by consensus, because everyone knows database performance and computer science in general can be determined by voting. Or maybe it can't.
What would the Stupid Mediawiki Tricks in these things do to the database and the cache structure? If it's as bad as I suspect it would, could some of you please stop by [[:en:WT:AFD]] and describe reality to them?
If the repeated requests for the ability to do this type of thing **without** resorting to "clever tricks" had been responded to, this is the kind of thing up with which you would not have to put.
Some people are trying their hardest to avoid duplicating the functionality in multiple templates, so that when (!) it can be hard-wired into the Template Syntax it will be as easy as possible to switch over.
Sadly. some are not, and there are a number of duplications. My personal bug-bear is {{qif}}, mainly because I cannot for the life of me see what it can do that {{if}} cannot.
Furthermore, as you well know, once the code in those "horrible" templates is stable, the effect on the caching system is much reduced. AFAIK the code on these templates is thoroughly checked and stable.
Flame-free help would be much appreciated. High-handed measures like those I suspect you are suggesting above will simply inflame matters and help Wikipedia very little.
"Phil Boswell" phil.boswell@gmail.com wrote in message news:dnk5ht$8e6$1@sea.gmane.org... [snip]
... My personal bug-bear is {{qif}}, mainly because I cannot for the life of me see what it can do that {{if}} cannot.
Now that I have taken another look at it, I think that it is actually doing something extremely clever. The wikicode is:
{{{else{{{test|}}}|{{{test{{{test|}}}|{{{then|}}}}}}}}}
You call it like this: {{qif |test=VARIABLE_OR_PARAMETER_TO_TEST |then=code if 'test' is not empty |else=code if 'test' is empty }}
It relies on the relatively-recent optional value system, where {{{parameter|value}}} gives you "value" if "parameter" is blank, otherwise "parameter".
So if I introduce a bit of white-space to make it easier to read the operation becomes a little more apparent: {{{ else {{{ test | }}} | {{{ test {{{ test | }}} | {{{ then | }}} }}} }}}
If 'test' is empty, this reduces to: {{{ else {{{ | }}} | {{{ {{{ | }}} | {{{ then | }}} }}} }}} and thus to: {{{ else | {{{ | {{{ then | }}} }}} }}} and assuming that 'else' is non-empty this simply gives else
If 'test' is *not* empty, then the original reduces to: {{{ else {{{ test }}} | {{{ test {{{ test }}} | {{{ then | }}} }}} }}} and thus to: {{{ elsetest | {{{ testtest | {{{ then | }}} }}} }}} Now 'elsetest' is perforce empty, since it's a whole new "parameter" giving: {{{ testtest | {{{ then | }}} }}} and the same goes for 'testtest':
{{{ then | }}} which trivially reduces to: then
Takes me back to my (admittedly brief) functional programming days and the dreaded lambda calculus :-)
So whether this template is more efficient than {{if}} basically boils down to whether the Template Syntax code can perform the transformations detailed above quicker than the extra fetch which the slightly-simpler {{if}} requires, relying on the trick whereby if you specify two parameters with the same name, Mediawiki discards the first and uses the second, passing parameters to a supporting template named {{show1}}.
I'm betting on the code beating the fetching by a long margin. So until we can persuade some kind developer to implement the "if" functionality in Mediawiki, I'm championing {{qif}}. It would be nice if we could retire the current version of {{if}} and re-use that name, but the nice thing about a wiki is that you can take things just about as slow as you like, provided nobody jogs your elbow.
HTH HAND
Phil Boswell wrote:
"Phil Boswell" phil.boswell@gmail.com wrote in message news:dnk5ht$8e6$1@sea.gmane.org... [snip]
... My personal bug-bear is {{qif}}, mainly because I cannot for the life of me see what it can do that {{if}} cannot.
Now that I have taken another look at it, I think that it is actually doing something extremely clever.
That's why I awarded Carl [[en:User:AzaToth]] a technology barnstar.
And because it eliminates one template call level, compared to {{if}} (In Re "meta-templates").
[snip] It would be nice if we could retire the current version of {{if}} and re-use that name, but the nice thing about a wiki is that you can take things just about as slow as you like, provided nobody jogs your elbow.
Yes that would be nice. One problem is that the old {{if}} unfortunately provides also a usage variant that provides unnamed parameters, which {{qif}}} deliberatley does not for speed, simplicity and '='-char safety (template artist Carl tried to do that in qif, but the outcome was code that even shocked me :-).
For this reason it comes handy that {{if}} has been given that new "test", "then" "else" parameter set as a migration path.
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
On Monday 12 December 2005 18:59, Phil Boswell wrote:
"Phil Boswell" phil.boswell@gmail.com wrote in message news:dnk5ht$8e6$1@sea.gmane.org... [snip]
... My personal bug-bear is {{qif}}, mainly because I cannot for the life of me see what it can do that {{if}} cannot.
Now that I have taken another look at it, I think that it is actually doing something extremely clever. The wikicode is:
[snip a lot]
While clever, that doesn't mean it is good. Not every thing you can do, you also should do. :)
Takes me back to my (admittedly brief) functional programming days and the dreaded lambda calculus :-)
So whether this template is more efficient than {{if}} basically boils down to whether the Template Syntax code can perform the transformations detailed above quicker than the extra fetch which the slightly-simpler {{if}} requires, relying on the trick whereby if you specify two parameters with the same name, Mediawiki discards the first and uses the second, passing parameters to a supporting template named {{show1}}.
I'm betting on the code beating the fetching by a long margin. So until we can persuade some kind developer to implement the "if" functionality in Mediawiki, I'm championing {{qif}}. It would be nice if we could retire the current version of {{if}} and re-use that name, but the nice thing about a wiki is that you can take things just about as slow as you like, provided nobody jogs your elbow.
I you thought that script languages like Perl, PHP, phyton, etc were slow, then this system has to beat them hands down. I can't even imagine how much CPU cycles must be burned for such a thing. Thank god it is only executed on rendering the page, once, and not for every view.
I can see it now:
* After {{{qif}}, somebody implements loops. * Soon lexial scoping, the switch statement and subroutines follow. * 5 days later the wiki-template system is turing-complete. * 2 days later a careless placed "{" triggers an endless loop and brings wikipedia down for 2 3/4 hours, until the bug is fixed. * 1 hour later JoeCleverProgrammer posts his brainfuck-interpreter, done entirely with "clever" templates in wikitext. * a week later the first page consisting only of curly braces, the pipe symbol, spaces and newlines is spotted. When viewed in a browser, it renders as "kilroy was here", due to a clever abuse of templates, variables, bugs and some unrelated accident involving a pound of butter, a slippery server room floor and an unfortunately placed button.
Joking aside, IMHO, if that sort of (ab)use of templates continues, soon the only people qualified to edit pages will be programmers. The wikisyntax is a success because it is so easy and maintainable/readable by mere humans. Crafting "clever" systems on top of it will merely make normal humans go away as they will not be able to understand this stuff even after staring on the curly mess for an hour.
Case in point is that regular contributors to smaller wikis already struggle with the table syntax or even simple templates. Variable substitution and conditional template inclusion will break their little minds.
Best wishes,
Tels
- -- Signed on Mon Dec 12 21:27:19 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"Elliot, Sie Schwachkopf!"
"Tels" wrote:
[snip] I can see it now:
- After {{{qif}}, somebody implements loops.
Very very unlikely. Would need anything like jumping to some label. If something is ridiculous, then it's this.
- Soon lexial scoping, the switch statement and subroutines follow.
Switch is already there: [[en:Template:Switch]]. Subroutines also (quite for a while :-).
- 5 days later the wiki-template system is turing-complete.
Ouch!
- 2 days later a careless placed "{" triggers an endless loop and brings wikipedia down for 2 3/4 hours, until the bug is fixed.
Your confidence in WikiMedia software seems not to be that huge.
- 1 hour later JoeCleverProgrammer posts his brainfuck-interpreter, done entirely with "clever" templates in wikitext.
- a week later the first page consisting only of curly braces, the pipe symbol, spaces and newlines is spotted. When viewed in a browser, it renders as "kilroy was here", due to a clever abuse of templates, variables, bugs and some unrelated accident involving a pound of butter, a slippery server room floor and an unfortunately
placed button.
And then all aficionados of qif are burnt at the stake after a furious witch-hunt.
Joking aside, IMHO, if that sort of (ab)use of templates continues, soon the only people qualified to edit pages will be programmers. The wikisyntax is a success because it is so easy and maintainable/readable by mere humans. Crafting "clever" systems on top of it will merely make normal humans go away as they will not be able to understand this stuff even after staring on the curly mess for an hour.
qif is not a curly mess.
No. All that hot stuff is packaged securely inside if/qif. And there are enough gurus that understand this and can maintain it. It's already very stable. And using if/qif (especially qif) does not require a MSc in brainfuck. And it will be implemented in the template syntax anyway, sooner or later.
Case in point is that regular contributors to smaller wikis already struggle with the table syntax or even simple templates. Variable substitution and conditional template inclusion will break their little minds.
The wast majority of users will never touch or even look at those templates that use if/qif. They just use [[en:template:book reference]] (or whatever).
And nobody will ever be pressed to use if/qif. It's an add-on, not a replacement.
On 12/13/05, Adrian Buehlmann adrian@cadifra.com wrote:
qif is not a curly mess.
No. All that hot stuff is packaged securely inside if/qif. And there are enough gurus that understand this and can maintain it. It's already very stable. And using if/qif (especially qif) does not require a MSc in brainfuck. And it will be implemented in the template syntax anyway, sooner or later.
It might be a good idea to protect all of those templates to prevent horrible consequences in the event of vandalism. If the syntax is really stable, then there shouldn't be any problems with that.
-- Stephen Bain stephen.bain@gmail.com
On 12/13/05, Stephen Bain stephen.bain@gmail.com wrote:
It might be a good idea to protect all of those templates to prevent horrible consequences in the event of vandalism. If the syntax is really stable, then there shouldn't be any problems with that.
I've now started a proposal to protect all these horrible templates at: [[Wikipedia:High-risk templates]] http://en.wikipedia.org/wiki/Wikipedia:High-risk_templates
-- Stephen Bain stephen.bain@gmail.com
Phil Boswell wrote:
Now that I have taken another look at it, I think that it is actually doing something extremely clever. The wikicode is:
{{{else{{{test|}}}|{{{test{{{test|}}}|{{{then|}}}}}}}}}
For quite some time (1973-1993 or so), the Unix/Linux commands test(1), true(1) and false(1) were stand-alone programs that required the fork(2) and exec(2) of a new process, after which the shell would check their exit status. In modern Unix shells (such as bash(1)) these are built-in commands, which makes their frequent use in scripts a lot more efficient.
Why not give up this {{{if}}} template craziness and implement a basic set of programming logic operators (if, for, foreach, while, switch, ...) in the wiki syntax? Programming logic embedded in textual content is well-known from languages like PHP.
"Lars Aronsson" lars@aronsson.se wrote in message news:Pine.LNX.4.61.0512141434370.22021@sara.aronsson.se...
Phil Boswell wrote:
[snip]
Why not give up this {{{if}}} template craziness and implement a basic set of programming logic operators (if, for, foreach, while, switch, ...) in the wiki syntax? Programming logic embedded in textual content is well-known from languages like PHP.
Why not indeed?
Someone explain to this good gentleman some of the history of this particular little scenario while I go and bang my head against a nice soft wall ...
-----BEGIN PGP SIGNED MESSAGE-----
Moin,
On Wednesday 14 December 2005 15:36, Phil Boswell wrote:
"Lars Aronsson" lars@aronsson.se wrote in message news:Pine.LNX.4.61.0512141434370.22021@sara.aronsson.se...
Phil Boswell wrote:
[snip]
Why not give up this {{{if}}} template craziness and implement a basic set of programming logic operators (if, for, foreach, while, switch, ...) in the wiki syntax? Programming logic embedded in textual content is well-known from languages like PHP.
Why not indeed?
Someone explain to this good gentleman some of the history of this particular little scenario while I go and bang my head against a nice soft wall ...
Exactly. This would replicate the "macro-in-document" scenario, and we all know what that leads to...
May I remind everyone wanting programming logic in text documents (aka wiki pages) on this little gem:
http://namb.la/popular/tech.html
You have been warned.
Tels
- -- Signed on Sun Dec 18 11:23:52 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"One man in a thousand is a leader of men, the other 999 follow women" -- Groucho Marx
Lars Aronsson wrote:
Why not give up this {{{if}}} template craziness and implement a basic set of programming logic operators (if, for, foreach, while, switch, ...) in the wiki syntax? Programming logic embedded in textual content is well-known from languages like PHP.
Can we hold off on the "while"? Just don't make it Turing-complete ...
- d.
"Lars Aronsson" lars@aronsson.se wrote in message news:Pine.LNX.4.61.0512141434370.22021@sara.aronsson.se
Phil Boswell wrote:
Now that I have taken another look at it, I think that it is actually doing something extremely clever. The wikicode is:
{{{else{{{test|}}}|{{{test{{{test|}}}|{{{then|}}}}}}}}}
For quite some time (1973-1993 or so), the Unix/Linux commands test(1), true(1) and false(1) were stand-alone programs that required the fork(2) and exec(2) of a new process, after which the shell would check their exit status. In modern Unix shells (such as bash(1)) these are built-in commands, which makes their frequent use in scripts a lot more efficient.
Why not give up this {{{if}}} template craziness and implement a basic set of programming logic operators (if, for, foreach, while, switch, ...) in the wiki syntax? Programming logic embedded in textual content is well-known from languages like PHP.
See [[m:User:AzaToth/Logic]] which is http://meta.wikimedia.org/wiki/User:AzaToth/Logic
Many thanks to Carl (aka AzaToth)!
I made a quick mockup of what I consider would be a nice advanced template syntax the other day, I guess this is as good a place to throw it into the ring as any.
Proposed syntax: http://kohl.wikimedia.org/~avar/syntax
Some key points that have to be considered:
* People don't want or need a wiki programming language, the execution time of this should be kept to a minimum and the language should focus on what people generally need to do, which is to have conditional templates, a proper template language done well should outperform the current template hacks. * I put some operators there which I thought might be useful: defined length < > <= >= == eq ne lt gt le ge and or xor not I'm still not sure about the usefulness of the length() function though.
"Ævar Arnfjörð Bjarmason" avarab@gmail.com wrote in message news:51dd1af80512122254p24be0d0aq1f3f4595c365b13b@mail.gmail.com...
I made a quick mockup of what I consider would be a nice advanced template syntax the other day, I guess this is as good a place to throw it into the ring as any. Proposed syntax: http://kohl.wikimedia.org/~avar/syntax
Sorry: given the current circumstances, nesting is not negotiable :-)
What would be the ideal first step would be if someone could simply implement the functionality of the {{if}} or {{qif}} template in wikicode. This would simply test whether a supplied argument is blank or non-blank and thereby choose one of two options to transclude.
We already have the {{fullurl:pagename|actionstring}} and {{localurl:pagename|actionstring}} operators. It's not a huge leap to {{if:test|thenstring|elsestring}} is it?
Announcing a nice new page (no pun intended):
[[m:Help:Parameter default]] http://meta.wikimedia.org/wiki/Help:Parameter_default
Describes the basics for the new template tricks. Kudos to Patrick and AzaToth.
wikitech-l@lists.wikimedia.org