April fool's joke: change the sequence numbers on the punch cards and "accidentally" cause the cleaners to drop them. 2014-09-25 16:41 GMT+01:00 ben <bfranchuk at jetnet.ab.ca>: -- Kind regards, Yvan Janssens Sent using CompuServe 1.22

Yes.. On Thu, Sep 25, 2014 at 12:16 PM, Mike Loewen <mloewen at cpumagic.scol.pa.us> wrote: I'd heard this one before, but couldn't quite recall how it went.. thanks!

At 02:20 PM 9/25/2014, Paul Koning wrote: Nothing in this world is impossible. :) Object Oriented COBOL? Yep, it exists. Fujitsu Cobol .NET. Dot Net. In Cobol. (Apparently it's now called "NetCOBOL" or some such.) MOVE TRUE-VALUE TO ENABLED-FLAG OF ROW X COLUMN Y OF GRID-CONTROL. -Rick

On 9/25/2014 9:01 PM, Rick Murphy wrote: You can even do OO COBOL on zOS. Enterprise COBOL, as I recall... Jim -- Jim Brain brain at jbrain.com www.jbrain.com

So, y'all think that OOPs is a JOKE? I wonder what Djikstra would have said about them. Oh, for the indecipherable hieroglyphics of APL, or the tedious verbosity of COBOL. -- Grumpy Ol' Fred cisin at xenosoft.com

It was written... Kinda yeah. More of a fad. But it is another bullet..... http://www.tundraware.com/Technology/Bullet/ J

On 09/26/2014 10:46 AM, geneb wrote: I believe that he didn't care much for the IBM 1620 either... --Chuck

On 09/26/2014 01:13 PM, Fred Cisin wrote: Dijkstra's illiteracy, Fred? Seriously, what language in 1960 offered hierarchical data structuring? "Special-names"? Choice between use of binary or decimal numeric representations? The list of langauge features is very long. I can remember being a bit surprised that such a crufty language had built-in segmentation/overlays. A co-worker back in the day was on the old IBM COMTRAN project. He thought COBOL was a pretty good language; it was PL/I that he regarded as a dog's dinner, citing extreme dysfunction among the project members. --Chuck

On 09/27/2014 08:10 AM, Paul Koning wrote: So what language would Dijkstra have used in 1960 to implement his BDP application? COBOL was notable in taking business languages from several vendors (e.g. COMTRAN, FLOW-MATIC) and coming up with a common dialect. COBOL was plagued, in the beginning, not primarily with issues of language, but of "cheats", such as IBM's "ENTER LINKAGE" for the S/360 or "ENTER AUTOCODER" for the earlier machines. IBM did nothing to discourage this--indeed, with the initial S/360 COBOL implementations, one had to resort of ENTER LINKAGE for ISAM files (I have the document detailing this). In, I think it was, COBOL 75, there was sufficient backlash toward vendor additions/"features" to the language that it was mandated in the standard that the default behavior of a compiler was to consider vendor extensions and features as errors, unless explicitly enabled. I vividly recall running the Navy Audit Tests before every new release. When answering program trouble reports, I had a well-thumbed copy of the CODASYL standard on my desk. It was very explicit in how things should and must work. Very handy for citing chapter and verse when a customer's complaint did not reflect reality. Heck, Dijkstra's pet Pascal didn't even *have* I/O initially, much less implementing ISAM. By then, of course, probably tens or hundreds of millions of lines of COBOL had been written. I don't remember Dijkstra offering to convert them to Pascal. --Chuck

On Sat, Sep 27, 2014 at 12:50 AM, Dave G4UGM <dave.g4ugm at gmail.com> wrote: Because they all sucked, for various reasons. Being in common use doesn't mean that they're good in any absolute sense. It might mean that they were slightly less awful than some other things available at the time. But it might not even mean that. In the 1970s the choice of programming language was often dictated by what happened to be available, and for many systems there were few choices. Things haven't really improved much since then either, despite the bewildering number of language choices now available. C is an absolutely awful programming language by any objective standard, worse than COBOL in some ways, yet it is one of the most prevalent programming languages in terms of actual lines of code in use worldwide (think internet infrastructure and/or embedded systems). I make my living predominantly by writing C code, despite my considerable misgivings about it. Why? Because the customer is always right, even when they're completely wrong. If the customer wants code written in C, that's what I deliver. In that regard things haven't changed since the 1970s, or, for that matter, since the first business transactions in human prehistory. Perhaps at some point customers will actually start to recognize the merits of programming in a high-level language, rather than C which is just portable assembly language, but that doesn't seem to have happened yet. I thought the Heartbleed bug might move us in that direction, but it hasn't. Some people claim that C++ has fewer problems than C, but they are delusional. As a near superset of C, C++ has all of C's problems, plus new ones that it has added. Possibly a sufficiently restricted subset of C++ might actually be a decent language. "The more I ponder the principles of language design, and the techniques which put them into practice, the more is my amazement and admiration of ALGOL 60. Here is a language so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors." -- "Hints on Programming Language Design", C.A.R. Hoare, Stanford Artificial Intelligence Laboratory Memo AIM-224,December 1973 With the benefit of hindsight, ALGOL definitely got some things wrong, but it got an amazing number of things right, including some that are still being done wrong in languages invented thirty or more years later. Note however that neither FORTRAN nor COBOL were successors of ALGOL. Almost all other programming languages are either successors of ALGOL, or at least have appeared sufficiently later than the appearance of ALGOL that they should have taken some lessons from ALGOL (either positive or negative).

C is not completely portable. FORTRAN was described as being as portable as syphilis. C is not quite an assembly language. But most implementations of C will be fairly cooperative about "get out of the way" when you do need to go low-level. Job's "dream team" designing the Lisa showed one example of when a high level language is NOT an ideal solution. They clearly demonstrated many examples where Theory and Reality don't match. Use of Pascal for writing an OS betrays a lack of familiarity with hardware performance needs. (Need for greater hardware performance doubles every 17 months, rendering Moore's law a futile attempt at catching up.) Significant components of the Lisa OS had to be rewritten in assembly language (or in some cases, maybe just C) to get acceptable performance. -- Grumpy Ol' Fred cisin at xenosoft.com

Neither is any other language. At the time, FORTRAN was about as good as it got for portability. Today? C is quite possibly the most widely portable language there is. (I feel reasonably sure there are more machines with C but not FORTRAN than the other way around.) Next month? Next year? Next decade? Sorry, my crystal ball is foggy. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 09/27/2014 03:11 PM, ben wrote: It depends. There were a lot of cross-assemblers written in FORTRAN. Some could be run on non-binary, non-ASCII, non-8-bit character machines. Let's see 'C' do that. Usually, the first couple of statements in such a program were: INTEGER CHARS( 64) READ 100, CHARS 100 FORMAT( 64A1) The first record in the input would be the character set used for the remainder of the program. I think a lot of young-uns are unaware of exactly how different 60s and 70s systems could be from one another. S/360 does not represent the beginning of time by a long shot. --Chuck

C _can_ do that; indeed, many of the freedoms granted to the compiler are there to support such machines. (That most C coders these days are unaware of that, and write as if the whole world were x86 Linux, is the fault of the coders, not the language.) Even machines that can't really support C can usually support something C-like enough that only the more language-lawyery types would refrain an 8051 - int was 8 bits and long 16, I think, but it was otherwise C.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Sep 28, 2014, at 10:04 AM, Dave G4UGM <dave.g4ugm at gmail.com> wrote: Of course ? that?s what the IBM 360 uses, and GCC has supported that for quite a long time now. paul

On Sun, 28 Sep 2014, Paul Koning wrote: I'm having a hard enough time wrapping my mind around how to get a 360 to process a card that starts with "/*" /* IS THIS JCL? */

possibly, but ISTR that when Prime tried to sell us some 750s their salesman said that the OS was written in PL/1. Incidentally the system we bought in that procurement (Honeywell level 66) may have eventually gained a "C" compiler (I don't think it did, however), but our preferred system programming language was "B". We only ever wrote 3 tiny modules in GMAP. [the other shortlisted suppliers were DEC and GEC - the DEC salesmen just didn't try, they effectively threw the price book at us whereas Prime and Honeywell threw the price book away :) The GEC salesmen were by far the most technically knowledgeable but they were only on the shortlist because we were forced to include a British company and their systems were not really in the same league as the others. We did have to fight hard to avoid being forced to buy them but we knew the score and put almost as much effort into proving that they couldn't meet our requirements as we did in comparing the other three. ]

On Sun, 28 Sep 2014, Chuck Guzis wrote: 40+ years ago, when utility companies sent their bills on punchcards, one fellow would add /* to the first two columns before sending it back. I always wondered whether that actually worked.

On 9/29/2014 11:25 AM, Mouse wrote: I like the COME FROM statement myself. How did it handle DECIMAL and BINARY?

On 09/29/2014 10:25 AM, Mouse wrote: To be fair, there was some wisdom in that. Algol had block structuring of a sort; FORTRAN had a widely-known concise and minimalist way of expressing mathematical operations (for quite a long time ACM CALGO would accept submissions in either Algol or FORTRAN); COBOL had a way of representing data structures and numeric precision. And all were mutually incompatible. Obviously, it would have been a real advantage to have a common lingua franca for these competing schools. When forced to use PL/I, the result, of course, was that the Algol people wrote in an Algol style, the FORTRAN people wrote in a FORTRAN style and the COBOL people wrote in a COBOL style. So there was never a common school of programming thought. That's not to say that PL/I didn't have its advantages. It had a very powerful preprocessor language--something that C never had, although C++ sort of comes close. When pared down, it could be quite useful--Intel's PL/M is nothing more than PL/I after a meat cleaver's done with it. DRI offered an amazingly rich version of pared-down PL/I for the 8080-family of microprocessors--it must have been a Herculean effort. --Chuck

On Sun, 28 Sep 2014, Chuck Guzis wrote: Surely, you could write a C compiler in FORTRAN. C SHIFT LEFT 1 BIT X = X + X

Hm, yes, I read too fast. Non-binary is difficult, probably to the point where it's not worth the bother. It would need, at a minimum, the assistance of runtime conversion to and from something operationally equivalent to binary. I'm not sure even that is enough; the assumption of everything being made up of bits is wired very deeply into modern C - and to a nontrivial extent into even K&R C. But it might be possible. It certainly would be possible by building an emulator for a binary machine, but that's a very not-in-the-spirit-of-C thing to do - it would feel more C-like to throw out the binary requirements in C's spec and implement a not-quite-C that actually matched the hardware. The attempt would certainly be a fascinating exercise. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

First, let me dispose of the easy ones: Auto-increment and -decrement are not bit-oriented; they make just as much sense for PICTURE 999999 variables as for int variables - indeed, any type for which addition and subtraction of small integers make sense can support ++ and --. (Note that standard C supports ++ and -- applied to pointers and floating-point types.) No C variant I'm aware of has rotates (though with the variety of experiments out there, I'd be surprised if nobody had created one). gcc's internal representation (in at least some versions) has rotates, it's true, but (a) gcc's "C" is not actually C (it's C plus various extensions, at a minimum), and (b) gcc also supports a bunch of other languages, at least some of which may well have rotates. Bitwise operators and shifts are the interesting ones. Modern C requires them to operate on unsigned integral types, and signed integral types when the values in question are nonnegative, as if they were represented in binary: 6.5 Expressions ... [#4] Some operators (the unary operator ~, and the binary operators <<, >>, &, ^, and |, collectively described as bitwise operators) are required to have operands that have integer type. These operators return values that depend on the internal representations of integers, and have implementation-defined and undefined aspects for signed types. ... 6.5.7 Bitwise shift operators ... [#3] The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. (in this next paragraph, note that the textification I'm quoting from lost superscripts; "2E2" is supposed to be 2 to the power E2.) [#4] The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1?2E2, reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1?2E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined. [#5] The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 divided by the quantity, 2 raised to the power E2. If E1 has a signed type and a negative value, the resulting value is implementation- defined. (Interesting. I hadn't previously noticed that << was undefined but >> was implementation-defined in the negative case. I wonder why....) ~ (6.5.3.3 #4), & (6.5.10 #4), ^ (6.5.11 #4), and | (6.5.12 #4) all simply speak of the bits making up the operands, so it's not clear what the spec could mean if the machine is non-binary or the operands are otherwise not made up of well-defined bits. But K&R is much laxer in its definitions. I'd have to go read it to be sure, but you might be able to implement &, |, ^, and ~ as per-digit operations rather than per-bit operations (my first cut would be & as digit-by-digit minimum, | as digit-by-digit maximum, ^ as digit-by-digit addition modulo the base, and ~ as ~x = MAXINT-1-x (loosely speaking)), with shifts shifting by digits instead of bits, and still conform to K&R. That certainly feels like a reasonable approach to me. K&R C was designed as an OS implementation language. As such, it is expected that the coder knows the machine, with operations doing things that are unsurprising in view of that. Modern C is a tricky balancing act, on the one hand pulled towards that original stance by the desire that it still be a useful OS implementation language, on the other hand pulled towards precisely-specified and machine-independent semantics by the desire that it be usable for cross-OS-portable programming, such as for application-level code and utility libraries. The current ubiquity of binary machines has meant that C could get away with mandating binary for things like & and << without crippling it enough to bother anyone with significant clout, in contrast to things (like int size, which they found it necessary to leave considerable leeway in). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

It was thus said that the Great Charles Anthony once stated: ANSI C mandates a short as being at least 16 bits, and a long as being at least 32 bits, and an int no shorter than a short, and no longer than a long. I don't think a single BCD digit would fit that criteria. Going back to K&R ... um ... maybe? Perhaps? Can you address a single BCD digit? If not, it may make char * a bit hard to support ... -spc

On Tue, Sep 30, 2014 at 1:50 AM, Eric Smith <spacewar at gmail.com> wrote: I forgot to mention that there also is a requirement that relates all of the integer types to powers of two, so for instance having an unsigned character type implemented as 3 BCD digits with a range of 000 to 999 is also a non-starter. I would have to be limited to 000 to 255 or 000 to 511, with the other possible machine representations becing known as "trap representations". Note that tonly the number of non-trap representations is restricted. While the source-level integer type semantics have to be 0..2^n-1 (for unsigned), or the near-equivalent signed range, the actual representation used for the values could be anything. For instance, the value 0 could be represented as the sequence of BCD digits 3, 9, 2 if you really wanted to do that, as long as all of the arithmetic, conversion, etc, consistently produced correct results that are not trap representations. It's allowed to produce a trap representation for signed overflow. The behavior of trying actually read an lvalue with a trap representation is undefined, so it might cause the machine to catch fire or demons to fly out of your nose, yet still be standard-conformant.

On 9/30/2014 1:50 AM, Eric Smith wrote: I would go with 2 BCD digits for characters. Control is NULL/CR/TAB/LF + 96 ASCII characters. But I suspect C would be different if the base machine was NOT a PDP-11. Ben.

On 9/30/2014 2:22 AM, Eric Smith wrote: C is so tied with UNIX and B it hard to say just who was first with what. For decimal C like lang, you still need backslash and delete so the character set needs to hacked. Ben.

On 09/29/2014 11:35 AM, Mouse wrote: Because there's more than one machine that has shift right as an arithmetic (sign-extended) operation, with shift-left being a logical (shift zeroes into the lsb and toss the msb). The CDC 6000, since we've mentioned it was one such (AXi Xj,Bk vs. LXi Xj,Bk operations). There are some assumptions made in K&R that are significant on older machines. Dijkstra didn't mention it in his tirade against the 1620, but there are characters/digits(?) on the 1620 that can't be compared (e.g. record, group marks), only tested for and one (numeric blank) that can neither be tested for nor compared. On the 1620, the compare operation is a strictly arithmetic affair and special characters aren't part of the vocabulary. So trying to, say, compare a record mark with a numeric blank will result in a check condition. Indeed, there's no way to tell the difference between a record mark encoded as 82 and 821, while it's certainly possible to read either into memory. I attribute these "shortcomings" to a shift in attitudes over the years. 1620 programmers KNEW about the various issues and inconsistencies and avoided them. At worst, you had to restart the machine. Sort of a "you know that you'll injure yourself if you try to trim your nails with this oxyacetylene torch" whereas modern architectures try to make sure that you never get the opportunity. There's a parallel in consumer and industrial protection regulations, I think. Hence a reference to PL/I. I think this page makes an interesting read: http://www.uni-muenster.de/ZIV.EberhardSturm/PL1andC.html One attraction of C was that it was a cheap close-to-assembler language with a small vocabulary. One could become usefully fluent in K&R C over the space of a weekend. With the latest incarnations of C++, I'm not sure that I could become usefully fluent in six months. Similarly, PL/I's biggest liability is that it's a very large language and somewhat difficult to master in a short amount of time. --Chuck

On 09/30/2014 06:39 AM, Mouse wrote: There's plenty on the 1620 on bitsavers. --Chuck

On 9/28/2014 8:02 AM, Paul Koning wrote: Back to BIG machines. BIG as 16K words , printer , card reader, disk I/O. I think Time Sharing vs Control computers splits most usage up better.

In article <54282EE7.6010607 at sydex.com>, Chuck Guzis <cclist at sydex.com> writes: If the 1620 is turing complete, that means that those operations can be implemented, although it sounds like you'd have to implement them in a very roundabout manner similar to the way floating-point operations were emulated on CPUs with only integer math. C doesn't require that boolean operations and shifts be in the native instruction set, only that you can implement some sequence of operations in the native instruction set that supports the semantics. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

On Behalf Of ben IBM card reader. I beg to differ. For many years 9-track tape was the basic method of interchange. A Mini-Reel could hold a reasonable amount of data and yet could easily be popped into a jiffy bag. As for being "portable" provided one stuck to the standard Fortran was extremely portable. Issue may have arisen when the extensions were used but there was a host of software that would, possibly with tweaks run on most anything. A typical example is CSMPII which was released for the IBM1130 so I guess around 1965. The 1130 might be an IBM system and usually had a card reader, but in no way is it a Mainframe!. Any way CSMP is IMHO a typical piece of scientific or engineering Fortran, except rather than being for a specific purpose was a general purpose analog computer simulation. It was "freeware" and very soon found its way onto a host of other systems including PDP-8, PDP-11 and PDP-10 most of which didn't have card readers and interestingly to the IBM/360 where there was a card reader. If my memory serves me correctly, at least "later on" whenever that is, there were the DEC extensions to Fortran which hindered portability. However when I worked at NERC in the UK we often moved Fortran between Honeywell, DEC and IBM machines with little effort. The GEC 4000 Fortran did kick up issues because of the way it treated single precision constants (1.0 as opposed to 1.0D0) which was a PITA for scientists used to DEC fortran. Even plotter output could was pretty portable. Most suppliers provided a clone of the Calcomp HCBS (I think I have that write) or there were higher level libraries. For Numerical Algorithms the NAG library (which still exists http://www.nag.co.uk/numeric/fl/FLdescription.asp) or the IBM Scientific Subroutine Package (SSP) were also portable (Like CSMP , SSP was freely re-distributable)... Having "C" is not the answer to every maiden's prayer. If you are interested in Scientific Programming then it may be if it's a small platform that whilst it has a "C" complier it doesn't have the libraries you need to run your program. If it will run every "C" program then you can always compile the Hercules Mainframe Emulator and load the free VM/370 which comes with three Fortran implementations (G, H and Watfiv).. Dave G4UGM

On Behalf Of Mouse are more which support FORTRAN well and C badly. I just think they are rare compared to the swamp of machines with C but no FORTRAN. Whilst I agree with the sentiment, consider the following proposition:- 1. The vast majority of "Machines with 'C'" are "machines with GNU "C"' 2. If the GNU compiler package is fully implemented GNU Fortran should run on any machine with GNU "C" (well C++) Given the above it would appear to me that machines with "C" but no Fortran (available/possible) are also pretty rare beasts, and largely exist because of lack of demand... ... actually it appears that the PDP-8 doesn't have a proper "C" compiler but it does have Fortran. I wonder how many PDP-8's still exist.... .. and finally if we change the definition to "machines with a self hosted "C" compiler" as "opposed to "C" via a cross compiler" then I think the numbers would equalize.... Having said all that I am still not going to write any new code in Fortran, well except that I want a HangMan program for my IBM1130 FPGA emulation and Pen Plotter for demo purposes and I don't have "C" for the 1130 so it is going to be in FORTRAN... Dave G4UGM of support aside, FORTRAN is usually a better language than C for heavy numerical code, which is what "scientific programming" designed as an OS implementation language. That neither is all that great at the other's task is hardly a surprise.)

http://en.wikipedia.org/wiki/Wirth's_law On Sat, Sep 27, 2014 at 12:29 PM, Fred Cisin <cisin at xenosoft.com> wrote: -- Lee Courtney +1-650-704-3934 cell

I feel reasonably sure it was not. It may, however, have been written in a Pascal-plus-extensions language. This may sound like quibbling, but I don't think so. One of Pascal's major defects for purposes like that[%] was its lack of support for things like what C would call casting, or the very restricted I/O available. [%] For Pascal's design purpose, these are advantages, not defects. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

From: Dave G4UGM Sent: Saturday, September 27, 2014 10:41 AM IIRC, BCPL was block-structured a la Algol. It was, of course, the direct ancestor of B, which is the direct ancestor of C. We all know that the proper successor to C will be named P. 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 thought there already was a "P" and a "D" ...

On 2014-Oct-01, at 8:11 AM, Brian L. Stuart wrote: There was a Z. 1970/80s sibling of C.

Facebook thinks its hot: http://www.drdobbs.com/mobile/facebook-adopts-d-language/240162694 On Wed, Oct 1, 2014 at 12:03 PM, Paul Koning <paulkoning at comcast.net> wrote:

Dijkstra's key interest was proving program correctness (he was a mathematician). All the stated languages had features that made this difficult - if not outright impossible. But he didn't have a good answer when I asked him if this didn't just push the problem back to the program specification, not to mention the problem that in "the real world" specifications received frequent modification. Proof of program correctness is one of those things that I feel "would be nice, but will /never/ happen for real applications". Andy

On 9/27/2014 1:59 PM, Paul Koning wrote: which one? all I can find is Green Hills RTOS at 6+ steve

Liam, He probably can't say. However I still don't think CC security evaluation is anything like a mathematical proof the program works as specified, it is also very expensive and time consuming... <sorry I wanted to put some CC links in here but the web site does not respond.> You might like (or perhaps not) to note that the UK also has what I understand is a lower level of assurance called "foundation level". I recently installed the Microsoft Windows/2012 Direct Access feature for the council where I formally worked. It is interesting to note that despite the product being certified to Foundation Level, which is a also rigorous process:- http://www.cesg.gov.uk/servicecatalogue/Product-Assurance/CPA/Pages/Foundat… http://www.cesg.gov.uk/servicecatalogue/Product-Assurance/CPA/Pages/CPA-and… they still recommend additional firewalls and an Intrusion Protection System... Dave G4UGM -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Liam Proven Sent: 28 September 2014 11:33 To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Who is the world's oldest working programmer? On 27 September 2014 22:59, Paul Koning <paulkoning at comcast.net> wrote: Name? Company? Any kind of a clue at all? -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On 9/28/2014 7:07 AM, Paul Koning wrote: Interesting home page... but I only see the DO-178B level A cert addressed. Lots of references to secure code but no CC or EAL cert. How about a link or something... Steve

On 9/28/2014 7:07 AM, Paul Koning wrote: Here's a 2005 doc that says "certifiable to EAL7" but that isn't the same as actually getting the t-shirt. http://www.sproyte.no/articles/files/1_lynxsecure.pdf Steve

On Sep 28, 2014, at 7:56 PM, Rick Murphy <rick at rickmurphy.net> wrote: I?ll have to dig more. Looks like this one is a red herring. The one I saw said that it was actually evaluated, not that it was ?designed to be evaluated?. paul

When mathematicians can't prove something, they try and transform it to something they can prove. So rather than prove the correctness of the original program, use tools to re-structure and re-write the program in such a way that the difficulties are eliminated. For example look at the techniques used to unravel the wonderful obfuscated 12 days of Christmas.... http://research.microsoft.com/en-us/um/people/tball/papers/xmasgift/ I am pretty sure tools be developed to take a program with the issues you mention and from it produce a functionally equivalent program, whose correctness would be more easily provable.. Indeed, as how do you specify the functional requirements of a program in way such that there are no ambiguities in the specification? Well perhaps you write pseudo code and I suggest that if you write pseudo code, then can I suggest it would be possible to produce algorithms for converting the pseudo code to most any language in such a way that the converted code will be provably correct.... Trying to prove an arbitrary program implements a specific function is challenging.... Dave G4UGM

On 9/27/2014 3:03 PM, Eric Smith wrote: I suspect it is more of being too general in many cases with the langauge. ,123+foobar(x++==++z); is a valid C statement but prove that is correct in what way? Ben.

On 09/27/2014 02:19 PM, Richard wrote: Way back when, I think it was IEEE Computer had an article entitled something to the theme of "Looking for the Silver Bullet". That was easily 20 years ago and the situation has not improved one bit. Witness, for example, the 25-year-or-so just-discovered vulnerability bug in bash. Used in millions of computers. It probably wasn't considered a bug 25 years ago, given that there was no way to exploit it. Things change. --Chuck

On 27/09/14 5:19 PM, Richard wrote: However, proving type soundness and other properties is commonly done today (and is much desired[1]). Much progress has been made in the past 50 years, despite regressive howlers like C. We _are_ allowed to use a wide range of well-researched mechanical methods to improve software quality. After all, we have a computer right here, why waste it. --Toby [1] http://qr.ae/cRFJa

On Sep 30, 2014, at 9:38 PM, Rich Alderson <RichA at LivingComputerMuseum.org> wrote: Predecessor on the calendar, yes. Not in any other way. paul

On 25 September 2014 20:20, Paul Koning <paulkoning at comcast.net> wrote: http://www.coboloncogs.org/INDEX.HTM But I'm surprised they do not yet have anyone who is still working and who started before 1969. Hell, I can just about *remember* 1969 and I'm only 46... -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

The old standby is: "COBOL programmers understand why women hate periods." On Thu, Sep 25, 2014 at 11:30 AM, drlegendre . <drlegendre at gmail.com> wrote:

On 9/25/14 8:30 AM, drlegendre . wrote: <plonk>