Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #34314 > unrolled thread

Does Forth solve the paradox?

Back to article view | Back to comp.lang.forth

Contents

  Does Forth solve the paradox? forthisit@gmail.com - 2014-11-05 08:08 -0800
    Re: Does Forth solve the paradox? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-05 19:45 +0000
      Re: Does Forth solve the paradox? "Elizabeth D. Rather" <erather@forth.com> - 2014-11-05 10:43 -1000
        Re: Does Forth solve the paradox? Paul Rubin <no.email@nospam.invalid> - 2014-11-05 14:04 -0800
          Re: Does Forth solve the paradox? "Elizabeth D. Rather" <erather@forth.com> - 2014-11-05 12:49 -1000
            Re: Does Forth solve the paradox? rickman <gnuarm@gmail.com> - 2014-11-05 18:13 -0500
              Re: Does Forth solve the paradox? "Elizabeth D. Rather" <erather@forth.com> - 2014-11-05 13:54 -1000
              Re: Does Forth solve the paradox? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-06 10:13 +0000
            Re: Does Forth solve the paradox? the_gavino_himself <visphatesjava@gmail.com> - 2014-11-05 20:55 -0800
            Re: Does Forth solve the paradox? Paul Rubin <no.email@nospam.invalid> - 2014-11-05 22:19 -0800
        Re: Does Forth solve the paradox? m.a.m.hendrix@tue.nl - 2014-11-06 03:05 -0800
          Re: Does Forth solve the paradox? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-06 11:43 +0000
            Re: Does Forth solve the paradox? m.a.m.hendrix@tue.nl - 2014-11-06 04:46 -0800
              Re: Does Forth solve the paradox? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-06 16:58 +0000
      Re: Does Forth solve the paradox? rickman <gnuarm@gmail.com> - 2014-11-05 17:22 -0500
      Re: Does Forth solve the paradox? the_gavino_himself <visphatesjava@gmail.com> - 2014-11-05 18:54 -0800
      Re: Does Forth solve the paradox? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-06 09:22 +0000
        Re: Does Forth solve the paradox? Mark Wills <markwills1970@gmail.com> - 2014-11-06 03:20 -0800
        Re: Does Forth solve the paradox? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-06 10:18 -0600
          Re: Does Forth solve the paradox? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-06 18:30 +0000
            Re: Does Forth solve the paradox? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-07 03:22 -0600
          Re: Does Forth solve the paradox? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-11-06 16:57 -0500
            Re: Does Forth solve the paradox? forthisit@gmail.com - 2014-11-06 14:38 -0800
            Re: Does Forth solve the paradox? "Elizabeth D. Rather" <erather@forth.com> - 2014-11-06 13:58 -1000
          Re: Does Forth solve the paradox? Paul Rubin <no.email@nospam.invalid> - 2014-11-07 10:40 -0800
            Re: Does Forth solve the paradox? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-08 02:36 -0600
            Re: Does Forth solve the paradox? "Elizabeth D. Rather" <erather@forth.com> - 2014-11-07 22:45 -1000
          Re: Does Forth solve the paradox? Bernd Paysan <bernd.paysan@gmx.de> - 2014-11-14 01:33 +0100
            Re: Does Forth solve the paradox? m.a.m.hendrix@tue.nl - 2014-11-14 02:34 -0800
            Re: Does Forth solve the paradox? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-14 05:07 -0600
              Re: Does Forth solve the paradox? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-15 16:21 +0000
                Re: Does Forth solve the paradox? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-11-15 11:52 -0600
                Re: Does Forth solve the paradox? hughaguilar96@yahoo.com - 2014-11-15 12:47 -0800
                Re: Does Forth solve the paradox? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-16 00:06 +0000
                  Re: Does Forth solve the paradox? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-11-16 00:45 +0000
                    Re: Does Forth solve the paradox? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-16 13:39 +0000
        Re: Does Forth solve the paradox? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-11-06 19:54 +0000
    Re: Does Forth solve the paradox? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2014-11-06 08:26 -0800
      Re: Does Forth solve the paradox? "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-11-06 16:57 -0500

Page 2 of 2 — ← Prev page 1 [2]

