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 1 of 2  [1] 2  Next page →

#34314 — Does Forth solve the paradox?

This article brought to mind Chuck's continual emphasis on the importance of 
simplicity.

http://www.informit.com/articles/article.aspx?p=1963779

Perhaps this is another good refutation of the argument frequently leveled against 
Forth: that simplicity doesn't matter that much anymore because we have 
oodles of cheap memory and processor power available. It seems like the 
conventional software world is still struggling in spite of it's vast resources.

[toc] | [next] | [standalone]

#34316

In article <6f36e5e5-037c-41e2-89c5-2bc11937ddcd@googlegroups.com>,
 <forthisit@gmail.com> wrote:
>This article brought to mind Chuck's continual emphasis on the importance of
>simplicity.
>
>http://www.informit.com/articles/article.aspx?p=1963779
>
>Perhaps this is another good refutation of the argument frequently
>leveled against
>Forth: that simplicity doesn't matter that much anymore because we have
>oodles of cheap memory and processor power available. It seems like the
>conventional software world is still struggling in spite of it's vast resources.

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.
So I read some books and revamped. So there.

This article merits no detailed analysis. But in the spirit of
Halloween I'll drive a wooden stake through the heart.

Flexibility breeds complexity?

No!

Simplicity breads flexibility.


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]

#34317

On 11/5/14 9:45 AM, Albert van der Horst wrote:
> In article <6f36e5e5-037c-41e2-89c5-2bc11937ddcd@googlegroups.com>,
>   <forthisit@gmail.com> wrote:
>> This article brought to mind Chuck's continual emphasis on the importance of
>> simplicity.
>>
>> http://www.informit.com/articles/article.aspx?p=1963779
>>
>> Perhaps this is another good refutation of the argument frequently
>> leveled against
>> Forth: that simplicity doesn't matter that much anymore because we have
>> oodles of cheap memory and processor power available. It seems like the
>> conventional software world is still struggling in spite of it's vast resources.
>
> 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.
> So I read some books and revamped. So there.
>
> This article merits no detailed analysis. But in the spirit of
> Halloween I'll drive a wooden stake through the heart.
>
> Flexibility breeds complexity?
>
> No!
>
> Simplicity breads flexibility.

Love it. The article is hugely overgeneralizing.

I am reminded of some Fortran libraries I worked with many years ago. 
Typically each was many pages long, and had a dozen or so parameters in 
the calling sequence. Inside, it would test some of the parameters to 
determine which of half-a-dozen algorithms would be used, the precision 
to be used, the units of the input, the units of the output, and maybe 
other stuff. So, the majority of the code was a tortured mass of tangled 
logic trying to figure out what to do based on all those choices. 
Precisely what the article calls "composing coarse-grained entities from 
fine-grained entities." Blech.

The Forth approach, of course, would just be to have a word for each 
algorithm/resolution, and you call the one you want. Your program 
doesn't even need to load the ones it isn't using.

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]

#34318

"Elizabeth D. Rather" <erather@forth.com> writes:
> some Fortran libraries ... would test some of the parameters to
> determine which of half-a-dozen algorithms would be used, the
> precision to be used...  The Forth approach, of course, would just be
> to have a word for each algorithm/resolution, and you call the one you
> want. Your program doesn't even need to load the ones it isn't using.

You're saying that the Fortran program did algorithm selection
automatically where the Forth approach is to shift that burden over to
the user.  I can understand that the Forth approach is easier for the
implementer, but really, the point of software is to transfer work away
from humans and onto computers.  So The Forth approach's main benefit
seems to be reaching a compromise that may be more economically
efficient than the Fortran approach in a given situation.  That can be
valuable, but it's not a reason to dismiss the value of having the
machine do more of the work instead of the human, when it's feasible to
do so.

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

#34320

On 11/5/14 12:04 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> some Fortran libraries ... would test some of the parameters to
>> determine which of half-a-dozen algorithms would be used, the
>> precision to be used...  The Forth approach, of course, would just be
>> to have a word for each algorithm/resolution, and you call the one you
>> want. Your program doesn't even need to load the ones it isn't using.
>
> You're saying that the Fortran program did algorithm selection
> automatically where the Forth approach is to shift that burden over to
> the user.  I can understand that the Forth approach is easier for the
> implementer, but really, the point of software is to transfer work away
> from humans and onto computers.  So The Forth approach's main benefit
> seems to be reaching a compromise that may be more economically
> efficient than the Fortran approach in a given situation.  That can be
> valuable, but it's not a reason to dismiss the value of having the
> machine do more of the work instead of the human, when it's feasible to
> do so.
>

