Hacker News Reader

Comment by greggman3 | Hacker News Reader

I know of almost no software that's ever finished. This is not some conspiracy. It's just a fact of life. Examples, image editors need to load new formats. Old computers didn't have cameras, now they do, many softwares would suck without support for them. New input devices come out (mice, touch screens), software needs an update to support them. Old old computers didn't have networking. Once networking exists plenty of software will be effectively obsolete if not updated to take advantagae. Old software was ASCII only, then the net connected us to the world and not all that old software needs to support full unicode. Old software didn't support useful rich copy and paste, new use cases appear (copy and paste text, images, audio clips, video, URL links, rich text, structured graphics). Old software that can't handle this is obsolete. Old software didn't handle multiple resolutions. Try running some non-HD-DPI aware Windows software on an HD-DPI screen. Good luck reading the text. Old software thought it could own the machine. OSes realized they needed to put the user in control. Now the software needs to be updated to ask for permission instead of just crash when it fails to access something.

Most software has to be updated, period.

View on HN

>> I know of almost no software that's ever finished.

All appliances including TVs until recently. 10s to 100s of modules on cars - until recently.

I knew someone who worked in over-the-air updates at <big car company> who said the software teams kept wanting to push updates after start of production. I said "no, updates are so you can avoid the cost of recalls, not so they can finish late" and we had complete agreement. Updates are potentially good by allowing critical fixes, but they are more commonly wanted by developers who can't wrap-up a solid release on schedule.

To be clear, suppliers to the auto companies have HARD deadlines - your customer has hundreds of suppliers delivering components for a particular model year SOP and they aren't going to disrupt everyone else because your software team is late. This leads to incremental (manageable) improvements rather than big new developments (which do happen but not tied to a particular program). Abusing OTA updates to allow more slop in this is probably going to lead to some issues.

> Examples, image editors need to load new formats

Alternatively, they could be designed to support plugins.

Someone still needs to write those, and you'd need to be a psychic to succeed in making an immutable API that can handle all possible future requirements.

E.g., up until a while back, 32-bit ARGB as exchange format would've been sufficient, but is now insufficient to handle 10 bit channels and/or stuff like HDR. What if we get a standard for 3D images? It gets worse if you want to handle animated images as well, whatever exchange format you specify will break once a decade at least. And god forbid someone tries DRM for images again…

Amiga did it. We can do it again. Besides, such an API is a slow-moving target, so still better than status quo.

Are we thinking about the same thing? Amiga did not have a perfectly future-proof API. Such an invention would be the holy grail of API design.

Some future proofing is better than none, right?

The status quo is the continued existence of IrfanView, which is probably as close as it gets to the ideal. Hasn't changed much since the 1990s, and looks like it, but supports about everything via plugins.

IrfanView is updated constantly though.

Yes, but the idea is that even if the original author dies, people can still keep using the last release of the application, but independently write new plugins to interpret new image formats that come out in the future.

Winamp has a similar property. If in 2030 FLAC is replaced by some fancy neural-network based lossless encoder, it can still read the files and play them without touching the core of the application, because all that's needed is a single plugin.

Well IrfanView is open source, so if the original author dies I would expect someone else to pick it up.

Your description might help with one specific area (compression algorithms) but there are numerous other areas where you can't just use a plugin.

This works, until something about the image violate your expectation. To use the image example, say you have an image editor that uses the common assumption that a pixel is a 3-byte item, with 255 possible values. Lots of stuff worked this way, its sort of a base assumption around which you have to build all your other stuff. Violating it requires you to like change sizes everywhere, which may mean performance of your fancy vectorized algorithm plummets somewhere.

Anyway, lots of stuff follows this 8-bit-per-channel api. Until you use RAW images or any number of higher color depth . Then you need 12 or 16 or 24 or 32 (or more) bits per channel.

At the point your text processing utility that was ASCII capably gets a plugin to support UTF-8 or UTF-16 you've made so much of the core modular that it no longer serves the benefit your proposed them for. Replacing core plugins of a program that provide the actual usefulness of it is no better than just upgrading the program.

Modularity can be useful, but there's always a core, and sometimes the core needs a change.

