Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Wikipedia Chooses Lua As Its New Template Language

Unknown Lamer posted about 2 years ago | from the mccarthy-seen-greenspunning-in-his-grave dept.

Programming 145

bonch writes "In an attempt to tackle the inefficient complexity of its current template system, Wikipedia will be adopting the Lua scripting language. Known most for its use in videogame scripting, particularly World of Warcraft, Lua is lightweight and designed for easy integration into existing applications. The transition is expected to begin after the release of MediaWiki 1.19, possibly in May." Basically, the template system started turning into an ugly programming language. There was debate over using Javascript or Lua; Lua ultimately won due to implementation concerns. The mailing list threads announcing the decision and discussing the change have further details.

cancel ×

145 comments

Sorry! There are no comments related to the filter you selected.

Lua (1, Flamebait)

serkit (2358056) | about 2 years ago | (#38891643)

Lua is a terrible language. What is wrong with you people?

Re:Lua (2, Insightful)

Anonymous Coward | about 2 years ago | (#38891653)

As opposed to Javascript?

Re:Lua (0, Troll)

kelemvor4 (1980226) | about 2 years ago | (#38891739)

As opposed to Javascript?

Yes, that's a good example of a better choice.

Re:Lua (0)

Anonymous Coward | about 2 years ago | (#38891789)

No, Lua is a good example of a better choice, which is why they chose it. Shut the fuck up if you won't back up your points (my post being an example just so you get it)

Re:Lua (5, Funny)

Anonymous Coward | about 2 years ago | (#38891883)

Javascript is web scale. Lua is not web scale. Also: Lua comes from Brazil. You know what else comes from Brazil? Waxed balls. I wouldn't trust a programmer that waxes his balls. If he can't make good decisions involving his nutsack, can he make godo decisions involving language design? (Just look at PHP!)

Re:Lua (3, Funny)

james_van (2241758) | about 2 years ago | (#38891987)

That's a really valid argument. Im inclined to agree.

Re:Lua (1)

Ihmhi (1206036) | about 2 years ago | (#38895373)

For some strange reason, so am I...

Re:Lua (0)

Anonymous Coward | about 2 years ago | (#38892009)

What the fuck is web scale? Some kind of armor from fantasy RPG?

Re:Lua (1)

Anonymous Coward | about 2 years ago | (#38894671)

MongoDB is web scale. It's got what plants crave.

Re:Lua (0)

Anonymous Coward | about 2 years ago | (#38893967)

Wait wait, do waxed balls support sharding?

Re:Lua (3, Funny)

glwtta (532858) | about 2 years ago | (#38895299)

I wouldn't trust a programmer that waxes his balls. If he can't make good decisions involving his nutsack, can he make godo decisions involving language design?

Seems like a perfectly good decision to me. There really is nothing like a shorn scrotum, it's breathtaking; I suggest you try it.

Re:Lua (0)

Anonymous Coward | about 2 years ago | (#38895721)

Hey!
Careful with what you say.
I wax my balls too and I'm not from Brazil... (I wonder if maybe that's the reason I'm not a programmer nut a marketing analyst instead)

Re:Lua (1)

geminidomino (614729) | about 2 years ago | (#38896363)

I wax my balls too and I'm not from Brazil... (I wonder if maybe that's the reason I'm not a programmer nut a marketing analyst instead)

I see what you did there...

Re:Lua (1)

mwvdlee (775178) | about 2 years ago | (#38893345)

As opposed to whatever scripting language(s) MediaWiki was already using for the rest of it's code.

Re:Lua (4, Funny)

Hognoxious (631665) | about 2 years ago | (#38892179)

Lua is a terrible language. It is also an excellent language.

FTFY (see WP:NPOV)

Re:Lua (2, Informative)

Anonymous Coward | about 2 years ago | (#38892511)

I've never been able to get into Lua, whereas Python and Javascript I have. I prefer C/C++, Java, C# however. Though, if I had to pick a scripting language to use I'd use Python. Ruby is unbearable for me, I've tried to like it just can't. Lua isn't unbearable so much as I'm generally too bored with it to try it.

Things I generally don't like about Lua:
1) Lua replaced the ! symbol with ~ for Not. This doesn't make any sense. Not that ! made much sense either. I do like that they added a "not" keyword. That at least makes sense.
2) It feels very BASIC with its do, end, then, end etc. That's not a good thing. We should be moving away from that garbage.
3) I'm not a particular fan of any language that wants me to type one of; local, let, or var. The parser should be able to figure out when I'm assigning at all times. And, they still use == in this language which is silly since the whole point of using local, let, or var is so you can distinguish = from assignment or condition. It's annoying when languages that do this. Having said that, you could just pull a Pascal instead := or something if you absolutely must avoid ==, I'd complain a lot less. At least it's a clever and convenient way of addressing the problem. Let's face it, == only makes sense to a programmer, a mathematician would look at you weird. Then again they'd look sideways at := too, whereas Let in math has a meaning. Really I think math should teach := and drop the let, it'll save room on whiteboards.
4) Why should you have to prepend = to evaluate something? Like: = 2+3, or even = 3 == 3. Why can't I just type 2+3, or even 3 == 3? It's weird.
5) They went so different with everything, but they kept % for modulo? Doesn't make sense, why not just type mod? The symbol never made much sense. If they were being really adventurous they would have tried harder IMHO. Having said that, I respect that they switched ^ to power instead of xor.
6) I'm not a fan of using .. to concatenate strings either. "a".."bc" looks godawful goofy. I much prefer "a" + "bc". I get that it can cause problems when you need to mix in math, but that's what parenthesis are for. I see why they didn't use + though, they support "coercion", like 100 + "7" becomes a 107 integer. Which is a pretty cool concept I guess. But, it forces you do something weird like .. for concatenation which is a minus against it. Maybe they could have done just "a" "bc" becomes "abc". Then it'd be as simple as two strings like str1, str2 just being placed like... str1 str2 in order to concatenate them. Then they could still use + for coercion.
7) I don't mind nil for NULL. It's better than Python's Nothing IMO because it's shorter. Though, I see where Python was going, they were trying to make it obvious when read by a user who doesn't know programming. However, the rest of Python isn't obvious to a non-programmer anyways, so that defeats the purpose. Whereas, nil is at least is less typing, doesn't require an uppercase, and it has an English and Latin definition so as far as being a real word it's wins against Nothing in at least simplicity. I give them props for using this.
8) tonumber("10") is goofy, they're going for English I guess. Python's int("10") is less typing so I'd prefer that. I think when it comes to English vs typing less, as long as it isn't a weird symbol that makes no sense, I lean towards typing less. However, I could live with tonumber, it's not one of the worst things in this language.
9) Having to type function or def in a language to declare a method is annoying. If I was forced at gunpoint to choose, I'd probably go with function because at least it's obvious, less typing didn't win out here, def is weird looking and doesn't make sense at all. The def keyword reminds me of Sub from BASIC, in a bad way. I realize it's a bastardization of defmethod from Lisp. If we absolutely have to have some way of parsing methods (I think there should be a way around it IMO) starting points, then why not use a symbol here instead like we do for everything else. It's so weird that they never think of that, they're so busy throwing random symbols at everything else. Like say we used @ or something. Here's maybe how my hypothetical language would look, for a method:
@DriveMyCar() ( print("Vroom vroom") )
There I just solved the brackets vs whitespace vs do end and also the function vs def debate in one short line.
10) I really don't like the idea of, a,b,c = f(), x where f is f(x,y,z) and f() is adjusted to 1 result, and c becomes nil. That is odd and doesn't make any sense.

Having said all that, there are worse languages *cough*Ruby*cough* they could have chosen. There's probably more I don't like that I can't think of right now.

Re:Lua (1)

lahvak (69490) | about 2 years ago | (#38893495)

This is probably the stupidest rant I have read in a long time.

Re:Lua (2, Interesting)

Anonymous Coward | about 2 years ago | (#38893549)

1) In standard logic, ~ means NOT. Since LUA uses functions for it's bit-wise operations, I see no issue with using this.
2) Why? People don't consider C to be BASIC and it allows pre and post-test WHILE loops.
3,4) I got nothing
5) You should really make up your mind here. They use the normal % for modulo and you complain? Come on now.
6) PHP uses . to concatenate strings, seems like you're splitting hairs here for no particular reason other than to complain.
7) Wow, you found something good?
8) LUA is dynamically typed, why would they have an int()?
9,10) You really shouldn't be using LUA... go with a language that you like. It sounds like you prefer Python anyways.

