Hacker News Reader

Comment by javascriptlol | Hacker News Reader

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 bothered fixing it. And it will be rationalised as a good decision now that people have been damaged into thinking it's a good thing. What's there has blinded people to what is possible. Don't let people fool you into thinking that there are good reasons why we ended up with, say, C instead of Forth. It's all rubbish. We've become a field of charlatans.

View on HN

This isn't rationalizing, but... no, automatic refreshing isn't being 'lazy'. They're called browsers because they were meant to let people browse, not consume as a TV watcher.

If I was reading a book, and the author made an update, I wouldn't necessarily want the new update from the author. Notify me there's an update? Sure! Automatically replace the copy I'm reading with the update, simultaneously removing my ability to ever get back to the version I was reading? No thanks.

"What's there has blinded people to what is possible." As someone who has a good idea of what's possible, I tend to agree, and think of browser 'cookie' support as a good example. 'cookies' were lambasted as the embodiment of evil in the mid-late 90's. The hysteria around them was insane. Why? We had little control over the visibility of what a cookie was, what it said, and how to manage them. Even today, in 2012, cookies are little understood, and to 'manager' them requires multiple clicks in to layers of menus often marked 'advanced' or 'privacy' (both are silly labels for cookie data, imo). We could have given people easier access to view/manage/understand cookie data, and probably avoided national legislation like we see in some countries now, but that would have meant breaking the status quo. Far easier to focus on browser market share and "standards compliance" as the primary measurements of browser utility and acceptance.

<blockquote>Automatically replace the copy I'm reading with the update, simultaneously removing my ability to ever get back to the version I was reading?</blockquote>

This is an asinine example. Why would the author do this except to correct typos or update the kind of information you want updated? Who are these nefarious authors trying to destroy your reading experience? They don't exist, and this kind of lazy thinking is why it took until very recently for browsers to even have the possibility of auto-update without polling (hello 1970).

Your first sentence is in conflict with your example. The UI complication of the refresh button is minuscule in comparison to the technical complexity of implementing universally canonical web page views. But even assuming you could make that work well enough it's impossible to make software that anticipates all needs correctly. A good example was brought up on 5by5 a few weeks ago: should the iPhone alarm be silenced by silent mode. People will expect it to work one way or another and they will be burned badly when it doesn't do what they expect (think setting an alarm to catch an early flight vs being in an opera).

It's easy to sit on a mountain top and spout off declarations about how things should be, but in no place is the old adage "the devil is in the details" more apropos then software development. Even the UI designer runs into these fundamental conflicts, but the low-level programmer is inundated with them. And worse yet, software stacks are so deep and CPUs so powerful that the scope of what software actually does is increasingly difficult to mentally model. The only way out of this is to ruthlessly narrow the scope and have an organization-wide emphasis on UX. This works for Apple, but consider that in order to do this they basically punt on all the hairiest business requirements because it just doesn't serve their vision. Nevertheless those requirements are real and unignorable which is why SAP et al thrive.

The reason most software is bad is not for lack of effort, it's just damn hard to do right. It's good to ask big questions, but then go try to solve some of them rather than admonish those of us who pour our lives into this.

Stop making stupid excuses. The fact that some people might get confused by some detail (like your iPhone alarm example) does not change the fact that some some other things are idiotic (like the refresh button). And your take on the refresh problem shows why this whole thing is a complete mess: I'm not suggesting "universal" auto-refresh. This is why the browsers is such a failure technologically: people want to try to solve all the problems in the platform instead of just providing simple, powerful primitives. As you recognise we need to restrict scope. The only software that actually works is simple and small. And I'm not just "admonishing others". I dropped out of academia and industry and moved into a cheaper neighbourhood to be independent so I can write the simplest software possible. To me that's better than empty talk about "UX" and other modernistic double-talk about how hard we've got it. And having an independent perspective, I can see that it's rationalisations all the way down. We will have botnets etc forever until people tackle the problems as a basic level by simple designs that eliminate the problems. But people can't even conceive of putting ethics before their own financial well-being because as an industry we have no ethics. Just pride in spreading our bullshit around as much as possible.

