We’d rather re-create reality where we know everything rather than taking the time to learn how to use a system someone else wrote.
IT and DevOPS does this too.
I worked with a group once that re-invented XML so that non-technical people could create text-based rules instead of writing code. But it ended up with a somewhat rigid naming structure with control characters and delimiters. The non technical people hated it more the actual XML they had used prior.
They started out with something close to YAML. As the project moved forward, they found out they needed to represent logic with interlinked sections. They needed section 3, point a to link back to section 1 point 3, sub point 2. So they toyed with some assembly-like operations. Then they needed some inheritance. They really just slowly re-implemented the common applications of xml one at a time, it just had less brackets and <> symbols when they were done.
Re: the not-XML-instead-of-code thing. Eventually, this sort of thing turns into a programming language. It’s just like carcinisation. Or you wind up writing ever-more code to support the original design. The environment inevitably creates evolutionary pressure that only if/else and iteration logic can solve, forcing the design ever closer to being Turing-complete.
We’d rather re-create reality where we know everything rather than taking the time to learn how to use a system someone else wrote.
IT and DevOPS does this too.
I worked with a group once that re-invented XML so that non-technical people could create text-based rules instead of writing code. But it ended up with a somewhat rigid naming structure with control characters and delimiters. The non technical people hated it more the actual XML they had used prior.
You’re talking about YAML? /s
LOL. not far off
They started out with something close to YAML. As the project moved forward, they found out they needed to represent logic with interlinked sections. They needed section 3, point a to link back to section 1 point 3, sub point 2. So they toyed with some assembly-like operations. Then they needed some inheritance. They really just slowly re-implemented the common applications of xml one at a time, it just had less brackets and <> symbols when they were done.
Hence making the parser more inefficient than XML?
It wasn’t without some advantage. The client hating it didn’t bode well though
The client hating it just means you’re smarter than them and should press on to help them outgrow their ignorance. It’s a good sign.
I woulda tried them on JSON. As long as they use an editor that keeps track of nested brackets I think it’s much more natural than XML.
I switched to TOML for my stuff.
Re: the not-XML-instead-of-code thing. Eventually, this sort of thing turns into a programming language. It’s just like carcinisation. Or you wind up writing ever-more code to support the original design. The environment inevitably creates evolutionary pressure that only if/else and iteration logic can solve, forcing the design ever closer to being Turing-complete.