Groups > alt.folklore.computers > #161395 > unrolled thread

Which Books Can You Recommend For Learning Computer Programming?

Started by	Neo Fortune <serenity3043@gmail.com>
First post	2016-03-23 02:31 -0700
Last post	2016-03-30 14:56 +0100
Articles	20 on this page of 401 — 44 participants

Back to article view | Back to alt.folklore.computers

Page 2 of 21 — ← Prev page 1 [2] 3 4 … 21 Next page →

#161837

From	hancock4@bbs.cpcn.com
Date	2016-04-02 13:10 -0700
Message-ID	<c6b9da65-588a-40e4-91a2-fbef7af863a4@googlegroups.com>
In reply to	#161824

On Saturday, April 2, 2016 at 10:00:02 AM UTC-4, Ahem A Rivet's Shot wrote:

> 	I recall being taught about APL but not learning the language, the
> example that started the lesson was a five character program to produce
> primes up to a given number. IIRC it worked by generating a one dimensional
> array with the values 1 to n in it, transposing and multiplying to get the
> 2D array of the products and finally filtering the original array to remove
> everything present in the 2D array. The takeaway seemed to be that APL
> allowed you to write amazingly compact programs and was really expressive
> in array manipulation - but efficiency was going to require some attention
> to achieve.

In some older works on bitsavers, there are case studies in which
the process utilizes extensive matrix arithmetic.  Presumably,
APL would be good for something like that.

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

#161845

From	Ahem A Rivet's Shot <steveo@eircom.net>
Date	2016-04-02 22:00 +0100
Message-ID	<20160402220014.f32eb4867c8578d9345b9806@eircom.net>
In reply to	#161837

On Sat, 2 Apr 2016 13:10:28 -0700 (PDT)
hancock4@bbs.cpcn.com wrote:

> On Saturday, April 2, 2016 at 10:00:02 AM UTC-4, Ahem A Rivet's Shot
> wrote:
> 
> > 	I recall being taught about APL but not learning the language,
> > the example that started the lesson was a five character program to
> > produce primes up to a given number. IIRC it worked by generating a one
> > dimensional array with the values 1 to n in it, transposing and
> > multiplying to get the 2D array of the products and finally filtering
> > the original array to remove everything present in the 2D array. The
> > takeaway seemed to be that APL allowed you to write amazingly compact
> > programs and was really expressive in array manipulation - but
> > efficiency was going to require some attention to achieve.
> 
> In some older works on bitsavers, there are case studies in which
> the process utilizes extensive matrix arithmetic.  Presumably,
> APL would be good for something like that.

	My understanding is that this sort of thing is exactly what APL was
designed for.

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

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

#161852

From	"J. Clarke" <j.clarke.873638@gmail.com>
Date	2016-04-02 20:35 -0400
Message-ID	<MPG.316a2f7a95a3b9bd98a062@news.eternal-september.org>
In reply to	#161845

In article <20160402220014.f32eb4867c8578d9345b9806@eircom.net>, 
steveo@eircom.net says...
> 
> On Sat, 2 Apr 2016 13:10:28 -0700 (PDT)
> hancock4@bbs.cpcn.com wrote:
> 
> > On Saturday, April 2, 2016 at 10:00:02 AM UTC-4, Ahem A Rivet's Shot
> > wrote:
> > 
> > > 	I recall being taught about APL but not learning the language,
> > > the example that started the lesson was a five character program to
> > > produce primes up to a given number. IIRC it worked by generating a one
> > > dimensional array with the values 1 to n in it, transposing and
> > > multiplying to get the 2D array of the products and finally filtering
> > > the original array to remove everything present in the 2D array. The
> > > takeaway seemed to be that APL allowed you to write amazingly compact
> > > programs and was really expressive in array manipulation - but
> > > efficiency was going to require some attention to achieve.
> > 
> > In some older works on bitsavers, there are case studies in which
> > the process utilizes extensive matrix arithmetic.  Presumably,
> > APL would be good for something like that.
> 
> 	My understanding is that this sort of thing is exactly what APL was
> designed for.

It was intended for use as an alternative mathematical notation--pretty 
much an exercise, then I understand that it was realized that it could 
be implemented as a kind of very high level pseudocode for for both 
programming and hardware conceptualization.  Then it was actually 
implemented.

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

#161825

From	Andrew Swallow <am.swallow@btopenworld.com>
Date	2016-04-02 16:18 +0100
Message-ID	<OIidnSNnI_1Vf2LLnZ2dnUU78UfNnZ2d@giganews.com>
In reply to	#161820

