The weather is an example of a non-linear dynamic system. Try as we might, we still cannot predict it really even a few days in advance. The stock market is much worse, even, so, no, it cannot be predicted.
Not the OP but I guess what they are saying is that since this language is a subset of go and if you use it as such then an arena allocator cannot be used in the transliterated code.
Maybe it's possible to force the transliteration to use a different allocator and then you could use the one you wrote in C?
Heh, I like the analogy but my question was really why it was considered such a hassle.
I mean we deal with daylight saving time all the time and I know it's not the same because the leap second affects UTC, not just local time zone, it's just that you are either dealing with monotonically increasing time like epoch, or you are dealing with "human" time and I found no distinction in the latter.
Is it "just" that leap seconds or delay seconds caused problems in epoch to utc conversion? Note the just in quotes, but did I just answer my own question? :)
I agree, I don't like it either. But... how would they then implement a world where you can wander everywhere? What it brings to the table is that you can wander across the world and not become terribly outmatched as soon as you wander "too soon" to an area.
My gaming preference is to go to an area as per game design, so the fact that I would be outmatched does not bother me and would prefer it that way. I do, however, understand why the game designers chose level scaling for what they wanted to achieve.
Can you explain where this comes from? I mean, that's not even close to what the norm is in Europe. Though, to be fair, we don't normally count fuel into TCO and the reasoning is: if you want to go distances then you are always paying for them. Whether it's public transport or taxis or whatever. Is fuel the major contributor in the number?
I think it now has a slightly different lens. The DropBox argument was that anyone can build this in five minutes, so why use this? Now, with LLMs, the argument is that anyone can build its own.
I remember reading an article in National Geographic of how crow's brains are much more interconnected than is the norm in mammals, i.e. IIRC they have a higher density of synapses between neurons. From that article, it seems that the usual brain weight vs. body weight to determine intelligence, which seems can be used to approximate intelligence in different species of mammals, cannot be used for birds (or at least crows, which the article was focusing on).
In other words, they seem to achieve better results with smaller brains than we thought. And yes, crows (in EU) do exhibit some pretty intelligent behavior.
You mean the middle management? I have been in environments where they were almost literally made up of pencil pushers. Wouldn't be too sad to see them go. Only half joking, but it is written in jest.
Indeed, there were plenty of people doing just that. I imagine they get the most out of vibe coding. However, when it became a problem, an engineer was still required to fix it.
It might have been you, a couple of months later, or someone else. I have dealt with slop produced by unknowing programmers most of my career. With this vibe coding I think my job is still safe. The amount, though, is increasing exponentially.
Indeed. I have to say, I hate this. Suppose you are in a meeting, you update something and you see the result, but the rest of the team does not. Ok, a couple of hundred ms does not play into this but if the update does not make it through? And yes, it happens.
But... software engineering was never about the boiler plate. Or adding the extra parameter.
It was about knowing how to fit the new use case into an existing code base, respecting the architecture, and sometimes rearchiteting the solution. How easy the latter was is really dependent on whether the code/arcitecture respected the low coupling, high cohesion principle.
Now, some of this can be coerced into LLMs but it takes work and careful study of the changes. Sometimes they get it right, many times they do not. So, you have to go back and forth with them. If you know what they should have produced.
SWE is far from dead. We just let too much slop into the codebase because we're overwhelmed by it and not incentivized by leadership to care. Code quality will likely drop to the point where even the leadership will notice and it will normalize again. There's nothing like a high profile customer calling out a problem that was vibe coded. It has started already and will be happening more and more.