Personal Dynamic Media08/31/2022, 4:36 PM
Jim Meyer08/31/2022, 4:45 PM
Konrad Hinsen08/31/2022, 4:59 PM
Jonathan Arnett08/31/2022, 5:31 PM
Chris Knott08/31/2022, 7:10 PM
Nick Smith09/01/2022, 2:58 AM
Konrad Hinsen09/01/2022, 6:40 AM
Tom Larkworthy09/01/2022, 7:27 AM
Chris Knott09/01/2022, 8:10 AM
Konrad Hinsen09/01/2022, 10:27 AM
Tyler Leonhardt09/01/2022, 4:38 PM
is used multiple times in a single method to iterate through multiple lists it is useful that different `i`s in different scopes are associated with different lists. It communicates an idea to other developers that the "mental load" introduced by the variable need only relate to the matter at hand and can be ignored outside of that context. In a similar way to dynamic vs typed languages you can get away without scopes with a little bit of discipline. Encoding the restrictions seems a useful way to communicate intentions of the code though. In traditional implementations it really doesn't put much burden on the author as types can in some cases.
Jason Morris09/02/2022, 4:10 PM
Chris Knott09/02/2022, 4:13 PM
Personal Dynamic Media09/02/2022, 4:32 PM
Tyler Leonhardt09/02/2022, 5:48 PM
It can be useful when you are debugging in your head ("playing computer") because it reduces the amount of possible factors affecting the program, but this is fool's gold, the actual solution is to make the computer help with debugging, so people don't have to play computer in their head at allI disagree with this, specifically the bold part. In almost every scenario the goal should be to get feedback as early as possible. Ideally you can look at a program and know what it does just like you can look at text in a book and know what it says. In many large programs it is difficult to run all of the code through a debugger, sometimes taking double digit numbers of minutes. For example, major games take minutes to compile, run, and load into maps. There are certainly use cases where you can lean more on a debugger, like scripting. Even in these scenarios most developers prefer to be able to look at code and know what it does rather than have to run it through a debugger.
Chris Knott09/02/2022, 6:16 PM
Personal Dynamic Media09/02/2022, 7:01 PM
Tyler Leonhardt09/02/2022, 8:16 PM
I think your concerns are about the current-of-programming, aren't they?
Yeah, I mean forget minutes - when I last worked in the games industry a full compile had to be done overnight. This is bad. I would be wary of basing philosophical positions on that though.
"If we adopt this language feature, compile times will be faster" is exactly the sort of tradeoff I'd classify as fool's gold.I feel like this is putting words in my mouth. I'm making this argument for past, present and future: it was true, it is true, and it will continue to be true. Looking at something and knowing it works is better than having to take extra steps to find out if it works. Games are only used as an example. I've also done OS development where the same is true. I provided scripting as a counter example where maybe your argument is stronger: it's easier to run and debug scripts. I'd be curious if you have any realistic examples where people would prefer "[making] the computer help with debugging" over being able to "[debug] in your head" (I changed the gerunds in your quotes). I can't think of any. Seems like you always want to look at a program and know it works where possible and debugging only needs to come into the picture when that fails.
Jason Morris09/02/2022, 8:42 PM
Chris Knott09/02/2022, 8:45 PM
Tyler Leonhardt09/02/2022, 8:55 PM
Hard disagree. Programs are complicated. Even if you can understand small parts well by looking at them, you have no possibility of seeing the implications of how they interact once they are beyond toy size. I'll take your second option hands down.How would even know how to write the program in the second bullet? A language could be so hard to use that its infeasible to get a program which is even debuggable. At least in the extreme case.
I agree that it would be better to be able to do it in your head but I think it's impossible.I agree that its impossible in many situations. I even agree that small programs can be difficult to get right. You can't know its right until you run. But ideally you can get it as close to right as possible before running it so that debugging time is minimized. Again, I'm not against debuggers and all code written should be run and tested so you can verify it is correct. Its just that the previous claim is too extreme for me to agree with. It certainly isn't "fool's gold" to construct better models that people can "debug in [their] head":
It can be useful when you are debugging in your head ("playing computer") because it reduces the amount of possible factors affecting the program, but this is fool's gold.
Jason Morris09/02/2022, 8:59 PM
Tyler Leonhardt09/02/2022, 9:03 PM
Chris Knott09/02/2022, 9:11 PM
Jason Morris09/02/2022, 9:12 PM
Tyler Leonhardt09/02/2022, 9:14 PM
To restate my point; people have been trying to create languages that are easier to write correctly for a long time, with comparatively little success, whereas less effort has been put into omniscient/time travel debugging/program visualisations etc.I agree much more with this framing of the point. I really take issue with calling the effort "fools gold" though. Separately, I'm not so sure folks have had "little success". In the context of "a long time". I think folks have had a lot of success at first, but it slowed down considerably over time. I made a previous point about a tradeoff between verifying with "looking at a program" vs verifying with "debugging" and I think there is a valid argument that we've gotten all the low-hanging fruit from the first and underinvested in the second.
Jason Morris09/02/2022, 9:21 PM
Tyler Leonhardt09/02/2022, 9:26 PM
Jason Morris09/02/2022, 9:32 PM
Tyler Leonhardt09/02/2022, 9:37 PM