3 ms·
We've been making developer experience optimizations _long_ before they started demanding high salaries. The whole reason to go from assembly to C was to improv
by Kilenaitor 5y ago
We've been making developer experience optimizations _long_ before they started demanding high salaries. The whole reason to go from assembly to C was to improve developer experience and efficiency.
It seems fairly reductive to dismiss the legitimate advantages of increased productivity. It's faster to iterate on ideas and products, we gain back time to focus on more complex concepts, and, more broadly, we further open up this field to more and more people. And those folks can then go on to invest in these kind of performance improvements.
- AnIdiotOnTheNet 5y ago> It seems fairly reductive to dismiss the legitimate advantages of increased productivity. Certainly there are some, but I think we passed the point of diminishing returns long long ago and we're now well into the territory of regression. I would argue that we are actually experiencing negative productivity increases from a lot of the abstractions we employ, because we've built up giant abstraction stacks where each new abstraction has new leaks to deal with and everything is much more complicated than it needs to be because of it.
- nicoburns 5y agoHmm... I think our standards for application functionality are also a lot higher. For example, how many applications from the 90s dealt flawlessly with unicode text.
- AnIdiotOnTheNet 5y agoHow much added slowness do you think Unicode is responsible for? Because as much of a complex nightmarish standard as it is[0], there are plenty of applications that are fast that handle it just fine as far as I can tell. They're built with native widgets and written in (probably) C. [0] plenty of slow as fuck modern software doesn't handle it even close to 'flawlessly'