you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 18 hours ago (3 children)

Never understood the idea of, "if it needs to be fast, that part is in a faster language." Why not just use the faster language? Most of the libraries that have Python wrappers also come with c headers. Sometimes you wind up in the reverse situation where your dependency doesn't have a Python wrapper and now you're stuck managing silly boilerplate. Python just feels like an extra thing in the way to wrangle for little gain.

Also, hotspot-only optimization doesn't seem to have held up in reality, right? We can all agree that software is getting slower every day. The infrastructure is slow.

All feels like cope, through and through.

  • source
  • hideshow 3 child comments
  • [–] 1 point 8 hours ago

    All programming is a trade-off between what's easy for the developer and what's fast for the machine.

    Sure, you could theoretically write everything in Assembly and it'd be blazingly fast; but unless you're a particularly elite developer, that process would take forever for any program more complicated than a calculator, the result would be super buggy, and those bugs would be very hard to fix.

    On the other end of the spectrum, you might imagine a natural language machine learning compiler which translated directly from human prose to binary. It would be dead simple to "program" anything in; but such an application would probably be unbelievably slow, and again, have a staggering number of difficult-to-fix bugs.

    Somewhere in the middle are modern programming languages that abstract away all of the stuff that's necessary but hard for humans to wrap their minds around (memory management, API interaction, network stack, etc) and let the human write clear and unambitious code to handle all of the business logic and displaying it to the user. The result won't run as blisteringly fast as writing directly in Assembly, and it won't be as quick to market as Vibes-to-ASM, but the application will be developed in a reasonable amount of time and be reasonably easy to maintain.

  • source
  • parent
  • [–] 7 points 16 hours ago

    Why not just use the faster language?

    Because the other language is more developer-friendly or faster to write/read even if slower to execute. Some code doesn't need to be fast because it is always waiting on other things anyway.

    Some languages effectively prevent whole classes of runtime failures / bad code. But, they do that by doing more which takes longer, at compile-time, run time, or both.

    Some programs can't avoid graph-structured data dependencies. In that case, the simplest solution is a garbage collector, and one built into the runtime is capable of being more efficient (and less buggy) than one written for a specific program.

    Anyway, there are many factors that determine which language is "best", and not all of them are objective. That's why we don't just use the fastest language. (Currently, I do all my coding in either Idris or Purescript, but I'm also unemployed and just programing for myself, for now.)

  • source
  • parent