That would be fun, although I don't think this list is setup for "sub-Reddits." I occasionally hack with my first love, APL. Wouldn't mind some SNOBOL or PL/1 dalliances, but no time. Lee C. On Fri, Aug 7, 2015 at 9:28 AM, Chris Osborn <fozztexx at fozztexx.com> wrote: -- Lee Courtney +1-650-704-3934 cell

On Sat, 8/8/15, Kip Koon <computerdoc at sc.rr.com> wrote: Kip, As Noel mentioned, MCPL wasn't part of the evolution; it actually is pretty recent compared to the other three. Yes. There are copies of several different generations of BCPL reference manuals floating around online. I've come across at least three, not including the material in his current distribution of it: basically the original one by Richards, one by Gardner, and one done by XEROX. It's been a surprisingly widely used language for one that is so little known. The basic story is that Cambridge began developing a language calling it the Cambridge Programming Language. They joined forced with London University who was also working on language development and changed the name to Combined Programming Language. Richards defined a subset of the language with the intent that it be the implementation language for a CPL compiler and described it in his dissertation at Cambridge in '66. The following year he was at MIT and did the first implementation of this Basic CPL, or BCPL. This was at the same time as when the Multics project was in full force and Bell Labs was involved. If I'm not mistaken, there was a version of BCPL that ran on Multics, and I am guessing that's where Ken was exposed to it. When Bell Labs pulled out of Multics and Ken started playing around with the now famous "little used PDP-7" he created a language for it that was based on BCPL but I gather somewhat smaller because of the more limited resources on the PDP-7. That was B. Then Dennis decided to add types to B and the result was C. As near as I can tell, MCPL was something Richards was playing around with primarily about 10 years ago. I'm not sure, but from what I can tell, his most recent work has been on BCPL rather than MCPL, though as I mentioned, I'm finding I really like MCPL. Richards' pages for both languages are here: http://www.cl.cam.ac.uk/users/mr/BCPL.html http://www.cl.cam.ac.uk/users/mr/MCPL.html Among the resources he has there is a rather extensive document on running BCPL on the Raspberry Pi. http://www.cl.cam.ac.uk/users/mr/bcpl4raspi.pdf Yeah, it started as a weekend diversion doing a paper design of a 6809 SBC, and I ended up doing a couple turns of the boards and have a few lying around I play with from time to time. One of them is dedicated to running a TU-58 emulator for one of my LSI-11s. I've got a rather skeletal collection of material on it here: http://www.cs.drexel.edu/~bls96/6809sbc/ The main things that you might find interesting here relative to Grant's are the inclusion of a microSD card for storage, a design and layout that allows for either a 6809 or 6809E (with appropriate jumpering), and a little MMU for using 128KB of memory mapped into the lower 48KB space in pages of 16KB. The whole thing ends up being 11 (or 12 if you're running on an E) chips: 1 - 6809 processor 1 - 6821 parallel interface 1 - 16550 UART 1 - MAX232 RS232 level converter 1 - 2864 EEPROM 1 - 628128 128KB static RAM 1 - 7404 2 - 74138 2 - 74153 The '138s are for address decoding as you'd expect. The '153s are the MMU. If you do get some material up on your system, I'd love to look at it. BLS

Actually, when the algorithm is to square a value, the difficulty reduces to ONLY ( n^2 + n ) / 2 which is effectively half of the multiply instructions required when two different numbers are multiplied. Unfortunately, as you point out, that still takes until half way to the heat-death of the universe. IN ADDITION, it is the Lucas-Lehmer primality test: http://en.wikipedia.org/wiki/Lucas%E2%80%93Lehmer_primality_test that I wish to implement (so I can understand the details along with being able to enjoy the challenge). So the series of one billion bit multiplications must be repeated (one billion - 2) times. I have already done that for all three: Karatsuba algorithm - n1.585 https://en.wikipedia.org/wiki/Karatsuba_algorithm Toom-Cook multiplication - n1.465 https://en.wikipedia.org/wiki/Toom-Cook_multiplication One aspect of the Toom-3 algorithm that needs to be solved is the requirement to divide by 3. There are a number of other possible Toom-Cook algorithms which divide the initial value into three or more parts which may also be even faster and might not require division, but only a shift. I understand both the Karatsuba and Toom-Cook algorithms sufficiently to EVENTUALLY implement both at this point. However, if I use RT-11 under Ersatz-11 as the starting point, it is highly probable that it will be necessary to use a DLL that is written in x86 assembler for the actual implementation of the subroutine to square, subtract two, then take the modulus. If I can perform each squaring operation in just one second, it should take only about 5 years to perform the squaring one billion times. One possible improvement might be to activate a second DLL which executes as a 64-bit program which is called by the 32-bit DLL. Since I expect to have a 64-bit Win7 system some time this month which I hope to be able to use to run Ersatz-11 in 32-bit mode, that MIGHT be possible. Can anyone who reads this comment on IF it is possible to have an additional thread spawned by a 32-bit DLL running under 64-bit Win7 which will execute as a 64-bit DLL? Since there is a single 32-bit value which needs to be passed to the 64-bit DLL and a single YES / NO result passed back, that might be a possible solution which might reduce the execution time by a factor of four. Sch?nhage-Strassen algorithm https://en.wikipedia.org/wiki/Sch%C3%B6nhage%E2%80%93Strassen_algorithm Unfortunately, the Sch?nhage-Strassen algorithm is still beyond my capability. However, I hope to master it eventually and implement the code. If anyone can comment on my question regarding the spawning of a 64-bit DLL from a 32-bit DLL running under a 64-bit Win7, that would be appreciated!!!!!! Also, a link to information about how to implement the Sch?nhage-Strassen algorithm would also be very much appreciated. Jerome Fine

