[haxscramper]

!: this is mostly a personal note although I am one of the nimskull contributors

For now the aim of this project is first and foremost refactoring and making it easier to contribute and improve the main code base of the compiler, as indicated by the "near-term" timeline that is shown in the readme.

This is mostly a disclaimer for the common reaction that invariably starts to move the discussion in the direction of "why not contribute to mainline instead", "disgruntled people" etc. etc.

At the moment we are focused on making it easier to work with the codebase - more documentation, cutting down on decades-old cruft and legacy features, unraveling mysteries of the commit messages that were written with this attitude https://github.com/nim-lang/Nim/pull/19211#issuecomment-9859... ("I have no intention to follow this guideline so I cannot accept it.")

Applying data-oriented design principles, writing a specification, providing guides for compiler developers https://nim-works.github.io/nimskull/debug.html and focusing on what is important for people who work in the project.

At least that's why I work on nimskull. I don't want to go into another round of "stories" that describe some interpersonal issues (which of course exist) and we explicitly opted to keep this our of readme as well, even though other might be interested in dirty details.

[seertaak]

I think it's great that you're tinkering with a compiler. But a language is more than a compiler; good language design requires a lot of programming experience, good taste and intuition, an ability to absorb programming language theory, and, yes, good programming skills. Araq has proven that he is a very capable language designer.

It sounds like you're taking Araq to task for trying out new things. And indeed, Nim is certainly a fairly expansive language. But a lot of the things he's trying are really cool, and I want to see the person with the _actual vision_ get a chance to try those things out without being encumbered by the need to write laborious commit message, because "democracy" and "best practices". Between Araq spending a marginal x minutes doing more on value types, and writing "clearer" commit messages, I'll choose the former, any day. I also trust him to jettison ideas that don't work.

I really think it's red flag when someone proposes to fork a language without being able to offer single reason that's actually related to language design. Sorry, I do realize this may come across as a bit aggressive, but I'm inclined to view you as a presumptious ingrate.

And really: when you come up with an original language that captures the imagination of scores of developers, I'll pay you the same respect.

[haxscramper]

Right now we are not forking "the language" as a collection of ideas etc. as you seem to think. Instead we are doing a much simpler thing - we are forking "the code". Of course former is built on latter, but current focus is making codebase usable for other contributors.

The main difference here seems to be that I interpret the need to "write laborious commit message" as a basic human decency that shows I'm respect other people's time. Five minutes on "value types" is not a lot all things considered, but pretty much enough to write the commit message.

This attitude always puzzled me to be honest - you just spent half an hour, maybe more, to write the code and have a good understanding of what you had just done and for which reasons. How hard would it be to sit down and type it out and save time for someone who comes next?

[otherme123]

Araq can be harsh sometimes, but what I'm reading in the linked github thread is a developer who at first doesn't see value in the PR (4th of december) but accepted the PR two days latter after being shown evidence that he was wrong. He didn't entrench, closed the PR without further discussion or requested an unreal ammount of proofs, which I have faced in a number of other projects. He just said: "so I'll try to follow this new guideline" and accepted the PR.

[haxscramper]

That does not magically rewrite all previous commit messages, although apparently the improvement is present https://github.com/nim-lang/Nim/commits?author=Araq - most of the total ~25 comments made in the last seven months since December 9, 2021 have more or less legible titles.

[asojfdowgh]

So nimskull is planning on rewriting all previous commit messages to be more legible? Or is that unreasonable?

Assuming unreasonable, isn't it unreasonable to expect someone to completely break git history for everyone, and or invent time travel?

Seems to be an absurd amount of condemnation over a mistake that did far less than hurting no-one

[bragr]

That's not what he's saying at all. He's saying that the maintainer now has better commit messages, but there is still a need to go back and produce documentation for undocumented code with inscrutable commit messages. e.g. doing better now does not undo prior damage

[asojfdowgh]

ok, how?

ok, why can that method that you choose not be applied to nim?

[haxscramper]

On how: The "method" is to just respect the future contributors from the start, instead of waiting for ten years until someone tells you to write better messages.

Why can't it be applied: no idea, writing sensible commit messages seems like a basic necessity if your goal is sustainable project development, but that's just me

[dmos62]

> unraveling mysteries of the commit messages that were written with this attitude https://github.com/nim-lang/Nim/pull/19211#issuecomment-9859...

Curious to know what your vision of commit messages is. My commit messages look exactly like the excerpt in your linked issue: they describe what has been done.

[masklinn]

> Curious to know what your vision of commit messages is.

Not GP, but the postgres project is a pretty good example of what I strive for:

- a title explaining what the commit does (possibly expanding into the body if details would be useful)

- plus the body explains the background for the change (the why), ideally at all levels of resolution e.g. if it’s a 1 line fix to something deep inside the bowels try to trace the path from the original high-level report or issue, then why it was fixed where it was (especially if it took ages to track down and / or decide)

- and if useful or necessary, discussions of the implementation details / options / considerations

If there’s a mailing list thread, or a bug tracker issue, it should be included, but it should not be necessary: IME it’s way more common for the log than the bug tracker to survive the sands of time, because converting history from one VCS to the next is generally relatively easy.

[benibela]

That reminds me of another project. Whatever you do, do not write the commit messages like that, and your are doing great: https://github.com/BeRo1985/pasvulkan/commits/master

[scotty79]

Not everybody treats fixing software just as an excuse for writing detailed flowery diary of the development process itself consisting entirely of artisanal, handcrafted git commit messages.

Some people just fix software to fix software and for them the whole utility of git is to be able to see how the code looked earlier or even just keeping it in case they ever want to know that. They don't write commit messages because they don't read commit messages because they'd rather read code than prose. Trying to figure out what someone meant when they wrote the comment is sometimes harder than reading the code change itself. And if you need to delve deep into the prose here's the ticket number with all the words that were exchanged that lead to this change.

[dmos62]

Someone's doing work.

[WesolyKubeczek]

My commit messages:

Fixes

Fixes

Fixes

Fix the fix

Frstegdghdsgsffff

More work

Fixes

Fixes

[haxscramper]

Commits message guidelines are a part of the contribution guidelines and are available in the documentation (linked in the GitHub page). Concrete application of said guidelines can be seen in the commit message history.

[severak_cz]

It would be nice if difference of code/features were described in some human readable form. E.g. there were various forks of DosBox which added some other features.