Hacker News Reader

Comment by jgilias | Hacker News Reader

Such a weird rant. Yes, some tools do some things, but not others. Making tools do everything for everyone just bloats them to unmaintainable messes. And it’s a special kind of entitlement to believe that the way _I_ imagine things must be working is the only possible correct interpretation.

Reality is messy, there are trade-offs, and a lot of smart people think very hard about what the correct trade-offs should be given a particular situation.

And, the last pet peeve of mine. If I got a dime every time someone says ‘why don’t you just’ without even beginning to start to realize the depth of an issue, I’d be a very rich man. That’s about this quote here:

> What would it possibly take to “stabilize” such a feature? It is a completely trivial feature!

View on HN

Not having a feature is fine. Kind of having a feature but hiding it behind obnoxious gatekeeping is not fine. Features that are buggy or inexplicably complex is not fine.

Some open source projects get this right, and others don't. Some projects don't care about wasting the user's time. Or they berate the user for wanting to do something in the 'wrong' way. Or they break things that worked just fine in the pursuit of some abstract purity.

It's not about complexity or technology at all. It's an attitude problem.

I really appreciate the way Rust feature gates unstable features. It's easy to opt into nightly if you need them, it's nice that new features are iterated until they are correct and it is nice to rely on stable being stable.

You can just prefix features with --experimental so people can use their own judgement. Software should warn users when they do something that might harm them. But it shouldn't patronizingly refuse to run.

"I'm sorry bryanlarsen, I'm afraid I can't do that." - 2023 a rustfmt Odyssey.

Is the code actually there on non-nightly builds or is it just a simple text response for the experimental flag?

For the former then sure, it should just let you do the thing and simply fail loudly if it fails. For the latter, there's not much they can really do without switching you over to nightly rust.

>Features that are buggy or inexplicably complex is not fine.

really depends on so many factors that this isn't a good general sentiment. Sure, if this is a professional grade tool targeting corporate, it better be polished or have excellent support for when stuff breaks. If it's some small scrappy tool handling a complex task with all kinds of edge cases I can give some leeway to the UX and even some very esoteric use cases.

vector graphics comes immediately to mind. I won't be too griped if Krita as a FOSS has some subtle bugs. I can at the very lest throw out an issue to at least bring awareness. I'd be much more miffed if Illustrator had some issue given how closed up and hard to contact Adobe is if you're not a million dollar business (not to mention Adobe's general philosophy of how they approach software these days).

Attitude is a factor, but I do take into account the problem space when evaluating feature completeness.

Some lie about working features to get people to read into the project and fix it for them. One liar and his flyer +42 fools make a open source Projekt, even if you can not code to save your life. These projects mostly consist of issues and pull requests..

I think the point is not whether certain tool does things in certain way. It's the lack of thought about how the user interacts with the tool and whether or not the particular way of doing it makes the interaction easier. Too often "technically correct" is considered the best kind of correct even though the resulting interface is infuriatingly unpleasant to use. It's hard to please everyone, but it is useful to remind people to at least try to be more thoughtful about this aspect.

Well, but the cases he mentions are really not “just not being thoughtful”.

I’m old enough to remember that Python 2 in fact had “print <string>”, and I think also “exit”. Exactly because once upon a time Guido thought about what would feel nice to users. In time it turned out that special casing a handful of special functions introduces pain across everywhere else. Because of its valid syntax in REPL, it’s valid Python. So they removed the special casing for these functions, and added a helpful comment for people who might be confused.

Ditto for wrapping comments in Rust. Doc strings in Rust can have doc-tests in them. Meaning that whatever comment wrapping you do must not break syntax there. I don’t know what feature exactly is needed there that’s currently nightly only, but I’m very sure it’s not just something trivial that nobody has gotten around to yet.

Point being, no, everyone else except _me_ is not some dumb f*ck, who doesn’t do the obviously right thing because they hate me.

Like, that _sometimes_ happens. But these are not those cases, and in my experience it actually happens pretty rarely. I think the default disposition towards seemingly stupid implementations or behaviors should be that people working on the implementation were not sloppy idiots who hate their users, but rather that they had their reasons, and me being put into their shoes would’ve likely done the same.

> So they removed the special casing for these functions, and added a helpful comment for people who might be confused.

Technically correct. But: what happens is that when you start python, it outputs:

Type "help", "copyright", "credits" or "license" for more information.

But when you type "license", you get this:

Type license() to see the full license text