On 02/04/2016 13:19, J. Clarke wrote:
> In article <ndn79701ej@news6.newsguy.com>, cgibbs@kltpzyxm.invalid
> says...
>>
>> On 2016-04-02, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>
>>> In article <ndgv2u048b@news6.newsguy.com>, cgibbs@kltpzyxm.invalid
>>> says...
>>>>
>>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>>>
>>>>> In article <ndfnam014op@news4.newsguy.com>, cgibbs@kltpzyxm.invalid
>>>>> says...
>>>>>
>>>>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>>>>>
>>>>>>> In article <fd704521-012a-4bdc-acec-c83269e46c4e@googlegroups.com>,
>>>>>>> sigma.research@gmail.com says...
>>>>>>>
>>>>>>>> Many might disagree, but APL is an
>>>>>>>> excellent language to start with. It was
>>>>>>>> the first language i sank my teeth into.
>>>>>>>> Easy to learn, but a lifetime to master.
>>>>>>>> There are a few free versions out there.
>>>>>>>
>>>>>>> Yep.  Trouble is that if you learn to think in APL then other languages
>>>>>>> become frustrating.
>>>>>>
>>>>>> Once I learned to think in assembly language, any high-level language
>>>>>> became frustrating.
>>>>>>
>>>>>> Now I think in C - and high-level languages are still frustrating.
>>>>>
>>>>> Different kind of frustrating.
>>>>>
>>>>> In APL if you are using a loop you are probably doing something wrong.
>>>>
>>>> Not in my kind of applications.  Are you saying that APL isn't
>>>> suited to sequential processing of records in a file?  (Database
>>>> gurus notwithstanding, sequential processing is still the most
>>>> efficient way to scan a million-record file.)
>>>
>>> In APL you don't "scan records", you suck them all into an array and
>>> then use the array operations.
>>>
>>> Arrays contining a million records are well within the capabilities of
>>> any modern APL system.
>>
>> Perhaps this is one of those cases where knowing how things work gets in
>> the way.  I have images of madly thrashing swap disks, and the inability
>> to process the first record until you've read the millionth.  I presume
>> that APL is somehow _very_ different.
>
> If you're dealing with databases too large to comfortably fit in RAM
> then APL is really the wrong tool to be using.  It can do the "read a
> record, process a record, write a record" kind of processing but to do
> that you're pretty much turning into imitation Fortran, and it's not
> really a very good imitation Fortran.
>
> We use it as part of our test strategy--typically we set up APL to
> generate datasets containing inputs and expected outputs, then feed
> those inputs into the C or Fortran production code and determine whether
> the outputs match.  If not then we figure out why and what to do about
> it.
>
> Anyway, this is kind of apart from the point I was making.  In APL you
> have numerous condise operators that do complicated things to every
> element of an array, even a multidimensional array.  Mostly procedures
> that are handled by looping in other languages are handled by array
> operations in APL, and there's a temptation for inexperienced APL
> programmers to write loops that replicate built in functionality.
>

APL needs to treat databases as a special type of array. What ever the 
top level may be doing the underlying subroutines can only handle one 
field at a time.

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

#161826

From	Ahem A Rivet's Shot <steveo@eircom.net>
Date	2016-04-02 17:20 +0100
Message-ID	<20160402172027.6f651f8ac223ef0f9c1e6bdb@eircom.net>
In reply to	#161825

On Sat, 2 Apr 2016 16:18:54 +0100
Andrew Swallow <am.swallow@btopenworld.com> wrote:

> APL needs to treat databases as a special type of array. What ever the 
> top level may be doing the underlying subroutines can only handle one 
> field at a time.

	Not so sure of that, AFAICS APL would lend itself well to being
implemented with something like CUDA on a modern graphics card with
massively parallel operations.

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

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

#161842

From	"J. Clarke" <j.clarke.873638@gmail.com>
Date	2016-04-02 16:49 -0400
Message-ID	<MPG.3169fa789e68722298a060@news.eternal-september.org>
In reply to	#161825

In article <OIidnSNnI_1Vf2LLnZ2dnUU78UfNnZ2d@giganews.com>, 
am.swallow@btopenworld.com says...
> 
> On 02/04/2016 13:19, J. Clarke wrote:
> > In article <ndn79701ej@news6.newsguy.com>, cgibbs@kltpzyxm.invalid
> > says...
> >>
> >> On 2016-04-02, J. Clarke <j.clarke.873638@gmail.com> wrote:
> >>
> >>> In article <ndgv2u048b@news6.newsguy.com>, cgibbs@kltpzyxm.invalid
> >>> says...
> >>>>
> >>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
> >>>>
> >>>>> In article <ndfnam014op@news4.newsguy.com>, cgibbs@kltpzyxm.invalid
> >>>>> says...
> >>>>>
> >>>>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
> >>>>>>
> >>>>>>> In article <fd704521-012a-4bdc-acec-c83269e46c4e@googlegroups.com>,
> >>>>>>> sigma.research@gmail.com says...
> >>>>>>>
> >>>>>>>> Many might disagree, but APL is an
> >>>>>>>> excellent language to start with. It was
> >>>>>>>> the first language i sank my teeth into.
> >>>>>>>> Easy to learn, but a lifetime to master.
> >>>>>>>> There are a few free versions out there.
> >>>>>>>
> >>>>>>> Yep.  Trouble is that if you learn to think in APL then other languages
> >>>>>>> become frustrating.
> >>>>>>
> >>>>>> Once I learned to think in assembly language, any high-level language
> >>>>>> became frustrating.
> >>>>>>
> >>>>>> Now I think in C - and high-level languages are still frustrating.
> >>>>>
> >>>>> Different kind of frustrating.
> >>>>>
> >>>>> In APL if you are using a loop you are probably doing something wrong.
> >>>>
> >>>> Not in my kind of applications.  Are you saying that APL isn't
> >>>> suited to sequential processing of records in a file?  (Database
> >>>> gurus notwithstanding, sequential processing is still the most
> >>>> efficient way to scan a million-record file.)
> >>>
> >>> In APL you don't "scan records", you suck them all into an array and
> >>> then use the array operations.
> >>>
> >>> Arrays contining a million records are well within the capabilities of
> >>> any modern APL system.
> >>
> >> Perhaps this is one of those cases where knowing how things work gets in
> >> the way.  I have images of madly thrashing swap disks, and the inability
> >> to process the first record until you've read the millionth.  I presume
> >> that APL is somehow _very_ different.
> >
> > If you're dealing with databases too large to comfortably fit in RAM
> > then APL is really the wrong tool to be using.  It can do the "read a
> > record, process a record, write a record" kind of processing but to do
> > that you're pretty much turning into imitation Fortran, and it's not
> > really a very good imitation Fortran.
> >
> > We use it as part of our test strategy--typically we set up APL to
> > generate datasets containing inputs and expected outputs, then feed
> > those inputs into the C or Fortran production code and determine whether
> > the outputs match.  If not then we figure out why and what to do about
> > it.
> >
> > Anyway, this is kind of apart from the point I was making.  In APL you
> > have numerous condise operators that do complicated things to every
> > element of an array, even a multidimensional array.  Mostly procedures
> > that are handled by looping in other languages are handled by array
> > operations in APL, and there's a temptation for inexperienced APL
> > programmers to write loops that replicate built in functionality.
> >
> 
> APL needs to treat databases as a special type of array. What ever the 
> top level may be doing the underlying subroutines can only handle one 
> field at a time.

