5 ms·

But, I was told that programming language choice doesn't matter and that I can write slow/bad code in any language... /s

dagw 2y ago
You can write slow code in any language, but you cannot write fast code in any language.
- ragnese 2y ago
  I didn't include every variant I've ever read, but there have been no shortage of people saying that the only thing that matters is your algorithms. Every time I've said that languages like Python, JavaScript, and basically any other language where it's hard to avoid heap allocations, pointer chasing, and copious data copies are all slow, there are plenty of people who come out of the woodwork to inform me that it's all negligible.
  - dagw 2y ago
    no shortage of people saying that the only thing that matters is your algorithms. To be a little bit fair to those people, I have been in many situations where people go "my matlab/python code is too slow, I must re-write it in C", and I've been able to get an order of magnitude improvement by re-writing the code in the same language. Hell I've ported terrible Fortran code to python/numpy and gotten significant performance improvement. Of course taking that well written code and re-writing that in well written C will probably give you a further order of magnitude improvement. Fast code in a slow language can beat slow code in a fast language, but obviously never beat fast code in a fast language.
    - ragnese 2y ago
      For sure. I agree with everything you say, and I've experienced the same thing 100 times, myself--including the specific scenario of speeding up someone's MATLAB code by multiple orders of magnitude by vectorizing the crap out of it. People seem to be almost drawn to quadratic-or-worse algorithms, even when I'd expect them to know better. I'm just a little bitter because of how many times I've been shushed in places like programming language subreddits and here when I've pointed out how inefficient some cool new library/framework/paradigm is. It feels like I'm either being gaslit or everyone else is in denial that things like excessive heap allocations really do still matter in 2025, and that JITs almost never help much with realistic workloads for a large percentage of applications.
rvz 2y ago
There you go. All the bootcamp cargo culting crew have pumped these lies such as "the language doesn't matter" or "learn coding in 1 week for a SWE job with JS / TS" and it has caused the increase in low quality software and with several developers asking how to improve or add "performance" optimizations as such. What we have just seen is that the TS team has admitted that a limit has been reached and *almost always* the solution is either porting it to a compiled language or relying on scaling with new computers with new processors in accordance to Moore's Law to get performance for free. Now the bootcampers are rediscovering why we need "static typing" and why a "compiled language" is more performant than a VM-based language.
- ragnese 2y ago
  Can you imagine the progress we could've made by now if people just tried to use the right tool for the job instead of trying to make the wrong tool good enough? All the time spent trying to optimize JITs for JavaScript engines, or alternative Python implementations (e.g., PyPy), and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications. Ugh...
  - wiseowise 2y ago
    > and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications This is how we got Graal, why would you call it "fruitless effort"?
    - ragnese 2y ago
      Okay, so "fruitless" wasn't the right word. If you try to build an actual house out of LEGO bricks, you can eventually succeed and therefore the endeavor was technically "fruitful." I think I should've described it as "wasteful" effort, or as an inefficient use of brilliant minds' time. For my specific example of JVMs on lambdas, I wasn't really thinking about GraalVM. I was more thinking of all the hacky, fiddly, things that people were doing to "warm up" their JVM-based lambdas. Like some of the stuff described in this article I just randomly grabbed from a web search: https://medium.com/@marcos.duarte242/keeping-your-aws-lambdas-warm-strategies-to-avoid-cold-starts-c3b50a001a6c https://medium.com/@marcos.duarte242/keeping-your-aws-lambda... The reality is that JVM languages were just the wrong tool for the job of writing short-lived applications. Even though I wasn't really thinking about GraalVM, it might not be shocking that I don't really like it either- for the same kind of reason(s). Java was designed as a fairly dynamic language: you have runtime reflection, dynamic class loading (hot swapping), and various other (admittedly niche) features. So, Java code destined for GraalVM has to be written differently than Java code destined for a standard JVM runtime, which is an inverted way of saying that the nominal goal of GraalVM is technically impossible (you can't, generally, write a native compiler for the Java programming language). So, again, we're taking a language that was designed and optimized for specific runtime properties and we're forcing that square peg into the round hole of AOT compilation. You want native performance? Use a native language! It feels like someone trying to design a hammer to also be a really shitty screwdriver. Why not just use a hammer sometimes and a screwdriver other times?
nipah 2y ago
Many people say this, but it is obviously bullshit. But most things people say all the time is bullshit, so I would not bother with it that much, it's not like people are saying "Programming languages don't matter, see here my affirmation is backed by a hundred statistics and data heavily reviewed and strong literature", it is more like "Programming languages don't matter, well at least I feel like it, the same way flowers smell like blue or something".
- ragnese 2y ago
  No doubt! I just like to point out the bullshit when I can. :)