On Fri, Aug 7, 2015 at 1:16 PM, Rich Alderson <RichA at livingcomputermuseum.org> wrote: Yeah, I guess I left it wide open, didn't I? I'm not sure I could really narrow it down, since different spheres do use different things, and (as in the case of Fortran and the Lisps) some quite old languages are still being used, and still evolving, in niches. But my question does include those two language families as well, especially the older implementations of them. Now that I think about it, though, I'm not sure whether C should qualify as an example; implicitly I was thinking it was far too mainstream (being the basis of Unix and much of Windows, plus tons of applications); but it is also fairly old and curmudgeonly, and allows you to do dangerous things like mess about with pointers. I think maybe the scope of this question probably depends a lot on the scope of the person asking it. I've only worked with microcomputers, so things like COBOL and RPG (while I'm sure they are available on micros in some form) are completely out of my ken. And I'm under 40, which means there are plenty of things I haven't heard of; but also that many things that I *have* heard of before the 1980s BASIC home computer heyday are sort of exotic and interesting. As for my interests, I started with Commodore BASIC and 6502 assembly. I'm still interested in 6502 (and to an extent x86) assembly, but I sort of feel like I got enough out of Commodore BASIC and don't feel the need to revisit it. Then again, since I'm a wishy-washy sort, I remember my dream of writing a compiler for it. And I'm slightly interested in GWBASIC and QBasic, since I haven't quite "worn them out" yet in my mind. I spent a long time trying to like C++; it was hard going (perhaps because the differences between C++ and C were fuzzy in my mind then). I was using DJGPP and Turbo C++ 3 back in those days; I've installed both in DOSBox but so far haven't had time to play with them much. Then finally I moved on to various scripting languages, and now I just pick up a little here and a little there of different things. (I love how interpreted languages on modern hardware run so much faster than compiled or hand-coded assembly programs in the old days.) A few years ago I developed quite an interest in PostScript, and through it discovered Forth and bits of other stack-based languages. I'm looking forward to getting a SunOS system (someone has agreed to set me up in the near future) so I can use PostScript as part of the NeWS operating system. I'm not sure why that system (which uses PS for all [local] front-end code, and whatever you like on the backend) seems so cool to me; it's basically the same way web apps work, only with PS instead of JavaScript, but still I want to try it. I don't like Forth as much as PS (doesn't seem as elegant), but it does have its charms, and slowly I'm digesting it and learning its conventions. It's nice that it's easily implemented on a small system. Finally, I'd like to actually learn Logo some day too. Back in grade school they would regularly sit us down and have us draw squares with the turtle, but no actual programming, which makes me sad and a little angry now -- Logo is a lot more than RT 90 FD 100! (I'm trying to remember if they even taught us how to repeat a set of instructions; I'm certain they never said anything about creating functions.) To Brian L. Stuart: What separates MCPL from CPL and BCPL? I'm not finding much about it, although it looks like it has the benefit of nice pattern matching. Ah... text editors are another big interest of mine. That's very cool. I should check TECO out some day. -- Eric Christopherson

I am not a programmer, but... I love stack-based languages in general (Forth was the first high-level-ish language I learnt after BASIC (which in turn I learnt after SC/MP machine code). I particularly like RPL, the language used on the HP28/48/49/50 series of calculators. You can put just about anything on the stack. Real numbers, integers, unit objects (real numbers with attached measurement units), binary numbers, strings, vectors, matrices, lists (of anything), programs (!), etc. Operators do what you'd expect so '+' applied to 2 reals pops them and pushes their sum. Applied to 2 strings, it pops them and pushes the concatenation of the strings. And so on. Not many languages let you built up what looks like a program in a string (using the normal string operators) then turn that string into a program (also on the stack) and then execute it. -tony

From: Eric Christopherson Sent: Friday, August 07, 2015 12:09 PM They're playing an all ages, no cover set at Showbox SoDo tomorrow night! (Sorry, I couldn't resist. I'd pay to go see a band called "Fortran and the Lisps", whether by value or by name. ;-) Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/

I view the language issue along the same lines as the OS (or monitor, or ???) that exists on the various classic computers. With some notable exceptions, I tend not to run Unix on my classic HW but one of the original OS's that the HW was shipped with. The same goes for programming languages. I don't want to write everything in "C". In some cases C imposes too heavy a burden (MVS 3.8 J for example) and isn't in line with the "flavor" of the machine and/or OS. In the case of my Symbolics machines, even though there is a C compiler for it, my question is "why?". It's a LISP machine, you should write in LISP (after all even the OS is written in LISP). When I'm doing programming, I choose the language that's most appropriate. Not only based upon the problem at hand but the environment/machine it's intended to be used on. For example, for my MEM11 project, I'm using a uP that is designed to run Forth, so I'm writing everything in Forth (including the simulator). It turns out to be really efficient and low overhead. I can't imagine what it would take for a C-runtime to provide the environment that I currently have with Forth. TTFN - Guy On 8/7/15 12:10 PM, Sean Caron wrote:

Sometimes a language doesn't appear to be "mainstream" until you dig deeper. For example, Forth used in OpenBoot. Heckuva great idea. I haven't the faintest idea of where OpenBoot stands now. --Chuck ------------------------------------------------------------- "The first thing we do, let's kill all the spammers."

All the young kids are using Python and PHP these days! :O Best, Sean On Fri, Aug 7, 2015 at 4:24 PM, David Cooper <trs80 at marmotking.com> wrote:

I love this list, I always learn so many interesting things ... reading the article on SynthesisOS now; a few pages in, it sounds like an early attempt at building a reflective operating system? Neat. I wonder if the Quamachine still exists? :O Best, Sean On Fri, Aug 7, 2015 at 6:11 PM, Sean Conner <spc at conman.org> wrote:

On Fri, 07 Aug 2015 at 18:11:09 -0400, Sean Conner <spc at conman.org> wrote: The DEC C / Compaq C / HP C or whatever it is called this week compiler on Alpha or IA64 VMS has 32 bits ints and pointers can be 32 or 64 bits. I think the similarly named compiler on OSF1 / Digital Unix / Tru64 or whatever that is called this week offers the same facilites. Regards, Peter Coghlan.

On 08/08/2015 08:44 AM, Jay Jaeger wrote: Technically, however, isn't the language "SNOBOL4", not "SNOBOL"? At least that's the way my bought-in-1968 black covered copy has it. I've tried it on a 360/40 and a CDC 6600 (even in 1968, there existed several "ports' of it, including for the Univac 1108 and RCA Spectrola as well as one for the Intel 8080 under CP/M. As others have pointed out, there are better tools now. Does the code from Bell Labs SNOBOL 1, 2, or 3 still exist anywhere? --Chuck

On 08/08/2015 12:13 PM, Jay Jaeger wrote: I think the test would be "Can language x+1 run, without substantial modification, programs written in language x?" If the answer is "no", then languages x and x+1 are separate languages, and not compatible dialects of the same language. So FORTRAN IV would be a compatible dialect of FORTRAN II (mostly at any rate, FII vendors had a nasty habit of adding their own features willy-nilly, as did FIV). I think Codasyl was first to clamp down on "the default is the standard as we say it is", then FORTRAN followed. However, I'd submit that F95 is a separate language, as it can't run FIV, F66 or F77 programs without modification as it doesn't understand ASSIGN-ed GOTOs as well as H-type (Hollerith) FORMAT specs. --Chuck

Hi Phil, I checked out your SNOBOL4 page and I just wanted to note for your list of historical platforms that SNOBOL4 and SPITBOL were also implemented on the Michigan Terminal System (MTS) on S/360 ... this is actually the incarnation I've been playing with recently ... along with numerous other languages, it's just baked right into the D6.0 distribution tapes so it's easy to get started right after a fresh installation ... I've found MTS is a great platform to play around with a lot of these older languages on Hercules... it's my favorite S/360 operating system by far. Best, Sean On Sat, Aug 8, 2015 at 11:14 AM, Phil Budne <phil at ultimate.com> wrote:

On Sun, 9 Aug 2015, Douglas Taylor wrote: ??!? December 1993 1.0 was February 1993 Do you really mean "first Microsoft IDE"?? Howzbout QUICKC? (October 1987) or first C++? or first Windoze? (QuickC for Windows September 1991) or first Windoze C++? When I taught C, I forced ("mean teacher") my students to do at least one program using a command line compiler (suggested: GCC or PersonalC (DeSmet)), and to do at least one program using an IDE (suggested: TurboC, quickC, VisualC++, or Microsoft C/C++). I was even so mean that I made them create a source file AND an executable file, and even check the DIRectory to confirm that the executable was newer than the source.