Prev: Anybody mind to translate this Felleisen quote from German to English
Next: Macros and anonymous functions
From: Nicolas Neuss on 27 Feb 2010 04:02 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 27 Feb 2010 07:10 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 27 Feb 2010 07:17 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 27 Feb 2010 08:30 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 27 Feb 2010 09:25
> 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 |