[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Uche Ogbuji" <uche.ogbuji@fourthought.com>
> BTW, I am surprised if Perl really has only one implementation, and it
does make me wonder about it.
Well .. honestly it should be 2,5 ( if counting cygperl as an impementation)
and it is all broken ;-) But the codebase is ... the same...
> Python, for instance, has likely 20 or more.
Really? It could be that I don't understand something.
Do you call any build of Python an 'implementation' ?
How come there are 20 Python's our there?
I can think only about JPython... Or do Python
people like to re-invent the wheel, rewriting
the same interpreter over and over again?
Maybe they just like writing interpreters?
Some kind of fun ?
> Of course, if the "Parrot" initiative to share common run-time between
Perl, Python, etc. comes to life, I guess Perl might have as many
implementations. (And, yes, for those who missed it, Parrot *started* as an
April Fool's joke, but has turned into a very interesting collaboration
between the top Python and Perl developers, with some PHP folk pitching in.
Seems Eric S. Raymond played mediator to get things rolling.)
That would be fun to see that bytecode wheel re-invented
again. UCSD, Java, .Net and now Parrot, started as a joke.
If you have not read it yet, I would recommend reading the
book "Just For Fun" ( by L.Torvalds ) where he explains that
every thing in this world goes through three stages
1. Survival
2. Social
3. Fun
His point is that we are in a stage 3 with Software. Sometimes
I think - perhaps he *is* kidding? ( Nice book, really ).
> > > And speaking of extensibility, the well-considered features for
extending
> > XSLT are another key part of its success. The flourishing of projects
such
> > as EXSLT so soon after the advent of XSLT 1.0 is quite telling.
> >
> > Telling what? By this metrics - Perl is a clean winner over *any*
> > language, because CPAN is *huge*
>
> And Perl is much older than XSLT. I did make qualification by age, if you
noticed.
Is XSLT really *that* young? What about DSSSL? OK, OK. XSLT is young
and time will tell. How old is XSLT? 4 years old?
Perl had plenty of extensions when it was 4 years old. Even if
counting from perl4. ( Not from perl5 ).
> > So by one of your metrics Perl sucks, but by another metrics it is the
> > winner.
> > I think there should be something wrong with the metrics, that you use.
>
> Nah. Something's just wrong with your reasoning about my "metrics".
> You did manage to beat that straw man to a bloody pulp, though.
Well, what was that warrior man doing here, in our ... poetical...
XML-dev list?
I really don't understand how can anyone 'measure' languages
with the 'objective' metrics. I think there are no such. Is COBOL
the best language ever?
> > Agree. Pipe-based approach is 'good'. However, somehow,
> > most of computer users ( including developers ) have serious
> > problems, writing UNIX pipes. I'd say that the majority
> > of computer users prefers GUI / OO / event-driven world
> > to pipes-based world.
>
> I think we'd all be better off if there were far fewer and far better
programmers. Call me a snot, but IMHO A programmer who cannot understand
the basic divide-and-conquer algorithmic imperatives that are the foundation
of computer science, and that are properly enforced by functional
programming, should be quarantined from *any* computer language.
Ah, those scientists.
I'm sorry, but it is us, unwashed masses, who do the coding
for food and the only thing *we* want from the computer
language is that it will *let us do our job* ( which is coding
for food ). That's why weird multipass C compiler, but
not 'elegant' one-pass Pascal compiler. E t.c.
> > Some people belive that this is the issue of 'education'. I don't
> > think so. Time will tell.
> >
> > The interesting thing is that creators of UNIX have *changed*
> > the pipes in Plan 9 to make them ... bi-directional ! The
> > creators of 'side-effect-free' processing decided that it is
> > 'too limiting' and 'it should be fixed'.
>
> Yeah. And they also decided that the good old process, which God intended
as the fundamental unit of CPU scheduling, be primped up with the addition
of "lightweight" processes (AKA threads).
Well, both threads and fork make sense. Really. It is good
to have both. By the way - Linux has it's own view on this
issue. Their threads are processes. At least it was so for
a long time. God knows why.
> And OBTW, who says UNIX pioneers are the "creators" of side-effect-free
processing?
Well, my point is not that they were first, but my piont
was that they did created a very popular
de-facto side-effect-free processing model
( UNIX pipes ) not even understanding what
they actually do ( happens all the time from
my point of view) They've seen it as a
'limitation' right from the beginning ( that's
written on dmr webpage )
> > I was *really* surprised to hear that ... in private
> > correspondence with one of UNIX gods ... I think the
> > world is funny. Isn't it ?
> O yeah. BTW, how often do *you* use bi-directional pipes?
In some sense, I use them every day, when browsing the internet.
Looks similiar to threads vs fork - it is good to have both
side-effect-free and bi-directional pipes. Right?
That was not my original conclusion, but that's what I think now. ;-)
( And BTW - XSLT is limiting, because it has only side-effect-free
pipe, but no support for bi-directional pipe ;-)
> > > Anyway, as an XSLT implementor and developer, I have often had cause
to
> > curse the XSL WG (decimal-format/format-number, and the lack of dynamic
> > programming features being leading causes), but I'm mostly vehement
because
> > of how good the product is overall.
> >
> > Good for *what*.
>
> For my purposes, which mostly involve developing forms-based apps and
document-based process dispatch systems.
>
> I have a pretty diverse background in programming languages and systems
and I am often surprised at how rapidly and effectively I can develop
Web-based systems using XSLT.
As to myself, I found that for a simple pages, XSLT is more convinient,
than plain CGI, but PSP + Chunks ( or AxKit + XPathScript ) is more
convinient, than XSLT. For complex pages with forms - nothing beats
PHP or Perl with Text::Template.
I have not seen an ideal framework yet and if you can recommend
some XSLT-based framework other, than 4Suite ( and not Cocoon )
I would be glad to investigate it, because I learn slowly and it could be
that I'm missing something obvious with XSLT.
Also, maybe it's just me. I have a crazy path switching
between Python and Perl. I tried Python several times until
I 'got it'. Now I really can not tell what language is 'better'
(or worse)! Sometimes I even can not make my mind what
language to use! Life should be very easy for those, who
prefer Perl to Python or vice versa. ;-)
Rgds.Paul.
PS. I'm sorry - there is too much offtopic in my letter,
so now I disappear. It was nice hearing from you,
brave XSLT straw man. ;-)
All the best.
|
