The Daily WTF: Curious Perversions in Information Technology

2008-03-18 Reply Admin

NeoMojo:
Dave:
tdittmar:
snoofle:
You FOOLS!
This person is obviously prepared for the day when they add another letter to our 26 character alphabet - better safe than sorry!
Or maybe they just knew that the US alphabet isn't the only one around - what about ä, ö, ü and ß in the German alphabet? Or all the other letters in all the other alphabets that are non-english?

WTF is a "US alphabet"?

The English alphabet, but written bigger and spoken more slowly.

The basic modern Latin alphabet,

2008-03-18 Reply Admin

decet:
NeoMojo:
Dave:
tdittmar:
snoofle:
You FOOLS!
This person is obviously prepared for the day when they add another letter to our 26 character alphabet - better safe than sorry!
Or maybe they just knew that the US alphabet isn't the only one around - what about ä, ö, ü and ß in the German alphabet? Or all the other letters in all the other alphabets that are non-english?

WTF is a "US alphabet"?

The English alphabet, but written bigger and spoken more slowly.
The basic modern Latin alphabet,

Now that's what I call a slow sentence. It must be using the US alphabet.

2008-03-18 Reply Admin

php5:

foreach (str_split(file_get_contents('alphabet.txt')) as $letter)
	printf('%1$s', $letter);

in any sane programming language

0. create a file containing all the letters in the alphabet
1. open the file for reading
2. read all characters from the file to a array
3. close the file
4. loop over the array and output the html using the current character

would still take less than 10 lines of code

2008-03-18 Reply Admin

c∞l:
You mean: future pr∞f.

G∞d one c∞l. See what I mean people? How you gona do that without the XSLT solution?

2008-03-18 Reply Admin

sholden:
Maybe Anon:
Scott:
'A'.upto 'Z' do |letter| puts '' + letter + '' end
Better?
It is a lot better, but now I don't see why it would have an advantage on another language/
I like it that the code looks pretty damn clean and reads like a sentence.

A up to Z do pipe letter pipe. Puts stuff plus letter plus stuff plus letter plus stuff end.

Yup, just like a sentence ;^)

2008-03-18 Reply Admin

Jay:
To say that it's a good solution if the author was constrainted by company policy ...

I for one am not claiming it's a good solution, just that it isn't necessarily bad code. As this has been submitted as a WTF code snippet, the company policy is relevant - if we are going to discuss this in context (I know, shocking concept) the code should be the WTF, not the idea. As it happens, comments from thewtf's xslt specialists suggest that not only is the idea bad, the implementation also has some problems. I'm happy to bow to their superior knowledge of XSLT!

tdittmar · 2008-03-18 Reply Admin

Jens:
Dave:
WTF is a "US alphabet"?
A shortcut for saying that these problems mostly arise with US-made software where people think that iterating over _A_SCII codes will give you a list of the alphabet.

Thank you! I was about to write something like this.

To all the other guys: You may continue to ask about the "US alphabet" - or you may turn on your brains, get over it and admit that you knew perfectly well what I was talking about in the first place.

BTW, I liked the "spoken more slowly"-comment ;-)

2008-03-18 Reply Admin

it's enterprise level

2008-03-18 Reply Admin

PrepositionJoe:
This is the first time I've ever felt compelled to comment.
The XSLT isn't great XSLT, but what you're missing is ... it's XSLT.

Seriously, that's what it's like. It's not like the languages you're used to. It doesn't work the same way. If you need to iterate through the letters A to Z, creating an XML file containing them as nodes is perfectly logical. If the only tool you had to do the job is XSLT (1.0), this is (roughly) what you'd get.

So, it boils down to you all saying "the real WTF is the entire XML/XSLT platform". Which you're entitled to do. But ... that's not what this site is for, is it?

Yeah, I agree. XSLT should include some easy way to do things like iterating through the alphabet. However, XSLT's support for variables is counterintuitive and .... weird. I wish it had real support for variables, but without that, you get WTFs like this.

