From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <420020.3484.qm@web1208.biz.mail.gq1.yahoo.com> References: <455f59971ace96897640df2bff497ce3@kw.quanstro.net> <4FDD3B61-CA0D-446E-A05B-204B4866D755@fastmail.fm> Date: Tue, 4 May 2010 09:56:54 -0700 From: =?iso-8859-1?Q?Gabriel_D=EDaz?= To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] du and find Topicbox-Message-UUID: 19e7418e-ead6-11e9-9d60-3106f5b1d025 Hello=0A=0A=0A(about students/trainees and perl)=0A=0ABeing able to recogni= ze what you've studied in your daily work is quite difficult in most places= . Also your work objectives are rarely related to the correctness, in the s= ense of science. I mean something correct or well enough for the business c= ould not be correct or well enough from the science point of view.=0A=0ASpe= aking about non programming-related business, for me, it's enough if a stud= ent is able to use or ask for a programming language to solve a task perl, = vbscript or whatever. I've seen a couple of times students matching two lis= ts of thousands of entries by hand, either in paper or in the original exce= l format. And I've seen mentors and managers agree with the method. If they= can write regexp, even ugly ones, that's enough, you can show them alterna= tives, suggest other ways, etc.=0A=0AThe fail is not the school, or not com= pletely. The tools are given to you, it is not usual you can choose the too= l you want to use to finish a task. In nice places, you might be able to pr= opose one. . .=0A=0Aslds.=0A=0Agabi=0A=0A=0A=0A=0A----- Original Message --= --=0AFrom: Jorden M =0ATo: Fans of the OS Plan 9 from Be= ll Labs <9fans@9fans.net>=0ASent: Tue, May 4, 2010 5:38:35 PM=0ASubject: Re= : [9fans] du and find=0A=0AOn Tue, May 4, 2010 at 6:01 AM, Ethan Grammatiki= dis wrote:=0A>=0A> On 3 May 2010, at 19:34, Jorden M = wrote:=0A>=0A>> On Mon, May 3, 2010 at 10:53 AM, erik quanstrom =0A>> wrote:=0A>>>>=0A>>>> It's always been easier for me to us= e python's/perl's regular=0A>>>> expressions when I needed to process a tex= t file than to use plan9's.=0A>>>> For simple things, e.g. while editing an= ordinary text in acme/sam,=0A>>>> plan9's regexps are just fine.=0A>>>=0A>= >> i find it hard to think of cases where i would need=0A>>> such sophistic= ation and where tokenization or=0A>>> tokenization plus parsing wouldn't be= a better idea.=0A>>=0A>> A lot of the `sophisticated' Perl I've seen uses = some horrible regexes=0A>> when really the job would have been done better = and faster by a=0A>> simple, job-specific parser.=0A>>=0A>> I've yet to fin= d out why this happens so much, but I think I can=0A>> narrow it to a combi= nation of ignorance, laziness, and perhaps that=0A>> all-too-frequent assum= ption `oh, I can do this in 10 lines with perl!'=0A>> I guess by the time y= ou've written half a parser in line noise, it's=0A>> too late to quit while= you're behind.=0A>=0A> I think it's ignorance and something. I'm not sure = what that something is. I=0A> am sure if you tried to suggest writing a par= ser to many of the=0A> open-sourcers I've talked to you would be treated as= if you were suggesting=0A=0AI can attest that it's not just open-source fo= lk.=0A=0A> a big job rather than a small one. "Why Write a Parser," they w= ould ask,=0A> "when I can just scribble a few little lines of perl?"=0A=0AT= hat phenomenon is true, and if you take it further once that person=0Ais do= ne writing their abominable perl, and point out that they've=0Awritten a pa= rser anyway, but poorly (not to mention one that would=0Ahave to be totally= rewritten to be modified), they look at you=0Acrosseyed and say `whatever.= '=0A=0A>=0A> Maybe it's humans' natural tendencies toward hierarchy coming = into play.=0A> Stuff known by Teachers and Masters easily takes on a bizarr= e kind of=0A> importance, rank is unconsciously attached, and the student n= aturally but=0A> unconsciously feels he is not of sufficient rank to attemp= t the Master's=0A> Way. That explanation does pre-suppose humans have a ver= y strong natural=0A> tendency to hierarchy. I find sufficient evidence with= in myself to believe=0A> it's true, as unpopular as the idea may be. Perhap= s some people are more=0A> strongly inclined that way than others. Anyway, = it's the only explanation I=0A> can imagine for the phenomena.=0A>=0A=0APre= tty much. Like Raschke mentioned, people as students are=0Aconditioned to t= hink that parsers are hard to do because they're a=0Apiece of a compiler, a= nd that Dragon book is too big and scary and=0Aonly Gods can write compiler= s and parsers, etc.. Another function of=0Athe `parsers are too hard' menta= lity is that people don't recognize=0Athe difference between something that= 's regular and something that's=0ACF, and spend days scratching their head = wondering why their regexes=0Abreak all over the place. Situations often be= come complicated when=0Aself-proclaimed perl experts drop in and go, `oh he= re, you just add=0Athis case and that case and you should be fine X% of the= time!', where=0AX is a BS figure pulled out of you know where.=0A=0AI thin= k what we have here can be construed as a failure of CS=0Aeducation, which = fits right in with the many failures of education at=0Alarge.=0A=0A>>=0A>>>= =0A>>> for example, you could write a re to parse the output=0A>>> of ls -l= and or ps. but awk '{print $field}' is so much=0A>>> easier to write and = read.=0A>>>=0A>>> so in all, i view perl "regular" expressions as a tough s= ell.=0A>>> i think they're harder to write, harder to read, require more=0A= >>> and more unstable code, and slower.=0A>>>=0A>>> one could speculate tha= t perl, by encouraging a=0A>>> monolithic, rather than tools-based approach= ;=0A>>> and cleverness over clarity made perl expressions=0A>>> the logical= next step. if so, i question the assumptions.=0A>>>=0A>>> - erik=0A>>>=0A= >>>=0A>>=0A>=0A> --=0A> Simplicity does not precede complexity, but follows= it. -- Alan Perlis=0A>=0A>=0A>