[32799] in Perl-Users-Digest
Perl-Users Digest, Issue: 4063 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Oct 24 16:09:28 2013
Date: Thu, 24 Oct 2013 13:09:02 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 24 Oct 2013 Volume: 11 Number: 4063
Today's topics:
Re: Replacement for CGI.pm <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 24 Oct 2013 17:23:14 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Replacement for CGI.pm
Message-Id: <87bo2ehc3x.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> >
>> > TT2 allows all those things, with the advantage of not being Turing-
>> > complete. This may seem like a disadvantage, but it actually makes your
>> > code much cleaner if you keep the business logic out of the templates
>> > and allow them to concentrate on presentation.
>>
>> It actually makes my code much cleaner when I can use a more powerful
>> programming language to build domain-specific abstractions for output
>> generation instead of being restricted to the 'generic, interpolated tag
>> soup' model, IOW, HTML-generation is a complex task in its own right
>
> I have to disagree there. It really isn't that complicated to generate
> the HTML once you've got as far as a data structure suitable for
> display,
I wrote 'complex' and not 'complicated' and did so for a reason: That
would mean a broadly-defined 'general task' (ie "generate the HTML")
which is really composed of a set of similar-but-different subtasks
which can further be divided into sub-subtasks and so on, with a
sufficient amount of repetition at each level that 'abstraction' is both
possible and sensible and a sufficient amount of variance that "copy and
paste" ....
> and the sort of abstraction which is helpful is better provided
> by a slightly-souped-up macro language than by a full programming
> language.
... or programmed "copy and paste" aka macro expansion (using some toy
language) are not really sufficient to solve to problem in a technically
sensible and reasonably easy-to-use way. I don't know of you ever came
across that,
http://thewml.org
qbut that's something I used to use in the past for 'more complicated
stuff' and I have - at one point or another, often within a single
project - actually made use of most features provided by it, and the
ability to 'write a program to write programs' wasn't the least used one
--- the WML macro processor seems more powerful to me than the 'TT' one
(based on looking at the documentation) and I have encountered
situations where it wasn't powerful enough. Also, textual substitution
is a PITA compared to real subroutines once things get 'interesting',
ie, at higher nesting levels.
[Random corollary: It is said that the purpose of Perl would be to make
the simple things easy and the complicated ones possible. Expanding on
that, the purpose of a 'web framework' would be to make the simple
things complicated and relegate the complicated ones to the realm of
fable.]
[...]
>> and using some kind of 'Logo for HTML-Editor-Jet-Pilots' instead just
>> restricts the options available to me for doing that. There's an "It
>> could be done, hence, it will be done" assumption in your statement
>> which is really a non-sequitur: Options don't chose themselves (I'm also
>> firmly convinced that the idea to stop people from making bad choices by
>> preventing them from making any choices is very misguided: If someone
>> thinks $opinion is really the Right Thing To Do[tm], the sensible
>> approach is to try to educate others to help them see the error in their
>> ways, not to force them to pay as little lip service to the superior
>> approach as they're capable of getting away with grudgingly).
>
> As usual, you are accusing me of trying to restrict others' choices,
> when in fact I am simply explaining the reasons for my own.
You wrote
,----
| TT2 allows all those things, with the advantage of not being Turing-
| complete. This may seem like a disadvantage, but it actually makes your
| code much cleaner if you keep the business logic out of the templates
| and allow them to concentrate on presentation.
`----
As it stands, this makes little sense. Because of this, I have chosen to
interpet it as something like "*If* the language used for
HTML-generation is sufficiently complete and easy to use that it can be
used for 'real programming', the end result will likely be
run-of-the-mill PHP-code and this is something one should rather
avoid". I agree with that latter, however, I disagree with the idea that
one would be a 'natural' effect of the other and with the more general
notion that the best way to prevent abuse of features is to remove or
omit them.
If you don't think anyone but you could possibly consider using PHP,
feel free to buy any kind of straight jacket keeping you from it :-).
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4063
***************************************