brazzy · 2008-03-18 Reply Admin

[quote user="decet"][quote user="NeoMojo"][quote user="Dave"][quote user="tdittmar"] WTF is a "US alphabet"?[/quote]

The English alphabet, but written bigger and spoken more slowly.[/quote] The basic modern Latin alphabet, [/quote] You mean the one that's sufficient for exactly three living languages (English, Swahili, and Hawaiian)?

brazzy · 2008-03-18 Reply Admin

Alonzo Meatman:
However, I'll hit you with this hypothetical - what if they were using a compiled language like C# or Java?

Read what I wrote about that - there's no problem except in the minds of people who've missed at least 20 years of development in software engineering.

Furthermore, what if this code was deployed for, say, 12 different sites? And what if these 12 different sites all used different stylesheets and formatting? Furthermore, what if the company wanted the style/formatting to be changeable by someone who wasn't a programmer, i.e. a graphics designer?
In that case, hardcoding the details for the tag would in itself be a WTF. This is one of the great uses of XSL - it allows you to change presentation-level details without requiring you to change your code.

XSLT is code, period (at least when it uses loops and variables like this example). Anyone who can understand and change it could also change a well-written and isolated implementation in Perl, Ruby, Python, C# or Java, and would probably have a much easier time doing it. Heck, if it used some sort of template, you actually COULD change the presentation level without messing with code (unlike the XSLT version).

Few other things are responsible for more unmaintainable coding horrors than the irrational fear of hardcoding things and the superstition that by transforming program logic from a form that's well-suited to programming (Perl, Ruby, Python, C# or Java...) to something that's NOT well-suited to programming (XSLT, a "business rule engine", some homegrown format, ...) it somehow magically becomes maintainable, understandable to non-programmers, doesn't need to be tested and causes no problems in deployment and configuration management

XSLT is a good tool for transforming XML documents, but if the transformations are more complex than renaming and shuffling tags and sttributes around, or if you wouldn't even have to start out with an XML document if you weren't using XSLT, there are better alternatives.

2008-03-18 Reply Admin

[quote user="brazzy"][quote user="decet"][quote user="NeoMojo"][quote user="Dave"][quote user="tdittmar"] WTF is a "US alphabet"?[/quote]

The English alphabet, but written bigger and spoken more slowly.[/quote] The basic modern Latin alphabet, [/quote] You mean the one that's sufficient for exactly three living languages (English, Swahili, and Hawaiian)?[/quote]

Says the fiancé who writes his résumé... (Do a sort by ASCII codes with that.)

A Nonny Mouse · 2008-03-18 Reply Admin

I don't know if anyone has mentioned this as i can't be arsed to read through all the comments, but XSLT is not supposed to know about ASCII etc - it is a pure transform language and used for displaying data

Whatever application produced the (presumably dynamic) XML should have included a list of the possible nodes.

Not a WTF, sorry.

2008-03-18 Reply Admin

brazzy:
Alonzo Meatman:
However, I'll hit you with this hypothetical - what if they were using a compiled language like C# or Java?
Read what I wrote about that - there's no problem except in the minds of people who've missed at least 20 years of development in software engineering.
Furthermore, what if this code was deployed for, say, 12 different sites? And what if these 12 different sites all used different stylesheets and formatting? Furthermore, what if the company wanted the style/formatting to be changeable by someone who wasn't a programmer, i.e. a graphics designer?
In that case, hardcoding the details for the tag would in itself be a WTF. This is one of the great uses of XSL - it allows you to change presentation-level details without requiring you to change your code.

XSLT is code, period (at least when it uses loops and variables like this example). Anyone who can understand and change it could also change a well-written and isolated implementation in Perl, Ruby, Python, C# or Java, and would probably have a much easier time doing it. Heck, if it used some sort of template, you actually COULD change the presentation level without messing with code (unlike the XSLT version).

