Hacker News Reader

Comment by emmelaich | Hacker News Reader

> Good Software Does Not Expose Its Implementation

Excellent goal but way harder than people think. I would say it is not possible in the fullest.

I kind of feel that you just read the title here. It's not talking about the 'fullest':

  An example of this would be if a music composition
  program has an easily-reached maximum song size because
  the code monkey who wrote it used a 16-bit variable
  instead of a 32-bit one. *While there are sometimes
  limitations that cannot be overcome*, the actual code
  written and the architecture used when it was written
  should have as little effect as possible on what the user
  sees and works with when using your software.

(emphasis mine)

I think it might be better rephrased as:

1) Don't add unnecessary constraints (or: Don't prioritise efficiency/etc. over the interface).

and

2) A good interface abstracts away technical problems, rather than presenting them in a different form.

The most common example I see is the password requirement that it must be between 8 and 16 characters... The 16 character limit is the main issue there... You know it has to do with the wya the data is stored.

It had better not...

And yet...

Between 8 and 16 characters, but only 7 bit ASCII. But there is no error message if you use § in your password, it just kills the server.

At my workplace the official password policy requires /exactly/ 8 character passwords...

I'm sure we agree 99%.

I don't think the goal is correct. In fact, I think the implementation should reflect the user's mental model. The closer the correspondence between the implementation's model and the user model, the less likely are surprises, bugs and limitations.

There's also the aspects of form follows function, and mechanical sympathy. The use of a tool should strongly guide its shape and design, and similarly, a user should be able to develop an intuition about what the tool is good for and what it's not good for, so they can use it to maximum effectiveness, and not be frustrated when it can't cope with a problem it's not designed for.

Totally agree. From the angle of UX and usability, the more closely the interface reflects the internal model of the system, the more accurate the users mental model of the software will be.

Indeed. Also referred to as "Leaky Abstractions"

Spolsky talked about it 16 years ago:

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

Indeed. Software is just like a person: what you see is an "interface," but what you are actually dealing with is the "implementation."

The most annoying (and visible) example of this is people naming their programs after the language/toolset used. As a user, I need not care that your code is written with Go/Python/KDE/Gnome, so why name your program with it?

Half of those don't quite belong in that list.

KDE/Gnome are much more than implementation details: writing a program for either is using a certain design languages and sets of UX rules, and those are user-visible.

Uh, it does matter though. If you're using KDE as a desktop environment, you might not want to pull in all the GTK dependencies just to run a single Gnome-based application when there's an equivalent one based on KDE. It's a common convention in Linux.

Definitely not possible. The implementation becomes the interface.

Classic example from when iOS/macOS had manual reference counting: fixing an over-retain bug in the framework causes the app with an over-release bug to crash.

Even more extreme example: https://twitter.com/gparker/status/1050903609142009856?s=20

Good software should expose its interface, not implementation.

The implementation will shine through sometimes, or will be (easily) detectable via "side-channel attacks", e.g. an interface feature can be slow due to an implementation.

OTOH this allows to upgrade and entirely change the implementation without affecting the user interface, or at least while keeping it largely backwards-compatible.

http://www.hyrumslaw.com/

Reply on news.ycombinator.com