#34342

Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> In article <4pudnS9lFcDMAsbJnZ2dnUVZ8qqdnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
> <simple>
>>
>>"Software complexity is a terrible enemy that inhibits our ability to
>>develop adaptable software that's easy to understand. To deal with
>>complexity, we try designing flexible software. Sadly, too often the
>>flexibility we hope will tame complexity and yield higher degrees of
>>reuse and maintainability has a paradoxical effect. The complexity
>>hinders use and decreases the ability of our software to survive
>>long-term."
>>
>>Quite.
> 
> Take my ASUS memopad. (Or an ipad).
> 
> It is the pinnacle of simplicity. Just a bunch of pixels in different
> colors. There is one interface, touch it at an xy coordinate.

An ipad is scarcely the pinnacle of simplicity.  It may present the
illusion of simplicity, but it is an illusion.

Andrew.

[toc] | [prev] | [next] | [standalone]

#34337

On Thu, 06 Nov 2014 11:18:25 -0500, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>> In article <6f36e5e5-037c-41e2-89c5-2bc11937ddcd@googlegroups.com>,
>>> <forthisit@gmail.com> wrote:
>>>> http://www.informit.com/articles/article.aspx?p=1963779
>> [...]

>>> This article reminds me of when I was a high school student and was
>>> obliged to write essays about subjects. Of course I was naive and
>>> had no opinion whatsoever about the subjects, even less personal
>>> experience.
>>
>> I also got the feeling of buzzword bingo from the article, like much
>> software engineering stuff around, but there are apparently some
>> points worth discussing there:
>>
>>> But in the spirit of
>>> Halloween I'll drive a wooden stake through the heart.
>>>
>>> Flexibility breeds complexity?
>>>
>>> No!
>>>
>>> Simplicity breads flexibility.
>>
>> Now that's an interesting point.  Looking at the descriptions of Chuck
>> Moore's philosophy (often called the Forth philosophy), he seems to
>> side with the author of the article: "Do not put code in your program
>> that might be used. Do not leave hooks on which you can hang
>> extensions."  These things he avoids are things that make the program
>> flexible.  And Chuck Moore does not want flexibility.  If the
>> requirements change and the program is not flexible enough, he does
>> not change the program, he rewrites it.
>
> Indeed so.  It seems to me that a lot of the arguments made by the
> author were exactly the ones made by Forthers in the past, especially
> Chuck Moore.  A very-generalized solution to a problem is going to be
> more complex, more expensive, and harder to maintain [than] one that
> simply does the job at hand.  A reusable component likewise.  I don't
> quite understand why this simple piece has raised so much ire here.
>

s/that/than

> "Software complexity is a terrible enemy that inhibits our ability to
> develop adaptable software that's easy to understand. To deal with
> complexity, we try designing flexible software. Sadly, too often the
> flexibility we hope will tame complexity and yield higher degrees of
> reuse and maintainability has a paradoxical effect. The complexity
> hinders use and decreases the ability of our software to survive
> long-term."
>

I think the problem is that everyone decided the
ancient paradigm of a dedicated program for every
task was bad, and adopted new paradigms which were
unproven and worse.  Look at the Linux applications
which attempt to merge the tasks of 50 programs into
just one.  I'd argue that 50 programs with few to
no parameters is much easier to use and maintain than
one program which has over 500 command line options.
Most standalone programs are "once and done."  They'll
never need any more work.  They work correctly the first
time and every time.  I can't even use "ls" list directory
command on Linux without consulting the manpage on an
almost daily basis for some needed option.  I'm constantly
consulting manpages for information on parameters and the
format of them.  What a total waste of time.  DOS did it
the correct way.  Every command has only a handful of
options and displays the options when queried or executed
without paramters.  If it's not that, then it's some other
issue such as which choice among many choices it the better
option, such as deciding between GREP, AWK, VI or SED.
Grocery stores which limit choice make far more money
than those which don't.  I believe the psychology behind
that is solid for programming languages too.  I've been
saying that is one reason for C's success versus Forth,
but no one here is listening to that, or receptive of it.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#34339

