Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Use Nim instead of Python for Data Processing

benjamindlee.com

Post reply on HN
Print view View original

101–110 of 183 posts

Re: Why I Use Nim instead of Python for Data Processing

#101

Post by Zababa »

egwor wrote: post #55
DeathArrow wrote: post #41

While Nim is for certain interesting and even pleasant to write code in, its small user base and environment discourage people to use it. I don't write code only for myself. How would I convince my employer to let me use Nim instead of a better known language? And even I would convince my employer, if we want to start a new project how could we find programmers well-versed in Nim? And even id we can find those people…

You could make the same argument about rust right now., but rust is further along the 'programming language life path'.

Not really, Rust is way more established than Nim. Lots of people use it, lots of companies use it, the community is very large. Maybe 5 years ago, Rust was at the same point as Nim, but even then I doubt it. Nim seems to be one of those languages that will always remain low-profile, because it's an incremental improvement and isn't pushed by a platform.

Re: Why I Use Nim instead of Python for Data Processing

#102

Post by jb1991 »

cycomanic wrote: post #34

One pitfall that I ran into when trying out Nim for scientific computing is that Nim follows more a computer science convention than mathematics convention for exponentiation and negation operators. That is in Nim -2^3=(-2)^3 unlike more scientific computing oriented languages where -2^3=-(2^3). To someone like myself who mainly does scientific work this was quite unexpected and it causes a surprising amount of menta…

To be honest, regardless of the behavior of the language, I would be wrapping things in parentheses to make it explicit anyway.

Re: Why I Use Nim instead of Python for Data Processing

#103

Post by IshKebab »

haxscramper wrote: post #56
IshKebab wrote: post #30

Earlier quoted context omitted.

Various programming languages (and file systems!) have had some form of case insensitivity and it always turns out to be an absolutely terrible idea: * It makes searching for identifiers harder. For Nim you can't even use case insensitive search because of the underscore thing! Better practice your regexes. * The case insensitivity rules are usually super complicated and don't apply to everything, so now it's an extr…

> 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…

> so the rule is pretty simple

So it's only identifiers, what about keywords, compiler directives? And only ASCII characters... And it doesn't affect the first character randomly. Sure very simple.

> If you depend on a library that uses `get_name` but your project adopted `getName()` your don't need to suffer.

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

> Nim projects usually adopt camel/pascal case.

So why do you need case insensitivity??!

Trust me this is a decision they will regret.

Re: Why I Use Nim instead of Python for Data Processing

#104

Post by hexo »

IshKebab wrote: post #88
elcritch wrote: post #32

Earlier quoted context omitted.

> Yeah should really be "Why I don't use Python for Data Processing". Not entirely. Nim‘s benefit here is that it’s superficially similar enough to Python that’s it’s easy for people from that world to pickup and start using Nim. > Also I don't know how anyone could design a language in the 21st century and make basic mistakes like this: > If that's any indication of the sanity of the rest of Nim then I'd say steer w…

> It’s intent is to allow a given codebase to maintain a consistent style (eg camel vs snake) even when making use of upstream libraries that use different styles. This doesn't make sense. For an entirely new language you can just have the entire ecosystem use the same style, e.g. like Rust does. Or even Python!

It actually makes a lot of sense. I personally don't want to touch .Net langs because of their PascalCase and camelCase coding style which I find very unfortunate arbitrary decision. And well, didn't really want to get into Nim because of camelCase but since I've learned about this feature I'm reconsidering again.

Re: Why I Use Nim instead of Python for Data Processing

#105

Post by gameswithgo »

piqufoh wrote: post #31

Python sometimes runs slowly, because it's not designed to run fast. It's designed to be readable and easy to write, which in turn makes developing python faster. It's a compromise, but I always prioritise _my_ time over my computers time, so if I can write something quickly and just go and get a coffee while it runs - I will do that. I won't spend twice as long writing a single-run script just because it'll finish b…

You can have Python syntax without Python slow.

Re: Why I Use Nim instead of Python for Data Processing

#106

Post by matthiaswh »

IshKebab wrote: post #16
zmmmmm wrote: post #8

It's primarily a testament to how simply mind bogglingly slow Python is outside of its optimised numerical science ecosystem. Which also why I don't use it that much, because while numerical analysis is a big part of what I do, so is what I would call "symbolic manipulation" and unless you go to quite some effort to transform every problem into a numerical one, Python is just awful at that. But Nim is only one of a w…

