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

Post by pjmlp » Mon, Apr 19, 2021, 5:18 AM UTC

miohtama wrote: post #13

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...

They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers. Instead, the burden of ensuring correctness had to be left as the cognitive burden for the developer for decades to come.

Post by pjmlp » Mon, Apr 19, 2021, 5:21 AM UTC

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.

Post by jabl » Mon, Apr 19, 2021, 6:27 AM UTC

Koshkin wrote: post #29

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

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.

Post by jabl » Mon, Apr 19, 2021, 6:34 AM UTC

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…

Post by jcelerier » Mon, Apr 19, 2021, 6:59 AM UTC

gpderetta wrote: post #8

jcelerier wrote: post #2

In the end the overall design looks like a semi-reified asynchronous dataflow programming API based on coroutines. I think that it would be useful to consider the existing (very very very large) body of research on dataflow PL and APIs; e.g. check this paper from 1982 which talks about dataflow, coroutines, for handling file operations: - https://scholarship.claremont.edu/cgi/viewcontent.cgi?articl... More recent pap…

Hum, in principle you can do arbitrary compile time transformations to the datagraph before submitting it via metaprogramming. If you really want you could even convert the graph (fully or partially) to a runtime representation. The core of the proposals are not about specific classes or functions other than some default algorithm implementations. Instead they are mostly about defining concepts and protocols so that…

    while(i) {
        co_await sch.schedule(std::chrono::milliseconds(100));
        co_await w.write(--i);
    }