Maybe, maybe not.  Modern hardware certainly has a good bit of parallel 
processing capability--to what extent modern APLs take advantage of it I 
have no idea but it certainly lends itself to parallization.

APL doesn't have special kinds of arrays.  It just has arrays.

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

#161851

From	Andrew Swallow <am.swallow@btopenworld.com>
Date	2016-04-03 00:52 +0100
Message-ID	<B-2dne22l8iCxp3KnZ2dnUU78LOdnZ2d@giganews.com>
In reply to	#161842

On 02/04/2016 21:49, J. Clarke wrote:
> In article <OIidnSNnI_1Vf2LLnZ2dnUU78UfNnZ2d@giganews.com>,
> am.swallow@btopenworld.com says...
>>
>> On 02/04/2016 13:19, J. Clarke wrote:
>>> In article <ndn79701ej@news6.newsguy.com>, cgibbs@kltpzyxm.invalid
>>> says...
>>>>
>>>> On 2016-04-02, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>>>
>>>>> In article <ndgv2u048b@news6.newsguy.com>, cgibbs@kltpzyxm.invalid
>>>>> says...
>>>>>>
>>>>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>>>>>
>>>>>>> In article <ndfnam014op@news4.newsguy.com>, cgibbs@kltpzyxm.invalid
>>>>>>> says...
>>>>>>>
>>>>>>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> In article <fd704521-012a-4bdc-acec-c83269e46c4e@googlegroups.com>,
>>>>>>>>> sigma.research@gmail.com says...
>>>>>>>>>
>>>>>>>>>> Many might disagree, but APL is an
>>>>>>>>>> excellent language to start with. It was
>>>>>>>>>> the first language i sank my teeth into.
>>>>>>>>>> Easy to learn, but a lifetime to master.
>>>>>>>>>> There are a few free versions out there.
>>>>>>>>>
>>>>>>>>> Yep.  Trouble is that if you learn to think in APL then other languages
>>>>>>>>> become frustrating.
>>>>>>>>
>>>>>>>> Once I learned to think in assembly language, any high-level language
>>>>>>>> became frustrating.
>>>>>>>>
>>>>>>>> Now I think in C - and high-level languages are still frustrating.
>>>>>>>
>>>>>>> Different kind of frustrating.
>>>>>>>
>>>>>>> In APL if you are using a loop you are probably doing something wrong.
>>>>>>
>>>>>> Not in my kind of applications.  Are you saying that APL isn't
>>>>>> suited to sequential processing of records in a file?  (Database
>>>>>> gurus notwithstanding, sequential processing is still the most
>>>>>> efficient way to scan a million-record file.)
>>>>>
>>>>> In APL you don't "scan records", you suck them all into an array and
>>>>> then use the array operations.
>>>>>
>>>>> Arrays contining a million records are well within the capabilities of
>>>>> any modern APL system.
>>>>
>>>> Perhaps this is one of those cases where knowing how things work gets in
>>>> the way.  I have images of madly thrashing swap disks, and the inability
>>>> to process the first record until you've read the millionth.  I presume
>>>> that APL is somehow _very_ different.
>>>
>>> If you're dealing with databases too large to comfortably fit in RAM
>>> then APL is really the wrong tool to be using.  It can do the "read a
>>> record, process a record, write a record" kind of processing but to do
>>> that you're pretty much turning into imitation Fortran, and it's not
>>> really a very good imitation Fortran.
>>>
>>> We use it as part of our test strategy--typically we set up APL to
>>> generate datasets containing inputs and expected outputs, then feed
>>> those inputs into the C or Fortran production code and determine whether
>>> the outputs match.  If not then we figure out why and what to do about
>>> it.
>>>
>>> Anyway, this is kind of apart from the point I was making.  In APL you
>>> have numerous condise operators that do complicated things to every
>>> element of an array, even a multidimensional array.  Mostly procedures
>>> that are handled by looping in other languages are handled by array
>>> operations in APL, and there's a temptation for inexperienced APL
>>> programmers to write loops that replicate built in functionality.
>>>
>>
>> APL needs to treat databases as a special type of array. What ever the
>> top level may be doing the underlying subroutines can only handle one
>> field at a time.
>
> Maybe, maybe not.  Modern hardware certainly has a good bit of parallel
> processing capability--to what extent modern APLs take advantage of it I
> have no idea but it certainly lends itself to parallization.
>
> APL doesn't have special kinds of arrays.  It just has arrays.
>
>
Which is why it cannot handle databases.

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

#161853

From	"J. Clarke" <j.clarke.873638@gmail.com>
Date	2016-04-02 20:37 -0400
Message-ID	<MPG.316a2fdcb8e3bd398a063@news.eternal-september.org>
In reply to	#161851

