3 ms·

I think, given a language that supports elegantly catching exceptions, it is inevitable that things like that will be written. And why not? The language makes t

by ATsch 5y ago

I think, given a language that supports elegantly catching exceptions, it is inevitable that things like that will be written. And why not? The language makes them nice to write, which signals to users that it is something you should be using a lot. I think the approach Go, Rust and others take there is the right way to go. By making panics annoying or even impossible to recover from in some cases, they ensure that they are only used for their intended purpose and are not abused as a general purpose control flow mechanism.

josephg 5y ago
> it is inevitable that things like that will be written. And why not? We can't just blame the programming language for programmers not understanding how computers work. I think as computers have gotten faster, and languages higher level, we've stopped talking about computers as mechanical devices. And this is a really important perspective to have. Can you answer these questions about your program? - How big is your binary / JS bundle? What parts take up most of the space? - When your program runs, what does the computer spend most of its time executing? What parts of your program are the slowest, and why? - How big is the memory footprint? Which parts of your program use the most RAM? For binary programs (like rust / Go / C), which patterns are easier or harder for the optimizer? If there are two ways to design your code, how do you discover which approach will run faster? This stuff shouldn't be considered advanced concepts. An architect understands the building they've designed. A chef knows what their food tastes like. When you program, you're making a thing. You should understand what you made and how it will be executed on the computer.
- ATsch 5y ago
  I'm not sure what you're arguing with here. The need to understand what you're doing is not at odds with designing our tools to make it easy to do the right thing. Quite the opposite, knowing what we are doing helps us write good tools and good tools help us know what we are doing.

by ATsch 5y ago

josephg 5y ago

> it is inevitable that things like that will be written. And why not? We can't just blame the programming language for programmers not understanding how computers work. I think as computers have gotten faster, and languages higher level, we've stopped talking about computers as mechanical devices. And this is a really important perspective to have. Can you answer these questions about your program? - How big is your binary / JS bundle? What parts take up most of the space? - When your program runs, what does the computer spend most of its time executing? What parts of your program are the slowest, and why? - How big is the memory footprint? Which parts of your program use the most RAM? For binary programs (like rust / Go / C), which patterns are easier or harder for the optimizer? If there are two ways to design your code, how do you discover which approach will run faster? This stuff shouldn't be considered advanced concepts. An architect understands the building they've designed. A chef knows what their food tastes like. When you program, you're making a thing. You should understand what you made and how it will be executed on the computer.

ATsch 5y ago
I'm not sure what you're arguing with here. The need to understand what you're doing is not at odds with designing our tools to make it easy to do the right thing. Quite the opposite, knowing what we are doing helps us write good tools and good tools help us know what we are doing.