🚀 go-pugleaf

On Tue, 29 May 2018 18:07:49 -0400, Andreas Kohlbach
<a...@spamfence.net> wrote:

>On Mon, 28 May 2018 22:29:15 -0500, Jon Elson wrote:
>>
>> Andreas Kohlbach wrote:
>>
>>> I found this IMO interesting video about the birth of BASIC on
>>> YouTube. It also shows some old IBM and other machines used back in the
>>> 1960s.
>>> 
>>> https://www.youtube.com/watch?v=WYPNjSoDrqw
>> First picture is John von Neuman (horribly mispelled in subtitles) standing 
>> to the side of the IAS computer, with its rows of Williams tubes.  All 
>> vacuum tubes, built from 1946 - 1951 in Princeton, NJ.  Now at the 
>> Smithsonian.
>
>Ignore the automated created subtitles. They even say ARGOR when AEGOL
>was meant.

I'm pretty sure that ALGOL was meant.

On 2018-05-29, J  Clarke <jclarke...@gmail.com> wrote:

> On Tue, 29 May 2018 18:07:49 -0400, Andreas Kohlbach
> <a...@spamfence.net> wrote:
>
>> On Mon, 28 May 2018 22:29:15 -0500, Jon Elson wrote:
>>
>>> Andreas Kohlbach wrote:
>>>
>>>> I found this IMO interesting video about the birth of BASIC on
>>>> YouTube. It also shows some old IBM and other machines used back in the
>>>> 1960s.
>>>> 
>>>> https://www.youtube.com/watch?v=WYPNjSoDrqw
>>>
>>> First picture is John von Neuman (horribly mispelled in subtitles) standing 
>>> to the side of the IAS computer, with its rows of Williams tubes.  All 
>>> vacuum tubes, built from 1946 - 1951 in Princeton, NJ.  Now at the 
>>> Smithsonian.
>>
>> Ignore the automated created subtitles. They even say ARGOR when AEGOL
>> was meant.
>
> I'm pretty sure that ALGOL was meant.

Cascading typos.  :-)

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

On Sun, 27 May 2018 18:12:01 -0400, Andreas Kohlbach wrote:

> I found this IMO interesting video about the birth of BASIC on YouTube.
> It also shows some old IBM and other machines used back in the 1960s.
> 
> https://www.youtube.com/watch?v=WYPNjSoDrqw
> 
> I enjoyed watching it.

I learned BASIC in 1971. Our textbook was the one by Kemeny and Kurtz.



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

On 31/05/2018 17:37, Bob Eager wrote:
> On Sun, 27 May 2018 18:12:01 -0400, Andreas Kohlbach wrote:
> 
>> I found this IMO interesting video about the birth of BASIC on YouTube.
>> It also shows some old IBM and other machines used back in the 1960s.
>>
>> https://www.youtube.com/watch?v=WYPNjSoDrqw
>>
>> I enjoyed watching it.
> 
> I learned BASIC in 1971. Our textbook was the one by Kemeny and Kurtz.
> 
> 
> 

I did my 3rd year engineering assignments in 1972 in BASIC on
the teletypes of the PDP10 at Essex Uni, when we were all expected
to do it in FORTRAN as had been taught  :-)

On Thu, 31 May 2018 17:56:45 +0100, Gareth's Downstairs Computer wrote:
>
> On 31/05/2018 17:37, Bob Eager wrote:
>>
>> I learned BASIC in 1971. Our textbook was the one by Kemeny and Kurtz.
>
> I did my 3rd year engineering assignments in 1972 in BASIC on
> the teletypes of the PDP10 at Essex Uni, when we were all expected
> to do it in FORTRAN as had been taught  :-)

Am probably too young. I first came in contact with BASIC when I had the
Commodore 64 around 1983.
-- 
Andreas

https://www.youtube.com/watch?v=ptoGMcls9RM

On Thu, 31 May 2018 17:12:57 -0400, Andreas Kohlbach
<a...@spamfence.net> wrote:

>On Thu, 31 May 2018 17:56:45 +0100, Gareth's Downstairs Computer wrote:
>>
>> On 31/05/2018 17:37, Bob Eager wrote:
>>>
>>> I learned BASIC in 1971. Our textbook was the one by Kemeny and Kurtz.
>>
>> I did my 3rd year engineering assignments in 1972 in BASIC on
>> the teletypes of the PDP10 at Essex Uni, when we were all expected
>> to do it in FORTRAN as had been taught  :-)
>
>Am probably too young. I first came in contact with BASIC when I had the
>Commodore 64 around 1983.

It was available on the mainframe at UofF in 1973 when I had my first
exposure to computers, but we also had APL, so BASIC kind of
languished.

On Thursday, May 31, 2018 at 5:11:01 PM UTC-4, Andreas Kohlbach wrote:

> > Nice program.  I particularly like the way they briefly mention
> > Bill Gates only to point out that they were there first.
> 
> The first to commercialize on BASIC. Without BASIC and the MITS 8800
> there might not be a Microsoft company today. Would be interesting to
> know if CP/M then would have lead the market well into the 1990s and
> beyond with GEM becoming the GUI of choice and Gary if Kildall would
> still be alive, not going to this bar and had this fight leading to his
> death...


I believe Gates and his friends were doing commercial work before
they did the BASIC compiler.  So, I strongly suspect Gates still
would have developed a major software company.

On Thursday, May 31, 2018 at 7:25:24 PM UTC-4, J. Clarke wrote:

> It was available on the mainframe at UofF in 1973 when I had my first
> exposure to computers, but we also had APL, so BASIC kind of
> languished.

BASIC timesharing was an excellent language, especially as HP and
others expanded it in the 1970s, but it was still looked down
upon by serious programmers.  "Real programmers" were supposed
to use Fortran or assembler in that era.  APL was credible, too.

In the business world, away from academia, COBOL was popular.
For the newly developed IBM System/3, RPG II was popular.

hanc...@bbs.cpcn.com writes:

> On Thursday, May 31, 2018 at 5:11:01 PM UTC-4, Andreas Kohlbach wrote:

>>> Nice program.  I particularly like the way they briefly mention
>>> Bill Gates only to point out that they were there first.

>> The first to commercialize on BASIC. Without BASIC and the MITS 8800
>> there might not be a Microsoft company today. Would be interesting to
>> know if CP/M then would have lead the market well into the 1990s and
>> beyond with GEM becoming the GUI of choice and Gary if Kildall would
>> still be alive, not going to this bar and had this fight leading to his
>> death...

> I believe Gates and his friends were doing commercial work before
> they did the BASIC compiler.  So, I strongly suspect Gates still
> would have developed a major software company.

No, they weren't.  Read Paul's book.

Paul and Bill did have 1 attempt at a company prior to the advent of the Altair
8800:  Traf-o-Data was a side-of-the-road traffic counter (now commonplace, but
at the time unheard of) based on the 8008 processor.  Because they did not have
a development system for the 8008, Paul wrote a simulator for the processor in
Macro-10 (PDP-10 assembler) which represented 8008 instructions as the address
portion of LUUOs[1].

Paul and Bill always wanted to write a BASIC for a microprocessor, but could
not find one powerful enough until the 8080 came along.  Paul revised the 8008
simulator for the 8080, and that was what they used to produce the first BASIC.
Variants were used at Microsoft for the next 15 years to produce all the micro
versions of BASIC which they sold; Microsoft was a PDP-10 shop until PCs were
capable of self-hosting.

