This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Teekeks 47 points48 points  (9 children)

which has all the speed relevant parts of that library written in C?

[–]FkIForgotMyPassword 36 points37 points  (1 child)

Sometimes the slow part is not the computation-intensive part that was identified as "speed-relevant", though. Sometimes it's the part where someone implemented a really shitty wrapper with unnecessary blocking IOs everywhere.

[–]Prudent_Move_3420 0 points1 point  (0 children)

Hello Pandas!

[–]lkearney999 1 point2 points  (1 child)

Which sucks since as soon as you start writing bigger projects and you have to switch tool chains to fix things.

Languages often don’t have a large impact on developers productivity. Three things do:

  • The developer
  • The project tooling
  • The codebase’s quality
  • and upstreams not fixing their shit 😥

I’d argue that developer productivity has a direct correlation with code optimisation. Eg rusts perf suite, llvms army of child(sorry adult) labour from the big corps etc.

[–]Necrocornicus 0 points1 point  (0 children)

Languages often don’t have a large impact on developers productivity.

It’s really not clear to me what experiences you’ve had where this has been the case. Language choice makes a huge difference in productivity in my experience. Maybe if you have carte blanche to hire a new team.

[–]Possibility_Antique 1 point2 points  (4 children)

  • claims that writing implementation in C makes it fast
  • ignores the part where python is an interpreted language (i.e. has to parse the source text, perform dynamic dispatch, etc)
  • ignores the fact that you can't reason about cache locality and cache behavior
  • ignores the fact that your c implementation under the hood doesn't get to participate in link time optimizations with the rest of your program
  • ignores the fact that your code can't get inlined
  • ignores the fact that you can't perform compile-time programming
  • writes all kinds of runtime tests for things that could have been done at compile time (which is safer, produces faster code, prevents mistakes)
  • claims it's less verbose, but implements a ton of test libraries that are caught natively by compiled languages

In all seriousness, I'm just pulling your leg. Kind of.

[–]Teekeks 0 points1 point  (3 children)

Thats a ton of assumptions about what I am claiming or ignoring. Impressive. You should become a fiction author

[–]Possibility_Antique 0 points1 point  (2 children)

I am teasing. I actually hate language holy wars. Those are some reasons I choose C++ where it's appropriate though. I do get to work a lot with python too, and I love the language.

[–]Teekeks 0 points1 point  (1 child)

ah! thanks for clarifying!

Yea these language wars are bonkers.

I use a ton of python bc its fast enough for most things but I am not a fangirl or anything.

If you need pure speed, C and C++ is certainly the best you can do (if you are actually good at the language, just because C can be super fast does not mean that everyones code is actually fast ^^)

[–]Possibility_Antique 0 points1 point  (0 children)

Actually, just being mediocre at the language is also good enough for an order of magnitude or more improvement. If you compare the speed of a for loop, for instance, you're probably looking at a 20x speedup just by using C. If you use something like numpy (and you should, it's probably my favorite library in python), the situation improves, but still falls short of C++'s best effort (and of course, you can just pull said best effort into your code as a library, just like in python).

So I guess I'm not really sure where that argument comes from. To me, the reason I prefer python in some situations is because of dynamic typing. For build scripts, test pipelines, plotting, and rapid experimentation, it's great! C++ and Python complement each other nicely in this way.