I'm directly illustrating your point that "a language designer does really well to describe one's motivations, goals, tradeoffs, decisions, and then live with what you make", with one negative example of YAML spectacularly failing, and another positive example of Relax/NG spectacularly succeeding.
Because if all I do is beat a dead horse by ragging on YAML without suggesting any counter examples, I'm just pointlessly whining.
The YAML developers were so ignorant of and incurious about past and existing technologies that they were under the mistaken impression that what they designed was a "markup language", so pathologically that two out of the four letters of its name are incorrect, and they had to change what the other two letters stood for retroactively after they finally figured it out. And the human interface -- the syntax of YAML itself -- suffered deeply because of that ignorance (as do its millions of users and apps and LLMs that still have to deal with those bad uninformed design decisions).
The Relax/NG developers knew what the hell they were doing because they had a long track record of working with real world markup language standards, and they eloquently and precisely described their motivations. They even KNEW what a markup language was, unlike the original YAML designers.
They deeply understood not only the history but the cutting edge competing technologies of the time, and Relax/NG greatly benefited because of it. They expertly performed, as you suggest, ''a full "forest level" comparison of all the trade-offs between the current'' RELAX/NG specification and many other schema languages past and present.
Bristling when somebody enthusiastically tells you about old technologies you should look at before designing new technologies is just self imposed ignorance, not a good look. Cultivating ignorance instead of learning from the past is what got the YAML designers in trouble, too.
So no, I'm not a Relax/NG evangelist, I have no stake in it, and I haven't used it for well over 15 years. And I've also used XML Schemas, which is another negative example of terrible language design, and why I appreciate Relax/NG so much. When I was learning and using Relax/NG, I read a lot of the papers and code on James Clark's web site, as well as the archives of the Relax/NG design group discussion (which were fascinating, if you're interested in user friendly language design and markup languages and schemas, which I am, and which this discussion is about).
Of course I've written before, responding to other people's comments, about how Relax/NG compares to XML Schemas, the history of markup and schema and language design in general, and how amusing it is to compare the length of James Clark's Haskel implementation of Relax/NG with the length of his Java implementation (although all arguments about how terrible Java is these days can be instantly won by mentioning the word "lawnmower" before getting into the weeds of thorny technical issues):
But I'm not trying to convince you to use Relax/NG, I'm just suggesting you might learn from its design, and check out James Clark's design document as a shining example of how enlightened language designers should express their goals and intentions just like you said.
I'm sorry you can't or won't see it, but what I learned and shared about Relax/NG applies directly to this discussion about YAML and HOML's reaction to it, insofar as Relax/NG has well designed user friendly human readable and writable compact syntax, which is perfectly compatible with its clumsy verbose XML syntax.
James Clark's paper, The Design of Relax/NG, is a perfectly on point illustrative example, directly addressing your comment about how language designers should "describe one's motivations, goals, tradeoffs, decisions, and then live with what you make".
Did you bother reading or even skimming that excellent paper which exemplifies what you called for, before accusing me of not responding to your comment and hijacking your thread? Geez, sorry, dude. Read the paper, then you'll understand.
Thanks for replying. I did indeed read your message but didn’t see a connection to the thread. Please don’t blame me for being honest about how your comment conveys (to me, and likely others, too).
Rather than ignoring your comment, I was open about how it came across. Some people don’t like that level of directness. It is hard to take feedback gracefully, I get it. A lot of people prefer to counterpunch.
Also, I think it’s probably a stretch to hope a person will read or skim through the quantity of words you’ve quoted at length and linked. Think about the readers. Whether you like it or not, you have convince people that it’s worth their time, one way or another.
To use your metaphor, you didn’t lead the horse to the water. The horse didn’t see water; it saw a pile of undrinkable words.
What an awful phrase. Leading a horse to water is about giving an opportunity to drink. If you lead a horse to water and it doesn’t drink, it likely means it’s not thirsty! You don’t yell at the horse for not drinking it.
All this said, I do sincerely appreciate you taking the time to reply.
I'm directly illustrating your point that "a language designer does really well to describe one's motivations, goals, tradeoffs, decisions, and then live with what you make", with one negative example of YAML spectacularly failing, and another positive example of Relax/NG spectacularly succeeding.
Because if all I do is beat a dead horse by ragging on YAML without suggesting any counter examples, I'm just pointlessly whining.
The YAML developers were so ignorant of and incurious about past and existing technologies that they were under the mistaken impression that what they designed was a "markup language", so pathologically that two out of the four letters of its name are incorrect, and they had to change what the other two letters stood for retroactively after they finally figured it out. And the human interface -- the syntax of YAML itself -- suffered deeply because of that ignorance (as do its millions of users and apps and LLMs that still have to deal with those bad uninformed design decisions).
The Relax/NG developers knew what the hell they were doing because they had a long track record of working with real world markup language standards, and they eloquently and precisely described their motivations. They even KNEW what a markup language was, unlike the original YAML designers.
They deeply understood not only the history but the cutting edge competing technologies of the time, and Relax/NG greatly benefited because of it. They expertly performed, as you suggest, ''a full "forest level" comparison of all the trade-offs between the current'' RELAX/NG specification and many other schema languages past and present.
Bristling when somebody enthusiastically tells you about old technologies you should look at before designing new technologies is just self imposed ignorance, not a good look. Cultivating ignorance instead of learning from the past is what got the YAML designers in trouble, too.
So no, I'm not a Relax/NG evangelist, I have no stake in it, and I haven't used it for well over 15 years. And I've also used XML Schemas, which is another negative example of terrible language design, and why I appreciate Relax/NG so much. When I was learning and using Relax/NG, I read a lot of the papers and code on James Clark's web site, as well as the archives of the Relax/NG design group discussion (which were fascinating, if you're interested in user friendly language design and markup languages and schemas, which I am, and which this discussion is about).
http://www.jclark.com/
Of course I've written before, responding to other people's comments, about how Relax/NG compares to XML Schemas, the history of markup and schema and language design in general, and how amusing it is to compare the length of James Clark's Haskel implementation of Relax/NG with the length of his Java implementation (although all arguments about how terrible Java is these days can be instantly won by mentioning the word "lawnmower" before getting into the weeds of thorny technical issues):
https://news.ycombinator.com/item?id=28668752
But I'm not trying to convince you to use Relax/NG, I'm just suggesting you might learn from its design, and check out James Clark's design document as a shining example of how enlightened language designers should express their goals and intentions just like you said.
I'm sorry you can't or won't see it, but what I learned and shared about Relax/NG applies directly to this discussion about YAML and HOML's reaction to it, insofar as Relax/NG has well designed user friendly human readable and writable compact syntax, which is perfectly compatible with its clumsy verbose XML syntax.
James Clark's paper, The Design of Relax/NG, is a perfectly on point illustrative example, directly addressing your comment about how language designers should "describe one's motivations, goals, tradeoffs, decisions, and then live with what you make".
https://relaxng.org/jclark/design.html
Did you bother reading or even skimming that excellent paper which exemplifies what you called for, before accusing me of not responding to your comment and hijacking your thread? Geez, sorry, dude. Read the paper, then you'll understand.
You can lead a horse to water...