On Thursday, November 6, 2014 3:57:55 PM UTC-6, Rod Pemberton wrote:
> 
> I think the problem is that everyone decided the
> ancient paradigm of a dedicated program for every
> task was bad, and adopted new paradigms which were
> unproven and worse.  Look at the Linux applications
> which attempt to merge the tasks of 50 programs into
> just one.  I'd argue that 50 programs with few to
> no parameters is much easier to use and maintain than
> one program which has over 500 command line options.
> Most standalone programs are "once and done."  They'll
> never need any more work.  They work correctly the first
> time and every time.  I can't even use "ls" list directory
> command on Linux without consulting the manpage on an
> almost daily basis for some needed option.  I'm constantly
> consulting manpages for information on parameters and the
> format of them.  What a total waste of time.  DOS did it
> the correct way.  Every command has only a handful of
> options and displays the options when queried or executed
> without paramters.  If it's not that, then it's some other
> issue such as which choice among many choices it the better
> option, such as deciding between GREP, AWK, VI or SED.
> Grocery stores which limit choice make far more money
> than those which don't.  I believe the psychology behind
> that is solid for programming languages too.  I've been
> saying that is one reason for C's success versus Forth,
> but no one here is listening to that, or receptive of it.
> 
> 
> Rod Pemberton

I don't understand your conclusion about C vs. Forth, but I appreciate the rest. 
It reminds me of the diagram at the end of Chap 11 of Starting Forth, you know 
the one with simplicity represented by a pegboard full of common tools vs. 
complexity represented by a single device attempting to be a combination of all 
those same tools. It asks "Which approach seems more useful?" I love that 
illustration and think of it often.

I see it happen in the world of EDA tools all the time. They seem to become more 
complex over time as they bundle more and more functions into the tool 
needlessly. I think people think they look smart and are contributing some 
valuable idea when they point out "Hey, why should we buy a simulator and 
revision control tool and synthesis tool when they could all be done by the same 
program?" Perhaps they think it saves money. But if that is true why don't we 
demand saw_hammer_level_drill_pliers? Wouldn't that save money? I'm not sure it 
would in the long run. I love my leatherman, but would never use it in my garage 
where I have easy access to all the individual tools that comprise it. Of course 
the EDA tool vendors are all too willing to add the complexity since it makes us 
more dependent on their version of what the design process should look like, and 
less likely or able to switch to a different tool vendor.

[toc] | [prev] | [next] | [standalone]

#34340

On 11/6/14 11:57 AM, Rod Pemberton wrote:
> On Thu, 06 Nov 2014 11:18:25 -0500, Andrew Haley
...
>> "Software complexity is a terrible enemy that inhibits our ability to
>> develop adaptable software that's easy to understand. To deal with
>> complexity, we try designing flexible software. Sadly, too often the
>> flexibility we hope will tame complexity and yield higher degrees of
>> reuse and maintainability has a paradoxical effect. The complexity
>> hinders use and decreases the ability of our software to survive
>> long-term."
>>
>
> I think the problem is that everyone decided the
> ancient paradigm of a dedicated program for every
> task was bad, and adopted new paradigms which were
> unproven and worse.  Look at the Linux applications
> which attempt to merge the tasks of 50 programs into
> just one.  I'd argue that 50 programs with few to
> no parameters is much easier to use and maintain than
> one program which has over 500 command line options.
> Most standalone programs are "once and done."  They'll
> never need any more work.  They work correctly the first
> time and every time.  I can't even use "ls" list directory
> command on Linux without consulting the manpage on an
> almost daily basis for some needed option.  I'm constantly
> consulting manpages for information on parameters and the
> format of them.  What a total waste of time.  DOS did it
> the correct way.  Every command has only a handful of
> options and displays the options when queried or executed
> without paramters.  If it's not that, then it's some other
> issue such as which choice among many choices it the better
> option, such as deciding between GREP, AWK, VI or SED.
> Grocery stores which limit choice make far more money
> than those which don't.  I believe the psychology behind
> that is solid for programming languages too.  I've been
> saying that is one reason for C's success versus Forth,
> but no one here is listening to that, or receptive of it.

I certainly think Forth is closer to the DOS model of many simple 
commands with few parameters than the Linux/ls example you cite, which 
sounds as though it was designed by the person to designed the bad 
Fortran program I described. The Forth style tends toward many small, 
simple programs, each of which does one thing well and requires few 
parameters. Indeed, it takes that model to an extreme, to the point that 
learning Forth is more like learning a human language than a programming 
language with only a few powerful commands.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#34347

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> A very-generalized solution to a problem is going to be more complex,
> more expensive, and harder to maintain that one that simply does the
> job at hand.  A reusable component likewise.  I don't quite understand
> why this simple piece has raised so much ire here.

