Orchid XP v8 wrote:
> Oh, sure. I just meant that even once grep has found the location for 
> you, the task you're attempting to perform is almost impossible anyway...

And... you program computers?  Why, if you find it almost impossible?

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

On Sat, 24 Apr 2010 19:27:38 +0100, Orchid XP v8 wrote:

>>> Isn't trying to figure out why an arbitrary piece of code doesn't work
>>> formally equivilent to the Halting Problem? (With non-termination
>>> simply being the most basic kind of program bug...)
>> 
>> You're not asking grep to tell you why it failed, just to tell you
>> where in the code the error is so one can manually inspect the file and
>> see if one can determine why the failure occurred.
> 
> Oh, sure. I just meant that even once grep has found the location for
> you, the task you're attempting to perform is almost impossible
> anyway...

Clearly it is, because I've only done it several times in my lifetime. ;-)

Come to that, I've even somehow managed this "impossible" or "almost 
impossible" task a few times *without access to the code*. <gasp>

(There you go again, assuming because you can't see how it could be done 
that it must be absolutely impossible for anyone to do - you really need 
to stop doing that).

Now, from a *practical* standpoint, with access to the source, the way I 
would do it is this:

1.  Grep for the error code in the source tree.
2.  Look at the function the error code is in; if it's a generic error 
function, then it becomes a little more tricky, but not impossibly so, 
because:
3.  I can use a tool like Source Navigator NG to show me the function 
call stack; walking backwards through the stack and seeing what 
conditions must exist in order to end up with that error message can 
point to several causes.
4.  Then look at the options for causes, and see which one is likely on 
the system.
5.  If it is easy to reproduce the cause, try it and see if the result is 
what was expected.

Not so difficult to do - and I don't have a background in software 
engineering. ;-)

Jim

Post a reply to this message

On Sat, 24 Apr 2010 19:30:52 +0100, Orchid XP v8 wrote:

> Warp wrote:
>> Orchid XP v8 <voi### [at] devnull> wrote:
>>> why would you want to do this?
>> 
>>   Why would one want to do pattern substitution?
> 
> No, why would you want to find anything that's a number, parse it, and
> add one to it. It doesn't seem like a particularly useful example. I'm
> sure the same techniques could be used to do something more useful, but
> I can't think of an example.

Immediately one that comes to me is the output of a program that was off 
by one - and the original program is no longer available or it would take 
longer to re-run than to just correct the data.

> Anyway, I forget how we even got started on this topic, but this debate
> has gone on long enough to make a few things clear. It seems that
> low-level text munging is useful for the kind of stuff you do, and not
> especially useful for the kind of stuff I do. Let's leave it at that.

It's entirely possible if you understood it better and what the 
capabilities of the various programs are, you could save yourself time 
(either now or in the future) by not doing things in a way that is harder 
or takes more time.

I said earlier that I'm not a software engineer - and I'm not.  I took a 
few courses in programming and Computer Science when I was at uni, but I 
do understand that if the only language you know is BASIC (the first 
language I learned - Commodore BASIC), many things will seem impossible 
to do because the *tool* is limited.  By understanding that there are 
other tools available and some tools are better suited to accomplish a 
task than others, you broaden your ability to get the job done 
efficiently.

If I had stuck with just programming in C (which was may main language of 
choice), then doing the types of data manipulation I do with awk or sed 
(I prefer the former, actually, but can use both), I'd be stuck in a 
cycle of code, compile, run, analyze, modify code, compile, run, 
analyze.....which takes a lot more time.

In C, a program to search and traverse the directory structure would be 
quite long (actually, one can see what's involved by looking at the 
source for grep!), but using a tool that's built for that purpose?  Much 
more efficient than building your own.

You know the old saying, when the only tool you have is a hammer, 
everything looks like a nail?

Jim

Post a reply to this message

Jim Henderson wrote:
> You know the old saying, when the only tool you have is a hammer, 
> everything looks like a nail?

everything looks like a thumb.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

On Sat, 24 Apr 2010 14:40:57 -0700, Darren New wrote:

> Jim Henderson wrote:
>> You know the old saying, when the only tool you have is a hammer,
>> everything looks like a nail?
> 
> everything looks like a thumb.

LOL, too true!

Jim

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Warp wrote:
> > Orchid XP v8 <voi### [at] devnull> wrote:
> >> why would you want to do this?
> > 
> >   Why would one want to do pattern substitution?

> No, why would you want to find anything that's a number, parse it, and 
> add one to it.

  You don't understand the concept of a simple example, do you?

  An example is a simple proof-of-concept which demonstrates a feature.
Asking "why would you want to do that" is idiotic when we are talking
about examples.

  If you give someone an example of a short Haskell program which prints
"Hello World!", and that someone would then ask you "why would you want
to do that?", wouldn't you consider him an idiot? He is *missing the point*.
It was just an example to demonstrate something.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Orchid XP v8 wrote:
>> Oh, sure. I just meant that even once grep has found the location for 
>> you, the task you're attempting to perform is almost impossible anyway...
> 
> And... you program computers?  Why, if you find it almost impossible?

My programs aren't arbitrary. They have some kind of structure to them. 
Other people's programs do not necessarily have this property.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> My programs aren't arbitrary. They have some kind of structure to them. 
> Other people's programs do not necessarily have this property.

So, everyone else is a *worse* programmer than you? And they write random 
programs with no purpose? ;-)

Here's the deal that Turing figured out. You can't take every *arbitrary* 
program, i.e., one created by generating a bunch of machine code 
instructions with a random number generator, and figure out what it's going 
to do without running it. But that's not how people write programs.

You also can't check that a program is typesafe, because you can't tell if 
an arbitrary program every assigns the wrong type to a variable. But we 
design strongly-typed programming languages that disallow well-typed 
programs that the compiler can't prove are well-typed.

Since people don't debug arbitrary random programs, it's usually (usually!) 
fairly easy to figure out, when you get an error message, what caused it. 
Certainly easier than when you get no error message and just the wrong answers.

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message

On Sun, 25 Apr 2010 09:35:34 +0100, Orchid XP v8 wrote:

> My programs aren't arbitrary. They have some kind of structure to them.
> Other people's programs do not necessarily have this property.

There's a difference between "arbitrary" and "complex".

Jim

Post a reply to this message

> It has its drawbacks, too. Having a file named -rf in your home directory 
> leads to problems, for example.  Before shells properly escaped 
> everything, files with spaces in the names were very problematic as well.

Took me a long time to figure out the CAD system on our Unix box was 
crashing because the path name had a space in it, not because the file was 
corrupt somehow...

Post a reply to this message