4 ms·

As I look at the comments on this blog post 4 hours after submission, the number of HN readers dismissing it out of hand is really disappointing: Rather than g

by js2 2y ago

As I look at the comments on this blog post 4 hours after submission, the number of HN readers dismissing it out of hand is really disappointing: Rather than go to all this hassle... Just Program in C Folks, take your dismissiveness elsewhere. It's not the HN spirit. The post is meant to be pedagogical, to teach the concept of codegen if you aren't already familiar with it. It already includes disclaimers about how this technique may be used on any language with a VM, not just Python. It explains why it was the right choice at the employer where the author used it. So your dismissive comments add nothing. To anyone who hasn't read the article yet: it's worth reading if you're not already familiar with code gen and want to learn a new tool to add to your programming toolbox. Take note of the caveats the author duly mentions.

the__alchemist 2y ago
An important part of programming is using the right tool for the job. It may make sense to use a hammer instead of pummeling a nail with a screwdriver. Anecdotally, many screwdriver experts don't have other tools in their in their box, and don't consider adding them. Repurposing a tool in a pinch is a useful skill, but it's a temporary solution.
bongodongobob 2y ago
I think the idea that every language is just as useful for task X is just as stupid. Sometimes you're just doing it wrong.
bmitc 2y ago
It is a general problem in the Python ecosystem and places that use Python that Python is viewed as the only possible language to solve every problem. While saying just use C is very much unhelpful and not even recommended by most, there are several languages that are just as easy if not much more easy to use as Python and come with many multipliers of performance that you don't even have to try for.
ameliaquining 2y ago
The thing is, I'm genuinely struggling to understand under what circumstances this could be the best solution. The author explains why it's better for his use case than just using inline conditionals (because of performance, though I really wish he'd included benchmarks), but although he asserts that it's also better than using C or C++ or Rust, he doesn't really explain why. Perhaps more importantly, the solution space isn't limited to "do the slow thing", "use C/C++/Rust", and "bytecode generation"; many other alternatives were brought up in this comment thread, some of which seem to provide most or all advantages of bytecode generation while being more maintainable. If the author was aware of these alternatives and rejected them for specific reasons, that would be very interesting to know, but again, the article gives no indication of this. What I'd like is to understand some set of circumstances such that, if somebody linked me this article and asked me "should I consider doing this in my code?", I could in good conscience say yes.
IshKebab 2y ago
I think the dismissiveness is because he is genuinely proposing this as a useful solution, even if only for limited circumstances. Whereas in reality there's no way you should do this ever. If he had presented it as a fun challenge or something and said "but actually just write performance sensitive code in a fast language" then I don't think you'd see these comments.

by js2 2y ago

the__alchemist 2y ago

An important part of programming is using the right tool for the job. It may make sense to use a hammer instead of pummeling a nail with a screwdriver. Anecdotally, many screwdriver experts don't have other tools in their in their box, and don't consider adding them. Repurposing a tool in a pinch is a useful skill, but it's a temporary solution.

bongodongobob 2y ago

I think the idea that every language is just as useful for task X is just as stupid. Sometimes you're just doing it wrong.

bmitc 2y ago

It is a general problem in the Python ecosystem and places that use Python that Python is viewed as the only possible language to solve every problem. While saying just use C is very much unhelpful and not even recommended by most, there are several languages that are just as easy if not much more easy to use as Python and come with many multipliers of performance that you don't even have to try for.

ameliaquining 2y ago

The thing is, I'm genuinely struggling to understand under what circumstances this could be the best solution. The author explains why it's better for his use case than just using inline conditionals (because of performance, though I really wish he'd included benchmarks), but although he asserts that it's also better than using C or C++ or Rust, he doesn't really explain why. Perhaps more importantly, the solution space isn't limited to "do the slow thing", "use C/C++/Rust", and "bytecode generation"; many other alternatives were brought up in this comment thread, some of which seem to provide most or all advantages of bytecode generation while being more maintainable. If the author was aware of these alternatives and rejected them for specific reasons, that would be very interesting to know, but again, the article gives no indication of this. What I'd like is to understand some set of circumstances such that, if somebody linked me this article and asked me "should I consider doing this in my code?", I could in good conscience say yes.

IshKebab 2y ago

I think the dismissiveness is because he is genuinely proposing this as a useful solution, even if only for limited circumstances. Whereas in reality there's no way you should do this ever. If he had presented it as a fun challenge or something and said "but actually just write performance sensitive code in a fast language" then I don't think you'd see these comments.