> A bad employee loses money until a manager notices. A bad agent loses money at machine speed, around the clock, on every channel at once, and files a beautiful report about it.
> When banks are asked to finance businesses that are run in part by agents, what proof will they accept? A dashboard? A screenshot? A performance report written by the same agent that spent the money? No underwriter on earth should accept that. Eventually none will.
Good, that's exactly what we need. People believe Big AI companies way too much. We need loud, widely-published stories of AI agents making horrible decisions and wrapping them in beautifully-formatted reports, so that a layman working with AI knows it will lie with the straight face, and even that smart-looking, cleanly formatted report might have a completely incorrect content.
I assume OP refers to the cases where "while" is used to re-implement existing operations... imagine finding code like this:
i = 0
while i != len(todo):
process(todo[i])
i = i + 1
sure, there may be a good reason to implement things this way (maybe "todo" grows during iteration?), but maybe not, and then the loop should be instead simplified to:
for value in todo:
process(value)
(as an aside, this is exactly the case where the comments are required: "# not using for loop because todo might grow" will make it clear it's an intentional decision and not hallucination or something written from ignorance)
todo_iter = iter(todo)
while True:
try:
value = next(todo_iter)
except StopIteration:
break
process(value)
or like that?
todo_iter = iter(todo) # Note: assume "todo" does not contain None
while value := next(todo_iter, None):
process(value)
I'd say neither of those are as clean as a simple for loop:
for value in todo:
process(value)
and yes, that's the case of a personal preference, although I'd bet a lot of Python programmers will share that preference with me. That's what "code smell" means, after all - it's not a bug which is clearly incorrect, it's a code which is best avoided based on reviewer's personal experience.
Your for loop is using an iterator of some kind. Just because it’s hidden in your language of choice doesn’t mean it’s not there.
While/for can achieve the same thing, sometimes while is more practical as the steps to complete are unknown. But sure, stick your simple iterating a fixed collection as why it demonstrates while is a lesser language feature.
I think your arguments would be much stronger with some actual code samples.
Usually, when the same code can be written either as range-based "for" or as a "while", the "for" will look better and have fewer possibility of bugs. If you have examples otherwise, I'd like to see them.
(Note I am specifically talking about range-based/iterator-based "for", not the C's variant. Nor am I talking the cases where the "for" is hard to use, like when the size might change at runtime)
The most urgent needs in frontend web dev were components and state management.
Vue and React won out, and I still don't see that changing for the foreseeable future on the vast majority of corporate web apps. This remaining split is just coke vs pepsi. Basically, a meaningless distinction and stable.
I don't doubt there will always be new tools, but a lot of HN doesn't see the forest for the trees when it comes to web. So many people chime in ignorantly just to be bullies and spread FUD and self-promote. I think that strategy not going to work again for a while. Everyone is very burned out on that overplayed game in all aspects of life, not just web dev.
If anyone is interested in frontend dev, LLMs only further entrench this situation. Now is the time to be creative with mature tools and learn a thing or two. The web summer is upon us, not an autumn of dying tools nor a winter of AI replacing people.
> The US doesn’t pre-approve vehicle designs. Automakers self-certify that their vehicles comply with all applicable Federal Motor Vehicle Safety Standards, and NHTSA checks after the fact.
huh, did not expect this. I wonder how many vehicles currently on road would fail those checks if the NHTSA started to pay close attention?
Like most federal regulations, there's enough poorly worded or vaguely written requirements that any investigator could find a way to fail every vehicle ever made.
Without the standards it would be difficult to hold automakers liable for defects in design or workmanship, so the standards are more useful as a means to hold automakers responsible for safety failings than they are at internal developing the optimal safe design.
The more specific they get, the more difficult it is for automakers to implement new safety technologies. For example, the safety standards were too specific about headlight design, so we ended up making headlights extremely bright all of the time in the US, for years after other countries were using adaptive headlights that dim in areas with lights and other vehicles, and brighten in dark areas.
At least in Python, I've found that "reduce" is very rarely needed. Most of the times, "sum" is enough, sometimes with "start" values customized (set it to [] to flatten an array for example). It is both easier to read, faster, and needs no imports. It also works great with list comprehensions - "sum(foo(x) for x in input if x > 5)" is much easier to read than reduce equivalent.
If you are multiplying, you are likely doing heavy math, and you'll be using numpy - which does not need reduce either.
If you are going to return a list of dict, then it's much faster to mutate the results, so using "reduce" will have significant performance implications (unless you want to return input argument, mis-using it as a glorified "for" loop)
And if returning not a list/dict, if you can use "min" or "max" or "any" or "all" or "next" (take the first element), then you should use it - it will be easier to read and faster too.
So what does this leave us for "reduce"? Frankly, not much. I've only seen it in merging immutable status codes, and that was pretty niche usecase to begin with.
(this was all for Python. In other languages without nice list of built-ins reduce might make more sense)
Has the performance of sum on lists of lists in Python been fixed? It used to be pretty abysmal. But I suppose some would say that if you need to consider performance at all, you’re in the wrong language… :)
Python 3.13.5 (main, Jul 15 2026, 20:25:40) [GCC 14.2.0] on linux
>>> x = [[n]*1000 for n in range(1000)]; import timeit, itertools, functools, operator
>>> timeit.timeit("len(list(sum(x, [])))", number=10, globals=globals())
13.009033881127834
>>> timeit.timeit("len(list(list(functools.reduce(operator.add, x, []))))", number=10, globals=globals())
12.941937348805368
>>> timeit.timeit("len(list(itertools.chain.from_iterable(x)))", number=10, globals=globals())
0.0706032607704401
>>> timeit.timeit("out=[]; [out.extend(i) for i in x]; len(out)", number=10, globals=globals())
0.06334403157234192
>>> timeit.timeit("len([i for a in x for i in a])", number=10, globals=globals())
0.1232151910662651
mutable is fastest, itertools is just a bit slower, list comprehension is 2x slower, both "sum(..., [])" and "reduce" are 200 times slower!
For numerical code I like einops.reduce more than numpy/pytorch sum reductions because you can reduce over named dimensions. It’s much more readable than having to reason through axis indexing again every time you come back to the code
Either "already" or "not any time soon", depending on how you count.
Already - because you have VMs and backwards compatibility. As long as you keep using Intel x86_64, your apps would run, no emulation needed. Or you can use the VM.
Not any time soon - because the computers are not speeding up that fast. 10 year old computers are still being used today, and even the latest CPUs are not orders of magnitude faster. So for a full-system emulation, the most well-known ones is x86 VM's on Apple Silicon, and according to reports, full-system mode is still not close to regular PCs.
true, but the question was about "my currently running system (anno 2016)" - which means intel core most likely. And at that generation, there requirements for precise timing is extremely rare, it's mostly PCI/PCIe devices and they can be shared with VMs just fine.
In the most common git setups, you never force-push to master - so a coworker can't rewrite history of master branch. Forges have protection rules, but even if your hosting does not, then the "git pull" will throw a ton of errors after history rewrites. So both fossil and git are similar in that regards.
On the other hand, unpushed branches can be rewritten any time in git.. but this applies to fossil as well. If you have not pushed your fossil changes, it's just a file on disk - you can delete it without pushing and no one will ever know you had intermediate version. Or work in "git" and only export to fossil (or svn or cvs or whatever) once things work.
This was CVS/SVN approach, and that's the reason git won so quickly (no, it was not github like some people claimed, I've seen git become popular in my circle before github was a thing)
I am not sure if you used CSV/SVN before - I did. It maintained the history of what was done in a very immutable way. The branches were heavy-weight and were only used for Serious Business, we generally had a person responsible for branching/merging. You only committed stuff which was in great shape and passed all the tests, just like Fossil wants you now.
And there were manual source code copying, so much copying.
- You are writing a feature and got interrupted mid-work to work on something else - copy/tar those files and restore from svn (you could also do a second checkout, but that destroys your cache).
- Want to send incomplete changes to friend? run "diff" and send them the patch by email, or place that patch file on shared disk.
- Your check-in failed, you need to merge in in latest changes from master? better tar up your work in case you break stuff.
- Are you doing new feature and want to see if refactor will improve it? don't forget to make a copy of changed files in case it does not.
None of this is worth committing on master. Who would want to share an incomplete feature which does not build / does not pass unit tests? Or an pre-refactor version of code which does not work?
Turns out using "git" covers all those usecases, and that's why it's the greatest thing. Fun fact: we've started using git in our team using git-svn, without central git server - we had mutable and shareable commits until the last moment, when we pushed it to central svn server.
IMHO, if you only want to record the final path code takes, and you plan to use "cp", "tar" and "patch" for throw-away work, then you might as well use a "releases" directory on FTP with timestamped archives. Why bother with VCS then?
What happens if you make a mistake while committing - maybe forget the file, or commit wrong one?
Fossil has no way to fix it, by design, and I find it an absolute showstopper. I do stupid mistakes all the time, and I am so glad that gits lets me fix those.
"Fossil purposely makes it difficult for users to delete content."
Those operations are explicitly declared special, not something you do many times per day because you had a typo in your print statement. I guess technically you can do it often, but the tooling does not make it easy at all, and you are going against program's recommended best practices.
> What happens if you make a mistake while committing - maybe forget the file, or commit wrong one?
Then you have proven that you are human.
> Fossil has no way to fix it, by design,
As an 18-year-long contributor to fossil i can assure you that this is absolutely not true. Fossil can amend any checkin and it can move checkins to other branches. Go to sqlite.org/src/timeline?r=mistake to see many examples of where human failing has been both demonstrated and accounted for without breaking anything.
14 "mistakes" in the entire 2025. I am probably making that many per week? Not to mention committing the intentionally broken stuff, with the expectation that I'll come back and amend if I decided it should go to main.
> When banks are asked to finance businesses that are run in part by agents, what proof will they accept? A dashboard? A screenshot? A performance report written by the same agent that spent the money? No underwriter on earth should accept that. Eventually none will.
Good, that's exactly what we need. People believe Big AI companies way too much. We need loud, widely-published stories of AI agents making horrible decisions and wrapping them in beautifully-formatted reports, so that a layman working with AI knows it will lie with the straight face, and even that smart-looking, cleanly formatted report might have a completely incorrect content.
reply