That's a different part of the implementation details. If you were to break the system into mocroservices, the model is a binary blob with a mocroservices wrapper and accessing web search is another microservice entirely. You really don't want the entire web to be constantly compressed and re-released as a new model iteration, it's super inefficient.
Technically you’re correct, but from a product point of view one should be able to get answers beyond the cut-off date. The current product fails to realise that some queries like “who is the current president of the USA” are time based and may need a search rather than an excuse.
This only holds water if they are able to retrain frequently, which they haven't demonstrated yet. But if they are as efficient as they seem, then maybe.
There is no success without try. If nobody ever tried to make something new, we would have never had many of the great tools we like today. The main problem with the fatigue is not new tools, it's when a tool exists for some time, gets used by real-world people, and decides to change major things. There could be good reasons for the change: maybe something that wasn't well thought enough, or the big picture has changed, .... but then all those users/developers have to adapt their real-world scenarios to the new major forced change, and this fucks everything and everyone up. And this tends to happen way too often with modern development.
Engineering is a lot about trade-offs. Use a new (dynamic/not stabilized thing) because it is 20% better at something, but you risk to need to adapt or use something old and stable that involves more work?
It is possible that many people avoid thinking explicitly about these trade-offs then they are upset. But if you worked in the field more than 6 years you should have seen the pattern.
I worked with people that preferred 10 years old, stable technology and they did not have surprises. There were some downsides, but I think these types of companies are there.
It's a very nice scene, but not as good as the 2CV from Le Corniaud.
Also looking at it closely, you can see at the camera angle change that the car is not the same (roof shape cut, rear door a bit open, ...), and that it is not standing on its wheels with supports appearing below
As soon as you put everything on a single point of failure, it will fail you.
It is not a good idea to have keys, documents, passes, ... all on a smartphone: it can break if dropped, it can be stolen anytime, it can have no battery. Those devices are not good for such important elements of a travel.
"charge everyone on board with espionage, give maximum jail sentence" won't help: most of the crew has no choice in those operations, some might not even know what is going on. They also have dozens of ships that can do such damage, so no way to scare them by seizing or jailing one.
The thing is that JSON was intended to be a data exchange format, not a configuration file format or anything else. IMHO Crockford's reasoning makes a lot more sense with that in mind.
JSON is a human-readable data exchange format. There is a good reason human-readable data exchange formats are so popular - they can be read and understood by humans! So it seems pretty absurd that a format designed to be read by humans doesn't support comments. If you're really concerned about performance or size, you should use a more efficient binary format for data exchange like protobufs, or heck, BSON (binary json)!
XML was intended as a data exchange format and has comments. Image file formats like JPEG and PNG support comments (and so does SVG by virtue of being XML). Database systems support comments on database objects. It’s really not a convincing argument.
Even if we stick to the data exchange format, it would be practical to have comments in examples of data. This would be good for training and learning, for documentation.
This is still possible. There's nothing stopping you from putting comments in the JSON in your file or a webpage. It's just not going to be accepted as valid by JSON parser, which for learning material should be fine.
Data interchange formats are often used for configuration. It makes sense to have a single source of truth in json if your configuration is consumed by an app.
> So instead of comments with parsing directives, people use underscore prefixed keys to keep metadata and comments, that's not a win at all
Your comment doesn't make any sense. You're just pointing out that developers designed data interchange formats as subsets of JSON which explicitly support metadata and comments. This means they are specifying their schemas to support these usecases in a way clients can and do support it. That, if anything, proves right the decision to not support comments because it resulted in better-defined and well-behaving clients.
The only, only reason I ever buy anything but the smallest phone they offer is because the best cameras are never on the smallest devices. The extra size is pure down-side for me, and I don't really give a shit about slightly faster processors or what have you (I hardly burden the low-end ones), but I do find when looking back at older photos I always appreciate when I've had better cameras, so I hesitate to go too low-end on those.
I'd pay about the same (or maybe even exactly the same, but feel a little annoyed about it) for a small Apple phone with the same camera as the expensive big models.
I choose the cheapest technically up-to-date one. I really don't care about the camera, the gap between generation is mostly not interesting. Actually the only reason I had to replace the last one is that Apple stopped supporting it with the latest iOS...
I'd be scared to break the thing: it is so big and directly connected. It wouldn't fit into a pocket anyway...
Also I wouldn't choose one with a lightning connector, better with a USB-C (or A) female port, so I could also use it for some other devices too if necessary.
reply