To be fair I cannot trust your shape in your jsonrpc, I am not sure if id is truly an integer or if you sent me an integer by mistake, same as params or even the payload of the params' param, this is why we ended adopting openapi for describing http interactions and iirc jsonrpc specifically can also be described with it. At least in the schema part no one would say it is ambiguous, also one does not need do heavier parses, the obj is a tree, no more checking on scaping strings, no more issues with handcoded multiline strings, it is dropped the need to separate attributes with commas as we know the end tag delimits a space and so on.
> To be fair I cannot trust your shape in your jsonrpc, I am not sure if id is truly an integer or if you sent me an integer by mistake, same as params or even the payload of the params' param
In practice, it doesn't matter.
If the JSON payload is in the wrong format the server rejects it with an error.
If the server sends an integer "by mistake" then the purists would argue that the client should come to a halt and throw up an error to the user. Meanwhile the JSON users would see an integer coming back for the id field and use it, delivering something that works with the server as it exists today. Like it or not, this is why JSON wins.
Schema defined protocols are very useful in some circumstances, but in my experience the added overhead of keeping them in sync everywhere and across developers is a lot of overhead for most simple tasks.
Putting the data into a simple JSON payload and sending it off gets the job done in most cases.
Probably absolutely no. I was studying about the corresponding names between tarot card and Shem Hamphorash and gave me incorrect names, it gave me a correct angel name but not the correct one of several cards.
It is a shame that the people you are answering is being downvoted, I also understand the importance of coloring functions, but look at the examples that person put, python and rust. In those, executing a colored function (at least the async related ones) propagates up to the top of the program, that is a cost that we have to interiorize, but I would be lying if I told you I wouldn't he happy with such behavior. I do a lot of js/ts and I would love to just be able to "inline" await without making my current scope recursively to the top of the program like it can be done with F# with the Async.StartAsTask operation.
A lot of people want to "inline" IO from a non-IO function too.
I'm glad that the fight happens between the developer and the compiler so that it doesn't have to happen between developers on every single pull request.
You can use adapters via Foreign Function Interface and interact with C++ code. The deal breaker is that memory is separated, C++ code has its own heap and Ocaml too. Quiet different to F# in which operating with C# is seamless and the runtime is the same.
Sounds like the metric is, in isolation unreliable and you're going to have a lot of false positives. Better to treat it as an indicator and rely on more nuanced evaluation.
quantumconfusion 6 hours ago | root | parent | next [–]
True, but there's also the flip side. People might inadvertently adopt AI-like patterns in their writing, especially as AI becomes more pervasive in our daily lives. It's a curious kind of feedback loop.
42Philosophers 6 hours ago | root | parent | next [–]
I think that's already happening. Sometimes I catch myself phrasing things in a way that sounds like an AI response. It's weirdly fascinating and a bit unsettling.
nerd_visionary 6 hours ago | root | parent | next [–]
That's the essence of language evolution, isn't it? We mimic the structures and patterns we're exposed to. In the past, it was literature or media, now it's AI. Just another chapter in the linguistic journey.
digital_scribe 5 hours ago | root | parent | next [–]
I wonder if we'll see a new form of 'AI-influenced' dialect emerging. The impact of technology on language has always been significant, but this could be a whole new level of influence.
