| Ah history...
Actually, before C there was BCPL. A friend of mine did the BCPL machine interpreter on the B1700, and later I did C. After his experience with BCPL, his view was that you really don't want to write programs at that level. But BCPL was an improvement over C. Before BCPL, there was CPL from the Mathematical Laboratory of the University of Cambridge. I was taught Languages and Compilers by someone who worked in that laboratory who also worked on GPM (General Purpose Macrogenerator)(no, not Strachey before anyone asks).
This I believe was the start of this language stream.
Before that was ALGOL 60 and this was the first language to have an OS written in it, the Burroughs B5000 MCP. Just as ALGOL is much better than C, MCP is much better than Unix. Oh well. Unix became popular because it came out of a company that weren't in the OS business like Burroughs.
Apple itself has a lot of Burroughs heritage - Alan Kay who invented the window, conceptualized the dynabook (iPad), and championed OOP in Smalltalk was a student of Bob Barton, who was the chief designer of the B5000:
(A lot of good stuff added to that article since I submitted the original.)
It was Barton who adopted HLLs for systems programming (although Don Knuth had developed the first ALGOL compiler for Burroughs during a student break).
C also got its defines from Burroughs ALGOL, although ALGOL did them right!
Well, that's a bit of the history about how C came to be (and thus the best C-based language... Objective-C of course!). I know pointing out that C has many flaws and deficiencies offends some people, but we do need some intellectual honesty and detachment when it comes to C.
Ian On 6 Jul 2010, at 06:22, David Halliday wrote: ObjC-Language list: It appears we have too many people here that don't know, or understand the history of C. As with nearly everything, the history helps one understand the why of various design characteristics. The "tool"* C (formerly B [and, presumably, formerly A]) was designed to be a high level assembly language, with no optimization whatsoever envisioned for it's "translator" (compiler). (The only "portable machine code" like entities I am aware of are the "byte" codes of virtual machines.) Yes, C exposes "implementation details all over the place." As with any assembly language (machine specific or high level) it is specifically designed to deal with implementation details. Almost every assembly (machine) level construct within practically any von Neumann like architecture is encoded into C operators.** One can practically "see" the machine code from the C code (at least before we started "muddying the waters" with optimizers). The problem wasn't so much that C was designed to expose "implementation details all over the place." The problem was in the way C caught on as a general purpose, let alone application level, programming language, which it most certainly was not designed to be. I don't know why Hamish Allan seems to think it is necessary, or even desirable to have an application level (high level) programming language "expose these levels of indirection". While it is needed to have such exposure at the assembly/machine level, it is most certainly unnecessary at the application coding level. (The fact is, the more such implementation details can be hidden away, the more powerful the optimizations that can be employed. This is the reason Fortran, for instance, is designed to hide so many implementation details.*** It is also the reason so many optimizations are unavailable to C compilers [and why even some of those that are available are "dangerous"].) David * It was called a "tool" because its creators (who were writing UNIX) were under strict orders not to create a new programming language in the course of their work. ** The primary exceptions I am aware of are the roll instructions. I suppose that either the creators of C (as a "tool" for writing UNIX) didn't figure they would ever need these instructions, or the hardware targets they had in mind didn't all have these, now oh so common instructions. (We now have to code this using multiple instructions and hope that the optimizer "does the right thing".) *** Unfortunately, during the Fortran 90 standardization process, some of us didn't completely understand this, and, having been "corrupted" by languages that expose "pointers" we clamored for, and obtained "reference" types—learning only later that there was a better way. On 7/5/2010 8:08 AM, Ian Joyner wrote: On 5 Jul 2010, at 20:51, Hamish Allan wrote:
On Mon, Jul 5, 2010 at 2:10 AM, Ian Joyner<email@hidden> wrote:
The simple fact is that C exposes implementation details all over the place.
This is bad
...
C is the root cause of most of today's computing problems
C is portable machine code.
Like any compilable language actually (or even interpreted code).
It's designed to expose implementation
details.
Don't know if it was designed to, but it just happens to.
Every high-level language you use, at the end of the day,
runs on a machine that needs to differentiate between values and
pointers. If "a->b" didn't exist, you'd have to write "(*a).b", and
you'd still have to make changes across your entire codebase if you
decided to change the level of indirection of a variable. How would
you design a language to expose these levels of indirection which did
not require such changes?
That's really easy.
obj A { b }
A a; // This a just goes on stack
To access b:
a.b
A *a; // This goes on heap
To access b:
a.b
Just the same. The compiler is smart enough to know one is on the stack and one is in the heap. Programmer changes mind compiler generates correct access code. There really is no need for two access operators that do the same thing, just as there is no need to have Objective-C objects declared with a * because everything goes on the heap anyway. If you could clean up these languages you'd get less irritating syntax errors, less programming exceptions and more reliable software, less need for common refactorings. All of these ills with the range of techniques with which you can undermine C to create viruses and worms means C is a weak base for any language. And yes it confuses new comers because it is confusing. C reminds me of the slides in WWDC 2010 session 103 showing the two urinals together so only one is usable, staircases on the outside of a building, and the non-balcony.
|
