|
RPATDO_LAMD posted:give those kids a good old fashioned int main() and then force them to grind their faces against pointers and malloc/free until they understand the difference between values and references. it builds character! Doing this atm, trying to learn old fashioned C so I can get a deeper understanding of the basics. I got the how of pointers, and I think I get the why... It's faster and saves space to point a variable directly to a memory adress? And I think there's more to it than that but I haven't gotten so far yet.
|
#
?
Dec 28, 2022 09:06
|
|
|
|
| # ? May 10, 2024 19:48 |
|
|
EoRaptor posted:They talk about how the .33 is an approximation of 1/3rd, so dropping the 'or equal too' isn't going to change the results in meaningful way. They assumed 0.33 was an approximation of 1/3rd. That or this is some fixed radix system and it still applies. Point being I very easily pointed to a case, from very small and basic ints, that changed because of their refactor. The other implication of having 'or equals' there is that there could be a strictly greater than on the same value elsewhere to cover all cases. Now there would be a discontinuity. They have changed the code either way. "Oh they must have just meant..." is a horrible, disgusting, terrifying assumption to make about somebody's code that 100% belongs in this thread, especially when a side point of the video is about programming correctness. One could weakly argue that this small snippet of code doesn't include any details like that and is just a teaching example, but it sure does have elements that point to being part of a far larger system to consider. There's good stuff in there that boils down to KISS, but this is fundamentally a refactor that almost certainly introduced a bug while trying to fix some other bug. There's a comment on the video that makes a great point: A good teacher would now ask their class to point out all the things they hosed up. This would be one of them, and subtracting returns in the denominator would be the other, especially after the video stated this refactor was to help suss out some other bug. Ranzear fucked around with this message at 11:12 on Dec 28, 2022 |
|
#
?
Dec 28, 2022 11:10
|
|
|
His Divine Shadow posted:Doing this atm, trying to learn old fashioned C so I can get a deeper understanding of the basics. I got the how of pointers, and I think I get the why... It's faster and saves space to point a variable directly to a memory adress? And I think there's more to it than that but I haven't gotten so far yet. There's a lot more to it than that. Neither saving time nor saving space is a major part of the reason for pointers. The biggest single reason relates to an important part of the language that you will not yet have encountered in your study, namely the allocation of memory with the function malloc. Pointers are the only way to interact with these allocations. It'll start to make more sense once you get to that feature. One challenging thing about learning programming is that all of the parts are designed to work together, so one feature won't make much sense on its own without also understanding several others. Programming languages are designed for people who already know how to use them. They're introducing the concept of pointers now so that you will have some exposure to the basic idea of how they work, but understanding why they work that way won't be possible just from the material preceding it in whatever reference you're following. If you'd like to jump ahead, I or someone here can give you a breakdown of the memory model used in C and many other languages.
|
|
#
?
Dec 28, 2022 11:18
|
|
|
I'd appreciate any and all help. I am not really following any course right now. Just googling, watching youtube and reading. Went through the intro C course on youtube from FreeCodeCamp and now I am watching stuff from Low Level Learning and some others. I've set up WSL with debian with emacs as an editor and using gcc instead of jumping into an IDE directly, since I want to get more familiar with the basics before moving onto stuff like an IDE. I think I would like an actual old school physical book too. I am mostly used to visual studio, I've done web oriented stuff in c# and javascript mainly and I've never had to think about the hardware or memory before. And I've learned on a "need to accomplish X" and then googling and using tack overflow basically. so I got loads of holes in my knowledge. Guess this is why I latched onto C and trying to learn tbe basics from the ground up. I would like to learn something "properly" as well as doing more low level stuff.
|
|
#
?
Dec 28, 2022 11:39
|
|
|
Well, the thing you should read about is dynamic memory allocation in C, with important keywords "the stack" and "the heap," two regions that C's memory model divides available memory into. The short version is: when you declare a variable, that automatically causes memory to be allocated on the stack, and because of the way the stack works, the location of that allocated memory is predictable, so the compiled program knows the memory address corresponding to that variable without also having to keep the address in memory in the form of a pointer; however, when you allocate memory on the heap instead, there is no such predictability, so you need (and you receive) a pointer in order for the program to know where to write and read.
|
|
#
?
Dec 28, 2022 12:13
|
|
|
His Divine Shadow posted:I'd appreciate any and all help. I am not really following any course right now. Just googling, watching youtube and reading. Went through the intro C course on youtube from FreeCodeCamp and now I am watching stuff from Low Level Learning and some others. Go to any used book store and pick up a book on C from the 90s. They all walk you through features of the language in sequence, often having some examples to work through as you go. If you want to force yourself to think about memory, you can write a game for Gameboy Advance or (if you're looking for much harsher constraints) NES, apple ii, or C64. There's some resources for all of them, but GBA is probably the most gentle https://www.coranac.com/tonc/text/. Llvm toolchain for 6502 (NES, C64, etc) here: https://llvm-mos.org/wiki/Welcome
|
|
#
?
Dec 28, 2022 15:11
|
|
|
Bongo Bill posted:There's a lot more to it than that. Neither saving time nor saving space is a major part of the reason for pointers. The biggest single reason relates to an important part of the language that you will not yet have encountered in your study, namely the allocation of memory with the function malloc.
|
|
#
?
Dec 28, 2022 19:09
|
|
|
the thing that made me truly understand how the stack and the heap worked wasn't any C tutorial at all, it was a tutorial on how to write a function in assembly. Assembly doesn't really have variables per se, it just has processor instructions, which you execute on memory locations. There's more or less three different ways to use memory in variable-like ways, which directly correspond in C to stack-allocated variables, heap-allocated variables, and global variables. Seeing what a hassle it was to set up the stack in assembly makes it crystal clear why it works the way it does in C, and thinking about how you might have variables without those limitations is more or less how you arrive at the heap (though the heap has its own limitations). as for pointers more generally, it's not really right to say there's One Reason to use pointers. There's at least half a dozen, they're extremely flexible tools. I can think of at least six language features in C++ which are just wrappers around one of the ways to use pointers (passing by reference, std::unique_ptr, std::shared_ptr, std::weak_ptr, std::vector, and std::array). cheetah7071 fucked around with this message at 19:25 on Dec 28, 2022 |
|
#
?
Dec 28, 2022 19:21
|
|
|
std::array is not dynamically allocated, that's the whole point of using it over vector
|
|
#
?
Dec 28, 2022 19:44
|
|
|
RPATDO_LAMD posted:std::array is not dynamically allocated, that's the whole point of using it over vector I know, all I'm saying I'd that you'd represent the same concept with a pointer in C
|
|
#
?
Dec 28, 2022 19:46
|
|
|
just lmao if you're using the standard library instead of using malloc for everything and your own hand-written character array libraries for everything
|
|
#
?
Dec 28, 2022 23:55
|
|
|
Ranzear posted:They assumed 0.33 was an approximation of 1/3rd. That or this is some fixed radix system and it still applies. Point being I very easily pointed to a case, from very small and basic ints, that changed because of their refactor. The entire premise of the video is that the code is currently incorrect and does not match the requirements, and the goal is to make the code understandable so that it can be made to do what the requirements say. This is a very different scenario from having some code which is currently working correctly but no one actually knows what the correct behavior is. In that scenario, changing >= to > to "simplify" it would be completely insane, but in the scenario given in the video the authoritative reference on whether it should be > or >= is the requirements doc, not the old version of the code. After refactoring the code the next step is to align the code with the doc, and that's the case regardless of what changes you make during refactoring. The idea of having an authoritative requirements doc is now quaint, but it was normal at the time the video was made.
|
|
#
?
Dec 29, 2022 00:21
|
|
|
In floating point you would never hit that equals condition anyways.
|
|
#
?
Dec 29, 2022 02:38
|
|
|
Plorkyeran posted:The entire premise of the video is that the code is currently incorrect and does not match the requirements, and the goal is to make the code understandable so that it can be made to do what the requirements say. This is a very different scenario from having some code which is currently working correctly but no one actually knows what the correct behavior is. In that scenario, changing >= to > to "simplify" it would be completely insane, but in the scenario given in the video the authoritative reference on whether it should be > or >= is the requirements doc, not the old version of the code. After refactoring the code the next step is to align the code with the doc, and that's the case regardless of what changes you make during refactoring. Yeah but the way the video presents it, that change isn't being made to match a requirements doc. The way the dialogue in the video presents it, the change is being made purely because "having both 'less than' and 'less than or equal' conditions in the same function is confusing"; and then when Lady Programmer correctly says "you can't do that, it changes the meaning of the code", the narrator just handwaves it away by getting Lady Programmer, whose dialogue indicates she has no idea what the number is actually for, to say "well it's probably an approximation for one-third" and that unfounded guess is used to justify the change. The narrator does not say "the requirements indicate the comparison should be 'less than one-third'." And there's no reason to think it is, since none of that entire segment is about fixing defects in the code; only in refactoring it into something more readable. It's a shame because the rest of the film is actually really good refactoring/formatting advice that holds up today; but that bit is just blatantly wrong. It can't even really be justified with floating point hand-waving because in the era this film was made, the code would have very probably been have been running with decimal encoded numerics. (Or, at the very least, it was common enough that a film whose target audience is developers who need to be told to name their variables sensibly shouldn't be teaching them assumptions based on floating point.) biznatchio fucked around with this message at 06:44 on Dec 29, 2022 |
|
#
?
Dec 29, 2022 06:36
|
|
|
The point of that example isn't that the code is strictly incorrect or that their solution is strictly correct. Obviously the only way to know for sure would be to have the requirements right there and then and rewrite the whole thing. The point is that inconsistency invites hard questions, so you should avoid it. It's confusing. You don't know if it's a requirement or an error. You might not even notice, specially in modern languages where the difference between a "<" and a "<=" would be even more subtle. If you need to check for edge cases, it's very likely you would always check it the same way each time. It's pretty unlikely a business would want 25% exclusive and 33% inclusive. A more common example is "for (i = 0; i < N; i++)" vs "for (i = 0; i <= N - 1; i++)". Programmers are pretty inconsistent about which one they prefer, yet it's pretty easy to miss one symbol. If you suddenly see a "for (i = 0; i < N - 1; i++)" are you gonna assume it's an off-by-one error, or that the requirements said to skip the last element? You have no way to be sure from looking at it, but if it's inconsistent from the rest of the code it's gonna set off alarm bells. SupSuper fucked around with this message at 08:01 on Dec 29, 2022 |
|
#
?
Dec 29, 2022 07:59
|
|
|
SupSuper posted:In floating point you would never hit that equals condition anyways. Except it's 0.33 which, I quite hope to not have to explain why, is not 1/3rd and can be hit even with a modern float equality let alone fixed point systems of the era. Plus I already gave the example where it does in totally reasonable numbers. In my mind a LE is always paired with a GT elsewhere. We don't see the rest of the code so can't say. Changing an LE to an LT screams red flags about introducing a discontinuity. Doing a change like that "for consistency" is absolutely braindead. That he shuts down the woman coder about it is just icing on top. Ranzear fucked around with this message at 11:06 on Dec 29, 2022 |
|
#
?
Dec 29, 2022 11:03
|
|
|
The premise of the entire exercise is still that there is some problem with the code, which has not been identified. The code is wrong, there are no degrees of more more or less wrong, as long as the nature of the wrongness is not yet described. (But who knows, maybe that inequality comparison was the bug, and changing it actually fixed it?)
|
|
#
?
Dec 29, 2022 11:14
|
|
|
Ranzear posted:Also only now noticing they subtract returns from total orders, so 50 returns on 100 orders is ... 100% return rate. That's probably the real bug they were trying to fix before getting off in the weeds and breaking something else. This is the realest programming video ever! It was when I went to figure out the value that hits that equality that I found the real error. Ranzear fucked around with this message at 11:23 on Dec 29, 2022 |
|
#
?
Dec 29, 2022 11:19
|
|
|
Ranzear posted:Except it's 0.33 which, I quite hope to not have to explain why, is not 1/3rd and can be hit even with a modern float equality let alone fixed point systems of the era. Plus I already gave the example where it does in totally reasonable numbers. You're demonstrating the point of the video, which is that the inconsistency invites confusion and endless discussion. So you should try to 1) avoid inconsistency or 2) document why an inconsistency is necessary. If the equality comparison here is important then that needs to be documented somehow. The fault here is with the original author for introducing the inconsistency in the first place
|
|
#
?
Dec 29, 2022 11:26
|
|
|
Oh okay. All inconsistency is bad, even when there's a completely rational reason. I get it. Nobody should ever mix < and ≤ and I'll forget the latter existed. Context is never important. Unseen reuse of the variable is irrelevant. Changing other behavior of the code when trying to troubleshoot a major bug is just fine.
|
|
#
?
Dec 29, 2022 11:33
|
|
|
You seem hung up on this.
|
|
#
?
Dec 29, 2022 11:37
|
|
|
Ranzear posted:Oh okay. All inconsistency is bad, even when there's a completely rational reason. I get it. Nobody should ever mix < and ≤ and I'll forget the latter existed. Context is never important. Unseen reuse of the variable is irrelevant. Changing other behavior of the code when trying to troubleshoot a major bug is just fine. QuarkJets posted:1) avoid inconsistency or 2) document why an inconsistency is necessary If context requires you to be inconsistent then simply document why. It's not hard
|
|
#
?
Dec 29, 2022 11:46
|
|
|
Business requirements should be documented. If that comparison comes from a business rule and not just a result of implementation detail, then yes, there should be something written somewhere that says why that comparison is being done. Developers should not be the ones writing this, though; this should come from the business (and ideally have been written before any code was ever typed into an IDE). But saying "> and >= are both used in one function and by golly that's just too much complexity for a developer to understand" is tripe that not only creates worthless busywork, but it also indicates that you don't trust that your developers know how to read literally the most basic code constructs possible; and it also makes your documentation more worthless because if that's your standard of 'what needs to be explicitly documented', then you're going to be burying the needle of the actual interesting stuff, the knowledge that the documentation should be providing beyond what a naive reading of the code already provides, in a bunch of time-wasting "here's what the code says, just written in English" haystack. I say this as a professional developer who can understand upwards of three different boolean operators within the same class file!
|
|
#
?
Dec 29, 2022 21:54
|
|
|
I don't follow the inconsistency argument. In the code, there's one instance of LT and one instance of LE. If the LE came first, would the LT be considered inconsistent? The "improved" code uses GT first and LT later. Should the LT have been changed to GT (or vice versa)?
|
|
#
?
Dec 30, 2022 01:06
|
|
|
biznatchio posted:Business requirements should be documented. If that comparison comes from a business rule and not just a result of implementation detail, then yes, there should be something written somewhere that says why that comparison is being done. i live in this absurd and unrealistic fantasy land, assuming that asking someone in a slack dm counts as "documented"
|
|
#
?
Dec 30, 2022 01:38
|
|
|
qsvui posted:I don't follow the inconsistency argument. In the code, there's one instance of LT and one instance of LE. If the LE came first, would the LT be considered inconsistent? The "improved" code uses GT first and LT later. Should the LT have been changed to GT (or vice versa)? Inconsistency means that they're not the same, they're inconsistent with each other
|
|
#
?
Dec 30, 2022 01:39
|
|
|
The video does in fact call out the recklessness of changing the behavior of a piece of code in the process of refactoring it. It's in the context of addressing the topic of spurious precision, in a business context where it's plausible for the constant .33 to be understood as an approximation for one-third. They go ahead and change it anyway because they're demonstrating that well-structured code doesn't leave the reader wondering whether the two numbers are meant to have different precision. They've only assumed that the number is an approximation, but to treat it as precise would also be an assumption, with equally little evidence to support it, since only the long-gone original author knows why they wrote it that way. Given a choice between two assumptions, they chose the one that would let them get the code into a structured state that much more easily. If it were to turn out later on that this assumption was wrong, and that .33 really does mean exactly thirty-three hundredths, so that changing the comparison introduced a threshold bug, the structured context will make fixing that bug much easier anyway. There's an argument to be made that if you don't know why something is the way it is, you shouldn't change it, because there might be a reason that you simply don't know; and therefore they should have instead chosen the assumption that .33 is a precise value. However, if you don't know the reason for a particular exceptional behavior, it's impossible to embed an expression of that reason in the structure of your code, which would make for a poor demonstration of techniques for using the structure of code to convey more information about its meaning.
|
|
#
?
Dec 30, 2022 01:48
|
|
|
I am siding with the narrator for the fact that this code is just some sales software. No one is going to die because 0.33 is precise or not.
|
|
#
?
Dec 30, 2022 03:41
|
|
|
wolfman101 posted:I am siding with the narrator for the fact that this code is just some sales software. No one is going to die because 0.33 is precise or not. "sorry grandma died because her blood pressure medication wasn't shipped in the correct quantity due to a billing error"
|
|
#
?
Dec 30, 2022 06:59
|
|
|
Poor Grandma, thought of floating point and died.
|
|
#
?
Dec 30, 2022 07:01
|
|
|
Grandma needed that missing 0.00333333th of a pill
|
|
#
?
Dec 30, 2022 07:11
|
|
|
Volmarias posted:Very pro click right here, it's great advice and it's way, way ahead of its time. Unless you're someone like me whos been around long enough to have PTSD from their first programming job being actual COBOL. *does the thousand mile greybeard stare*
|
|
#
?
Dec 30, 2022 08:37
|
|
|
wolfman101 posted:I am siding with the narrator for the fact that this code is just some sales software. No one is going to die because 0.33 is precise or not. There was an entire genre of 1980s/90s hackers that made their money off siphoning off those missing fractions of a cent.
|
|
#
?
Dec 30, 2022 08:39
|
|
|
duck monster posted:There was an entire genre of 1980s/90s hackers that made their money off siphoning off those missing fractions of a cent. The documentary “Office Space” covers this in some detail.
|
|
#
?
Dec 30, 2022 08:48
|
|
|
beuges posted:The documentary “Office Space” covers this in some detail. You misspelled "Superman III".
|
|
#
?
Dec 30, 2022 13:55
|
|
|
|
|
#
?
Dec 30, 2022 16:53
|
|
|
New Yorp New Yorp posted:"sorry grandma died because her blood pressure medication wasn't shipped in the correct quantity due to a billing error" I told Phizer not to name the new heart medication “1; drop database *”
|
|
#
?
Dec 30, 2022 18:43
|
|
|
redleader posted:i live in this absurd and unrealistic fantasy land, assuming that asking someone in a slack dm counts as "documented" That's the beauty of it. If it's not written down as a requirement then you still absolutely shouldn't be changing the logic during a refactor!
|
|
#
?
Dec 30, 2022 19:57
|
|
|
Thank god it's documented what each value means
|
|
#
?
Dec 30, 2022 20:34
|
|
|
|
| # ? May 10, 2024 19:48 |
|
|
love to see a library in which every property accessor has a documentation string that says either "gets the value of the Foo property" or "sets the value of the Foo property" as though that were helpful to anyone, clearly solely because there is some policy saying that every method and property accessor is required to have a documentation string so they can claim they reach some documentation target
|
|
#
?
Dec 30, 2022 20:38
|
|