From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <4FDD3B61-CA0D-446E-A05B-204B4866D755@fastmail.fm> References: <455f59971ace96897640df2bff497ce3@kw.quanstro.net> <4FDD3B61-CA0D-446E-A05B-204B4866D755@fastmail.fm> From: Jorden M Date: Tue, 4 May 2010 11:38:35 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] du and find Topicbox-Message-UUID: 19daf974-ead6-11e9-9d60-3106f5b1d025 On Tue, May 4, 2010 at 6:01 AM, Ethan Grammatikidis w= rote: > > On 3 May 2010, at 19:34, Jorden M wrote: > >> On Mon, May 3, 2010 at 10:53 AM, erik quanstrom >> wrote: >>>> >>>> It's always been easier for me to use python's/perl's regular >>>> expressions when I needed to process a text file than to use plan9's. >>>> For simple things, e.g. while editing an ordinary text in acme/sam, >>>> plan9's regexps are just fine. >>> >>> i find it hard to think of cases where i would need >>> such sophistication and where tokenization or >>> tokenization plus parsing wouldn't be a better idea. >> >> A lot of the `sophisticated' Perl I've seen uses some horrible regexes >> when really the job would have been done better and faster by a >> simple, job-specific parser. >> >> I've yet to find out why this happens so much, but I think I can >> narrow it to a combination of ignorance, laziness, and perhaps that >> all-too-frequent assumption `oh, I can do this in 10 lines with perl!' >> I guess by the time you've written half a parser in line noise, it's >> too late to quit while you're behind. > > I think it's ignorance and something. I'm not sure what that something is= . I > am sure if you tried to suggest writing a parser to many of the > open-sourcers I've talked to you would be treated as if you were suggesti= ng I can attest that it's not just open-source folk. > a big job rather than a small one. "Why Write a Parser," =A0they would as= k, > "when I can just scribble a few little lines of perl?" That phenomenon is true, and if you take it further once that person is done writing their abominable perl, and point out that they've written a parser anyway, but poorly (not to mention one that would have to be totally rewritten to be modified), they look at you crosseyed and say `whatever.' > > Maybe it's humans' natural tendencies toward hierarchy coming into play. > Stuff known by Teachers and Masters easily takes on a bizarre kind of > importance, rank is unconsciously attached, and the student naturally but > unconsciously feels he is not of sufficient rank to attempt the Master's > Way. That explanation does pre-suppose humans have a very strong natural > tendency to hierarchy. I find sufficient evidence within myself to believ= e > it's true, as unpopular as the idea may be. Perhaps some people are more > strongly inclined that way than others. Anyway, it's the only explanation= I > can imagine for the phenomena. > Pretty much. Like Raschke mentioned, people as students are conditioned to think that parsers are hard to do because they're a piece of a compiler, and that Dragon book is too big and scary and only Gods can write compilers and parsers, etc.. Another function of the `parsers are too hard' mentality is that people don't recognize the difference between something that's regular and something that's CF, and spend days scratching their head wondering why their regexes break all over the place. Situations often become complicated when self-proclaimed perl experts drop in and go, `oh here, you just add this case and that case and you should be fine X% of the time!', where X is a BS figure pulled out of you know where. I think what we have here can be construed as a failure of CS education, which fits right in with the many failures of education at large. >> >>> >>> for example, you could write a re to parse the output >>> of ls -l and or ps. =A0but awk '{print $field}' is so much >>> easier to write and read. >>> >>> so in all, i view perl "regular" expressions as a tough sell. >>> i think they're harder to write, harder to read, require more >>> and more unstable code, and slower. >>> >>> one could speculate that perl, by encouraging a >>> monolithic, rather than tools-based approach; >>> and cleverness over clarity made perl expressions >>> the logical next step. =A0if so, i question the assumptions. >>> >>> - erik >>> >>> >> > > -- > Simplicity does not precede complexity, but follows it. -- Alan Perlis > > >