This essay was written in 2002 (modulo some minor updates) but although a few of its specific examples are somewhat outdated at this point, it is still extremely relevant today. https://ometer.com/preferences.html
One thing it leaves out, that I think is pretty crucial for projects smaller and more volunteer-driven than GNOME, is what to do with the energy that people are bringing to your project looking to add those options. It's easy to say "we should work hard to design these features thoughtfully!" but harder to reckon with the difficulty of building a community when the prerequisite to joining it at all is hard product-management work to make your desired feature universally applicable.
@glyph I like your optimism on the resources GNOME has :)
@zbrown not so much "GNOME has a lot" but rather how much less most other projects do
@glyph I think the ‘problem’ is the popular perception that ‘GNOME’ is a single project — really it's dozens, and many of them are lucky to have one person half looking at them…
GNOME Shell is fortunate to have somewhat of a ‘team’, including some who can contribute on company time, but it's by far the exception not the rule — things like Calculator are a single person in their free time
@zbrown
I have always wondered if there was a high-level language that suited a desktop project but wasn't found or chosen. Clearly, gjs hasn't been it, and #Vala is a lot of technical debt, and Python start-up time is an issue. Go maybe isn't high-level, and anyway came late. Maybe Smalltalk and Lisp were the only options earlier.
@glyph
@glyph
Just measured startup time some years back. I like Erlang, thought it was slow to start up, then saw it was like Python. I have seen Ruby being slower but get faster. Perl probably has always been fast. Ignoring startup time ..
Any of Python/Ruby/Smalltalk/Lisp .. if they ran too slow at the time, why didn't a desktop project start with a compiled high-level language instead of C/C++? The #GNU project had the C+Lisp template in Emacs, so it was already proven
@zbrown
@tetrislife @zbrown there have been a lot of optimizations to startup time, across the board in python in recent years. I wonder if things would be better in your metrics. About when (ideally by python major version) did you measure? On what OS?
@tetrislife @zbrown What makes you say start-up time is an issue for Python? Admittedly my computer is fairly overpowered, but I see C++ applications take as long or longer to start up than Python, and Electron can certainly be a lot slower. Python's start-up time is high enough overhead that complex *CLI* apps are often straining against it, but desktop ones?