In article <B-2dne22l8iCxp3KnZ2dnUU78LOdnZ2d@giganews.com>, 
am.swallow@btopenworld.com says...
> 
> On 02/04/2016 21:49, J. Clarke wrote:
> > In article <OIidnSNnI_1Vf2LLnZ2dnUU78UfNnZ2d@giganews.com>,
> > am.swallow@btopenworld.com says...
> >>
> >> On 02/04/2016 13:19, J. Clarke wrote:
> >>> In article <ndn79701ej@news6.newsguy.com>, cgibbs@kltpzyxm.invalid
> >>> says...
> >>>>
> >>>> On 2016-04-02, J. Clarke <j.clarke.873638@gmail.com> wrote:
> >>>>
> >>>>> In article <ndgv2u048b@news6.newsguy.com>, cgibbs@kltpzyxm.invalid
> >>>>> says...
> >>>>>>
> >>>>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
> >>>>>>
> >>>>>>> In article <ndfnam014op@news4.newsguy.com>, cgibbs@kltpzyxm.invalid
> >>>>>>> says...
> >>>>>>>
> >>>>>>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> In article <fd704521-012a-4bdc-acec-c83269e46c4e@googlegroups.com>,
> >>>>>>>>> sigma.research@gmail.com says...
> >>>>>>>>>
> >>>>>>>>>> Many might disagree, but APL is an
> >>>>>>>>>> excellent language to start with. It was
> >>>>>>>>>> the first language i sank my teeth into.
> >>>>>>>>>> Easy to learn, but a lifetime to master.
> >>>>>>>>>> There are a few free versions out there.
> >>>>>>>>>
> >>>>>>>>> Yep.  Trouble is that if you learn to think in APL then other languages
> >>>>>>>>> become frustrating.
> >>>>>>>>
> >>>>>>>> Once I learned to think in assembly language, any high-level language
> >>>>>>>> became frustrating.
> >>>>>>>>
> >>>>>>>> Now I think in C - and high-level languages are still frustrating.
> >>>>>>>
> >>>>>>> Different kind of frustrating.
> >>>>>>>
> >>>>>>> In APL if you are using a loop you are probably doing something wrong.
> >>>>>>
> >>>>>> Not in my kind of applications.  Are you saying that APL isn't
> >>>>>> suited to sequential processing of records in a file?  (Database
> >>>>>> gurus notwithstanding, sequential processing is still the most
> >>>>>> efficient way to scan a million-record file.)
> >>>>>
> >>>>> In APL you don't "scan records", you suck them all into an array and
> >>>>> then use the array operations.
> >>>>>
> >>>>> Arrays contining a million records are well within the capabilities of
> >>>>> any modern APL system.
> >>>>
> >>>> Perhaps this is one of those cases where knowing how things work gets in
> >>>> the way.  I have images of madly thrashing swap disks, and the inability
> >>>> to process the first record until you've read the millionth.  I presume
> >>>> that APL is somehow _very_ different.
> >>>
> >>> If you're dealing with databases too large to comfortably fit in RAM
> >>> then APL is really the wrong tool to be using.  It can do the "read a
> >>> record, process a record, write a record" kind of processing but to do
> >>> that you're pretty much turning into imitation Fortran, and it's not
> >>> really a very good imitation Fortran.
> >>>
> >>> We use it as part of our test strategy--typically we set up APL to
> >>> generate datasets containing inputs and expected outputs, then feed
> >>> those inputs into the C or Fortran production code and determine whether
> >>> the outputs match.  If not then we figure out why and what to do about
> >>> it.
> >>>
> >>> Anyway, this is kind of apart from the point I was making.  In APL you
> >>> have numerous condise operators that do complicated things to every
> >>> element of an array, even a multidimensional array.  Mostly procedures
> >>> that are handled by looping in other languages are handled by array
> >>> operations in APL, and there's a temptation for inexperienced APL
> >>> programmers to write loops that replicate built in functionality.
> >>>
> >>
> >> APL needs to treat databases as a special type of array. What ever the
> >> top level may be doing the underlying subroutines can only handle one
> >> field at a time.
> >
> > Maybe, maybe not.  Modern hardware certainly has a good bit of parallel
> > processing capability--to what extent modern APLs take advantage of it I
> > have no idea but it certainly lends itself to parallization.
> >
> > APL doesn't have special kinds of arrays.  It just has arrays.
> >
> >
> Which is why it cannot handle databases.

So how many lines of APL code have you been paid to write?

There are reasons that APL is a poor choice for database programming, 
but the one you state is not one of them.

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

#161807

From	Dave Garland <dave.garland@wizinfo.com>
Date	2016-04-01 22:53 -0500
Message-ID	<ndnfit$ma2$1@dont-email.me>
In reply to	#161803

On 4/1/2016 8:12 PM, J. Clarke wrote:
> In article <ndgv2u048b@news6.newsguy.com>, cgibbs@kltpzyxm.invalid
> says...
>>
>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>
>>> In article <ndfnam014op@news4.newsguy.com>, cgibbs@kltpzyxm.invalid
>>> says...
>>>
>>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>>>
>>>>> In article <fd704521-012a-4bdc-acec-c83269e46c4e@googlegroups.com>,
>>>>> sigma.research@gmail.com says...
>>>>>
>>>>>> Many might disagree, but APL is an
>>>>>> excellent language to start with. It was
>>>>>> the first language i sank my teeth into.
>>>>>> Easy to learn, but a lifetime to master.
>>>>>> There are a few free versions out there.
>>>>>
>>>>> Yep.  Trouble is that if you learn to think in APL then other languages
>>>>> become frustrating.
>>>>
>>>> Once I learned to think in assembly language, any high-level language
>>>> became frustrating.
>>>>
>>>> Now I think in C - and high-level languages are still frustrating.
>>>
>>> Different kind of frustrating.
>>>
>>> In APL if you are using a loop you are probably doing something wrong.
>>
>> Not in my kind of applications.  Are you saying that APL isn't suited to
>> sequential processing of records in a file?  (Database gurus notwithstanding,
>> sequential processing is still the most efficient way to scan a million-record
>> file.)
>
> In APL you don't "scan records", you suck them all into an array and
> then use the array operations.
>
> Arrays contining a million records are well within the capabilities of
> any modern APL system.
>
I don't know anything about APL (other than that it led to weird 
keyboards), but does that imply that the array must fit into memory?

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

