Prev: Download new programs and english courses
Next: A toy example of embedding C code in lisp and vice versa
From: Rainer Joswig on 12 Jun 2010 17:49
In article <hv0ugv$jv2$1(a)news.eternal-september.org>,
Tim Bradshaw <tfb(a)tfeb.org> wrote:

> On 2010-06-12 21:22:39 +0100, Dan Weinreb said:
>
> > Perl is a domain-specific language for doing exactly that kind of
> > thing.
>
> Yes. Perl is a domain-specific language, the domain it is specific to
> being hell. Though I think, if one finds oneself in hell, it is
> probably better to arrange not to be there. That can prove difficult,
> of course.

You've got a barf bag with your UNIX HATERS handbook.

Unfortunately it is not part of the electronic version:

http://simson.net/ref/ugh.pdf

--
http://lispm.dyndns.org/
From: Kenneth Tilton on 12 Jun 2010 17:53
Tim Bradshaw wrote:
> Over the last couple of days, I've been gathering information from a
> number of machines about the number, types, and speeds of processors
> they have (so someone coud work out licensing costs). All of these
> machines were made by the same vendor (it does not matter which, they
> are all equally bad), who produced the OS and HW. So, obviously, there
> will be some nice way to ask the questions you need to ask - questions
> like what are the canonical names of the processors in the machine, how
> many are there, how fast are they running, how many cores do they have
> and so on. It's all slightly complicated because the processors in a
> single OS instance don't have to be all the same speed and so on. But
> this is all basically trivial, right?
>
> If only it was. The way things are reported depends, at least, on the
> OS version, patch level, platform, firmware version of the platform, and
> apparently also on the state of the tide when the system was last
> rebooted. There just is no escape from the fact that a program to
> gather this sort of information is going to have to (after dispatching
> on all the parameters it can think of) do a bunch of pattern-matching on
> the output of various commands to work out what particular bit of
> braindamage this system is afflicted with. Regular expressions are, in
> fact, the right way to do this, because *there is no higher-level
> structure there*: it's just appalling gloop.
>
> And, like it or not, Perl is the king, queen and crown prince of this
> kind of grovelling in the mud. You could do it in Lisp, but why would
> you? Perl is just the least painful thing you can use to get this done.
>
> But the clue is in the last sentence: Perl is the least painful way of
> getting this done, but it is going to be painful and unpleasant, in the
> same way walking on broken glass while neck-deep in sewage is painful
> and unpleasant.

Get a grip. The buoyancy from the sewage would reduce the effect of the
glass below detectability.

kt

ps. Your wysiwyg TeX editor is on the way, now that your goalie has
ham-handed* us a draw.

* We are still trying to work out how striking a ball with both hands in
one direction can accelerate it in the opposite. A Nobel Prize is not
out of the question.


--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
From: Tim Bradshaw on 12 Jun 2010 19:15
On 2010-06-12 22:49:48 +0100, Rainer Joswig said:

> You've got a barf bag with your UNIX HATERS handbook.

Yes, but the problem isn't really Unix, which I like in fact: it's idiocy.

From: Rob Warnock on 12 Jun 2010 23:03
Tim Bradshaw <tfb(a)tfeb.org> wrote:
+---------------
| Over the last couple of days, I've been gathering information from a
| number of machines about the number, types, and speeds of processors
| they have (so someone coud work out licensing costs). ...
+---------------