DISCLAIMER:  I worked[2] for Paul Allen, and was one of the team proofreading
his autobiography.  My name appears in the Acknowledgments to _Idea Man_.

[1] UUOs are instructions which trap as unimplemented in the PDP-10
    architecture.  The important ones are the Monitor UUOs (MUUOs), opcodes
    040-077, which provide the system call API for Tops-10 and derivatives and
    for ITS, and the Local UUOs, opcodes 001-037, which trap into the user
    program's address space, so that a handler can be written for them.  That's
    what the simulator did.

[2] I still work for the same museum, founded by Paul Allen, with which I've
    been associated for the last 15 years.  We've been spun off as a separate
    company instead of being a department of his holding company Vulcan, Inc.
    Since my paychecks no longer say "Vulcan, Inc." but "Living Computers", I
    no longer feel it appropriate to say "I work for Paul Allen".

-- 
Rich Alderson					  ne...@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

hanc...@bbs.cpcn.com writes:

> In the business world, away from academia, COBOL was popular.
> For the newly developed IBM System/3, RPG II was popular.

RPG III.  RPG II was the System/360 implementation.

-- 
Rich Alderson					  ne...@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

On Fri, 1 Jun 2018 11:03:38 -0700 (PDT), hanc...@bbs.cpcn.com wrote:
>
> On Thursday, May 31, 2018 at 5:11:01 PM UTC-4, Andreas Kohlbach wrote:
>
>> > Nice program.  I particularly like the way they briefly mention
>> > Bill Gates only to point out that they were there first.
>> 
>> The first to commercialize on BASIC. Without BASIC and the MITS 8800
>> there might not be a Microsoft company today. Would be interesting to
>> know if CP/M then would have lead the market well into the 1990s and
>> beyond with GEM becoming the GUI of choice and Gary if Kildall would
>> still be alive, not going to this bar and had this fight leading to his
>> death...
>
>
> I believe Gates and his friends were doing commercial work before
> they did the BASIC compiler.  So, I strongly suspect Gates still
> would have developed a major software company.

Gates and Allen previously were involved in traffic analysis for
cars. They had a company "Trafo-Data", Google for it. Once Allan
discovered the Popular Electronics issue about the MITS 8800 they offered
to produce an "operating system" including BASIC. And that kicked off
Microsoft's success.
-- 
Andreas

My random toughts and comments
https://news-commentaries.blogspot.com/

<hanc...@bbs.cpcn.com> wrote:
> On Thursday, May 31, 2018 at 7:25:24 PM UTC-4, J. Clarke wrote:
> 
>> It was available on the mainframe at UofF in 1973 when I had my first
>> exposure to computers, but we also had APL, so BASIC kind of
>> languished.
> 
> BASIC timesharing was an excellent language, especially as HP and
> others expanded it in the 1970s, but it was still looked down
> upon by serious programmers.  "Real programmers" were supposed
> to use Fortran or assembler in that era.  APL was credible, too.

I always thought of BASIC as "poor man's FORTRAN."

-- 
Pete

Rich Alderson <ne...@alderson.users.panix.com> wrote:
> hanc...@bbs.cpcn.com writes:
> 
>> On Thursday, May 31, 2018 at 5:11:01 PM UTC-4, Andreas Kohlbach wrote:
> 
>>>> Nice program.  I particularly like the way they briefly mention
>>>> Bill Gates only to point out that they were there first.
> 
>>> The first to commercialize on BASIC. Without BASIC and the MITS 8800
>>> there might not be a Microsoft company today. Would be interesting to
>>> know if CP/M then would have lead the market well into the 1990s and
>>> beyond with GEM becoming the GUI of choice and Gary if Kildall would
>>> still be alive, not going to this bar and had this fight leading to his
>>> death...
> 
>> I believe Gates and his friends were doing commercial work before
>> they did the BASIC compiler.  So, I strongly suspect Gates still
>> would have developed a major software company.
> 
> No, they weren't.  Read Paul's book.
> 
> Paul and Bill did have 1 attempt at a company prior to the advent of the Altair
> 8800:  Traf-o-Data was a side-of-the-road traffic counter (now commonplace, but
> at the time unheard of) based on the 8008 processor.  Because they did not have
> a development system for the 8008, Paul wrote a simulator for the processor in
> Macro-10 (PDP-10 assembler) which represented 8008 instructions as the address
> portion of LUUOs[1].

Wow, thats a whole lotta overhead! All the cost of handling an interrupt
for *every instruction.*

-- 
Pete

On 6/1/2018 3:22 PM, Rich Alderson wrote:
> hanc...@bbs.cpcn.com writes:
> 
>> On Thursday, May 31, 2018 at 5:11:01 PM UTC-4, Andreas Kohlbach wrote:
> 
>>>> Nice program.  I particularly like the way they briefly mention
>>>> Bill Gates only to point out that they were there first.
> 
>>> The first to commercialize on BASIC. Without BASIC and the MITS 8800
>>> there might not be a Microsoft company today. Would be interesting to
>>> know if CP/M then would have lead the market well into the 1990s and
>>> beyond with GEM becoming the GUI of choice and Gary if Kildall would
>>> still be alive, not going to this bar and had this fight leading to his
>>> death...
> 
>> I believe Gates and his friends were doing commercial work before
>> they did the BASIC compiler.  So, I strongly suspect Gates still
>> would have developed a major software company.
> 
> No, they weren't.  Read Paul's book.
> 
> Paul and Bill did have 1 attempt at a company prior to the advent of the Altair
> 8800:  Traf-o-Data was a side-of-the-road traffic counter (now commonplace, but
> at the time unheard of) based on the 8008 processor.  Because they did not have
> a development system for the 8008, Paul wrote a simulator for the processor in
> Macro-10 (PDP-10 assembler) which represented 8008 instructions as the address
> portion of LUUOs[1].
> 

Now wait...  I read somewhere that Gates and Allen worked on weekends at 
some Seattle company when the the two guys were still in high school or 
junior high.  At this company the two got good looks at the PDP-10 
source code for compilers and editors... including a Dec BASIC.  ISTM 
that the two were paid something like $2 per hour.

I read _Idea Man_, but I'm not sure where I read about the above.  _Idea 
Man_ was written so much better that Walter Isaacson's biography of 
Steve Jobs, which I also read.  (IMO)


-- 
numerist at aquaporin4 dot com

On 01/06/2018 22:57, Peter Flass wrote:
> <hanc...@bbs.cpcn.com> wrote:
>> On Thursday, May 31, 2018 at 7:25:24 PM UTC-4, J. Clarke wrote:
>>
>>> It was available on the mainframe at UofF in 1973 when I had my first
>>> exposure to computers, but we also had APL, so BASIC kind of
>>> languished.
>>
>> BASIC timesharing was an excellent language, especially as HP and
>> others expanded it in the 1970s, but it was still looked down
>> upon by serious programmers.  "Real programmers" were supposed
>> to use Fortran or assembler in that era.  APL was credible, too.
> 
> I always thought of BASIC as "poor man's FORTRAN."
> 

The writers of BASIC obviously knew FORTRAN. They chose GOTOs over blocks.

