haxscramper

As someone who has been writing nim for many years now, using grep, rg, and various other search tools I can say that I've never had any issues with finding things I wanted. This is just one of those imagined issues that your realize doesn't exist when you actually try to do it.

This is not really true, most of the times the discussion goes like this

Q: "Why haven't you implemented feature X -- python has it, so nim should too"

A: "Nim is not python, it is a different language, not all things implemented there are good, so we don't implement everything"

So this is not "against python" it is against specific attitude towards nim where people think it should be a python clone instead of a separate language

Somehow I missed this (very noticeable actually) non-algorithmic toggle button until I saw your comment, so many thanks for mentioning this.

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?

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

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.

There is no singular "story" here, mostly several former contributors decided for one reason or another (of course there are a lot of small "stories" behind this, but writing them all down would just come out as being "disgruntled people" (as already theorized in one of the top comments) to most readers) to spend their own time in a different projects.

We are certainly not opposed to this, although some of the more fundamental structural changes in the codebase might temporarily hurt the stability - this was one of the friction points with the mainline. While stability is important it was never clear where sound judgment ends and "don't touch this 14+-year-old code transpiled from Pascal" begins. We are almost a year in and among several former contributors we still sometimes have troubles figuring out the logic behind certain decisions. Now imagine doing all the digging and expecting to fight an uphill battle to prove the necessity of the changes. Maybe if we do it in the nimskull then mainline decides to adopt some of the improvements after seeing their real worth.

That is a correct interpretation, we decided some humor won't hurt at the start, and it certainly wasn't as venomous (aka "death to nim") as parent comments suggested

Actually the phrasing in the readme is not correct - I will change it later, but now I want to say that the objective is not deleting "much" of it, but rather cleaning up old and deprecated modules, or providing alternative solutions (for things like os/json that historically were a point of friction).

I can't remember exact place where I've seen this discussion (I think it was on the nim IRC), but if I recall correctly, the original line of thought with nim was to take C (because fast/compiled/available-everywhere) and LISP (because flexible/extensible/good-ideas) and add more syntax sugar, so that user would not have to reimplement most of the syntax from scratch (using reader macros/special functions and so on).

There are of course a lot of other languages that influenced the syntax and semantics (like Ada, python, C++ and so on), and I omitted a huge number of extra considerations.