Re: [9fans] du and find

["Gabriel Díaz" <gdiaz@rejaa.com>]

Hello


(about students/trainees and perl)

Being able to recognize 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 sense of science. I mean something correct or well enough for the business could not be correct or well enough from the science point of view.

Speaking about non programming-related business, for me, it's enough if a student 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 lists of thousands of entries by hand, either in paper or in the original excel 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 alternatives, suggest other ways, etc.

The fail is not the school, or not completely. The tools are given to you, it is not usual you can choose the tool you want to use to finish a task. In nice places, you might be able to propose one. . .

slds.

gabi




----- Original Message ----
From: Jorden M <jrm8005@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Sent: Tue, May 4, 2010 5:38:35 PM
Subject: Re: [9fans] du and find

On Tue, May 4, 2010 at 6:01 AM, Ethan Grammatikidis <eekee57@fastmail.fm> wrote:
>
> On 3 May 2010, at 19:34, Jorden M wrote:
>
>> On Mon, May 3, 2010 at 10:53 AM, erik quanstrom <quanstro@quanstro.net>
>> 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 suggesting

I can attest that it's not just open-source folk.

> a big job rather than a small one. "Why Write a Parser,"  they would ask,
> "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 believe
> 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.  but 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.  if so, i question the assumptions.
>>>
>>> - erik
>>>
>>>
>>
>
> --
> Simplicity does not precede complexity, but follows it. -- Alan Perlis
>
>
>