And that's before we even get into security issues. Sometimes entirely new classes of security problems are discovered, and if they weren't known at the time of writing, how were the authors supposed to guard against them? How much can we fault browsers for not guarding against spectre/meltdown when they were first written and released?

Thats a update to.

If it was the case that you needed your image processing software to handle new formats, or your OS to handle a camera, you would go to the supplier and buy an upgrade.

If that case was any common, then upgrades would be hugely lucrative, and software distributors wouldn't be forcing people to move into a different model.

> I know of almost no software that's ever finished.

I know of quite a lot of software that is "finished" as far as I'm concerned. Developers tend not to think it is, though.

And not just software, _everything_ is updated quite regularly because of technological advances and changing preferences: cars, clothes, beverages, laws, ...

Tools generally don't, I know they have added some antivibration stuff to hammers but an old hammer still works.

As far as socket sets and crow bars go I can't think of a new feature that happened in my life time.

For screw drivers the biggest change is companies keep inventing new heads for security by obscurity reasons, not better performance.

For screw drivers that may be the case now, or it may not be. Screws became popularized in the 1700s, but it wasn't until the early 1900s we see evidence of people trying different heads (square head), and it wasn't until the Phillips head in the 1930s that we adopted a standard. Even then it was a while before it entered consumer goods; I encountered a 1940 Fibber Mcgee and Molly episode (which is what led me to looking up the history of the screw) where Fibber went to buy a screwdriver, and literally asked for "a screwdriver with a black handle", no other qualifier, and the shop keep didn't ask for clarification.

Screw drivers, who need them when you have a perfectly good hammer, amirit?

Reminds me of a joke I made in passing by the pool this summer. All the ladies were drinking their hard seltzer cans, which is very trendy last couple years in US anyways. All of them using the Yeti/similar insulated can holders (coozies). My joke was something about how the entire beverage industry aligned on a new narrow and tall can size for seltzers just so they all had to buy new drink accessories

I agree with you that a lot of software needs open ended development, but I don't believe most of it does. I like the philosophy used in the development of the Gemini protocol: software should have a clearly defined scope, it should break not bend and it should eventually be done. I think the vast majority of software doesn't actually need continuous updates.

Look at the downsides, web browsers in particular are the biggest example of the downsides to this approach. They've become megalithic blobs of unmaintainable bloat. If they'd just stuck to delivering documents and let "web app" developers develop standalone clients we wouldn't be in the situation we are in with the web.

Some software can never be done, but most of it should be done.

If web browsers had stuck to just delivering documents, the Internet wouldn't have become what it is today. We'd end up with a bunch of AOL-like walled gardens, which benefits nobody.

Your "get off my lawn" ideal for web browsers would have never worked.

That's just ridiculous. It's not a dichotomy between news sites running megabytes of software on your machine and proprietary walled garden networks. There was a near decade long golden age where people used protocols and clients, browsers delivered documents and everyone used the same global network, and you're conveniently just ignoring that to make your invalid point.

Do you like what the web is today? I know almost nobody that does. "We wouldn't have the web we have today" isn't a selling point.

I have many issues with what the web is today, but removing all interactive features from web browsers would be a very negative change in my opinion.

Why?

Think about this scenario. You boot your machine, and it boots to a beautiful environment, with all the software you need to do the things you want to do. But most of it is useless because you have to start this other piece of software that's a blank rectangle, and in that software you must type the name of the application you want to run, and it will fetch the application over the network and render it. This blank rectangle must constantly be updated with new features in order to continue fetching software to run over the network properly. Whole teams need to be employed by non profits to keep this blank rectangle up to date. An operating system inside of an operating system. You don't think this is senseless?

Now imagine this scenario: you click a link to a video, the stream opens in VLC. You click subscribe, the link opens in thunderbird. If a company wants to have some interactive service they have to give you a client, they can't just externalize that workload on a browser maintainer. Isn't that the web we wanted?

That's not a problem on platforms like ChromeOS where web apps are treated like standard apps, from the user point of view they're indistinguishable.

A solution on other operating systems would be to use Electron, but I've seen many people on here also cry foul about that.

Electron is an even worse aspect of what I described, I thought about adding a line about it but decided to stay on point. You create an entire system designed for web apps, then you create basically a site specific browser to render just one web app because users need a dedicated client. It's another step in the senseless direction.

