APL\360

[Paul_Koning]

Probably old news to some, but I just ran into this 3 year old article.  Gotta 
dust off your Hercules:  
http://www.computerhistory.org/atchm/the-apl-programming-language-source-code/

And also http://wotho.ethz.ch/mvt4apl-2.00/

paul

APL\360

[Paul Koning via cctalk]

I was just poking around the computerhistory.org website, searching for Knuth 
stuff.

The second or third hit when I search for "Knuth" is this one: 
https://computerhistory.org/blog/the-apl-programming-language-source-code/ .  
It's not just about APL, it actually has a downloadable copy of the source 
code.  And it points to an executable version, apparently a packaged up 
Hercules running that code.

Nice.  I'll have to give it a try.

paul

RE: APL\360

[Dave G4UGM]

There are two other working vintage APL implementations. There is one for
the IBM1130 which can be downloaded from here:-

http://ibm1130.org/sim/downloads

and the other APL/360  on MTS so again Hercules is needed. 

http://archive.michigan-terminal-system.org/discussions/programming-language
s-available-under-mts

is probably a good starting place

Dave Wade

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of
> paul_kon...@dell.com
> Sent: 30 August 2015 23:54
> To: cctalk@classiccmp.org
> Subject: APL\360
> 
> Probably old news to some, but I just ran into this 3 year old article.
Gotta
> dust off your Hercules:  http://www.computerhistory.org/atchm/the-apl-
> programming-language-source-code/
> 
> And also http://wotho.ethz.ch/mvt4apl-2.00/
> 
>   paul

Re: APL\360

[Chuck Guzis via cctalk]

On 1/14/21 5:44 PM, Paul Koning via cctalk wrote:
> I was just poking around the computerhistory.org website, searching for Knuth 
> stuff.
> 
> The second or third hit when I search for "Knuth" is this one: 
> https://computerhistory.org/blog/the-apl-programming-language-source-code/ .  
> It's not just about APL, it actually has a downloadable copy of the source 
> code.  And it points to an executable version, apparently a packaged up 
> Hercules running that code.
> 
> Nice.  I'll have to give it a try.


I recall Neil Lincoln (he of CDC/ETA) relating that he taught APL to his
kids and his wife (APL was pretty much a natural for the STAR) as a
first programming language.

I took some time to learn it fairly well, but never really had any
opportunity to use it much, so it's gone into the memory dustbin of old
never-used languages of my brain.

A co-worker back when would never use the name of the book or the
abbreviation.  He always referred to it as "that Iverson language" or "TIL".

And it's comparatively easy to write short, perfectly opaque code in
APL; probably more so than other common languages.

--Chuck

Re: APL\360

[Norman Jaffe via cctalk]

I remember colleagues competing for the most 'interesting' one-liner in APL 
that actually did something useful, in university. 
I wrote several different kinds of simulator, one of which generated APL code 
on the fly that was then executed... plus a database-or-two. 
I've been actively collecting APL memorabilia and books for years now... if I 
could find an MCM/70 it would be awesome... 

From: "cctalk"  
To: "cctalk"  
Sent: Thursday, January 14, 2021 6:22:39 PM 
Subject: Re: APL\360 

On 1/14/21 5:44 PM, Paul Koning via cctalk wrote: 
> I was just poking around the computerhistory.org website, searching for Knuth 
> stuff. 
> 
> The second or third hit when I search for "Knuth" is this one: 
> https://computerhistory.org/blog/the-apl-programming-language-source-code/ . 
> It's not just about APL, it actually has a downloadable copy of the source 
> code. And it points to an executable version, apparently a packaged up 
> Hercules running that code. 
> 
> Nice. I'll have to give it a try. 


I recall Neil Lincoln (he of CDC/ETA) relating that he taught APL to his 
kids and his wife (APL was pretty much a natural for the STAR) as a 
first programming language. 

I took some time to learn it fairly well, but never really had any 
opportunity to use it much, so it's gone into the memory dustbin of old 
never-used languages of my brain. 

A co-worker back when would never use the name of the book or the 
abbreviation. He always referred to it as "that Iverson language" or "TIL". 

And it's comparatively easy to write short, perfectly opaque code in 
APL; probably more so than other common languages. 

--Chuck 

Re: APL\360

[Fred Cisin via cctalk]

APL was terse.

You could do amazing things with very short source code.
Extremely well suited for scientific programming.
(I used it on a timesharing terminal at Goddard Space Flight Center half a 
century ago)


It had a lot of operators.  So much so that it had to expand the character 
set.  Typically, it was used on a Selectric based terminal, with a special 
type-ball, and added labels pasted on the keys.


Unlike English based languages, such as FORTRAN or COBOL, anybody other 
than an APL programmer could not even guess what a line of APL did.


As a FIRST language, it had a first day steep learning curve learning new 
operators.  But, also, as a FIRST language, it was nice that it used an 
arrow, rather than an "equals sign" for assignment.



I remember a cartoon in Datamation?? 4 decades ago, of some egyptologists 
looking at some hieroglyphics and declaring, "It looks like a subset of 
APL"


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: APL\360

[Mark Linimon via cctalk]

On Thu, Jan 14, 2021 at 06:42:34PM -0800, Fred Cisin via cctalk wrote:
> APL was terse.

That's a nice way of saying "It was a write-only language".

Even back when my brain still worked 100% I could only remember what
the code I had just written actually _did_ for 24-48 hours.  After
that it was easier to rewrite from scratch.

mcl

Re: APL\360

[Fred Cisin via cctalk]

APL was terse.

On Fri, 15 Jan 2021, Mark Linimon wrote:

That's a nice way of saying "It was a write-only language".

Even back when my brain still worked 100% I could only remember what
the code I had just written actually _did_ for 24-48 hours.  After
that it was easier to rewrite from scratch.


It was, indeed, a "write-only language", although I didn't have difficulty 
reading my own code for a year.  Who else could read it?  Presumably 
nobody.
Whereas, a COBOL or FORTRAN program is potentially readable by any COBOL 
or FORTRAN  programmer.


But, in calling it "terse", I also meant that the source code density was 
extraordinarily high.  Thousands of lines of other languages could be done 
in dozens of lines of APL, unlike the verbosity of other "high level 
languages".  Which, of course, substantially reinforced its opacity to any 
but the programmer.



But, when using it instead of a calculator for one-time processing 
(programs that were not intended to be reused in the future), 
nothing could compare for inverting a matrix, etc.
"I want you to give me a least squares curve fit of E Vs L for this subset 
of the data", . . .


'Course, when I questioned the use of two decimal digits for year in our 
datafiles (National Space Sciences Data Center, building 26 GSFC), I was 
assured that "NONE of what we do now has any possibility of being used 
again in 30 years!"  And, THAT was the true Y2K problem.



--
Grumpy Ol' Fred ci...@xenosoft.com

Re: APL\360

[Chuck Guzis via cctalk]

On 1/14/21 6:42 PM, Fred Cisin via cctalk wrote:
> APL was terse.
> 
> You could do amazing things with very short source code.
> Extremely well suited for scientific programming.
> (I used it on a timesharing terminal at Goddard Space Flight Center half
> a century ago)
> 
> It had a lot of operators.  So much so that it had to expand the
> character set.  Typically, it was used on a Selectric based terminal,
> with a special type-ball, and added labels pasted on the keys.
> 
> Unlike English based languages, such as FORTRAN or COBOL, anybody other
> than an APL programmer could not even guess what a line of APL did.

APL was difficult for those used to traditional programming languages,
not primarily because of the character set, but because it's basically a
vector/matrix programming language.

It's a different world from BASIC, for sure.

Neil maintained that its strength lay in thinking about things in a
non-scalar way.  I'll give him that--programming on STAR, where a scalar
was treated by the hardware as a vector of length 1 (and thus very slow
because of startup overhead) certainly led you toward thinking about
things in vector operations, just like APL.

Here's the APL*STAR reference manual:

http://www.softwarepreservation.org/projects/apl/Books/197409_APL%20Star%20Reference%20Manual_19980800B.pdf

--Chuck

Re: APL\360

[Fred Cisin via cctalk]

On Thu, 14 Jan 2021, Chuck Guzis via cctalk wrote:

It's a different world from BASIC, for sure.

Neil maintained that its strength lay in thinking about things in a
non-scalar way.  I'll give him that--programming on STAR, where a scalar
was treated by the hardware as a vector of length 1 (and thus very slow
because of startup overhead) certainly led you toward thinking about
things in vector operations, just like APL.

Here's the APL*STAR reference manual:

http://www.softwarepreservation.org/projects/apl/Books/197409_APL%20Star%20Reference%20Manual_19980800B.pdf


Thank you for that!

You are right.  At the time, it simply never occured to me that anybody 
would use it for anything other than matrix processing of scientific data.

(MY view of the elephant)


Yes, I suppose that somebody of sufficient skill COULD write accounting 
software with it, . . .

But why?


And, one of the advantages of COBOL for business programming was the 
possibility of checking somebody else's code.  APL was intrinsically 
obfuscated code.

Re: APL\360

[Mark Linimon via cctalk]

On Thu, Jan 14, 2021 at 07:55:52PM -0800, Fred Cisin via cctalk wrote:
> Yes, I suppose that somebody of sufficient skill COULD write
> accounting software with it, . . .
> But why?

When I was living outside Dallas around 1988 or so, I knew a woman who
had a job-for-life with an insurance company that ran their whole company
on APL.  Of course by that time she was sick of working on the same thing
all the time, but they could not afford to let her go -- no one else could
do any maintance to it.

(I no longer remember the name of the insurance company ...)

mcl

Re: APL\360

[Chuck Guzis via cctalk]

On 1/14/21 7:55 PM, Fred Cisin wrote:

> You are right.  At the time, it simply never occured to me that anybody
> would use it for anything other than matrix processing of scientific data.
> (MY view of the elephant)

The vector thing did strange things to your thinking.  Any scalar
instruction was basically timed at k+e, where k is the pipeline startup
time and e is the actual time to do the operation.

Vectors of length n basically had timings of k+ne.  That lead to all
sorts of interesting things, such as for N<1000, the fastest sort was a
vector selection sort, not any of the traditional scalar methods such as
Quicksort.  Hashing a lookup table was often slower than simply
performing a serial search.   I wrote a text editor back around 1974
using vector instructions as a bootleg project. I found the same editor
still in use in 1985 on the ETA-10 super. It was called OGNATE, for "oh
god, not another text editor".

So, you could see how APL was somehow appropriate to the architecture.
Too bad that nobody really used it.  FORTRAN, FORTRAN and more FORTRAN.

I was able to speed up the OS resident by almost 30 percent by rewriting
scalar code as vector and making some scalar optimizations.   The
implementation language was IMPL, a dialect of LRLTRAN.

The instruction set on the STAR was, to put it mildly, huge.  Later
CYBER and ETA implementations stripped a lot of the more exotic
instructions away--and added a dedicated scalar unit.

Good times on a failed project...

Now, of course, any major CPU has vector instructions squirreled away
somewhere; e.g. Intel SSE, AVX, etc.

--Chuck

Re: APL\360

[Paul Koning via cctalk]

> On Jan 14, 2021, at 10:55 PM, Fred Cisin via cctalk  
> wrote:
> 
> On Thu, 14 Jan 2021, Chuck Guzis via cctalk wrote:
>> It's a different world from BASIC, for sure.
>> 
>> Neil maintained that its strength lay in thinking about things in a
>> non-scalar way.  I'll give him that--programming on STAR, where a scalar
>> was treated by the hardware as a vector of length 1 (and thus very slow
>> because of startup overhead) certainly led you toward thinking about
>> things in vector operations, just like APL.
>> 
>> Here's the APL*STAR reference manual:
>> 
>> http://www.softwarepreservation.org/projects/apl/Books/197409_APL%20Star%20Reference%20Manual_19980800B.pdf
> 
> Thank you for that!
> 
> You are right.  At the time, it simply never occured to me that anybody would 
> use it for anything other than matrix processing of scientific data.
> (MY view of the elephant)
> 
> Yes, I suppose that somebody of sufficient skill COULD write accounting 
> software with it, . . .
> But why?

