--- Comment #17 from Happy-melon <> 2011-01-04 16:42:53 UTC 
(In reply to comment #16)
> I have to agree with Aryeh,  there was a pipe-dram about Lua. Now that's dead
> this needs escalating. 

Escalation is the word, certainly... :P

> We currently have a situation where templates can stop working for mysterious
> reasons.  We have simple stuff ten-year-old children used to hack on pocket
> money computers 30 years ago, that professional software engineers are 
> sweating
> blood to achieve (or not).

Allowing this functionality is not going to make templates stop breaking.  If
anything, the fear is that it will develop to the point where when they break,
they do so in *even more mysterious* ways.

> Current situation:
> o Frustrated template writers
> o Inefficient (horrendously inefficient) code
> o Missing functionality
> o Reduced productivity
> Requested situation
> o Happy template writers
> o Fast code
> o buckets of functionality
> o Huge leaps in productivity
> What's not to like?

The fact that there is no reason to doubt that this utopia will in fact turn
into a dystopia where _frustrated template writers_ are using these string
functions to simulate the _missing functionality_ of regular expressions with
_horrendously inefficient_ code built on str_sub().  All historical precedent
suggests that this is what *will* happen, because those template writers are
happiest and most productive when they are pushing the envelope of what is
possible.  I don't want to look at [[Template:preg_replace]] in three years'
time and see something which makes today's string templates look like Hello
World functions.  I *especially* don't want to see spaghetti bowls of parser
function tags which are rendered even more incomprehensible by mystic
{{{{{safesubst|}}}foo:...|safesubst={{{safesubst|}}}}} constructs. 

The objection to StringFunctions is *not*, in general, that the functionality
should not be available.  It's that we don't want the next generation of
functionality to look like the previous generation of functionality, because
that is not a good look.  Cf
for how [[Template:Navbox]] could look in python, for instance.  Programming
languages are designed to be extensible, to retain a similar level of *visual*
complexity regardless of the *computational* complexity.  ParserFunctions etc,
are definitely *not* designed in that fashion.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

Wikibugs-l mailing list

Reply via email to