https://www.youtube.com/watch?v=oKg1hTOQXoY

He mentions how Xerox PARC machines with tagged architectures from the 80s were only 1/50 the speed of the x86 systems in '97. This, in contrast to the 50000x increase in computing power over the same time frame.

https://www.smecc.org/The%20Architecture%20%20of%20the%20Bur...

http://homes.cs.washington.edu/~levy/capabook/

Bitsavers and Wikipedia are good resources. The summaries of most on Wikipedia are accurate enough with references to get more authorative information on. I found a lot of it that way.

<rant> Please, stop pushing this wrong rethoric forward! As soon as there is undefined behavior, it's a bug in the code. There is a problem, and the problem is on the developer's side. I appreciate the effort of compilers to help me get the most performant machine code I can, and I've had enough of people asking them to stop being smart in order to accomodate crappy code. </rant>

In my experience, this is the right thing to do for most applications. Every time a program (ex: compiler) tries to guess what its user (ex: developer) meant, instead of just sticking to the input, there will be problems. In particular, you may help some users in some cases, but you'll prevent other users to get what they have the right to have.

> ... seems far less productive ...

And maybe it is, but it's not a compiler's business. Use automatic tools, write your own tools, decide coding convention, impose code reviews, but please let the compiler do what it is supposed to do and how it has learned to do in decades of evolution.

That's one approach to fixing errors, but there's another: tell the programmer that there's an error, and let them decide the best way to fix it. As you say, unsupervised "DWIM" is problematic, and so is a computer program that trusts its inputs absolutely.

> And maybe it is, but it's not a compiler's business.

What exactly isn't a compiler's business? Helping the programmer write a program that solves their problem? I would say that that is 100% of the compiler's job. It might be that part of the problem is "absolute performance", but that is almost always a secondary concern to correctness... computing the wrong answer (or pwning the user's data) is suboptimal, no matter how fast it happens. C defaults to exploiting everything for performance, rather than defaulting to correctness while also providing opt-in ("dangerous") tools for performance that one can use when necessary.

Yes, every time a C program relies on undefined behavior, it's a bug. And as djb observed, virtually all non-trivial C programs contain these bugs. This is the core of my argument.

Yes, we could rely on C programmers never making mistakes. But it would be better to design languages with no undefined behavior.

I do get a facial tick when people say "all significant C programs use (or contain) UB." It's never been necessary and it's always been shameful.

I think the emphasis on the original comment should be on the silent part. Nobody is arguing that these aren't bugs in the code; the problem is that you get no help from the compiler or runtime to find them and the damage is more severe than it would be if it simply crashed.

I think I see your point, but you are wrong when you write "simply". Crashing in case of UB is not simple! Actually, ensuring any type of behavior in case of UB is not simple! It requires huge lots of runtime checks, thus you obtain a ridden executable as output. If you want your program to be cuddled in a safe baby box (which is the right thing to want in several cases), then go for an interpreted language, but please let "gcc -O3 -march=..." be what it is: a masterwork coated with magic.

There are exceptions to every rule, of course, but we need to re-evaluate our priorities as times change.

The sad part is that they already existed since 1961 actually, long before C was born, but then some startups decided to base their workstation OSes on UNIX and got successful selling them.

For an idea of what it would take to make C actually secure (and even then only in so much as you reasonably can) take a look at all the things Rust has had to do. Nearly everything that exists in Rust is there because they started with a C feature and asked themselves "what do we need to change to make this safe/secure?". Most other languages as a minimal first step towards improving security remove direct access to pointers, they're simply too powerful to do securely in the manner C does. Rust has (mostly) secure pointers, but only after putting an insane amount of work into bolting a massively complicated ownership and lifetime tracking system on top of it, and even then it's still not perfectly secure since they had to include unsafe blocks to provide a trap door for certain edge cases (also for C interop).

So yes, you could make a secure C compiler, it just wouldn't compile C code anymore, it would compile some "safe" subset of C which would probably end up looking like either Rust or C# (or maybe ObjectiveC).

Your compiler could track those ints used as pointers all the way throughout the whole program and prevent out of bound values either at compile time or at runtime for compatibility. There is nothing fundamental about C that makes it incompatible with memory safety.

