::realizes this may be going a bit futher a field ... but tries to maintain topicality::
> Chris writes: >> Perl handels Regex's better than C, this is one of the reasons people >> use Perl. > > I disagree. Perl's Regex processor is written in C. The difference is > that it has outgrown Henry Spencer's regexp library. Mmm semantic differences I yield the floor seneator, but I wish it to go on the record that Regex's are built into the main syntax of the Perl language, and are fully supported by the culture. While you must specifically link to and consiously add in Regex's in C. You can build a Hash, Queue and Stack in C as well, but that doesn't mean that they aren't generally simpler to use in Perl because they're built right into the language. >> It makes (some) hard things easy and (some) impossible things >> hard ... within it's domain. XSLT is no different. Use the appropriate >> tool (or Toolkit) for the problem. > > Agreed. Perl is good at text manipulation. It is imiho superior to > XSLT in all spaces which XSLT claims to solve. Once you have an XML > parse tree in Perl, it's trivial to write a translator to any format > more correctly than XSLT. My favorite example is XML to CSV. Every > example I've seen in XSLT is cumbersome and wrong. You'd think it > wouldn't be hard, but try it. ;-) Well XSLT wasn't really designed (and shouldn't have been) to output plain text. Despite what the W3C says. It's designed to tranlsate between XML Vocabularies. I'll explain in a bit why I feel that XSLT is better suited for this than Perl. >> existance beyond the Towers of Hanoi problem. But I haven't seen it >> solved in TeX either (::know's there's gotta be a link for this::). > > I'm sure Randall wrote a TeX to TT translator to generate his TT > version of ToH. ;-) Merlyn any comments here? Other Powers-That-Be? I could see this as a JAPH ... only for size N problems it would take N^2 years to print. >> Rob, is what you are suggesting that one should not use a turing >> complete language for visual markup or that simply the language >> should be the best match for the solution? I'm just looking for >> clarity on your position. > > The question really surrounds "little languages". Perl is ideally > suited to creating them. There's no reason to invent a new syntax ([% > %]) or semantics for standard structures. I think you should write > classes in Perl that map to some interface which defines the language. This is where I think we have a disagreement. In usability circles there is an idea that different things should be ... well ... different. If one button turns on the radio ... it shouldn't look anything like the button that launches the missles. This is why I find XSLT well suited for XML->XML transformations because it is visually/ideologically well suited to it's primary domain. If I'm dealing with the angle brackets and the tree structure ... then I'm thinking about the angle brackets and the tree structure ... eventually I'm zenning in the whole Angle Brackety Tree Structury-ness of the world. (I have a degree in english I know exactly how awful that sentance was.) It may be true that Perl can do it quicker and faster ... but for me the advantage to visually distinguishing the logically different parts helps future maintainability. C and Perl are distinctly different because the domains they are best suited (and designed) for are distinctly different. Nobody wishes Perl's syntax were more like that of C, Java, or Cobol. If they do they should probably be writing C, Java or Cobol. (Inline::Cobol anyone?) In MVC if each letter were written in it's own language it would be very easy to maintain the seperation. If it's generally impractical to use three distinct languages* one should keep as much visual distinction between the three as possible. *Generally people already do use three langauges though with the Template Language (HTML|ASP|TT|XSLT), the Controller Language (Perl) and the Model Language (SQL). > It's pretty much gotten to the point where nobody gets fired for > choosing Java. I've lost many contract bids because I didn't say Java > was the right solution. I haven't lost a single customer who let us > solve the problem for them. People don't approach a contractor and tell them what tools to build a house with. Why do they insist on doing it with programmers? -Chris -- "[A] Genuinely skillful use of obscenities is uniformly absent on the Internet." -Karl Kleinpaste
