6 ms·

It's lazy when your platform still has mandatory polling decades after interrupt driven programming was invented.

by javascriptlol 15y ago

icebraining 15y ago
Interrupts are not without drawbacks. There are valid reasons to not implement them, particularly on the web.
- javascriptlol 15y ago
  So, WebSockets are a mistake then?
  - icebraining 15y ago
    Websockets are like airplanes: useful, but not for daily commuting.
    - javascriptlol 15y ago
      So do you have any technical points to make, or just more dumb excuses? If you don't want interrupts, you just use them to implement polling.
      - icebraining 15y ago
        Interrupts are stateful on the server side; that creates problems in terms of scalability, both due to increased memory usage and by being less flexible (either you have each user "locked" to a single process, or you have to implement state sharing, which adds overhead). It can also be extremely wasteful - if I leave a tab open for hours or days, you'll have to waste your resources and mine to keep pushing me stuff I won't see, while now I just hit refresh when I want to see new content. In terms of usability, it's often jarring to watch content change when you're interacting with it - that's why even sites that implement real time notifications often have a link or button that you have to press to update the UI. In many cases, doing that completely negates the benefits of pushing. Also, see the thesis on "Architectural Styles and the Design of Network-based Software Architectures": http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Polling is a good default for the web; it fits most use cases (content that rarely changes) in a simple and economical way. WebSockets are useful for the exceptions.
        javascriptlol 15y ago
        It fits most cases.. except that web applications are _constantly_ polling for information. Which may be fine, but you can implement polling with interrupts. What part of that do you not understand? Are you aware that the OS is using an interrupt-driven system to poll the server? It's just hidden from you, so you have no choice. This is just dumb engineering. And to say that it's good for "most things" is just lazy thinking. "Most things" are that way precisely because of the crappy architecture. Rationalisations.
        icebraining 15y ago
        It fits most cases.. except that web applications are _constantly_ polling for information. Web applications are a very small part of the web as a whole. you can implement polling with interrupts But why would you? Are you aware that the OS is using an interrupt-driven system to poll the server? Yes. So? In that case, interrupts are a great fit. In others, they aren't. This is just dumb engineering. Why? And to say that it's good for "most things" is just lazy thinking. It's not good: it's better for most things. There's nothing lazy about evaluating the options and choosing one. "Most things" are that way precisely because of the crappy architecture. Rationalisations. Sure, everyone who implemented this shit is dumb and lazy. It couldn't be that they have good reasons for doing what they did. I see you criticized me for not providing technical points, yet now you refuse refute them. I don't see the point of this conversation anymore.
        javascriptlol 15y ago
        You haven't made any technical points. You just waffled nonsense about scalability. I see you're bowing out of the argument because you have no case. Once you have interrupts on a platform, you have polling. If you're stuck with polling you can't recover interrupts. Which is why we have websockets decades late. The truth is there is not tension between interrupts and polling. Interrupts are plainly superior, since you can opt out of them trivially. But the platform should not opt out ahead of the developer. This turns out to be inadequate, so we get polling implemented inside interrupts and then a separate mechanism for interrupts. And the interrupt driven stuff has stupid reload buttons and so forth on the GUI. It's dumb engineering because increases complexity and leads to bad results for the user. You have no case. Polling is dumb. And if you think software engineers ever needed "good reasons" to add a bunch of pointless complexity to things, then you simply have no clue on the history of software development.

It's lazy when your platform still has mandatory polling decades after interrupt driven programming was invented.

icebraining 15y ago

Interrupts are not without drawbacks. There are valid reasons to not implement them, particularly on the web.

javascriptlol 15y ago
So, WebSockets are a mistake then?
- icebraining 15y ago
  Websockets are like airplanes: useful, but not for daily commuting.
  - javascriptlol 15y ago
    So do you have any technical points to make, or just more dumb excuses? If you don't want interrupts, you just use them to implement polling.
    - icebraining 15y ago
      Interrupts are stateful on the server side; that creates problems in terms of scalability, both due to increased memory usage and by being less flexible (either you have each user "locked" to a single process, or you have to implement state sharing, which adds overhead). It can also be extremely wasteful - if I leave a tab open for hours or days, you'll have to waste your resources and mine to keep pushing me stuff I won't see, while now I just hit refresh when I want to see new content. In terms of usability, it's often jarring to watch content change when you're interacting with it - that's why even sites that implement real time notifications often have a link or button that you have to press to update the UI. In many cases, doing that completely negates the benefits of pushing. Also, see the thesis on "Architectural Styles and the Design of Network-based Software Architectures": http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Polling is a good default for the web; it fits most use cases (content that rarely changes) in a simple and economical way. WebSockets are useful for the exceptions.
      - javascriptlol 15y ago
        It fits most cases.. except that web applications are _constantly_ polling for information. Which may be fine, but you can implement polling with interrupts. What part of that do you not understand? Are you aware that the OS is using an interrupt-driven system to poll the server? It's just hidden from you, so you have no choice. This is just dumb engineering. And to say that it's good for "most things" is just lazy thinking. "Most things" are that way precisely because of the crappy architecture. Rationalisations.
        icebraining 15y ago
        It fits most cases.. except that web applications are _constantly_ polling for information. Web applications are a very small part of the web as a whole. you can implement polling with interrupts But why would you? Are you aware that the OS is using an interrupt-driven system to poll the server? Yes. So? In that case, interrupts are a great fit. In others, they aren't. This is just dumb engineering. Why? And to say that it's good for "most things" is just lazy thinking. It's not good: it's better for most things. There's nothing lazy about evaluating the options and choosing one. "Most things" are that way precisely because of the crappy architecture. Rationalisations. Sure, everyone who implemented this shit is dumb and lazy. It couldn't be that they have good reasons for doing what they did. I see you criticized me for not providing technical points, yet now you refuse refute them. I don't see the point of this conversation anymore.
        javascriptlol 15y ago
        You haven't made any technical points. You just waffled nonsense about scalability. I see you're bowing out of the argument because you have no case. Once you have interrupts on a platform, you have polling. If you're stuck with polling you can't recover interrupts. Which is why we have websockets decades late. The truth is there is not tension between interrupts and polling. Interrupts are plainly superior, since you can opt out of them trivially. But the platform should not opt out ahead of the developer. This turns out to be inadequate, so we get polling implemented inside interrupts and then a separate mechanism for interrupts. And the interrupt driven stuff has stupid reload buttons and so forth on the GUI. It's dumb engineering because increases complexity and leads to bad results for the user. You have no case. Polling is dumb. And if you think software engineers ever needed "good reasons" to add a bunch of pointless complexity to things, then you simply have no clue on the history of software development.