[Gllug] Website developement

Nix nix at esperi.demon.co.uk
Sun Jul 15 18:55:12 UTC 2001


On Sun, 15 Jul 2001, Alex Hudson uttered the following:
> On 15 Jul 2001, Nix wrote:
>> > Perl is higher level than both C and Java, probably also Lisp
>> 
>> That you say this indicates either that you do not know anything about
>> Lisp, or, perhaps, that you don't know what the phrase `higher level'
>> means :(
> 
> Obviously. Go on, tell me why the oldest high-level language in existence,
> the one based on IBM machine code, is higher level than Perl...

The difference is minor, because Perl has stolen lots of stuff from Lisp
(`map' and `apply' for instance). However, Perl with no extensions is of
*minimal* use outside of its problem domain; this is not true of
Lisp. (Of course, this might indicate that Perl is terribly high level;
most terribly high level languages are bloody useless outside of their
original problem domain.)

Perl's lack of orthogonality reduces the number of things you can do
with it without writing extensions. Of course, with extensions, you can
do anything; but without them you haven't got a very wide choice of
problem domains at all :(

The `based on IBM machine code' line is an extreme misstatement. The
names of two functions were derived from an ancient IBM mainframe; that
doesn't mean that anything else was. And you can easily use `head' and
`tail' instead of `cdr' and `car' if you want to.


And if you think age automatically implies poor design, may I recommend
killing yourself at once? After all, you're based on four billion year
old code; you *must* be dysfunctional.

Lisp has stood up *very* well to the passing years, far better than any
other language I can think of. It has changed a bit, acquiring strings
and `let' and things, but most of its changes are (like `let') syntactic
sugar. The core remains the same, because it hasn't needed to change.

You can't say the same for Perl. (Mainly because, up until the Perl 6
redesign, Perl was never designed, it just accreted, which paid the
expected toll on readability, consistency, orthogonality, and much
else. And, no, I think lwall's claim that orthogonality is unimportant
in the Camel book is so much poorly-thought-out crap --- and so, it
seems, does lwall, these days. Certainly Perl 6 is shaping up to be
*way* more orthogonal than Perl 5 ever was.)

>> > first is separate presentation from content, which is where templates (et
>> 
>> This is, of course, the only sane way.
> 
> Sane for who? It's _easy_, perhaps, but leads to crap web pages :P

For values of `crap' equal to `readable on any device, automatically
adapting to changes in browser capabilities'. i.e., `good'.

>> > but gives the best results.
>> 
>> ... that is, it can look nice on totally broken browsers like Netscape 4
>> and IE3, but can't change its appearance to compensate for variations in
>> browser capability, is very hard to do, and is generally a Bad Idea.
> 
> No, not quite. Separating your presentation from your content doesn't
> magically lead to good HTML, and vice versa.

Straw man. It doesn't *magically* lead to anything, no, but mixing the
two up will not help your HTML's readability in any way, nor its
maintainability, nor its browser-independence.

>> Everything I produce is designed properly. I can't see the point in
>> going through endless agony to compensate for browsers with no style
>> sheet support; they get a really plain look and have to live with it.
> 
> That wasn't the point I was making :) Complete separation of content from
> presentation leads to dull, repetitive websites,

It leads to websites where you can see the *content*, rather than having
the alleged `design' getting in the way.

>             Information is the context lent to data (at least partially),
> and people use presentation to draw attention to different bits of data to
> be informative.

Really? It's *very* rare that I find people able to do that
properly. Normally, presentation is used to *distract* people from
potentially embarrassing bits of data, or is just splashed on to show
how k00l the webpage author is --- which leads to webpages that only
work on a subset of the set of browsers...

>                 I'm not saying that's impossible with templates, but it's
> a lot harder - either you need to have a lot of very similar information
> (like a directory, shop, etc.) or you need a lot of specialised
> templates.

This is a rather different point (I was railing against HTML
presentational elements, you're arguing against machine-generation), but
For a site larger than microscopic, using raw HTML is, IMHO, a bad
idea. All sites have some repeated elements, and if you put them in by
hand you'll make mistakes.

I assemble my sites with the aid of a mess of M4; others use other
methods. Whichever method is used, it leads to more consistency than
doing it all by hand would do.

-- 
`I'm not sure whether libtool is an existence proof that you _can_
 write a shell script that handles its arguments correctly, or a
 demonstration that you may try but you are doomed to failure.'
                                                       -- Zack Weinberg


-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list