What is senseless about that? It's common for apps to bundle their dependencies, with Electron the bundle just happens to be a app platform for HTML, CSS and Javascript that we colloquially call a web browser. I'm not really a fan of Electron myself but some of the hatred it seems to get on this website is pretty irrational and unreasonable, in my opinion.

So electron is "great" in the sense that it is a workaround to this disaster that I have described above that is the web. You have to build a web app, but you want a client application, the resources to build both are a lot so you just wrap your web app in electron. It's a stopgap and it's an enabler. It is not good for the user. As much as I dislike complex web apps, I will sooner run one in a tab in my browser than download an electron app.

Did you know that electron apps basically bundle the entire chrome browser in with every application you use it to make? Have you ever tried running more than a couple of electron apps at once?

I'm fully aware of what Electron is, you don't have to explain it. But for these teams I don't see how Electron is practically any different from any other cross-platform framework like Java. It's the same purpose. The teams using it are going for a "write once run anywhere" approach. It's not a stopgap, they're never going to spend the money on building two or more applications if they don't have to. If you think that's not good for the user, you may want to try explaining to the users that having a native app is going to cost them several times as much. That's the situations I've been in, and the cheap and easy Javascript-based solution (Electron, React Native, Flutter, etc) usually seems to win.

That's only because web apps are the default.

You build a system, the web app is supposed to be a demo of what your system can do. But since the days of Facebook, YouTube, reddit, the web app is the product itself. This is why these companies always break third party apps that connect to their API.

So you're in one of a few situations. You have to build a web app because precedent, and you don't want cost overruns. Also use case comes second to business case. And we end up where we are. It's a mess for the user, and I don't think it's sustainable, which means this problem won't exist long term.

I think they break third party apps because it's a real pain to keep maintaining a bunch of incompatible old versions of an API forever.

Also your last paragraph doesn't follow to me because the whole reason these apps exist is because they are web apps. They wouldn't exist otherwise. That's the whole reason they are sustainable now in the first place. They're the default because it's the cheapest and easiest way to deliver a product for billions of users.

It is ridiculous and senseless, but not a popular view here since there are a lot of HN'ers whose salary depends on that rectangle being the OS instead of the user's actual OS. What's even more ridiculous is that we also now have software that you download and "install" onto the actual OS, but the software itself comes bundled with another copy of that rectangle plus all the machinery underneath it. Installing an OS on an OS for each application. We have gone mad.

OS vendors could have prevented this madness, but chose the path of deliberate incompatibility with each other, so we're left with the world as it is rather than as it should be.

I sometimes joke that I am going to build a VM that runs a docker container inside which there is only an electron wrapper around Facebook.com as an art project.

How about this scenario: I vote on a comment on HN, my email client opens up with an email pre-filled by the "mailto:" link, and then I have to send it to cast my vote. What a great experience!

I hate to throw the word "stramwan" around because it gets done plenty enough already, but you just made up the most ridiculous scenario you could and then attributed it to my point to refute it.

How about this: you try turning JS off and go to HN and realize it works just fine without the bloat.

I had no idea HN had a fallback like that, but it makes sense. I'll concede that point.

So you're fine with web pages that function as applications, you just want the user experience to be stuck in 1995.

I want the user experience to be stuck in 2095. I want the user experience to be better than it is now.

I'll give you an example of a web app that I like: github. It is built as a web app because it makes sense as a web app, it works really well, there's no cruft. It could be better if it were an API with user built clients, something git is designed for anyway, but it's not bad.

I would be fine theoretically with web apps, if there were some way to ensure actual web apps that need interactive functionality were the only ones that could use it. The situation we are in now every document is a web app, every piece of content you try to see online loads it's own application just to render. I have a video player on my machine, I shouldn't have to download and render a video player onto a one size fits all abstraction layer every time I want to play a video. I shouldn't have to download an entire rendering framework just to display a CNN article.

The right way to do the web is with APIs, client applications and protocols. If you're delivering a document, I should use a client applications to render documents, which is what browsers are supposed to be. If you're building an interactive service, give your community an API to build a client or build a client yourself. An instant messaging application should not be rendered in a document delivery program delivered over HTTP. If there's some use case that requires a standard, a standalone application that implements that standard is the way to go. Think XMPP and pidgin. How terrible would it have been if XMPP could only be used in a web app?

