5 ms·

I firmly believe that teaching how to idiomatically do both character and line oriented file IO should be the first thing any language tutorial teaches, almost.

by TylerE 3y ago

I firmly believe that teaching how to idiomatically do both character and line oriented file IO should be the first thing any language tutorial teaches, almost. Just as soon as you’ve introduced enough syntax.

PoignardAzur 3y ago
FWIW, the Epitech cursus starts your very first C programming lesson by making you write a "my_putchar" function that does a "write" syscall with a single character. Then you spend the next few days learning how to create my_putnbr, my_putstr, etc, using that single building block. I think that's the right choice, by the way. Baby developers don't need to learn efficient I/O, they need to learn how you make the pile of sand do smart things. And if you've spent weeks doing I/O one syscall per character, getting to the point you write hundreds of lines that way, the moment some classmate shows you that you can 100x your program's performance by batching I/O gets burned in your memory forever, in a way "I'm doing it because the manual said so" doesn't.
- TylerE 3y ago
  I said idiomatic because that’s the form they’re going to encounter it in the wild, in library doc, in stack overflow answers. I do t think rhe sort of low level bit banging you propose is a worthwhile use of a students time, given the vast amount they have to learn that won’t be immediately obsolete.
  - samatman 3y ago
    I firmly disagree with this. We're talking about learning C, not learning an arbitrary programming language. The course of study the GP comment suggests teaches syscalls, pipes, buffering, and most important, it teaches mechanical sympathy. All of which are things a C programmer needs to understand. More programming tasks than you might imagine are low-level bit banging, and C remains the language of choice for doing them. It might be Zig one day, and if so, the same sort of deep-end dive into low-level detail will remain a good way to approach such a language. Far from becoming "rapidly obsolete", learning in this style will prevent this sort of mistake for years into the future: https://news.ycombinator.com/item?id=39766130 https://news.ycombinator.com/item?id=39766130
    - TylerE 3y ago
      “we” are certainly not talking about C. I never mentioned C, nor any language. This was intentional.
- mcguire 3y ago
  This is similar to the presentation in Software Tools, IIRC.
everforward 3y ago
I would argue that they should be teaching how file IO works at a low level at some point (preferably as one of the first "complicated" bits). Everybody should, at some early point, interact with basic file descriptors and see how they map to syscalls. Preferably including building their own character and line oriented abstractions on top of that, so they can see how they work. I'm convinced that IO is in the same category as parallelism; most devs understand it poorly at best, and the ones who do understand it are worth their weight in gold.
- TylerE 3y ago
  I do not think the typical language tutorial is well served by trying to teach a condensed version of all of CS.
  - everforward 3y ago
    I don't think they need to teach all of CS; I would agree your average language tutorial probably doesn't need a chapter on tree traversal or transitive closures or whatever. I do think they should all teach IO, though. If I could only pick 1 part of a language to understand really, really well it would be IO. The vast majority of apps spend the vast majority of their productive time on IO. Your average CRUD app is almost entirely IO. The user sends IO to the app, the app send IO to the database, the database does IO to get the results and then the IO propagates back up. The only part that isn't basically pure IO is transforming and marshalling the DB records into API responses. If you you add parallelism, that's like 98% of what most apps do. Parallel IO dominates most apps.
- WalterBright 3y ago
  I beat benchmark after benchmark in 80s on disk I/O. I was amazed that nobody else figured out what my compiler was doing - using a 16K buffer for the floppy drive rather than 512 bytes.
  - pixl97 3y ago
    Heh, wasn't 16k most of the memory in the machine? Large buffers do have other interesting and fun side effects, though back then you probably didn't have any threads or any/many of the things buffers cause these days.
WalterBright 3y ago
The FORTRAN-10 manual was not a tutorial, it was a specification.

by TylerE 3y ago

PoignardAzur 3y ago

FWIW, the Epitech cursus starts your very first C programming lesson by making you write a "my_putchar" function that does a "write" syscall with a single character. Then you spend the next few days learning how to create my_putnbr, my_putstr, etc, using that single building block. I think that's the right choice, by the way. Baby developers don't need to learn efficient I/O, they need to learn how you make the pile of sand do smart things. And if you've spent weeks doing I/O one syscall per character, getting to the point you write hundreds of lines that way, the moment some classmate shows you that you can 100x your program's performance by batching I/O gets burned in your memory forever, in a way "I'm doing it because the manual said so" doesn't.

TylerE 3y ago
I said idiomatic because that’s the form they’re going to encounter it in the wild, in library doc, in stack overflow answers. I do t think rhe sort of low level bit banging you propose is a worthwhile use of a students time, given the vast amount they have to learn that won’t be immediately obsolete.
- samatman 3y ago
  I firmly disagree with this. We're talking about learning C, not learning an arbitrary programming language. The course of study the GP comment suggests teaches syscalls, pipes, buffering, and most important, it teaches mechanical sympathy. All of which are things a C programmer needs to understand. More programming tasks than you might imagine are low-level bit banging, and C remains the language of choice for doing them. It might be Zig one day, and if so, the same sort of deep-end dive into low-level detail will remain a good way to approach such a language. Far from becoming "rapidly obsolete", learning in this style will prevent this sort of mistake for years into the future: https://news.ycombinator.com/item?id=39766130 https://news.ycombinator.com/item?id=39766130
  - TylerE 3y ago
    “we” are certainly not talking about C. I never mentioned C, nor any language. This was intentional.
mcguire 3y ago
This is similar to the presentation in Software Tools, IIRC.

everforward 3y ago

I would argue that they should be teaching how file IO works at a low level at some point (preferably as one of the first "complicated" bits). Everybody should, at some early point, interact with basic file descriptors and see how they map to syscalls. Preferably including building their own character and line oriented abstractions on top of that, so they can see how they work. I'm convinced that IO is in the same category as parallelism; most devs understand it poorly at best, and the ones who do understand it are worth their weight in gold.

TylerE 3y ago
I do not think the typical language tutorial is well served by trying to teach a condensed version of all of CS.
- everforward 3y ago
  I don't think they need to teach all of CS; I would agree your average language tutorial probably doesn't need a chapter on tree traversal or transitive closures or whatever. I do think they should all teach IO, though. If I could only pick 1 part of a language to understand really, really well it would be IO. The vast majority of apps spend the vast majority of their productive time on IO. Your average CRUD app is almost entirely IO. The user sends IO to the app, the app send IO to the database, the database does IO to get the results and then the IO propagates back up. The only part that isn't basically pure IO is transforming and marshalling the DB records into API responses. If you you add parallelism, that's like 98% of what most apps do. Parallel IO dominates most apps.
WalterBright 3y ago
I beat benchmark after benchmark in 80s on disk I/O. I was amazed that nobody else figured out what my compiler was doing - using a 16K buffer for the floppy drive rather than 512 bytes.
- pixl97 3y ago
  Heh, wasn't 16k most of the memory in the machine? Large buffers do have other interesting and fun side effects, though back then you probably didn't have any threads or any/many of the things buffers cause these days.

WalterBright 3y ago

The FORTRAN-10 manual was not a tutorial, it was a specification.