MediaWiki is getting a new programming language

[Neil Harris-2]

> In a message dated 7/6/2009 3:54:38 AM Pacific Daylight Time,
> usenet@... writes:
>
>
>> Although the point could have been put more tactfully, I think the
>> salient point here is that "English-like" programming languages have
>> been tried before many times, and have (with the possible exception of
>> COBOL) consistently been rejected in favour of compact equation-like
>> languages.>>
>
> -------------------------
>
> Neil let me just point out in counter-point that the two longest-living
> third-generation langages, COBOL and BASIC are both still alive and well.
>
> Both use a most English-like foundation.
>
>
>  Is Python more represented in want-ads ?  Most businesses still use older
> generation languages, regardless of what is being taught in university.
>
> Will Johnson

The reason why COBOL and SQL endure isn't their English-like syntax,
which is a relic of the era in which they were designed, but because
they were the first just-good-enough systems of their type.

The same is true of C, which is an appallingly badly designed language
by modern standards; but endures for the same reasons; familiarity,
backwards compatibility and the widespread availability of trained
programmers. But in its time, C was a _vast_ improvement over assembler,
which is what it existed to replace.

[Regarding want ads: granted, there are billions of lines of COBOL and
BASIC code out there in the business world, but how many new projects do
you see being created in COBOL or BASIC, and how many job ads for COBOL
and BASIC programmers? http://langpop.com/ has a pretty good survey of
what's actually used in the wider world. Gnomic ALGOL-esque languages
like C, Java C++ and PHP lead the pack.]

The MediaWiki template language survives for the same reason. This is
not to say that it's perfect, or even very good: but it works, has a
large installed base of legacy code, and general availability of the
appropriate skills in the existing base of "programmers", and is just
good enough to serve its purpose, and therefore survives on for the same
reasons as above.

Given the large installed base of existing template code, I believe it
would a much better idea to start with the template language we
currently have, and clean it up incrementally, than it would be to
rewrite it from scratch and risk second system syndrome.

Fortunately, it's (necessarily) machine-parsable, and it shouldn't be an
insuperable task to clean up the syntax whilst still running alongside
the old code, and remaining (mostly) backwards compatible. If this is
done in stages, the current template coder base should learn the new
syntax in parallel with the changes, and the new syntax should be much
easier for new template programmers to learn.

This has actually been done twice before: once with the creation of
proper conditionals and the retirement of {{qif}}, and a second time
with a subtle change in the semantics of the template system to make it
faster and easier to parse and run.

Perhaps the next move should be the replacement of {{{name|default}}}
with something like ${name|default}, with $name as a short form for the
common case?

-- Neil


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

[Neil Harris-2]

stevertigo wrote:

> On Mon, Jul 6, 2009 at 3:54 AM, Neil Harris<usenet@...> wrote:
>
>  
>> Consider the difference between the ease of writing, say, the Python-like
>>  print "%02x" % find(":", param[1])
>> or even the Lisp-like
>>  (print (fmt "%02x" (find ":" (param 1))))
>> compared to writing an "English-like" equivalent such as
>>  PRINT THE NUMBER OF CHARACTERS BEFORE THE FIRST OCCURRENCE OF THE
>> COLON CHARACTER IN THE FIRST POSITIONAL PARAMETER FORMATTED AS A
>> TWO-DIGIT ZERO-PADDED HEXADECIMAL NUMBER USING LOWERCASE LETTERS FOR THE
>> HEX DIGITS A TO F
>>    
>
> Your example is a bit unfair though, Neil. For one, how would it be parsed?
> Two, it only implies and does not explicitly state the "find/search"
> functionality
> you use in the examples.
>  

Oh, don't tempt me to write an implementation... a grammar for it might
look something like this:

command ::= print-expr | ...

expr ::= find-expr | param-expr  | arithmetic-expr | strong-expr

no-default-param-expr ::= "THE" ordinal-number-name "POSITIONAL
PARAMETER" | "THE PARAMETER CALLED" name-expr