These design decisions are not about the user, they're deliberately designed badly because incentives are misaligned. Can't find what the user bought on the internet and sell that info to marketing companies if you just deliver content and let the user choose what software they execute.

The future is what I'm looking at, not the past. To deliver a truly useful web you have to determine it's shortcomings and rethink the architecture that led to those shortcomings. Saying "this was a bad design decision and look at where it led us" is not the same as saying "let's go back to 1995."

You could've omitted most of your description and just said, "If a company wants to have some interactive service they have to give you a client."

> Isn't that the web we wanted?

No, because you just described the world we're actually in, where everything from Starbucks to the laundromat exhorts you to install their app (going so far as to nag you about it e.g. when looking then up on a map and clicking through to their website). Despite your framing it in a positive light, we know this isn't the case.

Let me try the same reframing trick to make the Web sound like the best option:

If a company wants to offer you something, whether a physical item or informational content, then they have a way for you to fill out a form and get it. There's a way to deliver digital forms in a universally understood format, and you can use a software agent to deal with them for you and handle them in whatever way you think is best.

I don't think anyone is arguing against removal of things like HTML forms, which are arguably the only good interactivity that browsers have; and indeed, a lot of "web 2.0" sites worked very well that way, no JS required.

This includes all the web forums, blogs, and even sites like YouTube and Twitter which used to actually work without JS (and were much faster too).

"The Internet today" friggin' blows. Get off my lawn indeed, lol

agreed. your software isn’t finished when it passes final qa. it isn’t finished when you deploy it to production. it isn’t finished when it has no known bugs. it’s only finished when your last user is dead.

A lot of Unix utilities have not been updated for years.

My thoughts on finishing software: https://gavinhoward.com/2019/11/finishing-software/ .

All software needs to be maintained much like food needs to be grown every year. The environment, need, situation, and security around the software is always changing so static software rots. Some rots quickly and some rots slowly but without maintenance it all rots.

> This is not some conspiracy. It's just a fact of life.

I disagree.

> Examples, image editors need to load new formats.

An image editor doesn't need to load new formats. An image editor just needs a library to convert to a format it can edit easier which almost always ends up being a bitmap of some sort.

That smells like a library. And that smells like not one library for _all_ image formats but instead one library for _each_ image format.

User wants to support the new copyright-compressed-image-video? Add a library. User doesn't want support for old-copyright-expired-and-is-now-public-domain-image-video? Don't update that library.

> Old computers didn't have cameras, now they do, many softwares would suck without support for them.

Nearly all softwares suck with support for them! Different features on the camera, different features in the software. What's needed is for software to just have a library to process an image stream and let the OS handle the camera...

> New input devices come out (mice, touch screens), software needs an update to support them.

What's new about mice that needs a software update? What's new about touch screens that needs a software update? These things haven't fundamentally changed in fifty years.

> Old old computers didn't have networking. Once networking exists plenty of software will be effectively obsolete if not updated to take advantagae

I disagree. Plenty of software shouldn't _need_ networking. That image editor? Yeah no it doesn't need networking. Your OS does though. Your OS should transparently provide any networking that you might need to edit an image on the network. Mount that network drive and your image editor should see it as if it's a local file. No update needed to the app.

> Old software was ASCII only, then the net connected us to the world and not all that old software needs to support full unicode.

Well yes but have you noticed how broken full unicode support often is? ASCII just worked.

> Old software didn't support useful rich copy and paste

And thank God for it. Rich copy and paste is a security nightmare and always ends up pasting junk and trash and vomit into something. I don't want rich copy and paste. How do I turn it off??!?!?!?!

> OSes realized they needed to put the user in control.

Hahahaha yeah... uhhh... no. Modern paid-for OSes (Windows, macOS, Android, et al) often take away more user control than they give. Dumb down the user interface so that they don't have to teach the user how things actually work and don't have to support that weird use case that the one power user used and most people wouldn't even understand. So take it away because it's just not worth the cost involved.

The problem with your suggestions is that the program would still need to be updated to support those new libraries. And new mice and touchscreens have gotten new hardware features, which require changes in the software to support them. Even something as simple as upping the resolution of the device can require an API break to widen the data type. Networking is also not something that can just be tacked on by the OS, if you want a decent experience then it needs to be built into the program.

