Re: [stack] Abstracting away the complexity is the goal.

chris glur <[email protected]> wrote:

> >How did you measure the complexity? I don't get it.
>  The number of new concepts introduced.
>

As a subjective definition, this is only valuable when you specify who the
concepts are new to. Wouldn't it be more useful to -- for example -- measure
complexity according to the number of computational steps required to
describe the task? The nice thing about that is that if you've got good
abstractions (a main theme of this email exchange), you can just *use* them
without describing them, thus lowering the apparent complexity.

RSS comes with a free abstraction: the individual comments are presented
separately. You don't need to think about parsing them apart. They're also
clearly dated, which normal web content is not; since your code thinks about
datestamps, this is actually important, and you have no way of getting that
info.

For decade/s I ignored Turbo-pascal & used my own P-code compiler, because
> "turbo" was a fad-word. I've been thinking that blogs are just a passing
> fad
> like sub-prime-loans.
>

I sympathize; I've been trying to think that for years. So far they haven't
gone away :-). To be fair, though, they've got advantages over Usenet. The
only thing I balk at anymore is the word 'blog', and that's just because I'm
a curmudgeon.

> What sort of thing does the utility do? I'm guessing it runs a Google
> > search qualified by "site:<URL>" for the 3 words...
>  Yes, that an example of NOT complexity. You could see what it does.
>

Actually, I was puzzled... Took me a while. I guess I've been using feed
aggregators for too long. BTW, there are also services that will email you
when a web page changes. (I wouldn't use 'em either. :-)

> No, I mean all the FOR loops. You have a huge set of nested FOR loops.
> > That's going to be _slow_.
> IMO we mostly talk past each other.
>

Yes, most of the time.

If the algorithm demands nested FORs ...which this one does.
>

My guess would be that it uses one FOR, perhaps two at the most; and a set
of nested IFs.

Except my text was wrong. Let's examine further ..
> Just look at this mess:-
> ContainsWord(
>  ContainsWord(
>  ContainsWord(
>   AllFilesYoungerThanDays(15), <word1>), <word2> , <word3>)
> which might STILL be wrong.
> Each of the 4 functions returns a set-of-files/FileNames.
>

Nod.

How much less complex [cognitive load] is a piped data-flow notation:
>  15 AllFilesYoungerThanDays |
> <word1> ContainsWord |
> <word2> ContainsWord |
> <word3> ContainsWord |
>

Fair statement. Now, in Factor or Joy you could have the same thing, only
without the pipes. Like this:

 15 AllFilesYoungerThanDays
<word1> ContainsWord
<word2> ContainsWord
<word3> ContainsWord

The definition of ContainsWord would have the stack effect ( path-list
string -- path-list' ).

I'm less interested in the D.Knuth-like considerations of optimising the
> search

by eg. combining the search for the 3 [or n] words, rather than just doing
> 3 searches, that the HUMAN readability/maintainablility of the code.
>

D Knuth knew well the sinfulness of premature optimization.

> you wanted to use functions from libraries
> YES! But they must be 'clean' as expounded in SICP.
> IMO if they evolve naturally, they get over-run by entropy.
> So they need to limited by formality.
>

What do you mean 'limited by formality'? I agree with the rest of your
point; actually, that's one thing I like about Factor, that because most of
the language's development is centered in the main Factor repository, the
team hasn't been afraid to make major changes even to the core library in
order to produce better code in applications and/or support code: they
change the library, and then change all the applications to make sure it
improves the application code.

Perhaps I have a special mental defficiency, but regular-expression-search
> is the most fascinating/frustrating can-of-worms for me.
> AGAIN I've spent hours, without success the find how to use sed to
> <extract the string from the file: which starts with "start" and ends  with
> "end", exclusively>.
>

That reminds me of REBOL's 'parse' function, which instead of using cryptic
regexps, uses more verbose and powerful LL expressions. You might want to
check it out; it's not exactly what you're asking for, but it might serve
your needs better than the other existing technologies.

I can't help you with sed; I prefer string processing rather than regular
expressions, and prefer full programming languages when possible. I suspect
you'd have to agree that 'sed' is pretty much the worst of all possible
worlds -- cryptic and relatively non-powerful.

But related to 'sed' the following newly discovered cat-like [piping results
> through transformers] method fascinates me.
>

I persist in my request that you justify using 'cat-like'. What you're
describing isn't like 'concatenative' languages, and it's not like the 'Cat'
language... Why do you keep using it?

So, the zillions of year-lines of confirmed unix code , prove the viability
> of the concept.  Except the unix utilities just evolved chaotically and
> don't fit together cleanly, as a system which was designed from the ground,
> would.
>

Yes, I agree. As a side comment, the OS "plan 9" (from some of the inventors
of Unix) attempted to reengineer Unix from the ground up on roughly those
grounds. http://www.caerwyn.com/acme/ seems to be the port for most OSes.

Yes it's flat which is the basis of [reason for] the simplicity.
> The nesting comes in the called functions,
>  which presumably can nestedly call other routines.
>

Yes, but they're still only flatly structured. Unless, of course, you allow
for immediate words, which is how Forth does its control structures -- and I
think is part of what annoys you.

I'm not convinced that adding control stuctures to this data-flow-view,
> is viable, because it would destroy the one-dimensional simplicity.
>

I understand; but programmers should be taught that when the code _can_ be
flat, it _should_ be. When it _can't_ -- it shouldn't. A more powerful

IMO forth is a nightmare to read.
>

I find it delightful. I enjoy ColorForth as well.

Whereas I'm proposing to use flat data-flow to call functions,
> as you know, unix uses block-structured algol-style scripts, with
> data-flow-tricks to get get values, like [conceptually]
>  append the date-field of the line mentioning "dog" to the
>  weight-field of the line mentioning "cat".


I'm not sure how I'd do that using only pipes in Unix. I know how I'd do it
in 'real' programming languages.

But once you allow data flow tricks, why not allow a decent set of them?

== Chris Glur.


-Wm


[Non-text portions of this message have been removed]