From: Nicolas Neuss on
ccc31807 <cartercc(a)gmail.com> writes:

> On Feb 26, 3:41�pm, Tamas K Papp <tkp...(a)gmail.com> wrote:
>
> [...]
>> For me, the most important point is how Perl rewards quick & dirty
>> solutions, but this is more costly in the long run and encourages bad
>> habits. �Again, you may disagree with this, but dismissing the
>> article as meaningless, unreasoned and incoherent is, in my opinion,
>> unjustified.

Reading Erik's post one has to keep in mind that he 1. was a fan of
shock therapy, 2. tried to provoke flames by formulating somewhat too
sharp. I can understand that his post is no nice read for Perl lovers,
although it has quite some truth in it.

> [...]
> Naggum: it's not that perl programmers are idiots, it's that the
> language rewards idiotic behavior in a way that no other language or
> tool has ever done, and on top of it, it punishes conscientiousness
> and quality craftsmanship
>
> Me: This is a proposition, not a statement of fact, and it's supported
> by no statement of facts. I'd certainly be interested in the evidence
> Naggum relies on in reaching this conclusion.
>
> [...]
>
> Naggum: here's a simple rule to use on perl programmers. if a
> solution is clean and complete, it will immediately look like a
> tremendous amount of work to a perl programmer, which it will:
>
> Me: Processing a file using a regular expression (a method much loved
> by Perlers) is absolutely clean and neat, although it may look like
> cussin' to the uninitiated. I've had non-programmers look at my code
> and ask, 'What's the cussing?' pointing to a regular expression. When
> I explain it to them, they have been truly impressed that so much can
> be packed into a single line.

Let me give an example in precisely this direction: I once have worked
together with others on a C application solving PDEs. This application
left a large trace of rather unstructured output about what it was
doing, how it solved the problem etc. Several of my colleagues used
Perl to go through this unstructured output and filter out the tiny bit
of information that was important to them. Note that they were
completely in control of the application and could have easily
instructed it to write out only the necessary information in a clean way
(as I did BTW). However, having Perl at hand it deemed them to be
easier to parse the full output (sometimes in the >100MB range) for the
information. This is simply the Sapir-Whorf hypotheses: the tool forms
the thinking and in this case in the direction of an extremely bloated
and unprecise interface.

Nicolas
From: Tim Bradshaw on
On 2010-02-27 01:09:01 +0000, ccc31807 said:

>
>> [1]http://www.jwz.org/doc/worse-is-better.html
>
> This is totally new to me, so it will take some time to digest, maybe
> even several years. I'm not hostile to Gabriel's argument, just
> unfamiliar with it.

I think this is the important point in this thread: there is an
enormous amount of context you're missing, which makes Erik's article
look very weird to you, and makes it look much less weird to people who
have that context. Even Erik's opening:

"the unemployed programmer had a problem. �"I know", said the
programmer, "I'll just learn perl." �the unemployed programmer now had
two problems."

Is derived from an earlier quote: "Some people, when confronted with a
problem, think 'I know, I'll use regular expressions.' ��Now they have
two problems." This quote is often attributed to JWZ, and in this form
it is, I think, his, but I suspect it in fact derives from yet earlier
quotes along the same lines.

Erik's article is a mass of implicit references to all this shared history.

I don't think it reflects badly on you that you are missing the context
to make sense of all this - the world is too big for everyone to have
experienced all of it. But what he says does make more sense if you
know the context.

As an aside: I think Erik is wrong, in fact, and there are plenty of
good uses of string-munging languages and Perl. And (going back to the
context) Unix is, in fact, not the horrible botch that it was seen to
be by the ITS/LispM people. I do think there are significant *dangers*
to things like Perl and regexps: they can suck you in until they are
all you can see, and then you're in quite serious trouble. It's a bit
like stimulants: we all drink coffee, but if you start relying on it or
other stimulants you are probably in some trouble.

But these kind of nuanced views have no place in a good flame war of course.


From: Tim Bradshaw on
On 2010-02-27 03:30:46 +0000, Rob Warnock said:

> As I've said before [most recently in Aug'09], the one thing that
> made Perl's "line noise" *much* more comprehensible to me was the
> realization[1] that Perl's "typeglobs" are really a lot like CL symbols,
> except with more slots, and using readmacros as accessors instead
> of functions:

I must have missed your previous posting, but this is a really good
point. To take it to some ridiculous extreme: Perl is, in fact, almost
Common Lisp, it's just got peculiar clothes on so you don't recognise
it.

From: ccc31807 on
On Feb 27, 7:10 am, Tim Bradshaw <t...(a)tfeb.org> wrote:
> I think this is the important point in this thread: there is an
> enormous amount of context you're missing, which makes Erik's article
> look very weird to you, and makes it look much less weird to people who
> have that context.  

Right. However, context can become so ingrained that it becomes a
shorthand to convey complex thoughts, and if we lose sight of the
'longcut' we run the danger of making the shortcut a stand in for the
complex ideas. The map is not the territory.

> But these kind of nuanced views have no place in a good flame war of course.

True as well. But don't forget that good flame wars also serve the
purpose of sharpening our reasoning and honing our logic, and
sometimes, even showing us where we are wrong and the other fellow is
right.

CC.
From: Giovanni Gigante on

> I thank you _so much_ for your "mini HOWTO post"! I have been looking for
> that very thing off-and-on these past 2 weeks. I suppose that I didn't look
> in the right place.


I am just a, let's say, "experienced beginner" in Lisp matters, so I
understand the problem.

I have been thinking for a while if some kind of "Common Lisp Beginner's
FAQ" would be useful (I had even begun to write a draft, some time ago).
Something not on the lines of the CL cookbook, but more basic. Like,
what are the relevant pieces of the toolkit (not of the language) and
what are they for.

While all the information is certainly available elsewhere, maybe the
"youngs" -as Pascal call them- might benefit from having certain things
collected in an easily digestible format.

g