61–70 of 82 posts
Earlier quoted context omitted.
A car could get you there faster, or dryer in the rain, or carrying more stuff. But there's not much Excel can do for the vast majority of users who just want a table with a few dozen records, that ViewSheet (or the granddaddy of them all VisiCalc) can't. Same with wordprocessing.
Except many of those users don't want just a table with a few dozen records - they want that plus a couple of small features. And the real problem is that they don't want the same couple of features. Hence, you end up with huge beasts to support each combination. For example, what if you want to use your spreadsheet when you're not home? Never happened to you? Well, it happened to others.
Software is too complicated. Now that we have a generation growing up with computers software engineers are happily brain-damaging them into expecting hugely complex software that doesn't really work. The browser is the perfect example. Why can the user manually reload a page? Shouldn't it all update automatically? The answer is: it's that way because it was convenient for lazy designers a long time ago and nobody bo…
Refresh does have a bit of an "implementation model of yesteryear" feel to it. On the other hand I've never observed it to be a massive pain point for users and removing it would need to be done very carefully so as not to create more problems than it solves. A warning from experience if you are thinking of implementing Alan Cooper's theories on the topic of legacy UI: Be very careful when removing conventional thing…
Earlier quoted context omitted.
Websockets are like airplanes: useful, but not for daily commuting.
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.
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
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.
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
A car could get you there faster, or dryer in the rain, or carrying more stuff. But there's not much Excel can do for the vast majority of users who just want a table with a few dozen records, that ViewSheet (or the granddaddy of them all VisiCalc) can't. Same with wordprocessing.
Except many of those users don't want just a table with a few dozen records - they want that plus a couple of small features. And the real problem is that they don't want the same couple of features. Hence, you end up with huge beasts to support each combination. For example, what if you want to use your spreadsheet when you're not home? Never happened to you? Well, it happened to others.
Earlier quoted context omitted.
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…
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 t…
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.
Earlier quoted context omitted.
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 t…
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 t…
Earlier quoted context omitted.
Except many of those users don't want just a table with a few dozen records - they want that plus a couple of small features. And the real problem is that they don't want the same couple of features. Hence, you end up with huge beasts to support each combination. For example, what if you want to use your spreadsheet when you're not home? Never happened to you? Well, it happened to others.
ViewSheet delivered a basic spreadsheet + sample code in BBC Basic to manipulate it. It could do anything Excel + VBA can do today.
Or to use my previous analogy, you're essentially saying that because you can build your own custom designed car from parts, pre-built cars are useless.
Here are some thoughts I'd put into the mix. 1. Software that is built to deadline will decay, even if the developers are good. That doesn't mean that an occasional deadline is the end, but if a long-term "deadline culture" sets in, get out. A long-standing deadline-oriented culture means you should be looking to jump to another project or company before the maintenance phase starts, because (1) the maintainers will…
I'd be curious to hear why you're so anti-IDE: do you have extensive experience working in Java with a good IDE like IntelliJ? I've heard this "IDE's are to help mediocre programmers be mediocre" argument before, but it's so alien to my experience with IntelliJ (which I've used every day for about 10 years now) that there's nearly no way to reconcile that argument with my personal experience. When I'm writing C or Ja…
I think the important question here is, does IntelliJ help you simplify existing code? Do you routinely simplify existing code? Does your team routinely simplify code? Or even better, does IntelliJ help you write simpler code in the first place? Meaning, is code written with IntelliJ routinely simpler than code written with Eclipse or Emacs?
My experience with IDE overall, is that they are of tremendous help for navigating complexity. On the other hand, they are of very little help for reducing complexity. (You cite the method renaming as an example, but compiler errors keep track of broken references just fine)
Regarding the REPL, it's not the REPL itself which is essential. It's the tight feedback loop. There are other ways to provide such a loop. Some of them are much, much better than REPLs: http://vimeo.com/36579366