Sometimes the answer to "why?" is that the dev had a hammer and the codebase was starting to look an awful lot like a nail. In-memory cache isn't considered as a serious option nearly enough imho.
I'm very happy about this. The fact that Temporal forces you to actually deal with the inherent complexities of time management (primarily the distinction between an instant and a calendar datetime) makes it incredibly difficult to make the mistakes that Date almost seems designed to cause. It's a bit more verbose, but I'll take writing a handful of extra characters over being called at 3AM to fix a DST related bug any day of the week.
Agreed. We've almost eradicated our usage of JS Date - fixing plenty of bugs along the way, and then I extracted thousands of lines of conversions and formatting from our production app (scheduling focused) into a temporal-fun package to make it Temporal more ergonomic for lots of common cases.
Word of warning Temporal relies on the Intl API for formatting, and support in Chrome is very limited due to their binary size constraints. As a result, you'll need to polyfill unsupported languages using format.js
No, because if I want something to happen everyday at 12 o'clock, I have to wait for one day, if I wait for 24 hours, I will be off by an hour for half of the year.
You seem to assume that a day always has 24 hours. Common (but not only) non-24h day lengths are:
- 23 hours
- 25 hours
- 24 hours 1 second
- 23 hours 59 minutes 59 seconds
You could assume that a day isn't exactly 24 hours, but it's close-ish to 24 hours. Nope, not even close.
And that assumes that we can treat an hour as a precise measure of time (we can't). On some systems, even a second is not a precise measure of time (second smearing).
To make things worse, those are "simple" edge cases.
Time is hard. I'm not sure if I can make any statement about time that is true.
I am saying that you shouldn't use day as a unit of time. You should use second, minute, hour, etc, because these have a constant duration. sleep(86400) should reliably make your thread sleep for at least 24 hours.
It depends on the context and the system you’re working with. In some systems, an hour may last 3599, 3600 or 3601 seconds (due to the leap second), a minute may be 59,60 or 61 seconds. Even a second is not always a „true” second.
There’s no single time unit that works for all situations.
Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan.
Ramadan is observed from one visual sighting of a crescent moon to the next.
Cloud conditions may prevent sighting and thereby alter the official start of Ramadan for an individual location, and from time-to-time, the start of a country's change in timezone.
> Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan.
Only Morocco does this, I believe, and it's not even clear that that's actually official time at this point. In 2018, Morocco abolished DST, but it seems unclear what that means in practice.
I'd love it if someone from Morocco could weigh in on what the actual situation is on the ground. Do people still change their clocks for Ramadan? Would they be annoyed if a website kept Moroccan users on standard time during Ramadan?
In this day and age when a natural language query can produce the most AbstractBeanFactoryFactoryBeanFactory boilerplate at the same rate as a much more concise equivalent, does verbosity matter as much?
Sure, but if I can summon up a summary of what’s going on for those abstraction layers in a matter of seconds, I don’t particularly care whether they were overly verbose or not. There’s no world where you can hand me a pile of code and expect me to be able to comprehend it faster than an LLM can walk the stack anymore, even the most beautiful pristine code that would make Linus Torvalds praise you is easier to have an LLM parse it and explain it to you than doing it yourself.
And the LLM doesn’t care. You could hand it a pile of the best code ever and a pile of brainfuck and probably the difference between comprehending one over the other is in the seconds if not milliseconds of compute time.
This works only until it doesn't. The stochastic nature of LLMs will not go away. When you have to fix that bug, but the explanations of the LLM are incorrect (root) cause analysis, and you have to dig into the code yourself, you will regret not having taken more care earlier. I have had numerous scenarios in my latest project, in which the LLMs simply did not get on the right track, when I asked them about some issue I saw with a widget or making a custom widget (Python, tkinter). I don't think it will fare much better when analyzing existing code, because ultimately it does not understand things.
Given the stochastic nature, if I am forced to have to dig into the code because the LLM couldn't figure it out perhaps one out of every 10 times, it's still a huge bonus. Probably it depends on what you are working on. Esoteric COBOL? Erlang? Yeah good luck, you're probably hand steering the thing while the frontier model providers figure out how to train it better. Vanilla-ish Python/Golang/Typescript/Java? I pretty much never have to do that nowadays for things the model is familiar with. If i do have to dig into the code, I've never regretted doing it this way, because 90% of my use cases worked just fine, and in those 90% of use cases I was able to produce working code at 20x the rate of hand writing it if not more. Feels like a huge win to me.
> Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times
I don't know about the guy you're replying to, but I've made many mistakes in my coding life, and some of them more than once. The Date API is written in a way to obfuscate the real complexities of date and time management, so I find it quite easy to imagine someone stepping in the same footgun more than once.
EDIT: oh ew, grandparent comment is a bot. How did you recognize it?
I can't imagine he's building anything serious. How can you claim otherwise that your agents were deploying code that you couldn't verify. Imagine doing that in any serious business ..
Yeah maybe I'm just old but in 25 years in industry - not one company has needed this much code that fast. They may insist they do but then it sits while they figure out how to sell, or the inevitable "oh wait, we didn't think about that..."
Exactly! How do other parts of the organization deal with this avalanche of features in terms of documenting, pricing and packaging, marketing, selling and getting feedback on them. How do users adopt these features and incorporate them in their workflows so fast?
Never in my career was the speed of writing code alone the bottleneck.
It is absolutely evil. Placing mines instantly puts you in the bad guy category as far as I'm concerned, no matter whom you claim you're "targetting". The Baltics withdrawing from the Ottawa treaty was an absolute disgrace. Indefensible.
> The Baltics withdrawing from the Ottawa treaty was an absolute disgrace. Indefensible.
It is entirely defensible on account of wanting to reduce risk of being invaded by Russia.
PS: Poland also exited the treaty. I entirely support use of mines on territory of mu country for purposes such as reducing risk of Russian invading Poland again. Though deployment should not be premature.
But I hope that production and stockpiling of enough mines is ongoing.
If you think that is indefensible - are you aware of how WW II went for Baltics, Poland, Belarus? In Poland about 16% of population was murdered, in Belarus about 20% of population was murdered. And Poland and Baltics got decades of occupation on top of that. Belarus still has not managed to get from Russia's boot as of 2026.
And I have no problem with position "war crimes are not OK".
War crimes are bad, but using ATP land mines is not a war crime by itself.
For example ATP land mines with reliable self-destruction used properly are OK (yes, some failure rate will exist - in case of war you rarely have 100% sunshine and rainbows solutions).
While dropping randomly land mines over city to target civilians is bad, evil, war crime and terrorism.
Arms control treaties are effective only if they are banning weapons that aren't useful. The problem is that landmines are incredibly useful weapons. What that means is that every country that has signed up to the Ottawa treaty either expects never to get into a major war again, is planning on relying on its allies who haven't signed the treaty to deploy landmines for them, or is planning on ignoring the treaty and using landmines anyways if it gets into another major war again.
In that vein, the Baltics withdrawing from the Ottawa treaty is commendable because they've stopped lying to everybody about what they're going to do come wartime.
> Arms control treaties are effective only if they are banning weapons that aren't useful. The problem is that landmines are incredibly useful weapons
There is not a single doubt in my mind that mines are useful. As are executions of people suspected of collaborating with the enemy. As is instituting precautionary concentration camps to round up folks who might have some bond with the enemy. The utility of dropping atom bombs on civilian centers is probably extremely high in negotiating with the enemy. But, like mines, these things are unconscionable, and when you start using these highly effective means, you should really ask yourself: "am I the good guy in this conflict?"
For me, the answer is no. I don't think we should commit war crimes, which somehow has become a controversial opinion.
War crimes are bad, but using ATP land mines is not a war crime by itself.
For example ATP land mines with reliable self-destruction used properly are OK (yes, some failure rate will exist - in case of war you rarely have 100% sunshine and rainbows solutions).
While dropping randomly land mines over city to target civilians is bad, evil, war crime and terrorism.
Yes, in case of war it is very likely that murdering soldiers of other side will become necessary. It does not make executing PoW acceptable, but guns/mines etc will be used.
One core principle behind determining whether the use of a weapon is a war crime is seeing if it can be used discriminately, i.e., if it can be targeted. So for example, the use of guns (though awful) is not a war crime, because using it requires you to point it at something and pull the trigger. You are in control of whether you shoot an enemy who is actively engaging, an enemy who is retreating, a field medic, a journalist reporting on the scene, a civilian who was not able to flee the area. With for example mustard gas, you cannot make this choice, and that's one of the two major reasons why the use of mustard gas is a war crime.
Even if you build in a self destruction mechanism to landmines(1), this indiscriminate nature remains.
On top of that, you mention something about peppering cities with land mines not being ok (and it wouldn't be), but I'm not convinced that anyone's doing that. And still civilians make up 90% of the victims.
Of course, there's another thing playing into that 90% figure, which is that, by and large, mines are not very effective against military tartgets because they have ample means to dispose of them. Given the fact that our target here is Russia, and not some poorly funded guerilla outfit, I think this should be taken into consideration.
Pairing their war crimey nature and their low efficacy (2), I personally cannot get behind withdrawing from the Ottawa treaty.
There is much more to say about this, and much more has been said about this. I would recommend giving
a skim. They give alternative, more effective, less inhumane, solutions to the problems that mines try (and largely fail) to solve.
(1) Which is ultimately a bit of a hypothetical exercise, because the nations that left the treaty, well, left the treaty. They didn't propose an amendment allowing for temporary mines, they left the treaty. And on top of that the failure rate for such smart mines is like 20%. You get 1/5th of a war crime I guess.
(2) Earlier I said something to the effect of "I'm sure they're effective". At the time I hadn't read up on the actual effectiveness of mines, because to me, the effectiveness of a method plays no role in whether it should be allowed in combat. I've since read up on that part too, and I'm reasonably convinced they're not very effective in our current context.
Modern mines have programmable target discriminators that use multiple sensor modalities in addition to a programmable self-destruct. A cow or a goat herder usually won't set these off.
Many types of sophisticated mines cannot be trivially cleared with line charges or engineering vehicles. Soviet style mines can be cleared this way but aren't the only kind that exist.
This tech isn't sophisticated but it costs money and requires maintenance. Many militaries don't use them because they want weapons that can sit in a warehouse for 50 years with zero maintenance.
The military purpose of mines is not to kill anyone. It is to deny use of space in order to shape the battlefield and trap the adversary in areas where they are exposed to other weapons. Mines are highly effective at this purpose and will be for the foreseeable future against almost all adversaries. This is not controversial.
The "expert" in the linked article has no background in mine warfare, only EOD. This became obvious when I was reading the article because it presented an unexpectedly naive understanding of mine warfare. That perspective might make sense if your only experience is clearing old Soviet mines and IEDs but it doesn't generalize.
I wonder how those sensors detect a retreating enemy. And again, a failure rate between 6% and 20% is not acceptable. A bit of mustard gas is still mustard gas. And the baltics left the "all mines" treaty, not the "smart mines" treaty.
You are underestimating what kind of evil things people had done and will do. This was in fact done.
> Even if you build in a self destruction mechanism to landmines(1), this indiscriminate nature remains.
Would you claim that dropping bombs from planes is also war crime? Because if mines are placed in exclusion zones or deployed directly in front on enemy charge then mines can be as discriminate as alternatives.
> Of course, there's another thing playing into that 90% figure, which is that, by and large, mines are not very effective against military tartgets because they have ample means to dispose of them. Given the fact that our target here is Russia, and not some poorly funded guerilla outfit, I think this should be taken into consideration.
In Ukraine mines were in fact effective, both against Russia and Ukraine.
> because they have ample means to dispose of them
Main benefit of using mines is slowing down enemy and forcing them to deploy means to dispose them
It drastically lowers speed of advance, even if mines harm noone in the end.
> And on top of that the failure rate for such smart mines is like 20%.
I heard about much better failure rates. Do you have a reliable source for that 20%? I would be happy to educate myself (and maybe change my opinion)
I did, and their claim of "Minefields can now be breached in minutes, using armoured engineering vehicles and explosive line charges." is highly misleading.
For example Russia lost piles of tanks and other combat vehicles around Vuhledar, large part of them to remotely deployed mines.
For other side, Ukrainian summer offensive failed in large part due to massive mine fields (there were also other factors like insufficient supply of armoured engineering vehicles and explosive line charges and Russian helicopters sniping ones that were trying to breach minefields).
If you restrict claim to ATP mines - they are still useful and they are nightmare to advancing military. Yes, after war they will be also horrible for civilians if not cleaned up.
Manipulation/mistake in quoted source is that any military thing can now be breached in minutes or faster, at least in some cases with proper tools deployed in proper position. The trick is that it is not reliable, you may lack this tools, you may miss window for deploying them, they may be opposed or stopped.
Yes, sometimes mines can be defeated quickly, mines are not win button, mines will not solve all problems. It does not change that mines are extremely useful and side not using them (or giving up ATP mines) is at huge handicap.
> I'm reasonably convinced they're not very effective in our current context.
I am not, at all, and as far as I know this is widely shared opinion among people who are actual experts in military matters. (I am not one)
I wonder to what extent you should say you "rebuilt" something when the most basic hello world example doesn't work. And I wonder to what extent it makes sense to call it "from scratch" if you inherit a battle tested extensive test suite from the thing you're rebuilding, and the thing you're rebuilding is part of the training data.
Here's the first paragraph of Harry Potter and the philosopher's stone. I rewrote it from scratch, apparently:
Mr. and Mrs. Dursley, of number four, Privet Drive, were proud to say that they were perfectly normal, thank you very much. They were the last people you’d expect to be involved in anything strange or mysterious, because they just didn’t hold with such nonsense. Mr. Dursley was the director of a firm called Grunnings, which made drills. He was a big, beefy man with hardly any neck, although he did have a very large mustache.
I think I finally understand why the LLM craze is like catnip to management types - they think they've found a cheat code to workaround the mythical man-month
For my whole life in technology, there was this thing called the Mythical Man Month: nine women cannot have a baby in a month. If you're Google, you can't just put a thousand software engineers on a product and wipe out a startup because you can only... build that product with seven or eight people. Once they've figured it out, they've got that lead.
That's not true with AI. If you have data and you have enough GPUs, you can solve almost any problem. It is magic. You can throw money at the problem. We've never had that in tech.
Maybe it could have been written slightly clearer, but I think the intended meaning is, "If 10x more tokens saves a day, spend the tokens. The bottleneck should be human decision-making time, not agent compute time."
Any human in the loop will be a bottleneck in comparison to AI performance.
If we take that to its logical conclusion, I think we can answer that question.
Getting rid of humans, unfortunately, also takes away their earnings and therefore their ability to purchase whatever product you are developing. The ultra rich can only purchase your product so often - hence better make it a subscription model.
So there is pressure on purchasing power versus earnings. Interesting to see what happens and why.
I'm not sure I agree with this. 10x more tokens means leaaving the agent to work for 10x longer, which may lead to bugs and misintepretation of the intention. Breaking the goal into multiple tasks seems more efficient in terms of tokens and getting close to the desired goal. Of course this means more human involvment, but probably not 10x more.
The day being referred to is the human’s time, not the AI’s time. That sentence is saying substitute the cheap, abundant resource for the expensive, bottlenecked resource.
^ This report from 2020 analyzed about 50,000 IT projects in a wide range of market segments, and they found that 50% exceeded their deadline. This seems to suggest that your conclusion holds more generally than just your specific context.
On a personal level, I hardly ever see a developer's estimate turn out to be right, on whatever scale. I'm wondering what the pro estimate folks in this thread work on that they're able to estimate accurately.
The other day we were discussing a new core architecture for a Microservice we were meant to split out of a "larger" Microservice so that separate teams could maintain each part.
Instead of just discussing it entirely without any basis, I instead made a quick prototype via explicit prompts telling the LLM exactly what to create, where etc.
Finally, I asked it to go through the implementation and create a wiki page, concatting the code and outlining in 1-4 sentences above each "file" excerpt what the goal for the file is.
In the end, I went through it to double-check if it held up from my intentions - which it did and thus didn't change anything
Now we could all discuss the pros and cons of that architecture while going through it, and the intro sentence gave enough context to each code excerpt to improve understanding/reduce mental load as necessary context was added to each segment.
I would not have been able to allot that time to do all this without an LLM - especially the summarization to 1-3 sentences, so I'll have to disagree when you state this generally.
Though I definitely agree that a blog article like this isn't worth reading if the author couldn't even be arsed to write it themselves.
Sometimes the answer to "why?" is that the dev had a hammer and the codebase was starting to look an awful lot like a nail. In-memory cache isn't considered as a serious option nearly enough imho.
reply