Actually, no. The Fortran program left the burden to the user, who 
specified everything in terms of selection parameters to this massive, 
hairy piece of code.

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]

#34321

On 11/5/2014 5:49 PM, Elizabeth D. Rather wrote:
> On 11/5/14 12:04 PM, Paul Rubin wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> some Fortran libraries ... would test some of the parameters to
>>> determine which of half-a-dozen algorithms would be used, the
>>> precision to be used...  The Forth approach, of course, would just be
>>> to have a word for each algorithm/resolution, and you call the one you
>>> want. Your program doesn't even need to load the ones it isn't using.
>>
>> You're saying that the Fortran program did algorithm selection
>> automatically where the Forth approach is to shift that burden over to
>> the user.  I can understand that the Forth approach is easier for the
>> implementer, but really, the point of software is to transfer work away
>> from humans and onto computers.  So The Forth approach's main benefit
>> seems to be reaching a compromise that may be more economically
>> efficient than the Fortran approach in a given situation.  That can be
>> valuable, but it's not a reason to dismiss the value of having the
>> machine do more of the work instead of the human, when it's feasible to
>> do so.
>>
>
> Actually, no. The Fortran program left the burden to the user, who
> specified everything in terms of selection parameters to this massive,
> hairy piece of code.

There is lots of bad code running around.  That doesn't make Fortran a 
bad language.  A lot of bad code has been written in Forth I am sure.

-- 

Rick

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

#34322

On 11/5/14 1:13 PM, rickman wrote:
> On 11/5/2014 5:49 PM, Elizabeth D. Rather wrote:
>> On 11/5/14 12:04 PM, Paul Rubin wrote:
>>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>>> some Fortran libraries ... would test some of the parameters to
>>>> determine which of half-a-dozen algorithms would be used, the
>>>> precision to be used...  The Forth approach, of course, would just be
>>>> to have a word for each algorithm/resolution, and you call the one you
>>>> want. Your program doesn't even need to load the ones it isn't using.
>>>
>>> You're saying that the Fortran program did algorithm selection
>>> automatically where the Forth approach is to shift that burden over to
>>> the user.  I can understand that the Forth approach is easier for the
>>> implementer, but really, the point of software is to transfer work away
>>> from humans and onto computers.  So The Forth approach's main benefit
>>> seems to be reaching a compromise that may be more economically
>>> efficient than the Fortran approach in a given situation.  That can be
>>> valuable, but it's not a reason to dismiss the value of having the
>>> machine do more of the work instead of the human, when it's feasible to
>>> do so.
>>>
>>
>> Actually, no. The Fortran program left the burden to the user, who
>> specified everything in terms of selection parameters to this massive,
>> hairy piece of code.
>
> There is lots of bad code running around.  That doesn't make Fortran a
> bad language.  A lot of bad code has been written in Forth I am sure.
>

I wasn't accusing Fortran of being a bad language. It's an ok language, 
but a lot of Fortran coding style is bad. I was mainly talking about the 
style of programming, which seemed to be the topic of the article.

COBOL is a bad language.

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]

#34327

In article <m3eavd$hbd$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>
>There is lots of bad code running around.  That doesn't make Fortran a
>bad language.  A lot of bad code has been written in Forth I am sure.

You're right. The bad code doesn't make FORTRAN a bad language.
It is a bad language all by itself.

>
>--
>
>Rick
-- 
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]

#34324

