6 ms·

Anyone who has done a programming contest, advent of code, etc knows that the language doesn’t matter so much as your algorithm. Yes, the language can bring a

• tyree731 2y ago
  Lots of very smart people have worked very hard on Python tools written in Python, yet the rust rewrites of those tools are so much faster. Sometimes it really is the programming language.
  • anyfoo 2y ago
    Choosing the right algorithm effectively means optimizing runtime complexity. Then, once runtime complexity is fixed with the right algorithm, you're still left with a lot of constant factors that O-notation deliberately ignores (it's only about growth of the runtime). Sometimes, optimizing those constant factors can be significant, and then the choice of language matters. And even some details about the CPU you are targeting, and overall system architecture.
    • o11c 2y ago
      Often languages like Javascript and Python don't allow optimal runtime complexity, because the types baked in to external interfaces fundamentally disallow the desired operation. And these languages are too slow to rewrite the core logic in the language itself. (but of course, the vast majority of the code, even in widely used tools, isn't properly designed for optimization in the first place) I only dabble in javascript, but `tsc` is abominable.
  • charrondev 2y ago
    In the JavaScript world a lot of speed up comes from 3 major things as far as I can tell: - easier concurrency. - the fact that things are actually getting rewritten with the purpose of speeding them up. - a lot of the JS tooling getting speedups deals with heavily with string parsing, tokenizing, generating and manipulation of ASTs. Being able to have shared references to slices of strings, carefully manage when strings are copied, and have strict typing of the AST nodes you enable things to be much faster than JavaScript.
  • jvanderbot 2y ago
    This is a very nice counterexample, but it's not actually a counter example without an example. Also, this was a thing before Rust. I've rewritten several things in C or Cpp for python back ends, and most pytbon performance-critical code is already an API to a shared library. You'd be surprised to run OR tools and find Fortran libraries loaded by your python code.
    • runesoerensen 2y ago
      Ruff is one example https://astral.sh/ruff https://astral.sh/ruff
      • aragilar 2y ago
        But can I write plugins for it? My understanding it is only implements a subset of the common plugins (and does not do any of the linting that pylint is useful for), so it avoids scanning the filesystem for plugins?
  • jampekka 2y ago
    Python is really really slow compared to JS though.
    • gaganyaan 2y ago
      CPython is (though it's slowly getting better). Pypy is amazingly fast
    • zeroonetwothree 2y ago
      I once worked on a Python system that had 50 machines dedicated to it. We were able to rewrite it in a more performant language such that it easily ran on one machine. This also allowed us to avoid all the issues distributed systems have. So yeah, Python is not great for systems programming
    • kukkamario 2y ago
      Node is so slow to start that python script can complete before Javascript even begins to execute.
      • jampekka 2y ago
        For extremely simple scripts maybe. I get around 70 ms difference in startup time. $ time python3 -c "print('Hello world')" Hello world real 0m0.017s $ time node -e "console.log('Hello world')" Hello world real 0m0.084s
  • worik 2y ago
    > Lots of very smart people have worked very hard on Python tools written in Python Yes, I agree that is very sad Python is achingly slow. I know the Python people want to address this, I do not understand. Python makes sense as a scripting/job control language, and execution speed does not matter. As an application development language it is diabolical. For a lot of reasons, not just speed
  • bsder 2y ago
    > Lots of very smart people have worked very hard on Python tools written in Python, yet the rust rewrites of those tools are so much faster. So? Some tool got written and did its job sufficiently well that it became a bottleneck worth optimizing. That's a win. "Finishing the task" is, by far, the most difficult thing in programming. And the two biggest contributors to that are 1) simplicity of programming language and 2) convenience of ecosystem. Python and Javascript are so popular because they tick both boxes.
    • tyree731 2y ago
      Don’t disagree about finishing the task, but personally I don’t find more performant languages any less productive for the sort of programming I tend to do.
      • bsder 2y ago
        Congratulations on being a programming god. This discussion isn't for you. From my point of view, I'm happy if I can convince my juniors to learn a scripting language. Okay? I don't care which one--any one. I'd prefer that they learn one of the portable ones but even PowerShell is fine. I have seen sooooo many junior folks struggle for days to do something that is 10 lines in any scripting language. Those folks who program but don't know a scripting language far outnumber the rest of us.
        • fredrikholm 2y ago
          > I have seen sooooo many junior folks struggle for days to do something that is 10 lines in any scripting language. > Those folks who program but don't know a scripting language far outnumber the rest of us. What domain are you in? This sounds like the complete inverse of every company I've ever worked at. Entire products are built on Python, Node ect, and the time after the initial honeymoon phase (if it exists) is spent retrofitting types on top in order to get a handle, any handle, on the complexity that arises without static analysis and compile time errors. At around the same time, services start OOM'ming left and right, parallellism=1 becomes a giant bottleneck, JIT fails in one path bringing the service performance down an order of magnitude every now and then etc... > Congratulations on being a programming god. This discussion isn't for you. On the behalf of mediocre developers everywhere, a lot of us prefer statically typed languages because we are mediocre; I cannot hold thousands of implicit types and heuristics in my head at the same time. Luckily, the type system can.
• noname120 2y ago
  It's not just a matter of “picking the correct algorithm”. Algorithmic-interview exercises are algorithmic-interview exercices. They are barely related to real-world software engineering.
  • anyfoo 2y ago
    Choosing the right algorithm is usually the prerequisite for fast code. Optimizing the constant factors is often pretty useless if you pick an algorithm with a runtime that grows quadratically, when there are much better options available.
    • noname120 2y ago
      What makes you think that the sluggishness of these tools is in any way related to not “choosing the right algorithm”?
      • anyfoo 2y ago
        What makes you think they're not? I don't know why these tools are sluggish, but I disagree with the notion that algorithms don't matter for "real-world software engineering". The world is full of slow software because one chose the wrong algorithm: https://randomascii.wordpress.com/2019/04/21/on2-in-createprocess/ https://randomascii.wordpress.com/2019/04/21/on2-in-createpr... https://randomascii.wordpress.com/2019/12/08/on2-again-now-in-wmi/ https://randomascii.wordpress.com/2019/12/08/on2-again-now-i... https://randomascii.wordpress.com/2021/02/16/arranging-invisible-icons-in-quadratic-time/ https://randomascii.wordpress.com/2021/02/16/arranging-invis... ...
  • magicalhippo 2y ago
    While picking the right algorithm seldom comes up in most programmers day-to-day activities, being aware of big-Oh and the performance guarantees/characteristics of the libraries you use most certainly should. I don't care if you don't know how to write a merge sort from scratch. I do care about you knowing not to write an O(n^2) loop when it can be avoided.
• tightbookkeeper 2y ago
  > knows that the language doesn’t matter so much as your algorithm. I know what you’re referring to but these problems have also taught me a lot about language performance. python and JS array access is just 100x slower than C. Some difficult problems become much harder due to this limitation.
  • jampekka 2y ago
    JS array access is a lot faster than Python array access. JS is easily within magnitude of C and can be even about as fast with typed arrays or well JITable code.
    • tightbookkeeper 2y ago
      > JS is easily within magnitude of C Typed arrays help a lot, but I’m still doubtful. Maybe it all the processing is restrict to idioms in the asm.js subset? And even then you’re getting bounds checking.
      • jampekka 2y ago
        In benchmarks JS is usually well within magnitude (i.e. under 10x slower). E.g. C++ vs Node.js here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/q6600/fastest/node-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Couldn't find C vs JS easily with the new benchmarksgame UI.
        • tightbookkeeper 2y ago
          I guess so. I clicked on the code for the first one. It’s using a C library to do the computation: > mpzjs. This library wraps around libgmp's integer functions to perform infinite-precision arithmetic And then the “array”: > Buffer.allocUnsafe So is this a good JavaScript benchmark?
          • jampekka 2y ago
• hawski 2y ago
  In higher level languages your code may allocate memory or trigger a GC pass or other smartness in unexpected places. This may cause slowdowns you may not have control over or may change from version to version or vendor to vendor. It is often easier to manage in "faster" languages. Good algorithm may not be enough.
• zeroonetwothree 2y ago
  The types of problems in those contests are meant to highlight algorithms. In the real world you might have a trivial algorithm but a huge input size, where the constant factor matters much more.
• moomin 2y ago
  Here’s the thing: languages like C#, Java and Rust all have extensive libraries and packages that implement many common data structures and algorithms well. With all due respect to the incredible work that goes into projects like lodash, JavaScript does not. (Nor does C, for that matter.)
• Ferret7446 2y ago
  Quite the opposite, for most cases you don't hit the scale where asymptotic algorithmic performance really makes a big impact (e.g., for many small set comparisons, iterating over a list is faster than a hash set, but only by 10-50% or so), vs switching to a compiled language which instantly gets you 10x to 100x performance basically for free. Or perhaps another way to look at it, if you care enough about performance to choose a particular algorithm, you shouldn't be using a slow language in the first place unless you're forced to due to functional requirements.
• xlii 2y ago
  > Anyone who has done a programming contest, advent of code, etc knows that the language doesn’t matter so much as your algorithm. This is one of the biggest falsehoods in the software engineering I know. Language is a collaboration glue and influences way of thinking guiding solution development. As an analogy: you can make a statue from a glass or from ice, but while both can be of the same shape and be equally awed upon, the process and qualities will differ. For the prototypes and throwaways context doesn’t matter - That’s why all short lived contests, golfs and puzzles ignore it. Yet, when software is to be developed not over the week but over the decades and (hopefully) delivered to thousands if not millions of computers it’s the technological context (language, architecture, etc.) that matters the most.
• eviks 2y ago
  And anyone who expands the horizon to the real world, instead of focusing on the artificial one of contests, knows that the language matters a great deal
• CrimsonRain 2y ago
  That's why almost every thing important in python is in C
• deleted 2y ago
  [deleted]
• rk06 2y ago
  I have done so, and one has to be out of their mind to attempt in java instead of c++ in those contests.