On 6/1/2018 4:57 PM, Peter Flass wrote:
> <hanc...@bbs.cpcn.com> wrote:
>> On Thursday, May 31, 2018 at 7:25:24 PM UTC-4, J. Clarke wrote:
>>
>>> It was available on the mainframe at UofF in 1973 when I had my first
>>> exposure to computers, but we also had APL, so BASIC kind of
>>> languished.
>>
>> BASIC timesharing was an excellent language, especially as HP and
>> others expanded it in the 1970s, but it was still looked down
>> upon by serious programmers.  "Real programmers" were supposed
>> to use Fortran or assembler in that era.  APL was credible, too.
> 
> I always thought of BASIC as "poor man's FORTRAN."
> 

I learned Fortran II in 1965, and BASIC in the early 1980s. BASIC 
always felt like a dialect of Fortran (that could handle strings 
decently) to me.

On Saturday, June 2, 2018 at 2:39:59 PM UTC-4, Dave Garland wrote:

> > I always thought of BASIC as "poor man's FORTRAN."
> > 
> 
> I learned Fortran II in 1965, and BASIC in the early 1980s. BASIC 
> always felt like a dialect of Fortran (that could handle strings 
> decently) to me.

I don't know if BASIC's designers had Fortran in mind, but BASIC
definitely mirrors Fortran.  Generally, BASIC is easier to use
than Fortran for simple applications; for heavy-duty stuff,
Fortran is better.

For younger children, BASIC was easier to teach and learn.  
For the _typical_ student, having completed Algebra-II was
usually necessary for best understanding of Fortran; the
REAL/INTEGER variables could cause confusion.

On Saturday, June 2, 2018 at 12:19:34 PM UTC-4, Andrew Swallow wrote:

> The writers of BASIC obviously knew FORTRAN. They chose GOTOs over blocks.

BASIC had GOSUB.  Some BASIC's had CHAIN.

On Friday, June 1, 2018 at 4:22:50 PM UTC-4, Rich Alderson wrote:
> hanc...@bbs.cpcn.com writes:
> 
> > On Thursday, May 31, 2018 at 5:11:01 PM UTC-4, Andreas Kohlbach wrote:
> 
> >>> Nice program.  I particularly like the way they briefly mention
> >>> Bill Gates only to point out that they were there first.
> 
> >> The first to commercialize on BASIC. Without BASIC and the MITS 8800
> >> there might not be a Microsoft company today. Would be interesting to
> >> know if CP/M then would have lead the market well into the 1990s and
> >> beyond with GEM becoming the GUI of choice and Gary if Kildall would
> >> still be alive, not going to this bar and had this fight leading to his
> >> death...
> 
> > I believe Gates and his friends were doing commercial work before
> > they did the BASIC compiler.  So, I strongly suspect Gates still
> > would have developed a major software company.
> 
> No, they weren't.  Read Paul's book.
> 
> Paul and Bill did have 1 attempt at a company prior to the advent of the Altair
> 8800:  Traf-o-Data was a side-of-the-road traffic counter (now commonplace, but
> at the time unheard of) based on the 8008 processor.  Because they did not have
> a development system for the 8008, Paul wrote a simulator for the processor in
> Macro-10 (PDP-10 assembler) which represented 8008 instructions as the address
> portion of LUUOs[1].
> 
> Paul and Bill always wanted to write a BASIC for a microprocessor, but could
> not find one powerful enough until the 8080 came along.  Paul revised the 8008
> simulator for the 8080, and that was what they used to produce the first BASIC.
> Variants were used at Microsoft for the next 15 years to produce all the micro
> versions of BASIC which they sold; Microsoft was a PDP-10 shop until PCs were
> capable of self-hosting.

In my humble opinion, given Gates' passionate use of computers in
high school, I believe they would've simply gone into some other
programming project had BASIC not come along.  I believe even in
high school Gates was doing some commercial work (using his schools'
computers.)

On 02/06/2018 20:11, hanc...@bbs.cpcn.com wrote:
> On Saturday, June 2, 2018 at 12:19:34 PM UTC-4, Andrew Swallow wrote:
> 
>> The writers of BASIC obviously knew FORTRAN. They chose GOTOs over blocks.
> 
> BASIC had GOSUB.  Some BASIC's had CHAIN.
> 

GOSUB is a CALL statement without parameters. Although GOSUB is 
recursive. However having to implement variables as arrays shows how 
inelegant actually recursion is.

On 03/06/2018 15:02, Andrew Swallow wrote:
> On 02/06/2018 20:11, hanc...@bbs.cpcn.com wrote:
>> On Saturday, June 2, 2018 at 12:19:34 PM UTC-4, Andrew Swallow wrote:
>>
>>> The writers of BASIC obviously knew FORTRAN. They chose GOTOs over 
>>> blocks.
>>
>> BASIC had GOSUB.  Some BASIC's had CHAIN.
>>
> 
> GOSUB is a CALL statement without parameters. Although GOSUB is 
> recursive. However having to implement variables as arrays shows how 
> inelegant actually recursion is.

Recursion is a technique favoured by those qualified in computer
science but never used by programmers in the real practical world.

On 03/06/2018 16:24, Gareth's Downstairs Computer wrote:
> On 03/06/2018 15:02, Andrew Swallow wrote:
>> On 02/06/2018 20:11, hanc...@bbs.cpcn.com wrote:
>>> On Saturday, June 2, 2018 at 12:19:34 PM UTC-4, Andrew Swallow wrote:
>>>
>>>> The writers of BASIC obviously knew FORTRAN. They chose GOTOs over 
>>>> blocks.
>>>
>>> BASIC had GOSUB.  Some BASIC's had CHAIN.
>>>
>>
>> GOSUB is a CALL statement without parameters. Although GOSUB is 
>> recursive. However having to implement variables as arrays shows how 
>> inelegant actually recursion is.
> 
> Recursion is a technique favoured by those qualified in computer
> science but never used by programmers in the real practical world.
> 

Recursion is useful when you have a variable number of loops. With a 
fixed number of loops the programmer codes them in and uses iteration. 
So the real life applications of recursion are when processing computer 
languages and bill of materials (BOM).

Gareth's Downstairs Computer
<headstone255.but.n...@yahoo.com> wrote:
> On 03/06/2018 15:02, Andrew Swallow wrote:
>> On 02/06/2018 20:11, hanc...@bbs.cpcn.com wrote:
>>> On Saturday, June 2, 2018 at 12:19:34 PM UTC-4, Andrew Swallow wrote:
>>> 
>>>> The writers of BASIC obviously knew FORTRAN. They chose GOTOs over 
>>>> blocks.
>>> 
>>> BASIC had GOSUB.  Some BASIC's had CHAIN.
>>> 
>> 
>> GOSUB is a CALL statement without parameters. Although GOSUB is 
>> recursive. However having to implement variables as arrays shows how 
>> inelegant actually recursion is.
> 
> Recursion is a technique favoured by those qualified in computer
> science but never used by programmers in the real practical world.
> 
> 

Some problems are easily solved by recursion that are significantly more
complicated otherwise. Of course Imhace a CS degree, so maybe I'm not
qualified to comment. ;-)

-- 
Pete

On 03/06/2018 22:40, Peter Flass wrote:
> 
> Some problems are easily solved by recursion that are significantly more
> complicated otherwise.

