[Gllug] Website developement

[Nix]

On Mon, 16 Jul 2001, Alex Hudson stipulated:
> 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,

So I'm contradicting myself and have a memory like a sieve ;)

> Perl is higher level because it supports OO concepts.

Not only does Lisp (specifically Common Lisp) support OO, it does so in
a typically Lispish (i.e., wildly overblown) manner. Look up `CLOS' in
Google.

Far from Perl 5's half-hearted OO support (radically improved in Perl 6,
that's one thing everyone agreed on), CLOS is, well, quite the most
excessive OO system ever implemented. It supports everything every other
OO system does (inheritance, polymorphism, delegation, message-passing,
access control...) and then adds loads of weird and wonderful features
whose use is, er, at times at best debatable. This has the downside that
the system is hugely hard to learn...

... but if you *need* to override the method used to do method lookup
and resolution at runtime, CLOS will let you do it.

It's very intereting to compare with Java's approach, because they were
designed by the same people (and, in fact, so too was the Scheme Object
System, and Scheme and Common Lisp as a whole. Gosling, Steele & co are
quite prolific hackers. They were all mixed up in Emacs, too...)

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

I meant the C-written extensions. The `holes in the VM'.

I have nothing against subroutines, at all :)

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

A *seriously* flawed one, as far as I'm concerned. But then I'm a
Lisp-head and language theory purist, so I don't expect to ever see
eye-to-eye with lwall on this.

>> The `based on IBM machine code' line is an extreme misstatement. 
> 
> No. "A FORTRAN compiled list procesing language", Gelernter, Hansen &
> Gerberich (1960).

I've been idly looking for a copy of that. Where'd you find yours?

> 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

`Highly influential in the development of' does not mean `equals', or
C++ would be Simula, and have built-in and astonishingly slow garbage
collection (Stroustrup has an amusing rant about it at the start of
D&E).

I'll acknowledge that languages which were originally implemented on IBM
mainframes influenced Lisp --- given IBM's dominance it could hardly be
otherwise --- but that doesn't turn Lisp into some kind of modified IBM
machine code.

(Is C PDP-11 assembler?)

>                       but the concept of symbolic expression processing was
> made easier by the architecture.

Again, agreed. Still doesn't make Lisp `based on IBM machine code'. It's
rather more based on the lambda calculus :) (although rather less so
than some other functional languages, which are even less useful ;) ).

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

OK, then in that case Lisp is really high level. After all, it's built
principally on maths, and maths has been doing this sort of building for
*ages*.

(But `age implies high-level-ness' is self-evident nonsense. IA64
assembler is only three years old, but it's not high level. It's got
some stuff in it to help things that high-level languages might *like to
do*, like exception handling, but it is not high level.)

>      Bottom up - a basic principle of building that has stood man in good
> stead for thousands of years. 

I do my design top-down and bottom-up both :)

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

Personally, I prefer to read content, not flashy stuff. Perhaps others
are looking for a `multimedia experience' when they hit the web; I'm
looking for information.

>> 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 :)

Catalogues? Mailing list archives, on-line magazines... pages with
*text* on them. You know, the stuff the web was designed to help publish?

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

Nope, I'm just pointing out (and putting it badly ;) ) that inconsistent
presentation does not assist in making things readable, and consistent
presentation is best accomplished by separating content and
presentation; logical and physical markup.

Compare, for instance, the layout and typesetting of Wired with that of
a normal book. Which is easier to read?

(And if you say `Wired' I'll have to assume that you are not a human
being. I can't believe *anyone* can read that for longer than a few
minutes without their eyes watering.)

>> 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'm not sure what `complete' machine generation is supposed to be. I
have almost no presentational elements in the source text from which my
HTML is generated, no, but that doesn't mean I don't have style sheets,
or that I don't have markup in the HTML to say, for instance, `emphasize
this bit of text' (with, of course, <STRONG>). Of course I do. But I
keep the details of *how* to `emphasize' or `make a list' separate from
`make an indented list with first-line indent of 3em', say.

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