3 ms·
I'm sorry, but if you don't understand what is being said to you I think the odds are pretty good that you were speaking out of turn when you were making procla
by 59nadir 3y ago
I'm sorry, but if you don't understand what is being said to you I think the odds are pretty good that you were speaking out of turn when you were making proclamations about what developers usually do with static languages with regards to hot reloading code. If you don't know about dynamic loading of shared libraries and can't even parse these replies I think maybe you should just admit that you just didn't know what you were talking about when you said that. I don't have examples of this in open source projects because I don't have some list of open source games or whatever that I can point to (and honestly no one should have to give an example of something so trivial and well used).
I sent you a video of someone doing this in less than 2 hours without even using non-OS dependencies. It's an example of someone actually doing it and showing how trivial it is to dynamically reload code when it changes in statically typed, ahead-of-time compiled languages, a class of languages you claimed don't have hot reloading of code without "complicated IDEs".
- cxr 3y ago> if you don't understand what is being said to you I think the odds are pretty good that you were speaking out of turn 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. Maybe it's amenable to just trying to get a response to a direct question? Having said that, the amount of effort here to get a succinct response to a far more direct and less abstract question, "Can you point to examples [of what you're talking about]", makes me doubt.) I've been programming for 20+ years. I know how shared libraries work (and dlopen—mentioned, finally, in your edit). I'm certainly confused—but the confusion is why you're bringing it up. It's totally unsuited as a drop-in replacement for what I described in the first comment you responded to. Did you read the blog post describing the actual mechanics of how the TWEAK macro works? I'm guessing no, since (a) your comments don't make sense in context and (b) that post references mollyrocket (Casey Muratori, the guy recording the screencast you linked to in your edit) by name. If your solution is to refactor your code into a separate module and use dlopen, then we're talking about different things, and I'm not watching a 2 hour video just to find out whether it is the person I'm interacting with who is in fact the one not grokking the breadth and depth of the discussion.
- 59nadir 3y ago> 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.