I would be interested to know some examples, please?

Gareth's Downstairs Computer
<headstone255.but.n...@yahoo.com> wrote:
> On 03/06/2018 22:40, Peter Flass wrote:
>> 
>> Some problems are easily solved by recursion that are significantly more
>> complicated otherwise.
> 
> I would be interested to know some examples, please?
> 
> 

Depth-first search of a binary tree. Top-down parsing.

Anything that requires retracing a path thru a data structure. Without
recursion you have to maintain a table to keep track of where you've been
and where you're going. Recursion just handles it naturally.

-- 
Pete

On Mon, 04 Jun 2018 06:28:37 -0400, Peter Flass wrote:

> Gareth's Downstairs Computer
> <headstone255.but.n...@yahoo.com> wrote:
>> On 03/06/2018 22:40, Peter Flass wrote:
>>> 
>>> Some problems are easily solved by recursion that are significantly
>>> more complicated otherwise.
>> 
>> I would be interested to know some examples, please?
>> 
>> 
>> 
> Depth-first search of a binary tree. Top-down parsing.
> 
> Anything that requires retracing a path thru a data structure. Without
> recursion you have to maintain a table to keep track of where you've
> been and where you're going. Recursion just handles it naturally.

+1

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

On 04/06/2018 12:13, Bob Eager wrote:
> On Mon, 04 Jun 2018 06:28:37 -0400, Peter Flass wrote:
> 
>> Gareth's Downstairs Computer
>> <headstone255.but.n...@yahoo.com> wrote:
>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>
>>>> Some problems are easily solved by recursion that are significantly
>>>> more complicated otherwise.
>>>
>>> I would be interested to know some examples, please?
>>>
>>>
>>>
>> Depth-first search of a binary tree. Top-down parsing.
>>
>> Anything that requires retracing a path thru a data structure. Without
>> recursion you have to maintain a table to keep track of where you've
>> been and where you're going. Recursion just handles it naturally.
> 
> +1
> 

In both cases a table is maintained, either through a manually 
programmed (trivial) table or through the auto-maintained call
tree, either by a return stack, or, again, in the case of
languages such as PL/M-86 that allocate local data statically,
a human-maintained call structure.

It seems to me that computer scientists wish for everything to
be handed to them on a plate and baulk at the thought of
minor diversions to provide some simple and trivial extra facitlites
whereas real world programmers just get on with the job.

Peter Flass <peter...@yahoo.com> writes:

> Gareth's Downstairs Computer
> <headstone255.but.n...@yahoo.com> wrote:
>> On 03/06/2018 22:40, Peter Flass wrote:
>>> 
>>> Some problems are easily solved by recursion that are significantly more
>>> complicated otherwise.
>> 
>> I would be interested to know some examples, please?
>
> Depth-first search of a binary tree. Top-down parsing.
>
> Anything that requires retracing a path thru a data structure. Without
> recursion you have to maintain a table to keep track of where you've been
> and where you're going. Recursion just handles it naturally.

Yes, but using a table, the application has some way of detecting
running out of storage.  For example, if the table depth is
exceeded, the application can attempt to allocate a larger table
and then fail with a message when storage is exceeded.
With recursion, you eventually run out of storage but with
any language I am familiar with it your program just dies.

-- 
Dan Espen

On 2018-06-04, Gareth's Downstairs Computer
<headstone255.but.n...@yahoo.com> wrote:

> On 04/06/2018 12:13, Bob Eager wrote:
>
>> On Mon, 04 Jun 2018 06:28:37 -0400, Peter Flass wrote:
>> 
>>> Gareth's Downstairs Computer
>>> <headstone255.but.n...@yahoo.com> wrote:
>>>
>>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>>
>>>>> Some problems are easily solved by recursion that are significantly
>>>>> more complicated otherwise.
>>>>
>>>> I would be interested to know some examples, please?
>>>
>>> Depth-first search of a binary tree. Top-down parsing.
>>>
>>> Anything that requires retracing a path thru a data structure. Without
>>> recursion you have to maintain a table to keep track of where you've
>>> been and where you're going. Recursion just handles it naturally.
>> 
>> +1
>
> In both cases a table is maintained, either through a manually 
> programmed (trivial) table or through the auto-maintained call
> tree, either by a return stack, or, again, in the case of
> languages such as PL/M-86 that allocate local data statically,
> a human-maintained call structure.
>
> It seems to me that computer scientists wish for everything to
> be handed to them on a plate and baulk at the thought of
> minor diversions to provide some simple and trivial extra facitlites
> whereas real world programmers just get on with the job.

I admit that there are probably cases where recursion is an
elegant solution to the problem.  However, in my experience
such cases are few and far between.  I've always considered
an obsession with recursion to be a hallmark of the CS weenie.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

On 4 Jun 2018 15:20:21 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> I admit that there are probably cases where recursion is an
> elegant solution to the problem.  However, in my experience

	Recursion is often a very elegant description ...

> such cases are few and far between.  I've always considered
> an obsession with recursion to be a hallmark of the CS weenie.

	... but rarely a good implementation. It is worth noting that some
compilers will actually spot and unwind some kinds of recursion
(particularly tail recursion).

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

> On 2018-06-04, Gareth's Downstairs Computer
> <headstone255.but.n...@yahoo.com> wrote:
>
>> On 04/06/2018 12:13, Bob Eager wrote:
>>
>>> On Mon, 04 Jun 2018 06:28:37 -0400, Peter Flass wrote:
>>> 
>>>> Gareth's Downstairs Computer
>>>> <headstone255.but.n...@yahoo.com> wrote:
>>>>
>>>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>>>
>>>>>> Some problems are easily solved by recursion that are significantly
>>>>>> more complicated otherwise.
>>>>>
>>>>> I would be interested to know some examples, please?
>>>>
>>>> Depth-first search of a binary tree. Top-down parsing.
>>>>
>>>> Anything that requires retracing a path thru a data structure. Without
>>>> recursion you have to maintain a table to keep track of where you've
>>>> been and where you're going. Recursion just handles it naturally.
>>> 
>>> +1
>>
>> In both cases a table is maintained, either through a manually 
>> programmed (trivial) table or through the auto-maintained call
>> tree, either by a return stack, or, again, in the case of
>> languages such as PL/M-86 that allocate local data statically,
>> a human-maintained call structure.
>>
>> It seems to me that computer scientists wish for everything to
>> be handed to them on a plate and baulk at the thought of
>> minor diversions to provide some simple and trivial extra facitlites
>> whereas real world programmers just get on with the job.
>
> I admit that there are probably cases where recursion is an
> elegant solution to the problem.  However, in my experience
> such cases are few and far between.  I've always considered
> an obsession with recursion to be a hallmark of the CS weenie.

Speaking as retired faculty, we tend to be better at giving the students
tools than at showing them where they're appropriate...

In the case of recursion, a problem a lot of new students have is
understanding the difference between calling a function, and using a
goto to get to the function and another goto to go back where you came
from (I actually once had a student ask me what the difference was; he
didn't have enough of a concept of abstraction, encapsulation, or
organization for any answer in those terms to make the slightest
sense).  Simply not telling them about labels and gotos in the first
class helps, but there's always one who figures it out on his own and
turns in a bowl of amazing spaghetti for his second or third assignment.

