4 ms·

> Since I have you, do you have any personal insights on why so many programmers retreat to this territory—simply deciding that the other person is a dumb and c

> Since I have you, do you have any personal insights on why so many programmers retreat to this territory—simply deciding that the other person is a dumb and confused noob and proceeding to more or less declare that that's the case? (It reads as insecurity/projecting, but it's hard to nail down without more concrete information about the other person. I think it's your attitude that does it, to be honest. For someone who seems to have issues understanding how `dlopen` and friends solves the same problem you're awfully dismissive yourself. I understand the blog post just fine, and it's honestly a way more complicated and less solid solution to something that has better solutions, including the one I mentioned (and yes, they solve the same problem). You stated statically typed languages have issues hot-reloading code and I've explained to you that this is patently not true (and obvious to anyone who has spent the minimum amount of time you need in order to reload DLLs on-the-fly). You not being willing to watch a video of this isn't really a problem I'm trying to solve or otherwise handle. > I know how shared libraries work Then you should have no problem understanding why the responses you've received are relevant for hot-reloading. Maybe you should actually try to understand how shared libraries work more, then, because your confusion and your lack of understanding of it point to you not really understanding how you could use them yet. Just to be clear, I'm trying to not be snarky, but your attitude about this is really getting on my nerves when coupled with your lack of understanding when you're the one with the original BS line about hot-reloading. I don't know why you can't just say "Oh, hey, I was basically just bullshitting because I've never done hot-reloading in a native language". It's not hard to recompile a DLL on file changes and reloading them when they change in a program. It's also not hard to compile a DLL. You implying that any of these things are hard shows that you really ought not to speak so definitively on any of them, and maybe you should tone down your dismissive tone when faced with proof of your misunderstanding.

cxr 3y ago
> For someone who seems to have issues understanding how `dlopen` and friends solves the same problem [...] Maybe you should actually try to understand how shared libraries work more See? You're still doing it. But I'll bite. Let's ignore the overhead of having to refactor your code for a quasi-plugin architecture in the first place. I'm going to ask you a very simple question: How do you reload a shared library using dlopen after changing a source file without recompiling it? > You stated statically typed languages have issues hot-reloading code The wounded tone suggests that you're reading way too much out of the (true, and what should be totally uncontroversial) statement that, in order for edit-and-continue to work when debugging an arbitrary program they're working on, "the conventional static languages folks have generally needed to rely on support in sophisticated IDEs". This was not a challenge in a static-vs-dynamic (or PL-vs-PL) holy war, and your taking it as such has you behaving with insolent irrationality. > you're the one with the original BS line about hot-reloading Just to underscore the source of conflict here: you don't seem to understand that hot code reloading (especially hot code reloading with "no stop-and-recompile"—a constraint that was explicitly mentioned not once, but twice in my original comment) is a far more general subject than hot module reloading, which is what you're describing. > It's not hard to recompile a DLL on file changes And there it is, HNers. You hardly ever fail to move the goalposts.
- 59nadir 3y ago
  Let's examine exactly what you said from the beginning so that we can put the goal post back from where you moved it with this ridiculous paragraph: > Just to underscore the source of conflict here: you don't seem to understand that hot code reloading (especially hot code reloading with "no stop-and-recompile"—a constraint that was explicitly mentioned not once, but twice in my original comment) is a far more general subject than hot module reloading, which is what you're describing. ... > In other words, rather than having a graphical interface for tweaking values at runtime, you interface with it the same way you normally would—by changing the constants in the original source file, but the difference between the ordinary stop-and-recompile way of doing it is that the changes get picked up live, so there is no stop-and-recompile. You've had it explained to you that "stop-and-recompile" isn't even a factor because you can pick up these changes live regardless and you've been shown how. > Let's ignore the overhead of having to refactor your code for a quasi-plugin architecture in the first place. You keep pushing this idea that this is somehow difficult and takes a ton of time. It's not and it doesn't. How am I supposed to assume you're competent and knowledgeable when what you write says you're not and you aren't? > How do you reload a shared library using dlopen after changing a source file without recompiling it? You recompile it because recompiling it and reloading the code isn't an issue. > The wounded tone suggests that you're reading way too much out of the (true, and what should be totally uncontroversial) statement that, in order for edit-and-continue to work when debugging an arbitrary program they're working on, "the conventional static languages folks have generally needed to rely on support in sophisticated IDEs". This was not a challenge in a static-vs-dynamic (or PL-vs-PL) holy war, and your taking it as such has you behaving with insolent irrationality. This word salad suggests that you're butthurt about having your programming chops challenged when you make bullshit statements about reloading code. I'm sorry, but I'm well and truly done with this. You say to assume competence and stuff but you seem to not understand at all that the things you're saying go against that entirely. You've now sort-of redefined what the original problem was to make it seem like hot-reloading shared libraries doesn't solve it. Honestly, just learn to not make these silly statements from the beginning instead when you're out of your element.
  - cxr 3y ago
    I'll note that you didn't answer the question. > You keep pushing this idea that this is somehow difficult and takes a ton of time. [...] recompiling it and reloading the code isn't an issue No, I didn't. But you can continue trying to move the goalposts, and I will continue pointing out that that's what you're doing. > You say to assume competence and stuff Really? Where? > You've now sort-of redefined what the original problem was to make it seem like hot-reloading shared libraries doesn't solve it. Perhaps you and I have a different understanding of the word "redefined". Or maybe you disagree on what "recompile" means (and/or what it means to say that there is "there is no stop-and-recompile"). I'll (re) ask a simpler question: did you read the post describing TWEAK that I linked to[1]—that is, before you replied (and subsequently dove headlong into trying to change the subject with ad hominem attacks on the competence of the person you responded to)? 1. <https://blog.voxagon.se/2018/03/13/hot-reloading-hardcoded-parameters.html https://blog.voxagon.se/2018/03/13/hot-reloading-hardcoded-p...>

