Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You can't do that because I hate you

bvisness.me

Post reply on HN
Print view View original

211–216 of 216 posts

Re: You can't do that because I hate you

#211

Post by Ferret7446 »

xdennis wrote: post #133
jgilias wrote: post #10

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 g…

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 Uni…

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.

Re: You can't do that because I hate you

#212

Post by Log_out_ »

gizmo wrote: post #59
jgilias wrote: post #10

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 g…

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 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..

Re: You can't do that because I hate you

#213

Post by Log_out_ »

smsm42 wrote: post #194
jgilias wrote: post #10

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 g…

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 remin…

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.

Re: You can't do that because I hate you

#214

Post by myaccountonhn »

8note wrote: post #92
prepend wrote: post #70

> But it does neither. It acknowledges your intent and refuses it. It’s saying “I know exactly what you want to do, but you’re doing it wrong. Do it right next time.” Programming languages follow rules and programmers should follow the rules. Just because mistake is common doesn’t mean the language should incorporate it into its functioning. That makes inconsistent behavior and is a pain in the long run because inste…

I think it's quite reminiscent of car infrastructure, in that you can know all the rules, but primarily you're interacting with other people who have varying knowledge and skill with the rules. The dutch make a strong case for the rules to follow what the people do naturally, and using design to make the correct thing the easiest one, rather than presenting a stiff ruleset and expecting people to contort themselves a…

I agree with the importance of designing things after how people act naturally, but with UX I think we sometimes go overboard with this mentality. Sometimes it feels like you can never expect people to have some base level of knowledge (or for heavens sake, make them learn something new), which makes it so that you remove vital features, change syntax to accompany what people are used to or change the architecture in a way that is more easily understood but hurts in a long run. There is a balance to struck.

Re: You can't do that because I hate you

#215

Post by Forge36 »

AceJohnny2 wrote: post #130
Forge36 wrote: post #112

Earlier quoted context omitted.

Do you have a list of favorites?

On Mac, assign traditional keybinds to Command/⌘ shortcuts (⌘-C/V for copy-paste, -S for save, etc). Display the current column number in the modeline with (setq column-number-mode t) Delete the selected area when overwriting by enabling (setq delete-selection-mode t) Save sessions (all open buffers/files) automatically on quit with (setq desktop-save-mode t) Display line numbers in the left gutter with (setq global-…

Thanks! I added

```

  (setq  column-number-mode t

  desktop-save-mode t

  display-line-numbers t

  global-auto-revert-mode t)

  (delete-selection-mode)

  (global-display-line-numbers-mode)
```

`delete-selection-mode` when set as a variable didn't work.

`display-line-numbers` appears to replace `global-linum-mode`

Re: You can't do that because I hate you

#216

Post by deterministic »

If you deprecate an API used by other developers, then you should not work on API’s used by other developers. It’s that simple.

Yes it might save a bit of time for you, but it also potentially waste orders of magnitude more time for other developers. Developers who will positively hate you for forcing them to fix something that is not a problem for them!

Instead keep the old API working and make the path to upgrade easy and smooth. Your API users will love you for it.

Post reply on HN