[Gllug] Website developement

Alex Hudson home at alexhudson.com
Sun Jul 15 23:04:28 UTC 2001


On Sun, Jul 15, 2001 at 07:55:12PM +0100, Nix wrote:
> > 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).

.. yet you say I obviously don't know the meaning of high level, when you
agree the point is subjective (as I did when I said 'probably')? For me,
Perl is higher level because it supports OO concepts. I don't see how that
opinion could lead to the conclusion that I don't know what HLLs are.

> However, Perl with no extensions is of minimal* use outside of its problem
> *domain;

By entensions, I presume you mean modules? These are not language extensions
- do you have something against subroutines?

> Perl's lack of orthogonality reduces the number of things you can do
> with it without writing extensions.

Perl's lack of orthogonality (apart from being a design feature) are because
of short-cuts, rather than holes of missing functionality - so while not
orthogonal, it is generally sufficient. Depending on what you call
'extensions' of course...

> The `based on IBM machine code' line is an extreme misstatement. 

No. "A FORTRAN compiled list procesing language", Gelernter, Hansen &
Gerberich (1960). This is where the XCARF (for example) function was
discussed and published - as part of an extension to FORTRAN for calculating
geometry theorems - and were designed for the IBM platform of the day.  This
was highly influential in the development of lisp. I'm not just talking
about function names, but the concept of symbolic expression processing was
made easier by the architecture.

> And if you think age automatically implies poor design

I didn't state that. I stated that it was unlikely to be higher level due to
it's being older. HLL were built on LLL, and ever higher levels are built on
top. Bottom up - a basic principle of building that has stood man in good
stead for thousands of years. 

> > 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'.

No, for values of crap equal to 'looks the same on every page you go to'.
Great if you're a machine, sucks if you're human and want something
interesting to read.


> >> ... 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. 

Straw man my hat. "Looks nice on broken browsers" infers bad HTML. 

> 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.

I didn't argue it did; hence I said content/presentation separation was
easier.. sigh. 

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

You stick to your catalogues then, I'll have my flash and javascript, and
we'll both be happy :)

> 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...

You're blaming the method for the errors of the author then? I'm sorry, but
doing things via templates etc. does not automatically lead one to good
taste. I can show you hundreds of templated sites with all the problems you
describe.

> This is a rather different point (I was railing against HTML
> presentational elements, you're arguing against machine-generation)

I'm not arguing against machine-generation as such; just complete machine
generation. It leads to cold, repetitive sites I find. But I think that is
the basic difference between us, yes.

> 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.

Exactly :) But I would rather have a site part good and part bad than
consistently mediocre :) That's what design is for :)

Cheers,

Alex.

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




More information about the GLLUG mailing list