If software engineers built bridges we'd make it drive up and down the river, put in a few houses to be "efficient". And then when the thing breaks down we'd complain that it's "too hard". No shit it's too hard: because we promise more than we can deliver, hiding the risks and problems from the user. Firefox has as a feature in every version the ability for criminals to install rogue programs on your computer. And yet you won't see this in their marketing material. This is a solved problem. We know how to eliminate memory-safety problems, but Mozilla would rather take N years to do their rust rewrite (if it even happens) because it's in their self interest. If we had any ethics as an industry Firefox would come with a warning that it makes it possible to install rogue programs on your computer. But it won't.

You're off the deep end man. Sure, things could be immeasurably better if you could get everyone to swim in the same direction to solve the big problems. That's not how things work though, we're all in the same boat you are, trying to do the best we can in an imperfect world. This is not a failure of the profession, it's a universal human failing, maybe even more universal than that.

I only seem off the deep end because the industry has brainwashed itself. The computer no longer exclusively serves humans. Rather, humans now look to the computer to know what to do. Talk about "imperfect worlds" is the same thing irresponsible scientists say about "imperfect information". People think spreading harmful theories is fine because they have "imperfect information". It is the same with software. People have lost touch with the possibility of doing nothing instead of engaging in harmful action. If the economy was in a downturn would you see that as an excuse to turn to the tobacco business? The basic misconception here is that the production of more software overrides problems such as increasingly irreversible dependency on complex systems. I keep hearing the same thing I heard when I was in academia: admissions that people were creating problems along with endless excuses and expressions of career-motivated cowardice. Anyone who criticises the bank bailouts as moral hazard and who is also working to build complex systems today is a hypocrite. Because it is the same heroin addict thinking: that we can fix an addiction by increasing the dosage.

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 things because they seem archaic and make sure that they respond to a genuine pain point and your dev team has the chops to fully implement the solution you propose. Otherwise you're going to end up with a half-arsed unconventional UI which will just confuse everyone.

I might agree with this statement if the web had produced anything like a "conventional UI" that is consistent. Every website is completely different. Just look at Facebook. This is a horribly confusing website and most of the features are the kind of self-justifying nonsense I'm talking about. Nobody wanted Facebook until Facebook came along and convinced people to turn photo/comment sharing into a sterile game.

Err, what are you supposed to do when you edit a file on your webserver and want to see how it looks? HTTP is not NFS!

But you are mostly right, software has far, far too many pointless layers of abstraction now, requiring vast resources just to do trivial tasks. There's nothing 99% of people use a wordprocessor or a spreadsheet for that you couldn't do on an 8-bit micro in the 80s. Games these days are just not fun, whereas the 8-bit days were a golden era of creativity. We need to take it back to the old school.

"HTTP is not NFS" is a technical challenge that is potentially solvable. With single page apps the reload button is becoming increasingly irrelevant anyway though.

Writing desktop apps within a browser running on a desktop is what's crazy... Pointless layers of abstraction.

It's only pointless because we are still using the "Desktop" model. I'm not advocating one over the other but as we see Mozilla try boot to gecko and Google trying Chrome OS we are seeing the early stages of the "webtopbrowserthing" being refined. We are in that transition state where we are trying to figure out what platform is where the money is.

Those of us who have been around for a while look at what Google are doing with a sense of deja vu

http://en.wikipedia.org/wiki/NeWS

And NeWS was better in the sense that it used PS for everything rather than an unholy mess of JavaScript, CSS, HTML, etc etc.

It just goes to show that market forces do not care about technical merit and ultimate purpose in the least. NeWS never got traction, yet the advance of the web is inexorable. Why?

Well the web is supported everywhere because it was simple. The fact that it is available everywhere (which is actually pretty amazing and unique in the entire history of media if you stop and think about it) meant people kept pushing the boundaries. The limitations caused standards to be pushed forward. Wide use of the standards means no platform can break free from supporting it (Microsoft did their best for almost a decade!).

Obviously it looks like a Frankenstein monster from an engineering perspective, but it doesn't matter because that's where the investment is going. The good news is it will evolve and improve, and soon enough the grey beards who remember that there could have been a better way will all be dead; a lot like UNIX actually ;)