#161810

From	Anne & Lynn Wheeler <lynn@garlic.com>
Date	2016-04-01 21:25 -0700
Message-ID	<877fggmych.fsf@garlic.com>
In reply to	#161807

Dave Garland <dave.garland@wizinfo.com> writes:
> I don't know anything about APL (other than that it led to weird
> keyboards), but does that imply that the array must fit into memory?

cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

ported apl\360 to cp67/cms for cms\apl. As part of cms\apl, on of the
things done was api to system services like file i/o ... so it could
handle real-world applications ... like larger than workspace size ...
typically 16kbytes for apl\360.

Another thing that had to be done was rework garbage collection.
APL\360 started out with all space compacted at one end of workspace
...and then every assignment allocated new location ... until it reached
the other end of workspace ... in which it did garbage collected.
Wasn't big deal for apl\360 workspace which were swapped as single piece
of storage. Moving to cp67/cms with workspace in demand paged virtual
memory, this could mean rapidly touching 16mbytes and then
compacting/garbage collection ... which resulted in lots of page
thrashing. garbage collection got tuned to be triggered before touching
excessive amount of workspace.

The APL forces criticized science center for corrupting the purity of
APL with the way the system services API was implemented. Eventually
they come up with "shared variables" semantices as mechanism for
accessing system services (replacing the original cms\apl
implementation)
https://en.wikipedia.org/wiki/Shared_Variables

this then shows up in apl\cms that was done for vm370/cms.

past posts mentioning apl &/or HONE (worldwide online sales&marketing
system that had majority of applications implemented in apl
... originally cp67/cms cms\apl ... and then moved to vm370/cms and
apl\cms).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#161821

From	"J. Clarke" <j.clarke.873638@gmail.com>
Date	2016-04-02 08:24 -0400
Message-ID	<MPG.31698409aa7113d398a05c@news.eternal-september.org>
In reply to	#161807

In article <ndnfit$ma2$1@dont-email.me>, dave.garland@wizinfo.com 
says...
> 
> On 4/1/2016 8:12 PM, J. Clarke wrote:
> > In article <ndgv2u048b@news6.newsguy.com>, cgibbs@kltpzyxm.invalid
> > says...
> >>
> >> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
> >>
> >>> In article <ndfnam014op@news4.newsguy.com>, cgibbs@kltpzyxm.invalid
> >>> says...
> >>>
> >>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
> >>>>
> >>>>> In article <fd704521-012a-4bdc-acec-c83269e46c4e@googlegroups.com>,
> >>>>> sigma.research@gmail.com says...
> >>>>>
> >>>>>> Many might disagree, but APL is an
> >>>>>> excellent language to start with. It was
> >>>>>> the first language i sank my teeth into.
> >>>>>> Easy to learn, but a lifetime to master.
> >>>>>> There are a few free versions out there.
> >>>>>
> >>>>> Yep.  Trouble is that if you learn to think in APL then other languages
> >>>>> become frustrating.
> >>>>
> >>>> Once I learned to think in assembly language, any high-level language
> >>>> became frustrating.
> >>>>
> >>>> Now I think in C - and high-level languages are still frustrating.
> >>>
> >>> Different kind of frustrating.
> >>>
> >>> In APL if you are using a loop you are probably doing something wrong.
> >>
> >> Not in my kind of applications.  Are you saying that APL isn't suited to
> >> sequential processing of records in a file?  (Database gurus notwithstanding,
> >> sequential processing is still the most efficient way to scan a million-record
> >> file.)
> >
> > In APL you don't "scan records", you suck them all into an array and
> > then use the array operations.
> >
> > Arrays contining a million records are well within the capabilities of
> > any modern APL system.
> >
> I don't know anything about APL (other than that it led to weird 
> keyboards), but does that imply that the array must fit into memory?

If you're dealing with data too big to comfortably fit into memory, APL 
is probably the wrong tool to be using.  It can do one-record-at-a-time 
processing but if that's what you're doing it doesn't bring anything to 
the party.

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

#161760

From	Jon Elson <jmelson@wustl.edu>
Date	2016-03-31 16:07 -0500
Message-ID	<tOKdneD4yYPzDGDLnZ2dnUU7-N3NnZ2d@giganews.com>
In reply to	#161617

Charlie Gibbs wrote:

> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
> 
>> In article <fd704521-012a-4bdc-acec-c83269e46c4e@googlegroups.com>,
>> sigma.research@gmail.com says...
>> 
>>> Many might disagree, but APL is an
>>> excellent language to start with. It was
>>> the first language i sank my teeth into.
>>> Easy to learn, but a lifetime to master.
>>> There are a few free versions out there.
>>
>> Yep.  Trouble is that if you learn to think in APL then other languages
>> become frustrating.
> 
> Once I learned to think in assembly language, any high-level language
> became frustrating.
> 
> Now I think in C - and high-level languages are still frustrating.
> 
Gee, not really.  It is a huge benefit to know what the machine code will 
look like in general when coding in HLLs.  But, the minute detail of what's 
left in the carry bit from 5 instructions back, I really DON'T want to deal 
with.  C can be a bit frustrating due to the crummy syntax, but it is kind 
of like English, the universal language.  I did all the programming for my 
own use in Pascal for quite some years, and still think it is a pretty good 
language.  it might even be making a comeback!