By the time they can get a simple recursive function to work, they have
to have some sort of understanding of the notion of a function call
being the same thing as turning a part of the problem over to somebody
else to solve, and getting an answer back.  So it's really helpful in
teaching functions.

Unfortunately, they also tend to come out of the experience with the
idea that it's a great way to find the fibonacci sequence...

Charles Richmond <nume...@aquaporin4.com> writes:

> On 6/1/2018 3:22 PM, Rich Alderson wrote:

>> Paul and Bill did have 1 attempt at a company prior to the advent of the
>> Altair 8800:  Traf-o-Data was a side-of-the-road traffic counter (now
>> commonplace, but at the time unheard of) based on the 8008 processor.
>> Because they did not have a development system for the 8008, Paul wrote a
>> simulator for the processor in Macro-10 (PDP-10 assembler) which represented
>> 8008 instructions as the address portion of LUUOs[1].

> Now wait...  I read somewhere that Gates and Allen worked on weekends at 
> some Seattle company when the the two guys were still in high school or 
> junior high.  At this company the two got good looks at the PDP-10 
> source code for compilers and editors... including a Dec BASIC.  ISTM 
> that the two were paid something like $2 per hour.

You've either misremembered what you read, or your source was garbled.

In the summer of 1968, a young high school math teacher named Fred Wright (not
the same Fred Wright who was a grad student at SAIL!) attended a summer school
at Stanford for math teachers to teach them BASIC as a tool for teaching
programming to students.  He was so enthusiastic about it that on his return to
the Lakeside School in Seattle, he convinced the Lakeside Mothers Club that
computers were so important that they devoted the funds from the annual Bake
Sale to paying for an account on GEIS (the General Eletric Information System,
a nationwide timesharing system) for those students who might like to learn
programming.

Two of the students who signed up were a sophomore, Paul Allen, and an eighth
grader, Bill Gates.  They were two of the half dozen who really got into
computing (Harvey Motulsky, Robert McCaw, Ric Weiland, and Kent Evans, to be
complete).  They ran through the annual budget in the first month.

At that time, Harvey's father saw a timesharing service bureau being
established in Seattle's University District, and the boys came into contact
with the Computer Center Corporation (AKA "C-Cubed") and the PDP-10.  They were
so obvioulsy enthusiastic that they were given free access to the system as
long as they kept records of what they were doing whenever the system crashed;
the systems programmers gave them access to the Macro-10 and UUO manuals, which
they devoured.

Five of the boys went on to work as programmers for RODS, part of the
Bonneville Dam project, over the summer between Paul's junior and senior years
in high school.  Their boss was later the business manager of the museum from
2011 to 2015.

> I read _Idea Man_, but I'm not sure where I read about the above.  _Idea 
> Man_ was written so much better that Walter Isaacson's biography of 
> Steve Jobs, which I also read.  (IMO)

It has all of this, with corroborative detail (like the names of the systems
programmers: Steve "Slug" Russell of MIT and Dick Gruen & Bill Weiher of SAIL).

-- 
Rich Alderson					  ne...@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

hanc...@bbs.cpcn.com writes:

> In my humble opinion, given Gates' passionate use of computers in
> high school, I believe they would've simply gone into some other
> programming project had BASIC not come along.  I believe even in
> high school Gates was doing some commercial work (using his schools'
> computers.)

Nope.  However, the summer that Gates and Allen and 3 of their friend from high
school worked for RODS, he spent a lot of time writing a class scheduling
program which would put him into classes with a high proportion of girls (as
the upcoming year would be the first when the Lakeside School was co-ed).

"Commercial work on school computers" describes the use of the Harvard PDP-10
to create their BASIC interpreter for the Altair...

-- 
Rich Alderson					  ne...@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

On 6/4/2018 2:05 PM, Joe Pfeiffer wrote:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> 
>> On 2018-06-04, Gareth's Downstairs Computer
>> <headstone255.but.n...@yahoo.com> wrote:
>>
>>> On 04/06/2018 12:13, Bob Eager wrote:
>>>
>>>> On Mon, 04 Jun 2018 06:28:37 -0400, Peter Flass wrote:
>>>>
>>>>> Gareth's Downstairs Computer
>>>>> <headstone255.but.n...@yahoo.com> wrote:
>>>>>
>>>>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>>>>
>>>>>>> Some problems are easily solved by recursion that are significantly
>>>>>>> more complicated otherwise.
>>>>>>
>>>>>> I would be interested to know some examples, please?
>>>>>
>>>>> Depth-first search of a binary tree. Top-down parsing.
>>>>>
>>>>> Anything that requires retracing a path thru a data structure. Without
>>>>> recursion you have to maintain a table to keep track of where you've
>>>>> been and where you're going. Recursion just handles it naturally.
>>>>
>>>> +1
>>>
>>> In both cases a table is maintained, either through a manually
>>> programmed (trivial) table or through the auto-maintained call
>>> tree, either by a return stack, or, again, in the case of
>>> languages such as PL/M-86 that allocate local data statically,
>>> a human-maintained call structure.
>>>
>>> It seems to me that computer scientists wish for everything to
>>> be handed to them on a plate and baulk at the thought of
>>> minor diversions to provide some simple and trivial extra facitlites
>>> whereas real world programmers just get on with the job.
>>
>> I admit that there are probably cases where recursion is an
>> elegant solution to the problem.  However, in my experience
>> such cases are few and far between.  I've always considered
>> an obsession with recursion to be a hallmark of the CS weenie.
> 
> Speaking as retired faculty, we tend to be better at giving the students
> tools than at showing them where they're appropriate...
> 
> In the case of recursion, a problem a lot of new students have is
> understanding the difference between calling a function, and using a
> goto to get to the function and another goto to go back where you came
> from (I actually once had a student ask me what the difference was; he
> didn't have enough of a concept of abstraction, encapsulation, or
> organization for any answer in those terms to make the slightest
> sense).  Simply not telling them about labels and gotos in the first
> class helps, but there's always one who figures it out on his own and
> turns in a bowl of amazing spaghetti for his second or third assignment.
> 
> By the time they can get a simple recursive function to work, they have
> to have some sort of understanding of the notion of a function call
> being the same thing as turning a part of the problem over to somebody
> else to solve, and getting an answer back.  So it's really helpful in
> teaching functions.
> 
> Unfortunately, they also tend to come out of the experience with the
> idea that it's a great way to find the fibonacci sequence...
> 

If you use "dynamic programming" and cache the results of Fibonacci 
calls, it can be quite efficient.  When the Fibonacci function returns a 
result or sub-result (say the fifth Fibonacci number), the result is 
cached.  Before any call to the Fibonacci function, the program first 
checks to see if the result being sought...  already exists in the 
cache.  If the result is in the cache, use the result instead of calling 
the function.

This prevents repetitiously calling of the Fibonacci function for any 
one particular number.  For example, if you have already called the 
Fibonacci function for the tenth number...  the result will be in the 
cache.  You never again need to call the Fibonacci function for the 
tenth Fibonacci number.

-- 
numerist at aquaporin4 dot com

Charles Richmond <nume...@aquaporin4.com> writes:

