Community splits around concrete technical choices (e.g. NeoVim, and use of Lua as a scripting language) SOMETIMES survive and thrive.
Forks that seem to exist for no clear reason other than disgruntled person(s) thumbing their nose at an upstream maintainer never do.
If this were meaningful, then there would be clear roadmap (at least high-level aspirations without dates) announced with the repo’s creation. Without that, this is little more than a gripe post on a Nim mailing list.
There is a chance that this fork could be similar to egcs, following the same trajectory as "Nim done better" evolving into "the current Nim variant/implementation".
Conservative improvements like specifying some dark corners better can attract users (more than flamboyant novel features), and correction of bugs can retain them.
It generally seems to the latter case with mostly disgruntled people with some areas where they were passionate. It doesn't seem to be "producing" anything, so it doesn't appear to be like NeoVim or similar. The Nim compiler/core seems to be progressing still and not stagnating.
!: 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.
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.
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?
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.
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.
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
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
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.
> 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.
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.
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.
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.
Perusing the Nim discord, it looks like some of the people behind this project were once Nim devs (think maintainers), but this project is also considered unusable and constantly under development. There is also talk about Nim not accepting PRs soon enough, and knowing ahead of finishing your work that your PR will be approved with NimSkull.
I could spend more time looking, but really these are the sort of things that should be in their own readme in plain English instead of leaving me and everyone else who has no context confused.
AFAICT, it's an opinionated refactoring of the core because... Reasons.
The devs might want to consider the lost time, and ultimate impact, of Flickr rewriting its internals for... Similar reasons. Sure, the project may seem unwieldy, but major refractors or rewrites are never worth it.
Courageous, but seems to be an immature decision and tactic to me. They haven't even figured out a name for the project and chose to instead signal "death to nim".
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
It "wasn't as venomous" .. implies there was some venom, and that you are not being truthful in the first half of your comment, because you actually meant to call Araq a numbskull.
Bugs Bunny is the source of a lot of weird misconceptions.
Example: people think rabbits mostly eat carrots because Bugs Bunny likes to snack on them while leaning on something and saying "What's up, Doc?". Except Bugs doing that was a reference to a movie where Clark Gable... ate carrots while leaning on a fence and calling people Doc.
And somehow a parody of a Clark Gable movie turned into most people believing that carrots are a staple of leporine diets.
Right, irony and sarcasm are universal (afaik). But I had in mind that americans tend to use e.g. “so bad” in a sense of “so good”, which is not so ubiquitous. (I’m only familiar with English, Russian, Deutsch and Tatar really, so my thought is limited to these four.)
One summer when I was at Bloomberg, there was an announcement that some interns had been assigned to implement an internet sarcasm detector, and that they had been completely successful. No one questioned it.
To me it seems like the people who created the fork may literally not have any known means of judging engineering merit aside from how detailed commit messages are.
If it's a large group then detailed commit messages are critical. If it's likely that between 0-1 people are actually going to read the message in the next month and there are a long list of other plans you have to implement with between 0 and 1 people actually helping you, then the value of more detail in commit messages moves toward the limit of 0.
I don't get the concrete failings of nim from the readme. Even though I have one of my own: They should have adopted a python-style import system and not a C-style omnibus import system. You don't always have a properly configures IDE by your side to resolve imports.
Qualified imports don't work well with uniform call syntax. How would you write "foo-bar".split("-") with full qualification? "foo-bar".(strutils.split)("-") ?
> They should have adopted a python-style import system and not a C-style omnibus import system. You don't always have a properly configures IDE by your side to resolve imports.
I've had this issue with Python as well, if you use virtualenv for enough projects, you might just run into it, PyCharm is an amazing IDE but sometimes I have to literally reconfigure it a dozen times because it defaults to this or that, or in the more famous case I had: an API written for Python 2 vs a web service written for Python 3 and it was problematic to switch context because you had to change interpreter for entire project, though debugging the two was no issue. I suppose the more obvious fix would of been for me to open the client library directory in a separate PyCharm IDE instance in retrospect, but my point being, even Python can run into this under niche circumstances.
This fork reminds me of the Ayo[1] fork on Nodejs. At least NimSkull actually has some plans/motivation to do work beyond adding an administrative document.
this is sad.
Nim deserves to get a lot more traction than it does now, and a distraction like this will just muddle search results and give a false impression of immaturity. could the forkers express their grievances and the steps they have taken to resolve them before?
They aren't. They are doing the exact opposite. The original version is free to continue as it pleases, free of annoying disruptions.
This process is literally the most fair and least offensive thing possible, and yet people still try to make it some kind of wrongdoing.
If they had tried to alter the original project to suit themselves, you would have said "they can just fork if they don't like it"
So what you're really saying is they should just shut up and like whatever already exists and neither change it to suit themselves, NOR go off and make their own thing. I have some bad news, saying that is about 1000x more offensive than forking something.
There is just not one tiny microscopic shred of validity to this line of thinking.
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.
nim is a nice language. but the lack of consensus amongst small languages is why they never get adopted. and people wonder why stick with c++ ? because c++ comes with a kitchen sink of features and you pick what suits you and never worry about adoption cz it works everywhere
I read through the wordy description and still feel more confused about why they did this. I also feel like missed the opportunity to call their language "Rod" in reference to Nim's original name Nimrod.
I assume they didn't like something about the maintainer or the community.
Nim has a plan to add incremental compilation, saving the compiler state in files with the .rod extension. So naming a derived language Rod would be confusing.
It's a bunch of people who like working on the compiler, working on the compiler. Nim proper doesn't have as much flexibility to make breaking changes, and this has limited much-needed internal refactoring.
There was a falling out between some developers on the Discord that led to personal attacks and an eventual banning a while back. If I recall, nimskull started shortly after, and has attracted a few other compiler developers since.
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.
I don't think this is common nomenclature outside crypto, but if I had to guess the distinguishing factor is that (according to their FAQ) they don't intend to merge upstream changes into the fork. So basically completely separate development histories from this point on.
No, the crypto community took this term from the FOSS community, particularly due to how coins that did hard fork are open source (usually) and they did exactly what you stated, not intending to merge upstream changes into the fork.
Forks that seem to exist for no clear reason other than disgruntled person(s) thumbing their nose at an upstream maintainer never do.
If this were meaningful, then there would be clear roadmap (at least high-level aspirations without dates) announced with the repo’s creation. Without that, this is little more than a gripe post on a Nim mailing list.