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

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.

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

!: 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 better phrasing would indeed be something like "several former core developers" - of course we can't really measure up to the size of the original community, and don't yet have any paid developers (like Araq and narimiran [1] in the mainline - although since the end of September there were not a lot of activity on their part as well - [2] ~30 commits (~23 that are marked `[backport]`) and even less [3] for narimiran)

[1] https://forum.nim-lang.org/t/8540#55418

[2] https://github.com/nim-lang/Nim/commits/devel?author=Araq

[3] https://github.com/nim-lang/Nim/commits/devel?author=narimir...

Right now, it seems like most of the work on the mainline seems to be done by community members.

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).

No, never. Actually the most problem I've ever had with this feature is seemingly unending discussions that come up in almost every single HN discussion ever, like https://news.ycombinator.com/item?id=28651040

> would make grepping harder on larger projects

There is a built-in tool `nimgrep`, but honestly I never even need for that - `rg` worked perfectly fine each time I had to do something like that.

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.

Adjacent comment already has a list of concrete libraries/frameworks for large number of areas, so I just want to mention that nim has a very good metaprogramming capabilities, and if the /language/ itself does not feel up to the task you have a lot more freedom when it comes to implementing things. So it really comes down to the community size and amount of money poured in the development, and not fundamental problems with the language design.

This is mostly an argument about "technically you can write anything with anything", except in nim's case it is also backed by extremely high flexibility.

EDIT: by flexibility I mean

- different backends they covet very huge ecosystems (Js and C, and by extension anything they you can interface with using C (like python))

- already mentioned metaprogramming

- support for low-level convenience features like custom operators

- different memory management options. If you want you can turn off automatic mm completely and write code that deals with pointers and stuff like that directly

- more niche things like support for embedding nim interpreter in your programs https://peterme.net/using-nimscript-as-a-configuration-langu...

This way you can write json literals in the code, and it will look just like regular json. For serialization and deserialization stdlib uses `to/load/store` proc names.

  import std/json

  echo %*{
    "key1": "value",
    "key2": 12,
  }

It does affect identifiers, built-in keywords and type names in the same manner, though it is completely beyond me why anyone would write 'tY_PE Position = tUPLE[x, y: iNt]'.

If we are going to dismiss any nontrivial behavior as "sure very simple" then sure, having two distinct incompatible ways to write get_name (or getName) looks better.

It does not "randomly" not affect first character. Most style guides for camel/pascal case treat first character differently, with types being capitalized and regular variables starting in lowercase. Making whole identifier style-insensetive would significantly reduce number of possible names. So this rule makes 'building' and 'Building' different, but at the same time does not differentiate between 'get_name' and 'getName'.

> Yeah because nobody ever imports code from other projects, copy/pastes from StackOverflow etc. /s

I don't understand your point (even considering /s) - if I do import code from my other projects or copy-paste it from somewhere it simply doesn't matter to me what style they used - I'm not required to fix copied code, or adapt to the style my dependencies use.

> So why do you need case insensitivity??!

If their code gets into larger ecosystem it will not affect anything else, or at least it's effects would be minimized. It is a win-win solution - library author uses their preferred style, I (and everyone else in the ecosystem) stick to common convention, and everyone bis happy.

> Trust me this is a decision they will regret.

I've been using nim for multiple years now, and I have never seen anyone actually regretting this. Of course, when new people come to the language they sometimes are really surprised by this, but rarely ever complain about this in the long run.

EDIT: forgot to mention that nim is more than a decade old language, and "decision they will regret" should have happened years ago, yet it does not seem to be the case.

Another nim & python thread that has not been mentioned yet here

https://news.ycombinator.com/item?id=28506531 - project allows creating pythonic bindings for your nim libraries pretty easily, which can be useful if you still want to write most of your toplevel code in python, but leverage nim's speed when it matters.

If you want to make your nim code even more "pythonic" there is a https://github.com/Yardanico/nimpylib, and for calling some python code from nim there is a https://github.com/yglukhov/nimpy

> Do you enjoy the tabs vs spaces debate? How about single quote Vs double quotes? Ugly inconsistently styled code?

Nim solved tabs/spaces debate by allowing only spaces. Single/double quote are also completely separate, so there is no inconsistency as well. About "inconsistently styled code" - due to style insensitivity, effects are not viral. If you depend on a library that uses `get_name` but your project adopted `getName()` your don't need to suffer.

> Unicode case insensitivity is actually really really complicated

Which is why nim only handles case insensitivity for ASCII identifiers and not Unicode. Which makes sense because 99.9% code is written in ASCII.

> The case insensitivity rules are usually super complicated and don't apply to everything

Quoting from the manual - "only the first letters are compared in a case-sensitive manner. Other letters are compared case-insensitively within the ASCII range, and underscores are ignored." Unicode is not handled in style-insensetive manner, so the rule is pretty simple.

> It makes searching for identifiers harder. For Nim you can't even use case insensitive search because of the underscore thing!

Technically true, but in reality this comes up so rarely, I didn't have any issues with this ever. Nim projects usually adopt camel/pascal case.

For some reason, people often assume that allowing style insensitivity instantly throws the whole language ecosystem in complete disarray and everyone starts writing code mixing every possible style of writing at once, swapping styles on every second identifier just for their amusement.

While I don't claim to have a comprehensive numbers, I did a quick `rg` on a full clone of nimble package list, and found that macros constitute approximately 0.4% of all definitions (functions, procedures, templates, methods).

  proc:      401673
  macro:     1869
  template:  16255
  func:      8746
  converter: 3538
  iterator:  1833
  method:    9025

You would be surprised how much can be accomplished just using simpler language constructs - even for the complex operations. Manual for example advises to use the least powerful construct for the job https://nim-lang.org/docs/manual.html#macros-caseminusof-mac...

  > Style note: For code readability, it is the best idea to use the least powerful programming construct that still suffices. So the "check list" is:

  >    Use an ordinary proc/iterator, if possible.
  >    Else: Use a generic proc/iterator, if possible.
  >    Else: Use a template, if possible.
  >    Else: Use a macro.

Also - notable portion of the commonly used macros is for embedded DSLs that in other languages would require you to use a separate build step with some external tool, or give way to horrible clutches like operator overloading-based DSL.

Note that I did the full clone several months back, and it is missing around two hundred packages that were added in this time, but I doubt it changes numbers greatly.

Using nim pattern matching library to implement simple dataflow programming DSL.