> On 6/4/2018 2:05 PM, Joe Pfeiffer wrote:
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>
>>> On 2018-06-04, Gareth's Downstairs Computer
>>> <headstone255.but.n...@yahoo.com> wrote:
>>>
>>>> On 04/06/2018 12:13, Bob Eager wrote:
>>>>
>>>>> On Mon, 04 Jun 2018 06:28:37 -0400, Peter Flass wrote:
>>>>>
>>>>>> Gareth's Downstairs Computer
>>>>>> <headstone255.but.n...@yahoo.com> wrote:
>>>>>>
>>>>>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>>>>>
>>>>>>>> Some problems are easily solved by recursion that are significantly
>>>>>>>> more complicated otherwise.
>>>>>>>
>>>>>>> I would be interested to know some examples, please?
>>>>>>
>>>>>> Depth-first search of a binary tree. Top-down parsing.
>>>>>>
>>>>>> Anything that requires retracing a path thru a data structure. Without
>>>>>> recursion you have to maintain a table to keep track of where you've
>>>>>> been and where you're going. Recursion just handles it naturally.
>>>>>
>>>>> +1
>>>>
>>>> In both cases a table is maintained, either through a manually
>>>> programmed (trivial) table or through the auto-maintained call
>>>> tree, either by a return stack, or, again, in the case of
>>>> languages such as PL/M-86 that allocate local data statically,
>>>> a human-maintained call structure.
>>>>
>>>> It seems to me that computer scientists wish for everything to
>>>> be handed to them on a plate and baulk at the thought of
>>>> minor diversions to provide some simple and trivial extra facitlites
>>>> whereas real world programmers just get on with the job.
>>>
>>> I admit that there are probably cases where recursion is an
>>> elegant solution to the problem.  However, in my experience
>>> such cases are few and far between.  I've always considered
>>> an obsession with recursion to be a hallmark of the CS weenie.
>>
>> Speaking as retired faculty, we tend to be better at giving the students
>> tools than at showing them where they're appropriate...
>>
>> In the case of recursion, a problem a lot of new students have is
>> understanding the difference between calling a function, and using a
>> goto to get to the function and another goto to go back where you came
>> from (I actually once had a student ask me what the difference was; he
>> didn't have enough of a concept of abstraction, encapsulation, or
>> organization for any answer in those terms to make the slightest
>> sense).  Simply not telling them about labels and gotos in the first
>> class helps, but there's always one who figures it out on his own and
>> turns in a bowl of amazing spaghetti for his second or third assignment.
>>
>> By the time they can get a simple recursive function to work, they have
>> to have some sort of understanding of the notion of a function call
>> being the same thing as turning a part of the problem over to somebody
>> else to solve, and getting an answer back.  So it's really helpful in
>> teaching functions.
>>
>> Unfortunately, they also tend to come out of the experience with the
>> idea that it's a great way to find the fibonacci sequence...
>>
>
> If you use "dynamic programming" and cache the results of Fibonacci
> calls, it can be quite efficient.  When the Fibonacci function returns
> a result or sub-result (say the fifth Fibonacci number), the result is
> cached.  Before any call to the Fibonacci function, the program first
> checks to see if the result being sought...  already exists in the
> cache.  If the result is in the cache, use the result instead of
> calling the function.
>
> This prevents repetitiously calling of the Fibonacci function for any
> one particular number.  For example, if you have already called the
> Fibonacci function for the tenth number...  the result will be in the
> cache.  You never again need to call the Fibonacci function for the
> tenth Fibonacci number.

Of course.  But in context it's clear I'm talking about a naive
recursive implementation.

On 04/06/2018 22:40, Joe Pfeiffer wrote:
> Charles Richmond <nume...@aquaporin4.com> writes:
> 
>> On 6/4/2018 2:05 PM, Joe Pfeiffer wrote:
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>
>>>> On 2018-06-04, Gareth's Downstairs Computer
>>>> <headstone255.but.n...@yahoo.com> wrote:
>>>>
>>>>> On 04/06/2018 12:13, Bob Eager wrote:
>>>>>
>>>>>> On Mon, 04 Jun 2018 06:28:37 -0400, Peter Flass wrote:
>>>>>>
>>>>>>> Gareth's Downstairs Computer
>>>>>>> <headstone255.but.n...@yahoo.com> wrote:
>>>>>>>
>>>>>>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>>>>>>
>>>>>>>>> Some problems are easily solved by recursion that are significantly
>>>>>>>>> more complicated otherwise.
>>>>>>>>
>>>>>>>> I would be interested to know some examples, please?
>>>>>>>
>>>>>>> Depth-first search of a binary tree. Top-down parsing.
>>>>>>>
>>>>>>> Anything that requires retracing a path thru a data structure. Without
>>>>>>> recursion you have to maintain a table to keep track of where you've
>>>>>>> been and where you're going. Recursion just handles it naturally.
>>>>>>
>>>>>> +1
>>>>>
>>>>> In both cases a table is maintained, either through a manually
>>>>> programmed (trivial) table or through the auto-maintained call
>>>>> tree, either by a return stack, or, again, in the case of
>>>>> languages such as PL/M-86 that allocate local data statically,
>>>>> a human-maintained call structure.
>>>>>
>>>>> It seems to me that computer scientists wish for everything to
>>>>> be handed to them on a plate and baulk at the thought of
>>>>> minor diversions to provide some simple and trivial extra facitlites
>>>>> whereas real world programmers just get on with the job.
>>>>
>>>> I admit that there are probably cases where recursion is an
>>>> elegant solution to the problem.  However, in my experience
>>>> such cases are few and far between.  I've always considered
>>>> an obsession with recursion to be a hallmark of the CS weenie.
>>>
>>> Speaking as retired faculty, we tend to be better at giving the students
>>> tools than at showing them where they're appropriate...
>>>
>>> In the case of recursion, a problem a lot of new students have is
>>> understanding the difference between calling a function, and using a
>>> goto to get to the function and another goto to go back where you came
>>> from (I actually once had a student ask me what the difference was; he
>>> didn't have enough of a concept of abstraction, encapsulation, or
>>> organization for any answer in those terms to make the slightest
>>> sense).  Simply not telling them about labels and gotos in the first
>>> class helps, but there's always one who figures it out on his own and
>>> turns in a bowl of amazing spaghetti for his second or third assignment.
>>>
>>> By the time they can get a simple recursive function to work, they have
>>> to have some sort of understanding of the notion of a function call
>>> being the same thing as turning a part of the problem over to somebody
>>> else to solve, and getting an answer back.  So it's really helpful in
>>> teaching functions.
>>>
>>> Unfortunately, they also tend to come out of the experience with the
>>> idea that it's a great way to find the fibonacci sequence...
>>>
>>
>> If you use "dynamic programming" and cache the results of Fibonacci
>> calls, it can be quite efficient.  When the Fibonacci function returns
>> a result or sub-result (say the fifth Fibonacci number), the result is
>> cached.  Before any call to the Fibonacci function, the program first
>> checks to see if the result being sought...  already exists in the
>> cache.  If the result is in the cache, use the result instead of
>> calling the function.
>>
>> This prevents repetitiously calling of the Fibonacci function for any
>> one particular number.  For example, if you have already called the
>> Fibonacci function for the tenth number...  the result will be in the
>> cache.  You never again need to call the Fibonacci function for the
>> tenth Fibonacci number.
> 
> Of course.  But in context it's clear I'm talking about a naive
> recursive implementation.
> 