Jon

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

#161762

From	Peter Flass <peter_flass@yahoo.com>
Date	2016-03-31 17:46 -0400
Message-ID	<591617504.481153252.838141.peter_flass-yahoo.com@news.eternal-september.org>
In reply to	#161760

Jon Elson <jmelson@wustl.edu> wrote:
> Charlie Gibbs wrote:
> 
>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
>> 
>>> In article <fd704521-012a-4bdc-acec-c83269e46c4e@googlegroups.com>,
>>> sigma.research@gmail.com says...
>>> 
>>>> Many might disagree, but APL is an
>>>> excellent language to start with. It was
>>>> the first language i sank my teeth into.
>>>> Easy to learn, but a lifetime to master.
>>>> There are a few free versions out there.
>>> 
>>> Yep.  Trouble is that if you learn to think in APL then other languages
>>> become frustrating.
>> 
>> Once I learned to think in assembly language, any high-level language
>> became frustrating.
>> 
>> Now I think in C - and high-level languages are still frustrating.
>> 
> Gee, not really.  It is a huge benefit to know what the machine code will 
> look like in general when coding in HLLs.  But, the minute detail of what's 
> left in the carry bit from 5 instructions back, I really DON'T want to deal 
> with.  C can be a bit frustrating due to the crummy syntax, but it is kind 
> of like English, the universal language.  I did all the programming for my 
> own use in Pascal for quite some years, and still think it is a pretty good 
> language.  it might even be making a comeback!
> 

You might convince me to take another look at Pascal.  I know at least one
other guy who does good stuff with it.  I looked at it years back when it
was a fad, but at that time the missing features and implementation
incompatibilities made it less than a good choice for me.  In general I
prefer PL/I, but it's most useful for larger projects.  I'd like something
like C was originally - a few instructions of overhead and otherwise just a
minimalist compilation of the C into machine code.  Now there's way too
much cruft, although some compilers for imbedded systems probably do a good
job.

-- 
Pete

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

#161780

From	scott@slp53.sl.home (Scott Lurndal)
Date	2016-04-01 13:20 +0000
Message-ID	<BAuLy.87499$111.60694@fx31.iad>
In reply to	#161762

Peter Flass <peter_flass@yahoo.com> writes:
>Jon Elson <jmelson@wustl.edu> wrote:
>> Charlie Gibbs wrote:
>> 
>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>> 
>>>> In article <fd704521-012a-4bdc-acec-c83269e46c4e@googlegroups.com>,
>>>> sigma.research@gmail.com says...
>>>> 
>>>>> Many might disagree, but APL is an
>>>>> excellent language to start with. It was
>>>>> the first language i sank my teeth into.
>>>>> Easy to learn, but a lifetime to master.
>>>>> There are a few free versions out there.
>>>> 
>>>> Yep.  Trouble is that if you learn to think in APL then other languages
>>>> become frustrating.
>>> 
>>> Once I learned to think in assembly language, any high-level language
>>> became frustrating.
>>> 
>>> Now I think in C - and high-level languages are still frustrating.
>>> 
>> Gee, not really.  It is a huge benefit to know what the machine code will 
>> look like in general when coding in HLLs.  But, the minute detail of what's 
>> left in the carry bit from 5 instructions back, I really DON'T want to deal 
>> with.  C can be a bit frustrating due to the crummy syntax, but it is kind 
>> of like English, the universal language.  I did all the programming for my 
>> own use in Pascal for quite some years, and still think it is a pretty good 
>> language.  it might even be making a comeback!
>> 
>
>You might convince me to take another look at Pascal.  I know at least one
>other guy who does good stuff with it.  I looked at it years back when it
>was a fad, but at that time the missing features and implementation
>incompatibilities made it less than a good choice for me. 

VAX-11 Pascal was fully featured - sufficient to write
efficient systems software.

> In general I
>prefer PL/I, but it's most useful for larger projects.  I'd like something
>like C was originally - a few instructions of overhead and otherwise just a
>minimalist compilation of the C into machine code.  Now there's way too
>much cruft, although some compilers for imbedded systems probably do a good
>job.

When was the last time you used a C compiler?    The quality of generated
code from modern compilers (PCG, Intel C, GCC, Clang) is exemplary.  Visual
Studio lags, it is true.

http://www.pgroup.com/

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

#161795

From	Peter Flass <peter_flass@yahoo.com>
Date	2016-04-01 17:05 -0400
Message-ID	<1994396952.481236811.664998.peter_flass-yahoo.com@news.eternal-september.org>
In reply to	#161780