Few other things are responsible for more unmaintainable coding horrors than the irrational fear of hardcoding things and the superstition that by transforming program logic from a form that's well-suited to programming (Perl, Ruby, Python, C# or Java...) to something that's NOT well-suited to programming (XSLT, a "business rule engine", some homegrown format, ...) it somehow magically becomes maintainable, understandable to non-programmers, doesn't need to be tested and causes no problems in deployment and configuration management

XSLT is a good tool for transforming XML documents, but if the transformations are more complex than renaming and shuffling tags and sttributes around, or if you wouldn't even have to start out with an XML document if you weren't using XSLT, there are better alternatives.

Once again, you miss my point - or evade it, I don't really know which.

The key here is this - say that the number of sites running the software is variable. This means that possibly 100 sites could be running the software. Do you really feel that it's a good idea to hardcode the styling information for 100 sites? If so, then I respectfully disagree. I think there's a good chance that such a project would turn into its own WTF.

My guess is that you've spent a lot of time with scripting languages where people pop in and change the source all the time. Besides, I actually think it's a good idea to take presentation-level details (like styling info) out of the compiled code.

Even if you do have a programmer (and not a designer) updating the XSL, it's still a lot more manageable to do it that way then to compile and distribute a new binary every time you want to tweak the design for one of the client sites.

2008-03-18 Reply Admin

There's really only one thing to say: Brillant!

brazzy · 2008-03-18 Reply Admin

Alonzo Meatman:
The key here is this - say that the number of sites running the software is variable. This means that possibly 100 sites could be running the software. Do you really feel that it's a good idea to hardcode the styling information for 100 sites? If so, then I respectfully disagree. I think there's a good chance that such a project would turn into its own WTF.

Once again, you miss my point - or evade it, I don't really know which.

The concept of "hardcoding", that anything configurable must not be "in code" in order to have a maintainable system, is a misleading simplification. Either the parts where changes need to be made are well-separated from the rest of the system and can be changed easily, or they're not. Whether they're in something generally considered a programming language or not does not matter one bit. The WTF here is a perfect example: the XSLT is actually a mix of logic and presentation, and less maintainable than if it were written in a "real" programming language.

Besides, I actually think it's a good idea to take presentation-level details (like styling info) out of the compiled code.

I think it's a good idea to separate them from program logic. Which CAN be done in compiled code. And it was NOT done in the XSLT in question.

The best solution would probably be one that uses code to loop over the characters and a template of some sort to output the links.

Even if you do have a programmer (and not a designer) updating the XSL, it's still a lot more manageable to do it that way then to compile and distribute a new binary every time you want to tweak the design for one of the client sites.

Not if you have a decent build and deployment process.

2008-03-18 Reply Admin

Ok, so what happens when you add a new client site? Tweak the executable again, and redeploy?

And once again, I return to my example of CSS class names. I'd rather leave it to the designer how they want to structure their CSS. I'd rather not hardcode this information.

Besides, I think that XSL is a good language for managing presentation-level details and generating HTML. I'd rather generate my HTML in something that resembles HTML than in a compiled language.

2008-03-18 Reply Admin

s.:
Essentially:
setObscureValue(getDifferentValue($index));

The line above didn't work. OTOH:

$temp = getDifferentValue($index); setObscureValue($temp);

did. "Likely, setObscureValue takes a reference, not a value, and it doesn't like reference to a call to a function." we guessed.

Except that neither call gives it a reference, which would look something like:

setObscureValue \getDifferentValue $index

The extra thing the fixed code gives you is a lvalue, so that setObscureValue can change its parameters. I'd want to know why setObscureValue would do something like that before I call it, too.

2008-03-19 Reply Admin

Genius

Cos it's a seperate XML file, you can use it across multiple platforms and applications!

Code reuse = good

2008-03-19 Reply Admin

Bozo:
Genius
Cos it's a seperate XML file, you can use it across multiple platforms and applications!

Code reuse = good

