MediaWiki is getting a new programming language

[Steve Bennett-8]

On Wed, Jul 1, 2009 at 7:59 PM, AGK<wikiagk@...> 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

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Thomas Dalton]

2009/7/1 AGK <wikiagk@...>:
> 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.

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Cary Bass-4]

Thomas Dalton wrote:

> 2009/7/1 AGK <wikiagk@...>:
>  
>> 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

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Carcharoth]

On Thu, Jul 2, 2009 at 4:57 AM, Steve Bennett<stevagewp@...> wrote:
> On Wed, Jul 1, 2009 at 7:59 PM, AGK<wikiagk@...> 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

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Aryeh Gregor]

On Thu, Jul 2, 2009 at 2:49 PM, Cary Bass<cary@...> 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, Carcharoth<carcharothwp@...> 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.

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[David Gerard-2]

2009/7/2 Carcharoth <carcharothwp@...>:

> 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.

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Judson Dunn-2]

On Thu, Jul 2, 2009 at 1:54 PM, Carcharoth<carcharothwp@...> 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&action=edit

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

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Steve Bennett-8]

On Fri, Jul 3, 2009 at 5:16 AM, Judson Dunn<cohesion@...> 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&action=edit

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@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[WJhonson]

 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@...>
To: English Wikipedia <wikien-l@...>
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<cohesion@...> 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&action=edit

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@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l



 

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Gwern Branwen]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkpNdUEACgkQvpDo5Pfl1oIhjgCfa+FkurtMQ/IekAmEin12EJin
IsoAoJno9sNJkfDcsehb7rbJf43kDw/M
=fy7n
-----END PGP SIGNATURE-----

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Steve Bennett-8]

On Fri, Jul 3, 2009 at 12:23 PM, <wjhonson@...> 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@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[stevertigo-2]

On Thu, Jul 2, 2009 at 7:11 PM, Steve Bennett <stevagewp@...> 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
_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Matthew Brown-5]

On Thu, Jul 2, 2009 at 10:09 PM, stevertigo<stvrtg@...> wrote:
> On Thu, Jul 2, 2009 at 7:11 PM, Steve Bennett <stevagewp@...> 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

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[WJhonson]

 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@...>
To: English Wikipedia <wikien-l@...>
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@...> 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@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l



 

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Matthew Brown-5]

On Fri, Jul 3, 2009 at 12:27 AM, <wjhonson@...> 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

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Sheldon Rampton]

Stevertigo wrote:

> Hm. That "crap" seems to have worked quite well for a few years now.

Hardly. The templating system has been a source of complaints and  
frustrations for a very long time. I remember hearing Aaron Swartz get  
a lot of laughter when he gave a talk at Wikimania 2006 and showed a  
Powerpoint slide with a screenful of templating gibberish that  
consisted of an huge, nested series of squiggly brackets, numerals and  
odd symbols. The line that drew the big laugh was when he asked if  
people thought that syntax was user-friendly.

The current system of parser functions is actually an improvement over  
what existed previously, because at least it provides for an if-then  
statement and some rudimentary calculations and logical branching.  
Before parser functions existed, people used an even uglier workaround  
in which they achieved the RESULT of an if-then statement through a  
process so complicated and counter-intuitive that it would take  
several labored paragraphs for me to even describe it . It was because  
that system DIDN'T "work quite well" that parser functions were  
developed. They're not very easy to use either, which is why the  
developers are now trying to come up with a better alternative.

I should mention too that a number of Mediawiki extensions have been  
written over the years -- Semantic Mediawiki, for example -- which are  
also basically attempts to overcome the limitations of Mediawiki  
syntax and the templating system in particular. There are also oodles  
of extensions that people have written in attempts to add some widget  
or transclusion feature to Mediawiki such as Google maps or RSS feeds.  
If the current system "worked quite well," a lot of those add-on  
extensions would be unnecessary.

The fact that the current template system works poorly is no one's  
fault. It's a consequence of the ad hoc way that Mediawiki and  
Wikipedia have evolved, and of course that ad hoc evolution is no  
one's fault either. If everyone had waited until they had a perfect  
wiki platform before launching Wikipedia, the project would never have  
gotten off the ground. The tech people have generally performed  
admirably at building and maintaining the software that runs  
Wikipedia, and I think it's great that they're talking about ways to  
further improve the templating system, which could certainly use it. I  
think they understand all too well that it's not a good system, and  
they also understand how difficult it will be to come up with a better  
alternative.

-------------------------------------------

SHELDON RAMPTON
Research director, Center for Media & Democracy
Center for Media & Democracy
520 University Avenue, Suite 227
Madison, WI 53703
phone: [phone]

Subscribe to our free Weekly Spin email:
<http://www.prwatch.org/cmd/subscribe_sotd.html>

Subscribe to our Weekly Radio Spin podcasts:
<http://www.prwatch.org/audio/feed>

Read and add to articles on people, issues and groups shaping the
public agenda:
<http://www.sourcewatch.org>

Support independent, public interest reporting:
<http://www.prwatch.org/donate>




_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[stevertigo-2]

On Fri, Jul 3, 2009 at 6:50 AM, Sheldon Rampton<sheldon@...> wrote:
> Stevertigo wrote:
>> Hm. That "crap" seems to have worked quite well for a few years now.

> Hardly. The templating system has been a source of complaints and
> frustrations for a very long time.

Well, agreed. But its important to separate complaints about its
nested (and usually whitespace removed) syntax from complaints about
its limited functionality.  If we look at these issues of syntax and
functionality separately, its conceivable that the current "language"
can just be 1) cleaned up a bit, and 2) extended in functionality to a
satisfactory degree.

With regard to 2), the "new language" idea presumes that there are a
large number of serious useful functions that Wikimedians need, that a
language like Lua (the frontrunner) can provide, and that would be too
much of a pain to replicate in amended/extended functions.

With regard to 1), ostensibly just handling the whitespace issue
better would allow for better formatting, and thus better readability.

> The current system of parser functions is actually an improvement over
> what existed previously, because at least it provides for an if-then
> statement and some rudimentary calculations and logical branching.

What other specific functions are needed is thus the real question.

> It was because that system DIDN'T "work quite well" that parser functions were
> developed.

Things work only as well as they do. I'm trying to get more than 25
miles to the gallon from my vehicle (a Ukranian mini-bus shaped like a
taco), but that's what I've got.

> I should mention too that a number of Mediawiki extensions have been
> written over the years -- Semantic Mediawiki, for example -- which are
> also basically attempts to overcome the limitations of Mediawiki
> syntax and the templating system in particular.

Hm. Semantic MW doesn't qualify, AIUI, and I'm not aware of any other
particular extensions to parser functionality.

> I think they understand all too well that it's not a good system, and
> they also understand how difficult it will be to come up with a better
> alternative.

Hm. Interesting.

-Steve

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Aryeh Gregor]

On Thu, Jul 2, 2009 at 10:23 PM, <wjhonson@...> 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.

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[stevertigo-2]

On Thu, Jul 2, 2009 at 7:23 PM, <wjhonson@...> 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

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[stevertigo-2]

On Fri, Jul 3, 2009 at 9:45 AM, stevertigo<stvrtg@...> wrote:
> "Note that *if* "English" itself isn't sufficient where "English" lacks the required (programming) concepts.

Should be: Note that English itself...

-Steve

_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l