Interesting.

I used APL around 1995 (with GNU APL, on a Solaris system).  The application 
was code breaking programs for an online course in cryptanalysis taught by Alex 
Biryukov at Technion Haifa.  Great course.  It would be nice to clean up that 
implementation to use Unicode for its APL text.

Did you know there's an ISO standard for APL?  I have it somewhere.

Another APL application I remember reading about was a microcode compiler for 
an RSA chip designed by Rivest, somewhere in the early 1980s if I remember 
right.  It's documented in an article in the first issue of what was then 
Lambda magazine, later renamed to "VLSI design".  Rivest mentioned either in 
the article or in a lecture at DEC that the microcode was converted to chip 
layout by a large APL program.  I don't remember how large -- 500 lines?

paul

Re: APL\360

[Kevin Jordan via cctalk]

If you would like to re/experience APL, four classic implementations are
available on five machines running at the Nostalgic Computing Center
<http://www.nostalgiccomputing.org>:

   - APL 2 (aka APLUM) on the CDC Cyber 865 and Cyber 175 NOS 2 systems
   - APLSF on the PDP-10 TOPS-20 system
   - APL-11 on the PDP-11 RSX-11M-Plus system
   - APL/Z on the Z80 CP/M system

The NCC is also planning to install APL\360 on its IBM 4381 VM/CMS system,
per instructions recently posted on the Hercules forum.

cheers,
Kevin

On Thu, Jan 14, 2021 at 8:45 PM Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

> I was just poking around the computerhistory.org website, searching for
> Knuth stuff.
>
> The second or third hit when I search for "Knuth" is this one:
> https://computerhistory.org/blog/the-apl-programming-language-source-code/
> .  It's not just about APL, it actually has a downloadable copy of the
> source code.  And it points to an executable version, apparently a packaged
> up Hercules running that code.
>
> Nice.  I'll have to give it a try.
>
> paul
>
>

Re: APL\360

[Nemo Nusquam via cctalk]

On 01/14/21 23:35, Mark Linimon via cctalk wrote (in part):

When I was living outside Dallas around 1988 or so, I knew a woman who
had a job-for-life with an insurance company that ran their whole 
company on APL. Of course by that time she was sick of working on the 
same thing all the time, but they could not afford to let her go -- no 
one else could do any maintance to it.


In 1999, a fellow student in a UML course worked for a large information 
company (Reuters, I think?) and told me that they had embarked on an 
expensive s/w conversion project.  Their back-end systems were 
implemented in APL and they could not find programmers -- even ones 
willing to learn APL for pay.


N.

Re: APL\360

[Lee Courtney via cctalk]

Norman,

Same here, but archived at the CHM Software Preservation site:
http://www.softwarepreservation.org/projects/apl

If there is anything you have that is missing from the above site I'd love
to add it. Please drop me an email.

BTW my Dad was one of the first users of the original 2 cassette MCM-70 in
the US. We had one at home, along with a selectric terminal that we used
(from 1969 on) to access APL on a mainframe. Fun days. His MCM machine is
on display at CHM.

Lee Courtney

On Thu, Jan 14, 2021 at 6:28 PM Norman Jaffe via cctalk <
cctalk@classiccmp.org> wrote:

> I remember colleagues competing for the most 'interesting' one-liner in
> APL that actually did something useful, in university.
> I wrote several different kinds of simulator, one of which generated APL
> code on the fly that was then executed... plus a database-or-two.
> I've been actively collecting APL memorabilia and books for years now...
> if I could find an MCM/70 it would be awesome...
>
> From: "cctalk" 
> To: "cctalk" 
> Sent: Thursday, January 14, 2021 6:22:39 PM
> Subject: Re: APL\360
>
> On 1/14/21 5:44 PM, Paul Koning via cctalk wrote:
> > I was just poking around the computerhistory.org website, searching for
> Knuth stuff.
> >
> > The second or third hit when I search for "Knuth" is this one:
> https://computerhistory.org/blog/the-apl-programming-language-source-code/
> . It's not just about APL, it actually has a downloadable copy of the
> source code. And it points to an executable version, apparently a packaged
> up Hercules running that code.
> >
> > Nice. I'll have to give it a try.
>
>
> I recall Neil Lincoln (he of CDC/ETA) relating that he taught APL to his
> kids and his wife (APL was pretty much a natural for the STAR) as a
> first programming language.
>
> I took some time to learn it fairly well, but never really had any
> opportunity to use it much, so it's gone into the memory dustbin of old
> never-used languages of my brain.
>
> A co-worker back when would never use the name of the book or the
> abbreviation. He always referred to it as "that Iverson language" or
> "TIL".
>
> And it's comparatively easy to write short, perfectly opaque code in
> APL; probably more so than other common languages.
>
> --Chuck
>


-- 
Lee Courtney
+1-650-704-3934 cell

Re: APL\360

[Gavin Scott via cctalk]

On Fri, Jan 15, 2021 at 9:05 AM Kevin Jordan via cctalk
 wrote:
>
> If you would like to re/experience APL, four classic implementations are
> available on five machines running at the Nostalgic Computing Center
> :

There's also HP's APL\3000 running on your own virtual 1979 HP 3000
Series III with the HP 2641A APL Display Station Terminal, included in
my turnkey HP 3000 simulator setup which is still up on my Drive for
now:

https://drive.google.com/file/d/1bmXvHkBLbUeLAid73EJ4H1yQ2uwXQuRu

APL is still a going concern in a few places, and there's an active
ACM APL SIG for it, as well as a few actively supported and evolving
commercial implementations. I did a presentation on APL\3000 (which is
a functional duplicate of IBM's APL.SV) for the APL SIG a while back.
There's also an APL WIKI at https://aplwiki.com/ with lots of
historically interesting information.

G.

Re: APL\360

[Liam Proven via cctalk]

On Fri, 15 Jan 2021 at 17:21, Nemo Nusquam via cctalk
 wrote:
>
> In 1999, a fellow student in a UML course worked for a large information
> company (Reuters, I think?) and told me that they had embarked on an
> expensive s/w conversion project.  Their back-end systems were
> implemented in APL and they could not find programmers -- even ones
> willing to learn APL for pay.

Later than that, Morgan Stanley was still using significant amounts of
APL, albeit in its own in-house dialect, A+

https://en.wikipedia.org/wiki/A%2B_(programming_language)

My lodger at one point (around 2005 I think) got a job with MS and had
to learn A+. He was a heavy Perl user before and maintained some
official Perl packages. He was given to improvising tiny cryptic Perl
one-liners on Linux to work stuff out, calculate dates, do file
management, etc. IOW he thought in Perl.

He commented to me in the pub a year or 2 later that he realised one
evening, doing some Perl work, that after some years working in A+, he
now found Perl irritatingly verbose, and that realisation rather
shocked him. :-)

Of course this is some 15Y ago now and it may no longer be in use, but
it certainly was well past the turn of the century.

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: APL\360

[Lee Courtney via cctalk]

Paul et al,

Along with the APL\360 material Len Shustek put together on the CHM web
site, there is a site I maintain at CHM hosting documents, papers, books,
etc on the history and evolution of APL as well as historic APL source code
and implementations: http://www.softwarepreservation.org/projects/apl/

I am always looking for more material to add.

There was also a recent forum by the Bristish APL Association discussing
history and future of APL. Unfortunately not yet posted to Youtube.

Lee COurtney

On Thu, Jan 14, 2021 at 5:45 PM Paul Koning via cctalk <
cctalk@classiccmp.org> wrote:

> I was just poking around the computerhistory.org website, searching for
> Knuth stuff.
>
> The second or third hit when I search for "Knuth" is this one:
> https://computerhistory.org/blog/the-apl-programming-language-source-code/
> .  It's not just about APL, it actually has a downloadable copy of the
> source code.  And it points to an executable version, apparently a packaged
> up Hercules running that code.
>
> Nice.  I'll have to give it a try.
>
> paul
>
>

-- 
Lee Courtney
+1-650-704-3934 cell

Re: APL\360

[Liam Proven via cctalk]

On Fri, 15 Jan 2021 at 17:44, Gavin Scott via cctalk
 wrote:
>
> APL is still a going concern in a few places

Oh, definitely. I subscribed to the British APL Association's
newsletter from an advert in UK magazine PCW in the 1980s and
continued to get its publication, _Vector_, for over 20Y.

https://britishaplassociation.org/

I never understood it but I enjoyed the feeling of baffled
incomprehension I got from reading it. I was sad when it stopped.

When I was emigrating in 2014, I found an unopened copy of Vector in a
box in my garage. _That_ copy was the one in which they asked all
subscribers to confirm they still wanted it. :-(

So I resubbed online and now I get it again. providing that warm
comforting sensation of intellects vast and cool, as immeasurably
superior to my own as mine is to that of the transient creatures that
swarm and multiply in a drop of water.

https://vector.org.uk/

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: APL\360

[Christian Corti via cctalk]

That reminds me of the APL\360 implementation running on the IBM 5100 and 
5110 using a rudimental System/360 emulator written in PALM machine code 
stored in the APL Executable ROS. The APL interpreter is stored in the APL 
language ROS and was accessed like an I/O device, i.e. the emulator 
fetched the 360 instructions with instructions like GETB and so on.


Also, I *think* that the PALM assembler used by IBM was written in APL, at 
least that's the impression I got when reading the documents from H. J. 
Myers "Instructions for the use of the Assembler Generator", and IBM 
report no. ZZ20-6431 "A Fast Assembly Technique Using APL"


Christian

Re: APL\360

[Bill Gunshannon via cctalk]

On 1/14/21 10:55 PM, Fred Cisin via cctalk wrote:

On Thu, 14 Jan 2021, Chuck Guzis via cctalk wrote:

It's a different world from BASIC, for sure.

Neil maintained that its strength lay in thinking about things in a
non-scalar way.  I'll give him that--programming on STAR, where a scalar
was treated by the hardware as a vector of length 1 (and thus very slow
because of startup overhead) certainly led you toward thinking about
things in vector operations, just like APL.

Here's the APL*STAR reference manual:

http://www.softwarepreservation.org/projects/apl/Books/197409_APL%20Star%20Reference%20Manual_19980800B.pdf 



Thank you for that!

You are right.  At the time, it simply never occured to me that anybody 
would use it for anything other than matrix processing of scientific data.

(MY view of the elephant)


Yes, I suppose that somebody of sufficient skill COULD write accounting 
software with it, . . .

But why?



There was a company her in Scranton, PA that did a very complex
financials package in APL.  One of my students interned there
and enjoyed the work.  Wy, you say?  Probably better than encryption
for protecting the source code.  :-)



And, one of the advantages of COBOL for business programming was the 
possibility of checking somebody else's code.  APL was intrinsically 
obfuscated code.


I  have known many APL programmers who would not agree with this.  When
I was doing COBOL and Fortran at West Point, NY we had an intern from
Marist College.  APL was their common instructional language and the
only one our intern knew when he started.

It was at West Point that I learned APL and I have since run it on
everything from a Micro to a mainframe.   Still have a version that
runs quite well on my TRS-80's.

bill

Re: APL\360

[Nemo Nusquam via cctalk]

On 01/15/21 11:50, Liam Proven via cctalk wrote (in part):

I never understood it but I enjoyed the feeling of baffled
incomprehension I got from reading it.
As a grad student, I still remember the row of APL terminals at the 
computer centre with their APL-specific keyboards, always ruing that I 
had no time to learn it.

Re: APL\360

[Toby Thain via cctalk]