I just don't believe you for one minute. It's quite easy to guard against unwanted memory access over serial ports and sockets. You have to know the size of the buffer, but that's just not hard.

If you go throwing pointers-as-if-they-were-tokens/handles around and blindly following them, you'll get in trouble.

So don't do that.

If you constrain operation only to valid data ( which isn't all that difficult ) then ( and I ask out of ignorance ), how can they hurt you?

What do I mean by "constrain operation..." yadda yadda? I mean if somebody "misspells" something, you dump the input. Your recognizer accepts only valid tokens. Usually, the tokens are in a table, with an FSM knitting them together.

So the table can be wrong, or the FSM can be wrong. That's it. Recently, all commands were in a simple subset of XML ( by the customer's choice ). That was particularly easy.

I grew up in environmentally hostile environments where you'd lose things like PHY chips and serial port drivers, so this was how it was done.

If you mean exploits in the O/S itself, then yeah - I agree. But then my choice of language is irrelevant.

I won't disagree about the C compiler thing, but that shouldn't be at issue here.

The author demonstrated this by pointing to a list of CVEs caused by their code, so.

But as hard as I tried, I still failed, because I relied on 3rd-party code (by an extremely talented programmer), and he made mistakes. Perfection is not a scalable strategy.

You do have choices to make in terms of techniques and tools you can apply (assuming you're aware of them) to modify the statistics, but you will not be perfect in your application of them, and the tools were not written by perfect people either.

There's another choice here - how high you set the security bar for "deals with hostile data off the network". Ekidd chose to set this bar high enough to rule out C. How high do you set it?

[1] https://www.quora.com/What-reasons-are-there-to-not-use-Go-p...

[2] https://plus.google.com/+nialldouglas/posts/AXFJRSM8u2t

We've had plenty of replacements waiting. C developers are just hyper committed to that language. Even though its inventors moved onto a Wirth-like language.

You'll even start writing code which relies on integer overflow (rollover from #$ff to #$00 again) because, depending on the situation, it will give you a performance boost, or make the algorithm implementation simpler, or both, and you'll know it.

It's long past time to invent and use better systems languages.

I can't comment on Go, but the textbook examples of Rust and even treatises on the subject from recognized experts in the computer science field (Adam Leventhal) show it to be an utterly overcomplicated language for which there should be a criminal trial and a prison sentence of several decades. Immutables, borrowing, no, I have to stop; my head hurts already, and I'm getting a migraine thinking about solving even the simplest of classic input-output problems with such an overly complicated language. (And my head wants to explode when I compare Rust with AWK for solving input/output problems, the biggest reason why computers were invented.)

So... C, C, and more C, because it's infinitely flexible and simple. I like simple, because simple is smart. Complicated and complex isn't.

Let's all please be humane to one another and stop inventing more languages. We need less languages, not a bazillion variations on the one central task: making the computer do something. And for that, we already have all the languages we could ever want or need, and for the theoretical case where we don't, there is always the almighty assembler, in which exist no limitations as to what one can program with it.

Knowing how processors work doesn't prevent people from making mistakes.

I knew assembly long before I knew C, because I grew up on computers that were too small to run a C compiler. I've contributed to a half-dozen compilers. I've written disassemblers for weird embedded DSP chips. And by the standards of C programmers, I'm pretty paranoid.

None of this makes me superhuman. I make mistakes. I've written network-facing C code, and I've left people exposed to security holes. Want to see the carnage?

https://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc...

That's 6 CVEs against an obscure C networking library that I wrote. Technically, none of them were found in my code (not yet). All were in the third-party XML parser that I chose to use. But that doesn't absolve me of fault, and I bet there's a few more bugs lurking in my code that could be found with modern fuzzers.

I don't care whether people use Go or Swift or D or Rust or some brand new language. But wherever C goes, bugs and security holes almost inevitably follow. It's going to take decades to reduce the proportion of C in our systems, and we ought to start now.

While it is commendable that you take responsibility, you mis-diagnosed your error: it isn't the C programming language, but what you chose to do with it: send/receive extensible markup language for remote procedure calls. Seems like a great idea, until you actually have to deal with it. I just happen to be working on an application where I'm forced to generate XML-SOAP and send that over the network to a server, and then process the XML-SOAP response I get back with XPATH, using xsltproc. And all that because the designers of the server application use Java and didn't even know they were using XML-SOAP and XPATH, since by the time they work with it, Java libraries treat them as objects. (And neither did I, until I reverse-engineered the responses I'm getting.) I have caused the server to crash innumerable amount of times.

