Hacker News Reader

Comment by andybak | Hacker News Reader

It's feels like a shame to me that the one Python maxim that Nim has chosen to reject is "there should be one and preferably only one way to do it" - from this flows so much of the other goodness of the Python ecosystem. I worry that some of the metaprogramming magic that Nim allows will result in the loss of that feeling that I can view source on almost any 3rd party Python code and immediately feel like I can follow what's going on. Maybe community standards can help restrain this somewhat.

Also:

> mapWidth, mapwidth and map_width all map to the same name

Why or why? Editors and IDEs now need Nim-aware search code!?

View on HN

> "there should be one and preferably only one way to do it"

In my very humble opinion this idiom is amazing at the start of a language and then it handcuffs it and that is why we have Python 2 or Python 3 issues.

I use to use Python for statistical work and about 2 years ago I switched to R. R is VERY flexible and seen a huge change over the last 5 or so years. It has changed for me especially in the last 6 months with changes in what libraries I use. Using dplyr and other libraries my code is night and day different. We now have piping with %>% that changes me code completely and makes it MUCH more readable and quick to write code. I don't see anything like this happening quickly in Python.

When you write code that's intended to be maintained for years, a degree of resistance to shifting language idioms should be considered a feature. That's not to say that Python itself is the greatest language for long-term maintainability, but I personally have both years-old Python code and years-old R code, and any thoughts of doing maintenance on the latter fills me with trepidation.

But when it comes to short-term, one-off, or unimportant tasks, I agree that an emphasis on flexibility is welcome. There's a reason that TIMTOWTDI works so well for Perl in its original role as a shell scripting language.

On the other hand, it's quite convenient if you can't remember the exact name and it saves you a look-up e.g. quick_sort vs quicksort vs quickSort - either work

I do not get it - what kind of "win" is it? For example, I know that PHP functions are case-insensitive, but we got to the point where we run linters to check if we used the same case as in declaration. Why not simply bake it in the compiler, especially when you HAVE a compiler?

Perhaps it's a reaction to the state of affairs in C++.

In Java and C# there are pretty widely adhered to coding standards. It's quite hard to find libraries that don't have consistent public APIs with these standards, and those that differ are usually subject to rumblings on their mailing lists and issue trackers.

In C++ there is no agreed upon standard. The standard library uses lower_train_case for all (public) types/members, and much 3rd party library code uses PascalCase and camelCase. The C++ standard library has fewer features than the Java/C#/Python standard libraries, and so you end up bringing more 3rd party code into non-trivial projects (in my experience).

If this feature existed in C++, a codebase could be much more internally consistent. However I'm still not sure I'd like this feature to be available. Certainly it's not possible to add it after-the-fact due to potential conflicts between members that differed by case.

I have a vague theory that the design of most programming languages can be understood as a reaction to the pain their designers experienced in their previous language. So, Java is largely C++ without the things that were painful in C++ (manual memory management, multiple inheritance, operator overloading). Nim's unusual handling of compound names is a reaction to something else that was painful in C++.

Hopefully they'll add a Smalltalk/Objective C style format one day.

That means that all three forms will wind up in any Nim project that gets large enough, though. Hardly a good thing.

If they all work, does it even make a difference? Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form.

Well, it's harder to grep, for one (although far from impossible).

It has little benefit and requires new tooling to do simple refactoring like "rename".

> Besides it would be trivial to write a refactoring tool that can autoreplace all instances with the preferred form.

This should be part of the language if it's being so lax with identifier uniqueness. And if it's so trivial, you should write it so people can't complain anymore.

I don't get why people get so worked up over this. It's not a "little" benefit in my opinion. In regards to drawbacks I can only see one, and that is grepping for the identifiers becomes more difficult.

> It's not a "little" benefit in my opinion

Could you explain it, then? An identifier refers to a single thing. I don't see having multiple ways to refer to that identifier as a win AT ALL—it may be a win for people who are too lazy to learn their own code base, but it makes code hard to read, hard to maintain, and hard to refactor.

Meanwhile, having an identifier unique makes it easy to index, easy to manipulate.

I don't understand why you think it makes code hard to read. In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things? The idea behind this "style insensitivity" is that amyAtePizza has the same meaning as amy_ate_pizza. Why should it be distinguished in a programming language?

> In what situation would a code base use fooBar and foo_bar as two different identifiers meaning two completely different things?

You don't. It's a terrible idea to mix naming conventions.

> amyAtePizza has the same meaning as amy_ate_pizza.

WHY?! What possible benefit could it have? Why would you be mixing styles in the first case? Why can't you just remember which style hopefully your entire code base uses?

I wouldn't mix styles inside my own code base. But what if I am using somebody else's library which uses a different style? The benefit is that I can then use the style I have been using in my code base to call the functions in that library without mixing naming conventions.

I hope you never move code between different code bases, then.

Wouldn't it be a lot simpler to have a single style?

I think it will put more cognitive load on the humans who read the code. Instead of doing a quick visual comparison to see if identifiers are the same, programmers will need to actually comprehend the two tokens, and then transform them in their head to see if they are the same. This sounds minor, but I think the cognitive load can add up. Visually comparing two tokens is not quite conscious thought, while comprehension is. It's something you'll always need to think about when reading code.

You don't understand how having multiple highly-different forms for each name is harder to read? People read a token at a time whenever possible.

Nobody is arguing that you should be able to use multiple forms for different variables. They're arguing that you shouldn't use multiple forms at all.

When I present myself to people I use one form of my name. Some people I know use nicks. Others use part of my formal name. Due to me being a foreigner, essentially everybody I know uses a slightly different way to name me or pronounce the same name. However, there is consistency. Each person will use the same form for naming me.

This happens with Nim code too. Each programmer will have their convention, and will use it consistently. If you have a team, you establish a convention for the project: you need that anyway because people creating new stuff need a consistent way of naming things and you don't want to later rename everything after a heated discussion. So if you can't keep people on your team from using a project convention, you have a bigger problem than slightly different identifiers in a programming language.

Also, once you start using the different free naming conventions in Nim you grow inmune to them looking ugly. Just like when you know only one programming language everything else looks alien, but when you learn something else you expand your horizon and it stops looking so alien, and it stops being "harder to read". I jump from one convention to another without problem for each project as needed, and doesn't even bother me at all.

tl;dr it's not a big deal, don't let that stop you from learning a very nice language, you could regret it later

It's an unusual feature. Perhaps it calls for a 'go fmt' (nim fmt?) type tool that canonicalises names, to be automatically run on check-in.

Well thank god a minor inconvenience has been addressed!

It allows you to use your own style everywhere, instead of relying on the specific styles of the library you used (so you don't end up in your code with camelCase AND snake_case).

It's definitely unusual, but I think it works quite well.

This is largely a matter of taste, but I think go has it exactly right. Ruthlessly enforce only one way, and make that as mandatory as possible.

Having code which is formatted as uniformly as possible is a huge boon. Rules are better than norms, especially if there is zero cost of enforcing them.

This makes a lot of sense, and makes me appreciate the choice more (although my gut feeling was that it was a good idea).

`nimgrep` is a tool that comes with it to help with that. It's actually pretty useful, especially when dealing with wrappers over C libraries (I'm looking at you, SDL2...)

Reply on news.ycombinator.com