423
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 27 Feb 2024
423 points (98.0% liked)
Open Source
30800 readers
1010 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
And what would your ideal, legible, general-purpose data markup language be? XML?
Yaml Ain't Markup Language: am i a joke to you
(JSON for data, TOML for configuration)
I've used both YAML and a TOML-adjacent INI format for Ansible. While I wouldn't use YAML for massive data serialization (because significant whitespaces are fucking stupid), it's much better suited for manual data entry compared to most options, including TOML, when nested data structures are required.
And if YAML's structure is too complicated, that's honestly a skill issue.
Not that YAML's structure is too complicated, but its syntax is too flexible. All the shit about being whitespace sensitive yet with whitespace errors leading to a syntactically valid YAML document. TOML's syntax is rigid which makes it unsuitable for expressing complex nested data structures, which is good because that's not what you should use TOML for. Ultimately the dependence on a highly flexible baseline language like YAML to create complex DSLs is a failure on the developers' part, and the entire configuration system should be reworked.
Do you use a linter like the ansible vscode extension?
I used to hate writing ansible, and yaml, until I installed the ansible lint vscode extension, and everything became much, much easier.
Later on, when I was working on a docker-compose, I noticed that the vscode yaml extension (which the ansible extension pulled in as a dependency) caught errors. It's quite intelligent, able to spot errors exactly like what you mentioned, where the yaml syntax is correct, but the docker-compose, or the ansible syntax is wrong.
Of course. If you're working in a DSL that's popular enough for someone to have written a good schema/parser for then tooling can help.
Significant white space is awesome! Not supporting tabs tho shows you don’t know what you are doing, YAML.
They very well know what they are doing. Take your filthy tabs and get out of here. Spaces only.
Tabs for indentation, spaces for alignment. It's perfect. Lets people visually indent as much as they want in their settings, but manually aligned things stay manually aligned. Forcing indents to always be... whatever number of spaces you personally like is dumb.
Plus then you can outdent with a single Backspace in every text editor ever.
😧
Accessibility be damned
set expandtabThat just converts tabs to space but doesn’t address the underlying accessibility needs where some folks demand different indentation due to vision issues or nonstandard IO devices like braille readers. Tabs allow the user to configure the width for their needs. Being static spaces ignores the needs of many folks.
Very good point re. Braille readers. I was being flippant and did not think of that. My apologies. Tabs for indentation may be useful there. as would a blind-friendly pre- and post- processor for programming language specific files (a braille liner, could call it black-er for python :)
I don't know how braille readers actuality work, but I guess they process a bytestream. How do they handle utf-16 and other non standard character sets? This is a known problem for a lot of systems- it would be interesting to know how they address it.
Have you met any such person?
I have interacted with triple digits number of developers and I have met exactly zero folk with such a need. If there is an actual need by a team member, sure, we will be accommodating.
Until then, however, the much more common thing is for people to have their own preferences for tab width and ignore the current code style, ending up in an identation abomination that sucks for everyone. Therefore, no thanks, forced width for everyone, using spaces.
No point ruining the happy path scenario for a theoretical person with such a disability. If there will be an actual need, sure, let's convert to tabs only then.
Can you give an example where a person's personal tab width breaks things? One tab per logical indent, and then spaces for alignment. How does this break anything? I know for a fact it doesn't or else people like me wouldn't advocate for it. What breaks indenting is mixing tabs and spaces for indents, and obviously that's foolish. You can't blame that mistake for causing an "abomination" when it's something that would violate any code style specification, whether using spaces or tabs. You yourself could set your IDE to emit only 2 spaces when you hit Tab, and that would also violate your code style spec if you mix those indents into a file with 4-space indents, and that has nothing to do with tabs at all.
Doing stupid things in the code that violates the code style are stupid things that violate the code style. No matter what whitespace you use. But having a personal setting to see 8 spaces per tab isn't one of them if you only use tabs for logical indenting and not for alignment.
All tabs or all spaces for indents result in the exact same thing: good looking code. But tabs then have further advantages. Easier outdenting, better accessibility, etc. The only benefit to forcing spaces is that some random program you use for code comparison or whatever might default to something other than 4 columns for a Tab and your code looks a little wide until you change your settings. That's nothing compared to the advantages of tabs. Turns out that "benefit" of spaces is actually a drawback because no one is allowed to view the indents as anything but whatever column width you personally think it should be.
I am literally that person, but kay
Depends on the use case but XML is good for markup—especially if you need extensibility.
For config, Nickel & Dhall take the cake for being typed & having LSPs so the configuration writer can get immediate feedback about possible options (while eliminating invalid states) without requiring the manual—with configuration readers not needing to mess around with marshaling their types. Both these configuration languages let you import files & write little loops to make your config more DRY & makes maintaining large files (like say Kubernetes) easier.
XML is great if the (de-)serialization is already implemented. Otherwise traversing the document is a massive pain.
True. Something like XPath can really help & there are use cases where that is more concise but requires loading XPath into your head like Regex (which tends to get unloaded). The extensibility shines tho as seen by XMPP continuing to this day with very good backwards compatibility with 2 decades of updates since everything in an extension to the base.
RON (Rusty Object Notation). Its like JSON but better.
Do you remember CSON? CoffeeScript Object Notation was a cute way to make JSON readable before CoffeeScript kinda died.
CSON looks like a slightly worse version of YAML to me
Parsing rules are way simpler… it was also a different time.
as a rustacian i cannot thank you enough for notifying me of this