Please use the recently introduced 27th letter of the English alphabet 'double o' written ∞. C∞l and I have adopted it, and it's about time everyone else did (I mean it's been out a couple of days now). I'll let you off this time, Bozo, but it really should have been written

'Code reuse = g∞d' ;-)

2008-03-19 Reply Admin

brazzy:

Even if you do have a programmer (and not a designer) updating the XSL, it's still a lot more manageable to do it that way then to compile and distribute a new binary every time you want to tweak the design for one of the client sites.
Not if you have a decent build and deployment process.

Code changes, rebuilding and deploy because data changes? We are coming close to WTF comments peak...

2008-03-19 Reply Admin

ASCII: American Standard Code for Information Interchange

brazzy · 2008-03-19 Reply Admin

Jens:
brazzy:

Even if you do have a programmer (and not a designer) updating the XSL, it's still a lot more manageable to do it that way then to compile and distribute a new binary every time you want to tweak the design for one of the client sites.
Not if you have a decent build and deployment process.
Code changes, rebuilding and deploy because data changes? We are coming close to WTF comments peak...

Yes, if you still fail to understand that XSLT, especially the kind shown here, is code and not data, that's indeed a WTF. I suggest a basic CS course.

2008-03-19 Reply Admin

[quote user="brazzy"] Code changes, rebuilding and deploy because data changes? We are coming close to WTF comments peak...[/quote] Yes, if you still fail to understand that XSLT, especially the kind shown here, is code and not data, that's indeed a WTF. I suggest a basic CS course.[/quote]

Er... sorry, re-read the article and the discussion, please, and you will see your mistake.

real_aardvark · 2008-03-19 Reply Admin

Miles Thompson:
Yeah. Way less cumbersome than recursion when "for i<26: asc(i)" is not even in consideration.
And for that we shouldn't blame our intrepid programmer, rather we should blame the insane bastard child of XML -- XSLT - the root of many a programming evil.

Internet conversations end when somebody mentions Hitler.

Language flames half-terminate when somebody mentions recursion.

The OP is silly enough without bringing recursion into it. I'm sure there's a really, really good way of using XSLT to recurse over the alphabet (in upper case, btw, in case nobody noticed), but I'd have to say that it might, just, be a good and compelling reason not to use XSLT to tackle the problem.

And I'd love to see a recursive XSLT solution, generalised to i18n.

Wait ... no. My eyes bleed only on Saint's days.

2008-03-20 Reply Admin

"...we guessed" You guessed while he found the reason, which happened to prove you guessed right.

2008-03-20 Reply Admin

$sAlpha = 'a b c d e f g h i j k l m n o p q r s t u v w x y z'; $aAlpha = explode(' ', $sAlpha); foreach($aAlpha as $sLetter){ echo ''.$sLetter.' '; }

BACON · 2008-03-23 Reply Admin

John:
c∞l:
You mean: future pr∞f.
G∞d one c∞l. See what I mean people? How you gona do that without the XSLT solution?

You mean: G∞d (∞ ÷ 2)ne c∞l.

2008-03-31 Reply Admin

IV:
I see several comments about adding letters, but no one seems to have considered the opposite possibility. What about removing letters? C is adaquetely covered by K and S. Q can be covered by C (K) and KW. We can bring the number of letters down to 24 without much work. Of course,...

Or perhaps this.

A Plan for the Improvement of English Spelling by Mark Twain

For example, in Year 1 that useless letter "c" would be dropped to be replased either by "k" or "s", and likewise "x" would no longer be part of the alphabet. The only kase in which "c" would be retained would be the "ch" formation, which will be dealt with later. Year 2 might reform "w" spelling, so that "which" and "one" would take the same konsonant, wile Year 3 might well abolish "y" replasing it with "i" and Iear 4 might fiks the "g/j" anomali wonse and for all.