On 2021-01-15 1:33 p.m., Nemo Nusquam via cctalk wrote:
> As a grad student, I still remember the row of APL terminals at the
> computer centre with their APL-specific keyboards, always ruing that I
> had no time to learn it.

Seems backwards when students have no time to learn things. Just sayin

--T

Re: APL\360

[Boris Gimbarzevsky via cctalk]

Thanks for the link.  Coincidentally, recently while going through my 
ancient Calgary printouts, found a few small APL programs I wrote in 
1968 or 1969.  There was an APL system being trialed at UofCalgary 
and a group of us had a chance to play around with it for a few 
hours.  It was very novel back then to have immediate results of a 
program instead of 24-48 hour turnaround for a batch FORTRAN job.  It 
was an easy language to learn but recall just writing a few simple 
one or two line programs and essentially using it as a sophisticated 
calculator to get immediate results for a physics problem.


Glad to see that APL manuals now online and can now decode what I was 
trying to do on those printouts with APL hieroglyphics.  Reminds me a 
bit of FOCAL on PDP-8 which was used to quickly create throwaway 
programs that were just needed for a calculation that was too tedious 
to do by hand or with a slide rule but too simple to go through 
bother of writing a FORTRAN program.


I was just poking around the computerhistory.org website, searching 
for Knuth stuff.


The second or third hit when I search for "Knuth" is this one: 
https://computerhistory.org/blog/the-apl-programming-language-source-code/ 
.  It's not just about APL, it actually has a downloadable copy of 
the source code.  And it points to an executable version, apparently 
a packaged up Hercules running that code.


Nice.  I'll have to give it a try.

paul

Re: APL\360

[Chuck Guzis via cctalk]

It's also worth noting that (ostensibly) the first complete
microcomputer system (keyboard, printer, storage) was the MCM/70, using
an 8008 implementing APL (not BASIC!).

https://en.wikipedia.org/wiki/MCM/70

I'll say it again--a programmer who thinks in APL is very different from
one who thinks in BASIC, Fortran, C, Pascal, etc.

So of course, an APL program would look unintelligible to a non-APL
programmer.

--Chuck

Re: APL\360

[Nemo Nusquam via cctalk]

On 01/15/21 14:25, Toby Thain wrote:

On 2021-01-15 1:33 p.m., Nemo Nusquam via cctalk wrote:
As a grad student, I still remember the row of APL terminals at the 
computer centre with their APL-specific keyboards, always ruing that 
I had no time to learn it. 

Seems backwards when students have no time to learn things. Just sayin
I was in math, not computer science.  APL would have been a curiousity 
and nothing else.


N.

Re: APL\360

[Ron Pool via cctalk]

Gavin -- It looks like you have frequents updates of your virtual HP 3000 
setup.  Is there someplace I can subscribe to learn of updates to your 
collection?

-- Ron Pool

On 1/15/21, 11:44 AM, "cctalk on behalf of Gavin Scott via cctalk" 
 wrote:
There's also HP's APL\3000 running on your own virtual 1979 HP 3000
Series III with the HP 2641A APL Display Station Terminal, included in
my turnkey HP 3000 simulator setup which is still up on my Drive for
now:

https://drive.google.com/file/d/1bmXvHkBLbUeLAid73EJ4H1yQ2uwXQuRu

Re: APL\360

[Bill Gunshannon via cctalk]

On 1/15/21 3:11 PM, Chuck Guzis via cctalk wrote:

It's also worth noting that (ostensibly) the first complete
microcomputer system (keyboard, printer, storage) was the MCM/70, using
an 8008 implementing APL (not BASIC!).

https://en.wikipedia.org/wiki/MCM/70

I'll say it again--a programmer who thinks in APL is very different from
one who thinks in BASIC, Fortran, C, Pascal, etc.

So of course, an APL program would look unintelligible to a non-APL
programmer.



But being an APL programmer does not preclude using all the other
languages.  One need to pick the language suitable for the job.
Back in the days when APL, COBOL, Fortran, ALGOL, etc. were the
norm languages were created domain specific.  Today they are all
just General Purpose.

As a side note, while I know and have used the APL Character Set
I have only ever owned two terminals that had it and most of my
APL was done using DiGraphs and TriGraphs.

bill

Re: APL\360

[Fred Cisin via cctalk]

On Fri, 15 Jan 2021, Nemo Nusquam via cctalk wrote:
As a grad student, I still remember the row of APL terminals at the computer 
centre with their APL-specific keyboards, always ruing that I had no time to 
learn it.


I guess that I was lucky?

At GSFC, I was in an entry level job ("Data Technician"), having EAM 
experience and some FORTRAN, being paid as a go-fer, but being expected to 
learn and do more and more stuff.  Such as simple FORTRAN to draw graphs 
on Calcomp plotters.


I had some calculations to do, and THE calculator (on a typewriter cart) 
was in use elsewhere.


One of my senior cow-orkers (a programmer) spent about a minute showing me 
that you could do routine arithmetic in APL.

So, it only took a few minutes before it was saving me time and effort.

After I was using it for calculator work for a little while, he came back 
and showed me how to write simple programs, and got me access to some 
manuals.


I was never GREAT, but I found it easy to learn new stuff in it.  I had 
been fascinated with matrix algebra in high school, and was thrilled to 
see some of the things that APL could do.


--
Grumpy Ol' Fred ci...@xenosoft.com

RE: APL\360

