| > You want to make a nuanced argument that calculated unsafety is better than general unsafety, No. I'm making a simple argument. More safety is better than less safety. You're trying to move argument that since perfect safety is impossible it's not worth pursuing. This is the sophistry part. > It depends on the use-case. No it doesn't. Debugging 30k lines is always going to take more than 3/30/300 lines especially when data races are involved. > This is a strawman argument which doesn't reflect reality. I said it's a contrived counter example for a contrived example. > You can't. I chose HPC deliberately as an example: in HPC performance is the most important constraint. There are HFT systems using Java, few were on HN even. That said, you might have thought of UHFT, but those use FPGA and ASIC, so not even C/C++ would be really correct. > You don't know that. They might have looked at spaces and understood immediately that it was an improvement. I know human nature. What we are used to is what we consider natural/ergonomic. And for the record ancient Greek and Romans made it point of pride to know where and how words end. > Wouldn't that support my argument that there's room for different modes of programming, both safe and unsafe? Well, not really. I'm saying ergonomic isn't universal. Due do mixing with English and other such languages what's considered ergonomic is shifting towards spaces and punctuation. > It's the most important aspect. Every other aspect is just relevant to how you deliver value. Ok, I see where you are coming from but I fundamentally disagree. If you prioritize delivering stuff fast (move fast, break things) you'll end up with a lot of broken software, and unmaintainable messes along the way. Maintainability and safety should be primary motivatiors. Without safety, your performance gains can be rendered moot point anyway. And without maintability your code performance will slowly rot and die. |
I'm not trying to move anything. I've made the consistent argument from the beginning that more language-level safety is not the most important design constraint for all use-cases.
> No it doesn't. Debugging 30k lines is always going to take more than 3/30/300 lines especially when data races are involved.
Yes it does. See HPC use-case.
> There are HFT systems using Java, few were on HN even. That said, you might have thought of UHFT, but those use FPGA and ASIC, so not even C/C++ would be really correct.
The point still stands.
> I know human nature. What we are used to is what we consider natural/ergonomic.
Ok now I suspect you're deliberately waisting both of our time. You can't claim to know what romans thought about spaces.
> If you prioritize delivering stuff fast (move fast, break things) you'll end up with a lot of broken software, and unmaintainable messes along the way.
I never said you should prioritize delivering stuff fast. I said you should focus on delivering value. So if your code is an unmaintainable mess, cleaning up your code is going to be the shortest path to delivering more value because it affects your velocity.
If you're writing OS-level networking code, safety is going to be critical to delivering value because security is paramount to your mission.
If you're writing a game, having direct, explicit, ergonomic access to memory may be more relevant to delivering value than slowing yourself down to make sure you are 100% sure every line of code is safe.
> Maintainability and safety should be primary motivatiors.
Unless they're not. If I'm prototyping a project it might me much more important to get something in front of users to see how they like it than it is to make something safe and maintainable.
Some code is used and built on for years and years. Other code is used and thrown away after it serves its purpose.