Hacker News Reader

Comment by pjmlp | Hacker News Reader

Finally C catches up with Algol 60 boolean types, it only took 60 years.

Maybe in another 60 it will get proper strings and arrays.

C has had a true Boolean type for over 20 years now, since C99. This time around they're merely dumping the backwards-compatible _Bool/_True/_False syntax + keyword-like #defines in <stdbool.h>, and replacing it all with proper keywords.

That said, it would be nice if C caught up with Algol 68, seeing how that's the one many of the concepts (and the corresponding keywords) are taken from. Let's start with first-class functions...

That was a kludge.

How?

It was a syntactic kludge, perhaps, but it had good reasons - and in terms of expressive power, it's exactly the same as any other Boolean type.

I wonder what other string could have C used 50 years ago that would have stayed usable for that long.

I love that, thanks to C, plenty of old programs can still be used today. In these days of accelerated bit-rot and language "communities", and perpetual rewrite of everything over and over again, C stability and ubiquity is a safe harbor, and has been at least until now a good investment.

I have no idea what you mean by "proper arrays". I guess bound checks?

Just like JOVIAL or FORTRAN from 1950's, you get to know their size at any time, and yes bounds checking.

Can you still write a function that accept arrays of any size, then?

C must be really amazing compared to Algol than. It powers today's computing infrastructure without having proper boolean type. Are there any widely used applications written in Algol?

UNIX free beer, hard to beat.

You do realize there is a lot of C code out there which has nothing to do with UNIX. Although I do remember when you once claimed C requires UNIX like OS to run. :)

Well, UNIX is surely responsible for C becoming popular (if not its being a thing in the first place).

I'm not arguing that it is not? It's funny though how many people saw value in C but not in Algol. Maybe C has something going for it?

Free beer alongside a free beer OS, instead of paying thousands of dollars for timesharing OSes like VMS.

I know you keep repeating it. You are conveniently ignoring plenty of other commercial OSs and languages which were successful.

