5 ms·

As programmers I feel like we'll always nitpick and bitch over what the optimal setup is for rather mundane things (tabs v spaces, yada yada). I'm not saying t

As programmers I feel like we'll always nitpick and bitch over what the optimal setup is for rather mundane things (tabs v spaces, yada yada). I'm not saying that conventional commits are God's given best way to structure a commit message, but they are a defined structure, and I find it much more effective and important that some expectations be set around commit messages, and I think conventional commits are as good as anything. Like the author is making a big deal that they think scope is more important than type. I may tend to agree, but I think the difference between "fix(compiler)" and "compiler fix" is not exactly a hill I'd be willing to die on. The tech industry has tons of things that became standards even if they weren't optimal. E.g. if one were starting from scratch I think any sane person would argue JSON should support comments (sorry but Douglas Crawford's rationale for not including comments never made sense to me), better defined numeric formats, etc. But it was better in many contexts than what came before it, so it became the standard. I could believe that there is some other format that differs a bit from conventional commits that is a little better, but not really better enough to want a whole other competing way of structuring comments.

olzhasar 5mo ago
Defined structure does not constitute quality. A commit message can be loosely structured, but be very insightful and good at communicating the nature of the change. On the flip side, one can make a very structured but confusing or non-informative commit message. I generally tend to agree with the author, conventional commits do not solve the core issue of the poor commit messages problem.
- sharts 5mo ago
  But it does enforce a minimum quality
  - yencabulator 5mo ago
    Form != quality, as LLMs will happily demonstrate.
- bloppe 5mo ago
  Conventional commits made it easier to generate changelogs and automate semantic version bumps. I suppose LLMs can usually do that the right way with looser structure, but in the before times it made a lot more sense, and even now is much less ambiguous
  - steveklabnik 5mo ago
    Both of these things are discussed in the article. (changelogs and semver)
    - mattrb 5mo ago
      They're hand-waved away by saying the changelogs are bad and the semver isn't always accurate. While I mostly agree with, that doesn't mean they don't provide _some_ value. You get categorized changelogs (even if the messages are technical) and semver that's generally correct. The alternative of good changelogs and perfect semver isn't free.
  - xigoi 5mo ago
    Auto-generated changelogs from commit messages are bad, no matter if the commit messages follow some structure.
  - Mawr 5mo ago
    I suppose it is a significant downside that you could get misled into thinking you can autogenerate a changelog from commit names.
- bfeynman 5mo ago
  why is "solving" the issue somehow the bar? software engineering has more practices rooted in psychology than engineering, its a moving and ambiguous target. Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics.
  - Guvante 5mo ago
    Why undoubtedly? In what context does wasting your first characters on fix vs feat matter? PRs are going to have an explanation that has way more detail than necessary to figure that out quickly. One lines tend to be (for me) in a situation where the difference is immaterial. If I am rapid firing through history I need to know what you did not why you did it. Again I am not claiming that these are bad or even that they aren't good. I am specifically disagreeing that any change is automatically good, that isn't true.
  - Merovius 5mo ago
    > Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics. I do not want to contribute to a project using conventional commits. I have consistently found, that I am unable to decide what the "type" of a commit even is and I feel unnaturally caged in into how I would split up commits, by having them be restricted to types (it doesn't help that the conventional commits I've seen appear to decide the type by fair dice roll). Discouraging contributions does not "undoubtedly improve contribution semantics".
    - shimman 5mo ago
      [flagged]
