4

While COBOL was the first highly successful business-oriented programming language, several business-oriented languages were designed before it in the late fifties, including Honeywell-800 Business Compiler a.k.a. Fully Automated Compiling Technique (FACT).

In History of Programming Languages page 209 Jean Sammet remarks on the comparison between that language and the in-development COBOL:

since ... FACT was really a good and advanced language, any technical comparison would usually be on the side of FACT. However, the difficulties of dealing with machine independence, and the interaction of competing manufacturers certainly made the creation of a common business language orders of magnitude more difficult.

(Emphasis in the original.)

While I can certainly see that FACT didn't need to be machine-independent and COBOL did, and that machine independence would require a little more care, I am very surprised by the assertion that it was 'orders of magnitude more difficult' (even allowing for hyperbole). I would expect, for example, a business-oriented language to specify data in characters and decimal digits (as COBOL does), therefore naturally not care about things like byte size, endianness, or ones versus twos complement signed integers, that might cause trouble for a lower-level language. But perhaps there were other particular difficulties at that time, that I am not used to taking into account.

What exactly was machine-specific about FACT? What were the big difficulties in achieving machine independence?

Improve this question
3
  • I might be wrong, but this seems quite related to the 'direct punch processing' issue asked in parallel: retrocomputing.stackexchange.com/a/16028/6659
    – Raffzahn
    Commented Aug 31, 2020 at 22:39
  • 1
    To your point, the 'Hollerith' mode permits any 'legitimate' punch, whatever that means -- but it could be arbitrary non-character patterns. The other modes seem portable enough.
    – dave
    Commented Aug 31, 2020 at 22:58
  • 2
    Keep in mind rhe context. Immediately before that passage, she tells us that she was on the Short-Range Committee that designed COBOL, and that in October 1959, the Intermediate-Range Committee passed a motion “the essence of which was that FACT was a much better language than the specification produced by the Short-Range Committee so far, and hence should be adopted as the basis of the new Common Business Language. As can be imagined, this had the effect of a major bombing on the Short-Range Committee [....]” What she says is a defense of her own work and of rejecting that recommendation.
    – Davislor
    Commented Aug 31, 2020 at 23:54

1 Answer 1

Reset to default
3

This is a partial answer at best, and guesswork as well.

Jean Sammets's Programming Languages: History and Fundamentals -- another book everyone here needs -- has a very brief section on FACT, pp327-328. This might be relevant to the present question:

The implicit assumption is that people using FACT will have their data on an input deck from which a tape must be created by the FACT system. (A similar facility is available for paper-tape file data.) The FACT system does quite a bit of error checking as this conversion is taking place.

My inference from that is that programs are rather particular about data format, and this the language is implicitly tied to a system (rather than to hardware).

How that relates to the language itself, rather than the sole implementation of the language, I can't guess.

The FACT language manual describes file handling. File descriptions on cards are used to create some sort of data dictionary that is written to the tape that will hold the file.

That seems to be a constraint of the language, and what data it can process -- only files created by the same language? -- and not something truly hardware-specific. But perhaps that was enough to disqualify FACT.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .