Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » The birth of BASIC
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: The birth of BASIC [message #368643 is a reply to message #368495] Tue, 05 June 2018 06:43 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
In article <r1c6hd9alvtcdvjo0sea4qc8ldp1tvd0em@4ax.com>,
Gene Wirchenko <genew@telus.net> wrote:
> To get specific, a tiny BASIC (interpreted) could be implemented
> in 2K. A compiler needs a lot more.

I don't think the Dartmouth compiler was much bigger than that since mainframe memory
in the 1960s was very expensive, but they did have fast disks.

--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: The birth of BASIC [message #368646 is a reply to message #368202] Tue, 05 June 2018 07:43 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Kerr-Mudd,John

On Tue, 05 Jun 2018 08:27:55 GMT, Huge <Huge@nowhere.much.invalid> wrote:


[some lines snipped]
>
> (Note for American readers; whenever I say "biscuit" in the following,
> please read "cookie" instead!)
>

I refuse cookies as a matter of principle!
[]

--
Bah, and indeed, Humbug.
Re: The birth of BASIC [message #368647 is a reply to message #368641] Tue, 05 June 2018 07:51 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Kerr-Mudd,John

On Tue, 05 Jun 2018 08:26:10 GMT, Ahem A Rivet's Shot
<steveo@eircom.net> wrote:

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

An interesting game I'd not come across before: there's a DOS version
here:
https://archive.org/details/HEXPLODE
"Creator Ray Jensen"

--
Bah, and indeed, Humbug.
Re: The birth of BASIC [message #368648 is a reply to message #368647] Tue, 05 June 2018 09:09 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Tue, 5 Jun 2018 11:51:47 -0000 (UTC)
"Kerr-Mudd,John" <notsaying@invalid.org> wrote:

> On Tue, 05 Jun 2018 08:26:10 GMT, Ahem A Rivet's Shot
> <steveo@eircom.net> wrote:
>
>> 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.
>>
>
> An interesting game I'd not come across before: there's a DOS version
> here:
> https://archive.org/details/HEXPLODE
> "Creator Ray Jensen"

Thanks, that seems to settle 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/
Re: The birth of BASIC [message #368657 is a reply to message #368619] Tue, 05 June 2018 10:17 Go to previous messageGo to next message
Andrew Swallow is currently offline  Andrew Swallow
Messages: 1705
Registered: January 2012
Karma: 0
Senior Member
On 04/06/2018 22:40, Joe Pfeiffer wrote:
> 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.
>

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.
Re: The birth of BASIC [message #368659 is a reply to message #368202] Tue, 05 June 2018 10:36 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Gareth's Downstairs Computer

On 05/06/2018 09:27, Huge wrote:
>
> Early on in my career, I spent a couple of years writing process control
> software for United Biscuits;

> We
> also got an allowance of free product and you were allowed to help
> yourself off the production lines.
>
> I put on a lot of weight.
>
>

Early on in my career, I spent a few summer holidays from school
working at Hale's Cakes in Clevedon.

They said eat what you want on the first day, but on the second
you never wanted to eat any of it again!

Working on the Battenburg production line, it was surprising how
much went to pig swill as a matter of course.
Re: The birth of BASIC [message #368662 is a reply to message #368202] Tue, 05 June 2018 11:31 Go to previous messageGo to next message
Alfred Falk is currently offline  Alfred Falk
Messages: 195
Registered: June 2012
Karma: 0
Senior Member
Huge <Huge@nowhere.much.invalid> wrote in
news:fnn022FfnnvU3@mid.individual.net:

> On 2018-06-05, AndyW <Andy@nojunqmail.com> wrote:
>> On 04/06/2018 12:29, Gareth's Downstairs Computer wrote:
>
> [19 lines snipped]
>
>>> Looks like computer scientism and not real-life programming.
>
> [Not sure why I'm responding to a topic started by a troll]
>
>> Nope. Definitely real-life coding.
>
> Absolutely. I've worked on two database systems (MUMPS and one on Data
> General whose name I cannot remember) which used tree structures.
> Recursion was a standard and everyday technique for walking those
> trees.

INFOS? Must be forgettable, because I couldn't remember and had to poke
through my archives to find that name. They had another one with lots of
glossy promo material but it was uselessly slow and I can't remember its
name either.
Re: The birth of BASIC [message #368665 is a reply to message #368600] Tue, 05 June 2018 12:02 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Quadibloc <jsavard@ecn.ab.ca> wrote:
> 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.

<g>

--
Pete
Re: The birth of BASIC [message #368666 is a reply to message #368603] Tue, 05 June 2018 12:02 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
<hancock4@bbs.cpcn.com> wrote:
> 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.

BTDT. I used to work on several programs at once, so one could be waiting
for a debug run, another in keypunching, and a third (or more) being coded.

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

Nowadays (from what I've seen, I'm happily out of the rat race) they expect
you to work your regular hours plus whatever time you need at home to fix
some "urgent" problem that could easily wait on nights and weekends. (
without extra pay or comp time, of course).

--
Pete
Re: The birth of BASIC [message #368667 is a reply to message #368646] Tue, 05 June 2018 12:02 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Kerr-Mudd,John <notsaying@invalid.org> wrote:
> On Tue, 05 Jun 2018 08:27:55 GMT, Huge <Huge@nowhere.much.invalid> wrote:
>
>
> [some lines snipped]
>>
>> (Note for American readers; whenever I say "biscuit" in the following,
>> please read "cookie" instead!)
>>
>
> I refuse cookies as a matter of principle!
> []
>

I agree to accept cookies.

--
Pete
Re: The birth of BASIC [message #368673 is a reply to message #368665] Tue, 05 June 2018 15:26 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: JimP

On Tue, 5 Jun 2018 12:02:25 -0400, Peter Flass <peter_flass@yahoo.com>
wrote:

> Quadibloc <jsavard@ecn.ab.ca> wrote:
>> 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.
>
> <g>

Or 1/60 or 1/400.
Re: The birth of BASIC [message #368675 is a reply to message #368643] Tue, 05 June 2018 15:42 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Sarr Blumson

John Levine <johnl@taugh.com> Wrote in message:
> In article <r1c6hd9alvtcdvjo0sea4qc8ldp1tvd0em@4ax.com>,
> Gene Wirchenko <genew@telus.net> wrote:
>> To get specific, a tiny BASIC (interpreted) could be implemented
>> in 2K. A compiler needs a lot more.
>
> I don't think the Dartmouth compiler was much bigger than that since mainframe memory
> in the 1960s was very expensive, but they did have fast disks.

The 225/235 had 16k 20 bit words. By convention the upper 8k was
read only system code, roughly 2k for the OS and 6k for the
"system program" eg the compiler and runtime library. The lower
8k was similarly divided into 2k of data for the OS and 6k for
the program. The user program was compiled into the 6k data
space.

BASIC was small enough to fit the compiler and runtime into one 6k
load but ALGOL, for example was not. The scheduler was smart
enough to put user jobs that used the same "high segment"
together to save having to reload it, because the disks weren't
actually all that fast by modern standards. 100 msec seeks. And
you could see the data transfer in the lights.

Far more than you wanted to know.

Sarr




--


----Android NewsGroup Reader----
http://usenet.sinaapp.com/
Re: The birth of BASIC [message #368685 is a reply to message #368202] Tue, 05 June 2018 23:59 Go to previous messageGo to next message
Gene Wirchenko is currently offline  Gene Wirchenko
Messages: 1166
Registered: January 2012
Karma: 0
Senior Member
On 5 Jun 2018 08:27:55 GMT, Huge <Huge@nowhere.much.invalid> wrote:

[snip]

> (Note for American readers; whenever I say "biscuit" in the following,
> please read "cookie" instead!)

[snip]

> I wrote software that mixed biscuit dough, weighed the chocolate
> coating on biscuits, measured the thickness of biscuits (if they are
> too thick, the pack will not close properly, so you have to omit
> one and then the packets are underweight and cannot legally be sold)
> and most interestingly, weighed flying crisps.

Never mind biscuits vs. cookies! What are flying crisps?

[snip]

Sincerely,

Gene Wirchenko
Re: The birth of BASIC [message #368689 is a reply to message #368641] Wed, 06 June 2018 02:32 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: AndyW

On 05/06/2018 09:26, Ahem A Rivet's Shot wrote:
> 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.

Hexplode. That's the name! I think that the original was the BBC version
in PC Magazing in the early 80s, it was so simple to type in but so fun
to play that it spawned ports on lots of platforms.

Really enjoyable little game, I didn't have a BBC at the time (and my
little Acorn Atom could not handle it) but I had a Speccy Pascal
compiler and wrote a version for that. I also had White Lightning Forth
but I never managed to get it to run properly on that. It was the first
time I had ever seen recursion used for real and it made the code quite
simple.

Andy
Re: The birth of BASIC [message #368690 is a reply to message #368647] Wed, 06 June 2018 02:39 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: AndyW

On 05/06/2018 12:51, Kerr-Mudd,John wrote:
> On Tue, 05 Jun 2018 08:26:10 GMT, Ahem A Rivet's Shot
> <steveo@eircom.net> wrote:
>
>> 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.
>>
>
> An interesting game I'd not come across before: there's a DOS version
> here:
> https://archive.org/details/HEXPLODE
> "Creator Ray Jensen"

Without exaggeration this game changed the way I thought about
programming. I was a standard procedural BASIC / assembler programmer
and programming this my way would have taken a lot of work and a lot of
code.
Once I had worked out what was happening it was a light bulb moment for me.


Andy
Re: The birth of BASIC [message #368720 is a reply to message #368580] Wed, 06 June 2018 13:13 Go to previous messageGo to next message
usenet is currently offline  usenet
Messages: 556
Registered: May 2013
Karma: 0
Senior Member
On Mon, 4 Jun 2018 12:35:24 +0100, 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.

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?
Re: The birth of BASIC [message #368721 is a reply to message #368583] Wed, 06 June 2018 13:14 Go to previous messageGo to next message
usenet is currently offline  usenet
Messages: 556
Registered: May 2013
Karma: 0
Senior Member
On Mon, 04 Jun 2018 09:19:42 -0400, Dan Espen <dan1espen@gmail.com> wrote:
> 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.

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.
Re: The birth of BASIC [message #368736 is a reply to message #368721] Wed, 06 June 2018 16:58 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Questor <usenet@only.tnx> wrote:
> On Mon, 04 Jun 2018 09:19:42 -0400, Dan Espen <dan1espen@gmail.com> wrote:
>> 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.
>
> 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
Re: The birth of BASIC [message #368749 is a reply to message #368675] Wed, 06 June 2018 23:16 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: weiner

In article <pf6p3h$g5u$1@dont-email.me>,
Sarr Blumson <sarr.blumson@alum.dartmouth.orgq> wrote:
> John Levine <johnl@taugh.com> Wrote in message:
>> In article <r1c6hd9alvtcdvjo0sea4qc8ldp1tvd0em@4ax.com>,
>> Gene Wirchenko <genew@telus.net> wrote:
>>> To get specific, a tiny BASIC (interpreted) could be implemented
>>> in 2K. A compiler needs a lot more.
>>
>> I don't think the Dartmouth compiler was much bigger than that since
> mainframe memory
>> in the 1960s was very expensive, but they did have fast disks.
>
> The 225/235 had 16k 20 bit words. By convention the upper 8k was
> read only system code, roughly 2k for the OS and 6k for the
> "system program" eg the compiler and runtime library. The lower
> 8k was similarly divided into 2k of data for the OS and 6k for
> the program. The user program was compiled into the 6k data
> space.
>
> BASIC was small enough to fit the compiler and runtime into one 6k
> load but ALGOL, for example was not. The scheduler was smart
> enough to put user jobs that used the same "high segment"
> together to save having to reload it, because the disks weren't
> actually all that fast by modern standards. 100 msec seeks. And
> you could see the data transfer in the lights.
>
> Far more than you wanted to know.

[smw] But it brings back lots of good memories.

[smw] The first system I was paid to use was a GE-265 run
by Pillsbury's Call-A-Computer division.

[smw] In Fortran (II as I recall) there was a trick of
using a negative index into an array to get various pieces
of system information from the OS area.

[smw] In addition to BASIC, ALGOL, and Fortran, there was
also LISP 1.5 available.

[smw] What was more fun than watching the disk lights was
watching the arms move. The disk drive on the system I used
was in a big box with windows so you could see this happen.

[smw] On a different branch of this topic, in high school for
my junior year, we handed in coding sheets which were punched
by the school department's key punchers and taken by our
teacher to first Harvard (7094) and later a defense contractor
(360/20 IIRC.) We usually got the cards and printout a week later.
The next year's class got to use a TTY33 to access the GE-265.

Sam
Re: The birth of BASIC [message #368786 is a reply to message #368720] Thu, 07 June 2018 13:32 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2018-06-06, Questor <usenet@only.tnx> wrote:

> On Mon, 4 Jun 2018 12:35:24 +0100, Gareth's Downstairs Computer
> <headstone255.but.not.these.five.words@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
Re: The birth of BASIC [message #368788 is a reply to message #368749] Thu, 07 June 2018 13:49 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Sarr Blumson

weiner@TheWorld.com (Sam Weiner) Wrote in message:
>
>
> [smw] The first system I was paid to use was a GE-265 run
> by Pillsbury's Call-A-Computer division.

235 + (Datanet)30 = 265. Thank you GE marketing.

> [smw] In addition to BASIC, ALGOL, and Fortran, there was
> also LISP 1.5 available.

FORTRAN was the only piece not developed at Dartmouth. GE's
refusal to let us use that was a source of much conversation.
:)

Sarr


----Android NewsGroup Reader----
http://usenet.sinaapp.com/
Re: The birth of BASIC [message #368797 is a reply to message #368736] Thu, 07 June 2018 14:42 Go to previous messageGo to next message
usenet is currently offline  usenet
Messages: 556
Registered: May 2013
Karma: 0
Senior Member
On Wed, 6 Jun 2018 16:58:25 -0400, Peter Flass <peter_flass@yahoo.com> wrote:
> Questor <usenet@only.tnx> wrote:
>> On Mon, 04 Jun 2018 09:19:42 -0400, Dan Espen <dan1espen@gmail.com> wrote:
>>> 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.
>>
>> 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.
Re: The birth of BASIC [message #368802 is a reply to message #368797] Thu, 07 June 2018 15:10 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
usenet@only.tnx (Questor) writes:
> On Wed, 6 Jun 2018 16:58:25 -0400, Peter Flass <peter_flass@yahoo.com> wrote:
>> Questor <usenet@only.tnx> wrote:
>>> On Mon, 04 Jun 2018 09:19:42 -0400, Dan Espen <dan1espen@gmail.com> wrote:
>>>> 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.
>>>
>>> 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.
>
Re: The birth of BASIC [message #368811 is a reply to message #368786] Thu, 07 June 2018 17:19 Go to previous messageGo to next message
Richard Thiebaud is currently offline  Richard Thiebaud
Messages: 222
Registered: May 2013
Karma: 0
Senior Member
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.not.these.five.words@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.
Re: The birth of BASIC [message #368834 is a reply to message #368811] Fri, 08 June 2018 08:27 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Thu, 7 Jun 2018 17:19:04 -0400
Richard Thiebaud <thiebauddick2@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/
Re: The birth of BASIC [message #368840 is a reply to message #368834] Fri, 08 June 2018 09:15 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Gareth's Downstairs Computer

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

And they're not scientists either, for they are not discovering anything
about the computers that was not known about by the designers.

Mathematical dream world hobbyists might be a better description?
Re: The birth of BASIC [message #368842 is a reply to message #368834] Fri, 08 June 2018 10:48 Go to previous messageGo to next message
Charles Richmond is currently offline  Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
Senior Member
On 6/8/2018 7:27 AM, Ahem A Rivet's Shot wrote:
> On Thu, 7 Jun 2018 17:19:04 -0400
> Richard Thiebaud <thiebauddick2@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
Re: The birth of BASIC [message #368851 is a reply to message #368834] Fri, 08 June 2018 12:03 Go to previous messageGo to next message
Richard Thiebaud is currently offline  Richard Thiebaud
Messages: 222
Registered: May 2013
Karma: 0
Senior Member
On 06/08/2018 08:27 AM, Ahem A Rivet's Shot wrote:
> On Thu, 7 Jun 2018 17:19:04 -0400
> Richard Thiebaud <thiebauddick2@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".
Re: The birth of BASIC [message #368852 is a reply to message #368851] Fri, 08 June 2018 12:39 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
Richard Thiebaud <thiebauddick2@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 <thiebauddick2@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.
Re: The birth of BASIC [message #368853 is a reply to message #368852] Fri, 08 June 2018 12:56 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Gareth's Downstairs Computer

On 08/06/2018 17:39, Scott Lurndal wrote:
> Richard Thiebaud <thiebauddick2@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 <thiebauddick2@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?
Re: The birth of BASIC [message #368857 is a reply to message #368643] Fri, 08 June 2018 14:36 Go to previous messageGo to next message
Alan Bowler is currently offline  Alan Bowler
Messages: 185
Registered: July 2012
Karma: 0
Senior Member
On 2018-06-05 6:43 AM, John Levine wrote:
> In article <r1c6hd9alvtcdvjo0sea4qc8ldp1tvd0em@4ax.com>,
> Gene Wirchenko <genew@telus.net> wrote:
>> To get specific, a tiny BASIC (interpreted) could be implemented
>> in 2K. A compiler needs a lot more.
>
> I don't think the Dartmouth compiler was much bigger than that since mainframe memory
> in the 1960s was very expensive, but they did have fast disks.
>

Well today the BASIC compiler on GCOS8
(essentially the Dartmouth compiler for the GE-635)
needs 13479 36-bit words (53916 9-bit bytes) to load.
Re: The birth of BASIC [message #368859 is a reply to message #368599] Fri, 08 June 2018 15:00 Go to previous messageGo to next message
Alan Bowler is currently offline  Alan Bowler
Messages: 185
Registered: July 2012
Karma: 0
Senior Member
On 2018-06-04 1:28 PM, 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.
>

I should have expanded a bit more. The 635 did have CPU timer
that was used to give programmed interrupts (used by the
CPU dispatcher). It worked in units of 1/64000 second.
Re: The birth of BASIC [message #368878 is a reply to message #368852] Sat, 09 June 2018 08:24 Go to previous messageGo to next message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On Fri, 08 Jun 2018 16:39:11 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> Richard Thiebaud <thiebauddick2@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 <thiebauddick2@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.

Nothing against them at all, so long as they stick to writing
papers and books exploring data structures, algorithms, language paradigms
and all that other fundamental stuff that eventually leads to useful tools
or helps us pick the right tool for a job because someone took the time to
analyse it in detail.

Get one writing code for a project with a deadline that has to be
maintained by trained monkeys for the next decade and they're a real
liability.

--
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 #368909 is a reply to message #368878] Sun, 10 June 2018 22:24 Go to previous messageGo to next message
Richard Thiebaud is currently offline  Richard Thiebaud
Messages: 222
Registered: May 2013
Karma: 0
Senior Member
On 06/09/2018 08:24 AM, Ahem A Rivet's Shot wrote:
> On Fri, 08 Jun 2018 16:39:11 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> Richard Thiebaud <thiebauddick2@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 <thiebauddick2@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.
>
> Nothing against them at all, so long as they stick to writing
> papers and books exploring data structures, algorithms, language paradigms
> and all that other fundamental stuff that eventually leads to useful tools
> or helps us pick the right tool for a job because someone took the time to
> analyse it in detail.
>
> Get one writing code for a project with a deadline that has to be
> maintained by trained monkeys for the next decade and they're a real
> liability.
>
Yes, that's the difference between a scientist and an engineer.
Re: The birth of BASIC [message #368932 is a reply to message #368592] Mon, 11 June 2018 16:34 Go to previous messageGo to next message
Walter Banks is currently offline  Walter Banks
Messages: 1000
Registered: July 2012
Karma: 0
Senior Member
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..
Re: The birth of BASIC [message #368935 is a reply to message #368932] Mon, 11 June 2018 17:07 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Bob Eager

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
Re: The birth of BASIC [message #368983 is a reply to message #368878] Wed, 13 June 2018 16:11 Go to previous messageGo to next message
Jorgen Grahn is currently offline  Jorgen Grahn
Messages: 606
Registered: March 2012
Karma: 0
Senior Member
On Sat, 2018-06-09, Ahem A Rivet's Shot wrote:

[computer scientists]

> Nothing against them at all, so long as they stick to writing
> papers and books exploring data structures, algorithms, language paradigms
> and all that other fundamental stuff that eventually leads to useful tools
> or helps us pick the right tool for a job because someone took the time to
> analyse it in detail.
>
> Get one writing code for a project with a deadline that has to be
> maintained by trained monkeys for the next decade and they're a real
> liability.

Donald Knuth always claimed he's a "programmer".

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Re: The birth of BASIC [message #368996 is a reply to message #368983] Thu, 14 June 2018 06:10 Go to previous message
Ahem A Rivet's Shot is currently offline  Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
Senior Member
On 13 Jun 2018 20:11:11 GMT
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

> On Sat, 2018-06-09, Ahem A Rivet's Shot wrote:
>
> [computer scientists]
>
>> Nothing against them at all, so long as they stick to writing
>> papers and books exploring data structures, algorithms, language
>> paradigms and all that other fundamental stuff that eventually leads to
>> useful tools or helps us pick the right tool for a job because someone
>> took the time to analyse it in detail.
>>
>> Get one writing code for a project with a deadline that has to
>> be maintained by trained monkeys for the next decade and they're a real
>> liability.
>
> Donald Knuth always claimed he's a "programmer".

Very justifiably too TeX is a magnificent piece of work, but wrt.
deadlines TAOCP Volume 4 seems a trifle late.

--
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/
Pages (4): [ «    1  2  3  4]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Mannix season 1 coming soon
Next Topic: Re: Weeks? hah!!
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 06:56:04 EDT 2024

Total time taken to generate the page: 0.02152 seconds