You're arguing for better systems languages, and I'm telling you that is a terrible idea because we have nobody so smart as to design something so complex to be simple, and the closest we have ever come to it is C. We already have way too many languages, that it's become a nauseating torture to work with computers.

... exactly.

- don't use XML for anything;

- use the correct tool for the job, but first define the problem better. What was XML-RPC attempting to solve?

That's an excellent question! To answer it, we need to rewind to the year 1998. Nobody had ever heard of JSON (2002) or REST (2000) or SOAP. If you wanted to do remote procedure calls, you needed to use Sun RPC or Corba or another binary RPC stack. Some of these required tens of thousands of lines of C code to implement, and I don't even want to think about the security issues.

Basically, XML-RPC was trying to be REST+JSON before that was a thing. It had already been implemented for most scripting languages, but one of my consulting clients needed a C implementation to interoperate, so I wrote xmlrpc-c in a couple of busy weeks around the end of 2000, I think.

Back in those days, XML had a very clear 30 page spec and XML-RPC had a 2 page spec. If you want to argue that I was wrong to use C to implement 32 pages of pretty good specs, or that I was wrong to use the best off-the-shelf XML parser of the day, well, I agree. But I think we need to demand more from our system languages.

But people had heard of S-expressions, which are far more appropriate for data transfer than XML.

And the canonical S-expression spec, from 1997, is rather less than 30 pages: http://people.csail.mit.edu/rivest/Sexp.txt

Then you add the inefficiencies of XML encoding, and the utterly crappy nature of most XML translation layers . . . yeah, really easy to see the train wreck coming.

If C isn't up to implementing an only slightly complicated network protocol, it's not much of a systems programming language, is it?

It turns out, C is fine for writing such systems and getting them working fairly well, but very poor at making them really reliable and secure, and that's no longer a good tradeoff.

He considers that a positive feature, not a bad thing. You're the inverse.

I can see both sides of that tbh. It's a justifiable - but myopically idealistic - point.

But man he's being a pretentious ass about it.