"The unfortunate tendency to write overly restricted code influences how
we write programs that are supposed to be general.  Soon enough we shall
meet programs designed to keep track of exactly seventeen salesmen, to
sort precisely 500 numbers, to trace through just one maze.  We can only
guess at how much of the program rewriting that goes on every day
actually amounts to entering parameters through the compiler."

--B. W. Kernighan and P.J. Plauger
_The Elements of Programming Style_ (2nd ed, 1978), p.3

[toc] | [prev] | [next] | [standalone]

#34353

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> A very-generalized solution to a problem is going to be more complex,
>> more expensive, and harder to maintain that one that simply does the
>> job at hand.  A reusable component likewise.  I don't quite understand
>> why this simple piece has raised so much ire here.
> 
> "The unfortunate tendency to write overly restricted code influences
> how we write programs that are supposed to be general.  Soon enough
> we shall meet programs designed to keep track of exactly seventeen
> salesmen, to sort precisely 500 numbers, to trace through just one
> maze.  We can only guess at how much of the program rewriting that
> goes on every day actually amounts to entering parameters through
> the compiler."

Yes, and that pithily summarizes the two positions.  Both kinds of
error exist in practice, of course, and both are to be avoided.

Andrew.

[toc] | [prev] | [next] | [standalone]

#34354

On 11/7/14 8:40 AM, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> A very-generalized solution to a problem is going to be more complex,
>> more expensive, and harder to maintain that one that simply does the
>> job at hand.  A reusable component likewise.  I don't quite understand
>> why this simple piece has raised so much ire here.
>
> "The unfortunate tendency to write overly restricted code influences how
> we write programs that are supposed to be general.  Soon enough we shall
> meet programs designed to keep track of exactly seventeen salesmen, to
> sort precisely 500 numbers, to trace through just one maze.  We can only
> guess at how much of the program rewriting that goes on every day
> actually amounts to entering parameters through the compiler."

Any program design that compiles in things like how many salesmen or 
numbers sorted is simply an incompetent design. That is not a useful 
argument. The level of generality that we're decrying is attempting to 
be all things to all people: for example, multiple sorting algorithms in 
the same package, rather than individual sorts, documented as to their 
appropriate use and parameters required so the programmer can select the 
one appropriate to this application need.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#34396

Andrew Haley wrote:
> Indeed so.  It seems to me that a lot of the arguments made by the
> author were exactly the ones made by Forthers in the past, especially
> Chuck Moore.  A very-generalized solution to a problem is going to be
> more complex, more expensive, and harder to maintain that one that
> simply does the job at hand.  A reusable component likewise.  I don't
> quite understand why this simple piece has raised so much ire here.

I'm not sure about this, because one reusable and extremely powerful tool in 
Forth is the interpreter itself.  The "Interpreter" is a very common design 
pattern; how often do you think a normal programmer writes an interpreter?  
Usually with the "design for one problem at hand" approach... which is very 
inflexible and quickly leeds to implementing another interpreter, because 
the first one wasn't good enough.

In Forth, instead of doing that, you often just reuse the already available 
interpeter.  And it's not big and complex.  And because Forth is a general 
purpose language, that interpreter is extensible and extremely powerful, 
even though quite simple to implement.  I've had friends, who weren't too 
much convinced of Forth, but exposed to it by me, and when they got to the 
point of "I need an interpreter", they just wrote a little Forth.  Because 
it was so much easier than any other typical option how to add an 
interpreter.

And that's how you do over-generalized things in Forth: You just expose the 
extensible interpreter, and write the stuff you actually need with this 
interpreter.  Or with a byte-coded variant of it, if you think byte-code is 
a good idea for your case (OpenFirmware and net2o considder tokenized code 
as better than plain text Forth).

So I think, yes: Forth does solve this paradoxon of simplifying, 
generalizing, and reusability, with the simple, general, and reusable 
component of the Forth interpreter, or variants, inspired by the Forth 
interpreter (can be both the inner or outer interpreter; after all, the 
inner interpreter is "just" a speed-optimized version of the outer 
interpreter so that you gain speed by compiling from outer to inner 
interpreter).