Cue Charlie Stross and the horrid licensing & "best practices"
issues that Bob Howard has to deal with in his IT day job at The
Laundry [as detailed in "The Atrocity Archives", "The Concrete
Jungle", The Jennifer Morgue", etc.]. You have my most profound
sympathies... :-{ :-{

+---------------
| ... There just is no escape from the fact that a program to gather
| this sort of information is going to have to (after dispatching
| on all the parameters it can think of) do a bunch of pattern-matching
| on the output of various commands to work out what particular bit of
| braindamage this system is afflicted with. Regular expressions are, in
| fact, the right way to do this, because *there is no higher-level
| structure there*: it's just appalling gloop.
+---------------

Though if one *were* to use CL for it, SEARCH & MISMATCH would be your
friends. [And to a lesser extent, (FIND ... :TEST #'SEARCH) & POSITION-IF.]

+---------------
| And, like it or not, Perl is the king, queen and crown prince of this
| kind of grovelling in the mud. You could do it in Lisp, but why would you?
| Perl is just the least painful thing you can use to get this done.
+---------------

If -- and it's a *very* big "if" -- you're one of those fortunate enough
to be able to keep the syntax of Perl in your head long enough to write
your initial mudball in the first place! I, on the other hand, am one of
the allicted who live right on the borderline: I can write useful amounts
of Perl if one of my hands is glued at all times to the thick version of
the Perl Reference "Card" [actually a booklet of some several dozen pages!].

But let a few days or weeks pass before the resulting mudball needs a minor
modification [and useful mudballs *always* need modification, often major,
sooner or later!] and I have to start all over figuring out what it is was
that I wrote in the first place!! **ARRRRGGGGHHHHH!!**

So even though I cheerfully admit that it's *not* anywhere near as concise
as Perl, I choose instead to write such dumpster-diving, sewer-wallowing,
muck-grovelling code in Common Lisp, both for the fact that I find that I'm
relatively[1] more sane when done [and can sleep at might without feeling
unclean!] *and* that I have *NO* trouble whatsoever reading and/or modifying
it days/weeks/months/years/decades later!!

+---------------
| But the clue is in the last sentence: Perl is the least painful way of
| getting this done, but it is going to be painful and unpleasant, in the
| same way walking on broken glass while neck-deep in sewage is painful
| and unpleasant.
+---------------

[1] Which is why I said "*relatively* more sane when done" above. As you
so vividly illustrated, the problem domain itself is a kind of hell,
and even Dante was a bit wilted around the edges once he escaped, ne?

+---------------
| So, yes, Perl is better than Lisp, if you live in hell.
+---------------

IMHO, to think so is a trap. Just because one is forced (hopefully
temporarily) to reside in Hell, that's no reason to heap further
suffering upon oneself [what Buddhists call "the pain of pain"].
Make, instead, the closest approximation you can to Heaven, be it
but one JND (or, for the crude, one RCH) better.

+---------------
| Unfortunately, for reasons that escape me at the moment, we do seem to
| be good at constructing really quite accurate approximations to hell.
| Still, it would clearly be preferable to live somewhere else.
+---------------

Reality stubbornly persists in being messier than even our most
convoluted idealizations of it. And sadly, Sir, we have yet to
demonstrate that one can live for very long in unreality...


-Rob

-----
Rob Warnock <rpw3(a)rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

From: Tim Bradshaw on 13 Jun 2010 06:08
On 2010-06-13 04:03:39 +0100, Rob Warnock said:

> Though if one *were* to use CL for it, SEARCH & MISMATCH would be your
> friends. [And to a lesser extent, (FIND ... :TEST #'SEARCH) & POSITION-IF.]

The trouble is that they would not. What you'd have to do is to write
a hacky pattern-matching languages which would compile down to a huge
number of calls toe the primitives CL gives you. After some years you
might have got to something which has all the bells and whistles of
Perl's regexp language.

> If -- and it's a *very* big "if" -- you're one of those fortunate enough
> to be able to keep the syntax of Perl in your head long enough to write
> your initial mudball in the first place! I, on the other hand, am one of
> the allicted who live right on the borderline: I can write useful amounts
> of Perl if one of my hands is glued at all times to the thick version of
> the Perl Reference "Card" [actually a booklet of some several dozen pages!].

The point is that you really only need a tiny part of the syntax of the
language. The programs I write to do this sort of thing typically
include loops over input lines, basic if/then/else conditionals, file
I/O and opening pipes, hash tables and arrays, and function definition.
And a huge amount of regular expressions.

That was really my point: in hell, programs are structurally simple,
because in hell there is no structured data. So languages which help
you deal with complicated structures (either of control or data) do not
help you much in hell ...

> IMHO, to think so is a trap. Just because one is forced (hopefully
> temporarily) to reside in Hell, that's no reason to heap further
> suffering upon oneself [what Buddhists call "the pain of pain"].
> Make, instead, the closest approximation you can to Heaven, be it
> but one JND (or, for the crude, one RCH) better.

.... and in fact, I think that they may hurt you. My claim is that, in
hell, Perl is actually the least painful option.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Download new programs and english courses
Next: A toy example of embedding C code in lisp and vice versa