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" <cctalk at classiccmp.org> To: "cctalk" <cctalk at classiccmp.org> 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 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

On Thu, Jan 14, 2021 at 06:42:34PM -0800, Fred Cisin via cctalk 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. mcl

On 1/14/21 6:42 PM, Fred Cisin 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'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%20… --Chuck

On Thu, Jan 14, 2021 at 07:55:52PM -0800, Fred Cisin via cctalk wrote: 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

On Fri, 15 Jan 2021 at 17:21, Nemo Nusquam via cctalk <cctalk at classiccmp.org> wrote: 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: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053

On 1/14/21 7:55 PM, Fred Cisin wrote: 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

On 1/14/21 10:55 PM, Fred Cisin via cctalk wrote: 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. :-) 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

On 1/15/21 3:11 PM, Chuck Guzis 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. 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

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" <cctalk at classiccmp.org> To: "cctalk" <cctalk at classiccmp.org> 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: 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

On 01/15/2021 07:18 PM, Paul Koning via cctalk wrote: 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

On Thu, Jan 14, 2021 at 07:43:13PM -0800, Chuck Guzis 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. 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. 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. 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.

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

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

On 29/01/2021 14:20, Fred Cisin via cctalk wrote: Amen to that (but did it not originate with DEC vs. IBM?) N.

On 1/29/21 11:40 AM, Nemo Nusquam via cctalk wrote: 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 00000 and so on. However, it's possible to extract any group of bits from a bit-addressed datum. --Chuck --Chuck

On 2/1/21 5:26 AM, Peter Corlett via cctalk wrote: I take it then, that you've never programmed a S/360 CPU? --Chuck

On 1/29/21 2:20 PM, Fred Cisin via cctalk wrote: Yes, it does. :-) bill

On 1/29/2021 12:59 PM, Fred Cisin 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 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

On Fri, 29 Jan 2021, ben via cctalk wrote: 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. 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 cisin at xenosoft.com

On Fri, 29 Jan 2021, wrcooke at wrcooke.net wrote: 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 a if (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. 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.

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

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

It was thus said that the Great Norman Jaffe via cctalk once stated: Wait ... you got *permission* and were still *fired*? Have I just been fortunate in where I've worked my entire career? [1] Wouldn't you have to recompile the Windows version for updates? Or was the company too cheap (or was unable to) run regression tests? Can you name names? Or do you need to protect yourself? -spc [1] Possibly yes.

On 1/29/21 6:08 PM, Sean Conner via cctalk wrote: 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

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

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: -- TTFN - Guy

On Fri, 29 Jan 2021, Guy Sotomayor via cctalk wrote: 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.

On 1/29/21 5:55 PM, dwight via cctalk wrote: 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

On Sat, 30 Jan 2021, dwight via cctalk wrote: 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.

On Sat, 30 Jan 2021 at 03:27, dwight via cctalk <cctalk at classiccmp.org> 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. -Tor

On Mon, 1 Feb 2021, Tor Arntsen via cctalk wrote: counting sheep, . . . My ex asked me whether I was playing piano in my sleep.

On 1/29/21 9:19 PM, Chuck Guzis via cctalk wrote: And what's with these 12 months of different lengths? :-) bill

On Sat, 30 Jan 2021 at 02:56, dwight via cctalk <cctalk at classiccmp.org> wrote: Um. I am a native English speaker, as well as an English citizen, and I count in decimal. Do you mean metric (SI / Systeme Internationale) versus Imperial measurements? If so, I 100% aver that metric is far better. I am 53 years old. I did not learn Imperial at school, in any of the 3 countries where I went to school (UK, Nigeria, Isle of Man.) I know some of the units; I think of a few things, such as human beings, computer screens, and pizzas, in Imperial units. People's height in feet & inches is more meaningful to me than in metres, but I can cope. People's weight in stones. Beer in pints. Speeds in MPH. But that's about all. I have never managed to learn how many ounces in a pound, or pounds in an stone, or stones in a hundredweight. I do not know what a fluid ounce is, or how many are in a pint. I do not know how many yards in a mile. They're all arbitrary numbers and it makes no sense. SI units are 100% easier by any metric. Yes, that is intentional. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053

On 2/1/21 8:10 AM, emanuel stiebler via cctalk wrote: Whose pint? UK Imperial pint = 568 ml. US liquid pint = 473 ml. Both are one-eighth of a gallon, but US and UK gallons differ. Trivia for today. --Chuck

On 2021-02-01 11:40, Chuck Guzis via cctalk wrote: That explains some conversations I had with people there ;-)