On Wednesday, November 5, 2014 2:49:15 PM UTC-8, Elizabeth D. Rather wrote:
> On 11/5/14 12:04 PM, Paul Rubin wrote:
> > "Elizabeth D. Rather" <erather@forth.com> writes:
> >> some Fortran libraries ... would test some of the parameters to
> >> determine which of half-a-dozen algorithms would be used, the
> >> precision to be used...  The Forth approach, of course, would just be
> >> to have a word for each algorithm/resolution, and you call the one you
> >> want. Your program doesn't even need to load the ones it isn't using.
> >
> > You're saying that the Fortran program did algorithm selection
> > automatically where the Forth approach is to shift that burden over to
> > the user.  I can understand that the Forth approach is easier for the
> > implementer, but really, the point of software is to transfer work away
> > from humans and onto computers.  So The Forth approach's main benefit
> > seems to be reaching a compromise that may be more economically
> > efficient than the Fortran approach in a given situation.  That can be
> > valuable, but it's not a reason to dismiss the value of having the
> > machine do more of the work instead of the human, when it's feasible to
> > do so.
> >
> 
> Actually, no. The Fortran program left the burden to the user, who 
> specified everything in terms of selection parameters to this massive, 
> hairy piece of code.
> 
> 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."
> ==================================================

Any chance some schools adopt gforth or pfe as teaching language?
Then perhaps a grant for forth webserver development.
I hope business is going well for forth inc.
cheers

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

#34325

"Elizabeth D. Rather" <erather@forth.com> writes:
> Actually, no. The Fortran program left the burden to the user, who
> specified everything in terms of selection parameters to this massive,
> hairy piece of code.

I see.  So the Fortran program used its parameter set as a kind of DSL
to let the user select the algorithm.  I guess the usefulness of that
approach depends on the application and how well the DSL is designed.  I
could imagine that the approach itself resulted from wanting to compile
the Fortran program once ahead of time, then let the algorithms be
selected by runtime data, and that Forth's traditionally very fast
compilation speed decreases the usefulness of ahead-of-time compilation.

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

#34328

On Wednesday, November 5, 2014 9:43:30 PM UTC+1, Elizabeth D. Rather wrote:
[..]
> I am reminded of some Fortran libraries I worked with many years ago. 
> Typically each was many pages long, and had a dozen or so parameters in 
> the calling sequence. Inside, it would test some of the parameters to 
> determine which of half-a-dozen algorithms would be used, the precision 
> to be used, the units of the input, the units of the output, and maybe 
> other stuff. So, the majority of the code was a tortured mass of tangled 
> logic trying to figure out what to do based on all those choices. 
> Precisely what the article calls "composing coarse-grained entities from 
> fine-grained entities." Blech.

Your remark is applicable to e.g. Lapack. There are, however two sides to this argument, centering around 'trust.'

LaPack contains low-level subroutines (e.g. for eigenvalue computation), but also very high-level 'driver' routines. These driver routines (which probably are the ones your 'blech' is aimed at) contain the domain knowledge of many numerical experts accumulated over many years. In Forth we typically have a plethora of sterling low-level routines (e.g. 20 different sorts), but nobody knows precisely under which conditions to use a particular one. When a sort is used, typically it is indeed best for the particular case (because of Forth's rapid test environment) but it is not documented why and the knowledge is not abstracted / saved in a library for later use by others.

In case it does get packed into a library, most Forthers will 'distrust' the prepackaged tools and roll their own. Up to now, in most cases with very good results :-) The question is if we should rely more on the experts or on the testers?

With Fortran (and other things) there is often no 'universal truth'. E.g. drivers that optimize for particular hardware limitations must be updated very regularly. This will only happen if the big libraries are actively maintained. In my opinion (and experience), for engineering purposes the testing approach wins. Never trust a dusty deck.

-marcel

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

#34330

m.a.m.hendrix@tue.nl writes:
>In case it does get packed into a library, most Forthers will 'distrust' th=
>e prepackaged tools and roll their own. Up to now, in most cases with very =
>good results :-) The question is if we should rely more on the experts or o=
>n the testers?

What the experts sometimes do is to write a program to do the
measuring and selection automatically (auto-tuning or self-tuning).
E.g., FFTW and ATLAS
(http://en.wikipedia.org/wiki/Automatically_Tuned_Linear_Algebra_Software).

Of course that is additional complexity, so it's probably not Chuck
Moore's way.

- 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]

#34331