param-expr ::= no-default-param-expr ["UNLESS THE PARAMETER IS
UNDEFINED, IN WHICH CASE USE" expr "INSTEAD"]

find-expr ::= "THE NUMBER OF CHARACTERS BEFORE THE FIRST OCCURRENCE OF"
expr "IN" expr

arithmetic-expr ::= expr "MULTIPLIED BY" expr | expr "ADDED TO" expr |
... | "OPEN BRACKETS" expr "CLOSE BRACKETS"

substitution-expr ::= "THE STRING" expr ", SUBSTITUTING THE STRING" expr
"FOR THE STRING" expr "THROUGHOUT"

string-expr ::= "THE" char-name "CHARACTER"

print-statement ::= "PRINT" expr "FORMATTED AS" print-format

print-format-atom ::= "A LITERAL STRING" | "A" ordinal-number-name
"-DIGIT" [ "ZERO-PADDED" ] ["HEXADECIMAL" | "OCTAL" | "DECIMAL" ]  
"NUMBER" ["USING" ["UPPERCASE" | "LOWERCASE" "LETTERS FOR THE HEX DIGITS
A TO F"]

print-format ::= print-format-atom | print-format-atom "FOLLOWED BY"
print-format

ordinal-number-name ::= "FIRST" | "SECOND" | "THIRD" | "FOURTH" ...

cardinal-number-name ::= "ONE" | "TWO" | "THREE" | "FOUR" ...

and then throw it at a packrat parser or similar shortest-length parser
for nondeterministic languages... I leave code generation and the
runtime environment as an exercise for the student. To keep fully within
the spirit of the exercise, don't forget to add automatic type coercion
of all data types to strings wherever necessary.

-- Neil


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

[stevertigo-2]

On Mon, Jul 6, 2009 at 12:49 PM, Neil Harris<usenet@...> wrote:

> Oh, don't tempt me to write an implementation... a grammar for it might
> look something like this:

I thought we were keeping this conversation high level.

-Steven

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

[Ian Woollard]

Yeah, that could work... if we lived in bizarro world where all the
developers actually liked COBOL!

If I know software engineers, over their dead bodies!

On 06/07/2009, Neil Harris <usenet@...> wrote:

> stevertigo wrote:
>> On Mon, Jul 6, 2009 at 3:54 AM, Neil Harris<usenet@...>
>> wrote:
>>
>>
>>> Consider the difference between the ease of writing, say, the Python-like
>>>  print "%02x" % find(":", param[1])
>>> or even the Lisp-like
>>>  (print (fmt "%02x" (find ":" (param 1))))
>>> compared to writing an "English-like" equivalent such as
>>>  PRINT THE NUMBER OF CHARACTERS BEFORE THE FIRST OCCURRENCE OF THE
>>> COLON CHARACTER IN THE FIRST POSITIONAL PARAMETER FORMATTED AS A
>>> TWO-DIGIT ZERO-PADDED HEXADECIMAL NUMBER USING LOWERCASE LETTERS FOR THE
>>> HEX DIGITS A TO F
>>>
>>
>> Your example is a bit unfair though, Neil. For one, how would it be
>> parsed?
>> Two, it only implies and does not explicitly state the "find/search"
>> functionality
>> you use in the examples.
>>
> Oh, don't tempt me to write an implementation... a grammar for it might
> look something like this:
>
> command ::= print-expr | ...
>
> expr ::= find-expr | param-expr  | arithmetic-expr | strong-expr
>
> no-default-param-expr ::= "THE" ordinal-number-name "POSITIONAL
> PARAMETER" | "THE PARAMETER CALLED" name-expr
>
> param-expr ::= no-default-param-expr ["UNLESS THE PARAMETER IS
> UNDEFINED, IN WHICH CASE USE" expr "INSTEAD"]
>
> find-expr ::= "THE NUMBER OF CHARACTERS BEFORE THE FIRST OCCURRENCE OF"
> expr "IN" expr
>
> arithmetic-expr ::= expr "MULTIPLIED BY" expr | expr "ADDED TO" expr |
> ... | "OPEN BRACKETS" expr "CLOSE BRACKETS"
>
> substitution-expr ::= "THE STRING" expr ", SUBSTITUTING THE STRING" expr
> "FOR THE STRING" expr "THROUGHOUT"
>
> string-expr ::= "THE" char-name "CHARACTER"
>
> print-statement ::= "PRINT" expr "FORMATTED AS" print-format
>
> print-format-atom ::= "A LITERAL STRING" | "A" ordinal-number-name
> "-DIGIT" [ "ZERO-PADDED" ] ["HEXADECIMAL" | "OCTAL" | "DECIMAL" ]
> "NUMBER" ["USING" ["UPPERCASE" | "LOWERCASE" "LETTERS FOR THE HEX DIGITS
> A TO F"]
>
> print-format ::= print-format-atom | print-format-atom "FOLLOWED BY"
> print-format
>
> ordinal-number-name ::= "FIRST" | "SECOND" | "THIRD" | "FOURTH" ...
>
> cardinal-number-name ::= "ONE" | "TWO" | "THREE" | "FOUR" ...
>
> and then throw it at a packrat parser or similar shortest-length parser
> for nondeterministic languages... I leave code generation and the
> runtime environment as an exercise for the student. To keep fully within
> the spirit of the exercise, don't forget to add automatic type coercion
> of all data types to strings wherever necessary.
>
> -- Neil
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l@...
> To unsubscribe from this mailing list, visit:
> https://lists.wikimedia.org/mailman/listinfo/wikien-l
>

--
-Ian Woollard

"All the world's a stage... but you'll grow out of it eventually."

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

[stevertigo-2]

Forgive my pseudocode (based on Neil's example):

function A: search ":" = [0],  scope (before [0]),  count [a-z] = [1],
format [1] [TWO-DIGIT ZERO-PADDED  HEXADECIMAL NUMBER]  /* :-P */,
format [1] [lowercase], move [1] [0].

Breakdown:
function A:
 search ":" = [0],                  // search for ":" and set it to
the 0 parameter
 scope (before [0]),            // set the scope for the next
operation as before 0 (":")
 count [a-z] = [1],               // count anything a-z within the
scope and set it to another parameter 1
 format [1] [TWO-DIGIT ZERO-PADDED HEXADECIMAL NUMBER],
 format [1] [lowercase],  // shouldn't affect numbers, and hex = A-F
anyway, so "A-F distinction = unnecessary
 move [1] [0].                 // put the results of 1 in the 0
position, period (.) ambiguously =  stop symbol

I'm not sure this gets all of it. IANAP

Me: "Compromising between efficiently terse syntax and efficiently expressive
natural language gets... "  .. a functional language?   Haskell?

-Steven

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

[Mark Wagner-2]

On Thu, Jul 2, 2009 at 19:23, <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 "_".

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

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

[WJhonson]

 Of course you've hit the nail right on the head.
I don't think we want to create a brand-new additional language that people have to learn just to code for Wikipedia.? What we'd want to do, is use an existing language, so that some people can jump right in with both feet and others, who want to, can pick up an instruction manual and start stabbing about.




If you'd like to propose a BASIC syntax for the tools we need, that
might make the argument more cogent and viable.  Of necessity you need
to base that on a BASIC which is freeware and portable.



 


 


 

-----Original Message-----
From: George Herbert <george.herbert@...>
To: English Wikipedia <wikien-l@...>
Sent: Mon, Jul 6, 2009 12:24 pm
Subject: Re: [WikiEN-l] MediaWiki is getting a new programming language










On Mon, Jul 6, 2009 at 12:01 PM, <WJhonson@...> wrote:
> The reason BASIC was and still enjoys wide popularity is because it's
> easier to learn.

I don't know that BASIC in any of its flavors lines up well with the
functional requirements needed for easy (compact, easy to read, easy
to learn how to program) template structure and so forth.

If you'd like to propose a BASIC syntax for the tools we need, that
might make the argument more cogent and viable.  Of necessity you need
to base that on a BASIC which is freeware and portable.


--
-george william herbert
george.herbert@...

_______________________________________________
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

[WJhonson]

 Yes I mean PRINT is far more obvious what it's doing.? Most programmers can understand what ADD, COUNT or FORMAT is supposed to do, in general.? Sure you could just use "/" or "~" or "^" but it's not obvious what they do without a manual.




Me: "Compromising between efficiently terse syntax and efficiently expressive
natural language gets... "  .. a functional language?   Haskell?



 


 


 

-----Original Message-----
From: stevertigo <stvrtg@...>
To: English Wikipedia <wikien-l@...>
Sent: Mon, Jul 6, 2009 3:56 pm
Subject: Re: [WikiEN-l] MediaWiki is getting a new programming language










Forgive my pseudocode (based on Neil's example):

function A: search ":" = [0],  scope (before [0]),  count [a-z] = [1],
format [1] [TWO-DIGIT ZERO-PADDED  HEXADECIMAL NUMBER]  /* :-P */,
format [1] [lowercase], move [1] [0].

Breakdown:
function A:
 search ":" = [0],                  // search for ":" and set it to
the 0 parameter
 scope (before [0]),            // set the scope for the next
operation as before 0 (":")
 count [a-z] = [1],               // count anything a-z within the
scope and set it to another parameter 1
 format [1] [TWO-DIGIT ZERO-PADDED HEXADECIMAL NUMBER],
 format [1] [lowercase],  // shouldn't affect numbers, and hex = A-F
anyway, so "A-F distinction = unnecessary
 move [1] [0].                 // put the results of 1 in the 0
position, period (.) ambiguously =  stop symbol

I'm not sure this gets all of it. IANAP

Me: "Compromising between efficiently terse syntax and efficiently expressive
natural language gets... "  .. a functional language?   Haskell?

-Steven

_______________________________________________
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

[George Herbert]

On Mon, Jul 6, 2009 at 4:14 PM, <wjhonson@...> wrote:
>
>  Of course you've hit the nail right on the head.
> I don't think we want to create a brand-new additional language that people have to learn just to code
> for Wikipedia.? What we'd want to do, is use an existing language, so that some people can jump right
> in with both feet and others, who want to, can pick up an instruction manual and start stabbing about.
>
>> If you'd like to propose a BASIC syntax for the tools we need, that
>> might make the argument more cogent and viable.  Of necessity you need
>> to base that on a BASIC which is freeware and portable.

Um.  Raw BASIC is not well structured to do the specific text
processing we're looking for.

You'd have to build templates up from raw code, without library tools,
accomplish what we do with the templates tools now.


--
-george william herbert
george.herbert@...

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

[WJhonson]

 Not sure I'm exactly following that.
Are you suggesting creating methods with inputs and outputs out of underlying templates and then allowing those methods to be called directly, so essentially building a higher-level language out of these templates as the tools ?




You'd have to build templates up from raw code, without library tools,
accomplish what we do with the templates tools now.



 


 


 

-----Original Message-----
From: George Herbert <george.herbert@...>
To: English Wikipedia <wikien-l@...>
Sent: Mon, Jul 6, 2009 4:28 pm
Subject: Re: [WikiEN-l] MediaWiki is getting a new programming language










On Mon, Jul 6, 2009 at 4:14 PM, <wjhonson@...> wrote:
>
> ?Of course you've hit the nail right on the head.
> I don't think we want to create a brand-new additional language that people
have to learn just to code
> for Wikipedia.? What we'd want to do, is use an existing language, so that
some people can jump right
> in with both feet and others, who want to, can pick up an instruction manual
and start stabbing about.
>
>> If you'd like to propose a BASIC syntax for the tools we need, that
>> might make the argument more cogent and viable. ?Of necessity you need
>> to base that on a BASIC which is freeware and portable.

Um.  Raw BASIC is not well structured to do the specific text
processing we're looking for.

You'd have to build templates up from raw code, without library tools,
accomplish what we do with the templates tools now.


--
-george william herbert
george.herbert@...

_______________________________________________
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

[geni]

2009/7/7 Mark Wagner <carnildo@...>:
> 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.

--
geni

_______________________________________________
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 Mon, Jul 6, 2009 at 6:58 PM, geni<geniice@...> 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

_______________________________________________
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 Tue, Jul 7, 2009 at 5:28 AM, Neil Harris<usenet@...> wrote:
> The MediaWiki template language survives for the same reason. This is
> not to say that it's perfect, or even very good: but it works, has a
> large installed base of legacy code, and general availability of the
> appropriate skills in the existing base of "programmers", and is just
> good enough to serve its purpose, and therefore survives on for the same
> reasons as above.

Erm, the MediaWiki template language survives because it has a
monopoly. There is no alternative. It doesn't really matter how bad it
is - there is nothing users could switch to.

Steve

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

[Charles Matthews]

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


_______________________________________________
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 Tue, Jul 7, 2009 at 6:00 AM, Charles
Matthews<charles.r.matthews@...> 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

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

[stevertigo-2]

On Tue, Jul 7, 2009 at 1:56 AM, Steve Bennett<stevagewp@...> wrote:
> Erm, the MediaWiki template language survives because it has a
> monopoly. There is no alternative. It doesn't really matter how bad it
> is - there is nothing users could switch to.

The word "monopoly" implies unfair business practices such that make
an inferior product the exceedingly market-dominant one. Putting aside
its basic inapplicability in an open-source context, and the fact that
in that context people will make free choices to use a tool, and not
to mention participate in that tools' further development..  what is
the argument?

-Steven

_______________________________________________
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:

> The word "monopoly" implies unfair business practices such that make
> an inferior product the exceedingly market-dominant one. Putting aside
> its basic inapplicability in an open-source context, and the fact that
> in that context people will make free choices to use a tool, and not
> to mention participate in that tools' further development..  what is
> the argument?

If you don't like the connotations of the word "monopoly," maybe  
you'll be happier with "path dependence," which conveys the same basic  
point:

http://en.wikipedia.org/wiki/Path_dependence

Obviously, "unfair business practices" are not responsible for  
maintaining Wikipedia's existing templating system. However, path  
dependence clearly occurs even in open source contexts. I think path  
dependence plays a big role in enabling Wikipedia to maintain its  
standing as the most popular online encyclopedia, and it probably is  
responsible for preventing a number of improvements from happening  
with Wikipedia. For example:

(1) No WYSIWYG editing system.

(2) The current templating system, which works but is far from easy  
for most people to use.

(3) Governance practices which are sometimes less than optimal.

If you look at Wikipedia pages and really compare them to what has now  
become state-of-the-art website design, it's hard to avoid the  
conclusion that Wikipedia looks a lot like Web 1.0 rather than Web  
2.0. Web design has come a long way since Wikipedia was launched. Many  
websites now integrate video very nicely and use Javascript/AJAX to  
improve user-friendliness and make pages more interactive and dynamic.  
The semantic web is also becoming more than a buzzword, and it's not  
hard to imagine a "Wikipedia 2.0" that would incorporate those sorts  
of features to become even more useful, attractive and popular than it  
already is. So why aren't those features already in place? Because the  
huge weight of Wikipedia's millions of articles and users makes it  
inevitable that introducing those sorts of features will be more  
technically challenging than if someone were to design those same  
features for a website that only has a small number of articles and  
users. In short, path dependence means that Wikipedia's very success  
makes it harder in some ways for the project to innovate and improve.

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

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

[George Herbert]

On Tue, Jul 7, 2009 at 9:55 AM, Sheldon Rampton<sheldon@...> wrote:

>[...]
> If you look at Wikipedia pages and really compare them to what has now
> become state-of-the-art website design, it's hard to avoid the
> conclusion that Wikipedia looks a lot like Web 1.0 rather than Web
> 2.0. Web design has come a long way since Wikipedia was launched. Many
> websites now integrate video very nicely and use Javascript/AJAX to
> improve user-friendliness and make pages more interactive and dynamic.
> The semantic web is also becoming more than a buzzword, and it's not
> hard to imagine a "Wikipedia 2.0" that would incorporate those sorts
> of features to become even more useful, attractive and popular than it
> already is. So why aren't those features already in place? Because the
> huge weight of Wikipedia's millions of articles and users makes it
> inevitable that introducing those sorts of features will be more
> technically challenging than if someone were to design those same
> features for a website that only has a small number of articles and
> users. In short, path dependence means that Wikipedia's very success
> makes it harder in some ways for the project to innovate and improve.

A large part of that is that programming full "Web 2.0" with all the
bells and whistles seems to take more attention / effort / skill than
we can reasonably expect out of our current editors.

I don't spend all day comparing Wiki software, but I've used most of
what's available, and MediaWiki is on the good side for usability and
features.  On the down side, as you mentioned, no WYSIWYG yet and
templates suck now.

Most of the things that are Web 2.0 GUI have extremely limited
functional sets compared to what we're using.  Perhaps it's possible
to reconceptualize the whole Wiki concept in terms of the function
sets those websites can do well, and do a complete new code base which
could do those sorts of things to build an encyclopedia wiki.  I've
seen a lot of people who wanted to make a better underlying engine
than MW stand up and say that it should be done.  I have seen
approximately zero actual functional specification, UI specification,
or code.

If someone wants to do that - great.  It's a hugely nontrivial
problem, but it's also clearly within the scope of what a well formed
open source development team could accomplish, and it ultimately is
probably what will happen.

If nobody does in the short term, however - we need to evolve MW in
some clear and obvious ways given its current challenges.  Everyone
knows that the templates and UI improvement and WYSIWYG are desirable
next major improvement steps to evolve MW (I hope).


--
-george william herbert
george.herbert@...

_______________________________________________
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/7 Sheldon Rampton <sheldon@...>:

> If you look at Wikipedia pages and really compare them to what has now
> become state-of-the-art website design, it's hard to avoid the
> conclusion that Wikipedia looks a lot like Web 1.0 rather than Web
> 2.0.


I'd call that a feature. Content is King. I used the classic skin for
ages after Monobook became the default.


- d.

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

[phoebe ayers-3]

On Fri, Jul 3, 2009 at 11:53 AM, Carcharoth<carcharothwp@...> wrote:

> On Fri, Jul 3, 2009 at 6:21 PM, Judson Dunn<cohesion@...> 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

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