I would say that a very generalized solution to a problem needs more time to 
be simplified enough so that it is easy to maintain and reuse; and as my 
rule of thumb is that any sufficient complicated problem requires a turing 
complete programming language as solution, my advice is that if you think 
that you might maybe have such a problem, just add the turing complete 
programming language right now (I should add to that "object oriented"), 
make it Forth or Forth-like, and then be done with it.  If you like OOP-
based design, add a very simplified OOP thingy to it, as well; it fits in 
naturally, and you'll get there, too.

Of course, you can say that an OOP-based Forth-like language consists only 
of hooks, and you are right: It's a simple, small, maintainable and fairly 
efficient solution to the over-generalized problem.

And then you can carry on by solving only those problems at hand, because 
you never have to think about the generalization.  It's already there.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#34401

> And that's how you do over-generalized things in Forth: You just expose 
> the extensible interpreter, and write the stuff you actually need with 
> this interpreter.

Very well formulated. It puts into words my strong aversion against turnkey 
(Forth) applications, precompiled modules, and comment-stripped/obfuscated
source. If it can't compile itself, it is not Forth.

It also exposes a potential weakness: to be useful, Forth must be able to
connect to every possible system resource. 

A Forth system that can compile itself and can access every possible resource would have no need to be backward or forward compatible with anything. The only thing that stands in its way is efficiency of execution (and convenience of use).

-marcel

[toc] | [prev] | [next] | [standalone]

#34404

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> Indeed so.  It seems to me that a lot of the arguments made by the
>> author were exactly the ones made by Forthers in the past, especially
>> Chuck Moore.  A very-generalized solution to a problem is going to be
>> more complex, more expensive, and harder to maintain that one that
>> simply does the job at hand.  A reusable component likewise.  I don't
>> quite understand why this simple piece has raised so much ire here.
> 
> I'm not sure about this, because one reusable and extremely powerful tool in 
> Forth is the interpreter itself.  The "Interpreter" is a very common design 
> pattern; how often do you think a normal programmer writes an interpreter?  

Sure, there are special cases where a very powerful and general
solution to a problem can be clean and simple.  The first such was
perhaps the subroutine call instruction.

> And that's how you do over-generalized things in Forth: You just
> expose the extensible interpreter, and write the stuff you actually
> need with this interpreter.  Or with a byte-coded variant of it, if
> you think byte-code is a good idea for your case (OpenFirmware and
> net2o considder tokenized code as better than plain text Forth).
> 
> So I think, yes: Forth does solve this paradoxon of simplifying,
> generalizing, and reusability, with the simple, general, and
> reusable component of the Forth interpreter, or variants, inspired
> by the Forth interpreter (can be both the inner or outer
> interpreter; after all, the inner interpreter is "just" a
> speed-optimized version of the outer interpreter so that you gain
> speed by compiling from outer to inner interpreter).

I'm not going to argue with the point about writing interpreters, but
as a more general rule I am very skeptical.  If you can find something
which is a nice fit, sure.  A good counter example is sorting: there
is no general-purpose sorting algorithm which is the best for all
datasets and all systems.

Andrew.

[toc] | [prev] | [next] | [standalone]

#34422

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> A good counter example is sorting: there
>is no general-purpose sorting algorithm which is the best for all
>datasets and all systems.

Best?  That sounds like "tightly optimized for a specific application
szenario", which I mentioned earlier.  Otherwise, mergesort and
quicksort are pretty good algorithms, and either one will do nicely
for most of the few applications that need sorting.  In the last 25
years, I did nearly all of my sorting with the Unix sort program; I
needed sorting in a program written in something lower-level than a
shell-script only once (and there I used standard C's qsort()
function).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#34423

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>
>> A good counter example is sorting: there is no general-purpose
>> sorting algorithm which is the best for all datasets and all
>> systems.
> 
> Best?  That sounds like "tightly optimized for a specific
> application szenario", which I mentioned earlier.

Indeed.

This isn't just old-fashioned stuff.  I have noticed a change of
emphasis in server design recently, mostly due to cloud computing:
when you're paying a cloud provider by the megabyte (and the
kilowatt!) you tend to care about efficiency.  And when you're
replicating a server thousands of times, it's worth paying someone who
knows what they're doing to optimize it.  As Nevil Shute put it, "It
has been said that an engineer is a man who can do for ten shillings
what any fool can do for a pound."

> Otherwise, mergesort and quicksort are pretty good algorithms, and
> either one will do nicely for most of the few applications that need
> sorting.

