yea that's an odd example to pick. expecting type conversion to add meaning to strings is a programmer problem not a language problem. really comes down to developers not thinking about types and their meaning anymore.
there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.
Seems like a rather easy thing to go wrong in the client, no?
User sends message via client. Client fumbles the recipient id. Message ends up at the wrong recipient.
Examples: incorrect recipient ID attached to contact in list where users selects recipient. Buggy selection of multiple targets in the selection UI due to incorrect touch event handling. Incorrect deletion of previously selected and then deselected recipient from recipient array of multitarget message. Or if working low level even a good old off by one error and reading out of bounds data for the recipient list (though that one hopefully should trigger a faulty send request due to other stuff no longer matching). There is endless examples.
The server can't really safeguard against the client providing a legitimate send request even though the user intended to send it to another recipient.
I'm not sure if I missed a bit here, but I have some colleagues doing research on unikernels for HPC and the point is that this unikernel is running directly on the hardware or hypervisor and not inside another VM. The unikernel is effectively a minimal VM and the network stack is one of the things they struggle the most with due to sheer effort.
JSON for something that essentially mirrors a shell installation process? Feels like you are trying to reinvent things with a golden hammer, not like actually making it easier.
If you read closely I am not talking about the limitations of GPT, but about the limitations of the developer having to fix code of others (GPT essentially being another developer). I guess it depends on the complexity of the problem. A lot of stuff is very easy to review and for me other stuff needs more time to understand than it did to write.
You're working under the assumption that you will be able to find the errors. I personally found reviewing code always way harder than writing it and we already push tons of bugs to production in written+reviewed code.
It's more like not using semi-autonomuous driving features with the car entirely relying on your expertise to realise and correct when it's making a mistake. The main difference is risk. Your own life at stake versus bugs in some production system.
Due to the nature of my current work I haven't really used GPT for coding yet, but I keep wondering isn't it easier to write code than to read and truly understand it? So how much development time was really saved, if I still care about off-by-one errors or correct identity checks in hash maps or all those edge cases I probably should care about? Those are all things much harder to spot reading than writing the code.
So I keep wondering if we just save time by introducing more unknown bugs using GPT?
I guess this also has a lot to do with what code is written. I would be much more concerned with a system level C++ library than some JavaScript CRUD.
According to the RFC's PUT can be used to create a resource as long as the request has a clear target. That doesn't necessarily mean an ID, but just some kind of identifier (composite key, hash of content, url, etc.). When a create instead of update happens the server should respond with a 201 CREATED, which should indicate the location or identifier of the created resource.
Aren't you basically describing that you want idempotency?
The RFC 9110 (and also the old 2616) clearly state PUT is idempotent while POST isn't.
9.3.4 PUT
"The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server."
9.2.2 Idempotent Methods
"Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ."
Until it's the German bureaucrats that ruin your day.
This is an international issue and a national answer doesn't solve it.
For what it's worth my first name is also not accepted correctly (it contains a hyphen) and I never had a problem so far. But every time an airline asks me to put my name exactly as in the passport I cringe.
The article makes that point. There is no law to put a giant banner that disturbs UX in your users face. Companies choose to do so. There only is a law that prevents companies from tracking you without consent.
I don't think we should abolish time zones, but he isn't making good points.
His points are based on conventions that exist because we use local time zones and he uses a lot of English centric bias in his argument.
His first point of am/pm is already a bad start considering a 24h clock is simply advantageous and used throughout most of the world.
Finding out if he can call his uncle would be as easy as looking up daylight times instead of time offsets/local times. And even then the cultural conventions of your country might not map to his and it was still inappropriate to call.
The problem with business hours and overlapping days is entirely made up, because he wants to stick to previous conventions that worked well with local time. If a night club opens Saturday from 19:00 to 05:00 it's perfectly clear that means it's open till Sunday 05:00. It would work similarly for business hours. The regular business hours also differ vastly in different cultures and jobs! The day name is of course UTC based and wraps at 00:00UTC.
I play an international online game that wraps days at 00:00UTC and we communicate in UTC. If I say Wednesday 14:00 UTC it's perfectly clear what that means and you get used to that very quickly. If we would change the system the next generation would grow up with that system and it would be natural. And I find it much easier to remember that my Korean friends are available from 23:00 UTC till 16:00 UTC than to remember what time it is there right now compared to here, because that requires mental math or a lookup.
there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.