Why that happens? Because "license" is a special object that has string representation as presented above and to actually read the license, you need to call it and not just request string representation. Technically it's all clean and correct. But guess what - the user does not care. Your design is not the user's problem, the usability is the user's problem. And the usability of this kind of solution is terrible. I know why it's done, I know how it's done, I can appreciate the technical beauty of it - and it still pisses me off. They clearly knew about this case, they themselves told me to use "license" and when I did it, they say "nah bro, you forgot the parens, you idiot, try again, har har har!" It's not a huge deal, but when it happens to you thousands of times, it eventually starts to piss you off. Avoiding this kind of thing is not easy - it may actually require departing from the nice and clean design you envisioned internally, and that may be annoying to a programmer - but as a user, I much prefer that this is how it would be done. I know there are reasons, in many cases I know exactly what the reasons are, because I've been guilty myself, but that doesn't help - the whole point is, as a user, it makes my life harder. So, in our development as a software engineers, once we learn how to build technically correct things, we also need to start thinking past that - how to build things that people would enjoy using.

The promise of.. You don't need to be a domain expert but to configure and use it you do. Needs a expert and a autoconfig noob api.

Writing code should be part of the OS as fundamentally as web browsing. You should get a cursor to write code, have a tree worth of files and have a button to publish the application as a single clickable program.

Anything else is a tribute to the rant.

Just like there was only one OS out there…

But I could see the the madness anytime I squint my eyes, a large part of computing is just this.

It’s a miracle that it works at all..

Ah yes, and when I write a new language all os vendors should be forced to integrate it, or I should be blocked from inventing a new language. None of this installing code that others wrote. If I want to write a language my only option should be writing an os from the kernel up.

Give it the appropriate file extension and the os downloads relevant programs and makes it work.

I agree with the rant, but not the examples.

It pisses me off when programmers add "features" which forces users to deal with them.

For example, pipenv always prints a message when you activate an environment (I don't know if it's still the case because I don't use it anymore). I had to migrate a cronjob which ran a Python script and sent an error email if anything got printed to stderr.

This is a pretty standard Unix thing to do, but pipenv decided to always print to stderr that the environment got activated, even though it's not an error. And there is of course no way to get it to shut up. I had to use some Bash hackery to filter that out.

Ryan Dahl's 2011 rant on this is quite relevant:

> Those of you who still find it enjoyable to learn the details of, say, a programming language - being able to happily recite off if NaN equals or does not equal null - you just don’t yet understand how utterly fucked the whole thing is. If you think it would be cute to align all of the equals signs in your code, if you spend time configuring your window manager or editor, if put unicode check marks in your test runner, if you add unnecessary hierarchies in your code directories, if you are doing anything beyond just solving the problem - you don’t understand how fucked the whole thing is. No one gives a fuck about the glib object model.

> pipenv decided to always print to stderr that the environment got activated, even though it's not an error.

This is a pet peeve of mine. I see it every so often and every time, I wonder if the dev wasn't familiar with the norms of the platform or if the dev was being malicious.

Either way, it doesn't speak well for them.

>if you are doing anything beyond just solving the problem

It's a rant so I won't take it TOO literally, but: The opposite extreme of this philosophy is why we have stuff like Blender pre-2.7 and GIMP. There is some use to polishing up a proper looking UI and ensuring familiar UX. Especially if your audience is non-developers.

But yes, I understand. configs and CLIs should be as "dumb" as possible. Proper line breaks for readability and maybe color if needed, but there's nothing more frustrating than debugging what comes down to a bare basic command.

stderr is not reserved for errors. It is perfectly acceptable in *nix to print diagnostics and logs to stderr. Granted, pipenv should have a quiet flag, but you should be checking the status code if you want to be notified of errors.

> Reality is messy, there are trade-offs, and a lot of smart people think very hard about what the correct trade-offs should be given a particular situation.

This is great and all, but misses the point. If you have made a decision to cut a feature then at least explain why. This then circumvents the 'why don’t you just' mentality. That is the root of the issue in the examples provided. It would be trivial to drop a warning about the comments not being formatted and include a link to the issue. Then there is no question of 'why' and thus you're now heading off the 'It is a completely trivial feature!' attitude, and blog posts complaining about it. Communicate clearly.

The very first example in the article discredits efforts to add clear communication.

TBF the Rust comments did address the "why don't you" issues. The problem was that the alternatives were also outdated in and of themselves. It sounds more like a docs issue than a communication issue.

So what you're saying is that it was still a communication issue. I'd view it that way if what I was told was either wrong or very out of date. Docs are how you communicate.

Communication on one end. I don't agree with the dev comments, but I didn't see anything off putting about thr way the CLI comments were phrased. Most of the author's post seemed to be about the smug attitude (so, the former).

Reply on news.ycombinator.com