[Dave Wade G4UGM via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Nemo Nusquam
> via cctalk
> Sent: 15 January 2021 21:51
> To: Toby Thain ; General Discussion: On-Topic
> and Off-Topic Posts 
> Subject: Re: APL\360
> 
> On 01/15/21 14:25, Toby Thain wrote:
> > On 2021-01-15 1:33 p.m., Nemo Nusquam via cctalk wrote:
> >> As a grad student, I still remember the row of APL terminals at the
> >> computer centre with their APL-specific keyboards, always ruing that
> >> I had no time to learn it.
> > Seems backwards when students have no time to learn things. Just sayin


> I was in math, not computer science.  APL would have been a curiousity and
> nothing else.

I was in Mathematics (sorry I am English) and I wrote code in APL to do 
Critical Path Analysis with Heuristic Resource Levelling in APL. Sadly I no 
longer have the code.
I believe APL was widely used by actuaries to calculate life assurance premiums 
because of its ability to do array manipulations, 


> 
> N.

Dave

Re: APL\360

[Fred Cisin via cctalk]

As a grad student, I still remember the row of APL terminals at the
computer centre with their APL-specific keyboards, always ruing that I
had no time to learn it.

On Fri, 15 Jan 2021, Toby Thain via cctalk wrote:

Seems backwards when students have no time to learn things. Just sayin


There are some flaws in our educational system.
Such as directing learning so rigidly that students are discouraged from 
exploring.


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: APL\360

[Bill Gunshannon via cctalk]

On 1/15/21 6:11 PM, Fred Cisin via cctalk wrote:

As a grad student, I still remember the row of APL terminals at the
computer centre with their APL-specific keyboards, always ruing that I
had no time to learn it.

On Fri, 15 Jan 2021, Toby Thain via cctalk wrote:

Seems backwards when students have no time to learn things. Just sayin


There are some flaws in our educational system.
Such as directing learning so rigidly that students are discouraged from 
exploring.


--
Grumpy Ol' Fred ci...@xenosoft.com



Even worse when they are told specifically to "not waste time" learning
things like APL or COBOL.

bill

Re: APL\360

[Fred Cisin via cctalk]

There are some flaws in our educational system.
Such as directing learning so rigidly that students are discouraged from 
exploring.


On Fri, 15 Jan 2021, Bill Gunshannon via cctalk wrote:

Even worse when they are told specifically to "not waste time" learning
things like APL or COBOL.


THAT is truly criminal.

A viewpoint opposed to mine:
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense."  - Edsger Dijkstra


Choosing to learn it, or APL, etc. is an admirable educational exercise.

A tangential recreational educational exploration is NEVER a "waste of 
time".


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: APL\360

[Chuck Guzis via cctalk]

On 1/15/21 3:07 PM, Bill Gunshannon via cctalk wrote:

> But being an APL programmer does not preclude using all the other
> languages.  One need to pick the language suitable for the job.
> Back in the days when APL, COBOL, Fortran, ALGOL, etc. were the
> norm languages were created domain specific.  Today they are all
> just General Purpose.

That's certainly true, but using a traditional language, such as JOVIAL
or PL/I is a lot more straightforward to an APL programmer (just view
everything as scalar and forget about the vector operators) than the
reverse.

My point is that taking APL as a starting point leads one to think about
problems differently.

--Chuck

Re: APL\360

[Fred Cisin via cctalk]

At least Edsger Dijkstra thought that APL had been "carried through to 
perfection"!   "language of the future" for our programming techniques!

creates a new generation of coders"!


Oh, wait.  Here's the context:
"APL is a mistake, carried through to perfection. It is the language of 
the future for the programming techniques of the past: it creates a new 
generation of coding bums."   - Edsger Dijksta


https://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html

Re: APL\360

[Norman Jaffe via cctalk]

I have found that the ideal combination of languages to learn early are APL, 
Simula, LISP and Smalltalk. 
I was lucky enough to have started programming when that was possible. 

From: "cctalk"  
To: "cctalk"  
Sent: Friday, January 15, 2021 4:13:26 PM 
Subject: Re: APL\360 

On 1/15/21 3:07 PM, Bill Gunshannon via cctalk wrote: 

> But being an APL programmer does not preclude using all the other 
> languages. One need to pick the language suitable for the job. 
> Back in the days when APL, COBOL, Fortran, ALGOL, etc. were the 
> norm languages were created domain specific. Today they are all 
> just General Purpose. 

That's certainly true, but using a traditional language, such as JOVIAL 
or PL/I is a lot more straightforward to an APL programmer (just view 
everything as scalar and forget about the vector operators) than the 
reverse. 

My point is that taking APL as a starting point leads one to think about 
problems differently. 

--Chuck 

Re: APL\360

[Paul Koning via cctalk]

> On Jan 15, 2021, at 6:41 PM, Fred Cisin via cctalk  
> wrote:
> 
>>> There are some flaws in our educational system.
>>> Such as directing learning so rigidly that students are discouraged from 
>>> exploring.
> 
> On Fri, 15 Jan 2021, Bill Gunshannon via cctalk wrote:
>> Even worse when they are told specifically to "not waste time" learning
>> things like APL or COBOL.
> 
> THAT is truly criminal.
> 
> A viewpoint opposed to mine:
> "The use of COBOL cripples the mind; its teaching should, therefore, be 
> regarded as a criminal offense."  - Edsger Dijkstra

Then again, there was this observation from my sister, who made her living 
writing COBOL and RPG:

"COBOL is the programming language that gives you writer's cramp".

paul

Re: APL\360

[Paul Koning via cctalk]

> On Jan 15, 2021, at 7:33 PM, Norman Jaffe via cctalk  
> wrote:
> 
> I have found that the ideal combination of languages to learn early are APL, 
> Simula, LISP and Smalltalk. 
> I was lucky enough to have started programming when that was possible. 

Interesting.

My first was ALGOL 60.

One measure I've used is that, out of 40 or so languages I know, with only two 
have I gone from "no knowledge" to "able to write a substantial program" in one 
week.  One was Pascal (in university -- computer course code generator).  The 
other was Python (about 15 years ago, a substantial enhancement to cvs2svn).

paul

Re: APL\360

[Liam Proven via cctalk]

On Fri, 15 Jan 2021 at 17:50, Liam Proven  wrote:

> So I resubbed online and now I get it again. providing that warm
> comforting sensation of intellects vast and cool, as immeasurably
> superior to my own as mine is to that of the transient creatures that
> swarm and multiply in a drop of water.

On which note, from a totally different source, this may amuse the
Perl _and_ APL fans:
http://www.dlugosz.com/Perl6/web/APL.html

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: APL\360

[Jon Elson via cctalk]

On 01/15/2021 05:07 PM, Bill Gunshannon via cctalk wrote:

On 1/15/21 3:11 PM, Chuck Guzis via cctalk wrote:

It's also worth noting that (ostensibly) the first complete
microcomputer system (keyboard, printer, storage) was the 
MCM/70, using

an 8008 implementing APL (not BASIC!).

I had to see this message several times before I saw the 
8008!  WOW, the 8008 was a very limited
processor, I'm amazed it could handle APL!  I built an 8008 
system using wire-wrap in 1976, but it only had 256 bytes of 
static RAM, and a keypad and LEDs for a console.


Jon

Re: APL\360

[Jon Elson via cctalk]

On 01/15/2021 07:18 PM, Paul Koning via cctalk wrote:


One measure I've used is that, out of 40 or so languages I 
know, with only two have I gone from "no knowledge" to 
"able to write a substantial program" in one week. One was 
Pascal (in university -- computer course code generator).
I used to be a Pascal proselytizer, using it on PDP-11 and 
VAX, then on PCs with Borland Turbo Pascal.
I found that when I got a Pascal program to compile, it 
would generally run first time, as the language nudged me to 
think clearly.
I wrote a number of modest programs with it, and then one 
larger program to take Gerber files and generate raster data 
for a photoplotter.  This turned out to be quite a large and 
intricate program.
I just used it as a tool for a number of years, and stopped 
using Pascal as I had migrated to Linux.
Then, FPC (Free Pascal Compiler) came out, specifically 
aimed at accepting Turbo Pascal and DEC Pascal extensions, 
units, etc.  I converted my old photoplotter program to run 
under Linux and FPC, and of course, it ran many times faster 
on new hardware.


Jon

Re: APL\360

[Eric Smith via cctalk]

On Fri, Jan 15, 2021 at 4:41 PM Fred Cisin via cctalk 
wrote:

> A viewpoint opposed to mine:
> "The use of COBOL cripples the mind; its teaching should, therefore, be
> regarded as a criminal offense."  - Edsger Dijkstra
>

As much as I generally highly respect Dijkstra, I agree with Fred, not
Dijkstra, on this one. COBOL was a remarkably good language for the problem
domain for which it was intended. As with all tools, it is less good for
other problem domains.

Learning and using any programming language will cause some language
specific habits to become ingrained, and you may have to "unlearn" some
when you learn a new language. That doesn't necessarily make either
language bad.

Re: APL\360

[Chuck Guzis via cctalk]

On 1/19/21 10:01 PM, Eric Smith via cctalk wrote:

> Learning and using any programming language will cause some language
> specific habits to become ingrained, and you may have to "unlearn" some
> when you learn a new language. That doesn't necessarily make either
> language bad.
> 

Hence PL/I.  You can wield your bad programming habits in three
languages all within the same program unit.

--Chuck

Re: APL\360

[Bill Gunshannon via cctalk]

On 1/20/21 1:01 AM, Eric Smith via cctalk wrote:

On Fri, Jan 15, 2021 at 4:41 PM Fred Cisin via cctalk 
wrote:


A viewpoint opposed to mine:
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense."  - Edsger Dijkstra



As much as I generally highly respect Dijkstra, I agree with Fred, not
Dijkstra, on this one. 


After reading many of Dijkstra's one liners I find I don't like
him or his opinions at all.


  COBOL was a remarkably good language for the problem
domain for which it was intended. As with all tools, it is less good for
other problem domains.


COBOL came from a time when most languages were domain specific. It
is sad that things like efficiency and proper design have been abandoned
in favor of general purpose languages and solutions.



Learning and using any programming language will cause some language
specific habits to become ingrained, and you may have to "unlearn" some
when you learn a new language. That doesn't necessarily make either
language bad.



Learning many different paradigms makes it easier to and more
likely that you will choose the right tool for the job.  In
the world of general purpose languages all you have is a hammer
and so all tasks look like nails.

bill

Re: APL\360

[ben via cctalk]

On 1/20/2021 10:16 AM, Bill Gunshannon via cctalk wrote:



Learning many different paradigms makes it easier to and more
likely that you will choose the right tool for the job.  In
the world of general purpose languages all you have is a hammer
and so all tasks look like nails.

bill



I don't see languages in general have improved since the the mid
1960's. Hardware and language models don't reflect each other,
and don't have extendable data sizes and types.
PL/I seems to have been the best,but too tied to IBM.
C standard 2131 complex numbers
C standard 2143 dubble complex numbers
Every machine I can think of had a carry flag of some type
yet no language uses that to extend it self.

 I don't believe in objects because data structures don't
have classes, but are more similar to each other. A window
 A structure is like window B but details are different.
That makes things look portable when they are not.


Constants still
seem to be embedded in data structures, rather than abstract.
-- zero array
define LIMIT abc
blah array[LIMIT]
...
i = 0 while i< LIMIT array[i] = 0 i = i + 1 endw
I would like say
let LIMIT = abc
blah array[LIMIT]
i = 0 while i< array:LIMIT array[i] = 0 i = i + 1 endw
 Ben.

Re: APL\360

[Peter Corlett via cctalk]

On Thu, Jan 14, 2021 at 07:43:13PM -0800, Chuck Guzis via cctalk wrote:
[...]
> APL was difficult for those used to traditional programming languages, not
> primarily because of the character set, but because it's basically a
> vector/matrix programming language.

It is *also* the use of symbols. Firstly, some people are just symbol-blind
and prefer stuff spelled out in words. It's just how brains are wired.
Secondly, beyond BODMAS, the meaning and precedence of random symbols is
unclear to casual readers. Calls to named functions tend to be more
descriptive -- "map" and "filter" mean the same sort of thing across
functional(-inspired) languages -- and the precedence is obvious thanks to
the parentheses.

At a guess, part of the reason APL does this is so that the programmer
pre-tokenises the input to make it easier for the language to process.
Sinclair BASIC did this too, to much wailing and gnashing of teeth. It may
have even been inspired to do this by APL given the manual says Sinclair
BASIC was written by a "Cambridge mathematician".

The "modern" vector/matrix programming language most commonly used by
contemporary programmers use is probably SQL. It's amazing how many people
use it inefficiently as a key-value store when it's really a
matrix-transformation language even though it *looks* like an imperative
language. The 1970s has a lot to answer for.

> It's a different world from BASIC, for sure.

Yes, well, a lot of BASIC programmers have even more fundamental problems
with understanding important programming concepts, such as recursion and
pointers/references. Without those, a lot of important algorithms cannot be
implemented, or even understood.

> Neil maintained that its strength lay in thinking about things in a
> non-scalar way. I'll give him that--programming on STAR, where a scalar
> was treated by the hardware as a vector of length 1 (and thus very slow
> because of startup overhead) certainly led you toward thinking about
> things in vector operations, just like APL.

Modern x86-64 (and ARM etc) also (finally!) has useful vector instructions.
Unfortunately, the popular languages do not make their use terribly simple,
and mostly rely on compilers recognising idiomatic loop patterns over
scalars and transforming them. This works about as well as you might expect.

Re: APL\360

[Gavin Scott via cctalk]

On Fri, Jan 29, 2021 at 6:11 AM Peter Corlett via cctalk
 wrote:
> Secondly, beyond BODMAS, the meaning and precedence of random symbols is
> unclear to casual readers.

An issue that plagues other operator-rich languages, but not APL since
APL follows a strict right-to-left evaluation order for ALL operators
(no BODMAS in sight). You can use parentheses to affect it, but it's
not as hard to figure out a complex APL expression as one might
naively expect at first glance.

The symbols did greatly limit the growth of APL in its early years
just because it made the cost of entry higher so not as many people
were exposed to it, and it also suffered the related "small
proprietary language" issue that has plagued pretty much every
language whose developers tried to get rich off the language itself.

Re: APL\360

[Paul Koning via cctalk]

> On Jan 29, 2021, at 7:27 AM, Gavin Scott via cctalk  
> wrote:
> 
> On Fri, Jan 29, 2021 at 6:11 AM Peter Corlett via cctalk
>  wrote:
>> Secondly, beyond BODMAS, the meaning and precedence of random symbols is
>> unclear to casual readers.
> 
> An issue that plagues other operator-rich languages, but not APL since
> APL follows a strict right-to-left evaluation order for ALL operators
> (no BODMAS in sight). You can use parentheses to affect it, but it's
> not as hard to figure out a complex APL expression as one might
> naively expect at first glance.

True, although right to left is not a natural way to read mathematical 
formulas.  The reason APL uses right to left is that the designers apparently 
were unwilling to change the direction of the assignment operator, so 
everything else had to follow.  Another language that doesn't have precedence 
avoided this issue by changing assignment to match the others, i.e., everything 
is left to right.  That is POP-2, a language out of the U of Edinborough I 
remember from an AI class.  So it would do stuff like:

a + 1 * 5 -> b

which in C would be

b = (a + 1) * 5;

and is definitely easier to read than the APL equivalent.

   paul

Re: APL\360

[Bill Gunshannon via cctalk]

On 1/29/21 7:27 AM, Gavin Scott via cctalk wrote:

On Fri, Jan 29, 2021 at 6:11 AM Peter Corlett via cctalk
 wrote:

Secondly, beyond BODMAS, the meaning and precedence of random symbols is
unclear to casual readers.


An issue that plagues other operator-rich languages, but not APL since
APL follows a strict right-to-left evaluation order for ALL operators
(no BODMAS in sight). You can use parentheses to affect it, but it's
not as hard to figure out a complex APL expression as one might
naively expect at first glance.

The symbols did greatly limit the growth of APL in its early years
just because it made the cost of entry higher so not as many people
were exposed to it, and it also suffered the related "small
proprietary language" issue that has plagued pretty much every
language whose developers tried to get rich off the language itself.



Curiously, in the very early 80's, it was the language of choice for
teaching computers at Marist College.  My understanding of the symbols
was that they are quite explanatory to a mathematician.  While I don't
have them in my head as most of the APL's I used worked on ASCII
terminals using Di-graphs and Tri-graphs, I can still understand and
even write APL.  It's fun to play with every once in a while.

bill

Re: APL\360

[Liam Proven via cctalk]

On Fri, 29 Jan 2021 at 13:11, Peter Corlett via cctalk
 wrote:
>
> It is *also* the use of symbols. Firstly, some people are just symbol-blind
> and prefer stuff spelled out in words. It's just how brains are wired.

Agreed. I submit this is also why some people find Lisp (and perhaps
Forth and Postscript) straightforward, while to others it remains
ineffable.

>  It may
> have even been inspired to do this by APL given the manual says Sinclair
> BASIC was written by a "Cambridge mathematician".

Specifically, this one, I believe:
https://en.wikipedia.org/wiki/Steve_Vickers_(computer_scientist)

> Yes, well, a lot of BASIC programmers have even more fundamental problems
> with understanding important programming concepts, such as recursion

Good BASICs had that.
> and
> pointers/references.

... Fair. :-(

> Modern x86-64 (and ARM etc) also (finally!) has useful vector instructions.
> Unfortunately, the popular languages do not make their use terribly simple,
> and mostly rely on compilers recognising idiomatic loop patterns over
> scalars and transforming them. This works about as well as you might expect.

Very interesting paper, IMHO:

https://queue.acm.org/detail.cfm?id=3212479
«
C Is Not a Low-level Language
Your computer is not a fast PDP-11.
»

It does imply the question, though, as to what a high-level language
designed for multithreaded partly-parallel CPUs with SIMD extensions
would look like, and whether this kind of logic is easily expressed
for people who do not have an APL sort of mind...

-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: APL\360

[Chuck Guzis via cctalk]

On 1/29/21 6:27 AM, Paul Koning via cctalk wrote:

> True, although right to left is not a natural way to read mathematical 
> formulas.  The reason APL uses right to left is that the designers apparently 
> were unwilling to change the direction of the assignment operator, so 
> everything else had to follow.  Another language that doesn't have precedence 
> avoided this issue by changing assignment to match the others, i.e., 
> everything is left to right.  That is POP-2, a language out of the U of 
> Edinborough I remember from an AI class.  So it would do stuff like:
> 
>   a + 1 * 5 -> b
> 
> which in C would be
> 
>   b = (a + 1) * 5;
> 
> and is definitely easier to read than the APL equivalent.

Well, part of the confusion lies in the difference of "=" in mathematics
indicating a property or state, as opposed to computer languages using
it as an operator. It's a subtle distinction, but important.

D = 4AC in mathematics establishes a property of D, whereas
D = 4*A*C in BASIC, etc. means "multiply 4 by A, then take that result
and multiply it by the value of C and store the result into D.

APL treats the assignment as what it is--an operation.   Why the RTL of
APL was chosen by Iverson, is a mystery; I agree.  He was, as far as I
know, not  native writer of Hebrew.  I suppose we should be grateful
that he didn't specify APL as a boustrophedon.

We already have Forth.

--Chuck

Re: APL\360

[Brian L. Stuart via cctalk]

On Friday, January 29, 2021, 10:19:54 AM EST, Liam Proven via cctalk 
 wrote: 
>On Fri, 29 Jan 2021 at 13:11, Peter Corlett via cctalk  
>wrote:
>>
>> It is *also* the use of symbols. Firstly, some people are just symbol-blind
>> and prefer stuff spelled out in words. It's just how brains are wired.
> 
> Agreed. I submit this is also why some people find Lisp (and perhaps
> Forth and Postscript) straightforward, while to others it remains
ineffable.

This reminds me of something I once heard Grace Hopper
say.  Now this won't be an exact quote since I'm relying
on some rather old memory.  As I remember it, she said:

"There are basically two kinds of people in the world.
The first is those of use who are Mathematicians at
heart.  We want to take all the words and turn them
into symbols.  Everyone else wants to take all the
symbols and turn them into words.  COBOL is for
them."

BLS

Re: APL\360

[Paul Koning via cctalk]

> On Jan 29, 2021, at 12:12 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 1/29/21 6:27 AM, Paul Koning via cctalk wrote:
> 
>> True, although right to left is not a natural way to read mathematical 
>> formulas.  The reason APL uses right to left is that the designers 
>> apparently were unwilling to change the direction of the assignment 
>> operator, so everything else had to follow.  Another language that doesn't 
>> have precedence avoided this issue by changing assignment to match the 
>> others, i.e., everything is left to right.  That is POP-2, a language out of 
>> the U of Edinborough I remember from an AI class.  So it would do stuff like:
>> 
>>  a + 1 * 5 -> b
>> 
>> which in C would be
>> 
>>  b = (a + 1) * 5;
>> 
>> and is definitely easier to read than the APL equivalent.
> 
> Well, part of the confusion lies in the difference of "=" in mathematics
> indicating a property or state, as opposed to computer languages using
> it as an operator. It's a subtle distinction, but important.
> 
> D = 4AC in mathematics establishes a property of D, whereas
> D = 4*A*C in BASIC, etc. means "multiply 4 by A, then take that result
> and multiply it by the value of C and store the result into D.
> 
> APL treats the assignment as what it is--an operation.   Why the RTL of
> APL was chosen by Iverson, is a mystery; I agree.  He was, as far as I
> know, not  native writer of Hebrew.  I suppose we should be grateful
> that he didn't specify APL as a boustrophedon.

You're correct about equality or identity vs. assignment, but that wasn't my 
point.  I should have used ALGOL rather than C as the "other language" example 
to avoid introducing that angle.

Yes, the right to left thing is really strange, since it requires changing the 
usual order of hundreds of operators to preserve the usual order of a single 
one, rather than serving the majority as POP-2 does.

BTW, I don't really know Hebrew but doesn't it still write math LTR?  I know 
they write numbers that way.

paul

Re: APL\360

[Peter Corlett via cctalk]

On Fri, Jan 15, 2021 at 11:21:11AM -0500, Nemo Nusquam via cctalk wrote:
[...]
> In 1999, a fellow student in a UML course worked for a large information
> company (Reuters, I think?) and told me that they had embarked on an
> expensive s/w conversion project. Their back-end systems were implemented
> in APL and they could not find programmers -- even ones willing to learn
> APL for pay.

I'd have taken it if the price was right. Heck, I seem to have spent most of
my career wading through fossilised Perl, so it's not as if I'd notice much
difference.

Companies moaning that they can't find staff inevitably turn out to be
offering less than the going rate for what they're demanding and/or the
company is toxic. Usually both.

Re: APL\360

[Fred Cisin via cctalk]

On Fri, 29 Jan 2021, Paul Koning via cctalk wrote:

BTW, I don't really know Hebrew but doesn't it still write math LTR?  I know 
they write numbers that way.


CAREFUL.

We don't need another BIG-endian/little-endian debate!
(when a 16 bit number is stored in bytes, does the high order byte come 
first, or the low order byte?)  (cf. intel V Motorola)

Re: APL\360

[Nemo Nusquam via cctalk]

On 29/01/2021 14:20, Fred Cisin via cctalk wrote:

We don't need another BIG-endian/little-endian debate!
(when a 16 bit number is stored in bytes, does the high order byte 
come first, or the low order byte?)  (cf. intel V Motorola)

Amen to that (but did it not originate with DEC vs. IBM?)

N.

Re: APL\360

[ben via cctalk]

On 1/29/2021 8:19 AM, Liam Proven via cctalk wrote:

On Fri, 29 Jan 2021 at 13:11, Peter Corlett via cctalk
 wrote:


It is *also* the use of symbols. Firstly, some people are just symbol-blind
and prefer stuff spelled out in words. It's just how brains are wired.


Agreed. I submit this is also why some people find Lisp (and perhaps
Forth and Postscript) straightforward, while to others it remains
ineffable.


Symbols I can live with. I can never remember them but that is not the 
point. ^\# is lot better than to say "invert matrix on diagonal".

 I like words because they tend to mean one thing,
not like Icons that imply something but never tell you just what.
In Car ~~  is that windshield wipers, flashing lights, or parking brake? 
GUI's are more a problem, they change every software revision. You can't 
use the online help, because you can't find where they moved it to in 
the menu, if can find the new menu.


Still annoyed at ASCII removing the -> (arrow) to something else.
you could write a+3 -> c leaving = for equal.
Why they needed all those control characters defined, but nobody used them?
Ben.

Re: APL\360

[Fred Cisin via cctalk]

On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote:

Well, part of the confusion lies in the difference of "=" in mathematics
indicating a property or state, as opposed to computer languages using
it as an operator. It's a subtle distinction, but important.

D = 4AC in mathematics establishes a property of D, whereas
D = 4*A*C in BASIC, etc. means "multiply 4 by A, then take that result
and multiply it by the value of C and store the result into D.

APL treats the assignment as what it is--an operation.   Why the RTL of
APL was chosen by Iverson, is a mystery; I agree.  He was, as far as I
know, not  native writer of Hebrew.  I suppose we should be grateful
that he didn't specify APL as a boustrophedon.

We already have Forth.


Therein lies one of the largest problems for first exposure to 
programming.
NO! We are NOT talking about "first exposure" as meaning a few years; we 
are talking about the first few DAYS (for most students, but up to 
weeks/months for some).  By the time that you got HERE, you had forgotten 
what you struggled with on your first day(s).


They have been brought up with enough math that they "understand" that
X = 3
means that X has a value of 3.
But why not 3 = X ?

As Chuck said, it is the fundamental difference between equality 
(property) and assignment (operation).


To a programming language, 3 = X is a request to take the current value of 
X, and assign that as the NEW value of the "constant" 3.  And the compiler 
won't cooperate!


Early versions of BASIC had a keyword "LET".LET X = 3   is devoid of 
most of the ambiguity, and LET 3 = X is much less likely to be attempted. 
'Course, changing the values of constants opens up some strange 
possibilities!
A few other languages have used other different symbols for assignment, to 
avoid the confusion of "equality"



Without OTHER changes in parsing arithmetic expressions, that may or may 
not be warranted, just replacing the '=' being used for assignment with an 
arrow ELIMINATED that particular confusion.  Well, mostly.  You can't use 
a right pointing arrow to fix 3 = X



I spent years introducing students to their first contact with computers.

MY first was FORTRAN.  My father handled the statistics for the "CBS 
National Driver's Test".  IBM provided the computers, the port-a-punch 
cards for mail-in responses (printed with a box for where to put a 
stamp!), and the programming.  One of the early percentages in the LIVE 
show didn't add up to 100!  If you look over Walter Cronkite's shoulder, 
you can see my father frantically manually recalculating the numbers. 
The next morning, my father had the dining room table covered with 
manuals, and we started to try to learn FORTRAN.  IIRC, over a short time, 
we settled on the books by McCracken and Decima Anderson.



BTW, I consider BASIC to be very good for "FIRST EXPOSURE", IFF it is 
limited to that, and other languages are soon introduced.

I don't agree with Dijkstra:
"It is practically impossible to teach good programming to students that 
have had a prior exposure to BASIC: as potential programmers they are 
mentally mutilated beyond hope of regeneration."   -Edsger Dijkstra

It takes a substantial OVER-exposure to cause the damage.


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: APL\360

[Fred Cisin via cctalk]

We don't need another BIG-endian/little-endian debate!
(when a 16 bit number is stored in bytes, does the high order byte come 
first, or the low order byte?)  (cf. intel V Motorola)


On Fri, 29 Jan 2021, Nemo Nusquam via cctalk wrote:

Amen to that (but did it not originate with DEC vs. IBM?)


Yes.  I was talking about more recent.  I don't know what other 
predecessors there were befor DEC V IBM.

Re: APL\360

[ben via cctalk]

On 1/29/2021 12:59 PM, Fred Cisin via cctalk wrote:



Without OTHER changes in parsing arithmetic expressions, that may or may 
not be warranted, just replacing the '=' being used for assignment with 
an arrow ELIMINATED that particular confusion.  Well, mostly.  You can't 
use a right pointing arrow to fix 3 = X




Blame K&R with C with the '=' and '==' mess because assignment is a 
operation. I never hear that C or PASCAL have problems.


I find the pseudo code often less confusing than real languages.
the one I like best uses indentation for structure.

while k do
.if foo then
..do this thing
..do that thing
.else
..something here
.!end if
! end while



--
Grumpy Ol' Fred ci...@xenosoft.com

Re: APL\360

[Guy Sotomayor via cctalk]

On 1/29/21 12:21 PM, ben via cctalk wrote:

On 1/29/2021 12:59 PM, Fred Cisin via cctalk wrote:



Without OTHER changes in parsing arithmetic expressions, that may or 
may not be warranted, just replacing the '=' being used for 
assignment with an arrow ELIMINATED that particular confusion.  Well, 
mostly.  You can't use a right pointing arrow to fix 3 = X




Blame K&R with C with the '=' and '==' mess because assignment is a 
operation. I never hear that C or PASCAL have problems.


We complained bitterly about this in the early days (Unix v6 days).  
They at least listened and fixed the = (e.g. =+, =-) because of 
ambiguity but refused to change assignment.  I find it annoying that a 
type-o of forgetting an '=' in a comparison can result in a hard to find 
bug.



TTFN - Guy

Re: APL\360

[Fred Cisin via cctalk]

Without OTHER changes in parsing arithmetic expressions, that may or may 
not be warranted, just replacing the '=' being used for assignment with an 
arrow ELIMINATED that particular confusion.  Well, mostly.  You can't use 
a right pointing arrow to fix 3 = X


On Fri, 29 Jan 2021, ben via cctalk wrote:
Blame K&R with C with the '=' and '==' mess because assignment is a 
operation. I never hear that C or PASCAL have problems.


I think that it was Ritchie and Thompson who created C;
Kernighan and Ritchie documented it.

'=' and '==' makes possible what is probably the most common error, and 
which the compiler doesn't catch:

if (x = 3) . . .   /* sets x to 3 and gives TRUE for the condition */
I imagine that there are probably some pre-processors that would return a 
WARNING for it.



I find the pseudo code often less confusing than real languages.
the one I like best uses indentation for structure.
while k do
.if foo then
..do this thing
..do that thing
.else
..something here
.!end if
! end while

You COULD design a language around your favorite pseudo-code structures.


I like indentation, and demanded it from my students.
while (k)
{   if (foo)
{  ..do this thing
   ..do that thing
}
else
{  ..something here
}
}

Even K and R did not agree on indentation styles.


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: APL\360

[Chuck Guzis via cctalk]

On 1/29/21 11:59 AM, Fred Cisin via cctalk wrote:

> Early versions of BASIC had a keyword "LET".    LET X = 3   is devoid of
> most of the ambiguity, and LET 3 = X is much less likely to be
> attempted. 'Course, changing the values of constants opens up some
> strange possibilities!

SUBROUTINE FOO(X)
INTEGER X
X=15
RETURN
END
...
CALL FOO(10)

Lots of fun, there.

--Chuck

Re: APL\360

[Will Cooke via cctalk]

> On 01/29/2021 2:58 PM Fred Cisin via cctalk  wrote:
> 

> '=' and '==' makes possible what is probably the most common error, and
> which the compiler doesn't catch:
> if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */
> I imagine that there are probably some pre-processors that would return a
> WARNING for it.
> 

Modern Visual Studio and GCC both flag the "=" in a condition, I believe.  But 
if you're shipping code with 260+ warnings, who would see one more.  

There's a pretty good chance the heat pump you're using right now has those 
warnings.  Alas...

Will

Re: APL\360

[Chuck Guzis via cctalk]

On 1/29/21 11:40 AM, Nemo Nusquam via cctalk wrote:
> On 29/01/2021 14:20, Fred Cisin via cctalk wrote:
>> We don't need another BIG-endian/little-endian debate!
>> (when a 16 bit number is stored in bytes, does the high order byte
>> come first, or the low order byte?)  (cf. intel V Motorola)
> Amen to that (but did it not originate with DEC vs. IBM?)
> 
> N.

It was the result of sub-word addressable architecures.

Most old (pre S/360) digit/character-addressable architectures were
big-endian (i.e. higher-order characters occupied lower addresses)

Even PDP-11 isn't strictly little-endian, though Intel X86 definitely is.

Numbering of bits in a word is also interesting.  Is the high order bit
in a 64 bit word, bit 0 or bit 63?  Both conventions have been employed.

This really gets interesting on bit-addressable architectures.  STAR for
example, is bit addressable, but big-endian, with alignment of data
dependent on the data type (e.g. bytes must have the lower 3 bits of
their address as 000; halfwords as 0 and so on.  However, it's
possible to extract any group of bits from a bit-addressed datum.

--Chuck


--Chuck

Re: APL\360

[Fred Cisin via cctalk]

Early versions of BASIC had a keyword "LET".    LET X = 3   is devoid of
most of the ambiguity, and LET 3 = X is much less likely to be
attempted. 'Course, changing the values of constants opens up some
strange possibilities!


On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote:

SUBROUTINE FOO(X)
INTEGER X
X=15
RETURN
END
...
CALL FOO(10)

Lots of fun, there.


I said that LET made redefining constants LESS likely, just because it 
clarifies that it is an assignment to be done.  There are other ways.

Redefining constants permits fixing a number of things,
such as 42
WHATDOYOUGETWHENYOUMULTIPLYSIXBYNINE

Re: APL\360

[Chuck Guzis via cctalk]

On 1/29/21 12:58 PM, Fred Cisin via cctalk wrote:
>>> Without OTHER changes in parsing arithmetic expressions, that may or

> I like indentation, and demanded it from my students.
> while (k)
> {   if (foo)
>     {  ..do this thing
>    ..do that thing
>     }
>     else
>     {  ..something here
>     }
> }
> 

That's fine, but when you have a language that makes indentation part of
the language (i.e. no braces, brackets or keywords denoting boundaries
of the block) , there be monsters.

And yes, there are such languages.

--Chuck

Re: APL\360

[Nemo Nusquam via cctalk]

On 01/29/21 15:58, Fred Cisin via cctalk wrote (in part):
'=' and '==' makes possible what is probably the most common error, 
and which the compiler doesn't catch:

if (x = 3) . . .   /* sets x to 3 and gives TRUE for the condition */
I imagine that there are probably some pre-processors that would 
return a WARNING for it.


Henry's first commandment: Thou shalt run lint frequently and study its 
pronouncements with care, for verily its perception and judgement oft 
exceed thine.


N.

Re: APL\360

[Fred Cisin via cctalk]

'=' and '==' makes possible what is probably the most common error, and
which the compiler doesn't catch:
if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */
I imagine that there are probably some pre-processors that would return a
WARNING for it.


On Fri, 29 Jan 2021, wrco...@wrcooke.net wrote:
Modern Visual Studio and GCC both flag the "=" in a condition, I 
believe.  But if you're shipping code with 260+ warnings, who would see 
one more.


Yet, '=' in a condition is not necessarily a fault.
while (*T++ = *S++); /* is the guts of strcpy  */

But, it can certainly still blow up in your face.
If you want to insert a character at the beginning of a string pointed 
to by P1,

P2 = P1 + 1;
strcpy(P2,P1);/* What went wrong? :-) */


For beginners, it would be nice to use a "SANDBOX" C with runtime error 
checking.  such that

Z = X / Y ;
would do aif (Y == 0) . . .
  Z = X / Y ;
But, that would slow down stuff in the situations where it isn't needed.
Y = 2;
if (condition) Y = 3;
Z = X / Y ; 
does NOT need that runtime error check.


An assumption in C (whether or not it is a valid assumption) is that the 
programmer KNOWS where and what runtime checking is needed, and will 
manually add it in where needed.   The problem, of course, is that they 
DON'T.




There's a pretty good chance the heat pump you're using right now has 
those warnings.  Alas...


In some cases, it is possible to put in preprocessor directives to alert 
the compiler that you are aware of it, and to NOT generate the WARNING.
Or, in many cases to modify the code, such as EXPLICIT typedefs to not 
generate warnings.

int X = PI;   /* should give a warning */
int x = (int)PI; /* should be OK, without a loss of efficiency */


It's scary that code gets shipped as soon as it "seems to be working", 
without confirming that ALL of the 260+ WARNINGS are deliberately 
over-ridden.

Re: APL\360

[David Barto via cctalk]

> On Jan 29, 2021, at 2:08 PM, Fred Cisin via cctalk  
> wrote:
> 
> On Fri, 29 Jan 2021, wrco...@wrcooke.net wrote:
>> Modern Visual Studio and GCC both flag the "=" in a condition, I believe.  
>> But if you're shipping code with 260+ warnings, who would see one more.
> 
> In some cases, it is possible to put in preprocessor directives to alert the 
> compiler that you are aware of it, and to NOT generate the WARNING.
> Or, in many cases to modify the code, such as EXPLICIT typedefs to not 
> generate warnings.
> int X = PI;   /* should give a warning */
> int x = (int)PI; /* should be OK, without a loss of efficiency */
> 
> 
> It's scary that code gets shipped as soon as it "seems to be working", 
> without confirming that ALL of the 260+ WARNINGS are deliberately over-ridden.
> 

Whenever I start a new job the first thing I do today is enable -Werror; all 
warnings are errors. And I’ll fix every one. Even when everyone claims that 
“These are not a problem”. Before that existed, I’d do the same with lint, and 
FlexeLint when I could get it.

And in every case, every single time I did this, for some reason the various 
“mysterious crash” problems would go away. Every time. But it couldn’t be those 
warnings, they weren’t the problem.

David

Re: APL\360

[Will Cooke via cctalk]

> On 01/29/2021 4:42 PM David Barto via cctalk  wrote:
> 

> Whenever I start a new job the first thing I do today is enable -Werror; all 
> warnings are errors. And I’ll fix every one. Even when everyone claims that 
> “These are not a problem”. Before that existed, I’d do the same with lint, 
> and FlexeLint when I could get it.

That's exactly what I did.  I was promptly told I was likely to get fired for 
it.  I left there very soon after.  They are most likely still shipping units, 
but now it probably has more warnings.  Sad.

Will


"A person who never made a mistake never tried anything new." -- Albert Einstein

Re: APL\360

[Sean Conner via cctalk]

It was thus said that the Great Will Cooke via cctalk once stated:
> 
> > On 01/29/2021 4:42 PM David Barto via cctalk  wrote:
> 
> > Whenever I start a new job the first thing I do today is enable -Werror;
> > all warnings are errors. And I’ll fix every one. Even when everyone
> > claims that “These are not a problem”. Before that existed, I’d do the
> > same with lint, and FlexeLint when I could get it.
> 
> That's exactly what I did.  I was promptly told I was likely to get fired
> for it.  

  WHY?  Why would you get fired for fixing warnings?  Would it make some
manager upstream look bad or something?  

  -spc

Re: APL\360

[Will Cooke via cctalk]

> On 01/29/2021 5:08 PM Sean Conner via cctalk  wrote:
> 
> > 
> WHY? Why would you get fired for fixing warnings? Would it make some
> manager upstream look bad or something?
> 
> -spc
Because the code was so fragile and "worked" that making the code "correct" was 
likely to break it.

"A person who never made a mistake never tried anything new." -- Albert Einstein

Re: APL\360

[Norman Jaffe via cctalk]

It happened to me as well - I found hundreds of warnings in the code and, after 
getting permission to address them, I was fired because 'we would have to 
recompile the Windows version due to the changes you made'; the source code was 
reverted to the state before I made the changes. 
I refuse to have their product on any system that I have involvement with... 

From: "cctalk"  
To: "cctalk"  
Sent: Friday, January 29, 2021 3:08:28 PM 
Subject: Re: APL\360 

It was thus said that the Great Will Cooke via cctalk once stated: 
> 
> > On 01/29/2021 4:42 PM David Barto via cctalk  wrote: 
> 
> > Whenever I start a new job the first thing I do today is enable -Werror; 
> > all warnings are errors. And I’ll fix every one. Even when everyone 
> > claims that “These are not a problem”. Before that existed, I’d do the 
> > same with lint, and FlexeLint when I could get it. 
> 
> That's exactly what I did. I was promptly told I was likely to get fired 
> for it. 

WHY? Why would you get fired for fixing warnings? Would it make some 
manager upstream look bad or something? 

-spc 

Re: APL\360

[ben via cctalk]

On 1/29/2021 1:58 PM, Fred Cisin wrote:


You COULD design a language around your favorite pseudo-code structures



I did that already, since I can not find a easy to port C compiler
with structures, and a small memory footprint like 64Kb. I found LCC 3.x 
off a old CD rom archive, but I can't find the book at

a low cost.

 Since the Architecture is still in flux, the compiler is rather rough.
The C code for cross compiler is a simple subset with no structures 
making it easy to port when the time. comes to able to self host.


I got rid most of all the annoying ;'s ,'s }'s {'s
unary operands are a hack at the movement.

control is just
IF cond statements { EIF exp statements }* { ELSE statements } ENDIF
WHILE cond statements REPEAT




I like indentation, and demanded it from my students.
while (k)
{   if (foo)
     {  ..do this thing
    ..do that thing
     }
     else
     {  ..something here
     }
}

Even K and R did not agree on indentation styles.


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: APL\360

[Fred Cisin via cctalk]

Whenever I start a new job the first thing I do today is enable
-Werror; all warnings are errors. And I’ll fix every one. Even
when everyone claims that “These are not a problem”. Before
that existed, I’d do the same with lint, and FlexeLint when I
could get it.


On Fri, 29 Jan 2021, wrco...@wrcooke.net wrote:

That's exactly what I did and was then told I was likely to get fired for
it.  I left that job soon after.
"A person who never made a mistake never tried anything new." -- Albert
Einstein



Similarly, "You don't have time to write comments as you go along.  You 
can go back and add them in AFTER the program is working."  Of course, as 
soon as it "seems to be working", "We're not paying you to mess with stuff 
that's already DONE.  We have ANOTHER project that you have to get on 
immediately."


It's not good to be in a job where they won't let you be thorough in error 
checking nor let you write comments.



And, of course, "Don't waste space with more than two decimal digits for 
year.  NOTHING that we are doing now will still be in use 30 years from 
now."



One of the tasks that I was assigned (working for a contractor at GSFC) 
was to work on converting a wall of punch-card subroutines for plotting on 
Calcomp plotters that needed to be changed to work on Stromberg-Carlson 
(later Stromberg Datagraphics).  It was budgeted for a LONG project to 
rewrite all of them.  I realized that all of the subroutines for Calcomp 
called lower and lower level routines, on down to a small number of 
primitives.  It was easy to write primitives for those lowest level ones, 
that worked on the SC/SD.  I got some help with the JCL to link my 
primitives to the routines for the Calcomps.  All of the routines for 
Calcomp worked fine calling their lower level routines, and ultimately 
calling MY primitives.  The company got a small bonus for getting it all 
done way sooner than planned, and I got a private major reprimand for 
getting it all done way sooner than it was budgeted for.  Many others 
earned bonuses for the company.  The company distributed the bonuses as 
BIG bonuses to upper executives (I think that the top guy got a car), and 
gave each of us a gift certificate/coupon for a turkey.

Re: APL\360

[Chuck Guzis via cctalk]

In the past (and occasionally today, I use the following construct:

FILE *myfile;

if ( !(myfile = fopen( filename, "r"))
{
  fprintf( stderr, "Couldn\'t open %s - exiting\n", filename);
  exit (1);
}

Yes, it only saves a line, but neatly describes what's being done.

--Chuck

Re: APL\360

[Fred Cisin via cctalk]

On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote:


In the past (and occasionally today, I use the following construct:

FILE *myfile;

if ( !(myfile = fopen( filename, "r"))
{
 fprintf( stderr, "Couldn\'t open %s - exiting\n", filename);
 exit (1);
}

Yes, it only saves a line, but neatly describes what's being done.

--Chuck


Yes.
That is another excellent example of where you DO want to do an assignment 
AND a comparison (to zero).  A better example than my strcpy one, although 
yours does not need to save that extra line, but a string copy can't 
afford to be slowed down even a little.


That is why it MUST be a WARNING, not an ERROR.
Of course, the error is when that wasn't what you intended to do.

Re: APL\360

[Guy Sotomayor via cctalk]

In a lot of industry standard coding practices (MISRA, CERT-C) that type 
of statement is prohibited and *will* result in an error being reported 
by the checker/scanner.


The if statement in your example has at least 2 errors from MISRA's 
perspective:


 * assignment within a conditional statement
 * the conditional not being a boolean type (that is you can't assume 0
   is false and non-0 is true...you actually need to compare...in this
   case against NULL)


On 1/29/21 3:59 PM, Fred Cisin via cctalk wrote:

On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote:


In the past (and occasionally today, I use the following construct:

FILE *myfile;

if ( !(myfile = fopen( filename, "r"))
{
 fprintf( stderr, "Couldn\'t open %s - exiting\n", filename);
 exit (1);
}

Yes, it only saves a line, but neatly describes what's being done.

--Chuck


Yes.
That is another excellent example of where you DO want to do an 
assignment AND a comparison (to zero).  A better example than my 
strcpy one, although yours does not need to save that extra line, but 
a string copy can't afford to be slowed down even a little.


That is why it MUST be a WARNING, not an ERROR.
Of course, the error is when that wasn't what you intended to do.


--
TTFN - Guy

Re: APL\360

[Antonio Carlini via cctalk]

On 30/01/2021 00:13, Guy Sotomayor via cctalk wrote:
In a lot of industry standard coding practices (MISRA, CERT-C) that 
type of statement is prohibited and *will* result in an error being 
reported by the checker/scanner.


The if statement in your example has at least 2 errors from MISRA's 
perspective:


 * assignment within a conditional statement
 * the conditional not being a boolean type (that is you can't assume 0
   is false and non-0 is true...you actually need to compare...in this
   case against NULL)


On 1/29/21 3:59 PM, Fred Cisin via cctalk wrote:

On Fri, 29 Jan 2021, Chuck Guzis via cctalk wrote:


In the past (and occasionally today, I use the following construct:

FILE *myfile;

if ( !(myfile = fopen( filename, "r"))
{
 fprintf( stderr, "Couldn\'t open %s - exiting\n", filename);
 exit (1);
}

Yes, it only saves a line, but neatly describes what's being done.

--Chuck


Yes.
That is another excellent example of where you DO want to do an 
assignment AND a comparison (to zero).  A better example than my 
strcpy one, although yours does not need to save that extra line, but 
a string copy can't afford to be slowed down even a little.


That is why it MUST be a WARNING, not an ERROR.
Of course, the error is when that wasn't what you intended to do.



I'm pretty sure that while modern compilers will correctly complain 
about an assignment in a conditional, they also recognise the idiom and 
don't warn when the extra set of brackets is present. So when you really 
do want an assignment and a conditional all in one go, you use the extra 
set of brackets and everyone (you, the compiler, future you) know that 
you really meant it.



Antonio


--
Antonio Carlini
anto...@acarlini.com

Re: APL\360

[Fred Cisin via cctalk]

if ( !(myfile = fopen( filename, "r"))


On Fri, 29 Jan 2021, Guy Sotomayor via cctalk wrote:
In a lot of industry standard coding practices (MISRA, CERT-C) that type of 
statement is prohibited and *will* result in an error being reported by the 
checker/scanner.
The if statement in your example has at least 2 errors from MISRA's 
perspective:

* assignment within a conditional statement
* the conditional not being a boolean type (that is you can't assume 0
  is false and non-0 is true...you actually need to compare...in this
  case against NULL)


That particular structure has become an industry standard.
MOST dialects of C return a NULL pointer on fopen error.
Similarly the code in strcpy has an assignment and is using the numeric 
valus of each character as if it were boolean, with the terminating NULL 
ending the while condition.


There are some situations where some code might not be obvious to all, in 
which case good comments provide the explanation.
For example, when I use DAA or AAM, etc. in X86 assembly language, I 
always comment heavily since my uses for breaking up and/or printing 
numbers are not the original intent for those instructions.

Re: APL\360

[dwight via cctalk]

My problem with words such as DAA is that I constantly have to look them up to 
see exactly what they actually do. Finding alternate uses it all about knowing 
what they actually do. I know what they were put there for ( to keep banker 
happy ).
I constantly see people claiming how much better decimal is than the English 
system of meassurment. I don't really think that much of the decimal number 
system. If we'd only been born with 8 fingers on each hand, computers would 
have been so much easier. Thing like powers of 2 are easier to understand in 
binary.
Such is life. If only we'd known.
Dwight



From: cctalk  on behalf of Fred Cisin via cctalk 

Sent: Friday, January 29, 2021 4:32 PM
To: General Discussion: On-Topic and Off-Topic Posts 
Subject: Re: APL\360

>>> if ( !(myfile = fopen( filename, "r"))

On Fri, 29 Jan 2021, Guy Sotomayor via cctalk wrote:
> In a lot of industry standard coding practices (MISRA, CERT-C) that type of
> statement is prohibited and *will* result in an error being reported by the
> checker/scanner.
> The if statement in your example has at least 2 errors from MISRA's
> perspective:
> * assignment within a conditional statement
> * the conditional not being a boolean type (that is you can't assume 0
>   is false and non-0 is true...you actually need to compare...in this
>   case against NULL)

That particular structure has become an industry standard.
MOST dialects of C return a NULL pointer on fopen error.
Similarly the code in strcpy has an assignment and is using the numeric
valus of each character as if it were boolean, with the terminating NULL
ending the while condition.

There are some situations where some code might not be obvious to all, in
which case good comments provide the explanation.
For example, when I use DAA or AAM, etc. in X86 assembly language, I
always comment heavily since my uses for breaking up and/or printing
numbers are not the original intent for those instructions.

Re: APL\360

[Chuck Guzis via cctalk]

On 1/29/21 5:55 PM, dwight via cctalk wrote:
> My problem with words such as DAA is that I constantly have to look them up 
> to see exactly what they actually do. Finding alternate uses it all about 
> knowing what they actually do. I know what they were put there for ( to keep 
> banker happy ).
> I constantly see people claiming how much better decimal is than the English 
> system of meassurment. I don't really think that much of the decimal number 
> system. If we'd only been born with 8 fingers on each hand, computers would 
> have been so much easier. Thing like powers of 2 are easier to understand in 
> binary.
> Such is life. If only we'd known.
> Dwight

Such as 24 hours in a day, 60 minutes in an hour, and 50 seconds in a
minute?

Although decimal time has been proposed numerous times, somehow we can't
shake our Babylonian roots, even if we don't have 60 fingers.

--Chuck

Re: APL\360

[dwight via cctalk]

If we'd thought about it we could count to 1023 on our fingers.
Dwight



From: cctalk  on behalf of Chuck Guzis via 
cctalk 
Sent: Friday, January 29, 2021 6:19 PM
To: dwight via cctalk 
Subject: Re: APL\360

On 1/29/21 5:55 PM, dwight via cctalk wrote:
> My problem with words such as DAA is that I constantly have to look them up 
> to see exactly what they actually do. Finding alternate uses it all about 
> knowing what they actually do. I know what they were put there for ( to keep 
> banker happy ).
> I constantly see people claiming how much better decimal is than the English 
> system of meassurment. I don't really think that much of the decimal number 
> system. If we'd only been born with 8 fingers on each hand, computers would 
> have been so much easier. Thing like powers of 2 are easier to understand in 
> binary.
> Such is life. If only we'd known.
> Dwight

Such as 24 hours in a day, 60 minutes in an hour, and 50 seconds in a
minute?

Although decimal time has been proposed numerous times, somehow we can't
shake our Babylonian roots, even if we don't have 60 fingers.

--Chuck

Re: APL\360

[Chuck Guzis via cctalk]

On 1/29/21 4:13 PM, Guy Sotomayor via cctalk wrote:
> In a lot of industry standard coding practices (MISRA, CERT-C) that type
> of statement is prohibited and *will* result in an error being reported
> by the checker/scanner.
> 
> The if statement in your example has at least 2 errors from MISRA's
> perspective:
> 
>  * assignment within a conditional statement
>  * the conditional not being a boolean type (that is you can't assume 0
>    is false and non-0 is true...you actually need to compare...in this
>    case against NULL)

Or zero; but then many current C (not C++) implementations do not define
an intrinsic boolean type.  When writing using gcc, for example, I have to

#include 

So, that leaves us with the value of NULL:

3.2.2.3 Pointers

An integral constant expression with the value 0, or such an
expression cast to type void * , is called a null pointer constant. If a
null pointer constant is assigned to or compared for equality to a
pointer, the constant is converted to a pointer of that type. Such a
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function.

--Chuck

Re: APL\360

[Fred Cisin via cctalk]

On Sat, 30 Jan 2021, dwight via cctalk wrote:

If we'd thought about it we could count to 1023 on our fingers.


If the more dominant/aggressive of our ancestors had come from warmer 
climates where feet don't stink too much to expose in public, then we 
could have had 20 binary digits.

Re: APL\360

[Will Cooke via cctalk]

> On 01/29/2021 7:55 PM dwight via cctalk  wrote:
> 
> 
> I constantly see people claiming how much better decimal is than the English 
> system of meassurment. I don't really think that much of the decimal number 
> system. If we'd only been born with 8 fingers on each hand, computers would 
> have been so much easier. Thing like powers of 2 are easier to understand in 
> binary.
> Such is life. If only we'd known.
> Dwight
> 

Some knew
https://en.wikipedia.org/wiki/Octal#Usage

Re: APL\360

[Sean Conner via cctalk]

It was thus said that the Great Fred Cisin via cctalk once stated:
> >Whenever I start a new job the first thing I do today is enable
> >-Werror; all warnings are errors. And I’ll fix every one. Even
> >when everyone claims that “These are not a problem”. Before
> >that existed, I’d do the same with lint, and FlexeLint when I
> >could get it.
> 
> On Fri, 29 Jan 2021, wrco...@wrcooke.net wrote:
> >That's exactly what I did and was then told I was likely to get fired for
> >it.  I left that job soon after.
> >"A person who never made a mistake never tried anything new." -- Albert
> >Einstein
> 
> 
> Similarly, "You don't have time to write comments as you go along.  You 
> can go back and add them in AFTER the program is working."  Of course, as 
> soon as it "seems to be working", "We're not paying you to mess with stuff 
> that's already DONE.  We have ANOTHER project that you have to get on 
> immediately."
> 
> It's not good to be in a job where they won't let you be thorough in error 
> checking nor let you write comments.

  I had a manager that told me not to be so pedantic about verifying the
incoming SIP messages because otherwise we (the Company) were going to go
out of business in six months if we didn't get the product OUT THE DOOR!

  I compromised on it---I didn't remove the checks, but for those that
didn't matter to our processing the message, I just logged the violation and
continued processing.  No one in the department was familiar with SIP at the
time so I figured tha was at least help us debug any issues.

  Of course, said manager left six months later because of burnout [1], and
two, I'm still at the same job five years later.

  -spc

[1] He was originally a developer who was forced into a management role,
something he was *very bad at*, and he still did development work,
not fully trusting anyone underneath him (nor operations, but that's
a whole other story).

Re: APL\360

[Sean Conner via cctalk]

It was thus said that the Great Norman Jaffe via cctalk once stated:
> 
> It happened to me as well - I found hundreds of warnings in the code and,
> after getting permission to address them, I was fired 

  Wait ... you got *permission* and were still *fired*?  Have I just been
fortunate in where I've worked my entire career? [1]

> because 'we would
> have to recompile the Windows version due to the changes you made'; the
> source code was reverted to the state before I made the changes.  

  Wouldn't you have to recompile the Windows version for updates?  Or was
the company too cheap (or was unable to) run regression tests?

> I refuse
> to have their product on any system that I have involvement with...

  Can you name names?  Or do you need to protect yourself?

  -spc

[1] Possibly yes.  

Re: APL\360

[Guy Sotomayor via cctalk]

On 1/29/21 4:32 PM, Fred Cisin via cctalk wrote:

if ( !(myfile = fopen( filename, "r"))


On Fri, 29 Jan 2021, Guy Sotomayor via cctalk wrote:
In a lot of industry standard coding practices (MISRA, CERT-C) that 
type of statement is prohibited and *will* result in an error being 
reported by the checker/scanner.
The if statement in your example has at least 2 errors from MISRA's 
perspective:

* assignment within a conditional statement
* the conditional not being a boolean type (that is you can't assume 0
  is false and non-0 is true...you actually need to compare...in this
  case against NULL)


That particular structure has become an industry standard.
MOST dialects of C return a NULL pointer on fopen error.
Similarly the code in strcpy has an assignment and is using the 
numeric valus of each character as if it were boolean, with the 
terminating NULL ending the while condition.



And unfortunately some industries it is prohibited.  Those industries 
*require* conformance to MISRA, CERT-C, ISO-26262 and others.  There is 
*no* choice since the code has to be audited and compliance is *not* 
optional.



--
TTFN - Guy

Re: APL\360

[Norman Jaffe via cctalk]

I was responsible for the Macintosh version and hence was both permitted to 
address the changes and criticized for impacting the Windows builds - the 
changes were in shared code. 
I would probably face legal issues if I named names. 
[You can always look me up in LinkedIn and, with minor detective skills, guess 
which product...] 

From: "cctalk"  
To: "cctalk"  
Sent: Friday, January 29, 2021 6:57:28 PM 
Subject: Re: APL\360 

It was thus said that the Great Norman Jaffe via cctalk once stated: 
> 
> It happened to me as well - I found hundreds of warnings in the code and, 
> after getting permission to address them, I was fired 

Wait ... you got *permission* and were still *fired*? Have I just been 
fortunate in where I've worked my entire career? [1] 

> because 'we would 
> have to recompile the Windows version due to the changes you made'; the 
> source code was reverted to the state before I made the changes. 

Wouldn't you have to recompile the Windows version for updates? Or was 
the company too cheap (or was unable to) run regression tests? 

> I refuse 
> to have their product on any system that I have involvement with... 

Can you name names? Or do you need to protect yourself? 

-spc 

[1] Possibly yes. 

Re: APL\360

[Tapley, Mark B. via cctalk]

> On Jan 29, 2021, at 8:27 PM, dwight via cctalk  wrote:
> 
> [EXTERNAL EMAIL]
> 
> If we'd thought about it we could count to 1023 on our fingers.
> Dwight

My kids actually do that (because I did think about it when they were growing 
up). And not just to impress me, I was watching the elder daughter in an 
orchestra concert via streaming cam one time. The camera happened to catch her 
during a really long rest, and I could see her hand resting on her knee, 
counting out measures in binary.

As far as I know, none of the kids have learned to control their toes 
individually, so they can’t actually count up to 1,048,575 :-).
- Mark

Re: APL\360

[Bill Gunshannon via cctalk]

On 1/29/21 2:20 PM, Fred Cisin via cctalk wrote:

On Fri, 29 Jan 2021, Paul Koning via cctalk wrote:
BTW, I don't really know Hebrew but doesn't it still write math LTR?  
I know they write numbers that way.


CAREFUL.

We don't need another BIG-endian/little-endian debate!
(when a 16 bit number is stored in bytes, does the high order byte come 
first, or the low order byte?)  (cf. intel V Motorola)


Yes, it does.  :-)

bill

Re: APL\360

[Bill Gunshannon via cctalk]

On 1/29/21 4:12 PM, Will Cooke via cctalk wrote:



On 01/29/2021 2:58 PM Fred Cisin via cctalk  wrote:




'=' and '==' makes possible what is probably the most common error, and
which the compiler doesn't catch:
if (x = 3) . . . /* sets x to 3 and gives TRUE for the condition */
I imagine that there are probably some pre-processors that would return a
WARNING for it.



Modern Visual Studio and GCC both flag the "=" in a condition, I believe.  But 
if you're shipping code with 260+ warnings, who would see one more.


And the problem here is really quite plain and simple.
Why are you shipping code with any warnings?



There's a pretty good chance the heat pump you're using right now has those 
warnings.  Alas...


Just because some other programmer is an idiot doesn't mean I have
to be.

bill

Re: APL\360

[Bill Gunshannon via cctalk]

On 1/29/21 4:25 PM, Nemo Nusquam via cctalk wrote:

On 01/29/21 15:58, Fred Cisin via cctalk wrote (in part):
'=' and '==' makes possible what is probably the most common error, 
and which the compiler doesn't catch:

if (x = 3) . . .   /* sets x to 3 and gives TRUE for the condition */
I imagine that there are probably some pre-processors that would 
return a WARNING for it.


Henry's first commandment: Thou shalt run lint frequently and study its 
pronouncements with care, for verily its perception and judgement oft 
exceed thine.


N.



Which Henry was that?  Henry Spencer perhaps?

bill

Re: APL\360

[Will Cooke via cctalk]

> On 01/30/2021 11:42 AM Bill Gunshannon via cctalk  
> wrote:

> > Modern Visual Studio and GCC both flag the "=" in a condition, I believe. 
> > But if you're shipping code with 260+ warnings, who would see one more.
> And the problem here is really quite plain and simple.
> Why are you shipping code with any warnings?
> 
The short answer, as I replied earlier, is that they deemed the code too 
fragile to touch.  When I told them I removed the warnings they said to put 
them back or I would likely be fired.

> > There's a pretty good chance the heat pump you're using right now has those 
> > warnings. Alas...
> Just because some other programmer is an idiot doesn't mean I have
> to be.

They only wanted idiots.  So I immediately started looking for another job.  I 
might be an idiot, but I don't want to be associated with the rest of them :-)

Will



"A person who never made a mistake never tried anything new." -- Albert Einstein

Re: APL\360

[Bill Gunshannon via cctalk]

On 1/29/21 6:08 PM, Sean Conner via cctalk wrote:

It was thus said that the Great Will Cooke via cctalk once stated:



On 01/29/2021 4:42 PM David Barto via cctalk  wrote:



Whenever I start a new job the first thing I do today is enable -Werror;
all warnings are errors. And I’ll fix every one. Even when everyone
claims that “These are not a problem”. Before that existed, I’d do the
same with lint, and FlexeLint when I could get it.


That's exactly what I did.  I was promptly told I was likely to get fired
for it.


   WHY?  Why would you get fired for fixing warnings?  Would it make some
manager upstream look bad or something?


They would see you as wasting valuable time fixing non-problems.
I would not work in a place like that.  Worse sti8ll is when you
work in a place point out logic errors that result in bad answers
that, obviously, don't get flagged by the compiler and nobody wants
to hear it.

bill

Re: APL\360

[Chuck Guzis via cctalk]

On 1/29/21 10:03 PM, Guy Sotomayor via cctalk wrote:

> 
> And unfortunately some industries it is prohibited.  Those industries
> *require* conformance to MISRA, CERT-C, ISO-26262 and others.  There is
> *no* choice since the code has to be audited and compliance is *not*
> optional.

Just an illustration of what happens when you take a "portable
alternative to assembly" and put lipstick on it.   I've been programming
C since System III Unix and I still consider it to be a portable (sort
of) alternative to assembly.

One of the problems with C, in my view, is a lack of direction.  There
are plenty of languages that aim for specific ends.  (e.g. COBOL =
business/commercial, FORTRAN = scientific, Java = web applications,
etc.).   But whence C or C++?

In my dotage, I do a fair amount of MCU programming nowadays, and C is
the lingua franca in that world; the only real alternative is assembly,
so that makes some sense.  Python, Ada, etc. never really managed to
make much headway there.  C is far more prevalent than C++ in that
world, FWIW.

Does standard C have vector extensions yet?  I was an alternate rep for
my firm for F90 (was supposed to be F88) for vector extensions; it's
just a matter of curiosity.

--Chuck

Re: APL\360

[Bill Gunshannon via cctalk]

On 1/29/21 9:19 PM, Chuck Guzis via cctalk wrote:

On 1/29/21 5:55 PM, dwight via cctalk wrote:

My problem with words such as DAA is that I constantly have to look them up to 
see exactly what they actually do. Finding alternate uses it all about knowing 
what they actually do. I know what they were put there for ( to keep banker 
happy ).
I constantly see people claiming how much better decimal is than the English 
system of meassurment. I don't really think that much of the decimal number 
system. If we'd only been born with 8 fingers on each hand, computers would 
have been so much easier. Thing like powers of 2 are easier to understand in 
binary.
Such is life. If only we'd known.
Dwight


Such as 24 hours in a day, 60 minutes in an hour, and 50 seconds in a
minute?

Although decimal time has been proposed numerous times, somehow we can't
shake our Babylonian roots, even if we don't have 60 fingers.


And what's with these 12 months of different lengths?  :-)

bill