Re: APL\360

2021-02-11 Thread Boris Gimbarzevsky via cctalk
Counting in binary on ones fingers was something I first ran into at age 11 when found a book on Military Electronics in a surplus store. Everything simplified, but in computer section found binary system explained with using fingers to represent bits. That was something that I used

Re: APL\360

2021-02-10 Thread Tom Hunter via cctalk
I too count sheep with my fingers, but I never get past zero due to the lack of sheep.:-) Tom Hunter On Mon, Feb 1, 2021 at 5:34 PM Tor Arntsen via cctalk wrote: > On Sat, 30 Jan 2021 at 03:27, dwight via cctalk > wrote: > > If we'd thought about it we could count to 1023 on our fingers.

Re: APL\360

2021-02-03 Thread Peter Corlett via cctalk
On Tue, Feb 02, 2021 at 08:50:56PM -0700, ben via cctalk wrote: > On 2/1/2021 6:07 AM, Peter Corlett via cctalk wrote: [...] >> You're describing a failing in C and similar languages stuck in the >> 1960s. Here's a Rust method that does add-exposing-carry: >>

Re: APL\360

2021-02-02 Thread ben via cctalk
On 2/1/2021 6:07 AM, Peter Corlett via cctalk wrote: On Wed, Jan 20, 2021 at 02:05:37PM -0700, ben via cctalk wrote: [...] 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

Re: APL\360

2021-02-02 Thread ben via cctalk
On 2/1/2021 12:15 PM, Liam Proven via cctalk wrote: On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk wrote: I had always been told, "A pint is a pound, the world around." Aha! Does that mean a pint of water weighs 1lb? Interesting. I did not know. Who Knows? It just works of beer or

NOT "Re: APL\360"

2021-02-02 Thread Stan Sieler via cctalk
reply with the same "Re:". After 29 "Re: APL\360", the next such msg would have subject line rewritten to "New topic 1", and the next (up to) 28 "Re: APL\360" would be similarly re-written (the '28' is decremented for every "Re: APL\360" and eve

Re: APL\360

2021-02-02 Thread Peter Corlett via cctalk
On Mon, Feb 01, 2021 at 08:15:25PM +0100, Liam Proven via cctalk wrote: > On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk > wrote: >> I had always been told, "A pint is a pound, the world around." "The world" meaning "the USA", of course. > Aha! Does that mean a pint of water weighs 1lb?

Re: APL\360

2021-02-01 Thread Paul Koning via cctalk
> On Feb 1, 2021, at 2:34 PM, Dave Wade G4UGM via cctalk > wrote: > >>> ... >>> I had always been told, "A pint is a pound, the world around." >> >> Aha! Does that mean a pint of water weighs 1lb? >> >> Interesting. I did not know. > > Typical American statement, where "world" means

Re: APL\360

2021-02-01 Thread Paul Koning via cctalk
> On Feb 1, 2021, at 2:13 PM, David Bridgham via cctalk > wrote: > > ... > Sure, one can get into the story that our numbers come from Arabic and > Arabic is written right-to-left so in fact they were originally > little-endian and just didn't get flipped around when incorporated into >

RE: APL\360

2021-02-01 Thread Dave Wade G4UGM via cctalk
> -Original Message- > From: cctalk On Behalf Of Liam Proven via > cctalk > Sent: 01 February 2021 19:15 > To: General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: APL\360 > > On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk > wrote:

Re: APL\360

2021-02-01 Thread David Bridgham via cctalk
On 2/1/21 1:59 PM, John Ames via cctech wrote: > This one has always boggled me, because it's the one aspect of the > Endian Wars where there's a simple, straightforward answer grounded in > basic mathematics - base ^ digit-number only gives the correct > place-value when the lowest-order bit is

Re: APL\360

2021-02-01 Thread John Ames via cctalk
> From: Chuck Guzis > 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 one has always boggled me, because it's the one aspect of the Endian Wars where there's a simple, straightforward answer

Re: APL\360

2021-02-01 Thread Chuck Guzis via cctalk
On 2/1/21 11:00 AM, Fred Cisin via cctalk wrote: >> On 2021-02-01 10:59, Liam Proven via cctalk wrote: >>> I do not know what a fluid ounce is, or how many are in a pint. > On Mon, 1 Feb 2021, emanuel stiebler via cctalk wrote: >> not enough? >> ;-) > > I had always been told, "A pint is a pound,

