I imagine that if/if-else as expressions and then necessarily their bodies as expressions would entail a much more fundamental change to the language. You then have to think of a way for the bodies to indicate a result. That, or you have to make a special case for if/else sequences where the bodies are bare expressions, in which case you've just invented the ternary operator.

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; }`

I can't imagine that making the differences between the languages more subtle would improve the performance of chatbots. Subtleties aren't their strong suit.

The original claim was that "at eight they have limited comprehension of the world around them and limited language skills" and that they can't conduct debate is a relevant example of that.

By sheer irony, it would also suggest that the original poster had limited language comprehension skills and wasn't capable of evaluating an eight year old.

Deciding on a product design that's easily marketable is also a marketing problem.

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?

This thread reminded me of Blaise Pascal's quip "I would have written a shorter letter, but did not have the time."

It's often easier to just throw in everything that's easy to do with little thought about cohesiveness or user experience. Leaving the record feature out of the walkman was likely a more difficult idea to push than including it and I think they were right.

Exactly this. You wouldn’t make a dictaphone and then be like, shall we just tout good speakers in it just in case someone wants to also listen to their music on it. So why the other way around.

Not seeing the forest for the trees

They seem attracted to sliced bread in plastic bags here in the Nordics. They attach to the end of the bag so as to seal and hold it closed, regardless of the labeling on the bag.

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

Chatbots enable unskilled developers to go in way out of their depth with little resistance. This creates problems of a new nature, not just more problems of the same nature as before.

Previously in my career, a junior making a mistake and being told why it was a mistake would learn from that and improve. The junior-chatbot duo will not. The junior will feed my comment into the chatbot, and the chatbot will superficially give the impression of having learned from the mistake and fix the code while introducing the same problem somewhere else, and the junior will have learned nothing.

This all requires that I review code as though it was created by some kind of cursed monkey's paw with an endless number of fingers that each grants a wish of the operator with a devastating caveat through idiotic interpretation.

If you give a toddler who can otherwise not operate a chainsaw -- for the simple reason that they don't have the strength to start it using the starter rope -- access to a robot who will turn on the chainsaw for them on command, you've created a problem which didn't exist before.

I understand that unskilled people are creating problems for themselves and others; but that doesn't interest me. I interpret everything from the point of view of the AI being used by skilled people.

Such as the claim "AI demands more engineering discipline, not less" ... of skilled people, not irrelevant unskilled people.

Unskilled people are not irrelevant if you intend on working with other people, in which case you will need to deal with them in one way or another.

I will probably be dealing with them in the future more than in the past because chatbots bypass the process by which unskilled people generally become skilled people.

Suppose I don't use AI, but have to work with people who are using it. Is AI demanding more/less engineering discipline of me?

I don't know anything about you, but I told you my experience a couple of messages back, which you effectively decided not to respond to.

I guess that the perceived problem from a security perspective is that they're there, not that they're necessarily hard to fix once found.

The main beef is the noise created around these disclosures instead of sending patches to fix the bugs.

If you quietly patch the vulnerable software it's unlikely that I will ever hear about the vulnerability. CVE disclosure is important because that's how I learn of security problems in software I critically depend on. It's not merely a service to the maintainers, but to the users who might otherwise critically depend on vulnerable software.

Did you bother to read the resulting translation?

Yup, translated it back through Google and double checked it wasn’t giving me horseshit.

So this is is intended to smooth over the poor work, bad commit hygiene and bad commit messages of "agents", presumably not meaning just any agent but LLM-based ones specifically.

I can already see the change. What I need to know is why, not how exactly. It should be clear from a commit message why a change was made. If it's not, that problem should be addressed during review. I shouldn't have to watch a recap of your conversation with a virtual idiot to understand your commit. If the tools you use to generate code can't be coaxed into producing that level of quality, or if you don't understand the output of your generative tools to the extent that you can describe for someone else why they made a particular change, you have a tooling and competency problem.

If further tooling can solve these problems, then I'm all for it, but the idea here seems to be to not solve that problem, but to burden anyone interrogating the history of a repository with also scrolling through chat histories so that virtual idiots can keep shitting out low-quality changes and so that operators can keep accepting those changes as-is without thinking too much about why.

I guess it doesn't help that tools like GitHub don't really care about commit messages. You can't even comment directly on commit messages during review.