Prev: Download new programs and english courses
Next: A toy example of embedding C code in lisp and vice versa
From: Tim Bradshaw on 12 Jun 2010 14:12
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.

So, yes, Perl is better than Lisp, if you live in hell. 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.

There, I feel much better now.

From: Dan Weinreb on 12 Jun 2010 16:22
Perl is a domain-specific language for doing exactly that kind of
thing.

I've wondered sometimes about having a DSL within Lisp that would be
good at the things that Perl is most used for, such as what you're
talking about. It's not easy to do this well, though, so I've never
seriously tried.
From: Jason Riedy on 12 Jun 2010 16:35
And Tim Bradshaw writes:
> So, yes, Perl is better than Lisp, if you live in hell.

Perl *the language* matters less than CPAN. CPAN encapsulates so many
aspects of hell that you stop feeling the burn. It's kinda like fire
walkers.

Perhaps something like CPAN only can occur when you know the burn's
there.

Jason
From: Tim Bradshaw on 12 Jun 2010 17:34
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.

From: Scott L. Burson on 12 Jun 2010 17:45
On Jun 12, 11:12 am, Tim Bradshaw <t...(a)tfeb.org> wrote:
>
> 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..

I almost never have to do this kind of thing, and I don't know much
Perl, so if I needed to do it, I would consider my time better spent
learning to use CL-PPCRE than learning Perl. It would probably take
less time, too.

Just my $.02.

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