Well, yes, but which quicksort?  There are many.  I spent a little
time this week reading Yaroslavskiy's dual-pivot quicksort.  It's very
impressive as a piece of engineering, in much the same way that a
large airliner is, but perhaps overkill if you want to sort half a
dozen integers.  If you don't care about the implementation complexity
or size this doesn't matter, of course.

I think there's no real disagreement about matters of fact here, just
a difference of emphasis.

Andrew.

[toc] | [prev] | [next] | [standalone]

#34424

On Saturday, November 15, 2014 9:33:34 AM UTC-7, Anton Ertl wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> > A good counter example is sorting: there
> >is no general-purpose sorting algorithm which is the best for all
> >datasets and all systems.
> 
> Best?  That sounds like "tightly optimized for a specific application
> szenario", which I mentioned earlier.  Otherwise, mergesort and
> quicksort are pretty good algorithms, and either one will do nicely
> for most of the few applications that need sorting.  In the last 25
> years, I did nearly all of my sorting with the Unix sort program; I
> needed sorting in a program written in something lower-level than a
> shell-script only once (and there I used standard C's qsort()
> function).

I provide HeapSort in the novice package, and got criticized horribly for it. As a practical matter, the only program I ever recall using a sort was the LowDraw program that I wrote over 10 years ago, and I used the BubbleSort for that (it was only 5 integers, and this was before the novice package existed so I was still putting low-level code in the application program).

Normally, if I want data sorted, I will use ASSOCIATION.4TH because it keeps the data sorted at all times while yet allowing new data to be inserted, which is pretty cumbersome and slow with an array. 

[toc] | [prev] | [next] | [standalone]

#34427

In article <2014Nov15.172155@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> A good counter example is sorting: there
>>is no general-purpose sorting algorithm which is the best for all
>>datasets and all systems.
>
>Best?  That sounds like "tightly optimized for a specific application
>szenario", which I mentioned earlier.  Otherwise, mergesort and
>quicksort are pretty good algorithms, and either one will do nicely
>for most of the few applications that need sorting.  In the last 25
>years, I did nearly all of my sorting with the Unix sort program; I
>needed sorting in a program written in something lower-level than a
>shell-script only once (and there I used standard C's qsort()
>function).

I had the problem of sorting a glossary, first by chapter then by wordname.
This I had solved by a c++ program (my first actually: 1994).
It specifies records and fields by regular expressions.
This was because I didn't know how to solve that sorting problem in some other
way. This general purpose full featured 10 kg sledgehammer has served me nicely,
and I recently made it to compile again to a 64 bit version, after using the
unaltered program till my 90 MHz Pentium broke down.
It is instrumental in generating the ciforth documentation.

At the time,it came out first in a comparative test I did, in
reliability, features and even in speed.

Bottom line, a situation where you want to sort integers in a
straight array is rare. You can handle fixed records with an
execution token for the comparison , and that is a one screener.
But if you're encountering a somewhat hard practical situation
that probably doesn't cut it.

And as you point out, mostly you sort files anyway.
The unix sort has some heavy usage with me on all kind of euler problems,
to analyse tables of results for patterns.

>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#34429

Albert van der Horst wrote:

> In article <2014Nov15.172155@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> A good counter example is sorting: there
>>>is no general-purpose sorting algorithm which is the best for all
>>>datasets and all systems.
>>
>>Best?  That sounds like "tightly optimized for a specific application
>>szenario", which I mentioned earlier.  Otherwise, mergesort and
>>quicksort are pretty good algorithms, and either one will do nicely
>>for most of the few applications that need sorting.  In the last 25
>>years, I did nearly all of my sorting with the Unix sort program; I
>>needed sorting in a program written in something lower-level than a
>>shell-script only once (and there I used standard C's qsort()
>>function).
> 
> I had the problem of sorting a glossary, first by chapter then by
> wordname. This I had solved by a c++ program (my first actually: 1994).
> It specifies records and fields by regular expressions.
> This was because I didn't know how to solve that sorting problem in some
> other way. This general purpose full featured 10 kg sledgehammer has
> served me nicely, and I recently made it to compile again to a 64 bit
> version, after using the unaltered program till my 90 MHz Pentium broke
> down. It is instrumental in generating the ciforth documentation.
> 
> At the time,it came out first in a comparative test I did, in
> reliability, features and even in speed.
> 
> Bottom line, a situation where you want to sort integers in a
> straight array is rare. You can handle fixed records with an
> execution token for the comparison , and that is a one screener.
> But if you're encountering a somewhat hard practical situation
> that probably doesn't cut it.
> 
> And as you point out, mostly you sort files anyway.
> The unix sort has some heavy usage with me on all kind of euler problems,
> to analyse tables of results for patterns.
> 
>>
>>- anton
> 
> Groetjes Albert

