131–140 of 170 posts
Earlier quoted context omitted.
What do you mean non-joke? How can you tell? How is this a joke, and how is that not a joke?! What makes the distinction?
Have you looked at the source code? It’s obvious.
Earlier quoted context omitted.
Replace `write(..)` with `puts("y")` and you'll be an order of magnitude faster. This is due to `puts` (`printf` too) being buffered (data isn't written to term/file immediately but retained in memory until some point). Improving this process (as seen in the reddit thread) gets GNU-yes.
It's line buffered when it prints to terminal.
> • yes-rs-2 (rewritten with different dependencies)
> • yes-rs-ng (Angular-inspired architecture)
> • yes-oxide (WebAssembly-first approach)
> • yep (minimalist reimplementation)
Earlier quoted context omitted.
That reddit thread has some amazing benchmarks. The GNU-yes $ yes | pv > /dev/null ... [10.2GiB/s] ... The way I (not a C programmer) would have written it void main() { while(write(1, "y\n", 2)); // 1 is stdout } $ gcc yes.c -o yes $ ./yes | pv > /dev/null ... [6.21 MiB/s] ...
If you compile your variant with -O3 I imagine it will be much faster? Iirc, the default is for GCC is to not optimise
Earlier quoted context omitted.
What a waste of 8 bytes! :)
It’s not about bytes, it’s about duplicating logic that should inherently be the same. If you change something about the loop or the puts , you now have to take care to change it identically in two places to be consistent. That’s a situation that should be avoided, and is what makes it not “as simple as it gets”.
In 99% of cases, yes of course you’re right, factor this loop.
In this specific case? This is trivial code, that will likely _never_ change. If it does change, it’s extremely unlikely that the two loops would accidentally diverge (the dev would likely not miss one branch, tests would catch it, reviewers would catch it). So if you get any upside by keeping the two loops, it might be worth it.
Here you get 8 bytes back. I honestly can’t see how that would ever matter, but hey it’s _something_, and of course this is a very old program that was running on memory-constrained machines.
So it’s a trade-off of (minor) readability versus (minor) runtime optimisation. I think it’s the better choice (although it’s very minor).
Or maybe there’s a better reason they chose this pattern… can’t imagine the compiler would generate worse code, but maybe it did back in the days?
Earlier quoted context omitted.
I don't believe puts is performing unbuffered I/O though. It's a libc function, not a direct syscall. Correct me if I'm wrong of course
The write(2) libc function is just a C wrapper for the syscall. It's the functions from stdio.h that are buffered.
Earlier quoted context omitted.
Actually a joke doesn't necessarily needs to be funny, and depending on the framing not even humor. Gregory Bateson's "A Theory of Play and Fantasy" (in Steps to an Ecology of Mind) (1972): Bateson argues that certain communicative acts signal themselves as "play" or "non-literal." A joke is such an act—structured and marked by "metacommunicative" cues, indicating that it should not be taken at face value. Regardless…
Joking aside, this is Marvin Minsky's paper "Jokes and their Relation to the Cognitive Unconscious", published in Cognitive Constraints on Communication, Vaina and Hintikka (eds.) Reidel, 1981. More fun than a barrel of an infinite number of monkeys. https://web.media.mit.edu/~minsky/papers/jokes.cognitive.txt >Abstract: Freud's theory of jokes explains how they overcome the mental "censors" that make it hard for us…
And jokes can be a construct without being humor as well.
Earlier quoted context omitted.
It’s not about bytes, it’s about duplicating logic that should inherently be the same. If you change something about the loop or the puts , you now have to take care to change it identically in two places to be consistent. That’s a situation that should be avoided, and is what makes it not “as simple as it gets”.
I was being humorous, but tbh it’s not so clear cut! In 99% of cases, yes of course you’re right, factor this loop. In this specific case? This is trivial code, that will likely _never_ change. If it does change, it’s extremely unlikely that the two loops would accidentally diverge (the dev would likely not miss one branch, tests would catch it, reviewers would catch it). So if you get any upside by keeping the two l…
If you consistently deduplicate code that is supposed to do the same and evolve the same, then any duplicated code sticks out as a statement of “this isn’t the same”, and in the present case it then makes you wonder what is supposed to be different about both cases. In other words, such code casts doubt on one’s own understanding, raising the question whether one might be overlooking an important conceptual reason for why the code is being kept duplicated. So in that sense I disagree that the duplicated version is more readable, because it immediately raises unanswered questions.
About possible performance reasons, those need an explanatory comment, exactly for the above reason. And also, if performance reasons warrant complicating the code, then it isn’t “as simple as it gets” any more. I was commenting because I disagreed with that latter characterization.