MediaWiki is getting a new programming language

[Steve Bennett-8]

On Wed, Jul 8, 2009 at 1:18 AM, stevertigo<stvrtg@...> wrote:

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

Sorry to offend you. The claim made was that users continued to use
the MediaWiki template language because it was "good enough". I say
users continue to use it because there is no alternative. If you
wanted to make templates in Wikipedia, you'd write them in BrainFuck*
if that was the only language available.

Steve
* With a tip of the hat to David G. I've never written BrainFuck, but
I have written a fungeoid interpreter...

_______________________________________________
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 Wed, Jul 8, 2009 at 6:22 AM, David Gerard<dgerard@...> 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.
>
>
> I'd call that a feature. Content is King. I used the classic skin for
> ages after Monobook became the default.

I'd call it a sad legacy of the timing of Wikipedia. I would dearly
love more Web 2.0 like features, particularly the general ability to
mash up data in different ways, edit stuff through AJAX rather than
page refreshes, less wordy screen layout etc etc.

(I don't for a minute mean fancier social networking features. Just
faster ways of manipulating content.)

Steve

_______________________________________________
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:01 AM, <WJhonson@...> wrote:

> The reason BASIC was and still enjoys wide popularity is because it's
> easier to learn.
>
> The example does not make the substantial point because it veers so
> strongly to the opposite end of the spectrum as to be unrelated to the argument
> whatsoever.  I never suggested that a language should *mimic* English (or a
> bizarre type of hyper-English).
>
> I welcome however, anyone who wants to actually conduct this argument, on
> Earth.

The difference between this thread and the parallel one on wikitech-l:
that thread quickly focussed on four genuine candidates: Lua, Python,
JavaScript and PHP. People identified the basic requirements
(security, speed...) and pointed out the pros and cons of each
language, in terms of available interpreters, tried and tested
experiments with sandboxing each, etc.

Here, we're talking about bringing back BASIC because it's so much
more readable. *yawn*

Steve

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

[Neil Harris-2]

Steve Bennett wrote:

> On Tue, Jul 7, 2009 at 5:01 AM, <WJhonson@...> wrote:
>  
>> The reason BASIC was and still enjoys wide popularity is because it's
>> easier to learn.
>>
>> The example does not make the substantial point because it veers so
>> strongly to the opposite end of the spectrum as to be unrelated to the argument
>> whatsoever.  I never suggested that a language should *mimic* English (or a
>> bizarre type of hyper-English).
>>
>> I welcome however, anyone who wants to actually conduct this argument, on
>> Earth.
>>    
>
>
> The difference between this thread and the parallel one on wikitech-l:
> that thread quickly focussed on four genuine candidates: Lua, Python,
> JavaScript and PHP. People identified the basic requirements
> (security, speed...) and pointed out the pros and cons of each
> language, in terms of available interpreters, tried and tested
> experiments with sandboxing each, etc.
>
> Here, we're talking about bringing back BASIC because it's so much
> more readable. *yawn*
>
> Steve
>
>  

Can we take this discussion back to wikitech-l now, please, and focus on
specific, concrete proposals for syntax reform and/or language replacement?

-- Neil




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

[WJhonson]

 Um.. no we're not.



<<Here, we're talking about bringing back BASIC because it's so much
more readable. *yawn*>>



 


 


 

-----Original Message-----
From: Steve Bennett <stevagewp@...>
To: English Wikipedia <wikien-l@...>
Sent: Wed, Jul 8, 2009 12:13 am
Subject: Re: [WikiEN-l] MediaWiki is getting a new programming language










On Tue, Jul 7, 2009 at 5:01 AM, <WJhonson@...> wrote:
> The reason BASIC was and still enjoys wide popularity is because it's
> easier to learn.
>
> The example does not make the substantial point because it veers so
> strongly to the opposite end of the spectrum as to be unrelated to the
argument
> whatsoever. ?I never suggested that a language should *mimic* English (or a
> bizarre type of hyper-English).
>
> I welcome however, anyone who wants to actually conduct this argument, on
> Earth.


The difference between this thread and the parallel one on wikitech-l:
that thread quickly focussed on four genuine candidates: Lua, Python,
JavaScript and PHP. People identified the basic requirements
(security, speed...) and pointed out the pros and cons of each
language, in terms of available interpreters, tried and tested
experiments with sandboxing each, etc.

Here, we're talking about bringing back BASIC because it's so much
more readable. *yawn*

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

[Neil Harris-2]

wjhonson@... wrote:
>  Um.. no we're not.
>
>
>
> <<Here, we're talking about bringing back BASIC because it's so much
> more readable. *yawn*>>
>
>
>  
Do you have a concrete example of the alternative language, or
alternative syntax for the existing language, that you are proposing as
an alternative to the current state of affairs?