One interesting aspect for sorting the Dictionary that was presented at one 
of the EuroForth's was to add another linkage into the header that could 
contain the sequence number for its sorted order. Only this field got sorted 
and the rest of the body stayed put. Seemed quite a neat solution, 
especially if you wanted an alphabetically ordered dictionary listing.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [prev] | [next] | [standalone]

#34433

In article <ccqacoFl667U1@mid.individual.net>,
Paul E Bennett  <Paul_E.Bennett@topmail.co.uk> wrote:
>Albert van der Horst wrote:
>
>> In article <2014Nov15.172155@mips.complang.tuwien.ac.at>,
>>
>> I had the problem of sorting a glossary, first by chapter then by
>> wordname. This I had solved by a c++ program (my first actually: 1994).
>> It specifies records and fields by regular expressions.
>> This was because I didn't know how to solve that sorting problem in some
>> other way. This general purpose full featured 10 kg sledgehammer has
>> served me nicely, and I recently made it to compile again to a 64 bit
>> version, after using the unaltered program till my 90 MHz Pentium broke
>> down. It is instrumental in generating the ciforth documentation.
>>
>>
>> Groetjes Albert
>
>One interesting aspect for sorting the Dictionary that was presented at one
>of the EuroForth's was to add another linkage into the header that could
>contain the sequence number for its sorted order. Only this field got sorted
>and the rest of the body stayed put. Seemed quite a neat solution,
>especially if you wanted an alphabetically ordered dictionary listing.

An alphabetical index is all but mandatory.

This is a piece of the alphabetized links in ci86.lina.html
"
... DLITERAL DNEGATE DOES> DO DPL DP DROP DSP! DSP@ DUP ELSE EMIT
EMPTY-BUFFERS EM ENVIRONMENT? ENVIRONMENT ERASE ERROR ERRSCR ETYPE
EVALUATE EXECUTE EXIT-CODE EXIT FAR! FAR@ FARMOVE FENCE FILL FIND FLD
FLUSH FM/MOD FOR-VOCS FOR-WORDS FORGET-VOC FORGET FORTH FORWARD) FOUND
GET-FILE HANDLER HEADER HERE HEX HIDDEN HLD HOLD ID. IF IMMEDIATE
INCLUDED INDEX INIT INTERPRET INVERT I J KEY? KEY LATEST LEAVE LINK
LIST LITERAL LIT LOAD LOCK LOOP LSHIFT L_>IN M* M/MOD MAX MESSAGE ...
"
For a small Forth this is practical.

But what you also want is wordsets, like so.

"
Here you can select the description of a Wordsets: small sets of words
that work together. These are intended to give more insight in how to
use the words in cooperation.

