Byte Magazine: The C Programming Language (1983)
archive.org
archive.org
(Which is not to say anything good about Java. The key to Java was elucidated by Mark Dominus: "I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.")
> ... but with no unsafe memory accesses.
Mostly true. But you could still get a null pointer exception in Java - which is especially weird because Java doesn't have pointers.
The contempt Java's designers held for its users fairly drips, in what they write about it.
For the primitive types, like long, you can't get a null pointer exception, because there really is no pointer, but for any object type it's actually a pointer, the object itself lives on the heap and you're given a pointer to it, if the object is null, that's a null pointer. They don't feel much like pointers from a language like C because you're not provided with pointer arithmetic - you can't try to add my_object + 16 as you could in C - and because Java was a modern language which knows what you mean when you write foo.bar, unlike C and C++ which expect you to remember whether foo is a pointer and write foo->bar so that the poor compiler needn't figure it out.
For modern Java the compiler does escape analysis and may conclude an object cannot "escape" in which case it may be created as part of the stack frame of the code which uses it instead of on the heap, but it's still basically a pointer.
This is all rather awkward, for example Java's 64-bit double precision floating point number is a primitive, always 8 bytes on your stack no need for a pointer to anything - but if you want your custom four 16-bit integers type (maybe representing RGBA) that's an Object so it is treated differently even though it's also just 8 bytes. C gets this part right, your custom types (struct, and to a lesser extent enum and union) aren't treated so much worse than the language built-in types.
Anyway, it's Memory Safe because the null pointer exception is essentially the same behaviour as if you try to unwrap() a None in Rust, the JVM isn't going to let you just "press on" as you might in C, you've got a programming error and must either recover from that or your program aborts.
But seriously, is there any modern language other than Perl where regular expressions feel so… natural? I reach out for Perl less and less, but always sigh when I need to handle any regex in Python.
Example: /.*a.*/.test("this is a string") // returns true
the most time I've ever spent dealing with invalid addresses and memory leaks, in production /enterprise code, has been in Java, not C or C++
my personal theory is because despite how much safer Java was by design, culturally, beginning in the early 2000s, it also opened the floodgates to a big wave of lower caliber programmers "just doing it for steady jobs" and so a "99% right? ship it! someone will file a ticket next week if needed" mentality was more common
not the fault or credit of the langs, just the type of people they attracted, at large scale
Java: "I'm super friendly! Just click here!"
C: "Here's a razor blade. Here's a razor blade. Another. Another. Now assemble to build a maze. Also the maze is invisible. Oh and our manual is 50 pages."
(I appreciate both in diff ways.)
Java was just enough like the C++ of 1990 to compete, but with garbage collection and a big library, and without confusing pointers, so lower-skilled programmers could use it. That is all. Computers were literally thousands of times slower than today. Java was considered just barely fast enough.
But without freeing programmers from the Microsoft frameworks treadmill, it would have sunk without a trace.
Right. We had Purify for that.
Maybe he is saying bull now to look more cool, but he sounded rather convincing in the interview. I'd recommend to listen to it
Can you send some examples? Curios to read those.
No memory leaks and portability were the main benefits we were sold on at the time
At least you get an error message. Silently continuing when things go wrong is worse.
No, that was much of the point. Memory leaks, pointer overruns, use after free bugs were a huge time sink. In addition to portability, industry wanted a language without these problems.
Enterprise development is always about delivering features first. Performance, security, reliability, etc. come after that.
Huge time sink.
I was tasked with porting to SunOS 4, where if you deref NULL you crash with SEGV. Therefore I had to get real good at GDB real fast and chase every instance of NULL usage, where I'd put in an initial check first. I did my job alright and before long, our server code was running smoothly cross-platform, and I'm fairly sure that my patches had far-reaching effects beyond the SunOS platform I'd developed on.
My colleagues and I were at the forefront of a wave of new Internet users in the early-to-mid 90s, and the embedded programming language environment of a simple text "adventure game" was conducive to many people learning how to program in a simple and forgiving environment. Those of us who hacked clients and servers were a somewhat elite vanguard; I decided to specialize in systems administration and had an interesting career soon afterwards.
And it all started because some VAX programmer had thought it was no big deal to dereference NULL pointers in a pervasive way throughout the ANSI C codebase of a game server.
Then came the “aha” moment. I downloaded a few tutorials which used the GLUT library from C and I was instantly amused. Now I could draw 3D teapots and text and rectangles with almost no boilerplate and I had examples to learn from. A turning event that has influenced all aspects of my life for the latter 20 years.
I almost actually considered leaving programming in the mid 2000s but then I started seeing the tide slowly turn away from OOP, or at least I found voices that agreed that OOP is not the only answer and I felt a sense of relief. Then as latency became a more and more important thing in algo trading, it eventually fell out of favor almost entirely.
But yeah, OOP has a place but it really went overboard for awhile and there was jiggawatts of brainpower spent on trying to make it work when straight C or other approaches would have worked much better- and with much more grokable code!
So I've been learning Smalltalk/Pharo and reading Smalltalk, Objects, and Design [1] because people say that's what OOP was really supposed to be. It's been interesting and enlightening in some ways, but I still feel like I'd rather do most things without OOP. Do you think it's still helpful or worth it to dig into all this for someone now?
[1]: https://www.amazon.com/Smalltalk-Objects-Design-Chamond-Liu/...
I would skim it though, just to have a sense of what's in there.
Remember, hardware is getting more powerful and cheaper.
Not much has changed over the years ;)
> In response to Gregg Williams' editorial ("The New Generation of Human- Engineered Software," April, p. 6), the mouse of Lisa, Visi On, and their predecessor, the Xerox Star, is a truly fascinating hardware device, and on those few occasions that I have seen these devices in use, I have been impressed. But the mouse is not revolutionary, and, as its name suggests, it is really nothing more than a rodent. Its functional predecessor was the light pen. Some years ago, light pens were fashionable devices for selecting a particular function, and they are still in use. But displays attaching light pens had to have an appropriate phosphor, and they were not as easy to program as function keys. About the same time, touch- sensitive screens were introduced, and they are still used in applications such as online catalogs in libraries; here, too, however, programming appears to be the chief stumbling block.
> If the name of the game is "ease of use," the industry would be far wiser to develop touch-sensitive displays than mice. Because a display has no moving parts, it is likely to prove more durable than a mouse. And a finger placed on a display screen does not require additional desk space, as a mouse does. If an executive were having an office conference, don't you think he might rather touch his screen a couple of times than roll a mouse around his desk pressing buttons on it?
> There are, obviously, many considerations at work in the development of new products. My bet, simply stated, is that the mouse is not a viable product. At best, it will limp along like bubble memory. - John P. Rash, President, Acorn Data Ltd.
There's also:
- Several refutations to a previous letter which claimed CRT monitors are a radiation hazard
- An engineer from Intel responding to criticisms of their FORTRAN compiler with "those issues have been fixed in the latest version"
- Debate over structured programming and strong typing
- Debate on what "computer literacy" means and whether the general population needs it (including a claim that WYSYWIG editors and desktop file managers do not make computers easier to use because "a desktop manager is only a sophisticated analog for being able to copy one file into another")
- Conversations on software prices and piracy
- And, of course, someone pointing out a typo in an article.
— Ecclesiastes chapter 1, verses 8-11, RSV translation.
Written about 2500 years ago, +/- some centuries (experts disagree on date and author). It's maybe a bit comforting and distressing at the same time.
I had to Google the quote, but it goes like "those who don't learn from the past are bound to repeat it". I am not sure if there's a way around it or some level or repetition is obligatory for things to move forward.
Maybe it's like the saying that you can't really give out advice to someone, because your advice also comes with all your previous baggage. But on the other hand, that's how we learn and transmit our knowledge across generations right?
I think there's some sort of true in all those "feelings" but we also can't deny there are also incremental change that persist over time... Hard to say.
The iPhone could not have succeeded without.
Then I saw the price of the software advertised, like compilers and such, and I whole heartily agree with that guy!
C++ succeeded not just because it can call C libraries -- most languages can -- but because it retained every advantage C has, even those that few recognize. C++'s STL is a success because it built on what made C a success, deliberately. Alex Stepanov, anyway, understood. Most STL components are really just examples.
Today we are locked in battle against C's weaknesses, particularly in how easy it is to exploit C programs. We lose that battle when new languages leave behind what made C successful. Too-easy accidental conversions bad; deliberate conversions possible, good.
C got various other things subtly right, too: manifestly enough to make up for its blatant failings. If you would displace C, it is much more important to retain its strengths than to fix its flaws. You can do that without understanding by copying. Retaining strengths while leaving behind flaws requires understanding, which has proven too hard for most.
There is a quite interesting session from talk done by him at Adobe, where he mentions his inspirations.
C++ proved adequate. But C++ compilers of the time were not; all of them needed massive improvement to usefully build programs that used STL. (It took many years for Microsoft to get there; STL implementations obliged to work under Microsoft compilers were badly crippled until after C++11 came out.) But no other language was up to the job.
Bjarne did not motivate porting it to C++; the language did. Bjarne helped, but Andrew Koenig might have helped more.
Could you elaborate on this point? Walter Bright famously wrote [1] that C's biggest mistake is that it implicitly degrades arrays to pointers when you pass them as arguments to functions. Do you have a rebuttal to his piece? I am not a C expert so I honestly don't know what could be wrong with his proposal.
[1] https://www.digitalmars.com/articles/C-biggest-mistake.html
I agree. I wonder how feasible it is to separate the two, though. Not because it seems as if there is some unavoidable trade-off to be made (if that was it then somebody would have found a relatively crisp definition of said trade-off). I suspect that it's best understood as an emergent phenomenon.
Consider the LINUX KERNEL MEMORY BARRIERS readme [1], which states very clearly: "Nevertheless, even this memory model should be viewed as the collective opinion of its maintainers rather than as an infallible oracle". And yet some people persist with the belief that such an Oracle must really be possible. Oracles are abstract concepts.
C doesn't persist despite its contradictions. It persists because of them.
I'm not claiming that this is good or bad. Just that it's the simplest explanation that I can think of.
[1] https://www.kernel.org/doc/Documentation/memory-barriers.txt
- C Language: Key to portability
- Apple Lisa's revolutionary user interface
- MS-DOS 2.0 brings Unix-like features
- ArpaNet can be a game changer
The editors had managed to cramp what would shape the next four decades of computing in a single issue.
"[ArpaNet] is not only operational, but growing. In time, it may shift from its defense-related role into more commercial areas."
Pascal, CP/M, OS/2, Logo, Smalltalk, etc...
That was its shtick.
Of course some of these predictions were going to turn out to be true.
(note: the articles sedatk mentioned didn't seem to be in the table of contents, but on PDF page 113 there is a "special report" section where I've found some of them)
- Big difference in philosophy. CP/M is record-based, you work with big tables describing files. Dos 2.0 prefers streams, and it has much more lightweight, Unix-like file handles.
- Another Unix feature adopted is device files. There was no line printer or console file in DOS 1.0, if you wanted to do something unique with I/O you had to write a program for it. That along with pipes makes 2.0 much more nice to work with even 40 years later.
- Hierarchical directories and hard drives. The two go together, and the advantages should be obvious.
- Memory management. Dos 2.0 is the first to have equivalents of malloc, free, and realloc in its syscalls. This makes having Terminate and Stay Resident (TSR) programs much more feasible. The PRINT command is an example, it can run in the background.
The only thing I remember ever bypassing DOS for filesystem access was things like Norton DiskEdit, unerase utilities, and defraggers. Do you have examples in mind?
(Of course lots of programs didn't use standard output.)
I agree that without hard drives you didn't really need subdirectories. It's hard to fit more than a couple of screenfuls of files on a single floppy.
Thanks, Mom. You opened the door to a lifelong passion and a decent livelihood to boot.
Also I could imagine what it was like living through this time, schematics for modems, cheesy ads for EEPROM writers, what a wonderful magazine, I would have been waiting by the door for this to be delivered each month.
About once a month I would journey down to the capital, where -- in exchange for my IT services -- they let me tinker to my heart's content and type in my programs (the only language available, and the only one I knew at the time was GW-BASIC).
The country, Lesotho, is unique in many ways. It is completely within South Africa, and 2/3 of the men used to go to the South African mines to work. I'm not sure about now, but they used to have one of the highest HIV infection rates in the world (35% or so).
There is also a ski resort (https://afriski.net/). The white colonizers didn't want the land because it was so mountainous -- the lowest point in the country is 1,400m above sea level -- and was not suitable for agriculture, so they let the Africans stay there.
Damn, now you have me dreaming about OCRing my journals!
If I remember correctly, I wrote a GW-BASIC program to decode WordPerfect macros, allow them to be edited as text, and re-encode them.
So many modems!
I know someone who was a grad student at that time, and how excited he was to get a 2400 baud modem and his own VT-100 for work on the VAX.
That grad student was me, though today it seems almost impossible to remember what it was like back then. I do remember ruining a colleague's line-by-line source printout by sending a console message that read, "Andropov just died."
We used to create static electricity by rubbing a hand on the carpet, then touching the phone wire...
We had to use Avian IP and tons of breadcrumbs...
> Operating systems have to deal with some very unusual objects and events: interrupts; memory maps; apparent locations in memory that really represent devices, hardware traps and faults; and I/O controllers. It is unlikely that even a low-level model can adequately support all of these notions or new ones that come along in the future. So a key idea in C is that the language model be flexible; with escape hatches to allow the programmer to do the right thing, even if the language designer didn't think of it first.
This. This is the difference between C and Pascal. This is why C won and Pascal lost - because Pascal prohibited everything but what Wirth thought should be allowed, and Wirth had far too limited a vision of what people might need to do. Ritchie, in contrast, knew he wasn't smart enough to play that game, so he didn't try. As a result, in practice C was considerably more usable than Pascal. The closer you were to the metal, the greater C's advantage. And in those days, you were often pretty close to the metal...
Later, on page 60:
> Much of the C model relies on the programmer always being right, so the task of the language is to make it easy what is necessary... The converse model, which is the basis of Pascal and Ada, is that the programmer is often wrong, so the language should make it hard to say anything incorrect... Finally, the large amount of freedom provided in the language means that you can make truly spectacular errors, far exceeding the relatively trivial difficulties you encounter misusing, say, BASIC.
Also true. And it is true that the "Pascal model" of the programmer has quite a bit of truth to it. But programmers collectively chose freedom over restrictions, even restrictions that were intended to be for their own good.
I was an avid reader of Byte and 80-Micro back then.
For various reasons, I focused on other studies for a few years after that, and didn't immediately learn C until after I went to college. I'm sure if I had learned C in '83, I would have had an entirely different career trajectory.
Back then, I used to dream about buying an eprom programmer!
I miss electronics...
Interesting. I thought C appeared as a (very) high level language back in 1983, when development on microcomputers was still mostly done in assembly. This article was published August 1983 and Turbo Pascal v1.0 was only released in November, so I'm not sure what high level languages were available on microcomputers back then, besides BASIC.
I was writing games, and there could be a bit of BASIC wrapper, but the rest was assembler.
It was a competitive advantage early in the 1980s, then turned into a handicap by the end of the decade when the performance and memory tricks didn’t matter as much as graphics and GUI.
Not really compatible with Windows though.
It was commercial, student and hard core amateur, developers who developed in assembly in the 80's. C was only ever 'high level' when compared to assembly/machine code. Manual memory management was an indicator that it wasn't high level at all. That said, much commercial software was still written in assembly back then as that was the only way to wring the performance out of an 8-bit and even early 16-bit micros. It was the transition to 16-bit, when all that 6502/6800 code became obsolete when C really started to take over.
https://www.digitalmars.com/articles/C-biggest-mistake.html
Feel free to model your work on this and/or on D as you see fit. It'd be great if you made it into an official proposal. That one thing will greatly benefit C programs, much more than any of the other improvements in the C Standard I've seen over the years.
https://en.wikipedia.org/wiki/Logo_(programming_language)
> Apple Logo for the Apple II Plus and Apple Logo Writer for the Apple IIe, developed by Logo Computer Systems, Inc. (LCSI), were the most broadly used and prevalent early implementations of Logo that peaked in the early to mid-1980s.
> Aquarius LOGO was released in 1982 on cartridge by Mattel for the Aquarius home computer.
> Atari Logo was released on cartridge by Atari for the Atari 8-bit family.
> Color Logo was released in 1983 on cartridge (26-2722) and disk (26-2721) by Tandy for the TRS-80 Color Computer.
> Commodore Logo was released, with the subtitle "A Language for Learning", by Commodore Electronics. It was based on MIT Logo and enhanced by Terrapin, Inc. The Commodore 64 version (C64105) was released on diskette in 1983; the Plus/4 version (T263001) was released on cartridge in 1984.[9][10]
And so on.
Magazines are generally much slimmer nowadays. Magazine racks are generally smaller and less ubiquitous. I presume the ad dollars have mostly moved onto the web, and the great majority of magazines have shrunk—many disappearing entirely.
Funny how the prices haven't changed much (seeing a "new computer" for $1,995), given the change in computing power and purchasing power (of the dollar)
There was just a newness and excitement, and the ads show it.
I feel a real romanticism for vintage computing.
Look how much text and detailed discussion there is compared to today's ads. These ads just seem to respect the reader's intellect more.
I still buy magazines for the ads. For example, I buy Mopar Action for the ads that are targeted towards me for things I might want or need for my Dodge. When I open the mag, I want to look at the ads.
This is fundamentally different from guessing what I want to see based on my browsing history. If I open a site on cooking, I don't want to see ads for car parts or kitchen faucets, regardless of my history. I would want to see ads for cooking supplies.
(those might not be the exact terms that were/are used)
Is that not the way it works for you? I mean, I pull up allrecipes.com and see a bunch of food-related stuff like my local supermarket (and one less relevant ad for Iceland Air, no idea). Closer to the subject at hand, the modern "Byte Magazine" might be something like tomshardware.com, where I see lots of tech products being hawked (phones, a tablet, Xfinity service), and ads for the retailers that sell them (lots of Best Buy on the pages I saw).
I mean, sure, there are going to be exceptions. But in general ads on the internet seem at least reasonably relevant.
It really seems sometimes like sites like HN are turning into information bubbles, where concepts like "advertising in the modern world is a dystopian disaster" are... just taken as faith? The experience of regular people doesn't really agree, and it seems like we're becoming more detached as the years go by.
Unrelated garbage. I remember once buying a kitchen faucet, and for months it seems every site I visit showed me ads for faucets.
For example, on a programming site it would keep pushing ads for the Batman movie. Phooey.
I mean, sure, there will always be funny hiccups, and on the edges there are genuine issues of privacy and justice and market fairness to be discussed.
But the idea that we're in some kind of advertising dystopia is simply not the experience of regular users. It's a meme[1] being perpetuated in the tech community. Regular products purchased by regular people are being advertised very effectively, and on the whole with near-universal approval of the customers.
[1] And as mentioned, an increasingly detached and frankly slightly deranged one. Real concerns about privacy are now being short-circuited with nonsense about "But Their Ads", and that's hurting the discourse we actually need.
For myself, I have a really hard time focusing on anything in the presence of visual or audio distraction, with ads just being one example. I wear earmuffs all day while working just so I can focus. The equivalent on the internet is adblock. Without adblock and uBlock origin's element zapper, I simply cannot function on the internet today.
Are you implying that my sensitivity to distracting noise in every aspect of life is somehow influenced by a meme about internet ads?
When, no, advertising is doing what it always has. Internet advertising, broadly, is well-targetted. It just is. (For really obvious reasons! Of all the people who want ad targetting to work most, the advertisers and the ad brokers are at the top of the list!)
Instead, I now run affiliate ads for quality programming books from a list I curated. Ads I would like to see myself when browsing those pages. Ads that probably add value to the page, rather than subtract. No more Batman or C++ training ads.
No, but they ran the same full-page BASF floppy disk ad or whatever at the end of the contents page every month for two years. Repetition in advertising has been a thing since the field was introduced. I can't believe you're only seeing it for the first time now. Even today, go pick up a Motor Trend and compare it to a Car & Driver (or Vogue and Elle, whatever floats your boat) and take a look. They're all running the same ads!
Now, sure, it's true that online ads afford the opportunity to saturate that print doesn't. But it's not any different at all. And it works! Which is why the advertisers (who, let's be clear, know their business a lot better than you do) do it.
There was an earnestness to many ads back then. Either "native" style ads, or price lists -- given researching anything was much more difficult without internet, magazines and print brochures were all you had. Ads were critical.
I get an ad for something I want. I get it. Then I don't need it anymore, but I get the same ad over and over again as if it went from a single thing I wanted to a hoarding obsession.
Then by chance I get an ad for something I want, but I want it later in the year, not today. I click the ad but don't get it.
When I want it, after few months, it is never shown again, and I get dozens of generic unrelated ads instead.
I wish it was actually more tailored to me.
Sometime around the 90s, most advertising gradually shifted to emotional manipulation, which is empirically more effective at scale. The famous iPod ads, for example, said nothing at all about the iPod's technical merits, or how you'd benefit by using an iPod instead of other MP3 players. They just showed some vaguely cool-looking person listening to an iPod.
The "I'm a Mac, I'm a PC" ads depicted PCs as old, uncool dorks; while the Mac is fun and interesting and young. Not a word about any actual features or benefits of the Mac. Purely associative emotional branding.
This actually does work in terms of "selling more iPods at scale," though it is dissatisfying to that small segment of the population that cares about making informed and rational decisions. Most HN readers fall into this category, though there aren't enough of us in the world to carry mass advertising strategies.
From what I recall almost every "I'm a Mac, I'm a PC" ad's premise was a feature or task that the Mac did easier or better, leaving the PC deflated or envious.
Yup.
> ... which is empirically more effective at scale.
I don't think that's the issue. Back in the 80s, stuff came out regularly that was significantly better than the predecessor (if there was one). Emotional manipulation took over when new versions no longer had significant technical advantages over existing competitors.
The same goes for the high fashion in clothing. Doesn't matter if the clothes are the best to wear and most protective and most resilient against wear and tear. Were' in the era of tech-fashion including wearable computing.
I think one reason is that back then, it was the way of keeping in touch with the commercial offering. Now, there are millions of review websites and user groups for that. A quick search can least you to the most niche products easily. As a result, ads just try to sell you stuff you are already aware of, instead of informing you about a new product and its capabilities, making them a lot less interesting.
And even ads about shady products were kind of interesting.
One said, dismissively, "Yeah. Dream on."
Not a real bright guy, as it turned out.
1991: joined Oracle, where they already had a whole style book listing things you could and couldn't do in C, including naming conventions so that your names would port to every one of the 90+ platforms they supported. (spoiler: it was 6-character names, later expanded to 8.)
Nobody wanted to write a new linker for whatever machine they targeted. Finally, GNU made a portable linker and saved the world. It might have been the first to support 32-character symbols, just about enough to link C++ programs without misery.
But if you had code that broke the coding conventions, they could send it back.
I remember being much better at only seeing the content when I was reading magazines like this in the past but I still wouldn't like to return to those times.
Also I think if it was possible to effectively ban all of the modern marketing techniques as many people want now the economic logic would result in paid magazines with content to ads ratio of 30 to 70.
cough much of the current web cough
BYTE differed in its filler being of typically better quality, but Computer Shopper was much, much bigger, and much more popular despite its execrable filler because it had more and better ads.
But I do miss those magazines and times, certainly was a lot more "fun" and interesting than today.
I don't play leading-edge games anymore, so personal computers have been plenty fast for me for years. But I wouldn't mind reading Byte with 50% tasteful, non-creepy ads.
(It is a shame that they make crap now. Back then their equipment was the best.)
Incidentally I think that multi month circulation delays were almost always caused by the International Postal Union rules for Direct Injection of bulk mail at wholesale rates. Very small countries you'd need a minimum of 5,000 items per lot. IPU rules effectively created a hysteresis inflection around global readership acquisition and acquisition costs that pumped advertising price cycles.
And yet, within a year they became commonly available, for DOS and Windows even, thanks to DJGPP. The local schoolsnet added SLIP support, and we could access Delorie's website. While Microsoft and Borland were still charging an arm and a leg, and GNU couldn't be bothered to support non-free systems, it was Delorie who created that bridge to common users and opened the world of C programming to us.
However, with my adoption of an old forth dialect - mstoical and a desire to play with kamby, it's time for me to add a new SSD, and install Ubuntu 22.04 LTS, and get to work knowing this thing I've avoided forever.
Perhaps, eventually, I can port a sane strings library to C, like the one in Free Pascal.
It's amazing how angry some people get when you ask.
Serious question! I want to know.
The importance it attached to feeding mainframes betrays his familial IBM connection (Mom), also the reason Microsoft now rules the world.
I can see why C is preferable to COBOL as the world moved to more commodified OSes and something better than assembly was needed for drivers & kernels, but it would be interesting to know what Pascal "idiosyncrasies" turned people to "portable" C. Any old timers here care to weigh in?
I forgot how powerful being able to address raw memory is with a non-asm language.
But Pascal was unusable without extensions. I mean that. I wrote programs in Pascal.
For example, Wirth's Pascal had no provision for programs that had more than one source file.
Like I say, two weights two measures.
Integrating C with assembly was easy. Pascal originally didn't support that at all. And academics were utterly horrified by things like Turbo Pascal.
The fact that Pascal extensions existed, and Modula-2 as evolution from Pascal was a standard since 1978, doesn't count.
Thus application code often looked like device driver code, maybe you (the application developer) wrote code that wrote to the screen directly or you used libraries that did. By the late 1980s there were text-mode UI frameworks that supported resizable windows, the mouse, and widget sets like you’d use in a GUI application today.
It seems pretty representative of other complaints about Pascal (versus C, in particular, but not always) I've seen from that same time.
This is fundamentally different from the Pascal case where extansions absolutely necessary for the compiler to be useful at all differed radically from one to another.
Kernighan (and P. J. Plaugher) had written a book called "Software Tools". It was supposed to give several reasonably-lengthy examples of software that did actual useful functions. It was written in RATFOR, which is a pre-processor for FORTRAN. Some time later, they re-wrote the book to use Pascal, calling it (predictably enough) "Software Tools In Pascal". After writing it, Kernighan wrote this paper, basically because he was thinking "That should have been way easier than writing the same stuff in RATFOR. Why was that so hard?"
I used Pascal for two years professionally, and many of the issues in the paper I ran into. Pascal was just clumsy to use. It was a good teaching language, but not good for professional programmers in many cases. (C, on the other hand, was written by people trying to write an operating system, and turned out to be a decent language for writing operating systems in.)
Note well: All of this is true of the original Pascal. Things like Turbo Pascal improved it and made it actually a usable language. But even that wasn't portable - there wasn't a Turbo Pascal for anything other than the IBM PC, so far as I recall. And every other "improved" version was different from Turbo Pascal, so there was no portability between extensions either.
For example, there was a Small-C compiler available for the Atari 800 in 1982:
http://www.atarimania.com/utility-atari-400-800-xl-xe-c-65_1...
"... based on the Small C compiler published in Dr. Dobb's Journal"
If you look in the beginning of the manual it has a list of what is and is not supported. They claim it is sufficient to compile C/65 itself but there are lots of things we take for granted missing.
https://books.google.com/books/about/A_Book_on_C.html?id=e5p...
So it is kind of ironic this revisionism how great was C "portability", when in reality it was full of dialects outside UNIX just like the competition.
Except "near" and "far" pointers, which were an absolute plague.
The 1980s C++ compilers on the PC also dominated the C++ compiler use. C++ on the PC vaulted the language from obscurity into the major language it is today.
A while back I chatted with someone who worked on both C and Pascal compilers around that time period and got the impression that the majority of their customers were people running on 68k based Unix workstations. May have just been their niche I suppose.
I didn't start programming until closer to 1990, and started with Mix software's C compiler on a 286, because that's what I could afford.
And if we go into the Amiga it was about Assembly and AMOS mostly.
On Apple, Object Pascal and Assembly, HyperCard, MPW with C++ came later into the pictures.
On thing I do agree, by the time Windows and OS/2 were taking off, C++ on the PC was everywhere and only masochistics would insist in using C instead of C++ frameworks like OWL, MFC or CSet++.
Sadly I never saw it anywhere on sale, as the graphical debugging for C++ data structures was quite cool to read about.
Then Slackware came out on CD!
There was a z80 version of Turbo Pascal that ran on CP/M machines (incidentally, one thing that’s striking about the first several years of BYTE is how many huge Cromenco ads there are) as well as the Apple II with a Z80 card. That, along with x86 support, covered a lot of ground.
Some things that come from the -11:
1. post increment and decrement
2. integer promotion rules
3. floating point promotion rules
3. `register` storage class
"This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1."
I also remember there were library functions with variable # of elements, but you could not write them (variable arg functions) yourself. Really hated that.
Not all of these were fair criticisms, but they were enough to switch for me.
And of course, who can forget the wonderful adds for the games from Infocom (Zork et al), who would "stick their graphics where the sun don't shine!". They were text based games, and very succesful on those days
Unfortunately I didn't learn the language well enough to ever use it.