Who, except for people too young to know better, saw value in C but not in Algol? The Bell Labs folks obviously thought enough of Algol such that C is a descendant in the family of Algol-like languages. Algol was widely used in Europe whereas in the U.S. we made do with Fortran, Cobol, and, I think to a lesser extent, PL/I, although the latter had many Algol-like features at the time. (And Fortran evolved to have many of those features; I suppose Cobol also, but I'm not familiar with its post-1981 history.)

Taking a contrarian view to everyone else in this thread, I don't think Unix rocketed C to stardom - Turbo C did. Turbo Pascal was very very popular for PC programming and was eventually supplanted by Turbo C and Turbo C++. Without Turbo C, I think C would have probably become just another niche language used on a niche OS, Unix.

And in line with what you say in another comment, commercial OSes -- including VMS -- were very powerful and much more popular than Unix. In 1982, a single VAX 11/780 running VMS with 4 and 8 MB of RAM could support 10s of programmers editing, compiling, debugging, and testing code. VMS was also a real-time operating system that we used in production to control/monitor/perform-I/O hardware devices handling LANDSAT image data. And Unix is still trying to figure out async I/O ... (Most of my career has been spent on Unix, but I appreciate other operating systems I've worked on as well.)

I have nothing against Algol. Turbo Pascal was my first language (i agree with you about Turbo C). I loved it at the time. But C is different. The same way Lisp is different. It is just one of those languages which have a very simple core idea which is also very powerful at the same time.

Lisp has the code-data duality (everything is a list) going for it and C has everything is pointer to a block of memory and that's it. That block can be a device register, data structure, array of sth. or just about anything you can imagine. This idea enables you some kind of proto-polymorphism without the verbosity and chains of higher level languages (at the cost of safety of course). That is the beauty of C and unlike Lisp it is also lot closer to the metal, which helped a lot with performance.

I think it's normal to be jaded when something objectively superior is being replaced with something simpler. But that doesn't mean the simpler thing is without merit. The world has more dimensions, the technical aspect is just one of it.

No, everything is not a pointer in C; C is based on value types that are passed around by copy (with the exception of arrays and functions). An variable of a given type designates a piece of storage which contains that value, rather than a pointer to it.

C is not significantly different from Algol or Pascal. The difference between C and Algol is a lot smaller than between either of those and Lisp or ML.

What's missing in some Algol-like languages compared to C is the loose pointer arithmetic, and possibly type punning via pointer conversions. Those features allow C programmers to do things like write their own memory allocator, which is incredibly useful in embedded systems. A C project can produce a self-contained image that boots on bare metal, with minimum assembly language. Or on almost bare metal, where there is a boot loader program that provides no services to the C program other than jumping to its entry point and maybe some console printing routines or something.

You have completely misunderstood my comment about why C stands out. I though it was obvious from the example I gave, what I meant, when I said everything is a pointer to something?

As an embedded developer in previous life, I can assure you C is not special because it can run on bare metal. Many other languages can too.

UNIX is to C like the Web is to JavaScript.

JavaScript also runs outside of the browser nowadays, so what.

I don't know what are you trying to say? How does this follow from the parent post?

It follows that the Web made JavaScript unavoidable, then nodejs made it available everywhere else.

Likewise UNIX made C unavoidable in systems programming for timesharing servers, eventually like JavaScript outgrew the browser, certain people wanted to run C in their microcomputers.

I don't disagree with you on C being popular because of UNIX. I do disagree if you believe this is the only reason why it still enjoys popularity. And you are selling the UNIX authors short if you think they chose C just for the fun of it.

The UNIX authors didn't choose C; they made it, specifically to make UNIX. And, much like the original UNIX itself, it was a hack - because they were trying to make do within the limits of their hardware. So, some of the syntax is the way it is because it was simpler to parse, for example. And some of the semantics was originally "because PDP does that".

As for why C has staying power, that's solely a function of its early success. There's nothing about the language itself that isn't better provided for by some of its historic competitors (e.g. Modula-2). But there's a self-reinforcing loop here, where all new hardware platforms start with C as a basis because it lets you write all the existing code; and conversely, using C is the way to ensure that your code will work even on future platforms.

You're hung up on words. I know they made it. It was based of Ken Thomson's B. They chose it, when they could have taken some other existing language. I see great beauty and simplicity in C the same way I see it e.g. in Lisp or Javascript for that matter. I dabbled in Modula-2 and it does not offer the same feeling in my opinion. The core features of C are very powerful and simple at the same time, which is the reason it stayed popular. People writing low level code understand that.

The core features of Modula-2 are largely the same as C + modules, but with more consistent syntax and fewer footguns (like no unsafe implicit pointer conversions), so I don't see how C can objectively possess "great beauty and simplicity" in comparison. Unless you're referring specifically to the syntax?

B was also written as a hack - it was basically a minimal subset of BCPL small enough to fit in the memory of the machines they were working with. B is elegant in a sense that it's a very simple language for a word-oriented architecture - but that's exactly the part that they had to get rid of for C to target byte-oriented ones. Coincidentally, it's also one of the sources of weirdness in C syntax (e.g. implicit int and K&R prototypes are all legacy of B).

Claiming something is not beautiful because it is "hacky" on HN is a bit unexpected.

For me this is beautiful:

https://briancallahan.net/blog/20220220.html

I'm sure it's just a hack to you, but you can't do that in Pascal.

I mostly like C because of what I wrote here: https://news.ycombinator.com/item?id=30404529

"Hacked together" can mean different things. In this case, it means something slapped together on short notice with limited resources. Such things rarely tend to be beautiful. Beautiful hacks absolutely exist, but they are never hacked together in this sense.

The only thing your blog post demonstrates is that C has a built-in textual macro facility. But if you wanted the same in Pascal, you could have it just the same, by running it through the C preprocessor; or better yet, something more powerful like M4. Of course, you'd have to deal with various impedance mismatches, such as the fact that the definition of "token" is different between the preprocessor and the compiler - but that's also true of C! In fact, this discrepancy alone is quite sufficient to deem C inelegant, in my opinion.

The Burroughs MCP operating system and some applications written on top of that. In fact, I believe that was the very first OS to be written entirely in a high-level language.

MCP is not today widely used in the same way, say, React or Linux is, but businesses used and depend on it such that it's still sold and supported, as Unisys ClearPath MCP.

I’ve heard that Burroughs had an absolutely world class engineering team in their heyday.

Cool, I will definitely look it up.

Then it would become Algol, wouldn't it?

So many features still missing.

It's no fun writing code without switch variables, goto-labels as arguments to procedures, and call-by-name.

Algol 60 pales and laughs nervously in the shadow of the Algol 68 giant and its type system towering over it.

I mean, C++ doesn't have "proper" strings, so I wouldn't wait up for C getting them.

I see them on the ISO C++ standard document, maybe your copy is missing pages.

>Maybe in another 60 it will get proper strings and arrays.

If you think this is missing, there's a big chance you don't "get" C.

Also, if you don't know how to properly emulate strings in a safe way in C nowadays (for which plenty of code sample and librariesexist), your skills with the language are quite poor.

I surely get C, having to deal with its casualties in DevSecOps.

I have been "getting" C since 1992, across Xenix, DG/UX, HP-UX, Solaris, AIX, FreeBSD, Linux, Amiga, Windows 3.x,.....

Well, then, you must know it's not really a big deal to write code with proper memory checks.

If you think that, then you really don't get C - not as in "it's intents", but as in its actual history and repurcursions...

I have found yet another C expert.

https://www.cvedetails.com/vulnerability-list/opmemc-1/memor...

It's a big deal, you need about 1/3 of sel4 proofs

You once claimed C requires UNIX like OS to run.

And he was right. He didn't mean it as a statement of fact (which would be wrong, and he already knew it).

No he was definitely wrong. Ask any C developer.

His comment: https://news.ycombinator.com/item?id=20828974

When I complain C's portability sucks, because it can't do anything useful without a ton of ifdefs, people tell me it's not a problem, I should just use POSIX.

https://twitter.com/rygorous/status/1224413742667988992

I claim it yet again on this very comment.

Without UNIX spreading with its free beer into universities, C would have been a footnote on the history of system programming languages.

Nope in the above comment you claim something else.

Here is where you claim C requires UNIX like OS:

https://news.ycombinator.com/item?id=20828974

Let me tell you, in embedded development we run C on bare metal or under RTOS. There is no UNIX in sight. And the code is portable to many CPU architectures.

A snowflake RTOS without POSIX, call me amazed.

I'm happy you learned something.

Not really, still waiting for the name of such marvelous OS.

Keil RTOS. You can also use C on bare metal without an OS. I hope you won't claim next that CPU's are UNIX like OSs.

Much more importantly, without UNIX and free beer TCP/IP there's a fair chance the Internet isn't the Network and none of this (gestures at HN and the Web) happens. That's a much bigger impact than C which is just a programming language, even if you count the influence of NUL-terminated strings, and all the semi-colon languages (including even Javascript and Rust, which are very different from C but preserve the enthusiasm for semi-colons) the Internet as Network makes more difference.

In particular it's possible X.25 could have won. JANET (the tertiary education network in the United Kingdom) was exclusively doing X.25 until 1991, when it tries an experiment offering IP. Unsurprisingly free beer TCP/IP offers a cornucopia of interesting new toys and sites are very enthusiastic about JIPS (the experimental IP service) so that by 1992 the IP service is no longer an experiment but the primary service, with X.25 maintained only until 1997.

You do get the Network anyway of course, that's what everything is leading up to after Shannon, but you probably get an X.25 flavoured Network instead of the Internet, or some other system coming from another direction, and broad deployment might have been delayed into the early 21st century rather than the 1990s depending on exactly how things work out. Stallman's GNU project doesn't happen, Tim's toy hypermedia system either doesn't exist or is a small inconsequential experiment largely unknown outside hypermedia fanatics, and Linus Torvalds probably doesn't make an operating system kernel for his 386 microcomputer. It's a very different environment, C is small potatoes by comparison.

So? I could deal with such alternative universe, after all, between 1986 and 1994, I managed to work with computers and networking just fine.

Adding so-called fat pointers to C that could be bounds checked would probably instantly eliminate a large fraction of all security issues.

Of course, you can emulate these yourself, it's just a struct but not everyone does.

Adding opaque builtin struct types to C would be kind of a big deal though and would probably creep into other parts of the language and interact with them in unexpected ways. Features like fat pointers, slices, builtin dynamic arrays/strings or tagged unions would all require builtin opaque structs. This would be a whole different language (closer to Zig).

It really wouldn't be that hard to do. The syntax would be trivial, and the whole point is that you want it to creep so people actually use them.

There's no overhead to doing it, but you save a bunch of bugs earlier, all for stopping conflating arrays with pointers, which is something not much code does these days anyway

C99 introduced variable-length array parameters and variable-length array pointers together with variable-length arrays (VLA). These take another parameter or variable as a length-parameter. These became optional in C11 together with VLAs (for some reason) but are supposed to again become mandatory in C23. However (yet, for some reason) the pointers can (in the latest published draft, still) only be inside procedures: not in structs or in global variables.

I think it would not be impossible for a C compiler to detect and produce a warning if an index used with such an array-pointer is not checked against the array-pointer's length variable.

This would not make bounds-checks automatic, but the use of these types could make compilers point out when bounds are not checked or checked incorrectly.

People don't really get the distinction you make here, which is a shame. Often any VLA's are outlawed which is tossing the baby out with the bathwater.

Compilers can already do this:

https://godbolt.org/z/jMMa8n48r

Yes, putting them into structs is a missing feature. It is not in the draft because no compiler can do it and their is no implementation experience. I am working on it.

Reply on news.ycombinator.com