On Tue, Jun 30, 2009 at 8:13 PM, Brian <Brian.Mingus(a)colorado.edu> wrote: 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

2009/7/1 Brian <Brian.Mingus(a)colorado.edu>du>: That doesn't even mention the word "template", which is what the whole discussion is about. 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).

2009/7/1 Brian <Brian.Mingus(a)colorado.edu>du>: You haven't responded to either of the points you quoted...

2009/7/1 Brian <Brian.Mingus(a)colorado.edu>du>: 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.

2009/7/1 Brian <Brian.Mingus(a)colorado.edu>du>: Technical decisions should not be made by a consensus of laymen.

On Tue, Jun 30, 2009 at 9:23 PM, Brian <Brian.Mingus(a)colorado.edu> wrote: The fact that the "techies" do not actively seek out community input 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 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.

On Wed, Jul 1, 2009 at 10:59 AM, AGK&lt;wikiagk(a)googlemail.com&gt; wrote: <snip> Brian, not Brion. :-) Carcharoth

Oops - I misread. My comment stands. ;) AGK

On Thu, Jul 2, 2009 at 4:57 AM, Steve Bennett&lt;stevagewp(a)gmail.com&gt; wrote: 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

On Thu, Jul 2, 2009 at 1:54 PM, Carcharoth&lt;carcharothwp(a)googlemail.com&gt; 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&act… 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 Judson http://en.wikipedia.org/wiki/User:Cohesion

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 &lt;stevagewp(a)gmail.com&gt; To: English Wikipedia &lt;wikien-l(a)lists.wikimedia.org&gt; 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 Dunn&lt;cohesion(a)sleepyhead.org&gt; 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. 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(a)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:23 PM, &lt;wjhonson(a)aol.com&gt; wrote: 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...)

On Fri, Jul 3, 2009 at 12:27 AM, &lt;wjhonson(a)aol.com&gt; wrote: 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 7:23 PM, &lt;wjhonson(a)aol.com&gt; wrote: 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 Thu, Jul 2, 2009 at 19:23, &lt;wjhonson(a)aol.com&gt; wrote: 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. -- Mark [[User:Carnildo]]

On Mon, Jul 6, 2009 at 6:58 PM, geni&lt;geniice(a)gmail.com&gt; wrote: 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

On Tue, Jul 7, 2009 at 6:00 AM, Charles Matthews&lt;charles.r.matthews(a)ntlworld.com&gt; wrote: 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 10:09 PM, stevertigo&lt;stvrtg(a)gmail.com&gt; wrote: A function, I think, of the desire for programmability, rather than the qualities of the language. -Matt

On Fri, Jul 3, 2009 at 6:21 PM, Judson Dunn&lt;cohesion(a)sleepyhead.org&gt; wrote: <snip> 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

On Fri, Jul 3, 2009 at 11:53 AM, Carcharoth&lt;carcharothwp(a)googlemail.com&gt; wrote: 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/1 AGK &lt;wikiagk(a)googlemail.com&gt;om>: 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.

On Thu, Jul 2, 2009 at 2:49 PM, Cary Bass&lt;cary(a)wikimedia.org&gt; wrote: Brian. On Thu, Jul 2, 2009 at 2:54 PM, Carcharoth&lt;carcharothwp(a)googlemail.com&gt; wrote: 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.