| Re: The birth of BASIC [message #368507 is a reply to message #368490] |
Sun, 03 June 2018 09:18   |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 02 Jun 2018 16:07:09 -0400
Andreas Kohlbach <ank@spamfence.net> wrote:
> I guess I am missing a link here. Why did none of the BASICs coming with
> the 8bit micros need a compiler and rather interpret the code instead?
Because for an interactive system where the language and the CLI
are one and the same (most 8 bit home micros) an interpreted language is
pretty much essential.
--
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/
|
|
|
|
| Re: The birth of BASIC [message #368512 is a reply to message #368492] |
Sun, 03 June 2018 09:57 |
Andrew Swallow
Messages: 1705
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 02/06/2018 22:19, Peter Flass wrote:
> Gareth's Downstairs Computer
> <headstone255.but.not.these.five.words@yahoo.com> wrote:
>> On 02/06/2018 18:37, Andrew Swallow wrote:
>>> On 02/06/2018 18:32, Gareth's Downstairs Computer wrote:
>>>> On 02/06/2018 17:26, Andrew Swallow wrote:
>>>> > On 02/06/2018 12:27, Gareth's Downstairs Computer wrote:
>>>> >> On 02/06/2018 06:44, Charles Richmond wrote:
>>>> >>>
>>>> >>> On the DEC-20, BASIC Plus 2 had a lot of enhancements to plain
>>>> >>> BASIC. I never used it much, but some I knew at university did
>>>> >>> fairly complex projects using this BASIC.
>>>> >>>
>>>> >>
>>>> >> Yes, but save from some contextual limitations (execution speed,
>>>> >> storage space, etc) to a well designed project, the implementation
>>>> >> language is irrelevant.
>>>> >>
>>>> >>
>>>> > If the computer language cannot handle character you soon hit problems.
>>>>
>>>>
>>>> All the languages with which I've been involved from the very lowest
>>>> to PASCAL and FORTRAN, had an inalienable capability to deal with
>>>> all forms of data having binary representations.
>>>>
>>>> You don't hit a problem if you need a couple of hours' work to turn in
>>>> string handling capabilities; after all, the C language has no string
>>>> handling facilities, and relies on a string library, and, usually, a
>>>> CHAR data type defined in terms of its binary size and signing.
>>>>
>>>
>>> The ICL 1900 read characters into integers in A1 format. IF statements
>>> compared by subtracting which resulted in overflow.
>>
>> I know not what is A1 format, but awareness of such a problem makes it
>> seem to be a simple matter to adjust values or else to translate to
>> an internal format.
>>
>>
>
> A1 stores input one character per word, so you lose somewhere between 75%
> and 84% of your memory, in return for having something that is a bit easier
> to handle. Otherwise you have to shift and mask to manipulate characters.
>
Also Fortran did not support shifting and masking. The programmer would
have to use division.
|
|
|
|
| Re: The birth of BASIC [message #368514 is a reply to message #368486] |
Sun, 03 June 2018 10:02 |
Andrew Swallow
Messages: 1705
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 02/06/2018 20:11, hancock4@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.
|
|
|
|
| Re: The birth of BASIC [message #368523 is a reply to message #368502] |
Sun, 03 June 2018 11:19 |
|
|
Originally posted by: Gareth's Downstairs Computer
On 03/06/2018 08:06, David Wade wrote:
> On 02/06/2018 21:07, Andreas Kohlbach wrote:
>> On Sat, 2 Jun 2018 12:23:56 +0100, Gareth's Downstairs Computer wrote:
>>>
>>> On 02/06/2018 03:44, John Levine wrote:
>>>> In article <cb11f87e-44a9-4f0b-b4b3-998177600274@googlegroups.com>,
>>>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>>>
>>>> Dartmouth's compiler was quite impressive, typically compiling an
>>>> entire program in one or two clock ticks. It was so fast that nobody
>>>> bothered to save object code.
>>>
>>> Interesting, does that also indicate interactive development where
>>> the compilation speed would be largely unapparent?
>>
>> I guess I am missing a link here. Why did none of the BASICs coming with
>> the 8bit micros need a compiler and rather interpret the code instead?
>>
> I guess in the early days there were not many folks with the cash for a
> floppy disk drive. Given you are working with tape loading and running
> from memory is attractive...
Well it certainly was a pain in the bum on an early PDP11/20 with a 10
chars per sec tape reader on the teletype!
3/4 hour to load the editor, then another 3/4 hour to load the assembler,
not to even mention the two passes of source through the assembler!
|
|
|
|
| Re: The birth of BASIC [message #368524 is a reply to message #368507] |
Sun, 03 June 2018 11:22 |
|
|
Originally posted by: Gareth's Downstairs Computer
On 03/06/2018 14:18, Ahem A Rivet's Shot wrote:
> On Sat, 02 Jun 2018 16:07:09 -0400
> Andreas Kohlbach <ank@spamfence.net> wrote:
>
>> I guess I am missing a link here. Why did none of the BASICs coming with
>> the 8bit micros need a compiler and rather interpret the code instead?
>
> Because for an interactive system where the language and the CLI
> are one and the same (most 8 bit home micros) an interpreted language is
> pretty much essential.
>
For compactness (and also write-only-non-readable code) FORTH takes the
biscuit.
Unfortunately some big systems have been implemented in FORTH, but only
because the programmer with ten year's experience had only 1 week's
experience repeated 519 times :-(
|
|
|
|
| Re: The birth of BASIC [message #368525 is a reply to message #368514] |
Sun, 03 June 2018 11:24 |
|
|
Originally posted by: Gareth's Downstairs Computer
On 03/06/2018 15:02, Andrew Swallow wrote:
> On 02/06/2018 20:11, hancock4@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.
|
|
|
|
| Re: The birth of BASIC [message #368530 is a reply to message #368525] |
Sun, 03 June 2018 11:53 |
Andrew Swallow
Messages: 1705
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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, hancock4@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).
|
|
|
|
| Re: The birth of BASIC [message #368532 is a reply to message #368530] |
Sun, 03 June 2018 12:13 |
|
|
Originally posted by: J. Clarke
On Sun, 3 Jun 2018 16:53:10 +0100, Andrew Swallow
<am.swallow@btinternet.com> wrote:
> 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, hancock4@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).
If it's a variable number of loops you just specify the number of
loops in a variable.
Where recursion helps is when you don't know at the time you start the
process how many branches there are going to be.
|
|
|
|
|
|
| Re: The birth of BASIC [message #368551 is a reply to message #368493] |
Sun, 03 June 2018 17:40 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> wrote:
> On Sat, 02 Jun 2018 16:07:09 -0400, Andreas Kohlbach
> <ank@spamfence.net> wrote:
>
>> On Sat, 2 Jun 2018 12:23:56 +0100, Gareth's Downstairs Computer wrote:
>>>
>>> On 02/06/2018 03:44, John Levine wrote:
>>>> In article <cb11f87e-44a9-4f0b-b4b3-998177600274@googlegroups.com>,
>>>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>>>
>>>> Dartmouth's compiler was quite impressive, typically compiling an
>>>> entire program in one or two clock ticks. It was so fast that nobody
>>>> bothered to save object code.
>>>
>>> Interesting, does that also indicate interactive development where
>>> the compilation speed would be largely unapparent?
>>
>> I guess I am missing a link here. Why did none of the BASICs coming with
>> the 8bit micros need a compiler and rather interpret the code instead?
>
> I think the real issue is the nature of a compiler and cost and
> availability of hardware.
>
> A compiler takes a source program, generates an object program, and
> then to actually do anything you need to load and execute the object
> program.
>
> To make this work you need to have enough storage of some kind (paper
> tape, mag tape, disk, drum, RAM, doesn't matter, you need to have
> enough) to store all the pieces. Early micros did not have much RAM
> and typically if they had a storage device other than the operator's
> paper notebook it was paper tape or an audio cassette recorder, so
> turnaround time for compiled code would be slow.
>
> An interpreter only needs storage for the source code, a scratchpad,
> and the output, so it can run reasonably well on a machine with
> limited RAM and a slow storage device, hence the popularity on early
> hobbyist micros (and yes, to the nits who think that hobbyists are
> only allowed to own toys, I mean the ALTAIR and its clones).
>
Good point.
--
Pete
|
|
|
|
| Re: The birth of BASIC [message #368552 is a reply to message #368525] |
Sun, 03 June 2018 17:40 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Gareth's Downstairs Computer
<headstone255.but.not.these.five.words@yahoo.com> wrote:
> On 03/06/2018 15:02, Andrew Swallow wrote:
>> On 02/06/2018 20:11, hancock4@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
|
|
|
|
| Re: The birth of BASIC [message #368564 is a reply to message #368456] |
Sun, 03 June 2018 22:50 |
Joe Pfeiffer
Messages: 764
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> writes:
> On Fri, 1 Jun 2018 11:06:54 -0700 (PDT), hancock4@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.
>
> At the time APL was like BASIC on steroids. Easy to learn,
> interactive, immensely capable, but could take the rest of your life
> to completely master.
Also, could take you the rest of your life to figure out the code you
wrote last week...
|
|
|
|
| Re: The birth of BASIC [message #368565 is a reply to message #368564] |
Sun, 03 June 2018 23:07 |
|
|
Originally posted by: J. Clarke
On Sun, 03 Jun 2018 20:50:59 -0600, Joe Pfeiffer
<pfeiffer@cs.nmsu.edu> wrote:
> J. Clarke <jclarke.873638@gmail.com> writes:
>
>> On Fri, 1 Jun 2018 11:06:54 -0700 (PDT), hancock4@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.
>>
>> At the time APL was like BASIC on steroids. Easy to learn,
>> interactive, immensely capable, but could take the rest of your life
>> to completely master.
>
> Also, could take you the rest of your life to figure out the code you
> wrote last week...
It's not really that bad. I get paid these days to figure out APL
code that somebody else wrote 20 years ago, and it's actually not as
hard as it's made out to be.
Admittely, sometimes I have to go a symbol at a time and rewrite
whatever it does in Python then run the Python to make sure that my
understanding is correct . . .
|
|
|
|
|
|
| Re: The birth of BASIC [message #368572 is a reply to message #368569] |
Mon, 04 June 2018 06:28 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Gareth's Downstairs Computer
<headstone255.but.not.these.five.words@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
|
|
|
|
| Re: The birth of BASIC [message #368578 is a reply to message #368572] |
Mon, 04 June 2018 07:13 |
|
|
Originally posted by: Bob Eager
On Mon, 04 Jun 2018 06:28:37 -0400, Peter Flass wrote:
> Gareth's Downstairs Computer
> <headstone255.but.not.these.five.words@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
|
|
|
|
| Re: The birth of BASIC [message #368579 is a reply to message #368572] |
Mon, 04 June 2018 07:29 |
|
|
Originally posted by: Gareth's Downstairs Computer
On 04/06/2018 11:28, Peter Flass wrote:
> Gareth's Downstairs Computer
> <headstone255.but.not.these.five.words@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.
>
Looks like computer scientism and not real-life programming.
|
|
|
|
| Re: The birth of BASIC [message #368580 is a reply to message #368578] |
Mon, 04 June 2018 07:35 |
|
|
Originally posted by: Gareth's Downstairs Computer
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.not.these.five.words@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.
|
|
|
|
| Re: The birth of BASIC [message #368581 is a reply to message #368532] |
Mon, 04 June 2018 08:38 |
Andrew Swallow
Messages: 1705
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 03/06/2018 17:13, J. Clarke wrote:
> On Sun, 3 Jun 2018 16:53:10 +0100, Andrew Swallow
> <am.swallow@btinternet.com> wrote:
>
>> 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, hancock4@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).
>
> If it's a variable number of loops you just specify the number of
> loops in a variable.
>
> Where recursion helps is when you don't know at the time you start the
> process how many branches there are going to be.
>
A variable may contain the number of times you loop but rarely the
number of FOR statements active
|
|
|
|
| Re: The birth of BASIC [message #368583 is a reply to message #368572] |
Mon, 04 June 2018 09:19 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Gareth's Downstairs Computer
> <headstone255.but.not.these.five.words@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
|
|
|
|
| Re: The birth of BASIC [message #368589 is a reply to message #368437] |
Mon, 04 June 2018 10:56 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Andreas Kohlbach <ank@spamfence.net> writes:
> On Fri, 1 Jun 2018 14:33:09 +0100, Gareth's Downstairs Computer wrote:
>>
>> BASIC (an acronym) is Beginner's All Purpose Instruction Code
>
> Interestingly the first versions of MS BASIC were also an "operating
> system" on the MITS Altair. When loaded it did also I/O for mass media
> devices like floppy disk and possibly punched cards.
FWIW, The oxford dictionaries claim BASIC is a backronym, not an acronym.
|
|
|
|
|
|
| Re: The birth of BASIC [message #368592 is a reply to message #368580] |
Mon, 04 June 2018 11:20 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2018-06-04, Gareth's Downstairs Computer
<headstone255.but.not.these.five.words@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.not.these.five.words@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
|
|
|
|
| Re: The birth of BASIC [message #368593 is a reply to message #368592] |
Mon, 04 June 2018 11:43 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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/
|
|
|
|
| Re: The birth of BASIC [message #368597 is a reply to message #368445] |
Mon, 04 June 2018 12:57 |
Alan Bowler
Messages: 185
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On 2018-06-01 6:21 PM, Quadibloc wrote:
> On Friday, June 1, 2018 at 3:09:44 PM UTC-6, Sarr Blumson wrote:
>
>> And, to kick one of my favorite dead horses, Dartmouth BASIC was
>> NOT an interpreter. It compiled to real machine code. Other
>> implementations varied.
>
> Yes, that's quite true, it was, I presume, one of those "load-and-go" compiler
> systems; quite a few of those had already been written for FORTRAN by that time.
>
> But _after_ Dartmouth BASIC, nearly all the other implementations were
> interpreters.
BASIC under GECOS TSS on the 635 was a compiler.
Actually, today it STILL IS although the machines with
that architecture are called DPS-9000, and GECOS renamed GCOS8.
However, it is essentially the same BASIC as the Dartmouth
implementation under DTSS on the 635.
|
|
|
|
| Re: The birth of BASIC [message #368598 is a reply to message #368469] |
Mon, 04 June 2018 13:12 |
Alan Bowler
Messages: 185
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On 2018-06-02 7:23 AM, Gareth's Downstairs Computer wrote:
> On 02/06/2018 03:44, John Levine wrote:
>> Dartmouth's compiler was quite impressive,
>> typically compiling an entire program in one or
>> two clock ticks. It was so fast that nobody
>> bothered to save object code.
Since the 635 and several generations of successors
were asynchronous machines I'm not clear what is
meant by "clock tick"
>
> Interesting, does that also indicate interactive
> development where
> the compilation speed would be largely unapparent?
*date
06/04/18 10:08:23
*list
10 let x=0
20 for i= 1 to 10
30 let x = x + i
40 next i
50 print x
*run
55
ready
*date
06/04/18 10:08:23
|
|
|
|
| Re: The birth of BASIC [message #368599 is a reply to message #368598] |
Mon, 04 June 2018 13:28 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Monday, June 4, 2018 at 11:12:41 AM UTC-6, Alan Bowler wrote:
> On 2018-06-02 7:23 AM, Gareth's Downstairs Computer wrote:
>> On 02/06/2018 03:44, John Levine wrote:
>
>>> Dartmouth's compiler was quite impressive,
>>> typically compiling an entire program in one or
>>> two clock ticks. It was so fast that nobody
>>> bothered to save object code.
>
> Since the 635 and several generations of successors
> were asynchronous machines I'm not clear what is
> meant by "clock tick"
I don't think any compiler, no matter how impresive, could compile a program of
any length in two processor clock cycles.
Compiling one in *two seconds* of wall-clock time, however, is perfectly
possible, and it would have been impressive on a computer made from discrete
transistors.
So I think the problem is that he meant a completely different kind of "clock
tick" from the kind you were thinking of that the GE 635 didn't have.
John Savard
|
|
|
|
| Re: The birth of BASIC [message #368600 is a reply to message #368599] |
Mon, 04 June 2018 13:31 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Monday, June 4, 2018 at 11:28:18 AM UTC-6, Quadibloc wrote:
> On Monday, June 4, 2018 at 11:12:41 AM UTC-6, Alan Bowler wrote:
>> On 2018-06-02 7:23 AM, Gareth's Downstairs Computer wrote:
>>> On 02/06/2018 03:44, John Levine wrote:
>>>> Dartmouth's compiler was quite impressive,
>>>> typically compiling an entire program in one or
>>>> two clock ticks. It was so fast that nobody
>>>> bothered to save object code.
>> Since the 635 and several generations of successors
>> were asynchronous machines I'm not clear what is
>> meant by "clock tick"
> I don't think any compiler, no matter how impresive, could compile a program of
> any length in two processor clock cycles.
> Compiling one in *two seconds* of wall-clock time, however, is perfectly
> possible, and it would have been impressive on a computer made from discrete
> transistors.
> So I think the problem is that he meant a completely different kind of "clock
> tick" from the kind you were thinking of that the GE 635 didn't have.
Or it could have even been able to compile a program in 1/30 of a second, not
just two seconds - which would be two 1/60 second "ticks" of the computer's
real-time clock... at least, many mainframes of that era synchronized their real
time clock to the mains frequency.
Oops, the AC power frequency. If they called it _that_, it would be 1/50 second.
John Savard
|
|
|
|
| Re: The birth of BASIC [message #368601 is a reply to message #368592] |
Mon, 04 June 2018 15:05 |
Joe Pfeiffer
Messages: 764
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> On 2018-06-04, Gareth's Downstairs Computer
> <headstone255.but.not.these.five.words@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.not.these.five.words@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...
|
|
|
|
| Re: The birth of BASIC [message #368602 is a reply to message #368490] |
Mon, 04 June 2018 15:28 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Saturday, June 2, 2018 at 4:07:10 PM UTC-4, Andreas Kohlbach wrote:
> I guess I am missing a link here. Why did none of the BASICs coming with
> the 8bit micros need a compiler and rather interpret the code instead?
FWIW, to provide some background:
When I bought my 286, it came with MS-DOS 3 which included GW-BASIC.
I went out and bought the M/S QuickBasic compiler, which cost about
$50 back then. (This was the much cheaper home version of the
"Professional BASIC"*). Some compiled programs ran much faster
than the GW version, and the development environment was easier.
QB included what later became the DOS EDIT (introduced as a standalone
in DOS 5.0, which also included a smaller QB).
Aside from being compiled, QB offered features to make better
use of memory and better buffering which sped up I/O. It also
allowed accessing interrupts, so one could program in handlers
for I/O device problems, e.g. paper not loaded or diskette not
inserted.
I purchased the book, QuickBasic Bible, which contained a
tremendous amount of useful information, including advanced
features.
* They later had a promotion for the Professional Version for $100
and I got it. But QB did virtually everything the PB did and I
rarely used the PB version. One feature was a currency data-type,
but I didn't need that.
|
|
|
|
| Re: The birth of BASIC [message #368603 is a reply to message #368506] |
Mon, 04 June 2018 15:38 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Sunday, June 3, 2018 at 9:30:04 AM UTC-4, Ahem A Rivet's Shot wrote:
>> From the late 1960s onward, many schools got Teletypes and timesharing
>> and offered BASIC classes.
>
> In the early to mid 70s our school had a Teletype, and there was a
> lunchtime BASIC class offered to a few of us. The Teletype did not connect
> to a timesharing service, it connected to another Teletype to send and
> receive paper tapes of programs to be run, and the results of yesterday's
> runs. Getting a syntax error back was a real time waster.
>
> The Teletype was only available to us during break and lunch. After
> school a sixth former would make the call and deal with the tapes whilst
> trying to chat up the operator at the other end.
OMG, that would be cumbersome--a 24 hour turnaround. I would think
that would be very discouraging to students--having to wait an
entire day only to learn a comma was left out, and then needing to
wait another day for another submission.
However, there were numerous times in industry in the 1980s and 1990s
where the company computer would be so busy with production work that
programmer work had to wait until overnight, so there was the similar
long wait for results.
In those days, we were often encouraged to work evening, late
night, or weekend hours to use the computer. People with families
didn't care for it since they missed family time. However, single
people liked it* because it gave them a lot of flexibility.
I liked it because I could take care of day chores, such as car
repair or doctor appts without taking time off from work--I'd just
work late or on a weekend to make up the time. I liked the flexibility.
However, I've noticed today that modern management is much less flexible
and expect staff to work on their prescribed schedule without any
deviation**. That kind of sucks.
* There were a few people going through a rough patch at home,
and they often worked odd hours to get out of the house.
** My neighbor was directed to fly to a different city, take a training
class, fly home, and report to work for the night shift, all in ONE
day. She'd be working basically 24 hours straight through. She'd
be only paid for one day; travel time and class time was not covered.
Indeed, I've heard of a lot of companies these days, including
government, having their workers take mandated training on their
own time, and even their own expense. To me, if a company requires
you to take certain training, they should cover all expenses of it.
|
|
|
|
| Re: The birth of BASIC [message #368604 is a reply to message #368514] |
Mon, 04 June 2018 15:44 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Sunday, June 3, 2018 at 10:02:43 AM UTC-4, Andrew Swallow wrote:
> On 02/06/2018 20:11, hancock4@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.
The earlier simpler versions of BASIC allowed only a branch in an
IF statement, e.g. IF A=B THEN {go to branch}. Later versions
allowed an imperative statement after the THEN as well as some
logical arrangement, such as ELSE. M/S QuickBasic allowed SELECT CASE.
My point is that even back circa 1970, programmers were making
their programs modular, even in BASIC. While it might not have
been "pure" structured programming, it was a step forward. By
then, programmers realized that in complicated programs spaghetti
code was bad and endeavored to avoid it.
As someone else mentioned, just having a "structured" program without
GOTO's did not eliminate the risk of creating confusing spaghetti code.
|
|
|
|
| Re: The birth of BASIC [message #368607 is a reply to message #368449] |
Mon, 04 June 2018 16:07 |
Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
Charles Richmond <numerist@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 news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: The birth of BASIC [message #368608 is a reply to message #368487] |
Mon, 04 June 2018 16:11 |
Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
hancock4@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 news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: The birth of BASIC [message #368609 is a reply to message #368603] |
Mon, 04 June 2018 16:31 |
|
|
Originally posted by: Gareth's Downstairs Computer
On 04/06/2018 20:38, hancock4@bbs.cpcn.com wrote:
>
> OMG, that would be cumbersome--a 24 hour turnaround. I would think
> that would be very discouraging to students--having to wait an
> entire day only to learn a comma was left out, and then needing to
> wait another day for another submission.
That was what happened in 1969 for we engineering students on
the FORTRAN course at Essex; Put your punched card deck in an
in-tray, and collect the output, wrapped around your card deck, the
following day.
'twas an ICL 1900 in them thar days.
|
|
|
|
| Re: The birth of BASIC [message #368610 is a reply to message #368609] |
Mon, 04 June 2018 16:42 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On Monday, June 4, 2018 at 4:31:09 PM UTC-4, Gareth's Downstairs Computer wrote:
> On 04/06/2018 20:38, hancock4@bbs.cpcn.com wrote:
>>
>> OMG, that would be cumbersome--a 24 hour turnaround. I would think
>> that would be very discouraging to students--having to wait an
>> entire day only to learn a comma was left out, and then needing to
>> wait another day for another submission.
>
> That was what happened in 1969 for we engineering students on
> the FORTRAN course at Essex; Put your punched card deck in an
> in-tray, and collect the output, wrapped around your card deck, the
> following day.
>
> 'twas an ICL 1900 in them thar days.
If I were in England, I'd have done anything to work with the
Leo/Lyons snake cake company and their early computer; both to get
computer work and get snack cakes.
https://en.wikipedia.org/wiki/LEO_(computer)
We had a tour of a commercial bakery back as kids. It amazes me
today we were taken back among the giant mixers and fermentation
room--a bunch of little kids sneezing and such.
Back then, the process seemed quite automated. The raw materials
were unloaded by air suction from freight trains and delivered
to the top floor. There they loaded to mixers, and passed by
chute to the lower floors for successive steps. I presume today
it is even more automated.
I wonder if there is still a Q/A dept were workers sampled by
eating the various products. They gave us plenty of free samples
to take home. We enjoyed that!
today
|
|
|
|
| Re: The birth of BASIC [message #368615 is a reply to message #368601] |
Mon, 04 June 2018 17:29 |
Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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.not.these.five.words@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.not.these.five.words@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
|
|
|
|
| Re: The birth of BASIC [message #368619 is a reply to message #368615] |
Mon, 04 June 2018 17:40 |
Joe Pfeiffer
Messages: 764
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Charles Richmond <numerist@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.not.these.five.words@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.not.these.five.words@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.
|
|
|
|
| Re: The birth of BASIC [message #368636 is a reply to message #368579] |
Tue, 05 June 2018 03:04 |
|
|
Originally posted by: AndyW
On 04/06/2018 12:29, Gareth's Downstairs Computer wrote:
> On 04/06/2018 11:28, Peter Flass wrote:
>> Gareth's Downstairs Computer
>> <headstone255.but.not.these.five.words@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.
>>
>
> Looks like computer scientism and not real-life programming.
Nope. Definitely real-life coding. I have used recursion for data
analysis and path finding, sneak circuit analysis and building and
solving mazes in game programming.
Even as far back as a game in BBC Basic in the 80s that used recursion
to handle the effects of a cell exploding in a board games called
'Hexplosion'. The game was a diamond shaped board made up of hexagons,
players took it in turn to click in a cell. Each cell could hold a
number on dots as large as the number of direct neighbour cells. Once
that limit was exceeded the cell explode sending a dot into all
neighbouring cells and changing it to their own colour. If any cell was
at the limit then it would explode... etc.
Recursion handles the explosions more efficiently than scanning the
underlying tables ever could. Nice little game.
Recursion is niche but a genuine real-life programming although you have
to be very careful not to eat up all the memory.
Andy
|
|
|
|
| Re: The birth of BASIC [message #368641 is a reply to message #368636] |
Tue, 05 June 2018 04:26 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Tue, 5 Jun 2018 08:04:23 +0100
AndyW <Andy@nojunqmail.com> wrote:
> Even as far back as a game in BBC Basic in the 80s that used recursion
> to handle the effects of a cell exploding in a board games called
> 'Hexplosion'. The game was a diamond shaped board made up of hexagons,
Hexplode when I saw it - A friend of mine wrote it for the Spectrum,
I'm not sure if he originated it or came across the game elsewhere, it was
the first time I saw it.
--
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/
|
|
|
|
Members
Search
Help
Register
Login
Home