If so, could you please post it to wikitech-l?

-- Neil


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

[WJhonson]

 My entire point Neil was simply that, "short-time-to-learn" should also be a consideration.? To me, a language that borrows heavily from an *already known* source like English or even BASIC is easier to learn, than one which requires that every command be learned again without any prior foundation.? I am not a subscriber to tech.? I don't think I want to be.




<<Do you have a concrete example of the alternative language, or
alternative syntax for the existing language, that you are proposing as
an alternative to the current state of affairs?>>



 


 


 

-----Original Message-----
From: Neil Harris <usenet@...>
To: English Wikipedia <wikien-l@...>
Sent: Wed, Jul 8, 2009 2:51 am
Subject: Re: [WikiEN-l] MediaWiki is getting a new programming language










wjhonson@... wrote:
>  Um.. no we're not.
>
>
>
> <<Here, we're talking about bringing back BASIC because it's so much
> more readable. *yawn*>>
>
>
>  
Do you have a concrete example of the alternative language, or
alternative syntax for the existing language, that you are proposing as
an alternative to the current state of affairs?

If so, could you please post it to wikitech-l?

-- Neil


_______________________________________________
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

[David Gerard-2]

2009/7/8  <wjhonson@...>:

>  My entire point Neil was simply that, "short-time-to-learn" should also be a consideration.? To me, a language that borrows heavily from an *already known* source like English or even BASIC is easier to learn, than one which requires that every command be learned again without any prior foundation.? I am not a subscriber to tech.? I don't think I want to be.


The point is that discussion of the matter is much more likely to be
effective there rather than here, because there is specifically where
the official discussion is being conducted!

It's an open list, anyone can subscribe to it or read the archive.


- d.

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

[Neil Harris-2]

wjhonson@... wrote:
>  My entire point Neil was simply that, "short-time-to-learn" should also be a consideration.? To me, a language that borrows heavily from an *already known* source like English or even BASIC is easier to learn, than one which requires that every command be learned again without any prior foundation.? I am not a subscriber to tech.? I don't think I want to be.
>
>  

Wikitech-l is undoubtedly the right forum for this discussion, so we
really should continue this discussion there.

I find it rather difficult to understand exactly what you want here.
Could you please give an example, even a rough one, of the sort of
syntax you are proposing?

For example, how would you write something like, say, this artificial
example:

