Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Universal I/O Abstraction for C++ (2020)

cor3ntin.github.io

Post reply on HN
Print view View original

21–30 of 88 posts

Re: A Universal I/O Abstraction for C++ (2020)

#21

Post by titzer »

linkdd wrote: post #10
pjmlp wrote: post #9

Earlier quoted context omitted.

Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.

This kind of comments are forgetting all the good that C did bring in the last 50 years of computer history. Too bad those shitty engineers in the 70s didn't think of Rust...

No one can seriously argue that C's language design was inherently advantageous over, say, Pascal. If Lisp, ML, Simula, Algol, or Ada received the amount of optimization and porting investment that C did, history would be very different.

C succeeded because a.) Unix, and b.) there were a zillion platforms with a zillion different compilers that could process something like C. They all did weird things and you couldn't actually write portable code for decades, but you could kind of fake it.

Re: A Universal I/O Abstraction for C++ (2020)

#22

Post by titzer »

rualca wrote: post #14
jabl wrote: post #12

Earlier quoted context omitted.

> Too bad those shitty engineers in the 70s didn't think of Rust... True, Rust didn't exist back then, and yes, some (few!) features in Rust weren't invented and worked out then, like the ownership model. OTOH the corollary to that statement isn't that C was some shining beacon of good design taking advantage of the then state of the art programming language knowledge. See e.g. https://pastebin.com/UAQaWuWG

That pastebin leaves out the fact that C's spartan approach and extreme simplicity allowed C to become the most popular programming language in the world already in the time of K&R, a book still renowned for it's clarity and low mental baggage required to onboard onto a programming language. The pastebin also left out that Bjarne Stroustrup developed C with classes, and the C, as a backward compatible superset of C t…

C was not extremely simple. Lisp was extremely simple.

Re: A Universal I/O Abstraction for C++ (2020)

#23

Post by flukus »

xjay wrote: post #19
pjmlp wrote: post #9

Earlier quoted context omitted.

Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.

The late pioneer in compiler optimization--Frances Allen--agrees. 2006: "..but something else had happened--and that was back in 1973--[something] which I was very, very unhappy about--and that was the advent of C! It derailed, as far as I was concerned, the advances that I foresaw in compilers. One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data-…

> One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally."

Well 50 years on we still haven't seen any of these "sufficiently smart compilers", at best they can outsmart C compilers in a few cases with things like generics, so the idea that higher level languages would be faster has been wrong for at least 5 decades. At least you can forgive them for thinking they would 50 years ago, but now it's just ignoring 50 years of reality.

Re: A Universal I/O Abstraction for C++ (2020)

#24

Post by agumonkey »

linkdd wrote: post #10
pjmlp wrote: post #9

Earlier quoted context omitted.

Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.

This kind of comments are forgetting all the good that C did bring in the last 50 years of computer history. Too bad those shitty engineers in the 70s didn't think of Rust...

Actually I'd bet a dollar or two that linear threading of resources existed even before C, it just wasn't neither a common practice nor a theoretical framework at the time.

Re: A Universal I/O Abstraction for C++ (2020)

#25

Post by Koshkin »

jfrd wrote: post #7

Too bad C++ is the most terrible thing since forever. https://twitter.com/Cor3ntin/status/1383875999033565194?s=20

I happen to disagree, C++ is the best thing after sliced bread. (Just wanted to balance the conversation, really, with an equally meaningless, albeit honest, statement.)

Re: A Universal I/O Abstraction for C++ (2020)

#26

Post by flukus »

Back when the "Law of Leaky Abstractions" was first coined such things were given as examples: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

> Even though network libraries like NFS and SMB let you treat files on remote machines “as if” they were local, sometimes the connection becomes very slow or goes down, and the file stops acting like it was local, and as a programmer you have to write code to deal with this. The abstraction of “remote file is the same as local file” leaks.

Re: A Universal I/O Abstraction for C++ (2020)

#27

Post by Koshkin »

pjmlp wrote: post #9
jfrd wrote: post #7

Too bad C++ is the most terrible thing since forever. https://twitter.com/Cor3ntin/status/1383875999033565194?s=20

Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.

Have been programming in C (and then C++), like, forever. Hardly any memory corruption issues. Yes, you have to be a little more disciplined and pay attention to things. Being distracted certainly does not help.

Re: A Universal I/O Abstraction for C++ (2020)

#28

Post by Koshkin »

titzer wrote: post #22
rualca wrote: post #14

Earlier quoted context omitted.

That pastebin leaves out the fact that C's spartan approach and extreme simplicity allowed C to become the most popular programming language in the world already in the time of K&R, a book still renowned for it's clarity and low mental baggage required to onboard onto a programming language. The pastebin also left out that Bjarne Stroustrup developed C with classes, and the C, as a backward compatible superset of C t…

C was not extremely simple. Lisp was extremely simple.

Problem was, real world programming in Lisp was not simple.

Re: A Universal I/O Abstraction for C++ (2020)

#29

Post by Koshkin »

jabl wrote: post #12
linkdd wrote: post #10

Earlier quoted context omitted.

This kind of comments are forgetting all the good that C did bring in the last 50 years of computer history. Too bad those shitty engineers in the 70s didn't think of Rust...

> Too bad those shitty engineers in the 70s didn't think of Rust... True, Rust didn't exist back then, and yes, some (few!) features in Rust weren't invented and worked out then, like the ownership model. OTOH the corollary to that statement isn't that C was some shining beacon of good design taking advantage of the then state of the art programming language knowledge. See e.g. https://pastebin.com/UAQaWuWG

Actually, computer science in general and the theory of programming languages in particular were already very advanced back in the 60s. It’s just people thought little of languages that would have needed gigabytes of memory (or days of run time) for the compiler to do its job.

Re: A Universal I/O Abstraction for C++ (2020)

#30

Post by MaxBarraclough »

Koshkin wrote: post #27
pjmlp wrote: post #9

Earlier quoted context omitted.

Nah, that place I leave for C, the number one reason we keep having memory corruption issues during the last 50 years of computer history, and having taited every language that has some level of compatibility with it.

Have been programming in C (and then C++), like, forever. Hardly any memory corruption issues. Yes, you have to be a little more disciplined and pay attention to things. Being distracted certainly does not help.

A significant fraction of major security vulnerabilities in C/C++ codebases relate to memory-management bugs.
Post reply on HN