Re: APL\360

2021-02-01 Thread Liam Proven via cctalk
On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk wrote: > > I had always been told, "A pint is a pound, the world around." Aha! Does that mean a pint of water weighs 1lb? Interesting. I did not know. > I had already assumed that pub prices had inflated to higher than a pound. It was under

Re: APL\360

2021-02-01 Thread dwight via cctalk
, February 1, 2021 7:59 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: APL\360 On Sat, 30 Jan 2021 at 02:56, dwight via cctalk wrote: > I constantly see people claiming how much better decimal is than the English > system of meassurment. Um. I am a native English speaker, a

Re: APL\360

2021-02-01 Thread Fred Cisin via cctalk
On 2021-02-01 10:59, Liam Proven via cctalk wrote: I do not know what a fluid ounce is, or how many are in a pint. On Mon, 1 Feb 2021, emanuel stiebler via cctalk wrote: not enough? ;-) I had always been told, "A pint is a pound, the world around." I had already assumed that pub prices had

Re: APL\360

2021-02-01 Thread Fred Cisin via cctalk
We don't need another big-endian/little-endian battle On Mon, 1 Feb 2021, Peter Corlett via cctalk wrote: Little-endian tends to be more useful when doing multi-word arithmetic. Big-endian is handy for text and human-readable numbers. That there are heated arguments over which endianness is

Re: APL\360

2021-02-01 Thread Fred Cisin via cctalk
On Sat, 30 Jan 2021 at 03:27, dwight via cctalk wrote: If we'd thought about it we could count to 1023 on our fingers. On Mon, 1 Feb 2021, Tor Arntsen via cctalk wrote: Some sheep herders in (IIRC) the Caucasus do, or did at least. I learned about that some decades ago. Counting sheep on

Re: APL\360

2021-02-01 Thread emanuel stiebler via cctalk
On 2021-02-01 11:40, Chuck Guzis via cctalk wrote: > Whose pint? UK Imperial pint = 568 ml. US liquid pint = 473 ml. That explains some conversations I had with people there ;-)

Re: APL\360

2021-02-01 Thread Chuck Guzis via cctalk
On 2/1/21 5:26 AM, Peter Corlett via cctalk wrote: > On every CPU I've used, LSB has always been bit 0. Unlike endianness, this > is clearly better than the other way round since the value is 2**bit_number > and the bit number doesn't change if the value is converted into a different > word

Re: APL\360

2021-02-01 Thread Nigel Johnson via cctalk
It's actually 568.26.  Easy to work out, in Canada the gallon is defined as being 454609 ten millionths of a cubic metre, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 nw.john...@ieee.org On 2021-02-01

Re: APL\360

2021-02-01 Thread Chuck Guzis via cctalk
On 2/1/21 8:10 AM, emanuel stiebler via cctalk wrote: > On 2021-02-01 10:59, Liam Proven via cctalk wrote: >> I do not know what a fluid ounce is, or how many are in a pint. > > not enough? > ;-) > Whose pint? UK Imperial pint = 568 ml. US liquid pint = 473 ml. Both are one-eighth of a

Re: APL\360

2021-02-01 Thread emanuel stiebler via cctalk
On 2021-02-01 10:59, Liam Proven via cctalk wrote: > I do not know what a fluid ounce is, or how many are in a pint. not enough? ;-)

Re: APL\360

