when i use json module , syntax to convert tuples to Json is
` %*`
Which is obviously unreadable and very easy to forget what it means.
Only other way is to impor 3 libraries and use toJson()
import std/tables
import std/jsonutils
import std/json
let jso= {"j":10,"s":20,"o":100,"n":5000}
echo jso.toOrderedTable().toJson()
Can't we just have json() method to do it?
Almost nothing in json.nim aged too well. :-)
The idea back then was "toJson is more common than modulo, so I'd rather use % for that operation". But % only worked on simple values (integers, values), so in order to turn "anything" you would use %* which read like "%/toJson but repeated".
yes.
template json*(t): JsonNode = %* t
badabing, crisis averted.
Which is obviously unreadable and very easy to forget what it means.
Not really, once you know what it means it's quite readable, but it requires that you familiarize yourself with the tools you're using. Besides, when you see something that looks suspiciously much like json with some appended symbols appended it's probably safe to assume that it's json data.
Only other way is to impor 3 libraries and use toJson()
The reason for this is because you're now manually first making a table and then converting that to json, which is quite a terrible way of doing it. The %* operator is a macro which reads what follows and converts it to code that generates the equivalent json data structure. What you could do if you really wanted to use json instead of %* is to define a template:
import json
template json(x: untyped): untyped =
%*x
let jso= json({"j":10,"s":20,"o":100,"n":5000})
i am avoiding use of template for now (to keep the language simple as possible) . Template are the strong point of Nim but too much template leads to too much magic. Too much magic would lead to undebuggable mess.
Importing and function magically attached to variables . Thats already enough hocus pocus.
Templates are IMO the simplest form of metaprogramming in Nim as it's just code substitution.
If you're concerned with debugging you can add an extra piece of complile-time logic into the templates that only executes / gets put into the resulting binary when you define something like debugging.
Don't shy away from templates!
Almost nothing in json.nim aged too well. :-)
Then its time to Fix it, even if it means breaking changes...
should have this in standard library then:
template json(x: untyped): untyped =
%*x
Then its time to Fix it, even if it means breaking changes...
No need to break anything, deprecate the module and link to an alternative, recommended package.
Macros make code much easier to read. Consider this example from npeg:
let parser = peg("pairs", d: Dict):
pairs <- pair * *(',' * pair) * !1
word <- +Alpha
number <- +Digit
pair <- >word * '=' * >number:
d[$1] = parseInt($2)
Imagine how unreadable this would be without the specialized syntax.
This is a pretty ridiculous claim and I think the only place where this even comes close to being true is in the web development world. Nim is a systems programming language, or at least it's supposed to be. It is not supposed to be NodeJS or whatever your favorite web framework is.
I don't care if JSON gets implemented in userland but I do care if the stdlib becomes more bloated with poor implementations. I have very little use for JSON and if I need fast JSON parsing I can always wrap some battle-tested C library that does it well, or bring my own implementation.
I'd rather see some library that is widely adopted and well implemented in user land get incorporated into the stdlib once it has proven itself than have another version of a module that will suffer the same eventual fate as json. Just because you think JSON is so important because you use it for your http / web dev stuff doesn't mean everyone has the same view as you do.
I have very little use for JSON The whole software development community vs You then? That would be more ridiculous. Nim is advertised as Battery Included , so we expect most standard things to be included in nim.
JSON is not perfect and i don't really like it but like it or not , you have to support JSON at one point when writing system applications as well : when the project becomes bigger and there is need to expose it over the web.
Claiming that JSON is only used by wed development world is totally blind.
Software Developers all over the world uses JSON for :
Many Many More.
Python have proper JSON lib and there is rarely need to use other JSON library , thats why it is easily compatible with Javascript.
I see Nim not just as system programming language , but as full stack solution .
I can always wrap some battle-tested C library that does it well, or bring my own implementation.
There more code you write , the more subsystem you develop , the more you need to maintain , more time need to work , less time for entertainment , more stress , dies earlier.
Worksmart , No time , you have , young padawan .
I don't even know how to reply to this honestly... Your JSON fetish isn't shared by everyone.
Yes I have maintained code I wrote years ago - I do it all the time at work. I also maintain code other people wrote years ago. I see little point to your argument.
I think you have a very narrow view of the software development world. How do you think configuration data was serialized before the advent of JSON? Just because you need JSON in your stdlib doesn't mean every one does, and I certainly don't want a sub-par implementation to exist in it.
Python isn't a systems programming language, just for your information. You'd be better off making a comparison to Golang, Rust, D, Zig or C/C++.
I don't care what YOU see Nim as, I care what Nim is advertised as, which is:
...a statically typed compiled systems programming language.
Also I don't appreciate the condescending tone. You have no idea how old I am or how long I've been writing software for.
Fetish blah blah blah !@#@!#@!
Wow a lot of anger and stress i can see from you , take a breather , chill grandpha/uncle/bro/sis/dude/cis/trans .
Python isn't a systems programming language, just for your information. You'd be better off making a comparison to Golang, Rust, D, Zig or C/C++.
That is why i am trying Nim as i obviously stated above .
I think you have a very narrow view of the software development world. How do you think configuration data was serialized before the advent of JSON? Just because you need JSON in your stdlib doesn't mean every one does, and I certainly don't want a sub-par implementation to exist in it.
what i am clearly saying is
Also I don't appreciate the condescending tone. You have no idea how old I am or how long I've been writing software for.
Anger leads to hate. Hate leads to suffering.