The same way you only do a factorial calculation once. There after you 
look it up. After 32! we hit overflow so the array was short.

On Mon, 4 Jun 2018 12:35:24 +0100, Gareth's Downstairs Computer
<headstone255.but.n...@yahoo.com> wrote:
>On 04/06/2018 12:13, Bob Eager wrote:
>> On Mon, 04 Jun 2018 06:28:37 -0400, Peter Flass wrote:
>> 
>>> Gareth's Downstairs Computer
>>> <headstone255.but.n...@yahoo.com> wrote:
>>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>>
>>>>> Some problems are easily solved by recursion that are significantly
>>>>> more complicated otherwise.
>>>>
>>>> I would be interested to know some examples, please?
>>>>
>>> Depth-first search of a binary tree. Top-down parsing.
>>>
>>> Anything that requires retracing a path thru a data structure. Without
>>> recursion you have to maintain a table to keep track of where you've
>>> been and where you're going. Recursion just handles it naturally.
>> 
>> +1
>> 
>In both cases a table is maintained, either through a manually 
>programmed (trivial) table or through the auto-maintained call
>tree, either by a return stack, or, again, in the case of
>languages such as PL/M-86 that allocate local data statically,
>a human-maintained call structure.
>
>It seems to me that computer scientists wish for everything to
>be handed to them on a plate and baulk at the thought of
>minor diversions to provide some simple and trivial extra facitlites
>whereas real world programmers just get on with the job.

Isn't that the whole point of computers?  To take care of all the little fiddly
bits so that humans don't have to?

Oh, these computer scientists with their assemblers and compilers... and their
octal and hexadecimal... why don't they just write out all the ones and zeros?

On Mon, 04 Jun 2018 09:19:42 -0400, Dan Espen <dan1...@gmail.com> wrote:
>Peter Flass <peter...@yahoo.com> writes:
>> Gareth's Downstairs Computer
>> <headstone255.but.n...@yahoo.com> wrote:
>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>> 
>>>> Some problems are easily solved by recursion that are significantly more
>>>> complicated otherwise.
>>> 
>>> I would be interested to know some examples, please?
>>
>> Depth-first search of a binary tree. Top-down parsing.
>>
>> Anything that requires retracing a path thru a data structure. Without
>> recursion you have to maintain a table to keep track of where you've been
>> and where you're going. Recursion just handles it naturally.
>
>Yes, but using a table, the application has some way of detecting
>running out of storage.  For example, if the table depth is
>exceeded, the application can attempt to allocate a larger table
>and then fail with a message when storage is exceeded.
>With recursion, you eventually run out of storage but with
>any language I am familiar with it your program just dies.

DEC hardware can trap stack overflows (and underflows).  That facility doesn't
always make it into HLLs, nor the ability to do something about them.

Questor <usenet@only.tnx> wrote:
> On Mon, 04 Jun 2018 09:19:42 -0400, Dan Espen <dan1...@gmail.com> wrote:
>> Peter Flass <peter...@yahoo.com> writes:
>>> Gareth's Downstairs Computer
>>> <headstone255.but.n...@yahoo.com> wrote:
>>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>> 
>>>>> Some problems are easily solved by recursion that are significantly more
>>>>> complicated otherwise.
>>>> 
>>>> I would be interested to know some examples, please?
>>> 
>>> Depth-first search of a binary tree. Top-down parsing.
>>> 
>>> Anything that requires retracing a path thru a data structure. Without
>>> recursion you have to maintain a table to keep track of where you've been
>>> and where you're going. Recursion just handles it naturally.
>> 
>> Yes, but using a table, the application has some way of detecting
>> running out of storage.  For example, if the table depth is
>> exceeded, the application can attempt to allocate a larger table
>> and then fail with a message when storage is exceeded.
>> With recursion, you eventually run out of storage but with
>> any language I am familiar with it your program just dies.
> 
> DEC hardware can trap stack overflows (and underflows).  That facility doesn't
> always make it into HLLs, nor the ability to do something about them.
> 
> 

It's the doing something that's a problem. OS/2 used a "guard page" on the
stack (hardware trap). You could set it to trap on accesses to the bottom
page or so of the stack, so when the stack was *almost* used up you got
notified, in time to do something. Once the stack is full, it's too late.

-- 
Pete

On 2018-06-06, Questor <usenet@only.tnx> wrote:

> On Mon, 4 Jun 2018 12:35:24 +0100, Gareth's Downstairs Computer
> <headstone255.but.n...@yahoo.com> wrote:
>
>> It seems to me that computer scientists wish for everything to
>> be handed to them on a plate and baulk at the thought of
>> minor diversions to provide some simple and trivial extra facitlites
>> whereas real world programmers just get on with the job.
>
> Isn't that the whole point of computers?  To take care of all the little
> fiddly bits so that humans don't have to?

Ostensibly, yes.  The reality is that users get stuck with the ever-increasing
proliferation of little fiddly bits known as "system configuration".

> Oh, these computer scientists with their assemblers and compilers... and their
> octal and hexadecimal... why don't they just write out all the ones and zeros?

No, no... computer scientists refuse to dirty their hands with real-world
things like ones and zeros.  They're too busy coming up with increasingly
high-level approaches to isolate themselves from the real world.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

On Wed, 6 Jun 2018 16:58:25 -0400, Peter Flass <peter...@yahoo.com> wrote:
>Questor <usenet@only.tnx> wrote:
>> On Mon, 04 Jun 2018 09:19:42 -0400, Dan Espen <dan1...@gmail.com> wrote:
>>> Peter Flass <peter...@yahoo.com> writes:
>>>> Gareth's Downstairs Computer
>>>> <headstone255.but.n...@yahoo.com> wrote:
>>>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>>> 
>>>>>> Some problems are easily solved by recursion that are significantly more
>>>>>> complicated otherwise.
>>>>> 
>>>>> I would be interested to know some examples, please?
>>>> 
>>>> Depth-first search of a binary tree. Top-down parsing.
>>>> 
>>>> Anything that requires retracing a path thru a data structure. Without
>>>> recursion you have to maintain a table to keep track of where you've been
>>>> and where you're going. Recursion just handles it naturally.
>>> 
>>> Yes, but using a table, the application has some way of detecting
>>> running out of storage.  For example, if the table depth is
>>> exceeded, the application can attempt to allocate a larger table
>>> and then fail with a message when storage is exceeded.
>>> With recursion, you eventually run out of storage but with
>>> any language I am familiar with it your program just dies.
>> 
>> DEC hardware can trap stack overflows (and underflows).  That facility doesn't
>> always make it into HLLs, nor the ability to do something about them.
>
>It's the doing something that's a problem. OS/2 used a "guard page" on the
>stack (hardware trap). You could set it to trap on accesses to the bottom
>page or so of the stack, so when the stack was *almost* used up you got
>notified, in time to do something. Once the stack is full, it's too late.

If you were serious about attempting to recover from a stack overflow, the first
thing the trap routine would do is exchange the stack pointer for a new one
pointing to sufficient pre-allocated stack space to attempt obtaining more
memory for a bigger stack and/or saving important information and exiting
gracefully.

You might do this in a language like BLISS or C, and of course assembly.  Not
so much in FORTRAN or COBOL.