{{#switch:
{{#iferror: {{#expr: {{{1}}} + {{{2}}} }} | error | correct }}
| error = that's an error
| correct = {{{1}}} + {{{2}}} = {{#expr: {{{1}}} + {{{2}}} }}}}

in your new notation?

-- Neil


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

[Carcharoth]

On Wed, Jul 8, 2009 at 11:23 AM, Neil Harris<usenet@...> wrote:

<snip>

> Wikitech-l is undoubtedly the right forum for this discussion, so we
> really should continue this discussion there.

It would be nice is discussion of the non-technical aspects continued
here and some of it fed back to wiki-tech-l, such as the pleas for a
manual and help pages that are well-written and people can understand.

> I find it rather difficult to understand exactly what you want here.
> Could you please give an example, even a rough one, of the sort of
> syntax you are proposing?

<snip>

I think he wants to reduce the number of curly brackets.

Carcharoth

_______________________________________________
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 9:55 AM, Sheldon Rampton<sheldon@...> wrote:

> (1) No WYSIWYG editing system.

Browsers by limitation are not real "WYSIWIG editing systems," and
because WP is a website, its nearly entirely dependent on the browser.
New functionality, regardless of its development, is mostly either
proprietary or useless unless the W3C deals with it.  One improvement
that comes to mind is text edit fields that are readable and
formattable, so the distinction between presentation and editing text
is blurred - maybe quick shifting between edit and view modes.

> If you look at Wikipedia pages and really compare them to what has now...

Much of what is called "web 2.0", aside from Wikipedia itself, is just
video - some of it useful - all but all of it running on the
proprietary Adobe Flash plugin for the forseeable future. The rest is
organizational and layers that hide lower level functions. Wiki of
course came out of the widespread love people have for hand-coding
HTML. And Tweets could have shown up nine years ago, but they didn't.
Its the concepts that are changing, not the "technology" so much.

> So why aren't those features already in place?

Keep in mind also that most necessary improvements are subtle, while
overt improvements are often borking.

-Steven

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

[WJhonson]

In a message dated 7/8/2009 3:23:57 AM Pacific Daylight Time,
usenet@... writes:


> For example, how would you write something like, say, this artificial
> example:
>
> {{#switch:
> {{#iferror: {{#expr: {{{1}}} + {{{2}}} }} | error | correct }}
> | error = that's an error
> | correct = {{{1}}} + {{{2}}} = {{#expr: {{{1}}} + {{{2}}} }}}}
>
> in your new notation?>>

--------------------
I don't have any new notation Neil.  I don't have a new language.
In fact we shouldn't be trying to create a *new* language.

If we have four proposed languages from which to choose, then one of the
criteria should be "easy to understand", "intuitive to the novice".

That is my point.  That's been my point.

Will




**************
Looking for love this summer? Find it now on AOL Personals.
(http://personals.aol.com/?ncid=emlcntuslove00000003)
_______________________________________________
WikiEN-l mailing list
WikiEN-l@...
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l

[Aryeh Gregor]

On Wed, Jul 8, 2009 at 11:57 AM, stevertigo<stvrtg@...> wrote:
> Browsers by limitation are not real "WYSIWIG editing systems

They aren't?  How about contenteditable?

> New functionality, regardless of its development, is mostly either
> proprietary or useless unless the W3C deals with it.

Well, contenteditable is standardized in HTML 5.  There may be other
ways; a lot of other projects seem to manage to do good WYSIWYG
somehow, at least in major browsers.  AFAICT, the only reason we don't
have it is because our wikitext is a complete mess to parse
client-side.  If we used HTML or some close analog as a storage
format, we could have WYSIWYG almost for free.

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

>> (1) No WYSIWYG editing system.
>
> Browsers by limitation are not real "WYSIWIG editing systems," and
> because WP is a website, its nearly entirely dependent on the browser.
> New functionality, regardless of its development, is mostly either
> proprietary or useless unless the W3C deals with it.  One improvement
> that comes to mind is text edit fields that are readable and
> formattable, so the distinction between presentation and editing text
> is blurred - maybe quick shifting between edit and view modes.


Nevertheless, there are a number of WYSIWYG editing technologies that  
people have developed which work with web browsers, such as FCKEditor.  
A number of non-Mediawiki wikis already have WYSIWYG functionality, as  
does Google's Knols project.

I know people who have tried developing WYSIWYG for Mediawiki, and the  
main obstacle they encounter is the wiki markup language, which is too  
idiosyncratic to parse properly and consistently. If Mediawiki used  
some other markup syntax, such as XML or HTML, they'd be able to do  
it. The current syntax was designed with the original intention of  
making it very easy and quick for people to edit articles and add  
formatting such as bold, italic, hyperlinks, etc. However, even a  
lightweight markup language is still a markup language, and WYSIWYG is  
easier for most people, so in this regard Wikipedia has fallen behind  
with regard to state-of-the-art standards for user-friendliness.  
Moreover, the original simplicity of Wikipedia's markup syntax has  
been lost somewhat as new functionality has been added. The whole  
templates mess is an example of this.

If someone were trying to design Wikipedia from scratch today, I think  
they'd be able to come up with a markup syntax that supports WYSIWYG  
very nicely, but of course designing it from scratch is not an option.  
There's too much legacy material that has already been created using  
the existing syntax, so changing it becomes very difficult. Again,  
this is en example of path dependency.

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

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

[Charles Matthews]

Sheldon Rampton wrote:
> There's too much legacy material that has already been created using  
> the existing syntax, so changing it becomes very difficult. Again,  
> this is en example of path dependency.
>  
Or rather, the retort a dozen years on to Ward Cunningham and "what's
the simplest thing that would actually work", "well, what do we do if it
works?" Your argument seems to me not so much about path-dependency,
which I would say relates more to the social side of WP, but to the
oldest jokes: "If I wanted to get there, I wouldn't start from here".

As far as templates are concerned, we could start in on deprecation for
technical reasons and try to improve the worst of it - sounds OK to me
and still within the "wiki way".

I'm not yet convinced that the absence of WYSIWYG is a barrier to WP
doing anything specific, and I don't believe that the usability studies
I have seen prove that it is. But then I tend to believe that the issue
with expository problems lies in the underestimation of expository writing.

Charles


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

[Sheldon Rampton]

Charles Matthews wrote:

> I'm not yet convinced that the absence of WYSIWYG is a barrier to WP
> doing anything specific, and I don't believe that the usability  
> studies
> I have seen prove that it is. But then I tend to believe that the  
> issue
> with expository problems lies in the underestimation of expository  
> writing.


The question is whether WYSIWYG would make editing Wikipedia articles  
easier for most users. I think the answer to that question is fairly  
self-evident.

Twenty years ago there were similar debates about WYSIWYG with regard  
to word processors, just as there were debates about whether command-
line DOS was better or worse than the GUI that Apple introduced with  
Macintosh computers. Some people back then argued that word processors  
like WordPerfect were better than WYSIWYG because you could go into  
edit mode and "see" the markup codes -- [b] for bold, [i] for italic,  
etc. Similarly, people argued that command-line DOS was better than  
dragging-and-clicking windows in a GUI because you could "see" the  
commands and their parameters. In the end, WYSIWYG and the GUI won.  
Most people don't WANT to see [b] for bold. They just want to be able  
to make the text bold. As a result, some once-dominant word processors  
died off, and Microsoft was forced to adapt by replacing DOS with  
Windows.

Wikipedia has enough earned reputation that path dependency will keep  
it on top of the heap for the foreseeable future, even without WYSIWYG  
editing, but sooner or later someone will develop a better alternative  
-- either within Wikipedia, or outside it.

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

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

[Charles Matthews]

Sheldon Rampton wrote:
> Twenty years ago there were similar debates about WYSIWYG with regard  
> to word processors, just as there were debates about whether command-
> line DOS was better or worse than the GUI that Apple introduced with  
> Macintosh computers.
Interesting to think what one couldn't prove with some argument from the
history of technology. Automatic transmission didn't replace the gear
lever. As far as I can see (which may be household dependent) remote
controls proliferate and get harder to use (sometimes there seem to be
five to choose from), and the same might be true of phones. I think
arguments from the period when the PC was moving onto every desk in the
workplace are a little special. I imagine MediaWiki will get WYSIWYG
simply because the project sounds like a good idea and will get funded.

Charles


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

[stevertigo-2]

On Wed, Jul 8, 2009 at 1:07 PM, Aryeh
Gregor<Simetrical+wikilist@...> wrote:

> Well, contenteditable is standardized in HTML 5.  There may be other
> ways; a lot of other projects seem to manage to do good WYSIWYG
> somehow, at least in major browsers.  AFAICT, the only reason we don't
> have it is because our wikitext is a complete mess to parse
> client-side.  If we used HTML or some close analog as a storage
> format, we could have WYSIWYG almost for free.

Contenteditable - nice. "Good WYSIWIG?" Gmail?  Lots of AJAX isn't
really a good thing, is it?  I guess Google is trying to get some of
Gears into the standard. Any ideas Wikimedia wants implemented?

> AFAICT, the only reason we don't have it is because our wikitext is a complete mess to parse
> client-side.

Parseability requires context. Context requires metadata. In our case
"metadata," for lots and lots of information, would mean something
like semantic web? Metadata in current wikitext jargon means "stuff
stuck somewhere at the bottom."

A dualistic Wikitext/XML metadata format maybe? Links for example
would still have the same bracket form, but would also need something
in its metadata to indicate universal location:  <site
prefix="http://en.wikipedia.org/wiki/">. One idea is that metadata in
XML form can be part of the raw wikitext, but would be hidden in the
standard edit mode on a Mediawiki. A different edit mode shows the XML
along with the wikitext.

In fact it seems a lot of this parsing or processing idea can be
handled in metadata. I want my audio player, for example, to
automatically make intelligent EQ adjustments per song, instead of
doing it by hand for each song.  Sound profile analysis on my tiny
player is not possible.  Sound profile analysis during file creation
and then encoding the abstractions into the metadata would take a bit
longer, but would also mean that even a tiny player, without any
processing or parsing at all, can do reasonably good audio shaping
just base on those abstractions.

-Steven

_______________________________________________
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 9, 2009 at 8:51 PM, stevertigo<stvrtg@...> wrote:
> Contenteditable - nice. "Good WYSIWIG?" Gmail?  Lots of AJAX isn't
> really a good thing, is it?

Gmail does not use AJAX for its WYSIWYG editor, as far as I know.  And
yes, its WYSIWYG editor works fine (although I normally type mail in
plain text).

> Parseability requires context. Context requires metadata. In our case
> "metadata," for lots and lots of information, would mean something
> like semantic web? Metadata in current wikitext jargon means "stuff
> stuck somewhere at the bottom."

What are you talking about?  Given some wikitext, you need to be able
to convert it to HTML, that's all, and convert changes the user makes
back to wikitext.  "Context" and "metadata" have nothing to do with
it.  The problem is wikisyntax is far too complicated to process
effectively and correctly in JavaScript, or in any implementation
other than Parser.php, without an inordinate amount of effort.  If we
used HTML, then we have instant native support in JavaScript for all
browsers.

_______________________________________________
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 Wed, Jul 8, 2009 at 8:02 PM, David Gerard<dgerard@...> wrote:
> The point is that discussion of the matter is much more likely to be
> effective there rather than here, because there is specifically where
> the official discussion is being conducted!
>
> It's an open list, anyone can subscribe to it or read the archive.

Maybe I'm being too nasty, but I feel like the people who should
participate in the wikitech-l discussion are, or at least, were,
participating in it. Would you really want all this noise over there?

Honestly, the question of which language to use is 90% practicality:
which language can we actually get an interpreter for, that is secure
and fast enough. Preferences for one style of syntax over another
don't really enter into it.

Steve

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