The stylistic elements on their own wouldn't raise an eyebrow if they appeared rarely among many other stylistic devices in order to enhance drama, suspense or emphasis, but within a single completion, Claude will sometimes implement just these two several times to express the most banal things. It ends up looking like a caricature of the worst pre-LLM Medium and LinkedIn garbage.

I mention it because it's immediately off-putting even though the project itself sounds fun enough. It tarnishes it with the impression that maybe you just don't care, but maybe you just aren't attuned to the style and its strong slop connotations.

I'm genuinely fascinated by the problem and I've wondered what in the training process causes the model to develop this peculiar style of writing. Is it because it's trained on old Medium slop? Someone else replied with a link to their SSH-based VPS, where the copy is absolutely saturated with the same annoying style.

I know some people use OPNsense or pfSense for their router and firewall needs, which are both based on FreeBSD.

The sort of place we're actually in is one where astronomical sums of money have been invested in this technology, creating an unprecedented incentive to hype and overstate its fundamental capabilities. They're large language models and their analyses are based on language statistics, not logic, comprehension and knowledge, all of which they are fundamentally incapable of, and all of which are fundamental to reasoning. They don't reason in the literal sense that planes fly.

I don't doubt that there could be a reasoning machine, but LLMs are not it.

> and how likely is that to fail anyway (at least I never had the canonical C hello-world fail on me).

I don't expect to know how likely writing to stdout is to fail and I don't think any answer to that question other than 0 really warrants ignoring the potential error if the correct result of invoking your program depends on it. For what it's worth, at least in Unix-likes, stdout could be pretty much anything. Writing to stdout could fail because a switch at the user's ISP is rebooting.

The C Programming Language includes a Hello World example that calls printf without checking the return value and returns a success code from the main function regardless.

The first example I find when googling "java hello world" simply calls System.out.println and neglects to call System.out.checkError to see if it was successful before exiting with a success code. Some Java developers won't even know what I'm talking about here because it has never occurred to them that printing may fail in a way that can only be discovered through this weird checking mechanism.

Go's example from their getting started guide simply calls fmt.Println while ignoring the return values which include any error that may have occurred, and the program exits with a success code regardless.

The example from Rust by Example is at least correct and thorough in that it will predictably panic upon error when invoking the println! macro, which is documented, but will through that mechanism not give you the option to actually handle the error except by using a different mechanism which front-loads more of the complexity (e.g. writeln!(io::stdout(), "Hello World")? for something equivalent to the Zig example).

Of course for something as basic as Hello World it might be easy to tell whether it was successful through a quick glance at the output, but consider some of these limitations in a larger program.

So maybe there is more inherent complexity to this problem than a typical Hello World implementation will reveal. Add to that the complexity of Zig's new swappable I/O models and their Hello World isn't so absurd.

An averaging filter makes sense if you have a noisy analog input. For a button input that registers whether it is pressed or not except for a known noise around transitions specifically, ignoring the transitions immediately after the first one registered is not only faster (both in terms of latency and CPU cost) but easier to implement. It's also equally practical for switches with long bounce, where the time it would take for an average to favor a transition might be impractically long.

It's also an open source project, so the end product is as much the codebase as it is the binary releases.

I've interacted enough with largely computer generated codebases to see that ergonomics problems easily grow and accumulate when LLMs remove the burden of dealing with those problems from the developer. I've always considered my laziness an asset. Now I would qualify that by saying that laziness is an asset for as long as it compels you to keep things simple and easily understandable so that the cost of making changes (whether that's measured in human gray hairs or tokens) doesn't grow with every change.

Zig and Rust have addressed the problem of how the result of a block expression should be presented, but neither solution seems particularly satisfying to me.

In Rust, blocks may end with an expression, giving them a non-void result. But a block may also end in a statement, the only difference being that the statement ends in a semicolon, in which case the expression still has the void result, and I think that semicolon being the only difference makes it hard to scan at a glance where values come from.

In Zig, blocks may give non-void results by `break`ing out of them with an expression. But break normally ignores blocks and break out of loops only, so to break out of blocks you have to provide a label for it and give that when you break so as to break out of the named block and not the outer loop, e.g. `const x = label: { break :label 35; }`. That creates a problem of one of the most difficult classes in software engineering: naming things. Ideally I think `break` from a block should have its own keyword, e.g. `const x = { give 35; }`

You suggest adding it as a "bonus", but for whom? Recording what on the walk? How would you advertise that along the main feature people actually buy the thing for? If not, what purpose does it serve? It's a few cents, but that's still a few cents too much if that's not what you're convincing people to buy.

Try to think of someone who didn't buy a walkman because it lacked a recording feature. What's their story? Can that easily be represented in the marketing material?

There are some positive side effects to this, which is probably the reason we're so tolerant of their presence.