dagw 2y ago

You can write slow code in any language, but you cannot write fast code in any language.

ragnese 2y ago
I didn't include every variant I've ever read, but there have been no shortage of people saying that the only thing that matters is your algorithms. Every time I've said that languages like Python, JavaScript, and basically any other language where it's hard to avoid heap allocations, pointer chasing, and copious data copies are all slow, there are plenty of people who come out of the woodwork to inform me that it's all negligible.
- dagw 2y ago
  no shortage of people saying that the only thing that matters is your algorithms. To be a little bit fair to those people, I have been in many situations where people go "my matlab/python code is too slow, I must re-write it in C", and I've been able to get an order of magnitude improvement by re-writing the code in the same language. Hell I've ported terrible Fortran code to python/numpy and gotten significant performance improvement. Of course taking that well written code and re-writing that in well written C will probably give you a further order of magnitude improvement. Fast code in a slow language can beat slow code in a fast language, but obviously never beat fast code in a fast language.
  - ragnese 2y ago
    For sure. I agree with everything you say, and I've experienced the same thing 100 times, myself--including the specific scenario of speeding up someone's MATLAB code by multiple orders of magnitude by vectorizing the crap out of it. People seem to be almost drawn to quadratic-or-worse algorithms, even when I'd expect them to know better. I'm just a little bitter because of how many times I've been shushed in places like programming language subreddits and here when I've pointed out how inefficient some cool new library/framework/paradigm is. It feels like I'm either being gaslit or everyone else is in denial that things like excessive heap allocations really do still matter in 2025, and that JITs almost never help much with realistic workloads for a large percentage of applications.

rvz 2y ago

There you go. All the bootcamp cargo culting crew have pumped these lies such as "the language doesn't matter" or "learn coding in 1 week for a SWE job with JS / TS" and it has caused the increase in low quality software and with several developers asking how to improve or add "performance" optimizations as such. What we have just seen is that the TS team has admitted that a limit has been reached and *almost always* the solution is either porting it to a compiled language or relying on scaling with new computers with new processors in accordance to Moore's Law to get performance for free. Now the bootcampers are rediscovering why we need "static typing" and why a "compiled language" is more performant than a VM-based language.

ragnese 2y ago
Can you imagine the progress we could've made by now if people just tried to use the right tool for the job instead of trying to make the wrong tool good enough? All the time spent trying to optimize JITs for JavaScript engines, or alternative Python implementations (e.g., PyPy), and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications. Ugh...
- wiseowise 2y ago
  > and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications This is how we got Graal, why would you call it "fruitless effort"?
  - ragnese 2y ago
    Okay, so "fruitless" wasn't the right word. If you try to build an actual house out of LEGO bricks, you can eventually succeed and therefore the endeavor was technically "fruitful." I think I should've described it as "wasteful" effort, or as an inefficient use of brilliant minds' time. For my specific example of JVMs on lambdas, I wasn't really thinking about GraalVM. I was more thinking of all the hacky, fiddly, things that people were doing to "warm up" their JVM-based lambdas. Like some of the stuff described in this article I just randomly grabbed from a web search: https://medium.com/@marcos.duarte242/keeping-your-aws-lambdas-warm-strategies-to-avoid-cold-starts-c3b50a001a6c https://medium.com/@marcos.duarte242/keeping-your-aws-lambda... The reality is that JVM languages were just the wrong tool for the job of writing short-lived applications. Even though I wasn't really thinking about GraalVM, it might not be shocking that I don't really like it either- for the same kind of reason(s). Java was designed as a fairly dynamic language: you have runtime reflection, dynamic class loading (hot swapping), and various other (admittedly niche) features. So, Java code destined for GraalVM has to be written differently than Java code destined for a standard JVM runtime, which is an inverted way of saying that the nominal goal of GraalVM is technically impossible (you can't, generally, write a native compiler for the Java programming language). So, again, we're taking a language that was designed and optimized for specific runtime properties and we're forcing that square peg into the round hole of AOT compilation. You want native performance? Use a native language! It feels like someone trying to design a hammer to also be a really shitty screwdriver. Why not just use a hammer sometimes and a screwdriver other times?

nipah 2y ago

Many people say this, but it is obviously bullshit. But most things people say all the time is bullshit, so I would not bother with it that much, it's not like people are saying "Programming languages don't matter, see here my affirmation is backed by a hundred statistics and data heavily reviewed and strong literature", it is more like "Programming languages don't matter, well at least I feel like it, the same way flowers smell like blue or something".

ragnese 2y ago
No doubt! I just like to point out the bullshit when I can. :)