That still discounts the network effects of Unix, of universities, of the substantial amount of open-source programs and routines to be stolen from the Unix/university world.
And it’s not as though Pascal was aimed at the same niche as C; Modula-2 was, but Pascal already had all the mindshare when it arrived.
…it really was a Pascal API. Programming a Mac in C involved basically swimming upstream against this API, full of dealing with things like non-C strings (if I remember right, Mac ROM strings were one byte length plus data).
The AmigaDOS portion of the Amiga OS was essentially a very quick port of TRIPOS; TRIPOS was written in BCPL. There were hoops one had to jump through when writing code in C and dealing with AmigaDOS to interface with the BCPL side of things.
(By the time of, IIRC, AmigaOS 2, the DOS had been rewritten but kept the BCPL behavior for compatibility purposes.)
Regardless, to my knowledge there was never any significant BCPL development on the Amiga. All official documentation was for assembly and C, and I don’t even know if I ever saw a BCPL compiler for the Amiga though I suppose one must have existed.
It’s been years since I dove into this part of things but yeah, to some extent.
The most notable stuff was that AmigaDOS dealt in BPTRs for pointers; these were always 32-bit aligned to conform to BCPL’s rules. There were also BSTR’s, which were BCPL/Pascal-style counted strings.
There were functions to convert between the various representations, and so on.
(BPTRs were just typedefs to pointer-to-long and, if I recall correctly there wasn’t a lot of help for dealing with BSTRs, you just kinda had to know about the length byte, but I could be misremembering.)
Well, BCPL was constructed when bytes were very, very new and probably not available on any machine its creators had encountered. In the 60s, you dealt with words. BCPL, which was meant to be a bootstrapping language for the more complex CPL language, was simple to implement and close to hardware, but especially close to hardware as it looked in the sixties.
When byte-addressed machines (almost every microprocessor ever) came around, the word-orientedness of BCPL became a problem because on a 68000, which can deal with bytes, 16-bit words and 32-bit longwords, BCPL addresses were always in the shape of longwords. That meant that in order to pass a pointer between C and BCPL you had to divide or multiply it by four to translate between byte and longword addressing.
Back in the day, low-level was all it was for most programmers. That made C a natural choice - higher than the assembler, yet, familiar and similar enough to feel comfortable. And you could call it a “real” programming language. The hardware was simple, and a simple language served it well.
Those conditions do not exist today - modern and heavily complex hardware, rapid adoption of software systems in all walks of life, and the demand for people to be able to tame these systems simply outruns the dedication, time and effort it takes to master a language like C.
It is a good thing actually - we have plenty of choice. With experience, I classify languages in the same “right tool for the job” bucket. This skill is invaluable and helps in making proper tradeoffs for the problem at hand.
That said, I still love C for its sheer simplicity. “The C Programming Language” is still my favorite book - every line in that book is carefully crafted with minimum number of words necessary to convey the meaning and no more. Just like the language. Sigh I now suddenly feel old and grumpy! :-)
I started developing for Macintosh around the time of that transition. My first programs were in Pascal but then in 1988 I was hired by a developer who required the app be in C. I can’t remember their rationale, but it may have been that my boss was a C programmer, and/or that ANSI C had just been published and the Lightspeed C IDE had just been released.
(Mac C compilers had a pascal keyword to flag a function as using Pascal calling conventions — opposite parameter order — and a string literal starting with “\p” was a Pascal string with a leading length byte.)
Within Apple, I think C++ had more to do with it. C wasn’t significantly more powerful than Pascal, but C++ was a lot more powerful than Object Pascal. The Finder team led the way, rewriting the Finder in C++ for System 7.0, and the MacApp app framework was ported at around the same time.
Speaking only for myself, but back in the early 1980s, the attraction of C over Pascal was so clear as to hardly require explanation. Pascal was the poster-child of bondage-and-discipline languages, reveling in syntactical rules of dubious utility. (“No semicolon before an end” is a perfect example of a theorist’s pet rule, one that sounds good on paper but offers little but irritation in practice.) In contrast, C was clearly a tool made by programmers for programmers. The language’s simplicity made it easy to grasp quickly. Even the warts were simple to understand to an experienced programmer. The reliance on punctuation over keywords for basic syntax made source code so much nicer to read. I swore off Pascal as soon as I learned C.
(Which is perhaps too bad, actually, because despite how comfortable C was, in some ways Pascal was the more appropriate language for the long-term future. Having been designed as a pedagogic language, its rigidity discouraged clever trickery and programs were probably more robust for that. Meanwhile C’s hands-off approach to hacking around language obstacles all but begged you to code for the current machine, ignoring any considerations of portability or future-proofing. C was not designed to be a portable language, so it’s a little unfortunate that that became its destiny.)
That still discounts the network effects of Unix, of universities, of the substantial amount of open-source programs and routines to be stolen from the Unix/university world.
And it’s not as though Pascal was aimed at the same niche as C; Modula-2 was, but Pascal already had all the mindshare when it arrived.
The AmigaDOS portion of the Amiga OS was essentially a very quick port of TRIPOS; TRIPOS was written in BCPL. There were hoops one had to jump through when writing code in C and dealing with AmigaDOS to interface with the BCPL side of things.
(By the time of, IIRC, AmigaOS 2, the DOS had been rewritten but kept the BCPL behavior for compatibility purposes.)
Regardless, to my knowledge there was never any significant BCPL development on the Amiga. All official documentation was for assembly and C, and I don’t even know if I ever saw a BCPL compiler for the Amiga though I suppose one must have existed.
Really! I had no idea BCPL had survived into the ‘80s. So its calling conventions were different from C?
BCPL is still updated today!
It’s been years since I dove into this part of things but yeah, to some extent.
The most notable stuff was that AmigaDOS dealt in
BPTRs for pointers; these were always 32-bit aligned to conform to BCPL’s rules. There were alsoBSTR’s, which were BCPL/Pascal-style counted strings.There were functions to convert between the various representations, and so on.
(
BPTRs were just typedefs to pointer-to-long and, if I recall correctly there wasn’t a lot of help for dealing withBSTRs, you just kinda had to know about the length byte, but I could be misremembering.)Well, BCPL was constructed when bytes were very, very new and probably not available on any machine its creators had encountered. In the 60s, you dealt with words. BCPL, which was meant to be a bootstrapping language for the more complex CPL language, was simple to implement and close to hardware, but especially close to hardware as it looked in the sixties.
When byte-addressed machines (almost every microprocessor ever) came around, the word-orientedness of BCPL became a problem because on a 68000, which can deal with bytes, 16-bit words and 32-bit longwords, BCPL addresses were always in the shape of longwords. That meant that in order to pass a pointer between C and BCPL you had to divide or multiply it by four to translate between byte and longword addressing.
Back in the day, low-level was all it was for most programmers. That made C a natural choice - higher than the assembler, yet, familiar and similar enough to feel comfortable. And you could call it a “real” programming language. The hardware was simple, and a simple language served it well.
Those conditions do not exist today - modern and heavily complex hardware, rapid adoption of software systems in all walks of life, and the demand for people to be able to tame these systems simply outruns the dedication, time and effort it takes to master a language like C.
It is a good thing actually - we have plenty of choice. With experience, I classify languages in the same “right tool for the job” bucket. This skill is invaluable and helps in making proper tradeoffs for the problem at hand.
That said, I still love C for its sheer simplicity. “The C Programming Language” is still my favorite book - every line in that book is carefully crafted with minimum number of words necessary to convey the meaning and no more. Just like the language. Sigh I now suddenly feel old and grumpy! :-)
I started developing for Macintosh around the time of that transition. My first programs were in Pascal but then in 1988 I was hired by a developer who required the app be in C. I can’t remember their rationale, but it may have been that my boss was a C programmer, and/or that ANSI C had just been published and the Lightspeed C IDE had just been released.
(Mac C compilers had a
pascalkeyword to flag a function as using Pascal calling conventions — opposite parameter order — and a string literal starting with “\p” was a Pascal string with a leading length byte.)Within Apple, I think C++ had more to do with it. C wasn’t significantly more powerful than Pascal, but C++ was a lot more powerful than Object Pascal. The Finder team led the way, rewriting the Finder in C++ for System 7.0, and the MacApp app framework was ported at around the same time.
Speaking only for myself, but back in the early 1980s, the attraction of C over Pascal was so clear as to hardly require explanation. Pascal was the poster-child of bondage-and-discipline languages, reveling in syntactical rules of dubious utility. (“No semicolon before an
end” is a perfect example of a theorist’s pet rule, one that sounds good on paper but offers little but irritation in practice.) In contrast, C was clearly a tool made by programmers for programmers. The language’s simplicity made it easy to grasp quickly. Even the warts were simple to understand to an experienced programmer. The reliance on punctuation over keywords for basic syntax made source code so much nicer to read. I swore off Pascal as soon as I learned C.(Which is perhaps too bad, actually, because despite how comfortable C was, in some ways Pascal was the more appropriate language for the long-term future. Having been designed as a pedagogic language, its rigidity discouraged clever trickery and programs were probably more robust for that. Meanwhile C’s hands-off approach to hacking around language obstacles all but begged you to code for the current machine, ignoring any considerations of portability or future-proofing. C was not designed to be a portable language, so it’s a little unfortunate that that became its destiny.)