edit: I'd appreciate if bitter GUI developers would respond rather than misdirect their anger at the down vote button.

Well. You're getting downvoted for wishing death on people you've never met.

>The good news is it will evolve and improve, and soon enough the grey beards who remember that there could have been a better way will all be dead; a lot like UNIX actually ;)

That sounds like some sort of evil plot. For that matter my beard isn't anywhere close to being gray and I know that things could have been better. And if you didn't have +8000 karma I would think you were trolling.

That you're not just makes it worse.

Who's wishing death on anyone? It's just a colorful way of saying that people will soon enough take the web heritage of apps for granted.

>The good news is...soon enough the grey beards...will all be dead... ;)

You're the one who asked. If thats what I got out of it it's probably what the people downvoting got out of it too.

For what it's worth maybe the intended message would have come through better if you were saying it in your voice with tone and inflection rather than the way I read it as words on the screen.

What are the practical issues you're concerned about? Dev time? performance / reliability?

Dev time, you say. Well let me tell you a story. I am quite into 8-bit, I like buying micros from the 80s as junk and fixing them up. Recently, my old lady and I wanted a spreadsheet to track days off, vacations and so on. I could have done it on the quad-core, 8G Mac in Excel or online with Google Docs... But I actually did it in ViewSheet on a BBC Micro.

So dev time, well the last THIRTY YEARS of dev time haven't gotten me any anything I didn't have already.

And today I walked a mile from my grandmother's to my house. The last HUNDRED YEARS of car manufacturing haven't gotten me any anything I didn't have already.

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.

People should simply design something small that satisfies a niche. If it doesn't have enough features for some person, rewrite it. When software is small you can rewrite as much as you want. Software engineers labour in the delusion that their creations are so fantastic and amazing that it can only accomplished through huge complexity.

ViewSheet delivered a basic spreadsheet + sample code in BBC Basic to manipulate it. It could do anything Excel + VBA can do today.

Yes, as long as you can code; but in that case, so can raw assembly. Most people can't code, so that doesn't help them if they want something more. Excel, on the other hand, has features they can actually use.

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.

I would personally not put up with a spreadsheet where the GOTO cell function is rather awkardly hidden on function key number seven.

On automatic website refreshing:

See guidelines 97 and 98 from Jakob Nielsen and Marie Tahir's book 50 Websites Deconstructed [1] for the primary reason why there has been little interest in removing the "refresh" button from browsers.

Technical limitations don't really exist (and if they do exist it'd be fairly easy to solve). Server-sent events[2] and WebSocket[3] are already implemented in the latest versions of popular browsers. Modules or implementations within popular HTTP servers already exist for doing HTTP push (they tend to use older AJAX-like techniques though).

If usability was no concern (or very carefully handled) it'd be fairly easy to write your own nginx module or "WebSocket server"[4] that uses inotify to check for file system changes. For each change that impacts an open WebSocket connection, a "refresh this page" notification can be sent to the browser (which then uses JavaScript to force a page refresh). There is a potential for smarter refresh mechanisms in browsers that maintain the current scroll state, field values, etc but you'd still be frustrating the user with severe usability problems.

[1] http://www.useit.com/homepageusability/guidelines.html

[2] https://en.wikipedia.org/wiki/Server-sent_events

[3] https://en.wikipedia.org/wiki/WebSockets

[4] http://altdevblogaday.com/2012/01/23/writing-your-own-websoc...

Yes but none of these things existed in 1993. You can call it "lazy" I suppose that TBL didn't implement all the features you take for granted 20 years later before releasing the first browser(!)

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

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

So, WebSockets are a mistake then?

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.

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

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.

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.

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.

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.

Notice how the posts that are downvoted have no replies, because the downvoters cannot argue their case. How sad.

I had not downvoted you, but I thought about it - because you are making ranty, ad hominem attacks ("lazy thinking", "dumb excuses"), and you appear to be ignoring or handwaving away all the actual points anyone makes. I have no interest in engaging you in any discussion for these reasons, and I expect that other people feel the same way: hence, downvotes and lack of replies. Feel free to do what you wish with this information.

Reply on news.ycombinator.com