Just as a note, I haven't programmed anything in LUA before but I've looked at the code and looked over the reference manual. Looks like a fine language; I just have no use for it as of yet.

Re:Lua (0)

Anonymous Coward | about 2 years ago | (#38894073)

What's with the caps? Lua is not an acronym.

Re:Lua (1)

empty mind (1355971) | about 2 years ago | (#38896679)

I know it's not a big problem but... Not all keyboard layouts have a "~".

Re:Lua (2)

Xtifr (1323) | about 2 years ago | (#38894391)

Disclaimer: I mostly like Lua, though I wouldn't say I love it. Like all languages, it has advantages and disadvantages. Lua's strength is embedding, though, and that's where it shines--the only other language that comes close is Tcl, and Lua is cleaner, IMO.

1. I mostly agree with you that ~= for not equals was a mistake. As another poster pointed out, it's a somewhat justifiable mistake, but we had nearly managed to standardize !=. Lua is the first recent language to ignore this near-standard. After 11, below, this is probably my biggest complaint about Lua.
2. BASIC? Really? Dude! Those keywords don't come from BASIC! (In fact, I've never used a version of BASIC that supported any of them--oh, and get off my lawn!) Those come from Algol, probably by way of Pascal or Modula, and they're great, which is why BASIC ripped them off--they're probably the only good part of any flavor of BASIC, because they're not BASIC features. :)
3. I'm not sure what you're on about with "local, let and var" (though I think I disagree), but the rest of your rant (about "==") is inconsistent with your earlier complaint about "~=". Like "!=", "==" has become more-or-less standard, and I'm glad Lua didn't decide to innovate here.
4. What are you on about? "print(2+3)" works just fine, as does "a = {1, 2+3}".
5. Man you're stretching! And again, inconsistent with your point 1.
6. Matter of taste. I think I actually prefer "..", but it's not something I feel strongly about either way. Using "+" for concatenation tends to work better in an OO language with operator overriding. Lua's more of a low-level embedded language.
7. Like, whatever. Is this really worth even discussing? 47 different languages do this 47 different ways, and all of them are fine.
8. tonumber() is consistent with the other coercion functions, and if you really hate typing that much, you should probably find another line of work. I certainly wouldn't want to hire you. People who complain about extra typing are generally the ones who write opaque, cryptic, incomprehensible code with no comments.
9. Oh. My. God! If you ever design a language, I will pray that I am never, ever forced to use it! :) Oh, and "def" doesn't come from Lisp--it's simply short for "define". P.s. if you really want to use just one delimiter everywhere, try Tcl. It's not a bad alternative to Lua if you're looking for an embedded language, and it uses curly braces for everything--even function arguments. P.p.s. those aren't methods, because Lua's not an OO language. Those are functions. (Or procedures, though Lua, like most modern languages, doesn't distinguish between the two.)
10. I don't think I've ever encountered this quirk, so I won't comment, except to say, if you don't like that, don't do it!
11. You only had 10 points on your list, and I'm truly amazed you left out the one biggest issue most people (especially those familiar with C, C++, Java, Perl, Python, Ruby, etc.) will trip over--one-based arrays! If you're going to rant about Lua, how can you possibly ignore the exasperating one-based arrays? Are you even a programmer? :)

Anyway, Lua's not really competing directly with perl/python/ruby. Its strength is that it's small, fast, and easily embeddable. The ease with which you can call back and forth between Lua and C is what really makes it shine. Some of its quirks seem to be choices made for performance reasons, and I'm willing to live with that. Overall, I like its style and flavor better than tcl, which seems to be its main competition.

Re:Lua (1)

K. S. Kyosuke (729550) | about 2 years ago | (#38894569)

3) I'm not a particular fan of any language that wants me to type one of; local, let, or var. The parser should be able to figure out when I'm assigning at all times. And, they still use == in this language which is silly since the whole point of using local, let, or var is so you can distinguish = from assignment or condition.

No, the point of local, let or var is to establish a new lexical scope in a clean manner, so that the implementation does not have to guess the actual scope from the place of the first assignment. Lua assigns with =, but it does not establish new lexical bindings with it.

Stop delaying the inevitable. (5, Funny)

MadKeithV (102058) | about 2 years ago | (#38891677)

"the template system started turning into an ugly programming language" - ah, any sufficiently complex system eventually evolves to contain a limited, broken version of Common Lisp.
Stop delaying the inevitable!

Re:Stop delaying the inevitable. (4, Informative)

dkf (304284) | about 2 years ago | (#38891723)

"the template system started turning into an ugly programming language" - ah, any sufficiently complex system eventually evolves to contain a limited, broken version of Common Lisp.

This includes Common Lisp, which contains itself as a proper subset.

Re:Stop delaying the inevitable. (1)

jbolden (176878) | about 2 years ago | (#38894539)

No... Norvig's variant: Any sufficiently complicated Common Lisp program contains an ad-hoc, informally-specified bug-ridden slow implementation of Prolog.

Re:Stop delaying the inevitable. (4, Funny)

goldaryn (834427) | about 2 years ago | (#38891795)

"the template system started turning into an ugly programming language" - ah, any sufficiently complex system eventually evolves to contain a limited, broken version of Common Lisp. Stop delaying the inevitable!

LEEEEEEEROOOY JEEEEEENKIIIIIIIIINNSSS

Re:Stop delaying the inevitable. (0)

Anonymous Coward | about 2 years ago | (#38895319)

"the template system started turning into an ugly programming language" - ah, any sufficiently complex system eventually evolves to contain a limited, broken version of Common Lisp. Stop delaying the inevitable!

LEEEEEEEROOOY JEEEEEENKIIIIIIIIINNTTTHHHHHHHH

FTFY

Re:Stop delaying the inevitable. (4, Insightful)

David Gerard (12369) | about 2 years ago | (#38894081)

The trouble with domain-specific languages is that they are Turing complete. This is a fatal trap: your hammer may be a great hammer, but if it's Turing-complete you will (this is a law of the universe) one day be forced to use it as a screwdriver, spanner, soda siphon, and nail. You will end up having to build a working full-scale replica of the Titanic from toothpicks and spit, complete with iceberg.

Your rule is more like - any domain-specific language will eventually evolve into brainfuck [wikipedia.org] . ParserFunctions certainly did.

Re:Stop delaying the inevitable. (2)

jbolden (176878) | about 2 years ago | (#38894557)

That's why DSL's in LISP are nice. They just admit the problem and include LISP underneath for when you want to do something different.

Re:Stop delaying the inevitable. (1)

David Gerard (12369) | about 2 years ago | (#38896391)

What Lisp-type DSLs are there that people actually use much? The only one I can think of is Guile in GIMP, but it doesn't have a community. (And Emacs Lisp, of course, but Emacs is for goddamn geeks.) Most DSLs that even become popular enough in their area for many people to use them are not far above batch files, with Turing-completeness pretty much a bolt-on. This results in crawling horrors and a need to replace it with a real language, but the beginner user wants something very like batch files.

Re:Stop delaying the inevitable. (1)

K. S. Kyosuke (729550) | about 2 years ago | (#38894597)

"the template system started turning into an ugly programming language" - ah, any sufficiently complex system eventually evolves to contain a limited, broken version of Common Lisp. Stop delaying the inevitable!

Only in this case, it is a case of a system od evolving into a limited and broken version of Scheme. ;-)

Let's Discuss having a Discussion about a Decision (0, Offtopic)

Anonymous Coward | about 2 years ago | (#38891701)

The funny thing about Wikipedia is that there's so many "Bicycle Sheds"(http://en.wikipedia.org/wiki/Bicycle_shed) that we can be ensured that no action ever takes place and there's plenty of people to opine on a point that the implementation of a decision never happens.

Re:Let's Discuss having a Discussion about a Decis (4, Interesting)

Trepidity (597) | about 2 years ago | (#38891715)

This seems to be at least partial evidence that that's not really the case: it was discussed for a while, a decision was made, and implementation rather than further discussion is now happening.

Re:Let's Discuss having a Discussion about a Decis (1)

Anonymous Coward | about 2 years ago | (#38892541)

Exactly what I was thinking. We have a problem: not enough people understand how to edit Wikipedia because of it's complexity. Rather than analyze what makes it complex and how it could be simplified (which is boring), we'll focus on implementing something technically whizzy in some language that's cool, and that will solve the problem.

Re:Let's Discuss having a Discussion about a Decis (0)

Anonymous Coward | about 2 years ago | (#38893177)

Just because the decision has been officially put to rest does not mean that it won't be unofficially/covertly trifled to death. The original posts subject "Let's discuss having a discussion about a decision" may very well still apply.

Re:Let's Discuss having a Discussion about a Decis (3, Interesting)

svick (1158077) | about 2 years ago | (#38894757)

Using Lua instead of the current template syntax will not mean much for editors of articles and nobody claimed it would. It will only make (huge) difference for those who currently write templates.

On the other hand, there is also some work going on to make editing of articles easier using a WYSIWYG editor [mediawiki.org] .

Re:Let's Discuss having a Discussion about a Decis (1)

David Gerard (12369) | about 2 years ago | (#38894103)

That's because it's the devs. They tend to solve stuff in relatively short order.

(The reason a visual editor has taken so long is that it involved not merely an impossibly difficult problem - analysing wikitext - but politics as well - ten years' existing data and a requirement to keep the shitty, shitty format. Wikimedia has lots of sheer brilliance on tap, but this problem also required money and politics.)

Re:Let's Discuss having a Discussion about a Decis (1)

Ihmhi (1206036) | about 2 years ago | (#38895397)

Great. Now if they actually handle the problem of people tapping the proverbial delete button like it dispenses morphine, then myself and a lot of editors will actually have a reason to return to that hellhole.

There is no justification (outside of highly illegal content) for articles being deleted as rapidly as they are. Not in the era of cheap bandwidth, cheap disk space, and crowdsourcing.

Sounds exciting (5, Interesting)

YutakaFrog (1074731) | about 2 years ago | (#38891703)

Lua has some notable differences from more prominent languages like Java, but as a World of Warcraft addon developer, I find it a surprisingly robust and fun language to program in. I look forward to this change to Wikipedia and hope it works well for all of their contributors.

Re:Sounds exciting (4, Funny)

Talderas (1212466) | about 2 years ago | (#38892003)

I want a DPS meter addon for wikipedia.

Re:Sounds exciting (1)

Dotren (1449427) | about 2 years ago | (#38892119)

I want a DPS meter addon for wikipedia.

I think you mean an EPS meter.. or "Edits Per Second". I think that would take all of those cross-editing arguments on there to a whole new level.

Re:Sounds exciting (1)

Anonymous Coward | about 2 years ago | (#38892609)

DPS == Delete Per Second

Of couse, only useful for admins.

Re:Sounds exciting (1)

Anonymous Coward | about 2 years ago | (#38892651)

And a port of Omen to measure editor threat, too.

Re:Sounds exciting (2)

shutdown -p now (807394) | about 2 years ago | (#38894779)

Lua is a language with neat syntax and clear semantics which tend towards minimalism without sacrificing usefulness, that seems to be designed by sane people for a change. Compared to some other *cough* JS *cough* it's practically a godsend.

Oh great (0, Insightful)

Anonymous Coward | about 2 years ago | (#38891741)

Maybe they should take a step back and wonder why templates became so popular in the first place? Now every page looks the same, and sports fifty irrelevant warning messages that "this page is part of blah blah blah" and god help you if you decide not to use the template, or change something you don't like about it, because you will bring down the wrath of the anal-retentive neckbeards that run the place harder than the fist of an angry god.

mod dOw^n (-1)

Anonymous Coward | about 2 years ago | (#38891819)

do, And with any

Raw- or OOP-base Lua? (4, Interesting)

Phrogz (43803) | about 2 years ago | (#38891829)

I'll be interested to see if they go for WoW-style "raw", imperative Lua (gobs of functions) or a more OOP-style Lua [phrogz.net] (NB: my site).

In designing the Lua interface for an old Game UI authoring product [gamasutra.com] I originally went with OOP-style Lua. It was (IMHO) a rather elegant wrapper on our DOM. However, we soon found that the memory thrash of using Lua's lightweight userdata to go back and forth between C++ and Lua resulted in poor performance on consoles, and I ultimately had to redesign the interface to be more WoW-like for our next release.

It was a shame, putting more onus on the scripter to manage objects (tables of properties in Lua) based on a 'pointer' passed around to uniquely identify each element in the DOM, and passing that pointer to all relevant functions. But the performance increase was dramatic.

Re:Raw- or OOP-base Lua? (4, Interesting)

Phrogz (43803) | about 2 years ago | (#38891911)

BTW, my personal opinion on Lua:

It's a fun language to learn, because at the core it is *so* simple. In less than a week a good scripter can fully wrap their head around everything that Lua has to offer from the scripting side (not the C++ side; that might be another week). It's rather elegant, really, with convenient syntax for integer-based for-loops that automatically create a new copy of the loop variable on each pass for simple closure creation.

However, when you get down to actually typing in itwell, it's not as verbose as Java, but there's some real RSI danger there. With it's simple core come decisions like "not only will we not give you foo++, we won't even give you foo+=1". Try typing things like "frameCounter = frameCounter + 1" many times and you'll start to scream. Every day I scripted in Lua at work I would long for the times when I could use Ruby to actually get something done.

For those who know JavaScript and want to get a glimpse of what Lua is like, I have a page on my site: Learning Lua from JavaScript [phrogz.net] .

Re:Raw- or OOP-base Lua? (1)

speps (1108625) | about 2 years ago | (#38892531)

After integrating Ruby into the SciTE editor, I can say that Ruby's biggest drawback is it's complete lack (at least when I tried it, maybe not now with another VM) of simple C embedding like Lua does. It was pain to embed but it worked somehow, it was not as clean as SciTE's Lua integration though.

Re:Raw- or OOP-base Lua? (1, Interesting)

Anonymous Coward | about 2 years ago | (#38892643)

And the previous two posts, just for starters, is exactly why Python continues to be so populuar. Well that and the fact that Ruby works hard to be the anti-culture programmer's language. Which means its unlikely to ever be more than an obscure language.

Re:Raw- or OOP-base Lua? (-1)

Anonymous Coward | about 2 years ago | (#38893859)

Hopefully it will be posted and moderated without troll moderation. I guess some people really hate python or blindly love ruby without knowledge to evaluate the truth of the statement which follows; which was incorrectly troll moderated.

And the previous two posts, just for starters, is exactly why Python continues to be so populuar. Well that and the fact that Ruby works hard to be the anti-culture programmer's language. Which means its unlikely to ever be more than an obscure language.

Wish moderators would learn to do their job correctly. There was absolutely nothing in that quote which deserves to be moderated down. If anything it should be moderated up once or twice. Its all true and factually accurate. And in fact, Ruby's inception grew out of a anti-establiment, anti-python, anti-lua core crowd. If the truth offends you, learn to grow rather than censor and hide the truth from people. The fact remains, in many ways ruby wants to python. That's not to say ruby does have some cool features which have garnered interest from python programmers, but the fact remains ruby is extremely likely to remain in the shadow of python and lua for many years to come; if not always.

People can't wait to moderate down and censor the truth just because it offends their personal opinion. Slashdot is so lame these days.

Re:Raw- or OOP-base Lua? (-1)

Anonymous Coward | about 2 years ago | (#38895011)

The troll moderator are especially active today.

Sure wish the moderators would do their job. They are literally useless anymore. Slashdot IS lame these days.

And the previous two posts, just for starters, is exactly why Python continues to be so populuar. Well that and the fact that Ruby works hard to be the anti-culture programmer's language. Which means its unlikely to ever be more than an obscure language.

Too true!

Why are Ruby lovers so concerned about censoring the truth? All Everything that's been stated and censored above has been more or less admitted on the record by core Ruby developers. Why does the truth upset Ruby developers so much? Oh ya, they're too busy be'ing anti-culture hipsters and bother with the truth.

Slashdot is soo borked and the moderators are useless. Why is it so hard for moderators to follow VERY simple instructions any more? Damn they ARE useless.

Re:Raw- or OOP-base Lua? (1)

lahvak (69490) | about 2 years ago | (#38892605)

If that is really a problem, why don't you make an editor shortcut that will automatically expand frameCounter++ to frameCounter = frameCounter + 1? Who still types out every little piece of repetitive code these days?

Re:Raw- or OOP-base Lua? (1)

mwvdlee (775178) | about 2 years ago | (#38893435)

Lua is supposed to be embedded and extended with domain-specific functions.
If you're developing RSI while using Lua, you're probably trying to do too much inside the Lua script that should be done in the application code.

Re:Raw- or OOP-base Lua? (2)

Darinbob (1142669) | about 2 years ago | (#38894661)

Look at how it's implemented though. Lua is small and efficient. Ruby looks like a committee has been working on it, and Python is even bulkier. That's why you see Lua in embedded systems so much more than other interpreted languages. It doesn't get in the way of the application like say Tcl does. Yes it comes with very little in the way of "standard library" which is also a benefit in many ways. I've seen some extremely elegant OOP systems for Lua that are short and do what is needed and no more, while simultaneously others re-created their favorite OOP style and end up writing more code to do that than their application code itself. Lua works because it keeps it simple.

Re:Raw- or OOP-base Lua? (1)

shutdown -p now (807394) | about 2 years ago | (#38894823)

One thing about Lua is that its source code is also small and clean and easy to work with. So it's trivial to change things that you don't like, or add small things that seem to be missing.

Re:Raw- or OOP-base Lua? (3, Insightful)

pnot (96038) | about 2 years ago | (#38895305)

However, when you get down to actually typing in itwell, it's not as verbose as Java, but there's some real RSI danger there. With it's simple core come decisions like "not only will we not give you foo++, we won't even give you foo+=1". Try typing things like "frameCounter = frameCounter + 1" many times and you'll start to scream.

Which, for me, immediately raises the question "Are there any good Lua IDEs?". I mainly code in Java, and it's true that it can often read like the Book of Deuteronomy -- but fortunately I don't have to type all that shit out, because NetBeans autocompletes a lot of it for me. Is there anything similar for Lua?

Re:Raw- or OOP-base Lua? (2)

Short Circuit (52384) | about 2 years ago | (#38891971)

I hope they're going with a PHP extension, and not implementing LUA in PHP. I'd rather have the execution happen in C code than PHP, for execution speed reasons, and I imagine their server operators feel similarly. (Though there's the obvious counterpoint that you're adding a new chunk of less-tested code that has fewer barriers to cross to exploit some vulnerability...)

In any case, I can't say I'm upset at the change--I'm actually a bit giddy. MW templates are a royal PITA.

Re:Raw- or OOP-base Lua? (1)

Anrego (830717) | about 2 years ago | (#38892421)

To be honest, while that would be great for wikipedia itself, for users of wikimedia, having to install a PHP add-on would be a nightmare (especialyl those with shared hosting).

Re:Raw- or OOP-base Lua? (1)

Short Circuit (52384) | about 2 years ago | (#38892831)

To an extent. Shared hosting providers are a dime a dozen, though, so finding a different one is pretty easy. Then there's Wikia and a number of other wiki farms ranging from free to an equivalent to managed hosting. And migrating a MW site isn't all that difficult, and not necessarily even time-consuming; the software is very good about that kind of thing, including cases where you need to upgrade.

Server administration to add that kind of thing is easy, and where a shared hosting provider falls behind, migration to another won't be preventatively difficult for anyone who shouldn't have been using a wiki farm to begin with.

Of course, for people like me who have to run our own server to run MediaWiki on, it's almost a nonissue; typically just a package install to get what we need. And I've been running a reasonably popular MediaWiki install for five years, so things may appear simpler to me than to other people. Point is, administering a website requires a minimum of knowledge, even if that minimum of knowledge is being able to migrate to a different service provider. If they can't do that, they weren't going to get around to upgrading in the future place.

Re:Raw- or OOP-base Lua? (1)

Anrego (830717) | about 2 years ago | (#38893027)

True enough for people who run a website that mainly revolves around their wiki.

However, lots of people just throw a mediawiki install to supplement the rest of their site, usually precisely because it's dead simple to get running and works on just about any host. Moving to another host just to preserve their little 10 page wiki is probably not sensible, and the content is probably in-appropriate for external wiki hosts (or isn't desirable for other reasons).

Obviously for people with their own server (or in my case, a VPS) this is a non-issue .. but I figure there are probably enough people for which this would be an issue that I can't see them not at least providing a PHP only implementation as an option.

Re:Raw- or OOP-base Lua? (1)

Short Circuit (52384) | about 2 years ago | (#38893355)

Those users will be able to stay on their pre-LUA version of MW for a major release or two (upstream doe security and bugfix releases for a while), which should give their vendor time to upgrade, if necessary.

And, yes, I'm sure someone will come up with a MediaWiki extension to implement Lua in pure PHP, and patches will probably be accepted to allow selection of Lua providers in LocalSettings.php. Of course, the reverse is also plausible; upstream might choose to use a pure-PHP solution, and the existing PECL extension might be tied in via a subsequent MediaWiki extension.

Re:Raw- or OOP-base Lua? (1)

HarvardAce (771954) | about 2 years ago | (#38893593)

True enough for people who run a website that mainly revolves around their wiki.

However, lots of people just throw a mediawiki install to supplement the rest of their site, usually precisely because it's dead simple to get running and works on just about any host. Moving to another host just to preserve their little 10 page wiki is probably not sensible, and the content is probably in-appropriate for external wiki hosts (or isn't desirable for other reasons).

Obviously for people with their own server (or in my case, a VPS) this is a non-issue .. but I figure there are probably enough people for which this would be an issue that I can't see them not at least providing a PHP only implementation as an option.

In your simple case, is there any reason to upgrade to a version of MW that implements LUA for templates, especially if it means an incompatibility with your current provider?

Re:Raw- or OOP-base Lua? (1)

gnapster (1401889) | about 2 years ago | (#38894869)

I think that bug fixes and security patches might be one reason, but maybe they will be backported.

Re:Raw- or OOP-base Lua? (4, Informative)

nahdude812 (88157) | about 2 years ago | (#38893283)

There is a LUA PHP PECL extension: http://pecl.php.net/package/lua [php.net]

It's relatively new, but this kind of attention could really skyrocket the extension forward. It's a great idea at large, there are a variety of situations where you want to defer decisions to your customer. Historically that meant creating a kind of pseudo DSL with a bunch of forms to fill out for the customer, with hopefully most major options covered, but usually failing to satisfy a variety of corner cases.

Another alternative is the V8JS extension (JavaScript). The advantage of JS is that more people know it already, and in may ways, JS is surprisingly elegant (not that Lua isn't). It won't perform as well as LUA though, and requires more resources to maintain the VM.

Re:Raw- or OOP-base Lua? (1)

Short Circuit (52384) | about 2 years ago | (#38893399)

yeah, I saw that; I googled for it before finishing my original comment. :)

Re:Raw- or OOP-base Lua? (1)

bonch (38532) | about 2 years ago | (#38892671)

I thought a light userdata was a pointer. I know one technique is to use a full userdata to represent a pointer and use the metatable capability of full userdata to register C functions as methods that interact with the properties of the real object.

Re:Raw- or OOP-base Lua? (1)

David Gerard (12369) | about 2 years ago | (#38894119)

They'll probably end up writing brainfuck in it, like they did with the existing ParserFunctions language.

Yay! (-1)

Anonymous Coward | about 2 years ago | (#38891963)

I can't wait to make edits using this new language, only to have them reverted minutes later.

Seriously though, I'm sure it'll make it a lot easier for an admin to sculpt the page in their own vision without interference from others.

Re:Yay! (2)

Trepidity (597) | about 2 years ago | (#38892039)

You don't generally need to be an administrator to edit the scripts, with the exception of a few scripts that are used on so many pages that they're vandalism magnets. And even for those, you can propose changes on the talk page, which are usually made if they're reasonable. There is not really a whole lot of politicking around the content of scripts, although admittedly that's partly because the home-rolled language sucks so much that very few people care to figure out how to edit pages that look more like line-noise than classic Perl did.

There's sometimes politicking about whether a particular one should exist or be used at all; some people find the proliferation of infoboxes, footer boxes, succession boxes, portal boxes, etc. too much clutter and not very useful. But the internals, afaik, aren't one of the hotbeds of debate.

StringTemplate is designed for this (1)

GodfatherofSoul (174979) | about 2 years ago | (#38892071)

The author specifically modeled it on MVP to maintaining a strict separation of concerns. Presentation and model don't co-mingle. Might seem a bit unusual at first since the language will seem limited at first. But, it'll keep you from running into the "bloating script" problem.

Not a language problem (3, Insightful)

zarlino (985890) | about 2 years ago | (#38892145)

Wikipedia could stick to PHP or switch to any other language. But that's not their problem. Their problem is the messy markup language they slowly created. I know cause once I tried to render their markup inside another app. Basically, they have all sorts of tags that reference obscure server-side behaviour and everything is so entangled that creating a new renderer is basically impossible. This is sad because they are wasting the work of volunteers.

Re:Not a language problem (2)

JDG1980 (2438906) | about 2 years ago | (#38893969)

This actually is a serious problem that has been discussed on the Wikipedia development and foundation mailing lists. Because Wikicode is not rigorously defined like real HTML/XML, the only definition of correct output is "whatever the current parser generates." This not only makes it nearly impossible to independently implement Wikicode in other products besides MediaWiki, but it also makes it far more difficult to create a WYSIWYG editor that doesn't break things. And doing the latter has been a goal of many people high up in Wikipedia for some time.

Re:Not a language problem (3, Informative)

David Gerard (12369) | about 2 years ago | (#38894195)

That's the precise problem. 1. the language was never designed, it accreted, and is mathematlcally impossible to describe fully in most sensible formats. 2. we can't throw it away because there's billions of words of text in it accumulated over ten years. 3. we can't throw it away because the existing editor base demand it stay because they're used to it.

So WMF is (a) throwing money as well as brilliance at the problem, and (b) has put Brion Vibber onto sorting out what is to be removed from wikitext, because he's one of two people (Tim Starling the other) that people will accept the opinion of on this matter. All proceeds well :-)

So now the problems are with seriously complicated things like doing bidirectional text [mediawiki.org] properly - a hard requirement for an international project, and one that is not done quite properly by anyone else. Something where mere dev brilliance has half a chance :-)

Éééééééé.. (-1)

Anonymous Coward | about 2 years ago | (#38892271)

...do BRASIIIIIIIIIIIL ~ Galvão Bueno

Lua is Great for Configuration (4, Interesting)

alexbirk (2565251) | about 2 years ago | (#38892385)

Embedding Lua for configuration or building templates is it's real strength. I've used it many times in programs that require pretty extensive configuration and it's a joy in that environment. I think it's a great choice for this.

Re:Lua is Great for Configuration (0)

Anonymous Coward | about 2 years ago | (#38894443)

But will I still be able to have a clique of editors to revert edits of newbies?

It's called "the inner-platform anti-pattern" (1)

Anonymous Coward | about 2 years ago | (#38892619)

Wiki syntax did always strike me as stunningly stupid. It has essentially become just another markup language. Except that it's much more unclear, shitty and limited than original XML. Which is a textbook example of the inner-platform anti-pattern.

Another horrible example is TypoScript. Which is a template language, written in another template language (PHP)!! Again becoming a shitty clone of PHP. Which itself already is a shitty clone of a proper scripting language. (I've had to use it in my day job, every day, for five years. I know. [And yes, I still keep up-to-date. And if anything, with the new tacked-on over-blown object system it has only gotten worse.])

XHTML already IS a n00b markup language that your grandma can use.
PHP already IS a n00b template language that every "web designer" (read: wannabe amateur) can use.

And for that purpose, they are perfectly fine!

Re:It's called "the inner-platform anti-pattern" (2)

Lennie (16154) | about 2 years ago | (#38892867)

As I understand it:

MediaWiki is written in PHP and they wanted to create a sandbox for the templates scripts, so they choose to use Lua as a PHP extension.

Because Lua is very suitable for embedding, as that is what it's general purpose in life is.

There is no PHP in a sandboxing inside PHP as far as I'm aware of.

Re:It's called "the inner-platform anti-pattern" (0)

Anonymous Coward | about 2 years ago | (#38894045)

Sorry, but any time I read a post whose main point seems to be that "real" programmers use PHP only under duress, I stop paying attention. I'm going to go out on a limb and guess you're a Ruby developer?

I'm not really interested (-1, Offtopic)

kthreadd (1558445) | about 2 years ago | (#38892629)

I stopped editing Wikipedia many years ago and I have no intention to ever have anything to do with them again.

Re:I'm not really interested (0)

Anonymous Coward | about 2 years ago | (#38892895)

1) Then why bother even reading the article?
2) Wikipedia is a visible site seen by a great number of people, so it's still relevant.
3) The engine that WP uses, MediaWiki, is used by other wikis besides Wikipedia, some of them even actively anti-Wikipedia.

Re:I'm not really interested (0)

Anonymous Coward | about 2 years ago | (#38892949)

Cool story, bro.

Re:I'm not really interested (1)

sourcerror (1718066) | about 2 years ago | (#38892979)

Sorry, your comment is NPOV. I marked it for speedy deletion. Also see WP:Shit_that_no_one_cares_about
-- SparklyRainbowLetters

As opposed to a Wordpress style engine? (4, Insightful)

PortHaven (242123) | about 2 years ago | (#38892863)

Seriously, Wikipedia's #1 fault and the reason I ceased actively contributing is that it requires humans to use a mark-up language for what is essentially a simple text based document.

And all such edits would be handled much easier via a WYSWIG editor. Yes, elitist monkeys with far too much time on their hands love that feel of doing something complicated for the sake of it.

Those more intelligent and or beings who have furthered the race through reproduction tend not to want to waste time.

Implement a simple editor that facilitates editing. And let computers do what they do best, process. And humans do what they do best collate ideas and knowledge.

First rule of computers. Don't waste time doing what a computer can do better than you.

Re:As opposed to a Wordpress style engine? (1)

TheSunborn (68004) | about 2 years ago | (#38893173)

Implementing a "Simple editor" which allows the user to use all of wikipedias features is not a simple task. It is a very very very tough task, for the same reason that making a general html editor is very difficult. There is a reason that so much html/css is still written "by hand" and it is not because we like it.

Re:As opposed to a Wordpress style engine? (1)

lahvak (69490) | about 2 years ago | (#38893607)

And all such edits would be handled much easier via a WYSWIG editor.

YMMV, but I find that editing structured documents is much faster using plain text, than a WYSIWYG editor. That is if the mark up language is not idiotically verbose, like XML.

Don't waste time doing what a computer can do better than you.

Exactly! Why should I waste time formatting the document, when the computer will easily do it for me. I just type what I want to say, and let the computer place it on the screen.

Re:As opposed to a Wordpress style engine? (0)

Maury Markowitz (452832) | about 2 years ago | (#38895663)

" I find that editing structured documents is much faster using plain text, than a WYSIWYG editor"

I assume you mean something like HTML or such. But I also suspect this does not apply to something like a word processor document, where you likely use Word or something similar?

Wikipedia documents are supposed to be word processor documents. Unfortunately, they've been implemented in code. *THAT* is the problem here.

And as one of the Wiki's more prolific authors, I state this from more than a little experience. I currently do my editing offline in Smultron, but I would kill for a GUI editor that let me drag references around, to start with.

Here's what I imagine

I start a new document. It opens a window on the left with a sidebar on the right.
I start my research, finding references and images I want to use. I drop them in the sidebar.
I start writing. I drag items from the sidebar into the document where I want it.
When I save, it asks me to format the sidebar info, adding things that it can't get from the URL (say the publisher for a book).

That would save me hours a document. Right now I use a lash-up in Smultron which is far from ideal.

Re:As opposed to a Wordpress style engine? (2)

Hatta (162192) | about 2 years ago | (#38896667)

I assume you mean something like HTML or such. But I also suspect this does not apply to something like a word processor document, where you likely use Word or something similar?

He's talking about LaTeX. It's both a word processor document AND code. And it's better than Word in every way except the steepness of the learning curve.

Re:As opposed to a Wordpress style engine? (1)

bananaquackmoo (1204116) | about 2 years ago | (#38894973)

Huh? You're comparing apples to oranges here. Editing the content in a wiki entry has nothing to do with this Slashdot article.

Yay lua (2)

Osgeld (1900440) | about 2 years ago | (#38893081)

the only language that would use more words to describe the article than what's in the article

Another use of Lua (1)

madison_hotel (2466834) | about 2 years ago | (#38894075)

The nmap guys seem to have considered a few scripting languages too for a while, and stuck to Lua because of a couple of reasons addressed in this [nmap.org] conference (and probably in some other place in the NSE docs). While I know nothing of the people behind the scenes of Wikipedia, I do kind of trust the decisions made by the nmap team, so my guess is it's not a clueless decision.

LuaTeX (0)

Anonymous Coward | about 2 years ago | (#38894129)

Knowing nothing about Lua(La)TeX, I wonder if this could be helpful in any way. Perhaps, at least in *TeX -> HTML conversion?

The reason (1)

Tei (520358) | about 2 years ago | (#38894147)

I don't have the bookmark here, but I followed the discussion ( I am on that mail list, and I am a huge fan of javascript ) is that with Lua, is possible to have "quotas". You can limit what LUA do in cpu and ram useage, while a javascript vm maybe will end stressing the server. This was the ultimate motive. This and that some features we easy to implement (where already implemented in the discussion). I think this mean that Javascript must add these things, and make easy for "language embeders" to control how much memory javascript take. I don't know how feasible is that.

Why procedural? (0)

Anonymous Coward | about 2 years ago | (#38894547)

Is there any reason why a templating language shouldn't be declarative? I can think of one reason: they were looking for something to translate their old spaghetti code into. If that's it, they're doing it wrong.

Lua is fine, but has some small problems (1)

roguegramma (982660) | about 2 years ago | (#38894747)

For example, the lua table object is used by the standard library (table functions [lua.org] ) to represent C arrays with integer indexes or more accurately C++ vectors. However, in general you should not attempt to use the resulting table object in any other way than provided for by the table functions. It would have been more user-friendly to have an own vector type for this.

Although it isn't a problem most of the time, sometimes you want to preserve the order in an associative array with non-numerical indexes like you are used to for example in PHP. As far as I know this can only be achieved by having a second table defining the order.

I really like using "or" to express default initialization anywhere though, this will assign "die" if funny is null (or false):
function be(funny)
funny = funny or "die" ..
end

Re:Lua is fine, but has some small problems (0)

Anonymous Coward | about 2 years ago | (#38896331)

IIRC, Lua seems to generate large nests. Something about break (last) and continue (next) not being present.

standard picked at the wrong level of abstraction (1)

PJ6 (1151747) | about 2 years ago | (#38895093)

User-generated anything (code, data, content, etc) is best supported when you allow many modes of expression, and freedom to change without a standards committee getting in the way.

On the other hand, machines require a fixed standard, or something that changes relatively infrequently.

For this reason, I think the choice of any scripting language here is as ill-conceived as the web itself being standardized on HTML/JavaScript.

Wrong problem (0)

Maury Markowitz (452832) | about 2 years ago | (#38895443)

Gebus, we're spending developer cycles on THIS?

How about the ability to drag an URL into the body of an article to automatically create a reference?

Which is more important?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?