Scott Lurndal <scott@slp53.sl.home> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>> Jon Elson <jmelson@wustl.edu> wrote:
>>> Charlie Gibbs wrote:
>>> 
>>>> On 2016-03-30, J. Clarke <j.clarke.873638@gmail.com> wrote:
>>>> 
>>>>> In article <fd704521-012a-4bdc-acec-c83269e46c4e@googlegroups.com>,
>>>>> sigma.research@gmail.com says...
>>>>> 
>>>>>> Many might disagree, but APL is an
>>>>>> excellent language to start with. It was
>>>>>> the first language i sank my teeth into.
>>>>>> Easy to learn, but a lifetime to master.
>>>>>> There are a few free versions out there.
>>>>> 
>>>>> Yep.  Trouble is that if you learn to think in APL then other languages
>>>>> become frustrating.
>>>> 
>>>> Once I learned to think in assembly language, any high-level language
>>>> became frustrating.
>>>> 
>>>> Now I think in C - and high-level languages are still frustrating.
>>>> 
>>> Gee, not really.  It is a huge benefit to know what the machine code will 
>>> look like in general when coding in HLLs.  But, the minute detail of what's 
>>> left in the carry bit from 5 instructions back, I really DON'T want to deal 
>>> with.  C can be a bit frustrating due to the crummy syntax, but it is kind 
>>> of like English, the universal language.  I did all the programming for my 
>>> own use in Pascal for quite some years, and still think it is a pretty good 
>>> language.  it might even be making a comeback!
>>> 
>> 
>> You might convince me to take another look at Pascal.  I know at least one
>> other guy who does good stuff with it.  I looked at it years back when it
>> was a fad, but at that time the missing features and implementation
>> incompatibilities made it less than a good choice for me. 
> 
> VAX-11 Pascal was fully featured - sufficient to write
> efficient systems software.
> 
>> In general I
>> prefer PL/I, but it's most useful for larger projects.  I'd like something
>> like C was originally - a few instructions of overhead and otherwise just a
>> minimalist compilation of the C into machine code.  Now there's way too
>> much cruft, although some compilers for imbedded systems probably do a good
>> job.
> 
> When was the last time you used a C compiler?    The quality of generated
> code from modern compilers (PCG, Intel C, GCC, Clang) is exemplary.  Visual
> Studio lags, it is true.

I've used gcc.  I was thinking of Aztec C for DOS (and probably
Borland,etc.), that had something like four instructions of overhead for a
program.  Nowadays the startup calls tons of library code before the
program does anything, even if it just returns.

> 
> http://www.pgroup.com/
> 



-- 
Pete

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

#161982

From	scott@slp53.sl.home (Scott Lurndal)
Date	2016-04-04 13:04 +0000
Message-ID	<DDtMy.13934$4s2.12109@fx01.iad>
In reply to	#161795

Peter Flass <peter_flass@yahoo.com> writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:

>> When was the last time you used a C compiler?    The quality of generated
>> code from modern compilers (PCG, Intel C, GCC, Clang) is exemplary.  Visual
>> Studio lags, it is true.
>
>I've used gcc.  I was thinking of Aztec C for DOS (and probably
>Borland,etc.), that had something like four instructions of overhead for a
>program.  Nowadays the startup calls tons of library code before the
>program does anything, even if it just returns.
>

If you consider a couple hundred instructions "a ton".

$ cat /tmp/a.c

int main(int argc, const char * const *argv)
{
        return 1;
}

$ strace /tmp/a
execve("/tmp/a", ["/tmp/a"], [/* 64 vars */]) = 0
uname({sys="Linux", node="host1", ...}) = 0
brk(0)                                  = 0x121d000
brk(0x121e180)                          = 0x121e180
arch_prctl(ARCH_SET_FS, 0x121d860)      = 0
brk(0x123f180)                          = 0x123f180
brk(0x1240000)                          = 0x1240000
exit_group(1)                           = ?

Six system calls, all but one of which extended the
heap by about 128kbytes.

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

#161770

From	Stan Barr <plan.b@bluesomatic.org>
Date	2016-04-01 07:18 +0000
Message-ID	<slrnnfs86r.90o.plan.b@ID-309335.user.uni-berlin.de>
In reply to	#161760

On Thu, 31 Mar 2016 16:07:54 -0500, Jon Elson <jmelson@wustl.edu> wrote:
>  I did all the programming for my 
> own use in Pascal for quite some years, and still think it is a pretty good 
> language.  it might even be making a comeback!

I would prefer Modula-2, I did a lot of stuff in FST Modula back in
the MSDOS days.  Sort of Pascal redone right(er)
Oberon is worh a look too, it follows on from Modula.

-- 
Stan Barr     plan.b@bluesomatic.org

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

#161791

From	Anne & Lynn Wheeler <lynn@garlic.com>
Date	2016-04-01 10:24 -0700
Message-ID	<8760w1i6mw.fsf@garlic.com>
In reply to	#161770

Stan Barr <plan.b@bluesomatic.org> writes:
> I would prefer Modula-2, I did a lot of stuff in FST Modula back in
> the MSDOS days.  Sort of Pascal redone right(er)
> Oberon is worh a look too, it follows on from Modula.

from long ago and far away

Date: 10/11/83 19:30:53
From: wheeler

i'm going to order a copy of PC MODULA2 compilers from LOGITECH ...

Date: 02/07/84 08:52:10
From: wheeler

3 copies of modula2 showed up today ... but they are not the new
improved release 1.0 version.

Date: 04/16/84 09:06:36
From: wheeler

got three release 1 modula2 upgrades today

... snip ...

Took me four months to get the order and another two months to get the
release one upgrade.  However, modula2 compiler performance compared
poorly with turbo pascal, modula2 5line example program, took 3mins to
compile and one min to link.

Fall of 1983, palo alto science center published comparison for moudla2
and pascal/vs (which had a lot of enhancements not found in base
pascal). A big difference was modula2 "PROCESS", "NEWPROCESS" and
"TRANSFER" (for multiprogramming/multithreading). However, they did
pascal/vs library implementation of the features and used them to
implement moudla2 example programs.

The original mainframe pascal (that became pascal/vs) was done by the
los gatos vlsi tools group using metaware's TWS (later pascal/vs was
made available on both mainframe and rs/6000). There was also some
effort looking at using metaware's TWS to implement modula2 front-end
for the pascal/vs backend code generator.

from long ago and far away

