3 ms·

It's what everyone else is using so it's fine. Isn't the convincing argument you might hope it is.

jabradoodle 3y ago
It is relatively convincing when there are plentiful free alternatives and no one is telling you what to use (This from an emacs user).
mejutoco 3y ago
My argument is: engineering is not about best in absolute terms, but about best given constraints. Some nuance and examples of traditional engineering (titanium as material) were given, if you want to rebuke them. I am not appealing to popularity. I am offering a counterexample. It seems electron is not the problem (I showed a counter-example), but priorities are. Software engineers did not wake up and decide to make programs slow. The economic incentives decided that it was not "worth it". For that to change, the incentives need to change. Just claiming it "should" be like this is not as insightful as it may seem. In the same way we could complain about programs not being formally verified for correctness, instead of not being as fast as possible. Probably that is a worse offender.
- grayhatter 3y ago
  > My argument is: engineering is not about best in absolute terms, but about best given constraints. I usually agree. But laziness as the primary constraint should feel appalling to anyone who would willingly call themselves an engineer. Perhaps I actually mean to use a different word for engineer but I don't know what it should be > I am not appealing to popularity. I am offering a counterexample. It seems electron is not the problem (I showed a counter-example), but priorities are. I think you are, indirectly or inadvertently, citing electron and arguing in defense of it as a reasonable choice/option does do that. > Software engineers did not wake up and decide to make programs slow. The economic incentives decided that it was not "worth it". For that to change, the incentives need to change. Just claiming it "should" be like this is not as insightful as it may seem. Laziness is a choice. There are known better options, but software engineers *DID* choose to make it slow. The common axiom good, fast, or cheap; pick two. If you choose ease of development over fast you chose to make it slow. The people who build in python over C because they can write python faster, chose to make runtime slow. I guess you could argue for ignorance as a reason, but once you realize your software is slow, and refuse to do the work needed to fix it. You've also made the choice for it to be slow. > In the same way we could complain about programs not being formally verified for correctness, instead of not being as fast as possible. Probably that is a worse offender. Good engineers are willing to make the right trade offs. and I still believe that laziness is a positive trait in software engineers. But great engineers find a way to have both/everything, and people acting ethically don't prioritize their comfort or convenience over what's in the best interest of users. The problem isn't if we can or can't make it fast, or correct, or user friendly. 55GiB/s fizzbuzz proves if you care enough, anything can be fast. The problem is people don't care, and that others who also don't care throw up their hands and say good enough is acceptable. And sure by definition it is acceptable. But I'd argue everything is awful, on fire, trash, user hostile, bad because too many people go ehh good enough you can stop trying.
  - mejutoco 3y ago
    I think we basically agree. Let me address what I think is the main difference. It seems the difference is what we each are including in the "universe" of the problem. To me, it looks like you start and end with the developer (maybe developer + user), and assign laziness to them (aka you turn it into a moral problem). On my argument, I am including the company, the users, and the whole economy. In that context, it is not about what the developer wants, but about the economical incentives, and it is not a moral problem but an optimization one.

It is relatively convincing when there are plentiful free alternatives and no one is telling you what to use (This from an emacs user).

mejutoco 3y ago

My argument is: engineering is not about best in absolute terms, but about best given constraints. Some nuance and examples of traditional engineering (titanium as material) were given, if you want to rebuke them. I am not appealing to popularity. I am offering a counterexample. It seems electron is not the problem (I showed a counter-example), but priorities are. Software engineers did not wake up and decide to make programs slow. The economic incentives decided that it was not "worth it". For that to change, the incentives need to change. Just claiming it "should" be like this is not as insightful as it may seem. In the same way we could complain about programs not being formally verified for correctness, instead of not being as fast as possible. Probably that is a worse offender.

grayhatter 3y ago
> My argument is: engineering is not about best in absolute terms, but about best given constraints. I usually agree. But laziness as the primary constraint should feel appalling to anyone who would willingly call themselves an engineer. Perhaps I actually mean to use a different word for engineer but I don't know what it should be > I am not appealing to popularity. I am offering a counterexample. It seems electron is not the problem (I showed a counter-example), but priorities are. I think you are, indirectly or inadvertently, citing electron and arguing in defense of it as a reasonable choice/option does do that. > Software engineers did not wake up and decide to make programs slow. The economic incentives decided that it was not "worth it". For that to change, the incentives need to change. Just claiming it "should" be like this is not as insightful as it may seem. Laziness is a choice. There are known better options, but software engineers *DID* choose to make it slow. The common axiom good, fast, or cheap; pick two. If you choose ease of development over fast you chose to make it slow. The people who build in python over C because they can write python faster, chose to make runtime slow. I guess you could argue for ignorance as a reason, but once you realize your software is slow, and refuse to do the work needed to fix it. You've also made the choice for it to be slow. > In the same way we could complain about programs not being formally verified for correctness, instead of not being as fast as possible. Probably that is a worse offender. Good engineers are willing to make the right trade offs. and I still believe that laziness is a positive trait in software engineers. But great engineers find a way to have both/everything, and people acting ethically don't prioritize their comfort or convenience over what's in the best interest of users. The problem isn't if we can or can't make it fast, or correct, or user friendly. 55GiB/s fizzbuzz proves if you care enough, anything can be fast. The problem is people don't care, and that others who also don't care throw up their hands and say good enough is acceptable. And sure by definition it is acceptable. But I'd argue everything is awful, on fire, trash, user hostile, bad because too many people go ehh good enough you can stop trying.
- mejutoco 3y ago
  I think we basically agree. Let me address what I think is the main difference. It seems the difference is what we each are including in the "universe" of the problem. To me, it looks like you start and end with the developer (maybe developer + user), and assign laziness to them (aka you turn it into a moral problem). On my argument, I am including the company, the users, and the whole economy. In that context, it is not about what the developer wants, but about the economical incentives, and it is not a moral problem but an optimization one.