- SOLAR_FIELDS 5mo ago
  It’s the linting argument all over again. I don’t give a shit what the style is. I give a shit that it’s consistent. Form whatever opinion you want about how you want to format your code, structure commit messages etc. I don’t really care, if you want to start every commit with “poop(fix): pooper my commit message”, as long as you’re consistent about it and enforce it programmatically you have my emphatic support This comment assumes you are picking between a conventional commit message or something better. But the reality is you are almost always picking between a conventional commit and Nothing.
  - Guvante 5mo ago
    That is only true of semantically equivalent things. Tabs vs spaces don't matter they are equivalent. But consistency is only better when it is an improvement. It is fundamentally important that convential commit is better for adopting it to be an improvement. After all in your example wasting the first four characters of your commits with poop would objectively reduce the quality of your commit history, whether or not it was consistent.
    - rablackburn 5mo ago
      > Tabs vs spaces don't matter they are equivalent. Just to nitpick (because what else is this thread about? :)) They aren't equivalent! Tabs carry more semantic information than spaces. 1 Tab character == 1 Level of nesting Space-based systems _can_ provide the equivalent semantic information if they are 100% consistent. ...but part of the argument in favor of spaces is that they allow an escape hatch of the strict indentation in order to allow pleasing visual alignments.
      - Guvante 5mo ago
        Tabs are not used consistently for nesting so your argument is missing some nuance. E.g. foo(//long function call\n\t//more parameters)
    - SOLAR_FIELDS 5mo ago
      > It is fundamentally important that convential commit is better for adopting it to be an improvement. Absolutely! Which means we can also agree that conventional commit is objectively better than No System For Their Commits At All, which is what 99.9% of people are actually choosing between when evaluating conventional commit. They aren’t looking at conventional commit vs Some Better Way, they are looking at “we have no standardization of commit messages” vs “we have standardization of commit messages”. For the 0.1% people for whom that’s not good enough, one hundred percent agree that these people should be pursuing better solutions.
- monooso 5mo ago
  I don't think it's reasonable to judge Conventional Commits on something it doesn't claim to do. I can't see any suggestion on the CC site [^1] that it "solve[s] the core issue of the poor commit messages problem." Rather, it's explicitly described as "a specification for adding human and machine readable meaning to commit messages." I'd say it accomplishes that modest goal. [^1]: https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/
xena 5mo ago
I end up thinking that conventional commits is a good idea because you can make tooling force people to at least put one iota of thought into what goes in a commit message. I've had to review so many commits with the subject "small fix" that was not in fact a small fix.
- deleted 5mo ago
  [deleted]
- BoingBoomTschak 5mo ago
  So now you'll get a lot of "fix: small", heh.
  - beart 5mo ago
    Most of the folks I caught pushing "changes" as a commit message are now letting AI write their commit messages for them. It has been a massive improvement.
deleted 5mo ago
[deleted]
mmcnl 5mo ago
Who reads commit messages anyway?
- theptip 5mo ago
  Maybe more people if the contract is that it’s how you get your work into the release notes?
- Izkata 5mo ago
  I work with legacy code and am regularly reading commit messages from 10-15 years ago while figuring out what was going on several teams past. It's also why I'm against squash-merges, there have been plenty of times a commit was in the middle of a chain of commits and the helpful context would have been erased if we had squashes in svn.
- ajuc 5mo ago
  Commit messages are usually more useful than code comments. For one thing they change when the code changes, so they are much less likely to lie.
theptip 5mo ago
I don’t have a horse in the race, but the OP objections ring hollow to me. - scope is important: true, but isn’t that derivable from the commit contents? An important sanity check on a diff is to look at the paths touched. (A “test” diff should not modify prod auth code.) but if you want to see this from —oneline, sure, I think feat(auth): is better than feat: - wrong audience: I don’t agree. feat commits _should_ actually describe the product-facing changes. You _should_ curate a nice stack with your no-op refactor changes first, then your small new feature change atop. This is the most helpful thing to include in a diff comment. You should put anything technical in comments so they are not lost, “why I chose algorithm X” belongs in a comment or DECISIONS.md. These are all tedious things that only psychos bother doing in a commit history at a fast moving company, but on OSS projects I think it’s much more important to stash context in the commit messages.
yolkedgeek 5mo ago
Sidenote: Although JSON is very common, I argue EDN is the best data format out there.
- compel2160 5mo ago
  Curious: what are the primary advantages you see?
  - accrual 5mo ago
    Not GP but I enjoyed reading through some details of EDN here, I hadn't studied it before: https://edn-format.dev/ https://edn-format.dev/
    - compel2160 5mo ago
      Yeah, I looked through the GitHub. I've used Clojure before so it seems pretty easy to pick up.
  - rmunn 5mo ago
    I'm not yolkedgeek but I can give my own answer: EDN has tags. Tags start with `#` and are followed by a symbol (which is a lot like an identifier except that a lot of punctuation is allowed in symbols, because EDN derives from Lisp syntax rules). The `/` character is used for namespacing, and a user-defined tag must use a namespace. The tag meaning is application-defined, but there are a couple standard tags with well-defined meanings: #inst "1985-04-12T23:20:50.52Z" = an instant / timestamp in RFC 3339 format #uuid "f81d4fae-7dec-11d0-a765-00a0c91e6bf6" = a GUID/UUID More tags could be defined by the standard later, because the entire unprefixed namespace is reserved. But just having a well-defined way to represent timestamps and UUIDs is an immense win over JSON, where you have to somehow know (based on what you were expecting to receive) that this string should be parsed as a timestamp or a GUID. Also, user-defined tags will often be used to represent a class: #myapp/Person {:first "Fred" :last "Mertz"} Again, no need to know (based on what you were expecting) that this particular object is an instance of Person; the data transfer format tells you what class it is. JSON has to add a field, and what field it is will vary from application to application so it's usually not possible to write a universal parser. One server might generate { "__type": "Person", "first": "Fred", "last": "Mertz } while another one does { "$$class": "Person", "first": "Fred", "last": "Mertz }, for example. EDN also has syntax defined for sets, but that's a smaller win over JSON, because it's not often necessary to declare that something is a set. Still, there are times it's helpful; it's certainly not a bad thing to have a set syntax. Also, EDN has comments built in to the system. Two kinds, one line-based comment (useful for actual comments, e.g. when you use EDN as a config format), and one that comments out the next thing in the file (useful for temporarily commenting out an entire section with a single token, or for removing ONE item temporarily from a list that's all on the same line so line-based comments are difficult). Because Douglas Crockford didn't envision JSON as being used for config, he forbade comments in JSON, and people have been coming up with competing proposals for putting comments back in ever since. (Thankfully, nearly all the proposals interoperate, because all of them sensibly use Javascript comment syntax, so it doesn't matter if the file is JSONC or HuJSON or JSON5, the comment syntax is the same). But the biggest win for EDN is tags, which can convey type information outside the data structure. JSON has to use something inside the data structure to convey type information, and there's always that small chance that the name chosen (__type or $$class or whatever) will collide with a property of the actual object that was supposed to be serialized.
markbao 5mo ago
I’m all for standardization but you could just use this argument to keep any suboptimal status quo in place. XML is good enough and a standard. SOAP is good enough and a standard. etc. The claim is that Conventional Commits are good enough and standardized enough that having another structure isn’t really worth it. But “worth it” is subjective. I’d say that if you are making commits and reading PRs every work day, and the conventional commits format causes a little bit of friction, that friction can add up. Having another option other than seeing conventional commits as a law of nature gives options for teams who prefer it. (Most teams aren’t generating changelogs anyway.)
- hn_throwaway_99 5mo ago
  The new structure needs to be "better enough" that it overcomes the built-in deficits of the older structure, and it can't introduce so many new problems that make it a net negative. JSON was definitely a huge improvement in simplicity and readability compared to XML for many contexts. Similarly REST a much better option than SOAP (and all of these are examples of the general over-engineered, design-by-committee architectures that came out of the late 90s/early 00s - see also the original EJB spec - before a larger trend towards simplicity and ease of use won out). But it this case, a lot of the differences just feel like potayto/potahto, i.e. minor stylistic preferences. And I have been in jobs where more than 50% of my time was doing code reviews, and while often there were e.g. some linter rules or whatever that I found suboptimal, it was a lot easier to just go with it than waste the energy to have the battle over why I think for loops are actually OK.
stefan_ 5mo ago
I don't need a standard for this. This is just noise. There are some people who have some sort of mental ailment that makes them obsessively want to introduce "structure" "scheme" "patterns" where it is just innately nonsense. You do you, but stop trying to force it on people. Reminds me of the "scrum master" adjacent folks who could never cut it writing code and then branched into all kinds of things like "Git Flow" when having never understood Git to begin with. Peak bikeshed territory.
- SoftTalker 5mo ago
  Reminds me of a place I worked at where a "naming committee" had to approve variable names. And no, you could not use "i" as an index in a one-line loop.
  - npstr 5mo ago
    i and j etc is bad though, but for a different reason than usually claimed. it's suboptimal because it's hard to search for. just use ii, jj, kk, etc
    - nemetroid 5mo ago
      \<i\>
    - ajuc 5mo ago
      If you need to search for a variable named i - you should have named it something else (and no, jj is NOT an improvement in that case). One letter variables are supposed to be used in scopes that fit on the screen completely. You might as well search for "for" TL; DR: it's on purpose.
      - xorcist 5mo ago
        Also the fact that every search function since the dawn of interactive computing can search for whole words only (like -w in grep or C-w in emacs).
      - 5mo ago
hexasquid 5mo ago
Introducing JSON scoped comments, far superior to JSON conventional comments. People who use those are our rivals.
SoftTalker 5mo ago
> Douglas Crawford Crockford.
yifanl 5mo ago
Some programmers prefer 2 spaces, some programmers prefer 4, why don't we compromise and pick a number between 2 and 4?
- Groxx 5mo ago
  hence tabs. just configure your display for the width you like. though I do wish more editors had some kind of "ignore the spacing, display it semantically like [this]" and just let you insert whatever you wanted, converted to whatever is nearby, and didn't touch lines you didn't create. there's no reason to even have the debate or care about inconsistencies, you can essentially always* convert between them losslessly in terms of behavior.
  - deleted 5mo ago
    [deleted]
  - Terr_ 5mo ago
    The next iteration is "smart tabs", where indents are stored as spaces in files for consistency, but when using an editor it recognizes that something special is going on, and offers you a tab-like experience.
    - Groxx 5mo ago
      which they kinda already do, yea. I just want it to be stronger, and to correct indentation that doesn't follow your formatting rules (which I have not seen / is not widespread). kinda like a `gofmt` overlay on a file, rather than modifying the file directly. as a bonus, this could also make `goto fail;` errors more obvious.
  - chrisweekly 5mo ago
    Given a choice between (spaces) and (mix of tabs and spaces) -- these being the only two options IRL -- it's not hard to see why spaces won.
- masfuerte 5mo ago
  π?
amadeuspagel 5mo ago
> Like the author is making a big deal that they think scope is more important than type. I may tend to agree, but I think the difference between "fix(compiler)" and "compiler fix" is not exactly a hill I'd be willing to die on. The big deal is not that scope is more important then type, the big deal is that natural language allows you to formulate things to emphasize whatever you consider important, and by forcing everything into a specific format this information is lost. There's a reason we have formats like markdown and plaintext, not just JSON.
- hn_throwaway_99 5mo ago
  Conventional Commits still have a free-form description section. The structure just introduces some standardized elements - and this is common in all types of written communication. Books have tables of contents, chapters have titles, letters have salutations, etc. etc.
scuderiaseb 5mo ago
Great perspective! As a sidenote, I really like json5 for everything that would be needed for a human to read and it has great support everywhere. It fixes so many of JSONs shortcomings like comments. Edit: forgot the link if anyone’s interested https://json5.org/ https://json5.org/
- hn_throwaway_99 5mo ago
  Agreed, I really feel JSON5 should just be the default standard. But the fact that it's still not means it can't be used in a bunch of places where it would be an obvious improvement, for example, in package.json files - and fwiw I don't understand the NPM team's objection to using it.
  - beart 5mo ago
    As long as the file extension changes to align with the format, that sounds great. There are far too many abuses of .json that allow comments, trailing commas, etc.
daveisfera 5mo ago
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" - Bjarne Stroustrup

olzhasar 5mo ago

Defined structure does not constitute quality. A commit message can be loosely structured, but be very insightful and good at communicating the nature of the change. On the flip side, one can make a very structured but confusing or non-informative commit message. I generally tend to agree with the author, conventional commits do not solve the core issue of the poor commit messages problem.

sharts 5mo ago
But it does enforce a minimum quality
- yencabulator 5mo ago
  Form != quality, as LLMs will happily demonstrate.
bloppe 5mo ago
Conventional commits made it easier to generate changelogs and automate semantic version bumps. I suppose LLMs can usually do that the right way with looser structure, but in the before times it made a lot more sense, and even now is much less ambiguous
- steveklabnik 5mo ago
  Both of these things are discussed in the article. (changelogs and semver)
  - mattrb 5mo ago
    They're hand-waved away by saying the changelogs are bad and the semver isn't always accurate. While I mostly agree with, that doesn't mean they don't provide _some_ value. You get categorized changelogs (even if the messages are technical) and semver that's generally correct. The alternative of good changelogs and perfect semver isn't free.
- xigoi 5mo ago
  Auto-generated changelogs from commit messages are bad, no matter if the commit messages follow some structure.
- Mawr 5mo ago
  I suppose it is a significant downside that you could get misled into thinking you can autogenerate a changelog from commit names.
bfeynman 5mo ago
why is "solving" the issue somehow the bar? software engineering has more practices rooted in psychology than engineering, its a moving and ambiguous target. Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics.
- Guvante 5mo ago
  Why undoubtedly? In what context does wasting your first characters on fix vs feat matter? PRs are going to have an explanation that has way more detail than necessary to figure that out quickly. One lines tend to be (for me) in a situation where the difference is immaterial. If I am rapid firing through history I need to know what you did not why you did it. Again I am not claiming that these are bad or even that they aren't good. I am specifically disagreeing that any change is automatically good, that isn't true.
- Merovius 5mo ago
  > Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics. I do not want to contribute to a project using conventional commits. I have consistently found, that I am unable to decide what the "type" of a commit even is and I feel unnaturally caged in into how I would split up commits, by having them be restricted to types (it doesn't help that the conventional commits I've seen appear to decide the type by fair dice roll). Discouraging contributions does not "undoubtedly improve contribution semantics".
  - shimman 5mo ago
    [flagged]
SOLAR_FIELDS 5mo ago
It’s the linting argument all over again. I don’t give a shit what the style is. I give a shit that it’s consistent. Form whatever opinion you want about how you want to format your code, structure commit messages etc. I don’t really care, if you want to start every commit with “poop(fix): pooper my commit message”, as long as you’re consistent about it and enforce it programmatically you have my emphatic support This comment assumes you are picking between a conventional commit message or something better. But the reality is you are almost always picking between a conventional commit and Nothing.
- Guvante 5mo ago
  That is only true of semantically equivalent things. Tabs vs spaces don't matter they are equivalent. But consistency is only better when it is an improvement. It is fundamentally important that convential commit is better for adopting it to be an improvement. After all in your example wasting the first four characters of your commits with poop would objectively reduce the quality of your commit history, whether or not it was consistent.
  - rablackburn 5mo ago
    > Tabs vs spaces don't matter they are equivalent. Just to nitpick (because what else is this thread about? :)) They aren't equivalent! Tabs carry more semantic information than spaces. 1 Tab character == 1 Level of nesting Space-based systems _can_ provide the equivalent semantic information if they are 100% consistent. ...but part of the argument in favor of spaces is that they allow an escape hatch of the strict indentation in order to allow pleasing visual alignments.
    - Guvante 5mo ago
      Tabs are not used consistently for nesting so your argument is missing some nuance. E.g. foo(//long function call\n\t//more parameters)
  - SOLAR_FIELDS 5mo ago
    > It is fundamentally important that convential commit is better for adopting it to be an improvement. Absolutely! Which means we can also agree that conventional commit is objectively better than No System For Their Commits At All, which is what 99.9% of people are actually choosing between when evaluating conventional commit. They aren’t looking at conventional commit vs Some Better Way, they are looking at “we have no standardization of commit messages” vs “we have standardization of commit messages”. For the 0.1% people for whom that’s not good enough, one hundred percent agree that these people should be pursuing better solutions.
monooso 5mo ago
I don't think it's reasonable to judge Conventional Commits on something it doesn't claim to do. I can't see any suggestion on the CC site [^1] that it "solve[s] the core issue of the poor commit messages problem." Rather, it's explicitly described as "a specification for adding human and machine readable meaning to commit messages." I'd say it accomplishes that modest goal. [^1]: https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/

xena 5mo ago

I end up thinking that conventional commits is a good idea because you can make tooling force people to at least put one iota of thought into what goes in a commit message. I've had to review so many commits with the subject "small fix" that was not in fact a small fix.

deleted 5mo ago
[deleted]
BoingBoomTschak 5mo ago
So now you'll get a lot of "fix: small", heh.
- beart 5mo ago
  Most of the folks I caught pushing "changes" as a commit message are now letting AI write their commit messages for them. It has been a massive improvement.

deleted 5mo ago

[deleted]

mmcnl 5mo ago

Who reads commit messages anyway?

theptip 5mo ago
Maybe more people if the contract is that it’s how you get your work into the release notes?
Izkata 5mo ago
I work with legacy code and am regularly reading commit messages from 10-15 years ago while figuring out what was going on several teams past. It's also why I'm against squash-merges, there have been plenty of times a commit was in the middle of a chain of commits and the helpful context would have been erased if we had squashes in svn.
ajuc 5mo ago
Commit messages are usually more useful than code comments. For one thing they change when the code changes, so they are much less likely to lie.

theptip 5mo ago

I don’t have a horse in the race, but the OP objections ring hollow to me. - scope is important: true, but isn’t that derivable from the commit contents? An important sanity check on a diff is to look at the paths touched. (A “test” diff should not modify prod auth code.) but if you want to see this from —oneline, sure, I think feat(auth): is better than feat: - wrong audience: I don’t agree. feat commits _should_ actually describe the product-facing changes. You _should_ curate a nice stack with your no-op refactor changes first, then your small new feature change atop. This is the most helpful thing to include in a diff comment. You should put anything technical in comments so they are not lost, “why I chose algorithm X” belongs in a comment or DECISIONS.md. These are all tedious things that only psychos bother doing in a commit history at a fast moving company, but on OSS projects I think it’s much more important to stash context in the commit messages.

yolkedgeek 5mo ago

Sidenote: Although JSON is very common, I argue EDN is the best data format out there.

compel2160 5mo ago
Curious: what are the primary advantages you see?
- accrual 5mo ago
  Not GP but I enjoyed reading through some details of EDN here, I hadn't studied it before: https://edn-format.dev/ https://edn-format.dev/
  - compel2160 5mo ago
    Yeah, I looked through the GitHub. I've used Clojure before so it seems pretty easy to pick up.
- rmunn 5mo ago
  I'm not yolkedgeek but I can give my own answer: EDN has tags. Tags start with `#` and are followed by a symbol (which is a lot like an identifier except that a lot of punctuation is allowed in symbols, because EDN derives from Lisp syntax rules). The `/` character is used for namespacing, and a user-defined tag must use a namespace. The tag meaning is application-defined, but there are a couple standard tags with well-defined meanings: #inst "1985-04-12T23:20:50.52Z" = an instant / timestamp in RFC 3339 format #uuid "f81d4fae-7dec-11d0-a765-00a0c91e6bf6" = a GUID/UUID More tags could be defined by the standard later, because the entire unprefixed namespace is reserved. But just having a well-defined way to represent timestamps and UUIDs is an immense win over JSON, where you have to somehow know (based on what you were expecting to receive) that this string should be parsed as a timestamp or a GUID. Also, user-defined tags will often be used to represent a class: #myapp/Person {:first "Fred" :last "Mertz"} Again, no need to know (based on what you were expecting) that this particular object is an instance of Person; the data transfer format tells you what class it is. JSON has to add a field, and what field it is will vary from application to application so it's usually not possible to write a universal parser. One server might generate { "__type": "Person", "first": "Fred", "last": "Mertz } while another one does { "$$class": "Person", "first": "Fred", "last": "Mertz }, for example. EDN also has syntax defined for sets, but that's a smaller win over JSON, because it's not often necessary to declare that something is a set. Still, there are times it's helpful; it's certainly not a bad thing to have a set syntax. Also, EDN has comments built in to the system. Two kinds, one line-based comment (useful for actual comments, e.g. when you use EDN as a config format), and one that comments out the next thing in the file (useful for temporarily commenting out an entire section with a single token, or for removing ONE item temporarily from a list that's all on the same line so line-based comments are difficult). Because Douglas Crockford didn't envision JSON as being used for config, he forbade comments in JSON, and people have been coming up with competing proposals for putting comments back in ever since. (Thankfully, nearly all the proposals interoperate, because all of them sensibly use Javascript comment syntax, so it doesn't matter if the file is JSONC or HuJSON or JSON5, the comment syntax is the same). But the biggest win for EDN is tags, which can convey type information outside the data structure. JSON has to use something inside the data structure to convey type information, and there's always that small chance that the name chosen (__type or $$class or whatever) will collide with a property of the actual object that was supposed to be serialized.

markbao 5mo ago

I’m all for standardization but you could just use this argument to keep any suboptimal status quo in place. XML is good enough and a standard. SOAP is good enough and a standard. etc. The claim is that Conventional Commits are good enough and standardized enough that having another structure isn’t really worth it. But “worth it” is subjective. I’d say that if you are making commits and reading PRs every work day, and the conventional commits format causes a little bit of friction, that friction can add up. Having another option other than seeing conventional commits as a law of nature gives options for teams who prefer it. (Most teams aren’t generating changelogs anyway.)

hn_throwaway_99 5mo ago
The new structure needs to be "better enough" that it overcomes the built-in deficits of the older structure, and it can't introduce so many new problems that make it a net negative. JSON was definitely a huge improvement in simplicity and readability compared to XML for many contexts. Similarly REST a much better option than SOAP (and all of these are examples of the general over-engineered, design-by-committee architectures that came out of the late 90s/early 00s - see also the original EJB spec - before a larger trend towards simplicity and ease of use won out). But it this case, a lot of the differences just feel like potayto/potahto, i.e. minor stylistic preferences. And I have been in jobs where more than 50% of my time was doing code reviews, and while often there were e.g. some linter rules or whatever that I found suboptimal, it was a lot easier to just go with it than waste the energy to have the battle over why I think for loops are actually OK.

stefan_ 5mo ago

I don't need a standard for this. This is just noise. There are some people who have some sort of mental ailment that makes them obsessively want to introduce "structure" "scheme" "patterns" where it is just innately nonsense. You do you, but stop trying to force it on people. Reminds me of the "scrum master" adjacent folks who could never cut it writing code and then branched into all kinds of things like "Git Flow" when having never understood Git to begin with. Peak bikeshed territory.

SoftTalker 5mo ago
Reminds me of a place I worked at where a "naming committee" had to approve variable names. And no, you could not use "i" as an index in a one-line loop.
- npstr 5mo ago
  i and j etc is bad though, but for a different reason than usually claimed. it's suboptimal because it's hard to search for. just use ii, jj, kk, etc
  - nemetroid 5mo ago
    \<i\>
  - ajuc 5mo ago
    If you need to search for a variable named i - you should have named it something else (and no, jj is NOT an improvement in that case). One letter variables are supposed to be used in scopes that fit on the screen completely. You might as well search for "for" TL; DR: it's on purpose.
    - xorcist 5mo ago
      Also the fact that every search function since the dawn of interactive computing can search for whole words only (like -w in grep or C-w in emacs).
    - 5mo ago

hexasquid 5mo ago

Introducing JSON scoped comments, far superior to JSON conventional comments. People who use those are our rivals.

SoftTalker 5mo ago

> Douglas Crawford Crockford.

yifanl 5mo ago

Some programmers prefer 2 spaces, some programmers prefer 4, why don't we compromise and pick a number between 2 and 4?

Groxx 5mo ago
hence tabs. just configure your display for the width you like. though I do wish more editors had some kind of "ignore the spacing, display it semantically like [this]" and just let you insert whatever you wanted, converted to whatever is nearby, and didn't touch lines you didn't create. there's no reason to even have the debate or care about inconsistencies, you can essentially always* convert between them losslessly in terms of behavior.
- deleted 5mo ago
  [deleted]
- Terr_ 5mo ago
  The next iteration is "smart tabs", where indents are stored as spaces in files for consistency, but when using an editor it recognizes that something special is going on, and offers you a tab-like experience.
  - Groxx 5mo ago
    which they kinda already do, yea. I just want it to be stronger, and to correct indentation that doesn't follow your formatting rules (which I have not seen / is not widespread). kinda like a `gofmt` overlay on a file, rather than modifying the file directly. as a bonus, this could also make `goto fail;` errors more obvious.
- chrisweekly 5mo ago
  Given a choice between (spaces) and (mix of tabs and spaces) -- these being the only two options IRL -- it's not hard to see why spaces won.
masfuerte 5mo ago
π?

amadeuspagel 5mo ago

> Like the author is making a big deal that they think scope is more important than type. I may tend to agree, but I think the difference between "fix(compiler)" and "compiler fix" is not exactly a hill I'd be willing to die on. The big deal is not that scope is more important then type, the big deal is that natural language allows you to formulate things to emphasize whatever you consider important, and by forcing everything into a specific format this information is lost. There's a reason we have formats like markdown and plaintext, not just JSON.

hn_throwaway_99 5mo ago
Conventional Commits still have a free-form description section. The structure just introduces some standardized elements - and this is common in all types of written communication. Books have tables of contents, chapters have titles, letters have salutations, etc. etc.

scuderiaseb 5mo ago

Great perspective! As a sidenote, I really like json5 for everything that would be needed for a human to read and it has great support everywhere. It fixes so many of JSONs shortcomings like comments. Edit: forgot the link if anyone’s interested https://json5.org/ https://json5.org/

hn_throwaway_99 5mo ago
Agreed, I really feel JSON5 should just be the default standard. But the fact that it's still not means it can't be used in a bunch of places where it would be an obvious improvement, for example, in package.json files - and fwiw I don't understand the NPM team's objection to using it.
- beart 5mo ago
  As long as the file extension changes to align with the format, that sounds great. There are far too many abuses of .json that allow comments, trailing commas, etc.

daveisfera 5mo ago

"There are only two kinds of languages: the ones people complain about and the ones nobody uses" - Bjarne Stroustrup