They are going to add something like PHP/Python/Lua so that you can program the encyclopedia. If you want to participate in the conversation you should join wikitech-l. Cheers ;)
2009/7/1 Brian Brian.Mingus@colorado.edu:
They are going to add something like PHP/Python/Lua so that you can program the encyclopedia. If you want to participate in the conversation you should join wikitech-l. Cheers ;)
"Program the encyclopaedia"? At least try and give people a meaningful idea of what the thread you are pointing them towards is about...
There is a (rather technical) discussion going on about implementing a new language for writing templates to replace the current mess of parser functions.
On Tue, Jun 30, 2009 at 9:09 PM, Thomas Daltonthomas.dalton@gmail.com wrote:
2009/7/1 Brian Brian.Mingus@colorado.edu:
They are going to add something like PHP/Python/Lua so that you can program the encyclopedia. If you want to participate in the conversation you should join wikitech-l. Cheers ;)
"Program the encyclopaedia"? At least try and give people a meaningful idea of what the thread you are pointing them towards is about...
Dude. Go nitpick someone else.
On Tue, Jun 30, 2009 at 8:13 PM, Brian Brian.Mingus@colorado.edu wrote:
On Tue, Jun 30, 2009 at 9:09 PM, Thomas Daltonthomas.dalton@gmail.com wrote:
2009/7/1 Brian Brian.Mingus@colorado.edu:
They are going to add something like PHP/Python/Lua so that you can program the encyclopedia. If you want to participate in the conversation you should join wikitech-l. Cheers ;)
"Program the encyclopaedia"? At least try and give people a meaningful idea of what the thread you are pointing them towards is about...
Dude. Go nitpick someone else.
Your response to Thomas' legitimate point is in poor form. Thomas is right: You provide no context, no direct link to a substantive wikitech-l post, no link to an overview on a meta page, and (more to the point) you gave no indication that the techies actually want non-technical input.
-S
On Tue, Jun 30, 2009 at 10:19 PM, stevertigostvrtg@gmail.com wrote:
You provide no context
The title says it all - MediaWiki is getting a new programming language.
no direct link to a substantive wikitech-l post
I assume, having signed up to this list, that you understand what wikitech-l is and where it is located
(more to the point) you gave no indication that the techies actually want non-technical input.
The fact that the "techies" do not actively seek out community input is why we ended up with ParserFunctions. Furthermore these changes are supposed to be 'community' decisions. The 'techies' are also not the people who edit Wikipedia articles the most. They write code, fix servers etc...
Anyone interested by MediaWiki's new programming language will have no problem finding the conversation based on the information I provided. It is wholly sufficient.
2009/7/1 Brian Brian.Mingus@colorado.edu:
On Tue, Jun 30, 2009 at 10:19 PM, stevertigostvrtg@gmail.com wrote:
You provide no context
The title says it all - MediaWiki is getting a new programming language.
That doesn't even mention the word "template", which is what the whole discussion is about.
(more to the point) you gave no indication that the techies actually want non-technical input.
The fact that the "techies" do not actively seek out community input is why we ended up with ParserFunctions. Furthermore these changes are supposed to be 'community' decisions. The 'techies' are also not the people who edit Wikipedia articles the most. They write code, fix servers etc...
ParserFunctions were implemented because there was a demand for them. One of the greatest strengths and also the greatest weaknesses of the way MediaWiki is developed is that there is very little top-down direction and people just get on and do what seems like a good idea. That results in a lot of quick fixes, like ParserFunctions, which means features that are high in demand get implemented quickly but it also means that the solutions are often far from optimal. I don't see how any of that would be fixed by community discussion. I'm not even sure what community would discuss it - the core Mediawiki code is used by far more than just the English Wikipedia (or even the whole of the Wikimedia movement).
On Tue, Jun 30, 2009 at 10:36 PM, Thomas Daltonthomas.dalton@gmail.com wrote:
I don't see how any of that would be fixed by community discussion. I'm not even sure what community would discuss it - the core Mediawiki code is used by far more than just the English Wikipedia (or even the whole of the Wikimedia movement).
I have not forgotten what many of you have.
Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, as ultimately determined by everybody in Wikipedia, in full consultation with the community consensus. http://en.wikipedia.org/wiki/User:Jimbo_Wales
2009/7/1 Brian Brian.Mingus@colorado.edu:
On Tue, Jun 30, 2009 at 10:36 PM, Thomas Daltonthomas.dalton@gmail.com wrote:
I don't see how any of that would be fixed by community discussion. I'm not even sure what community would discuss it - the core Mediawiki code is used by far more than just the English Wikipedia (or even the whole of the Wikimedia movement).
I have not forgotten what many of you have.
Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, as ultimately determined by everybody in Wikipedia, in full consultation with the community consensus. http://en.wikipedia.org/wiki/User:Jimbo_Wales
You haven't responded to either of the points you quoted...
On Tue, Jun 30, 2009 at 10:43 PM, Thomas Dalton thomas.dalton@gmail.comwrote:
2009/7/1 Brian Brian.Mingus@colorado.edu:
You haven't responded to either of the points you quoted...
Yes, I did. Your comments demonstrate my points. More technically minded folks believe that they can sit down and powwow about the technically best solution to a problem and can't even imagine what sort of input the community could possibly provide. It's totally backwards. The conversation should start on WikiEN-l, not wikitech-l. You have to first adequately characterize a problem before you start implementing solutions.
2009/7/1 Brian Brian.Mingus@colorado.edu:
On Tue, Jun 30, 2009 at 10:43 PM, Thomas Dalton thomas.dalton@gmail.comwrote:
2009/7/1 Brian Brian.Mingus@colorado.edu:
You haven't responded to either of the points you quoted...
Yes, I did. Your comments demonstrate my points. More technically minded folks believe that they can sit down and powwow about the technically best solution to a problem and can't even imagine what sort of input the community could possibly provide. It's totally backwards. The conversation should start on WikiEN-l, not wikitech-l. You have to first adequately characterize a problem before you start implementing solutions.
That's better done by surveying the community, not a community discussion. Anyway, that's only one of the points you quoted. You're still talking as if the English Wikipedia is the only site using MediaWiki.
On Tue, Jun 30, 2009 at 10:52 PM, Thomas Dalton thomas.dalton@gmail.comwrote:
That's better done by surveying the community, not a community discussion.
Yeah, still waiting for that survey. Or that community discussion. Or that usability study. Something tells me that without any griping I will wait forever. I wonder what it is. Oh that's right - precedence. I dug through all of the conversations around ParserFunctions. There wasn't much. It takes a lot of diligence to fully consult the community consensus. It's hard work that developers, historically speaking, haven't card one iota about. Whoever finishes their implementation first and is best friends with a core dev wins.
2009/7/1 Brian Brian.Mingus@colorado.edu:
On Tue, Jun 30, 2009 at 10:52 PM, Thomas Dalton thomas.dalton@gmail.comwrote:
That's better done by surveying the community, not a community discussion.
Yeah, still waiting for that survey. Or that community discussion. Or that usability study. Something tells me that without any griping I will wait forever. I wonder what it is. Oh that's right - precedence. I dug through all of the conversations around ParserFunctions. There wasn't much. It takes a lot of diligence to fully consult the community consensus. It's hard work that developers, historically speaking, haven't card one iota about. Whoever finishes their implementation first and is best friends with a core dev wins.
Technical decisions should not be made by a consensus of laymen.
On Tue, Jun 30, 2009 at 9:23 PM, Brian Brian.Mingus@colorado.edu wrote:
The fact that the "techies" do not actively seek out community input
is why we ended up with ParserFunctions. Furthermore these changes are supposed to be 'community' decisions. The 'techies' are also not the people who edit Wikipedia articles the most. They write code, fix servers etc...
You are not actually correct. Things develop the way they do because they arise as the natural next step. All things improve incrementally, and in accord with available tools and available understanding. You're too young to remember what CamelCase is aren't you?
More technically minded
folks believe that they can sit down and powwow about the technically best solution to a problem and can't even imagine what sort of input the community could possibly provide. It's totally backwards. The conversation should start on WikiEN-l, not wikitech-l. You have to first adequately characterize a problem before you start implementing solutions.
While you are certainly right about this idea that techs can get stuck in certain places that non-tech insights could help with, you are wrong about certain other things. The facts are: They deal with a lot already, they know the work involved for any request, they understand the concepts well enough to know what works and what doesn't, they can reconceptualize ideas and solutions in ways that the rest of us cannot (seen this a dozen times here), and they know very well where the tipping point is when things need to get to the next step.
If there's a technical idea that the tech and general communities need to interface about, write it up in detail on the meta wiki, and give us a link. [[meta:New parser language]] or [[meta:New backend scripting language]] might work.
-Stevertigo
PS: Other comments and responses:
The title says it all - MediaWiki is getting a new programming language.
What does that even mean? That everything in PHP code will be rewritten in Python? Context for non-techies means something you may not yet understand.
It was wholly sufficient.
Your initial message, unlike perhaps your typical coded program, was neither wholly sufficient nor actually sufficient. "Template parser functions" for example, as Tom said, would have provided context.
I assume, having signed up to this list, that you understand what
wikitech-l is and where it is located
1) Dont assume anything. 2) Always provide a link. 3) "Location" does not by itself or in context indicate any relevance. 4) Terseness of the type you provide does not facilitate *any understanding.
Um, why are we giving Brion such a hard time? If his message didn't provide enough details, then a polite request for clarification would be in order; on the contrary, however, some of the replies to his post were just plain rude. I do miss the days when we all played nice. AGK
On Wed, Jul 1, 2009 at 10:59 AM, AGKwikiagk@googlemail.com wrote:
Um, why are we giving Brion such a hard time?
<snip>
Brian, not Brion. :-)
Carcharoth
2009/7/1 Carcharoth carcharothwp@googlemail.com:
On Wed, Jul 1, 2009 at 10:59 AM, AGKwikiagk@googlemail.com wrote:
Um, why are we giving Brion such a hard time?
<snip>
Brian, not Brion. :-)
I think people are giving *Brian* an unfairly hard time because he is giving *Brion* (and the other "techies") an unfairly hard time. :-)
Pete / the wub
On Wed, Jul 1, 2009 at 7:59 PM, AGKwikiagk@googlemail.com wrote:
Um, why are we giving Brion such a hard time?
He posted without enough context, got defensive when that was pointed out, then started snide remarks about developers not consulting the community and therefore making bad decisions. Since you asked.
Now, enough meta-thread?
Steve
On Thu, Jul 2, 2009 at 4:57 AM, Steve Bennettstevagewp@gmail.com wrote:
On Wed, Jul 1, 2009 at 7:59 PM, AGKwikiagk@googlemail.com wrote:
Um, why are we giving Brion such a hard time?
He posted without enough context, got defensive when that was pointed out, then started snide remarks about developers not consulting the community and therefore making bad decisions. Since you asked.
Now, enough meta-thread?
Seemingly not (from the other posts since).
Can someone explain in layman's terms what this programming language thing is and how it relates to templates?
Carcharoth
2009/7/2 Carcharoth carcharothwp@googlemail.com:
Can someone explain in layman's terms what this programming language thing is and how it relates to templates?
OK. Open a complicated template. Let's use {{infobox actor}} here. Look at the wikitext, and you'll see a sea of goop like this:
|image = {{#if:{{{image|}}}|[[File:{{{image|}}}|{{#if:{{{image_size|{{{imagesize|}}}}}}|{{{image_size|{{{imagesize|}}}}}}|220px}}]]}}
That horrible collection of braces is actually the ParserFunctions programming language:
http://www.mediawiki.org/wiki/Extension:ParserFunctions
It lets you make a template that is actually a program to produce nice results from relatively simple template parameters. The language itself is documented here:
http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions
It was created in a completely ad-hoc manner with little planning. So it's (a) all but unreadable (b) hard to program (c) hard to optimise on the server end (where these programs actually run).
So the discussion is about picking a new programming language that wasn't just made up as someone went along. This will have the benefits of allowing more people to get into template programming. This assists the encyclopedia as it lets us make nice templates that do useful things without non-geeks having to understand all the plumbing, it lets geeks do the plumbing behind such things better, and it lets WMF sysadmins run the servers without them melting quite as often.
- d.
On Thu, Jul 2, 2009 at 1:54 PM, Carcharothcarcharothwp@googlemail.com wrote:
Can someone explain in layman's terms what this programming language thing is and how it relates to templates?
It would replace the nightmare parserfunction language in the more complex templates. Here is a random example of one of those type:
http://en.wikipedia.org/w/index.php?title=Template:Backlognav_inner&acti...
It would replace that with something like PHP, javascript, Lua etc. (real languages) We might even get syntax highlighting!
If you don't make or edit these templates it's no big deal to you, it might allow the templates to be even more useful, but definitely won't make them worse. If you do it will be helpful.
Personally any of the listed alternatives are so superior I don't have any preference. :D
On Fri, Jul 3, 2009 at 5:16 AM, Judson Dunncohesion@sleepyhead.org wrote:
It would replace the nightmare parserfunction language in the more complex templates. Here is a random example of one of those type:
http://en.wikipedia.org/w/index.php?title=Template:Backlognav_inner&acti...
The thing I find astonishing is that people are willing to work with these templates and actually maintain them. I've coded regexes, tcl, sh, prolog, haskell, C..., but I have absolutely no desire to get this crap on my hands.
Anyone know if the people who work with these templates are experienced coders, or just wikipedians who have gotten into it as a pleasant sunday afternoon mindfuck?
Steve
The language chosen will hopefully be as ENGLISH-like as possible, even it that means it requires more typing.? The hyper-complex and excessively structured codes of most languages make it difficult for the vast majority of our contributors to even try to make a break into them.
In addition to that, English-like languages are easier for programmers in other languages to pick up because they seem more sensible than learning a whole new set of obscure codewords and symbols.? A language that uses "AND" instead of "&", "+" or "[]".? A language that uses "NOT" instead of "-", "/" or "_".
That would be helpful.
Will Johnson
-----Original Message----- From: Steve Bennett stevagewp@gmail.com To: English Wikipedia wikien-l@lists.wikimedia.org Sent: Thu, Jul 2, 2009 7:11 pm Subject: Re: [WikiEN-l] MediaWiki is getting a new programming language
On Fri, Jul 3, 2009 at 5:16 AM, Judson Dunncohesion@sleepyhead.org wrote:
It would replace the nightmare parserfunction language in the more complex templates. Here is a random example of one of those type:
http://en.wikipedia.org/w/index.php?title=Template:Backlognav_inner&acti...
The thing I find astonishing is that people are willing to work with these templates and actually maintain them. I've coded regexes, tcl, sh, prolog, haskell, C..., but I have absolutely no desire to get this crap on my hands.
Anyone know if the people who work with these templates are experienced coders, or just wikipedians who have gotten into it as a pleasant sunday afternoon mindfuck?
Steve
_______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, Jul 2, 2009 at 10:23 PM, wrote:
In addition to that, English-like languages are easier for programmers in other languages to pick up because they seem more sensible than learning a whole new set of obscure codewords and symbols.? A language that uses "AND" instead of "&", "+" or "[]".? A language that uses "NOT" instead of "-", "/" or "_".
That would be helpful.
Will Johnson
ADD COBOL TO SUGGESTED-LANGUAGES GIVING REJECTION.
- -- gwern
On Fri, Jul 3, 2009 at 12:23 PM, wjhonson@aol.com wrote:
The language chosen will hopefully be as ENGLISH-like as possible, even it that means it requires more typing.? The hyper-complex and excessively structured codes of most languages make it difficult for the vast majority of our contributors to even try to make a break into them.
In addition to that, English-like languages are easier for programmers in other languages to pick up because they seem more sensible than learning a whole new set of obscure codewords and symbols.? A language that uses "AND" instead of "&", "+" or "[]".? A language that uses "NOT" instead of "-", "/" or "_".
I don't know if "programmability by a non-technical users" is a major requirement. The real requirements are: 1) Secure 2) Fast 3) Sane, maintainable language 4) Existing interpreter. (Therefore, existing language...)
Well I think you know that isn't what I said. You half-read what I wrote and responded. Creating even higher barriers for people isn't the way to openness.
<<I don't know if "programmability by a non-technical users" is a major requirement.>>
-----Original Message----- From: Steve Bennett stevagewp@gmail.com To: English Wikipedia wikien-l@lists.wikimedia.org Sent: Thu, Jul 2, 2009 8:47 pm Subject: Re: [WikiEN-l] MediaWiki is getting a new programming language
On Fri, Jul 3, 2009 at 12:23 PM, wjhonson@aol.com wrote:
?The language chosen will hopefully be as ENGLISH-like as possible, even it
that means it requires more typing.? The hyper-complex and excessively structured codes of most languages make it difficult for the vast majority of our contributors to even try to make a break into them.
In addition to that, English-like languages are easier for programmers in
other languages to pick up because they seem more sensible than learning a whole new set of obscure codewords and symbols.? A language that uses "AND" instead of "&", "+" or "[]".? A language that uses "NOT" instead of "-", "/" or "_".
I don't know if "programmability by a non-technical users" is a major requirement. The real requirements are: 1) Secure 2) Fast 3) Sane, maintainable language 4) Existing interpreter. (Therefore, existing language...)
_______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On Fri, Jul 3, 2009 at 12:27 AM, wjhonson@aol.com wrote:
Well I think you know that isn't what I said. You half-read what I wrote and responded. Creating even higher barriers for people isn't the way to openness.
Do you really think any of these would be a higher barrier for entry than the current template and parser-functions system? Possibly the current system is more egalitarian only in that it is painful for those who do know how to program as well as those who don't.
-Matt
On Thu, Jul 2, 2009 at 10:23 PM, wjhonson@aol.com wrote:
The language chosen will hopefully be as ENGLISH-like as possible, even it that means it requires more typing.? The hyper-complex and excessively structured codes of most languages make it difficult for the vast majority of our contributors to even try to make a break into them.
Excessively English-like code is harder to work with, not easier. Normally there are many ways to say something in English, and the language has to arbitrarily pick one or two to support but not any others. That leads to considerable inconsistency. From experience, "easy-to-use" languages end up being harder to work with and maintain on serious projects. Look at the average programmer's attitude to COBOL or SQL. Such languages have been tried and are almost universally agreed to be inferior by the people who actually have to use them.
That's not to say you can't have reasonably understandable notation in a good language. I think Python strikes an excellent balance here. But setting out to avoid "excessively structured" code is a bad idea.
Expecting a majority of our contributors to be able to contribute to anything programming-related is unrealistic in any event. A majority of people who take introductory programming courses get an F -- and that's even in the self-selected group that wants to learn how to program. It's not because the teachers or languages make it hard. It's because most people just have a really difficult time understanding how to program.
Happily, it's not necessary that the *average* user be able to contribute to programming. Only people who want to write flexible templates will have to learn the syntax in any case. The large majority of users can stick to writing content, RC patrol, and a million other things that are at least as important.
On Thu, Jul 2, 2009 at 7:23 PM, wjhonson@aol.com wrote:
The language chosen will hopefully be as ENGLISH-like as possible, even it that means it requires more typing.? The hyper-complex and excessively structured codes of most languages make it difficult for the vast majority of our contributors to even try to make a break into them. In addition to that, English-like languages are easier for programmers in other languages to pick up because they seem more sensible than learning a whole new set of obscure codewords and symbols.? A language that uses "AND" instead of "&", "+" or "[]".? A language that uses "NOT" instead of "-", "/" or "_".
It's easy to be a native English speaker and then demand another system to be parasitic to it. Note that if "English" itself isn't sufficient where "English" lacks the required (programming) concepts. And there's probably no issue of using Farsi or Bengali anyway, as all/most programming languages are already parasitic to English. (Lua, mentioned previously, written by Brazilians, does not use Portuguese for anything other than its name).
Part of the idea to begin with for using arbitrary symbols for operator symbols is to strengthen the projections between programming and mathematics, and maybe also in a certain way to transcend natural language peculiarities. It's not about efficiency == parasitism to English, but its about representing computing as mathematics. AIUI. Of course the ASCII dependency issue puts characteristic limitations (what WJ calls "easier") on things, but that's out of scope.
-Steve
On Fri, Jul 3, 2009 at 9:45 AM, stevertigostvrtg@gmail.com wrote:
"Note that *if* "English" itself isn't sufficient where "English" lacks the required (programming) concepts.
Should be: Note that English itself...
-Steve
On Thu, Jul 2, 2009 at 19:23, wjhonson@aol.com wrote:
The language chosen will hopefully be as ENGLISH-like as possible, even it that means it requires more typing.? The hyper-complex and excessively structured codes of most languages make it difficult for the vast majority of our contributors to even try to make a break into them.
In addition to that, English-like languages are easier for programmers in other languages to pick up because they seem more sensible than learning a whole new set of obscure codewords and symbols.? A language that uses "AND" instead of "&", "+" or "[]".? A language that uses "NOT" instead of "-", "/" or "_".
Every few years, English-derived programming languages become fashionable as a solution for programming being difficult, and every few years, another generation of advocates discovers that it isn't the obscure codewords and symbols that make programming difficult.
2009/7/7 Mark Wagner carnildo@gmail.com:
Every few years, English-derived programming languages become fashionable as a solution for programming being difficult, and every few years, another generation of advocates discovers that it isn't the obscure codewords and symbols that make programming difficult.
Programing being difficult isn't out problem (at least not going by what people have managed to do with templates so far). Programing being inaccessible is.
On Mon, Jul 6, 2009 at 6:58 PM, genigeniice@gmail.com wrote:
Programing being difficult isn't out problem (at least not going by what people have managed to do with templates so far). Programing being inaccessible is.
Including being inaccessible even to trained programmers.
It strikes me that in the current Wikipedia template-programming system that we've managed to create a "perfect storm", a worse solution for everyone. We're in, at least, the easy situation in which almost any alternative would be better.
-Matt
Matthew Brown wrote:
It strikes me that in the current Wikipedia template-programming system that we've managed to create a "perfect storm", a worse solution for everyone. We're in, at least, the easy situation in which almost any alternative would be better.
To be fair, there are tens of thousands of template, they basically work, and one can usually make a new one by finding an old one and changing some text. This snafu is just that, the way WP works "in practice not in theory". Not that the template issue shouldn't be addressed when the kludginess starts hitting home; but as they say "Le mieux est l'ennemi du bien" ([[:q:Voltaire]]). Fortunately your sentiments are compatible with mine.
Charles //
On Tue, Jul 7, 2009 at 6:00 AM, Charles Matthewscharles.r.matthews@ntlworld.com wrote:
Not that the template issue shouldn't be addressed when the kludginess starts hitting home; but as they say "Le mieux est l'ennemi du bien" ([[:q:Voltaire]]). Fortunately your sentiments are compatible with mine.
To be fair, the current system has some advantages:
1) It's implemented purely in PHP, and thus does not require the installer to be able to compile code or install it; furthermore, since it works on any system that PHP works on, it adds no compatibility issues. 2) It is adequately sandboxed and programs written in it cannot escape into the system that runs MediaWiki. 3) It has pretty tight resource limits making it hard (though not impossible) to DoS a MediaWiki host through the template language.
It's going to be tricky to keep all of those with another language; it's quite likely that point 1 will be lost in any replacement, for instance, unless we're willing to put in a lot of work polishing up a language parser written in PHP (there are PHP Javascript engines, for instance, but all would require significant work to be usable).
-Matt
On Thu, Jul 2, 2009 at 7:11 PM, Steve Bennett stevagewp@gmail.com wrote:
The thing I find astonishing is that people are willing to work with these templates and actually maintain them. I've coded regexes, tcl, sh, prolog, haskell, C..., but I have absolutely no desire to get this crap on my hands.
Hm. That "crap" seems to have worked quite well for a few years now.
-Steve
On Thu, Jul 2, 2009 at 10:09 PM, stevertigostvrtg@gmail.com wrote:
On Thu, Jul 2, 2009 at 7:11 PM, Steve Bennett stevagewp@gmail.com wrote:
The thing I find astonishing is that people are willing to work with these templates and actually maintain them. I've coded regexes, tcl, sh, prolog, haskell, C..., but I have absolutely no desire to get this crap on my hands.
Hm. That "crap" seems to have worked quite well for a few years now.
A function, I think, of the desire for programmability, rather than the qualities of the language.
-Matt
On Thu, Jul 2, 2009 at 9:11 PM, Steve Bennettstevagewp@gmail.com wrote:
Anyone know if the people who work with these templates are experienced coders, or just wikipedians who have gotten into it as a pleasant sunday afternoon mindfuck?
I've done a few, not as complex as that one. It's not that complicated, it's just that the logic is all nested bracket based things so it looks terrible and is hard to read. I would say I'm an amateur coder. :)
A simple statement starts out ok, it's just the nesting that makes them crazy, and {} brackets are used for almost everything.
{{#ifeq: string 1 | string 2 | value if true | value if false }} .
Also, when you pass variables in, those are often numbered, and they are frequently in the if statements so you get {{{1}}} things, and you want to use templates in them, which also use {{brackets}} So everything is using brackets and nesting. The parser is magic. :)
I didn't mean to make it seem like I didn't like parserfunctions and templates. They are amazing, and I think one of the coolest and most innovative parts about mediawiki honestly.
They basically allow general users to create content methods on the fly that can do a ton of work. I think they are instrumental in the fast development of a lot of features that would have taken much longer had the user had to explain their vision to a developer.
Templates and parserfunctions are one of the best examples of transparency and editor agency on wikipedia.
On Fri, Jul 3, 2009 at 6:21 PM, Judson Dunncohesion@sleepyhead.org wrote:
<snip>
{{#ifeq: string 1 | string 2 | value if true | value if false }} .
The help pages for templates are not very helpful.
Instinctively, and by looking at examples, I sort of know the above, but I've never seen a help page that clearly explains how to use templates and parser functions, let alone how to construct tables (more a WYSIWYG problem). Maybe I've been looking at the wrong pages, but if there are pages that clearly teach people how to construct templates and tables, I'd really like to be pointed at them.
Carcharoth
2009/7/3 Carcharoth carcharothwp@googlemail.com:
On Fri, Jul 3, 2009 at 6:21 PM, Judson Dunncohesion@sleepyhead.org wrote:
<snip>
{{#ifeq: string 1 | string 2 | value if true | value if false }} .
The help pages for templates are not very helpful.
Instinctively, and by looking at examples, I sort of know the above, but I've never seen a help page that clearly explains how to use templates and parser functions, let alone how to construct tables (more a WYSIWYG problem). Maybe I've been looking at the wrong pages, but if there are pages that clearly teach people how to construct templates and tables, I'd really like to be pointed at them.
Carcharoth
Tables are an issue yes. I don't do much with templates but when I've wanted to use ParserFunctions I've either copied and pasted or worked from
http://www.mediawiki.org/wiki/Help:ParserFunctions
On the other hand the formal help page is a complete mess:
http://en.wikipedia.org/wiki/Help:Template
On Fri, Jul 3, 2009 at 11:53 AM, Carcharothcarcharothwp@googlemail.com wrote:
On Fri, Jul 3, 2009 at 6:21 PM, Judson Dunncohesion@sleepyhead.org wrote:
<snip>
{{#ifeq: string 1 | string 2 | value if true | value if false }} .
The help pages for templates are not very helpful.
Instinctively, and by looking at examples, I sort of know the above, but I've never seen a help page that clearly explains how to use templates and parser functions, let alone how to construct tables (more a WYSIWYG problem). Maybe I've been looking at the wrong pages, but if there are pages that clearly teach people how to construct templates and tables, I'd really like to be pointed at them.
I think I can say with some authority that the existing help pages on templates -- both for casual users and programmers, but especially for those who want to start understanding parserfunctions and how to construct a template from scratch -- completely suck. If there's any template gurus out there who have some spare time and want to work on the documentation, you'd be doing a huge community service.
The table help pages in the MediaWiki manual are ok, but on en:wp need to be re-integrated with the en:wp documentation; similar information is spread over several pages and you just have to know that some features exist, e.g. sortable tables.
-- phoebe
2009/7/3 Steve Bennett stevagewp@gmail.com:
The thing I find astonishing is that people are willing to work with these templates and actually maintain them. I've coded regexes, tcl, sh, prolog, haskell, C..., but I have absolutely no desire to get this crap on my hands. Anyone know if the people who work with these templates are experienced coders, or just wikipedians who have gotten into it as a pleasant sunday afternoon mindfuck?
You mean, of course, [[Brainfuck]].
I'm wondering if we could do our templates in BANCstar.
- d.
2009/7/1 AGK wikiagk@googlemail.com:
Um, why are we giving Brion such a hard time? If his message didn't provide enough details, then a polite request for clarification would be in order; on the contrary, however, some of the replies to his post were just plain rude. I do miss the days when we all played nice.
I was already annoyed at him because of his nonsensical comments in the thread he was referencing, so that may have resulted in my original reply being a little more harsh than it would usually have been. I stand by everything I said, though.
Thomas Dalton wrote:
2009/7/1 AGK wikiagk@googlemail.com:
Um, why are we giving Brion such a hard time? If his message didn't provide enough details, then a polite request for clarification would be in order; on the contrary, however, some of the replies to his post were just plain rude. I do miss the days when we all played nice.
I was already annoyed at him because of his nonsensical comments in the thread he was referencing, so that may have resulted in my original reply being a little more harsh than it would usually have been. I stand by everything I said, though.
Brian or Brion?
-Cary
On Thu, Jul 2, 2009 at 2:49 PM, Cary Basscary@wikimedia.org wrote:
Thomas Dalton wrote:
I was already annoyed at him because of his nonsensical comments in the thread he was referencing, so that may have resulted in my original reply being a little more harsh than it would usually have been. I stand by everything I said, though.
Brian or Brion?
Brian.
On Thu, Jul 2, 2009 at 2:54 PM, Carcharothcarcharothwp@googlemail.com wrote:
Can someone explain in layman's terms what this programming language thing is and how it relates to templates?
It's not anything unless we can figure out something workable, which isn't clear. The idea would be that instead of using ParserFunctions for programming templates, a "real" language like Lua/JavaScript/PHP/Python/etc. would be made available. This would potentially allow much better template performance and maintenance. It would have no direct effect on people other than template authors, except that some templates could potentially be made more automated and thus easier to use.
However, it's not clear that we can implement a language in a way that's secure, efficient, *and* usable by wikis on shared hosting, so I don't know whether anything will come of this.
On Wed, Jul 1, 2009 at 1:13 PM, BrianBrian.Mingus@colorado.edu wrote:
On Tue, Jun 30, 2009 at 9:09 PM, Thomas Daltonthomas.dalton@gmail.com wrote:
2009/7/1 Brian Brian.Mingus@colorado.edu:
They are going to add something like PHP/Python/Lua so that you can program the encyclopedia. If you want to participate in the conversation you should join wikitech-l. Cheers ;)
"Program the encyclopaedia"? At least try and give people a meaningful idea of what the thread you are pointing them towards is about...
Dude. Go nitpick someone else.
Here's the quick summary: The senior techie MediaWiki people (Brion Vibber, Tim Starling et al) are discussing alternatives to the current ad-hoc templating language, including Python, PHP, Lua and server side JavaScript. No decisions have been made, and nothing may eventuate, but with Brion's support, something is sure to happen.
The thread is "On templates and programming languages" on Wikitech-L.
Steve