Live data from Hacker News

Shitlist Driven Development (2016)

sirupsen.com

41–50 of 148 posts

Re: Shitlist Driven Development (2016)

#41
post #25

If you don't want people to use deprecated code, it's essential to document what the replacement should be. In JavaWorld, this can be done through Javadoc. Just tagging a method or class with @Deprecated and leaving it there is the sort of thing that makes me want to hurt people.

This is literally one of the topics covered in the article and the author advocates for the same solution, documenting the alternative in the error/deprecation message...

Re: Shitlist Driven Development (2016)

#42
post #25

If you don't want people to use deprecated code, it's essential to document what the replacement should be. In JavaWorld, this can be done through Javadoc. Just tagging a method or class with @Deprecated and leaving it there is the sort of thing that makes me want to hurt people.

This is literally one of the topics covered in the article and the author advocates for the same solution, documenting the alternative in the error/deprecation message...

Is supporting the article's position frowned upon?

Re: Shitlist Driven Development (2016)

#43
post #42

Earlier quoted context omitted.

This is literally one of the topics covered in the article and the author advocates for the same solution, documenting the alternative in the error/deprecation message...

Is supporting the article's position frowned upon?

No. But when it's not explicitly mentioned as support, it can appear as an implicit contradiction to readers. We also want the discussion about an article to build on what the article proposes, and explicitly tying comments to the article help with that.

Re: Shitlist Driven Development (2016)

#44

Earlier quoted context omitted.

... windows ? MacOS ? Literally every Adobe software ? Literally every large audio / video / 3d création software ? Every large game engine ? I don't know, I notice pretty much the opposite in the field of software I know - smaller software come and go, but the large ones were there 20 years ago and will likely still be there in twenty years

So you'd write a new application using win32? There is a lot of inertia driving maintenance on some of these large products but there is also a ton of deprecation taking place internally relative to them.

Yes, yes I would. I'm pretty sure that Win32 will be supported in 30 years, without much maintenance effort, compared to whatever new hotness that is popular today.

Re: Shitlist Driven Development (2016)

#45

I will probably remember Sirupsen forever for his move of breaking Golang projects by renaming his github username. This led to go modules freaking out because different project used different name casing for the dependency. He has a popular logging library and go modules are angry when you rename github usernames..

Does go-lang not have "official" repos, including clones of popular repos, to avoid deps on personal repos?

Or is this an "unofficial but popular" library?

Re: Shitlist Driven Development (2016)

#46
post #6

Here, a “shitlist” tracks existing uses of deprecated behavior within a large code base. It prevents new uses of deprecated behavior without disrupting legacy code. This is a temporary measure used to facilitate refactoring large code bases.

Not necessarily temporary. Abandoned (but critical) code might stay on the shitlist forever if it's not worth migrating it.

Re: Shitlist Driven Development (2016)

#47

I will probably remember Sirupsen forever for his move of breaking Golang projects by renaming his github username. This led to go modules freaking out because different project used different name casing for the dependency. He has a popular logging library and go modules are angry when you rename github usernames..

Does go-lang not have "official" repos, including clones of popular repos, to avoid deps on personal repos? Or is this an "unofficial but popular" library?

Go imports are done by direct github URL mostly.

Re: Shitlist Driven Development (2016)

#48
post #37

I'm more curious about how things like shitlists are implemented in different languages. Most of my experience is C#, where calling deprecated code triggers a warning. Considering that C# warnings will fail in CI, how would someone do a C# shitlist? Would it require some kind of #pragma, that would stick out like a sore thumb in a code review

My preference is when violating the shitlist is a compile/build/lint error.

Re: Shitlist Driven Development (2016)

#49
post #25

If you don't want people to use deprecated code, it's essential to document what the replacement should be. In JavaWorld, this can be done through Javadoc. Just tagging a method or class with @Deprecated and leaving it there is the sort of thing that makes me want to hurt people.

That’s because you don’t understand what deprecated means.

Deprecated means “still supported but its use is discouraged.” It does not mean “no longer supported.”

Post reply on HN