cxr 3y ago

> For someone who seems to have issues understanding how `dlopen` and friends solves the same problem [...] Maybe you should actually try to understand how shared libraries work more See? You're still doing it. But I'll bite. Let's ignore the overhead of having to refactor your code for a quasi-plugin architecture in the first place. I'm going to ask you a very simple question: How do you reload a shared library using dlopen after changing a source file without recompiling it? > You stated statically typed languages have issues hot-reloading code The wounded tone suggests that you're reading way too much out of the (true, and what should be totally uncontroversial) statement that, in order for edit-and-continue to work when debugging an arbitrary program they're working on, "the conventional static languages folks have generally needed to rely on support in sophisticated IDEs". This was not a challenge in a static-vs-dynamic (or PL-vs-PL) holy war, and your taking it as such has you behaving with insolent irrationality. > you're the one with the original BS line about hot-reloading Just to underscore the source of conflict here: you don't seem to understand that hot code reloading (especially hot code reloading with "no stop-and-recompile"—a constraint that was explicitly mentioned not once, but twice in my original comment) is a far more general subject than hot module reloading, which is what you're describing. > It's not hard to recompile a DLL on file changes And there it is, HNers. You hardly ever fail to move the goalposts.

59nadir 3y ago
Let's examine exactly what you said from the beginning so that we can put the goal post back from where you moved it with this ridiculous paragraph: > Just to underscore the source of conflict here: you don't seem to understand that hot code reloading (especially hot code reloading with "no stop-and-recompile"—a constraint that was explicitly mentioned not once, but twice in my original comment) is a far more general subject than hot module reloading, which is what you're describing. ... > In other words, rather than having a graphical interface for tweaking values at runtime, you interface with it the same way you normally would—by changing the constants in the original source file, but the difference between the ordinary stop-and-recompile way of doing it is that the changes get picked up live, so there is no stop-and-recompile. You've had it explained to you that "stop-and-recompile" isn't even a factor because you can pick up these changes live regardless and you've been shown how. > Let's ignore the overhead of having to refactor your code for a quasi-plugin architecture in the first place. You keep pushing this idea that this is somehow difficult and takes a ton of time. It's not and it doesn't. How am I supposed to assume you're competent and knowledgeable when what you write says you're not and you aren't? > How do you reload a shared library using dlopen after changing a source file without recompiling it? You recompile it because recompiling it and reloading the code isn't an issue. > The wounded tone suggests that you're reading way too much out of the (true, and what should be totally uncontroversial) statement that, in order for edit-and-continue to work when debugging an arbitrary program they're working on, "the conventional static languages folks have generally needed to rely on support in sophisticated IDEs". This was not a challenge in a static-vs-dynamic (or PL-vs-PL) holy war, and your taking it as such has you behaving with insolent irrationality. This word salad suggests that you're butthurt about having your programming chops challenged when you make bullshit statements about reloading code. I'm sorry, but I'm well and truly done with this. You say to assume competence and stuff but you seem to not understand at all that the things you're saying go against that entirely. You've now sort-of redefined what the original problem was to make it seem like hot-reloading shared libraries doesn't solve it. Honestly, just learn to not make these silly statements from the beginning instead when you're out of your element.
- cxr 3y ago
  I'll note that you didn't answer the question. > You keep pushing this idea that this is somehow difficult and takes a ton of time. [...] recompiling it and reloading the code isn't an issue No, I didn't. But you can continue trying to move the goalposts, and I will continue pointing out that that's what you're doing. > You say to assume competence and stuff Really? Where? > You've now sort-of redefined what the original problem was to make it seem like hot-reloading shared libraries doesn't solve it. Perhaps you and I have a different understanding of the word "redefined". Or maybe you disagree on what "recompile" means (and/or what it means to say that there is "there is no stop-and-recompile"). I'll (re) ask a simpler question: did you read the post describing TWEAK that I linked to[1]—that is, before you replied (and subsequently dove headlong into trying to change the subject with ad hominem attacks on the competence of the person you responded to)? 1. <https://blog.voxagon.se/2018/03/13/hot-reloading-hardcoded-parameters.html https://blog.voxagon.se/2018/03/13/hot-reloading-hardcoded-p...>