On Mon, 1 Feb 2021 at 20:00, Fred Cisin via cctalk <cctalk at classiccmp.org> wrote: Aha! Does that mean a pint of water weighs 1lb? Interesting. I did not know. It was under ?1 for ?litre of beer when I got here. In fact it was under US$1/ US 1pt. Now it's a bit more. Cheapest I had was CzK 17 for half a litre. At the time that was about 50?. It is one of the things I miss most in lockdown. And there's no electricity supply in my man-cave/basement so I can't even go down there and play with my old computers. :-( -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053

That would fit tradition. A lot of the Imperial unit names were at one time also used in the rest of Europe. But their definition varied randomly, often from town to town. I have a book about sailing ships that gives the dimensions in "Amsterdam feet", which by the way have 11 inches per foot, not 12. My father, a metrologist, had a history book discussing the pre-metric systems of units of Europe. The units were often set by the ruler of the day (e.g., the "ell" might match the arm of the prince in charge at that time). Sometimes not, though. The book had a lovely picture showing the way the standard "foot" was estabished in one German principality: officials gathered outside the town church in some town, stopped the first 12 adult males leaving Mass, and had them line up their feet. They captured that measurement, divided by 12, presto, the standard foot. For that place and time, anyway. So don't be surprised that there are lots of pounds, ounces, etc. -- that's just how it's always been done. Much later, there were three different inches: the UK one, the US one, and the Canadian one. At least in theory. In reality they were so close that it's unlikely any instrument could tell the difference. And precision calibration was done with Johansson blocks, which followed the Canadian definition (25.4 mm exactly). paul

On 01/02/2021 20:07, Fred Cisin via cctalk wrote: <grin> That's also a US measure. An imperial fluid ounce is 28.4ml and a floz of water weighs 28.4g, same as an avoirdupois ounce. In fact it's defined (or was) as the volume of water that weighs one ounce. -- Pete Pete Turnbull

On 2/1/21 12:07 PM, Fred Cisin via cctalk wrote: No, as I said, it's that Americans (of the US variety) are authentically English, using the 1588 standard, than their overseas cousins, who use the Imperial 1824 one. Simple, that. Importing the IBM PC 5150 into Europe must have caused a bit of a kerfuffle. All of those SAE fasteners--e.g. 6-32 bolt used extensively. #6 bolt size with 32 threads per inch. It wasn't really until the clone makers got into the picture with their metric hardware. The result is that most recent PCs employ a macaronic assortment of fasteners. Thank heavens that the Brits didn't come out with the 5150--we might have had to deal with Whitworth (BSW) fasteners. --Chuck

On Mon, 1 Feb 2021 at 21:07, Fred Cisin via cctalk <cctalk at classiccmp.org> wrote: Close enough for government work. With all the off-hand mental approximations people use to convert units, including some I think mentioned here, 4% is pretty good. I may use metric when I am measuring things myself, but I got my motorbike licence in 1991 and my car licence in 2005. I was solely taught and tested in MPH. For estimating stopping distances by eye, a metre is a yard, near enough -- and of course "car lengths" and seconds aren't affected. Keep 2 car lengths back under 30mph, and over that, maintain 2 seconds' braking distance, is metric-independent. Wouldn't know. I have never in my life seen such a unit on sale, I think. Indeed so. It does get worse. When I emigrated, I had no problem adapting to buying half litres of beer -- or even, just once in a brewery in Slovakia, a litre of beer. But the strengths...! Czech beer comes in 10?, 11?, or 12?, and very occasionally 13?, 14? or even 17?-18?. I have almost never seen anything stronger. But what the heck is a ten-degree beer?! I'd never heard of degrees in beer before. Degrees proof, yes, but just halve that for %ABV, which is far more meaningful for me. But while a 10? beer being 5% alcohol by volume was just about believable, a 15% ABV beer seems unlikely. Well, it is. The system is "degrees Plato", a system so obscure there isn't even a Wikipedia page for it. And all I knew about Plato's drinking habits was: ? Plato, they say, could stick it away Half a crate of whiskey every day ? It's horribly complicated in use: http://8degreesplato.com/2017/05/31/so-what-is-degrees-plato/ No wonder nobody much outside Central Europe uses it. But this country is the world capital of beer -- they consume more per capita than anyone else. There are good reasons I like it here, and it's not the language. https://news.expats.cz/czech-food-drink/the-czech-republic-leads-all-nation… The USA drinks 12x as much in total -- but has nearly 40x as many people. I believe I have heard that. Maybe this is why it is meaningless to me -- it doesn't work with UK Imperial units, only with American Imperial units. Yet more reason to burn imperial measurements in a fire and throw the ashes in the sea. ;-) Did you know that the Central African Republic covers one of the largest magnetic anomalies in the world? It's so big it's named after the capital of the CAR, which will of course make it trivial for you all to look it up. Very true. British beer is often served with very little foam on top, so the capacity of the glass is measured to the brim. A Czech beer without at least a few centimetres of foam is considered defective and most drinkers would send it back -- so Czech beer glasses are lined instead, to leave plenty of space for the froth on top. Oh gods, me too. Sorry to hear that. Oh my word. My deepest condolences. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053

