|
|
|
|
|
by pointernil
4017 days ago
|
|
That's really fascinating and interesting and educating. Now every other http server implementation should need to explain every byte it is larger and every ms it is slower it terms of "why?" and "what for?" and "who gains from this?" ;) I don't know, for longer already I don't buy this tales about "it needs to be this large because..." ... mostly legacy, abstractions and ease of code maintenance etc.
This took us all into the world in which the very smallest app on the phone reacting to a click with a "beep" takes how much memory? And the software development craft accepts unbelievable inefficiencies. Memory, Cpu manufactures for long time added to this fires by essentially mis-nurturing devs by optimizing in the background and by creating an environment of limitless virtual resources. I like how "battery-life" enforces, brings back some old ideas on efficiency and software craftsmanship. Humanity starts to deal with limits of its planet, its own limits and maybe this kind of thinking will bring back some level of limits into the virtual realms as well? I think we would gain from it. |
|
(Now, if you want to talk about the actual efficacy of HTTP vs other stateless protocols, that's a different story... But I doubt we're going to go there in a thread about an assembly HTTP server where people are ooh'ing over the achivement. Not that it isn't cool, TBQF.)
Programmers at large really need to stop being pretend philosophers clutching at straws about "why things are so darn bad today!!!" (among other psuedo philosophical positions). They're mostly terrible at it, and it's almost always just so damn hamfisted and full of itself.