I was curious what the current plans are for MW 2.0. Will it just be announced sometime during the quarterly release schedule? Will it be a considerable rewrite?
If the later, I have an interesting idea for SoC. How about somebody rewrite the MW 1.6 core. Details of the rewrite would include
*Changing everything to PHP 5 (better OO support in core) **If not PHP 5, then at least better OO'ize the code *Eliminating $wg global usage. **Perhaps replacing with a registry of sorts **Perhaps create a master MediaWiki object that has the $wgTitle, $wgUser variables and gets passed around *Numerous little things that everybody hates about the current core
We call the result of this rewrite MediaWiki 1.99, or something ridiculous. MediaWiki 1.99 has the full functionality of MediaWiki 1.6. The only difference is a re-factored core. Now, we have two branches of MediaWiki for developers to work on. We have the 1.6 branch for minor updates on Wikipedia, etc. We have the 1.99 branch for drastic changes to how MediaWiki works. The 1.99 branch allows developments such as LiquidThreads, a well-thought-out API, permissions system, wiki farms, etc to be worked out independently of the stable 1.6 branch. In addition, database schema can be changed easily.
Thoughts?
Gregory Szorc gregory.szorc@gmail.com
On 03/05/06, Gregory Szorc gregory.szorc@gmail.com wrote:
I was curious what the current plans are for MW 2.0. Will it just be announced sometime during the quarterly release schedule? Will it be a considerable rewrite?
If the later, I have an interesting idea for SoC. How about somebody rewrite the MW 1.6 core.
Why the 1.6 core? 1.7alpha is in constant development and is in use on Wikimedia sites.
Rob Church
On 5/3/06, Rob Church robchur@gmail.com wrote:
On 03/05/06, Gregory Szorc gregory.szorc@gmail.com wrote:
I was curious what the current plans are for MW 2.0. Will it just be announced sometime during the quarterly release schedule? Will it be a considerable rewrite?
If the later, I have an interesting idea for SoC. How about somebody rewrite the MW 1.6 core.
Why the 1.6 core? 1.7alpha is in constant development and is in use on Wikimedia sites.
I said 1.6 because it is the latest official release. In reality, it doesn't matter where you make the branch point since changes from the development branch would be difficult to apply to the new core because of internal changes. If you had an intention of running the new core for Wikipedia, then the branch point should be as up to date as possible since you would have to re-patch the new core. However, the whole purpose of rewriting the core is to provide a true development branch point for major changes (db schema, parser rewrite, etc).
Greg
On Wed, May 03, 2006 at 01:26:06PM -0400, Gregory Szorc wrote:
I was curious what the current plans are for MW 2.0. Will it just be announced sometime during the quarterly release schedule? Will it be a considerable rewrite?
If the later, I have an interesting idea for SoC. How about somebody rewrite the MW 1.6 core. Details of the rewrite would include
*Changing everything to PHP 5 (better OO support in core)
If you're going to rewrite it -- why not rewrite it in another language?
Chad Perrin wrote:
If you're going to rewrite it -- why not rewrite it in another language?
Any kind of core rewrite as a SoC project is sheer lunacy. In fact, the best thing that can happen is for this thread to die young :)
It's something we might want to discuss at Hacking Days, however.
On 5/3/06, Ivan Krstic krstic@fas.harvard.edu wrote:
Chad Perrin wrote:
If you're going to rewrite it -- why not rewrite it in another language?
Any kind of core rewrite as a SoC project is sheer lunacy. In fact, the best thing that can happen is for this thread to die young :)
It's something we might want to discuss at Hacking Days, however.
How is it "sheer lunacy?" Do you doubt the abilities of good programmers? Google is paying $4500 for a student to complete this work. Student coding can go anywhere from $10 to $25/hr on average. Let's say it is $25/hr. That is 180 hours, or 4.5 40 hour weeks.
I am not proposing a FULL rewrite of the core, but a core re-organization. We keep the same classes, but just re-arrange things. We eliminate the use of global variables, assign visibility keywords to class functions, etc. This has been on the table for quite some time. Once this is done, you can start hacking away at the new core, replacing, deleting, and modifying classes as you see fit. The benefit to doing it this way instead of the natural progression of the Wikipedia development branch is that the Wikipedia developers don't have to spend the time "upgrading" the core to better OO. Their time can be spent doing actual development on MediaWiki. Think of the proposal as a glorified code audit/refactorization.
Greg
Gregory Szorc wrote:
Do you doubt the abilities of good programmers?
I certainly do, when they're students who are working alone and who might disappear from the face of the planet after SoC finishes, as turns out to be the case with a vast majority of SoC projects.
Think of the proposal as a glorified code audit/refactorization.
A rewrite implies starting from scratch. Making the MW code less ugly, which is what it sounds like you want do, is another matter entirely.
On Wednesday 03 May 2006 22:18, Gregory Szorc wrote:
On 5/3/06, Ivan Krstic krstic@fas.harvard.edu wrote:
Chad Perrin wrote:
Any kind of core rewrite as a SoC project is sheer lunacy. In fact, the best thing that can happen is for this thread to die young :)
How is it "sheer lunacy?" Do you doubt the abilities of good programmers?
http://www.joelonsoftware.com/articles/fog0000000069.html
daniel
Daniel Wunsch wrote:
On Wednesday 03 May 2006 22:18, Gregory Szorc wrote:
On 5/3/06, Ivan Krstic krstic@fas.harvard.edu wrote:
Chad Perrin wrote:
Any kind of core rewrite as a SoC project is sheer lunacy. In fact, the best thing that can happen is for this thread to die young :)
How is it "sheer lunacy?" Do you doubt the abilities of good programmers?
http://www.joelonsoftware.com/articles/fog0000000069.html
daniel
That article is spot-on. Progressive refactoring, piece by piece, until each part has been rewritten without ever breaking the system, is the only way to go: think of [[George Washington's axe]]. Radical rewrites result in [[second-system syndrome]].
-- Neil
On Wed, May 03, 2006 at 11:51:22PM +0200, Daniel Wunsch wrote:
Can I make a smart-ass crack about programmers who put that many non-significant 0's in a URL? :-)
Cheers, -- jra
On Wed, May 03, 2006 at 07:41:41PM -0400, Jay R. Ashworth wrote:
On Wed, May 03, 2006 at 11:51:22PM +0200, Daniel Wunsch wrote:
Can I make a smart-ass crack about programmers who put that many non-significant 0's in a URL? :-)
Yes, I suspect you can.
Jay R. Ashworth wrote:
On Wed, May 03, 2006 at 11:51:22PM +0200, Daniel Wunsch wrote:
Can I make a smart-ass crack about programmers who put that many non-significant 0's in a URL? :-)
The article was written in April 2000 and needs a complete rewrite, but I just couldn't find the edit button.
Moin,
On Wednesday 03 May 2006 22:18, Gregory Szorc wrote:
On 5/3/06, Ivan Krstic krstic@fas.harvard.edu wrote:
Chad Perrin wrote:
If you're going to rewrite it -- why not rewrite it in another language?
Any kind of core rewrite as a SoC project is sheer lunacy. In fact, the best thing that can happen is for this thread to die young :)
It's something we might want to discuss at Hacking Days, however.
How is it "sheer lunacy?" Do you doubt the abilities of good programmers? Google is paying $4500 for a student to complete this work. Student coding can go anywhere from $10 to $25/hr on average. Let's say it is $25/hr. That is 180 hours, or 4.5 40 hour weeks.
Maybe I am just a slow programmer, but I would say you need at least 10 times that amount for a refactorisation of such a big project.
I have spent easily 1000 hours last year into a little pet project which is _far_ less complcicated as Mediawiki.
To "rewrite" the core of MW, or even just refactor it or clean it, you need to be familiar with it, which easily eats the first 100 hours.
Best wishes,
Tels
We're working on a complete re-write of MW in Perl. Well not exactly a port, but we like lots of mediawiki features, and will be really looking at it for tips, we just like perl more and need a few things customized to work with our goal instead of the messed up wikimedia one; including a lot more support for integration between wikis on a network.
On May 3, 2006, at 11:53 AM, Chad Perrin wrote:
On Wed, May 03, 2006 at 01:26:06PM -0400, Gregory Szorc wrote:
I was curious what the current plans are for MW 2.0. Will it just be announced sometime during the quarterly release schedule? Will it be a considerable rewrite?
If the later, I have an interesting idea for SoC. How about somebody rewrite the MW 1.6 core. Details of the rewrite would include
*Changing everything to PHP 5 (better OO support in core)
If you're going to rewrite it -- why not rewrite it in another language?
-- Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ] "A script is what you give the actors. A program is what you give the audience." - Larry Wall _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 5/3/06, Elliott F. Cable ecable@avxw.com wrote:
We're working on a complete re-write of MW in Perl. Well not exactly a port, but we like lots of mediawiki features, and will be really looking at it for tips, we just like perl more and need a few things customized to work with our goal instead of the messed up wikimedia one; including a lot more support for integration between wikis on a network.
Perl?
You're kidding right?
Is there some rule that says mediawiki must be written in a language which encourages, nay demands!, unmaintainable results?
On Wed, May 03, 2006 at 04:43:26PM -0400, Gregory Maxwell wrote:
On 5/3/06, Elliott F. Cable ecable@avxw.com wrote:
We're working on a complete re-write of MW in Perl. Well not exactly a port, but we like lots of mediawiki features, and will be really looking at it for tips, we just like perl more and need a few things customized to work with our goal instead of the messed up wikimedia one; including a lot more support for integration between wikis on a network.
Perl?
You're kidding right?
Is there some rule that says mediawiki must be written in a language which encourages, nay demands!, unmaintainable results?
No, there isn't. That's probably why they're using Perl instead of Visual Basic.
Bad coding practice creates unmaintainable code, not Perl.
Moin,
On Wednesday 03 May 2006 22:43, Gregory Maxwell wrote:
On 5/3/06, Elliott F. Cable ecable@avxw.com wrote:
We're working on a complete re-write of MW in Perl. Well not exactly a port, but we like lots of mediawiki features, and will be really looking at it for tips, we just like perl more and need a few things customized to work with our goal instead of the messed up wikimedia one; including a lot more support for integration between wikis on a network.
Perl?
You're kidding right?
Is there some rule that says mediawiki must be written in a language which encourages, nay demands!, unmaintainable results?
You just insulted me as a Perl programmer that all my code is unmaintanable. Please have a look at:
and show me the unmaintanable bits so that I can fix them.
No wishes this time,
Tels
On 5/3/06, Tels nospam-abuse@bloodgate.com wrote:
Moin,
On Wednesday 03 May 2006 22:43, Gregory Maxwell wrote:
On 5/3/06, Elliott F. Cable ecable@avxw.com wrote:
We're working on a complete re-write of MW in Perl. Well not exactly a port, but we like lots of mediawiki features, and will be really looking at it for tips, we just like perl more and need a few things customized to work with our goal instead of the messed up wikimedia one; including a lot more support for integration between wikis on a network.
Perl?
You're kidding right?
Is there some rule that says mediawiki must be written in a language which encourages, nay demands!, unmaintainable results?
You just insulted me as a Perl programmer that all my code is unmaintanable. Please have a look at:
I'd humbly suggest that there are better things to discuss here than if certain languages are more maintainable than others. A good programmer can write maintainable code in any language; similarly a bad programmer can write crap anywhere, too.
Are we here to have a meaningful discussion about MW, or just engage in useless language debates?
-- Ben Garney Torque Technologies Director GarageGames.Com, Inc.
Moin,
On Thursday 04 May 2006 02:05, Ben Garney wrote:
On 5/3/06, Tels nospam-abuse@bloodgate.com wrote:
Moin,
On Wednesday 03 May 2006 22:43, Gregory Maxwell wrote:
On 5/3/06, Elliott F. Cable ecable@avxw.com wrote:
[snip]
Perl?
You're kidding right?
Is there some rule that says mediawiki must be written in a language which encourages, nay demands!, unmaintainable results?
You just insulted me as a Perl programmer that all my code is unmaintanable. Please have a look at:
I'd humbly suggest that there are better things to discuss here than if certain languages are more maintainable than others. A good programmer can write maintainable code in any language; similarly a bad programmer can write crap anywhere, too.
Are we here to have a meaningful discussion about MW, or just engage in useless language debates?
Er, my mail should have gone only to the author, not the list. My apologies.
Best wishes,
Tels
On Thu, May 04, 2006 at 12:39:23PM +0200, Tels wrote:
I'd humbly suggest that there are better things to discuss here than if certain languages are more maintainable than others. A good programmer can write maintainable code in any language; similarly a bad programmer can write crap anywhere, too.
Are we here to have a meaningful discussion about MW, or just engage in useless language debates?
Er, my mail should have gone only to the author, not the list. My apologies.
What, you mean mailing lists with reply-to set to the list are a *bad* thing?
Cheers, -- jr 'PLEASE DO NOT REPLY TO THIS MESSAGE' a
Jay R. Ashworth wrote:
On Thu, May 04, 2006 at 12:39:23PM +0200, Tels wrote:
I'd humbly suggest that there are better things to discuss here than if certain languages are more maintainable than others. A good programmer can write maintainable code in any language; similarly a bad programmer can write crap anywhere, too.
Are we here to have a meaningful discussion about MW, or just engage in useless language debates?
Er, my mail should have gone only to the author, not the list. My apologies.
What, you mean mailing lists with reply-to set to the list are a *bad* thing?
What, you mean you'd rather have hundreds of e-mails constantly go to the individuals when they were meant for the list?
Timwi (P.S. I use the newsgroup interface and I don't really get why anyone would use the mailing list. :-) )
On Thu, May 04, 2006 at 06:44:44PM +0100, Timwi wrote:
Jay R. Ashworth wrote:
What, you mean mailing lists with reply-to set to the list are a *bad* thing?
What, you mean you'd rather have hundreds of e-mails constantly go to the individuals when they were meant for the list?
Timwi (P.S. I use the newsgroup interface and I don't really get why anyone would use the mailing list. :-) )
Speaking just for myself here . . . I don't need *yet another interface* for dealing with the world. It's hard enough just keeping up with email and the telephone. Frankly, I'd need newsgroups to notify me by email when something new arrived.
On May 4, 2006, at 10:12 AM, Chad Perrin wrote:
On Thu, May 04, 2006 at 06:44:44PM +0100, Timwi wrote:
Jay R. Ashworth wrote:
What, you mean mailing lists with reply-to set to the list are a *bad* thing?
What, you mean you'd rather have hundreds of e-mails constantly go to the individuals when they were meant for the list?
Timwi (P.S. I use the newsgroup interface and I don't really get why anyone would use the mailing list. :-) )
Speaking just for myself here . . . I don't need *yet another interface* for dealing with the world. It's hard enough just keeping up with email and the telephone. Frankly, I'd need newsgroups to notify me by email when something new arrived.
Try - mail, RSS, AIM, MSN, ICQ, iChat, 4x web interfaces, at least 30 forums, at least 50 wikis, IRC (usually in around 10 channels on 4 servers) Limewire/azeureus chat, SEE chat, ventrilo, teamspeak, Squeak, skype - the list goes on. Telephone? Fax? Not to mention people trying to swarm me in RL while I'm trying to communicate with the really important ones online...
On Thu, May 04, 2006 at 12:59:40PM -0800, Elliott F. Cable wrote:
Speaking just for myself here . . . I don't need *yet another interface* for dealing with the world. It's hard enough just keeping up with email and the telephone. Frankly, I'd need newsgroups to notify me by email when something new arrived.
Try - mail, RSS, AIM, MSN, ICQ, iChat, 4x web interfaces, at least 30 forums, at least 50 wikis, IRC (usually in around 10 channels on 4 servers) Limewire/azeureus chat, SEE chat, ventrilo, teamspeak, Squeak, skype - the list goes on. Telephone? Fax? Not to mention people trying to swarm me in RL while I'm trying to communicate with the really important ones online...
Oh, yeah, I use RSS, AIM, MSN, ICQ, YM, IRC, and a boatload of web interfaces (wikis, fora, et cetera), too. I try to keep funnelling the really important stuff into email, though. Thus, I get email alerts from all the web stuff that supports it, and I don't really need to put any effort into IMs because they make noise at me when there's incoming communication.
The point, at any rate, is this: I don't want to gratuitously add yet another interface to my information overload. When I have a choice between sending something to my email inbox or adding another, separate system of communication, I'll send it to email.
On 04/05/06, Elliott F. Cable ecable@avxw.com wrote:
Try - mail, RSS, AIM, MSN, ICQ, iChat, 4x web interfaces, at least 30 forums, at least 50 wikis, IRC (usually in around 10 channels on 4 servers) Limewire/azeureus chat, SEE chat, ventrilo, teamspeak, Squeak, skype - the list goes on. Telephone? Fax? Not to mention people trying to swarm me in RL while I'm trying to communicate with the really important ones online...
How long does it take to notify everyone everytime you go on holidays? :)
Steve
On May 4, 2006, at 1:55 PM, Steve Bennett wrote:
On 04/05/06, Elliott F. Cable ecable@avxw.com wrote:
Try - mail, RSS, AIM, MSN, ICQ, iChat, 4x web interfaces, at least 30 forums, at least 50 wikis, IRC (usually in around 10 channels on 4 servers) Limewire/azeureus chat, SEE chat, ventrilo, teamspeak, Squeak, skype - the list goes on. Telephone? Fax? Not to mention people trying to swarm me in RL while I'm trying to communicate with the really important ones online...
How long does it take to notify everyone everytime you go on holidays? :)
I just don't take vacations without one of the laptops. Or at least setting *EVERYTHING* up to forward to my PDAphone, if it's less than 2 days and I simply CAN'T take a computer - the biggest thing is I have to get up progressively earlier each day - as of now, it already takes about an hour and a half each morning to reply to e-mails, posts, check edits to all the wikis, reply to IMs sent over the night - and it's increasing more every day. I might just have to stop sleeping.
On May 4, 2006, at 9:44 AM, Timwi wrote:
Jay R. Ashworth wrote:
On Thu, May 04, 2006 at 12:39:23PM +0200, Tels wrote:
I'd humbly suggest that there are better things to discuss here than if certain languages are more maintainable than others. A good programmer can write maintainable code in any language; similarly a bad programmer can write crap anywhere, too.
Are we here to have a meaningful discussion about MW, or just engage in useless language debates?
Er, my mail should have gone only to the author, not the list. My apologies.
What, you mean mailing lists with reply-to set to the list are a *bad* thing?
What, you mean you'd rather have hundreds of e-mails constantly go to the individuals when they were meant for the list?
Timwi (P.S. I use the newsgroup interface and I don't really get why anyone would use the mailing list. :-) )
What is that?
On Thu, May 04, 2006 at 09:22:23AM -0400, Jay R. Ashworth wrote:
On Thu, May 04, 2006 at 12:39:23PM +0200, Tels wrote:
Er, my mail should have gone only to the author, not the list. My apologies.
What, you mean mailing lists with reply-to set to the list are a *bad* thing?
Nah, I think that means someone made a mistake when replying.
As my latest (rather long) mail to the list stated, I have no wish to clog the list with this. Thus let's please end it.
As I also said, those interested in Perl and mediawiki can contact me personally, not clog the list, thanks (-:
On May 4, 2006, at 2:39 AM, Tels wrote:
Moin,
On Thursday 04 May 2006 02:05, Ben Garney wrote:
On 5/3/06, Tels nospam-abuse@bloodgate.com wrote:
Moin,
On Wednesday 03 May 2006 22:43, Gregory Maxwell wrote:
On 5/3/06, Elliott F. Cable ecable@avxw.com wrote:
[snip]
Perl?
You're kidding right?
Is there some rule that says mediawiki must be written in a language which encourages, nay demands!, unmaintainable results?
You just insulted me as a Perl programmer that all my code is unmaintanable. Please have a look at:
I'd humbly suggest that there are better things to discuss here than if certain languages are more maintainable than others. A good programmer can write maintainable code in any language; similarly a bad programmer can write crap anywhere, too.
Are we here to have a meaningful discussion about MW, or just engage in useless language debates?
Er, my mail should have gone only to the author, not the list. My apologies.
Best wishes,
Tels
-- Signed on Thu May 4 12:38:41 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email.
"Sundials don't work, the one I've had in my basement hasn't changed time since I installed it." grub (11606) on 2004-12-03 on /.
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Tels wrote:
You just insulted me as a Perl programmer that all my code is unmaintanable.
Can we please drop this discussion? People are free to use whatever tools make them happy. MediaWiki currently happens to be a huge PHP codebase. Rewriting the core, even in PHP, is absolutely inappropriate for a SoC project; rewriting all of MW in a different language is not likely to happen anytime soon. Pointless language bickering adds unnecessary and irrelevant noise to this list; those inclined to continue it should do so privately.
On 03/05/06, Elliott F. Cable ecable@avxw.com wrote:
We're working on a complete re-write of MW in Perl. Well not exactly a port, but we like lots of mediawiki features, and will be really looking at it for tips, we just like perl more and need a few things customized to work with our goal instead of the messed up wikimedia one; including a lot more support for integration between wikis on a network.
Your post seems to assume two things which are fallacious, as far as I can tell.
1. "the messed up Wikimedia [goal]"
That a particular organisation chooses to persue a particular course which differs from that of another does not disqualify the intentions as "messed up". If the product is not fit for your purpose, don't use it. Roll your own, as you are apparently doing.
2. "a lot more support for integration between wikis on a network"
I was under the understanding that cross-wiki interaction is beginning to pick up in terms of priorities and sharing of data, etc. Lack of implementation does not equal lack of intention.
Rob Church
On 5/3/06, Elliott F. Cable ecable@avxw.com wrote:
including a lot more support for integration between wikis on a network.
If you are referring to the ability of MediaWiki to host multiple wikis and have more robust support for permissions, then look no further than my SoC application. If you have something else in mind, please share.
In the ideal world, we have a formalized parser syntax complete with XML representation and a robust web API and MediaWiki is just a nice interface to the web API. Nothing more. Nothing less. But that's my middleware mind speaking...
On 03/05/06, Gregory Szorc gregory.szorc@gmail.com wrote:
On 5/3/06, Elliott F. Cable ecable@avxw.com wrote:
including a lot more support for integration between wikis on a network.
If you are referring to the ability of MediaWiki to host multiple wikis and have more robust support for permissions.
Um...one can't run multiple wikis with MediaWiki?
I KNEW IT! THIS WIKIMEDIA THING IS AN ELABORATE CON! A HOAX! YOU HAVE PULLED THE WOOL OVER ALL OUR EYES, VIBBER! I DEMAND VENGEANCE!
[Please don't stab me.]
Rob Church
Wikimedia sites aren't well integrated, nor are they meant to be. I am talking swarms of sites, many more than wikimedia has or plans to have - separate sites, not language translations. For instance, we are constantly changing what are currently called mediawiki: namespace messages - for us, an integration closer to that of images (where the message would be pulled off of meta if it doesn't exist locally) would be more ideal. Also, pages can be shared or marked as global on meta, in which case they are (again) treated the same. Help: namespace would be global, so the help documents would only have to be written once and maintained on one site; same for user pages, as users are global already (more support for that would be integrated, as well as different preferences on different network sites, and keep the sessions across wikis), and project: pages would be eschewed, as information about each project would be on meta - again, more customizations like this focused on a hub-sattelite architecture. Our main goal is just using perl, however - much of mediawiki is very well done and salvageable! We're just planning on working in something more powerful than... php... ^^/
I am sure mediawiki works for you; I'm just saying it doesn't work for us, thus we're doing it another way. Why blow up at me? Many people prefer Perl over PHP; actually, all the ones I know well do... I have yet (until the other message in this thread ("Is there some rule that says mediawiki must be written in a language which encourages, nay demands!, unmaintainable results?") I have actually never in my coding life heard somebody support php as a viable language to develop in... perhaps I'm just crazy. Whatever. I'm not saying you should change MediaWiki to perl, that'd be lots of largely-useless work for you.
On May 3, 2006, at 1:05 PM, Rob Church wrote:
On 03/05/06, Gregory Szorc gregory.szorc@gmail.com wrote:
On 5/3/06, Elliott F. Cable ecable@avxw.com wrote:
including a lot more support for integration between wikis on a network.
If you are referring to the ability of MediaWiki to host multiple wikis and have more robust support for permissions.
Um...one can't run multiple wikis with MediaWiki?
I KNEW IT! THIS WIKIMEDIA THING IS AN ELABORATE CON! A HOAX! YOU HAVE PULLED THE WOOL OVER ALL OUR EYES, VIBBER! I DEMAND VENGEANCE!
[Please don't stab me.]
Rob Church _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 5/3/06, Elliott F. Cable ecable@avxw.com wrote:
I'm not saying you should change MediaWiki to perl, that'd be lots of largely-useless work for you.
So in essence you're working on a different codebase, in a different language, with different design goals... this seems like a strange basis for any conversation about MediaWiki on this mailing list, and a situation prone to people reacting in ways that don't make sense to one another. ;)
I've seen large sites written in a variety of languages (Google has at least one major web app written using Java, the GarageGames website is all PHP and one of the top 3 sites for games programming according to Alexa, there are several big portal sites on ColdFusion, slashdot is still in Perl last I checked, and even some guys doing things in C++!). Whatever works for your team and situation is best, of course, but I don't think the _viability_ of projects in non-PERL languages is really open to question. They seem to be doing quite well. :)
-- Ben Garney Torque Technologies Director GarageGames.Com, Inc.
On Wed, May 03, 2006 at 02:45:15PM -0700, Ben Garney wrote:
I've seen large sites written in a variety of languages (Google has at least one major web app written using Java, the GarageGames website is all PHP and one of the top 3 sites for games programming according to Alexa, there are several big portal sites on ColdFusion, slashdot is still in Perl last I checked, and even some guys doing things in C++!). Whatever works for your team and situation is best, of course, but I don't think the _viability_ of projects in non-PERL languages is really open to question. They seem to be doing quite well. :)
I'm pretty sure the point wasn't "non-Perl languages aren't viable", but that PHP is a huge pile of functions held together by an anemic syntax, and they'd prefer to use something a little more robust than that. Python, Ruby, C/C++, Java, or Lisp might well have been the option if the programmers discussing this liked those languages better, I would guess -- but, apparently, they like Perl. Frankly, I sympathize.
Of course, PHP is still very useful. It's just not typically my own first choice for anything beyond the occasional bit of markup-embedded control structures and includes.
Moin,
On Thursday 04 May 2006 01:11, Chad Perrin wrote:
On Wed, May 03, 2006 at 02:45:15PM -0700, Ben Garney wrote:
I've seen large sites written in a variety of languages (Google has at least one major web app written using Java, the GarageGames website is all PHP and one of the top 3 sites for games programming according to Alexa, there are several big portal sites on ColdFusion, slashdot is still in Perl last I checked, and even some guys doing things in C++!). Whatever works for your team and situation is best, of course, but I don't think the _viability_ of projects in non-PERL languages is really open to question. They seem to be doing quite well. :)
I'm pretty sure the point wasn't "non-Perl languages aren't viable", but that PHP is a huge pile of functions held together by an anemic syntax, and they'd prefer to use something a little more robust than that. Python, Ruby, C/C++, Java, or Lisp might well have been the option if the programmers discussing this liked those languages better, I would guess -- but, apparently, they like Perl. Frankly, I sympathize.
Of course, PHP is still very useful. It's just not typically my own first choice for anything beyond the occasional bit of markup-embedded control structures and includes.
And as an author with thousand lines of Perl under my belt (do they make me look fat?) who wrote recently his first PHP extensions, I can just say
Amen!
How in the world am I supposed to work if the "compiler" doesn't tell me that I typoed $sMyStringType as $sMxStringType? Bah!
Back to the topic, I think the tool doesn't matter as much as the tool-yielder. A good programmer can write robust code in anything. (and vice versa!)
But I do not blame or bash people when they want to use tools that support them and help them, instead of something that hates the tool-user :)
(Specific examples not named, because this would start a silly and useless flamewar)
As for MW, refactoring and improving two specific points:
* usage of globals * mixing of code and data (and data and code in skins)
would be the first goal, but you don't need a full rewrite for that, especially not from scratch.
If you want to build something that is suitable different than MW, well, I guess then it makes sense to re-invent a few bits. But maybe MW could be structured so that it provides a low-level lib, which can then be extended etc. Basically an API and interface sitting on top of a few backend libraries.
The the guys wanting to use Perl wouldn't need to re-invent the mysql backend :) Just throwing out ideas.
Best wishes,
Tels
On Thu, May 04, 2006 at 01:42:38AM +0200, Tels wrote:
"In my opiniation, "burglarize" is a perfectionally validative wordification. How else would reportization of the securitial/policial forceship appearize to be importantive enoughly to be respectative by the massmediaship and influentate the societyness?" SharpFang (651121) on 2004-12-13 at /. about "burgle" vs. "burglarize"
This may come off as needlessly superficial, but your sig was my favorite part of the email.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The the guys wanting to use Perl wouldn't need to re-invent the mysql backend :) Just throwing out ideas.
That's the easy part - I'm already running MW on PostgreSQL. :) Next step is to move some of the logic into the database. *Then* we can port the whole thing to Perl...
- -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200605040944 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
On Thu, May 04, 2006 at 01:46:01PM -0000, Greg Sabino Mullane wrote:
The the guys wanting to use Perl wouldn't need to re-invent the mysql backend :) Just throwing out ideas.
That's the easy part - I'm already running MW on PostgreSQL. :) Next step is to move some of the logic into the database. *Then* we can port the whole thing to Perl...
Is there enough involved these days in running MW against Pg to entail writing a howto? (Or, I think, updating the one that's already on meta...)
Cheers, -- jra
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Is there enough involved these days in running MW against Pg to entail writing a howto? (Or, I think, updating the one that's already on meta...)
Once my current patches get applied, it should be pretty seamless as far as using Pg vs mysql: just pick which one you want on the config screen. (Updating an existing installation is another matter I'm deferring for now).
Once the patches are in place and things a little further along (e.g. everything just works from start to finish), I'll update the existing docs.
- -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200605051256 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
Gregory Szorc wrote:
I was curious what the current plans are for MW 2.0. Will it just be announced sometime during the quarterly release schedule? Will it be a considerable rewrite?
Whether there will even be a 2.0 is an open question. So far we've made huge changes in internal structure incrementally, without having to rewrite everything, and there's no obvious reason why this can't continue.
If the later, I have an interesting idea for SoC. How about somebody rewrite the MW 1.6 core. Details of the rewrite would include
A core rewrite is I think not going to work for SoC. :)
*Changing everything to PHP 5 (better OO support in core)
We already require PHP 5 for 1.7, and will be making more use of the new features as things get refactored.
*Eliminating $wg global usage.
This too happens piece by piece. Most non-configuration globals have been pruned from most code, though there's still further work to be done.
-- brion vibber (brion @ pobox.com)
On 5/3/06, Brion Vibber brion@pobox.com wrote:
Gregory Szorc wrote:
I was curious what the current plans are for MW 2.0. Will it just be announced sometime during the quarterly release schedule? Will it be a considerable rewrite?
Whether there will even be a 2.0 is an open question. So far we've made huge changes in internal structure incrementally, without having to rewrite everything, and there's no obvious reason why this can't continue.
If the later, I have an interesting idea for SoC. How about somebody rewrite the MW 1.6 core. Details of the rewrite would include
A core rewrite is I think not going to work for SoC. :)
*Changing everything to PHP 5 (better OO support in core)
We already require PHP 5 for 1.7, and will be making more use of the new features as things get refactored.
*Eliminating $wg global usage.
This too happens piece by piece. Most non-configuration globals have been pruned from most code, though there's still further work to be done.
Thank you, Brion, for the reply. This is exactly what I wanted to hear.
Would a suitable project for SoC be to go through the code base and assist with the PHP 5/$wg global phase out that has been occurring with 1.7? For example, adding visibility keywords on all the functions and fixing all the references to functions that are currently marked with comments as private or protected? On top of that, someone could update all the functions that have a better PHP 5 implementation. For example, replacing the XML functions with PHP 5 DOM ones and replacing all the references to the old functions.
Gregory Szorc gregory.szorc@gmail.com
Gregory Szorc schrieb:
On 5/3/06, Brion Vibber brion@pobox.com wrote:
Gregory Szorc wrote:
I was curious what the current plans are for MW 2.0. Will it just be announced sometime during the quarterly release schedule? Will it be a considerable rewrite?
Whether there will even be a 2.0 is an open question. So far we've made huge changes in internal structure incrementally, without having to rewrite everything, and there's no obvious reason why this can't continue.
If the later, I have an interesting idea for SoC. How about somebody rewrite the MW 1.6 core. Details of the rewrite would include
A core rewrite is I think not going to work for SoC. :)
*Changing everything to PHP 5 (better OO support in core)
We already require PHP 5 for 1.7, and will be making more use of the new features as things get refactored.
*Eliminating $wg global usage.
This too happens piece by piece. Most non-configuration globals have been pruned from most code, though there's still further work to be done.
Thank you, Brion, for the reply. This is exactly what I wanted to hear.
Would a suitable project for SoC be to go through the code base and assist with the PHP 5/$wg global phase out that has been occurring with 1.7? For example, adding visibility keywords on all the functions and fixing all the references to functions that are currently marked with comments as private or protected? On top of that, someone could update all the functions that have a better PHP 5 implementation. For example, replacing the XML functions with PHP 5 DOM ones and replacing all the references to the old functions.
For an initial attempt to get rid of the last globals, see index.php and include/Wiki.php One could expand on that.
Magnus
Moin,
On Thursday 04 May 2006 02:14, Gregory Szorc wrote:
On 5/3/06, Brion Vibber brion@pobox.com wrote:
Gregory Szorc wrote:
I was curious what the current plans are for MW 2.0. Will it just be announced sometime during the quarterly release schedule? Will it be a considerable rewrite?
[snip]
Thank you, Brion, for the reply. This is exactly what I wanted to hear.
Would a suitable project for SoC be to go through the code base and assist with the PHP 5/$wg global phase out that has been occurring with 1.7? For example, adding visibility keywords on all the functions and fixing all the references to functions that are currently marked with comments as private or protected? On top of that, someone could update all the functions that have a better PHP 5 implementation. For example, replacing the XML functions with PHP 5 DOM ones and replacing all the references to the old functions.
Another worthwhil project would be to properly tag variables so that doxygen can extract/find them. Unfortunately, I am not a student, so I cant apply :D
Best wishes,
Tels
Brion Vibber wrote:
Gregory Szorc wrote:
I was curious what the current plans are for MW 2.0. Will it just be announced sometime during the quarterly release schedule? Will it be a considerable rewrite?
Whether there will even be a 2.0 is an open question. So far we've made huge changes in internal structure incrementally, without having to rewrite everything, and there's no obvious reason why this can't continue.
I suggested calling 1.5 2.0, but that didn't quite happen. One of the problems with it is that you usually expect a change in major version number to come along with significant user-visible changes. But in the current development model, you can't expect two big things to happen at once.
Gregory suggests calling the MediaWiki with refactored code "1.99" and then calling this refactored code plus some extra features "2.0". I suspect the two would more likely be tagged 1.7 and 1.8.
Maybe we should just drop the "1." and call the next release 7.0. Makes for less typing. Someone remind me which software project did that...
-- Tim Starling
On Thu, May 04, 2006 at 02:47:11PM +1000, Tim Starling wrote:
Gregory suggests calling the MediaWiki with refactored code "1.99" and then calling this refactored code plus some extra features "2.0". I suspect the two would more likely be tagged 1.7 and 1.8.
Maybe we should just drop the "1." and call the next release 7.0. Makes for less typing. Someone remind me which software project did that...
Java. Ick.
I know you're kidding, but I just ate. Please don't say things like that when I've just eaten.
Cheers, -- jra
On Thu, 2006-05-04 at 14:47 +1000, Tim Starling wrote:
Maybe we should just drop the "1." and call the next release 7.0. Makes for less typing. Someone remind me which software project did that...
GNU Emacs: went from version 1.1 to 1.12, then dropped the initial "1" and has continued from version 13 to version 21 (so far).
Carl Witty
On Thu, May 04, 2006 at 11:44:52AM -0700, Carl Witty wrote:
Maybe we should just drop the "1." and call the next release 7.0. Makes for less typing. Someone remind me which software project did that...
GNU Emacs: went from version 1.1 to 1.12, then dropped the initial "1" and has continued from version 13 to version 21 (so far).
Less has never had "traditional" version numbers; it's up near version 247 or something.
Cheers, -- jra
On May 4, 2006, at 9:57 AM, Jay R. Ashworth wrote:
On Thu, May 04, 2006 at 11:44:52AM -0700, Carl Witty wrote:
Maybe we should just drop the "1." and call the next release 7.0. Makes for less typing. Someone remind me which software project did that...
GNU Emacs: went from version 1.1 to 1.12, then dropped the initial "1" and has continued from version 13 to version 21 (so far).
Less has never had "traditional" version numbers; it's up near version 247 or something.
Mac OS X? Other way around - went from system 7, 8, OS 9 - then 10.1 (10), 10.2 (11), 10.3 (12), 10.4 (13) and soon, 10.5 (14) - I tend to find that copying something apple did leads to success, ESPECIALLY when they changed something - usually, when they admit they made a mistake (very rare) and fix it in a given way (much less rare) then they usually fix it 100%, and put lots of thought into their decision. I see the fact that they ended up using a X.YY system means we should stick to the same, but maybe that's just me.
On 04/05/06, Elliott F. Cable ecable@avxw.com wrote:
On May 4, 2006, at 9:57 AM, Jay R. Ashworth wrote:
On Thu, May 04, 2006 at 11:44:52AM -0700, Carl Witty wrote:
Maybe we should just drop the "1." and call the next release 7.0. Makes for less typing. Someone remind me which software project did that...
GNU Emacs: went from version 1.1 to 1.12, then dropped the initial "1" and has continued from version 13 to version 21 (so far).
Less has never had "traditional" version numbers; it's up near version 247 or something.
Mac OS X? Other way around - went from system 7, 8, OS 9 - then 10.1 (10), 10.2 (11), 10.3 (12), 10.4 (13) and soon, 10.5 (14) - I tend to find that copying something apple did leads to success, ESPECIALLY when they changed something - usually, when they admit they made a mistake (very rare) and fix it in a given way (much less rare) then they usually fix it 100%, and put lots of thought into their decision. I see the fact that they ended up using a X.YY system means we should stick to the same, but maybe that's just me.
I can't believe that people are bothering to go out and research the version numbering schemes of different products in order to bolster this one's reputation through some implied connotation.
What's the problem with sticking to 1.x.y, and incrementing the 1 when we can all agree that a single release has inserted something highly significant into the product?
Don't count your bridges before you cross them. Don't worry about numbering your versions until you have them.
Rob Church
On May 4, 2006, at 1:11 PM, Rob Church wrote:
On 04/05/06, Elliott F. Cable ecable@avxw.com wrote:
On May 4, 2006, at 9:57 AM, Jay R. Ashworth wrote:
On Thu, May 04, 2006 at 11:44:52AM -0700, Carl Witty wrote:
Maybe we should just drop the "1." and call the next release 7.0. Makes for less typing. Someone remind me which software project did that...
GNU Emacs: went from version 1.1 to 1.12, then dropped the initial "1" and has continued from version 13 to version 21 (so far).
Less has never had "traditional" version numbers; it's up near version 247 or something.
Mac OS X? Other way around - went from system 7, 8, OS 9 - then 10.1 (10), 10.2 (11), 10.3 (12), 10.4 (13) and soon, 10.5 (14) - I tend to find that copying something apple did leads to success, ESPECIALLY when they changed something - usually, when they admit they made a mistake (very rare) and fix it in a given way (much less rare) then they usually fix it 100%, and put lots of thought into their decision. I see the fact that they ended up using a X.YY system means we should stick to the same, but maybe that's just me.
I can't believe that people are bothering to go out and research the version numbering schemes of different products in order to bolster this one's reputation through some implied connotation.
What's the problem with sticking to 1.x.y, and incrementing the 1 when we can all agree that a single release has inserted something highly significant into the product?
Don't count your bridges before you cross them. Don't worry about numbering your versions until you have them.
Was just kidding - and I wasn't saying we should change it, I was vouching keeping it as it is (-:
On Thu, May 04, 2006 at 01:04:42PM -0800, Elliott F. Cable wrote:
Mac OS X? Other way around - went from system 7, 8, OS 9 - then 10.1 (10), 10.2 (11), 10.3 (12), 10.4 (13) and soon, 10.5 (14) - I tend to find that copying something apple did leads to success, ESPECIALLY when they changed something - usually, when they admit they made a mistake (very rare) and fix it in a given way (much less rare) then they usually fix it 100%, and put lots of thought into their decision. I see the fact that they ended up using a X.YY system means we should stick to the same, but maybe that's just me.
There's some truth in that -- but you might want to think about all the implications of their decisions. The reason for the change in version numbering for MacOS seems to have been made for reasons other than how pretty the version numbers look.
After all, the version numbers are largely targeted at technically oriented people who just want a sense of continuity to the versioning. The reason there's a 10.x anything is that MacOS X followed MacOS 9. They're dragging out the 10.x because of the association of 10 with X.
The real marketing decision on the front-end was to use "X" in the OS name after the rewrite and stuff like "Panther" and "Tiger" for versions.
In fact, they may well end up going to 10.x.x if this gets dragged out long enough to make it necessary to avoid a 10.247 version number. I think it's a lot more likely they'll go the Emacs/Java route, though, and drop the 10. part of the version numbering, if they don't toss out their current numbering system entirely and do another significant paradigm shift in the way they present their OS to the world instead.
On Thu, May 04, 2006 at 03:41:48PM -0600, Chad Perrin wrote:
On Thu, May 04, 2006 at 01:04:42PM -0800, Elliott F. Cable wrote:
Mac OS X? Other way around - went from system 7, 8, OS 9 - then 10.1 (10), 10.2 (11), 10.3 (12), 10.4 (13) and soon, 10.5 (14) - I tend to find that copying something apple did leads to success, ESPECIALLY when they changed something - usually, when they admit they made a mistake (very rare) and fix it in a given way (much less rare) then they usually fix it 100%, and put lots of thought into their decision. I see the fact that they ended up using a X.YY system means we should stick to the same, but maybe that's just me.
There's some truth in that -- but you might want to think about all the implications of their decisions. The reason for the change in version numbering for MacOS seems to have been made for reasons other than how pretty the version numbers look.
After all, the version numbers are largely targeted at technically oriented people who just want a sense of continuity to the versioning.
Ah... someone who likes my addition to [[Version number]]. :-)
The reason there's a 10.x anything is that MacOS X followed MacOS 9. They're dragging out the 10.x because of the association of 10 with X.
Indeed. And it's worth noting, too, that Elliot is apparently missing the fact that 7, 8, and 9 all had sub-version numbers, as well. So, no, 10.2 != 11.
In fact, they may well end up going to 10.x.x if this gets dragged out long enough to make it necessary to avoid a 10.247 version number. I think it's a lot more likely they'll go the Emacs/Java route, though, and drop the 10. part of the version numbering, if they don't toss out their current numbering system entirely and do another significant paradigm shift in the way they present their OS to the world instead.
Well, one can *hope* the engineers will win out over the marketers; look what happened to Motorola when that stopped being the case. Or HP.
Thank ghod it hasn't happened to state Departments of Transportation. Would you want to drive on Interstates that were designed for looks?
Cheers, -- jra
On Fri, May 05, 2006 at 08:44:51AM -0400, Jay R. Ashworth wrote:
On Thu, May 04, 2006 at 03:41:48PM -0600, Chad Perrin wrote:
After all, the version numbers are largely targeted at technically oriented people who just want a sense of continuity to the versioning.
Ah... someone who likes my addition to [[Version number]]. :-)
Actually . . . I haven't read it. I should.
I guess I will, as soon as I get off hold with tech support for my webhost.
The reason there's a 10.x anything is that MacOS X followed MacOS 9. They're dragging out the 10.x because of the association of 10 with X.
Indeed. And it's worth noting, too, that Elliot is apparently missing the fact that 7, 8, and 9 all had sub-version numbers, as well. So, no, 10.2 != 11.
I didn't follow the doings of Apple as much before MacOS X. Their OS simply didn't provide the general functionality domain I needed -- it didn't intersect at all with the purposes to which I put computers, basically. As such, I didn't know they released minor versions that were numbered in that fashion.
In fact, they may well end up going to 10.x.x if this gets dragged out long enough to make it necessary to avoid a 10.247 version number. I think it's a lot more likely they'll go the Emacs/Java route, though, and drop the 10. part of the version numbering, if they don't toss out their current numbering system entirely and do another significant paradigm shift in the way they present their OS to the world instead.
Well, one can *hope* the engineers will win out over the marketers; look what happened to Motorola when that stopped being the case. Or HP.
I don't think there's really a "marketers have won now" cut-off point at either company. In each case, some significant battles have been won in a way that makes it painfully obvious to we outsiders, but there are still occasional signs that the engineers get to make decisions that make it out to the real world now and then. This might be especially notable to me because I'm currently living in an area littered with HP research centers.
By the way, the fact that the engineers still make about 98% of the decisions related to Linux, outside of companies like Mandriva and Canonical (where the decisions are somewhat closer to 50%, from what I've seen so far), is probably a significant contributing factor to the condition of low market and mindshare penetration for desktops and even servers in certain market niches. Engineers have an even greater hold on decision making for *BSD, which is (I think) why the various BSDs are even less widely known and implemented than Linux distributions.
. . . but I digress.
Thank ghod it hasn't happened to state Departments of Transportation. Would you want to drive on Interstates that were designed for looks?
Unfortunately, the bureaucrats are in charge, rather than either marketing or engineers.
There's a freeway interchange in Southern California that bears a passing resemblance to a cloverleaf interchange, but as designed by someone with a sick, diabolical sense of humor. This is perhaps the worst-designed interchange I have ever seen in my life, and worse than any I expect to see any time soon. Ironically, the man who designed it is rumored to have died there.
That sounds a little like poetic justice.
On May 5, 2006, at 4:44 AM, Jay R. Ashworth wrote:
On Thu, May 04, 2006 at 03:41:48PM -0600, Chad Perrin wrote:
On Thu, May 04, 2006 at 01:04:42PM -0800, Elliott F. Cable wrote:
Mac OS X? Other way around - went from system 7, 8, OS 9 - then 10.1 (10), 10.2 (11), 10.3 (12), 10.4 (13) and soon, 10.5 (14) - I tend to find that copying something apple did leads to success, ESPECIALLY when they changed something - usually, when they admit they made a mistake (very rare) and fix it in a given way (much less rare) then they usually fix it 100%, and put lots of thought into their decision. I see the fact that they ended up using a X.YY system means we should stick to the same, but maybe that's just me.
The reason there's a 10.x anything is that MacOS X followed MacOS 9. They're dragging out the 10.x because of the association of 10 with X.
Indeed. And it's worth noting, too, that Elliot is apparently missing the fact that 7, 8, and 9 all had sub-version numbers, as well. So, no, 10.2 != 11.
I'm not missing the fact that the old OS had version numbers - Hehe I remember excitement at the updates (-:
I'm saying that the change from 10.1 to 10.2 is MORE than enough to qualify a major change - I should have specified more; let me re- write that: They switched from 7.x -> 8.x -> 9.x (snap!) 10.1.x -> 10.2.x -> 10.3.x -> 10.4.x and so on. And yes, I am aware that 7-9 had sub-sub versions also, I am just saying that their entire numbering system was A) reset to 1 B) moved one place to the right, and C) prefixed by 10. Make sense now? [-;
On Thu, May 04, 2006 at 11:44:52AM -0700, Carl Witty wrote:
On Thu, 2006-05-04 at 14:47 +1000, Tim Starling wrote:
Maybe we should just drop the "1." and call the next release 7.0. Makes for less typing. Someone remind me which software project did that...
GNU Emacs: went from version 1.1 to 1.12, then dropped the initial "1" and has continued from version 13 to version 21 (so far).
I wasn't aware of that one. I knew about the Java example, though.
Of course, I wouldn't expect to know that much about Emacs. After all, I already have an OS. I don't need another.
wikitech-l@lists.wikimedia.org