Return to “Dev Logs”

Post

Re: [Adam] Thursday, February 15, 2018

#91
DoctorGester wrote:
Thu Feb 22, 2018 4:16 pm
So you are trying to argue you are both a good programmer and a programmer who mistypes things and fails to foresee things and your code reviewer is also like that?
To err is human.

If you are arguing that good programmers never make mistakes, then you are arguing that there are no good programmers. I know of literally zero programs of any real complexity that were bug-free on initial release, let alone at every point during development.
Games I like, in order of how much I like them. (Now permanent and updated regularly!)
Post

Re: [Adam] Thursday, February 15, 2018

#92
> To give you an example, the error I had recently (which I didn't cause, just had to fix) was because apparently C allows you to call functions on deleted and freed objects. And it works fine 99.9 percent of the cases. Like why does that even work? How does that not crash in nearly all cases?

I can't tell if you are being serious or not. "Object" being deleted doesn't mean the memory at that location simply stopped existing. It could in fact keep all the contents of your deleted struct and be fine until somebody overwrites it. If you were serious and failed to understand this concept then I have grounds to suspect that yes, you might be just not good enough to handle the complexity of your project.

Again, we are talking about a language which is targeted specifically towards experienced people who tend to write better code and make less mistakes so I'm kinda missing the point you guys are trying to prove there.


> Just typing this I have made two dozen or more mistakes in my typing that I have manually corrected.

Then you are not good at typing. I never said there are perfect people, dammit. Not in a single messages. All you can do is diminish the rate of errors, and people who are good are also good at diminishing that rate. You people are trying to mangle my words into the point of view which is easier to argue with.

> If it's obvious (like a missing semicolon) it gets fixed upon the next debug run.
> If it's non-obvious, like == instead of === it might only get noticed after a few dozen attempts to find a very specific error that only occurs sometimes in some things, and is unpredictable.

Yeah I don't think we are talking about javascript there.
Post

Re: [Adam] Thursday, February 15, 2018

#93
DoctorGester wrote:
Thu Feb 22, 2018 4:31 pm
> To give you an example, the error I had recently (which I didn't cause, just had to fix) was because apparently C allows you to call functions on deleted and freed objects. And it works fine 99.9 percent of the cases. Like why does that even work? How does that not crash in nearly all cases?

I can't tell if you are being serious or not. "Object" being deleted doesn't mean the memory at that location simply stopped existing. It could in fact keep all the contents of your deleted struct and be fine until somebody overwrites it. If you were serious and failed to understand this concept then I have grounds to suspect that yes, you might be just not good enough to handle the complexity of your project.

Again, we are talking about a language which is targeted specifically towards experienced people who tend to write better code and make less mistakes so I'm kinda missing the point you guys are trying to prove there.
so i have to write sanity checking code around every single object call?
that sure sounds faster than just using a refcounting pointer.
Post

Re: [Adam] Thursday, February 15, 2018

#95
DoctorGester wrote:
Thu Feb 22, 2018 4:36 pm
Better code structure can ensure that your code never reaches the branch where a deleted object can be used in a non-convoluted way.
so yes, sanity checking before every call.
because if i remember correctly dino is working in a multi user concurrent environment.
so references could very well be dead by the time you call them
Post

Re: [Adam] Thursday, February 15, 2018

#96
DoctorGester wrote:
Thu Feb 22, 2018 4:31 pm
> If it's non-obvious, like == instead of === it might only get noticed after a few dozen attempts to find a very specific error that only occurs sometimes in some things, and is unpredictable.

Yeah I don't think we are talking about javascript there.
You assumed JS?
It occurs in ANY weakly typed language.
I've seen it happen in a few.

However, it's a perfect example of a common error. And a non-obvious one.
Which was why I used it.

There are plenty of errors that occur in C, especially around pointers, that are super non-obvious.
°˖◝(ಠ‸ಠ)◜˖°
Toba - A Development Dump
Post

Re: [Adam] Thursday, February 15, 2018

#99
DoctorGester wrote:
Thu Feb 22, 2018 4:31 pm
I can't tell if you are being serious or not. "Object" being deleted doesn't mean the memory at that location simply stopped existing. It could in fact keep all the contents of your deleted struct and be fine until somebody overwrites it. If you were serious and failed to understand this concept then I have grounds to suspect that yes, you might be just not good enough to handle the complexity of your project.

Again, we are talking about a language which is targeted specifically towards experienced people who tend to write better code and make less mistakes so I'm kinda missing the point you guys are trying to prove there.
Could you are least try not to insult my skill (which you haven't even seen) every 5 minutes? Yes of course I know how memory works in c, and once I found the place that was calling the function on the deleted object the fix was trivial. My point is that the fact c doesn't complain makes it very hard to find when it happens. In this case it was because we are using a new iterator over a list but the objects were being deleted from the list, and the person writing the iterator (as well as someone double checking his code
) missed that there was one call on the current object left in the post loop increment. And because in 99.9 percent of cases it works fine, or was only noticed on a very specific case were apparently the memory was already overwritten in exactly the right way to actually cause a problem.
And it has clearly nothing to do with experience - the person who wrote this has been writing in c for longer than I've been alive. It's not like he didn't know it was wrong when it was pointed out, but erring is human and memory unsafe languages make it a lot easier to err, no matter how good you are.
Last edited by Dinosawer on Thu Feb 22, 2018 4:53 pm, edited 1 time in total.
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
Post

Re: [Adam] Thursday, February 15, 2018

#102
> It's not like he didn't know it was wrong when it was pointed out, but erring is human and memory unsafe languages make it a lot easier to err, no matter how good you are.

Sure, it's always a tradeoff. Easier to make a mistake, but how much time did it take you to find and fix that mistake compared to all the time you spent because you were constrained by the language?

Again I'll remind you that having clear code structure makes debugging things easier. Having telling function names makes it easier to notice possible side effects when writing code. The more good practices you employ the less error prone your code becomes because it becomes easier to write. It's just statistics.
Post

Re: [Adam] Thursday, February 15, 2018

#104
DoctorGester wrote:
Thu Feb 22, 2018 4:50 pm
Typos are eliminated by having proper naming conventions and writing code in a statically typed compiled language.
Typos are generally defined as an event where your intention is to press a certain key, but you either miss that key or press a different one by mistake. Everyone makes those. I correct typos in Josh's, Lindsey's, and Adam's devlogs after they make them... and I typically miss fixing some there too. Josh has typos in his latest Kickstarter update that he inadvertently introduced after I wrote it up for him. It's not a question of "how good are you at typing" - it's just a question of how often they occur. They can't be eliminated.
DoctorGester wrote:
Thu Feb 22, 2018 4:54 pm
Again I'll remind you that having clear code structure makes debugging things easier. Having telling function names makes it easier to notice possible side effects when writing code. The more good practices you employ the less error prone your code becomes because it becomes easier to write. It's just statistics.
I agree with this fully. :)
DoctorGester wrote:
Thu Feb 22, 2018 4:54 pm
Sure, it's always a tradeoff. Easier to make a mistake, but how much time did it take you to find and fix that mistake compared to all the time you spent because you were constrained by the language?
I believe this is the main point of disagreement in this argument. You believe that it takes less time to fix the added mistakes than is lost by having to write your own memory-handling code, regardless of how many people are working in the group, and they believe that it could take more time - specifically in an environment with a large number of programmers that may not be able to keep everyone fully up-to-date on what they're doing.

edit: I suppose it ought to be added that the main point this argument is occurring isn't the above disagreement at all, but rather that Adam insulted many of the programmers here on the LT forums - which, incidentally, make up a fairly large percentage of the userbase. I strongly doubt this was his intention. :P But... as others have said... people make mistakes.
Last edited by Talvieno on Thu Feb 22, 2018 5:05 pm, edited 1 time in total.
Have a question? Send me a PM! || People talking in IRC over the past two hours: Image
Image
Image

Online Now

Users browsing this forum: No registered users and 4 guests

cron