Sorry about that. I didn't pay close enough attention to my outgoing header.

On 2/1/2021 12:15 PM, Liam Proven via cctalk wrote: Who Knows? It just works of beer or ale. :) Ben.

My point was that the metric system is easier because we chose to use a decimal number system. Things like using fractional measurements as in the Imperial system are actually better for designing with. Fractional numbers work better with things like cross sectional areas and strength. Look at typical metric bolt sizes. I agree things like ounces per pound are broken thinking. Giving up fractional dimensions to make it easer to match our decimal number system is also broken. Dwight ________________________________ From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Liam Proven via cctalk <cctalk at classiccmp.org> Sent: Monday, February 1, 2021 7:59 AM To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Subject: Re: APL\360 On Sat, 30 Jan 2021 at 02:56, dwight via cctalk <cctalk at classiccmp.org> wrote: Um. I am a native English speaker, as well as an English citizen, and I count in decimal. Do you mean metric (SI / Systeme Internationale) versus Imperial measurements? If so, I 100% aver that metric is far better. I am 53 years old. I did not learn Imperial at school, in any of the 3 countries where I went to school (UK, Nigeria, Isle of Man.) I know some of the units; I think of a few things, such as human beings, computer screens, and pizzas, in Imperial units. People's height in feet & inches is more meaningful to me than in metres, but I can cope. People's weight in stones. Beer in pints. Speeds in MPH. But that's about all. I have never managed to learn how many ounces in a pound, or pounds in an stone, or stones in a hundredweight. I do not know what a fluid ounce is, or how many are in a pint. I do not know how many yards in a mile. They're all arbitrary numbers and it makes no sense. SI units are 100% easier by any metric. Yes, that is intentional. -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053

On 1/29/21 10:03 PM, Guy Sotomayor via cctalk wrote: 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

On 1/29/21 4:13 PM, Guy Sotomayor via cctalk wrote: 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 <stdbool.h> 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

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

On 1/29/21 12:58 PM, Fred Cisin via cctalk wrote: 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

On 1/29/21 4:25 PM, Nemo Nusquam via cctalk wrote: Which Henry was that? Henry Spencer perhaps? bill

On 1/30/21 1:57 PM, Nemo Nusquam via cctalk wrote: Another blast from the past. I haven't seen anything of or spoken with him in nearly 30 years. bill

On 1/29/21 11:59 AM, Fred Cisin via cctalk wrote: SUBROUTINE FOO(X) INTEGER X X=15 RETURN END ... CALL FOO(10) Lots of fun, there. --Chuck

On Fri, 29 Jan 2021 at 22:14, Fred Cisin via cctalk <cctalk at classiccmp.org> wrote: ? -- Liam Proven ? Profile: https://about.me/liamproven Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053

On Fri, 29 Jan 2021 at 13:11, Peter Corlett via cctalk <cctalk at classiccmp.org> wrote: Agreed. I submit this is also why some people find Lisp (and perhaps Forth and Postscript) straightforward, while to others it remains ineffable. Specifically, this one, I believe: https://en.wikipedia.org/wiki/Steve_Vickers_(computer_scientist) Good BASICs had that. ... Fair. :-( 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: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053

On 1/29/2021 8:19 AM, Liam Proven via cctalk wrote: 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.

On Fri, 15 Jan 2021 at 17:44, Gavin Scott via cctalk <cctalk at classiccmp.org> wrote: 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: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053

On 2021-01-15 1:33 p.m., Nemo Nusquam via cctalk wrote: Seems backwards when students have no time to learn things. Just sayin --T

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, Dave

On 1/15/21 6:11 PM, Fred Cisin via cctalk wrote: Even worse when they are told specifically to "not waste time" learning things like APL or COBOL. bill

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

On Fri, Jan 15, 2021 at 4:41 PM Fred Cisin via cctalk <cctalk at classiccmp.org> wrote: 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.

On 1/20/21 1:01 AM, Eric Smith via cctalk wrote: After reading many of Dijkstra's one liners I find I don't like him or his opinions at all. 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 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