Yeah should really be "Why I don't use Python for Data Processing". I would consider Typescript as an alternative too which I'm sure would get a similar speedup. Also I don't know how anyone could design a language in the 21st century and make basic mistakes like this: > Nim treats identifiers as equal if they are the same after removing capitalization (except for the first letter) and underscore, which means that yo…

I wish this tired, boring argument didn't derail every conversation that remotely mentions Nim. See: literally every past HN post with "Nim" in the title.

Nim's underlying, perhaps understated philosophy is that it lets you write code the way you want to write code. If you like snake case, use it. If you want camel case, sure. Write your code base how you want to write it, keep it internally consistent if you want, or don't. Nim doesn't really care.

(That philosophy extends far beyond naming conventions.)

What this avoids is being stuck with antiquated standard libraries that continue to do things contrary to the language's standards for the sake of backward compatibility (arg Python!) and 3rd party libraries where someone chose a different standard because that's their preference (arg Python! JavaScript! Literally every language!). Now you're stuck with screaming linters or random `# noqa` lines stuffed in your code, and that one variable that you're using from a library sticks out like a sore thumb.

Your code is inconsistent because someone else's code was inconsistent - that's simply not a problem in Nim.

Could Nim have forced everyone to snake_case naming structures for everything from the start? Well, sure, but then the people that have never actually written code in Nim would be whining about that convention instead and we'd be in the same place. After having actually used Nim, my opinion, and I would venture to say the opinion of most, is that its identity rules were a good decision for the developers who actually write Nim code.

Re: Why I Use Nim instead of Python for Data Processing

#107

Post by haxscramper »

IshKebab wrote: post #103
haxscramper wrote: post #56

Earlier quoted context omitted.

> 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…

> so the rule is pretty simple So it's only identifiers, what about keywords, compiler directives? And only ASCII characters... And it doesn't affect the first character randomly. Sure very simple. > If you depend on a library that uses `get_name` but your project adopted `getName()` your don't need to suffer. Yeah because nobody ever imports code from other projects, copy/pastes from StackOverflow etc. /s > Nim proj…

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.

Re: Why I Use Nim instead of Python for Data Processing

#108

Post by ad404b8a372f2b9 »

santiagobasulto wrote: post #37

I don't doubt Nim, looks like a great language. But that is just an awful Python implementation. I'd do it in this way: lines = (line for line in lines("orthocoronavirinae.fasta") if not line.startswith(">")) gc_lines = (1 if ('G' in line or 'C' in line) else 0 for line in lines) gc = sum(gc_lines) total = len(list(gc_lines)) # Alternatively, a more "memory efficient" total would be: total = sum(1 for _ in lines) Edi…

That's not good python, it's unreadable and less optimized than the original code. Your "1 if ... else 0" condition serves no purpose and you iterate twice over the same loop for no reason. Use normal loops and save everyone who comes after a lot of reading time and bugs.

Re: Why I Use Nim instead of Python for Data Processing

#109

Post by pdimitar »

benjamin-lee wrote: post #5
liamwestray wrote: post #4

Earlier quoted context omitted.

Yeah, this is why my comment led with “I trust the author”… I’m surprised you need the full 4 bits to deal with ambiguous bases, but it probably makes sense at some lower level I don’t understand.

This is because there's four bases and each can either be included or excluded from a given combination. So there are 4*2 = 16 combinations each of which with their own letter. In all honesty, these are pretty rarely used in practice these days except for N (any base) although they do sometimes show up when representing consensus sequences.

What do you mean that each base can be included or excluded? Isn't only one extra value needed? Sort of like nil?

Re: Why I Use Nim instead of Python for Data Processing

#110

Post by pdimitar »

oxfordmale wrote: post #33

The author makes a fair point, however, that is a rather non optimal implementation in Python. You likely could use chunked Pandas to speed up or the code, or at least replace some of the for loops with a list comprehension syntax. However, in any case I would never replace Python with Nim as it is too niche of a language and you would struggle with recruiting. I could consider Julia if it's popularity keeps growing.…

There's a class of technologies falling under what I'd call "most of your engineers would pick that in a weekend".

Not all technologies require the full cycle and the normal risk management.

Post reply on HN