If C is that bad at managing complexity (and complexity doesn't only arise from bad design choices, some problems are inherently complex) then it should be used as rarely as possible, period.

It's not about idealism, it's about ill-placed, almost comical elitism ("C is a low-level-hacker language and only real programmers use it" while a 3rd grader could understand pointer arithmetic) to the point of rather spending 5 days writing bug-ridden code in C instead of 5 minutes in whatever else, just because it's the right way.

It's ridiculous.

This, in my opinion, is why even if C were somehow free of buffer/integer overflow, UAF, and other vulnerabilities, it would still be a poor choice for many real-world (read: complex) applications.

Bingo, give the man a prize! As we say on UNIX: C gives one enough rope to hang oneself. It is expected one knows what one is doing, but in return, one gets complete control and infinite flexibility. No programming language can compensate for bad architectural decisions, or an absence of such decisions, or absence of insight. Such a programming language does not yet exist, and it is questionable whether it ever will. So yeah, you got exactly what I was trying to say.

Now, back to C: nobody, including me, has all the solutions, but from experience, I have some tips when writing C code:

run the damn thing you're building through a debugger; feed it all kinds of garbage while doing so; try to break it in every way, shape, or form you can think of. As the author of the program, one should have unique and powerful insights into where the weak points are. And after all of that is done and fixed, have someone completely unrelated to it try to break it. This last piece of advice is good for any language.

I have a friend. I'd beat the daylights out of my programs, break them every which way, fix all the bugs I could find, then I'd let him have at it. He'd usually break my program in 15 - 25 seconds. Then the cycle would repeat, until he could no longer break anything. At that point, we had something remotely resembling stable software. And a lot of those programs I had him break weren't even written in C!

One of the best techniques I found while developing in both assembler and C: run the program you're working on through the debugger as you're writing it. As soon as I write a new function, I fire up a debugger (or shell tracing, or...) One wouldn't believe how many bugs I've found and fixed before the program saw the light of day. And it saves so much time, even though that's completely counter-intuitive.

This just made me laugh. I'm not making a value judgement about your statement, I neither agree nor disagree.

There were "too many languages" before C was even conceived of. If that were a reason to not use new languages, you'd never even have heard of C.

Any more than five becomes counterproductive and destructive, because it's physically impossible to keep up with all of the new languages coming out, and no language solves all the problems simply and efficiently. Or elegantly, for that matter.

In my experience, it takes about ten years of heavy use to master a programming language and use it not only to its fullest extent, but correctly and efficiently as well. I would be interested to meet a person who has that kind of time, biologically.

If that were a reason to not use new languages, you'd never even have heard of C.

Back in my day, the number of computer platforms was pragmatically limited: either you wrote software for the Commodore Amiga, or you wrote software for the Atari ST. If you were a software company, you wrote for both. If you were a programmer with lots of experience, you split the core from the hardware dependent subroutines, but I don't think anyone thought about this very UNIX-specific approach to programming back then (most of us had never heard of UNIX). We all wrote software in assembler, and were just lucky enough that both major platforms had the exact same processor family, the Motorola 68000. The C programming language was a solution to a problem nobody had or asked for. I remember making fun of my mathematics teacher and berating him for writing programs in C, because compared to assembler, it was lame: bloated and slow. It was impossible to code something of any significant speed and small enough size in C on either Atari ST or the Amiga. We viewed C as something lamers who couldn't figure out assembler dabbled with. One just couldn't compete in C with code written in assembler, which effectively meant that if you didn't code in assembler, and your code wasn't small or fast enough, or both, you weren't competitive, and the lamer label was soon to follow.

Times have changed, C is now the portable assembler, but they have changed only somewhat. When push comes to shove, understanding what happens at the hardware level is still crucial when performance problems strike... and they strike a lot. Most importantly, understanding how the hardware functions at the lowest level is most important when writing in really high level languages. The higher the language abstractions, more crucial understanding of how low level hardware functions becomes.

Nowadays, when I have multple incompatible processors to deal with, completely different hardware architectures, and plenty of raw processing power, C is a very viable, even desirable choice: if I write my code cleanly enough, it will just compile and run everywhere without modification, and I'm done, but back then...

...C was the answer to a question nobody asked or cared for in the personal / home computer space in those days. If one couldn't figure out assembler, one dabbled in GFA-BASIC or C, or Pascal. It was a very elitist, eat or be eaten environment. If one's code was too large or too slow, one became the public laughing stock of the scene. It was a very effective, and highly motivating selection measure. I miss those days.

The level of contempt for other people and utter lack of perspective shown by this comment makes my head want to explode.

> no more overflows, no more pointer screwups, no more forgetting to free the memory, because you'll know exactly what will happen in the chip and the memory when that code compiles

To whoever wrote this: are you ready to share the code of a sufficiently complex program in C (or assembler, why not) you wrote and pay $100 for every "pointer screwup", buffer overflow, memory leak and generally every bug people find, which could have been prevented by a strong type system or borrow checking and other such complicated features?

You sure are angry with me for working on a programming language.

1. Creating something non-trivial in language X, 2. Identifying things that language X made difficult, 3. Brainstorming ways to implement solutions to those issues within a set of acceptable trade-offs, 4. Concluding that some of the brainstormed ideas might actually work, 5. Working really hard to implement and iterate on them.

I can't figure out which step the parent commenter scorns. I guess probably step 2, where they see no pain points to begin with. That's fine, but trying to convince people they haven't felt pain that they have felt is a silly battle. I guess they're actually implying that people who have felt that pain are just not smart enough.

And the worst part of it is, no such language covers all problems effectively; they all have flaws in one way or another... so the next guy comes along thinking he can do it better, and just repeats the mistake of his or her predecessor(s).

Instead of realizing that this would just exacerbate the problem, they go ahead and make it worse.

I guess they're actually implying that people who have felt that pain are just not smart enough.

It is extremely difficult to solve a complex problem in a simple manner. One literally has to be a genius with a lifetime of experience and insights from that experience in order to be able to pull that off, and even then, it doesn't always work and requires multiple iterations, and lots and lots of experimentation. Case in point: Go, still a work in progress by exactly such people. That should be instructive, but it seems that it isn't.

Which is exactly why you don't try to create a language that covers all problems effectively, you define the problems you'd like to speak to. If you have defined those problems in such a way that they are shared by many people, and if you solve those problems in a way that many people find effective, then you may have created a compelling solution. How does that exacerbate "the problem"?

Honestly, what even is "the problem"? Why does it bother you that there are new languages created? The "literal geniuses" from the Bell Labs era experimented a ton, and that was a great thing then, and remains a great thing now. It's always valuable to point people to prior art, but it makes no sense to bemoan research and experimentation.

The problem is that new languages have such fatal flaws, that they make the problems they are trying to solve even worse.

The second, and much more serious problem, is that it takes at least ten years to truly master a programming language. Humans only live about 70 years on the average, which means that it is impossible to keep up with every new language that comes out. I mean I live for this stuff, but I would literally have to be chained to the computer my entire life without time for anything else. That is nonsense.

Anybody who thinks they have mastered a computer language in less than ten years is either a genius, or unbelievably egotistical and arrogant; and knowing a whole bunch of computer languages in a perfunctory manner, enough to make one dangerous leads to a really shitty job of sorting out that mess afterwards... that's the problem. My problem, and likely other people's problem.

What I don't understand about your position is its absolutism. You keep talking about people being egotistical and arrogant, but it seems like you're the only one on this thread being those things, by claiming your subjective opinion as objective fact, and then making ridiculous hyperbolic statements about throwing people in jail based on it. It's not a contradiction for you to personally dislike a language's philosophy and for that language to have been a worthwhile creation and valuable to many people.

Your feelings about different languages are just, like, your opinion man.

Just wait until you invest ten years of your life to master a language, only for everyone else to move on to the next new trend, with you stuck holding the bag.

AngularJS, Rust, and node.js, is it? I can't wait to ask you how you're feeling about all that time you invested into all of those, when all the kids move on to something else and they're no longer popular, for no reason other than the newcomers' ignorance, or because something shinier came along, but didn't actually add any value, just re-implemented the old thing in a worse way.

We can then have a discussion about how you're feeling, having wasted a decade or more of your life away on what will then be perceived irrelevant. That's of course under the (optimistic) assumption that HN is still going to be popular in ten years...

The fathers of C created AWK as C on steriods, and even though they were a success in this endeavor, they were wise enough to create it as a domain specific, and not a general purpose language. If you study their works afterwards, up to Go, they always developed domain specific minilanguages, and always split the difficult problems into many small programs, hence Plan 9. This is very instructive in the context of their previous achievements. They even recommend to solve problems by creating a domain specific minilanguage, but only when this is appropriate to the problem at hand.

Now fast forward to Go. These guys really know what they're doing, and still Go is a research project, unlike Rust, they're not trying to actively sell it to the populace at large, because they know just how difficult it is to create a good systems programming language. So yeah, you bet your patootie I'm angry at anyone who thinks they can do it better. It's not even that they screw it up, that's part of learning and gaining insight, but that they actually actively attempt to sell it as a good solution. Meanwhile, it's even more complicated than the previous solution! And then let's suppose someone invests about a decade to master that new language, such as it is: by that time a pile of other people come along thinking that they know it better and invent their own languages; sometimes they invent a new language just because they think it should have a different syntax, as was the case with Ruby, in the author's own words! Unbelievably arrogant! And now that becomes the new hotness. Congratulations, you just wasted a decade of your life on something that's not in fashion any more. That would be no problem if we lived for 500 to a 1,000 years, or if we were immortal, but we only have this one life, and the length of our life is a blip in the universe. So it turned out to be a huge waste of time. That's the part that really angers me.

.. for the specific chip you've targeted. And possibly even the specific stepping.

And that's assuming that you're diligent enough to manually review all that assembler. Very, very few people are. This is why typesafe code was developed. This is why all those checks exist in Rust. Limitations are good. Limitations are your safety equipment. Assembler is the guy who scrambles up on the roof without tether or hardhat to "get the job done".

> language for which there should be a criminal trial and a prison sentence of several decades

Commentators who overuse hyperbole should be executed.

I used to write a lot of C, and I no longer use it for anything serious either, because I'm too stupid and the stakes are higher. Maybe better tool support could change that, but I'd prefer a better language.

No you won't. Assembly is an abstraction now, at least on x86.

The chip does all sorts of things in ucode behind the scenes