[
Lists Home |
Date Index |
Thread Index
]
As you say, much of this is now OT, and I think we're both clearly in positions that are unlikely to be resolved in XML-DEV, but a bit of clarification...
> > 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 ?
There are CPython, Jython, Python.NET, Stackless Python, Vyper, Rattlesnake, and many others. To be honest, only the first four are not experimental, and there are very good reasons for each of them.
My point is that a thriving language has a thriving culture, and the sort of culture that spawns multiple implementations (usually a guru task) often reveals that the underlying language has much in to to attract good developers.
> > 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?
Probably reading too much Ezra Pound:
"""
Damn it all! all this our South stinks peace.
You whoreson dog, Papiols, come! Let's to music!
I have no life save when the swords clash.
But ah! when I see the standards gold, vair, purple, opposing
And the broad fields beneath them turn crimson,
Then howls my heart nigh mad with rejoicing.
"""
> 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?
Good. That makes two of us. Of course, whoever was trying to use objective measures for languages is likely just another straw man lurking around, avoiding your wrath.
;-)
> > > 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.
Oh come now, Paul. Play Everyman all you want, but I know very well from correspondence that you are one of the elite that would be spared by the CompSci Inquisition. I personally don't mind being boldly labeled a menshevik if it would mean I have to maintain much less bad code.
> 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.
Again, I think you're picking the wrong argument. First of all, I don't say at all that you can only pick up good comp sci in one of the fleshpots of science. Many great programmers have learned their craft through a sort of apprenticeship: learning algorithm and software engineering practice for eminently practical reasons. Also, many who go through all the silly classes can't code their way past the Logo turtle.
I, for one, had little time for class while in ENgineering school. I was too busi pursuing practical programming, in part as a paid consultant writing code for income.
I program for food as well, but you won't catch me whingeing that the task at hand (manipulating trees) is not amenable to the BASIC approach to programming.
Programming is a profession. It requires no less study and practice than, say, art restoration or Midwifery.
I suspect that if you were to need any medical attention, you would not go see an amateur who thinks that the finer points of Physiology are for Scientists.
> > > 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.
Threads are far too heavyweight to be of use. If they had not been clumsily bolted on to most OSes, most programming languages would probably have acquired good microthread engines by now, and all our code would be running much more quickly.
> > O yeah. BTW, how often do *you* use bi-directional pipes?
>
> In some sense, I use them every day, when browsing the internet.
Hmm. A very remote sense, I must say.
> ( And BTW - XSLT is limiting, because it has only side-effect-free
> pipe, but no support for bi-directional pipe ;-)
Funny, I hadn't notice this as a limitation. I won't even attempt with the proof, but I am quite confident that as long as pipes can be cleanly composed, any task that requires bi-directional pipes can be easily transformed to one using only uni-directional pipes.
> 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.
Wow. Waiting for an ideal framework? Who's playing scientist now?
I am quite happy to deal with "good enough for the task at hand", and the nice thing about XSLT is that there are many XSLT frameworks that are just that, two of which you name?
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management
|