On Wed, Jan 20, 2021 at 02:05:37PM -0700, ben 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: https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.overflowing… The documentation doesn't explicitly say "carry" because Rust is architecture-neutral and it's down to LLVM to decide how to express it in machine code, but on x86 (and probably ARM) the boolean return value comes directly from the carry flag. You "don't believe in objects" yet then describe a problem which only exists due to the lack of them and then present OO pseudocode to solve it. A lot of OO languages suck of course, but the fundamental idea of encapsulation is not the bit that sucks. Here's it in Rust, where it takes in an arbitrary array (pedantically, "slice", a (pointer, element count)-tuple) and determines its length at runtime: pub fn clear_indexed(array: &mut [usize]) { for index in 0 .. array.len() { array[index] = 0; } } (The code for C-style fixed-length arrays looks broadly similar but has a bit more boilerplate because they're less useful.) Iterating over indices is generally discouraged for a number of reasons, not least being that the index may be out-of-bounds, but also because it can inhibit vectorisation or parallelisation. You have no choice in broken languages such as C, but many languages provide some notion of iteration which guarantees to not go out-of-bounds: pub fn clear_iterator(array: &mut [usize]) { for elem in array { *elem = 0; } } Both code fragments generate equivalent assembly in this trivial example because the Rust compiler could prove at compile time that the index variable can't go out-of-bounds. In more complex real-world code it cannot reliably do so and will insert a run-time check which aborts if the index is out-of-bounds. Or if it's C, trundle on and corrupt things. Oddly enough, the state of the art has moved on a bit in the half-century since C was invented. It's just that quite a lot of programmers haven't yet noticed.

On Tue, Feb 02, 2021 at 08:50:56PM -0700, ben via cctalk wrote: [...] (I assume you mean "30 years earlier" here.) Two reasons, one of which I was already aware of back then in 1991, and one which is only obvious in hindsight. The first is simple toxic masculinity. It's more manly to write stuff in machine code (then) or C (now), apparently. The second is a combination of Moore's Law and computer science. To handwave wildly, Rust is what you get when you look at C++'s mistakes of the last forty years and start again. If you've used a C++ compiler from the 1980s or early 1990s, you'll have found the experience harrowing: computers were still too slow and too small to do a good job, and various important language design and code-generation techniques were not yet known and/or were too impractical to implement. It all improved rapidly in the 1990s and 2000s, bringing us more or less to the top of the sigmoid curve. u32::overflowing_add() returns a (u32, bool), i.e. a two-member struct. Those early compilers cannot return structs directly, so the caller would have to reserve space (on the stack, probably) and pass the address for the function to fill in. That simple add-producing-carry has just become a function with a half-dozen instructions, several of which are needed to check the carry flag and convert it into a integer, plus many memory accesses, just to provide a C wrapper around a simple add instruction. At that point it does make sense to toss the compiler and write assembly language. Modern compilers do a lot of heavy inlining as a matter of course, will split structs and perform dataflow analysis on individual elements, and generally avoid memory access unless they absolutely have to. u32::overflowing_add() should turn into a single add instruction and the carry flag will probably be tested directly by a branch instruction and never get converted to a boolean variable. It'll be as good as if not better than hand-written assembler. This is a particularly trivial function as well. Rust just wouldn't be viable with 30 year old compiler technology. RISC-V doesn't have a carry flag. It handles overflow by e.g. using the BLT instruction to branch if the result is smaller than the number being added to. So documentation which assumes the world is x86 will not make sense here. [...] There's no real difference between a "constant ... when called into use" and a pure function which returns a value based on the structure elements. That is an implementation detail which you don't need to know to be able to write Rust code. However, the len() method actually just returns the element count from the (pointer, element count)-tuple. The function is so trivial that it is guaranteed to be inlined so it's exactly the same as if you had accessed the field directly. Before you ask, no, you can't access the field directly for all of the excellent reasons explained by every "introduction to OOP" tutorial which I don't need to repeat. [...] Runtime bounds-checking can get rather expensive -- it tends to add an extra compare-and-branch to tight inner loops and may also foil automatic vectorisation -- so it makes code much faster if the compiler can prove the check is unnecessary and eliminate it, or at least hoist it out of loops. An ordinary Rust programmer doesn't actually need to know any of this. They write code and it goes as fast as is safe. If it's not fast enough for them, they can ask an expert who knows this sort of intimate low-level detail and optimisation tricks to poke at their code, much as with any other language. What decades of toxic-masculinity C programmers have taught us is that they'll eliminate the bounds-check without proving it was unnecessary, assuming they ever bothered to perform the test in the first place, and ship code which will be trivially compromised. But it'll be really fast right up until your credit card details are leaked!

On Fri, 15 Jan 2021 at 17:50, Liam Proven <lproven at gmail.com> wrote: 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: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053