Note: the first reference under `see also' of a word is the wordset to
which it belongs.

BLOCKS COMPILING CONTROL DEFINING DENOTATIONS DICTIONARY DOUBLE
ENVIRONMENTS ERRORS FILES FORMATTING INITIALISATIONS INPUT JUGGLING
LIBRARY LOGIC MEMORY MISC MULTIPLYING OPERATINGSYSTEM OPERATOR OUTPUT
PARSING SCREEN SECURITY STACKS STRING SUPERFLUOUS WORDLISTS
"

If you have read the wordset description of e.g. STRINGS once
hopefully you have an impression the next time what kind of words are
in there.

This is what is there for BLOCKS:
"
WORDSET BLOCKS
# OVERVIEW OF BLOCKS
# #BUFF
# -->
# ?DISK-ERROR
# B/BUF
# BLOCK-EXIT
# BLOCK-FILE
# BLOCK-HANDLE
# BLOCK-INIT
# BLOCK-READ
# BLOCK-WRITE
# BLOCK
# DISK-ERROR
# EMPTY-BUFFERS
# UPDATE
# (BUFFER)
# +BUF
# BLOCK-SEEK
# FLUSH
# OFFSET
# _FIRST
# _LIMIT
# _PREV
"

This is what you see if you click on "OVERVIEW OF BLOCKS"
"
OVERVIEW:

The block mechanism connects to the Forth system a single background
storage divided in numbered blocks. The wordset BLOCKS contains words
to input and output to this mass storage. In this ciforth blocks
reside in a file, by default named ``forth.lab''. . Most blocks are
used for the SCREEN facility, where each block contains source code.
"
************************************************************************
* Without this context those words could be really hard to understand. *
* Furthermore in a large dictionary those words become isolated, even  *
* when you have the context.                                           *
************************************************************************

Now next time you can decide to always ignore this wordset.
Or you could look what the SCREEN wordset is all about.

This is what you see if you click on "EMPTY-BUFFERS"
"
EMPTY-BUFFERS

STACKEFFECT:

DESCRIPTION:

Mark all block-buffers as empty. Updated blocks are not written to the
disc. This is an initialization proceedure before first use of the
disc. The usage as an ``undo'' is infeasible in ciforth.

GLOSSARY INDEX

SEE ALSO: BLOCKS   FLUSH   BLOCK   SCREEN   UPDATE

"
The clickable association through SEE ALSO is very important.
(and I must say, in my documentation it could be improved,
but in this case it is pretty spot on.)

Now if I decide --like in going from 5.1 to 5.2 -- that IN[] should
be renamed into PP@@ , I can rename it in the one generic source file
and it goes into the pdf/info/html documentation of mina/wina/lina32/lina64
at the right alphabetic place. It is a similar small change to move
a word to another wordset.

>
>--
>********************************************************************
>Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
>Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
>Mob: +44 (0)7811-639972
>Tel: +44 (0)1235-510979
>Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
>********************************************************************
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#34336

Anton Ertl wrote:

[%X]

> Sure, there are also cases where a simple solution is more flexible
> than, say, a solution that is tightly optimized for a specific
> application szenario; but in this example there is a third issue at
> work that apparently took precedence over simplicity and flexibility.
> Nobody will choose a complex and inflexible solution if they see a
> simple and flexible one, unless the complex and inflexible solution
> gives another, more important benefit.

Taking a complex problem space and decomposition of that complex problem 
space into smaller, less complex problems (and continuing in that vein until 
you have a collection of simple problems to solve) is a divide and conquer 
regime that has worked in many other engineering and craft disciplines to 
great success. What you end up with, having solved all those simple small 
problems, is a collection of solution components that you just have to 
assemble together as a collective. I have referred to such a strategy as a 
"Component Oriented" method and it has a great many benefits, including 
flexibility.

Take a construction solution like Mecanno or Lego. These are extremely 
simple components, yet they have been assembled into some of the most 
interestingly complex constructions, yet retain the flexibilit of the 
individual component.

Forth is very well placed to be the Mecanno or Lego of the Software World if 
you think about it in Component Oriented terms. Each individual word can 
also be fully certified to conform to its specification (if you had written 
your requirements for the word first in the style of its glossary entry). 

As to the original question. All I ask is "What Paradox?" Naturally, you 
have to decompose and resolve the natural architecture of the problem space 
into the solution space without making the smaller components too difficult 
to fully understand. It takes some effort to get the simplest and most 
elegant solutions but that effort is worth it.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [prev] | [next] | [standalone]

#34333

'We can't divide by zero. - Perhaps, with Forth we can?' :) This kind of self-complacency brings absolutely nothing, except of wasted time. 

[toc] | [prev] | [next] | [standalone]

#34338

On Thu, 06 Nov 2014 11:26:22 -0500, Ilya Tarasov  
<ilya74.tarasov@gmail.com> wrote:

> 'We can't divide by zero. - Perhaps, with Forth we can?' :) This kind of  
> self-complacency brings absolutely nothing, except of wasted time.

Well, mathematicians are fond of "proving" that .999 repeating is *equal*
to one.  This is *instead* of them proving the _limit_ of .999 repeating
approaches one as the decimal places approach infinity, via a Taylor  
series.
By their faulty logic, we can also "prove" zero is just 1 over X as X's
value approaches infinity.  Therefore, anything divided by zero is
divided by one and multiplied by infinity, i.e., infinity.  This is
just division by a complex fraction.  So, yes, you could check for
zero with division operations in Forth and return the cloeset value
to infinity that your Forth can represent, i.e., the maximum integer
or maximum float.


Rod Pemberton

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web