On Thursday, November 6, 2014 12:52:46 PM UTC+1, Anton Ertl wrote:
> m.a.m.hendrix@tue.nl writes:
> >In case it does get packed into a library, most Forthers will 'distrust' the
> >prepackaged tools and roll their own. Up to now, in most cases with very 
> >good results :-) The question is if we should rely more on the experts or 
> >on the testers?
> 
> What the experts sometimes do is to write a program to do the
> measuring and selection automatically (auto-tuning or self-tuning).
> E.g., FFTW and ATLAS
> (http://en.wikipedia.org/wiki/Automatically_Tuned_Linear_Algebra_Software).
> 
> Of course that is additional complexity, so it's probably not Chuck
> Moore's way.

That's a good point, but I think ATLAS only tunes at install/compile time (so our modern pre-packaged Linuxes don't benefit). FFTW maintains some kind of wizard database at run-time, but I don't remember the details.

-marcel

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

#34334

m.a.m.hendrix@tue.nl writes:
>On Thursday, November 6, 2014 12:52:46 PM UTC+1, Anton Ertl wrote:
>> What the experts sometimes do is to write a program to do the
>> measuring and selection automatically (auto-tuning or self-tuning).
>> E.g., FFTW and ATLAS
>> (http://en.wikipedia.org/wiki/Automatically_Tuned_Linear_Algebra_Software).
...
>That's a good point, but I think ATLAS only tunes at install/compile time (so our modern pre-packaged Linuxes don't benefit).

Tough luck on the users of such Linux distributions, but far from
optimal performance seems to be their way; e.g., Debian has disabled
dynamic superinstructions in Gforth by default on all platforms since
forever (slowdown by a factor of 2), because at one time that was a
workaround for a bug on one platform.

Anyway, people who distribute software as source code, particularly
those who distribute scientific software normally design it for people
who install it from source code.  If someone else divides the
installation step into several stages, it's those people's job to
divide it correctly.

- 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]

#34319

On 11/5/2014 2:45 PM, Albert van der Horst wrote:
> In article <6f36e5e5-037c-41e2-89c5-2bc11937ddcd@googlegroups.com>,
>   <forthisit@gmail.com> wrote:
>> This article brought to mind Chuck's continual emphasis on the importance of
>> simplicity.
>>
>> http://www.informit.com/articles/article.aspx?p=1963779
>>
>> Perhaps this is another good refutation of the argument frequently
>> leveled against
>> Forth: that simplicity doesn't matter that much anymore because we have
>> oodles of cheap memory and processor power available. It seems like the
>> conventional software world is still struggling in spite of it's vast resources.
>
> 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.
> So I read some books and revamped. So there.
>
> This article merits no detailed analysis. But in the spirit of
> Halloween I'll drive a wooden stake through the heart.
>
> Flexibility breeds complexity?
>
> No!
>
> Simplicity breads flexibility.

Four legs good, two legs bad!  What?

-- 

Rick

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

#34323

On Wednesday, November 5, 2014 11:46:01 AM UTC-8, Albert van der Horst wrote:
> In article <6f36e5e5-037c-41e2-89c5-2bc11937ddcd@googlegroups.com>,
>  <forthisit@gmail.com> wrote:
> >This article brought to mind Chuck's continual emphasis on the importance of
> >simplicity.
> >
> >http://www.informit.com/articles/article.aspx?p=1963779
> >
> >Perhaps this is another good refutation of the argument frequently
> >leveled against
> >Forth: that simplicity doesn't matter that much anymore because we have
> >oodles of cheap memory and processor power available. It seems like the
> >conventional software world is still struggling in spite of it's vast resources.
> 
> 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.
> So I read some books and revamped. So there.
> 
> This article merits no detailed analysis. But in the spirit of
> Halloween I'll drive a wooden stake through the heart.
> 
> Flexibility breeds complexity?
> 
> No!
> 
> Simplicity breads flexibility.
> 
> 
> 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

Hows life in the netherlands?

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

#34326

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.

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.

- 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]

#34329

On Thursday, 6 November 2014 09:38:28 UTC, Anton Ertl  wrote:
> 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.

Unless you're a project manager; in which case it allows you
to hire more people, command a larger budget, and gain schedule
extensions ;-)

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

#34332

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 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.

"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.

Andrew.

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

#34335

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.

On the other hand it is extremely flexible. One moment it is a metronome.
The next moment it is a guitar tuner. Next moment it is a free cell
game. Next moment it is film projector. Next moment it is a film camera.
And yes it can be a g-forth too.

So I repeat: simplicity breeds flexibility.

Where is the paradox? Why does a metronome program hinders gForth
"long-term survival"?

>
>Andrew.
-- 
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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web