Jenerally, then, the improvement would kontinue iear bai iear with Iear 5 doing awai with useless double konsonants, and Iears 6-12 or so modifaiing vowlz and the rimeining voist and unvoist konsonants. Bai Iear 15 or sou, it wud fainali bi posibl tu meik ius ov thi ridandant letez "c", "y" and "x" -- bai now jast a memori in the maindz of ould doderez -- to riplais "ch", "sh", and "th" rispektivli.

Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld.

2008-04-14 Reply Admin

Ben:

print join(' | ', map { qq|$_| } ('A'..'Z"))

:D

Yuck!

And wrong too (it outputs '|' that wasn't in the Ruby code and I don't think in the original. And there's a syntax error there as well.)

Much better written as

print qq|$_| for ('A'..'Z');

Taking i18n into account is left as an exercise for the reader, but probably uses split //, slurp $file;

Or as a WTF on its own (completely untested, but you get the idea), use the current locale to determine the valid alphabet.

print qq|$_| for grep /\w/, map chr, (0..2**31);

:-)

M4

2008-05-02 Reply Admin

brazzy:
Alonzo Meatman:
The key here is this - say that the number of sites running the software is variable. This means that possibly 100 sites could be running the software. Do you really feel that it's a good idea to hardcode the styling information for 100 sites? If so, then I respectfully disagree. I think there's a good chance that such a project would turn into its own WTF.
Once again, you miss my point - or evade it, I don't really know which.
The concept of "hardcoding", that anything configurable must not be "in code" in order to have a maintainable system, is a misleading simplification. Either the parts where changes need to be made are well-separated from the rest of the system and can be changed easily, or they're not. Whether they're in something generally considered a programming language or not does not matter one bit. The WTF here is a perfect example: the XSLT is actually a mix of logic and presentation, and less maintainable than if it were written in a "real" programming language.

Besides, I actually think it's a good idea to take presentation-level details (like styling info) out of the compiled code.
I think it's a good idea to separate them from program logic. Which CAN be done in compiled code. And it was NOT done in the XSLT in question.
The best solution would probably be one that uses code to loop over the characters and a template of some sort to output the links.

Even if you do have a programmer (and not a designer) updating the XSL, it's still a lot more manageable to do it that way then to compile and distribute a new binary every time you want to tweak the design for one of the client sites.
Not if you have a decent build and deployment process.

Hmm, decent Build and deployment process, you mean, like having one xsl file that you change once and the entire 100 sites change.

2009-04-29 Reply Admin

"Yes, that's all much simpler than three line for loop."

OK, let's see you implement all that in some other language using a three line for loop.

The for loop in the code you showed is short... an opening and a closing tag. The rest of the code does things beyond merely outputting a letter... E.g. it pattern-matches a second parsed XML document to find out whether there are any staff whose surname begins with each letter, to avoid unnecessary links. All that found_alpha jazz could have been done in one line:

<xsl:if test="document($staff)/staff/profile[starts-with(surname, $alpha)]">

The part you found verbose, the 28-line XML input document, could have been done in XSLT 1.0 in a few lines, using a variable

<xsl:variable name="alphabet" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'" />

and iterating over nodes in the XSLT document itself. But admittedly, that's awkward. Looping from 1 to 26 (or 'A' to 'Z') is awkward in XSLT 1.0. In XSLT 2.0 it's much easier.

Moreover, XSLT is designed for something more relevant for an XML transformation language than looping from 1 to 26: looping over your input data. This problem could have been solved not by looping over A to Z, but creating a key indexed by first letter of last name of staff, and looping over the key values... a very waste-free and straightforward solution that leverages XSLT's strengths instead of struggling through its weaknesses.

I can't tell from your article where the code came from. But it's not right to shoot the language just because somebody implemented a feature in a suboptimal way in that language. Every language has strengths and weaknesses.

2010-06-22 Reply Admin

Fredrik:
The US alphabet isn't ubiquitous, you know...

AAAAGGGGGHHHHH!!!!!

It's the ENGLISH alphabet. Not everything is made in America. You speak English (although probably badly).

The Alphabet... The Hard Way

Leave a comment on “The Alphabet... The Hard Way”