Usually in the course of program development, one gets a sense of how much
stack space is required for normal operation.  Subsequent overflows or
underflows are probably the result of a programming error uncovered by an
obscure condition not encountered during testing.

usenet@only.tnx (Questor) writes:
>On Wed, 6 Jun 2018 16:58:25 -0400, Peter Flass <peter...@yahoo.com> wrote:
>>Questor <usenet@only.tnx> wrote:
>>> On Mon, 04 Jun 2018 09:19:42 -0400, Dan Espen <dan1...@gmail.com> wrote:
>>>> Peter Flass <peter...@yahoo.com> writes:
>>>>> Gareth's Downstairs Computer
>>>>> <headstone255.but.n...@yahoo.com> wrote:
>>>>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>>>> 
>>>>>>> Some problems are easily solved by recursion that are significantly more
>>>>>>> complicated otherwise.
>>>>>> 
>>>>>> I would be interested to know some examples, please?
>>>>> 
>>>>> Depth-first search of a binary tree. Top-down parsing.
>>>>> 
>>>>> Anything that requires retracing a path thru a data structure. Without
>>>>> recursion you have to maintain a table to keep track of where you've been
>>>>> and where you're going. Recursion just handles it naturally.
>>>> 
>>>> Yes, but using a table, the application has some way of detecting
>>>> running out of storage.  For example, if the table depth is
>>>> exceeded, the application can attempt to allocate a larger table
>>>> and then fail with a message when storage is exceeded.
>>>> With recursion, you eventually run out of storage but with
>>>> any language I am familiar with it your program just dies.
>>> 
>>> DEC hardware can trap stack overflows (and underflows).  That facility doesn't
>>> always make it into HLLs, nor the ability to do something about them.
>>
>>It's the doing something that's a problem. OS/2 used a "guard page" on the
>>stack (hardware trap). You could set it to trap on accesses to the bottom
>>page or so of the stack, so when the stack was *almost* used up you got
>>notified, in time to do something. Once the stack is full, it's too late.
>
>If you were serious about attempting to recover from a stack overflow, the first
>thing the trap routine would do is exchange the stack pointer for a new one
>pointing to sufficient pre-allocated stack space to attempt obtaining more
>memory for a bigger stack and/or saving important information and exiting
>gracefully.

e.g. sigaltstack for catching SIGSEGV.

>
>You might do this in a language like BLISS or C, and of course assembly.  Not
>so much in FORTRAN or COBOL.
>
>Usually in the course of program development, one gets a sense of how much
>stack space is required for normal operation.  Subsequent overflows or
>underflows are probably the result of a programming error uncovered by an
>obscure condition not encountered during testing.
>

On 06/07/2018 01:32 PM, Charlie Gibbs wrote:
> On 2018-06-06, Questor <usenet@only.tnx> wrote:
> 
>> On Mon, 4 Jun 2018 12:35:24 +0100, Gareth's Downstairs Computer
>> <headstone255.but.n...@yahoo.com> wrote:
>>
>>> It seems to me that computer scientists wish for everything to
>>> be handed to them on a plate and baulk at the thought of
>>> minor diversions to provide some simple and trivial extra facitlites
>>> whereas real world programmers just get on with the job.
>>
>> Isn't that the whole point of computers?  To take care of all the little
>> fiddly bits so that humans don't have to?
> 
> Ostensibly, yes.  The reality is that users get stuck with the ever-increasing
> proliferation of little fiddly bits known as "system configuration".
> 
>> Oh, these computer scientists with their assemblers and compilers... and their
>> octal and hexadecimal... why don't they just write out all the ones and zeros?
> 
> No, no... computer scientists refuse to dirty their hands with real-world
> things like ones and zeros.  They're too busy coming up with increasingly
> high-level approaches to isolate themselves from the real world.
> 
They are computer scientists, not computer engineers. They are not 
supposed to be developing practical applications.

On Thu, 7 Jun 2018 17:19:04 -0400
Richard Thiebaud <thieba...@aol.com> wrote:

> They are computer scientists, not computer engineers. They are not 
> supposed to be developing practical applications.

	s/supposed to be/safe/

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On 6/8/2018 7:27 AM, Ahem A Rivet's Shot wrote:
> On Thu, 7 Jun 2018 17:19:04 -0400
> Richard Thiebaud <thieba...@aol.com> wrote:
> 
>> They are computer scientists, not computer engineers. They are not
>> supposed to be developing practical applications.
> 
> 	s/supposed to be/safe/
> 

         s/supposed to be/safe to be trusted with/

-- 
numerist at aquaporin4 dot com

On 06/08/2018 08:27 AM, Ahem A Rivet's Shot wrote:
> On Thu, 7 Jun 2018 17:19:04 -0400
> Richard Thiebaud <thieba...@aol.com> wrote:
> 
>> They are computer scientists, not computer engineers. They are not
>> supposed to be developing practical applications.
> 
> 	s/supposed to be/safe/
> 
Change back to "supposed to be".

Richard Thiebaud <thieba...@aol.com> writes:
>On 06/08/2018 08:27 AM, Ahem A Rivet's Shot wrote:
>> On Thu, 7 Jun 2018 17:19:04 -0400
>> Richard Thiebaud <thieba...@aol.com> wrote:
>> 
>>> They are computer scientists, not computer engineers. They are not
>>> supposed to be developing practical applications.
>> 
>> 	s/supposed to be/safe/
>> 
>Change back to "supposed to be".

I don't understand this despite of computer scientists.

On 08/06/2018 17:39, Scott Lurndal wrote:
> Richard Thiebaud <thieba...@aol.com> writes:
>> On 06/08/2018 08:27 AM, Ahem A Rivet's Shot wrote:
>>> On Thu, 7 Jun 2018 17:19:04 -0400
>>> Richard Thiebaud <thieba...@aol.com> wrote:
>>>
>>>> They are computer scientists, not computer engineers. They are not
>>>> supposed to be developing practical applications.
>>>
>>> 	s/supposed to be/safe/
>>>
>> Change back to "supposed to be".
> 
> I don't understand this despite of computer scientists.
> 

The World needs the computer so-called scientists like a fish needs a 
bicycle?

On 2018-06-04 11:20 AM, Charlie Gibbs wrote:

> 
> I admit that there are probably cases where recursion is an elegant
> solution to the problem.  However, in my experience such cases are
> few and far between.  I've always considered an obsession with
> recursion to be a hallmark of the CS weenie.
> 

The one clear winner I know about is compiler parsing I have done it
both ways. Recursive parsers are significantly shorter and faster.

w..

On Mon, 11 Jun 2018 16:34:58 -0400, Walter Banks wrote:

> On 2018-06-04 11:20 AM, Charlie Gibbs wrote:
> 
> 
>> I admit that there are probably cases where recursion is an elegant
>> solution to the problem.  However, in my experience such cases are few
>> and far between.  I've always considered an obsession with recursion to
>> be a hallmark of the CS weenie.
>> 
>> 
> The one clear winner I know about is compiler parsing I have done it
> both ways. Recursive parsers are significantly shorter and faster.

If I want a quick parser, I do it recursively. Otherwise I take the time 
and do a table driven one. I believe they are actually faster!

(table driven might mean using yacc/lex or bison/flex, or rolling my own)



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org