Unicode is required if you want to have decent support for non-English text, for a really basic example you might want to try writing an ASCII document that includes multiple languages in it and see how it doesn't really work at all.

I'm not sure what you mean rich copy and paste is a security nightmare, programs that don't handle a complex data type will just ignore that type. A text editor will commonly just negotiate the type down to "text/plain" or equivalent.

> the program would still need to be updated to support those new libraries

Really? You think programs can't just load all of the libraries in a given directory?

> And new mice and touchscreens have gotten new hardware features

Yeah, like... more buttons and higher DPI

except they still boil down to the exact same interface. "Button X was pressed... button Y was released... moved +X+Y"

For real the biggest innovation I've seen in touchscreens is a sensor that tells how far away a stylus is or how hard it's been pressed. And that's really _not_ a big breaking change to require an update to every piece of software.

> Even something as simple as upping the resolution of the device can require an API break to widen the data type.

Yeah okay but that hasn't really happened any time recently. Or are you going to tell me that we should support a screen whose resolution is measured in _more than_ billions of pixels wide and tall? because I'm pretty sure your eye can't even _see_ that many pixels.

> Unicode is required if you want to have decent support for non-English text

Yes okay that's nice. That doesn't change the fact that unicode is broken in most apps.

> programs that don't handle a complex data type will just ignore that type

Programs that do handle that type are exactly what I want to stop. I absolutely never ever want to copy HTML from somewhere but there's often no way to disable it. Formatted text? Trash. Send me a file. Picture? Trash. Send me a file.

>Really? You think programs can't just load all of the libraries in a given directory?

They can't, a library implements a specific API.

>except they still boil down to the exact same interface. "Button X was pressed... button Y was released... moved +X+Y"

Well no, with multitouch the interface has changed from that to a series of events, and you have to handle gestures too. Some apps still don't support these. This isn't just for mobile devices, laptops all have these touchpads now too.

>Or are you going to tell me that we should support a screen whose resolution is measured in _more than_ billions of pixels wide and tall?

This would be for pointing devices, so yeah, with a high DPI mouse then you might want to make it 32-bit or 64-bit. This wouldn't be for billions of pixels but to subdivide into many fractions of a pixel. Example: the original Win32 API only uses 16 bits for mouse coordinates, so a new API is needed and the apps need to be changed if they want to take full advantage of that mouse.

>That doesn't change the fact that unicode is broken in most apps.

Please report those bugs to the developer, that should be fixed.

>Programs that do handle that type are exactly what I want to stop. I absolutely never ever want to copy HTML from somewhere but there's often no way to disable it. Formatted text? Trash. Send me a file. Picture? Trash. Send me a file.

I can't agree with this, I copy formatted text and pictures all the time. Your program should have the ability to remove the formatting.

> They can't, a library implements a specific API.

I'm sorry, what? That's the whole point of putting things into a library. Every library should be compatible with the common set of APIs. Any library that isn't compatible is defective.

> with multitouch the interface has changed from that to a series of events, and you have to handle gestures too. Some apps still don't support these. This isn't just for mobile devices, laptops all have these touchpads now too.

A series of events is exactly what a mouse has always reported.

Gestures? Apps don't need to support gestures. Even iOS often doesn't understand the gestures that it claims it supports. Why on earth do you think an app should support something that the OS itself can't support?

> subdivide into many fractions of a pixel

The whole point of a pixel is to be the smallest point that a program needs to understand.

> the original Win32 API only uses 16 bits for mouse coordinates

My screen resolution is 2560x1600. I have two monitors spanned, giving me 5120x1600. I can see someone having a couple dozen of them to get up beyond 65k width. But at that point the user is already reaching the limits of the hardware to render such a large number of pixels, the limits of physical space to even _have_ them.

Given that the Win32 API has been around for a few decades and I don't think we're actually reaching the hardware capabilities to need the upgrade... I'm going to simply say that you're being hyperbolic.

> Please report those bugs to the developer, that should be fixed.

No, fuck that. I have better things to do with my time than to be every developer's free QA.

Reply on news.ycombinator.com