4 ms·

> "Hand-crafted" imperative code will always have more potential, but most code is not this sort of code, and most engineers probably don't have the skillset to

> "Hand-crafted" imperative code will always have more potential, but most code is not this sort of code, and most engineers probably don't have the skillset to be able to do this, at least not when traded-off with implementing features and shipping customer value (no criticism, this is likely the right trade-off). This trade-off sounds like declarative frameworks make it easier for bad developers to make mediocre software while making it impossible for great developers to make great software?

tracker1 4y ago
Depends on the definition of "great" ... if you're a company building a one-off app that only a couple people are ever going to use, do you want efficient, and lower cost to build/deploy getting the job done, or do you want "great"? And would you be willing to pay out of your own pocket for others to do that work? I'm all for software quality and craftsmanship. I think far too often, far too many corners are cut, and there are often huge projects which have been poorly written. That said, it really depends. Most people only use a handful of one-off apps. But most apps are one-offs. The developer time is far more costly than the resources to run the app, or the time of the people using the app, generally speaking. Saving 0.01 seconds may make things seem smoother, but it's not really going to make the person using the app more effective.
- robenkleene 4y ago
  I'm not saying every piece of software needs to be great, just that not having the tools to be able to aloe great software at all is a problem (and I'd argue that's the direction Apple is headed in today, i.e., I don't think Apple's tech is a good choice to build another Sketch https://en.m.wikipedia.org/wiki/Sketch_(software) https://en.m.wikipedia.org/wiki/Sketch_(software) today).
danpalmer 4y ago
In my experience SwiftUI gets the right balance here. For a few hero screens we were able to implement what we wanted, with the performance we wanted, in non-idiomatic but not-bad ways. For almost the entirety of the rest of the app SwiftUI pretty much did the right thing without much work and gave us a performant app essentially for free. In our previous UIKit app so many screens had edge cases where the engineers implementing it hadn't had time to optimise for particular ways of using it, and the whole thing felt a bit janky to use. Not criticising the work they did, but the tradeoffs were such that we didn't have time to polish that much. Declarative frameworks can either make it easier for bad developers to make mediocre software while limiting great developers, or, with the right tradeoffs that I believe SwiftUI does well, they can allow bad (or time-constrained) developers to make pretty good software, while leaving the door open for great deveolopers (or more highly resourced teams) to make great software.

tracker1 4y ago

Depends on the definition of "great" ... if you're a company building a one-off app that only a couple people are ever going to use, do you want efficient, and lower cost to build/deploy getting the job done, or do you want "great"? And would you be willing to pay out of your own pocket for others to do that work? I'm all for software quality and craftsmanship. I think far too often, far too many corners are cut, and there are often huge projects which have been poorly written. That said, it really depends. Most people only use a handful of one-off apps. But most apps are one-offs. The developer time is far more costly than the resources to run the app, or the time of the people using the app, generally speaking. Saving 0.01 seconds may make things seem smoother, but it's not really going to make the person using the app more effective.

robenkleene 4y ago
I'm not saying every piece of software needs to be great, just that not having the tools to be able to aloe great software at all is a problem (and I'd argue that's the direction Apple is headed in today, i.e., I don't think Apple's tech is a good choice to build another Sketch https://en.m.wikipedia.org/wiki/Sketch_(software) https://en.m.wikipedia.org/wiki/Sketch_(software) today).

danpalmer 4y ago

In my experience SwiftUI gets the right balance here. For a few hero screens we were able to implement what we wanted, with the performance we wanted, in non-idiomatic but not-bad ways. For almost the entirety of the rest of the app SwiftUI pretty much did the right thing without much work and gave us a performant app essentially for free. In our previous UIKit app so many screens had edge cases where the engineers implementing it hadn't had time to optimise for particular ways of using it, and the whole thing felt a bit janky to use. Not criticising the work they did, but the tradeoffs were such that we didn't have time to polish that much. Declarative frameworks can either make it easier for bad developers to make mediocre software while limiting great developers, or, with the right tradeoffs that I believe SwiftUI does well, they can allow bad (or time-constrained) developers to make pretty good software, while leaving the door open for great deveolopers (or more highly resourced teams) to make great software.