2021-02-01 Thread Liam Proven via cctalk
On Sat, 30 Jan 2021 at 02:56, dwight via cctalk wrote: > I constantly see people claiming how much better decimal is than the English > system of meassurment. Um. I am a native English speaker, as well as an English citizen, and I count in decimal. Do you mean metric (SI / Systeme

Re: APL\360

2021-02-01 Thread Liam Proven via cctalk
On Fri, 29 Jan 2021 at 22:14, Fred Cisin via cctalk wrote: > such as 42 > WHATDOYOUGETWHENYOUMULTIPLYSIXBYNINE  -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype:

Re: APL\360

2021-02-01 Thread Peter Corlett via cctalk
On Fri, Jan 29, 2021 at 01:12:55PM -0800, Chuck Guzis via cctalk wrote: [...] > 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. I

Re: APL\360

2021-02-01 Thread Liam Proven via cctalk
On Mon, 1 Feb 2021 at 10:34, Tor Arntsen via cctalk wrote: > > Some sheep herders in (IIRC) the Caucasus do, or did at least. I > learned about that some decades ago. Counting sheep on their fingers. > I use the system sometimes. Fred Pohl's short story "Digits and Dastards" explains it well. I

Re: APL\360

2021-02-01 Thread Peter Corlett via cctalk
On Wed, Jan 20, 2021 at 02:05:37PM -0700, ben via cctalk wrote: [...] > 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

Re: APL\360

2021-02-01 Thread Tor Arntsen via cctalk
On Sat, 30 Jan 2021 at 03:27, dwight via cctalk wrote: > If we'd thought about it we could count to 1023 on our fingers. > Dwight Some sheep herders in (IIRC) the Caucasus do, or did at least. I learned about that some decades ago. Counting sheep on their fingers. I use the system sometimes.

Re: APL\360

2021-01-30 Thread Sean Conner via cctalk
It was thus said that the Great Bill Gunshannon via cctalk once stated: > 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

Re: APL\360

2021-01-30 Thread Bill Gunshannon via cctalk
On 1/30/21 1:57 PM, Nemo Nusquam via cctalk wrote: On 30/01/2021 12:45, Bill Gunshannon via cctalk wrote: 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

Re: APL\360 (Was: cctalk Digest, Vol 76, Issue 29

2021-01-30 Thread Chuck Guzis via cctalk
On 1/30/21 1:38 PM, Fred Cisin via cctalk wrote: > Actually, that was Chuck who said that "there be monsters" when > languages use whitespace rather than punctuation to denote boundaries. And then there's "make", where a hard tab must be used for indentation, unless it's a recipe, then spaces

Re: APL\360

2021-01-30 Thread Guy Sotomayor via cctalk
On 1/30/21 9:52 AM, Chuck Guzis via cctalk wrote: 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

Re: APL\360

2021-01-30 Thread Nemo Nusquam via cctalk
On 30/01/2021 12:45, Bill Gunshannon via cctalk wrote: 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) . . .  /*

Re: APL\360

2021-01-30 Thread Will Cooke via cctalk
> On 01/30/2021 11:50 AM Bill Gunshannon via cctalk > wrote: > > > 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

Re: APL\360

2021-01-30 Thread 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

Re: APL\360

2021-01-30 Thread 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

Re: APL\360

2021-01-30 Thread 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

Re: APL\360

2021-01-30 Thread 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

Re: APL\360

2021-01-30 Thread 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

Re: APL\360

2021-01-30 Thread 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

Re: APL\360

2021-01-30 Thread 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

Re: APL\360

2021-01-30 Thread 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

Re: APL\360

2021-01-30 Thread Norman Jaffe via cctalk
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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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 >

Re: APL\360

2021-01-29 Thread 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

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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: >

Re: APL\360

2021-01-29 Thread 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 ).

Re: APL\360

2021-01-29 Thread dwight via cctalk
. 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 S

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

2021-01-29 Thread 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,

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread Norman Jaffe via cctalk
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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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,

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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,

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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)

Re: APL\360

2021-01-29 Thread 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) >

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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. 

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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?)

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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

Re: APL\360

2021-01-29 Thread 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.

Re: APL\360

2021-01-20 Thread 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

Re: APL\360

2021-01-20 Thread 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

Re: APL\360

2021-01-19 Thread 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.

Re: APL\360

2021-01-19 Thread 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

Re: APL\360

2021-01-15 Thread 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

Re: APL\360

2021-01-15 Thread 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

Re: APL\360

2021-01-15 Thread 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.

Re: APL\360

2021-01-15 Thread 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.

Re: APL\360

2021-01-15 Thread 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

Re: APL\360

2021-01-15 Thread 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

Re: APL\360

2021-01-15 Thread 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

  1   2   >