#***********************************************************#
#                                                           #
#                       TM                                  #
#               MetaWare   TWS User's Manual                #
#                                                           #
#               A Translator Writing System                 #
#                      based  on  the                       #
#                   LR Parsing Technique                    #
#                                                           #
#               (C) Copyright  1979, 80, 81                 #
#                   Franklin L.  DeRemer                    #
#                   Thomas  J.  Pennello                    #
#                   Santa Cruz, CA 95060                    #
#                                                           #
#                                                           #
#***********************************************************#

past posts mentioning metaware
http://manana.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://manana.garlic.com/~lynn/2002n.html#66 Mainframe Spreadsheets - 1980's History
http://manana.garlic.com/~lynn/2002q.html#19 Beyond 8+3
http://manana.garlic.com/~lynn/2003h.html#52 Question about Unix "heritage"
http://manana.garlic.com/~lynn/2004d.html#71 What terminology reflects the "first" computer language ?
http://manana.garlic.com/~lynn/2004f.html#42 Infiniband - practicalities for small clusters
http://manana.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
http://manana.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://manana.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://manana.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://manana.garlic.com/~lynn/2004q.html#61 will there every be another commerically signficant new ISA?
http://manana.garlic.com/~lynn/2005b.html#14 something like a CTC on a PC
http://manana.garlic.com/~lynn/2005e.html#0 [Lit.] Buffer overruns
http://manana.garlic.com/~lynn/2005e.html#1 [Lit.] Buffer overruns
http://manana.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal of R&D
http://manana.garlic.com/~lynn/2006b.html#8 Free to good home: IBM RT UNIX
http://manana.garlic.com/~lynn/2007j.html#14 Newbie question on table design
http://manana.garlic.com/~lynn/2008j.html#77 CLIs and GUIs
http://manana.garlic.com/~lynn/2009e.html#11 Lack of bit field instructions in x86 instruction set because of ?patents ?
http://manana.garlic.com/~lynn/2009l.html#36 Old-school programming techniques you probably don't miss
http://manana.garlic.com/~lynn/2009o.html#11 Microprocessors with Definable MIcrocode
http://manana.garlic.com/~lynn/2010c.html#29 search engine history, was Happy DEC-10 Day
http://manana.garlic.com/~lynn/2010i.html#28 someone smarter than Dave Cutler
http://manana.garlic.com/~lynn/2010n.html#54 PL/I vs. Pascal
http://manana.garlic.com/~lynn/2011i.html#69 Making Z/OS easier - Effectively replacing JCL with Unix like commands
http://manana.garlic.com/~lynn/2011m.html#32 computer bootlaces
http://manana.garlic.com/~lynn/2012h.html#20 Mainframes Warming Up to the Cloud
http://manana.garlic.com/~lynn/2012i.html#89 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://manana.garlic.com/~lynn/2012m.html#21 The simplest High Level Language
http://manana.garlic.com/~lynn/2013l.html#59 Teletypewriter Model 33
http://manana.garlic.com/~lynn/2013m.html#36 Quote on Slashdot.org
http://manana.garlic.com/~lynn/2015g.html#51 [Poll] Computing favorities
http://manana.garlic.com/~lynn/2015g.html#52 [Poll] Computing favorities

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#161799

From	Anonymous <no_email@invalid.invalid>
Date	2016-04-01 22:41 +0000
Message-ID	<dm8bpbF10m9U1@mid.individual.net>
In reply to	#161770

Stan Barr <plan.b@bluesomatic.org> wrote:
> On Thu, 31 Mar 2016 16:07:54 -0500, Jon Elson <jmelson@wustl.edu> wrote:
>> I did all the programming for my 
>> own use in Pascal for quite some years, and still think it is a pretty good 
>> language.  it might even be making a comeback!
> 
> I would prefer Modula-2, I did a lot of stuff in FST Modula back in
> the MSDOS days.  Sort of Pascal redone right(er)
> Oberon is worh a look too, it follows on from Modula.

The natural follow on from Pascal is Ada, a gcc-supported language that
corrects all of Pascal's many mistakes.  Modula and Oberon just continue
down the same misguided path of fetishizing ever-increasing
'simplicity'.

-- 
Bill Findlay

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

#161937

From	Walter Bushell <proto@panix.com>
Date	2016-04-03 19:31 -0400
Message-ID	<proto-2E5D26.19313903042016@news.panix.com>
In reply to	#161760

In article <tOKdneD4yYPzDGDLnZ2dnUU7-N3NnZ2d@giganews.com>,
 Jon Elson <jmelson@wustl.edu> wrote:
> > 
> Gee, not really.  It is a huge benefit to know what the machine code will 
> look like in general when coding in HLLs.  But, the minute detail of what's 
> left in the carry bit from 5 instructions back, I really DON'T want to deal 
> with.  C can be a bit frustrating due to the crummy syntax, but it is kind 
> of like English, the universal language.  I did all the programming for my 
> own use in Pascal for quite some years, and still think it is a pretty good 
> language.  it might even be making a comeback!
> 
> Jon

 It doesn't matter about the carry bit, out of order and speculative 
execution make such details an elephant and immaterial.

-- 
 To terrify children with the image of hell,
 to consider women an inferior creation is that good for the world?  
  Christopher Hitchens

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

Page 2 of 21 — ← Prev page 1 [2] 3 4 … 21 Next page →

csiph-web

Which Books Can You Recommend For Learning Computer Programming?

Contents

#161837

#161845

#161852

#161825

#161826

#161842

#161851

#161853

#161807

#161810

#161821

#161760

#161762

#161780

#161795

#161982

#161770

#161791

#161799

#161937