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..
Shitlist Driven Development (2016)
31–40 of 148 posts
Re: Shitlist Driven Development (2016)
#32It's better to use a Shiterator, which can yield pieces of shit on demand, lazily enumerate them just in time, and generate infinite streams of shit, instead of allocating all your shit up front, and having your shit together in one place.
Re: Shitlist Driven Development (2016)
#33On a somewhat related note: One of the biggest things I've noticed is that simpler pieces of software are less likely to be deprecated, whereas complex codebases quickly become legacy and abandoned...
... 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.
Re: Shitlist Driven Development (2016)
#34Earlier 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.
On Windows, almost every "new" API is built on top of Win32.
Obviously, if you're writing a simple CRUD application, you'll never need to go down there. (You'll probably make a browser application or an Electron application.)
But if you're doing something unique, like a utility, or trying to hook into the OS to make it do something new, you gotta work at the lower level APIs.
And, yes, I shipped a product that included a Windows driver this year. It required working at the Win32 level in user-mode to communicate with the driver, and to test the driver. Windows recently added a new API to Windows 10 that eliminated the need for a driver, but we still had customers on Windows 7. Even then, that new API is technically Win32.
Re: Shitlist Driven Development (2016)
#35Shitlist driven migration/refactor, maybe. If it's development it means you're always deprecating something and that's a significant organizational smell.
If software is organic, and there are limits to growth, how is it that you don’t always have something changing?
And why is it an organizational smell?
Re: Shitlist Driven Development (2016)
#36If 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.
Seems to me that if you want shitlists to drive development then often there won't be an immediate replacement.
Re: Shitlist Driven Development (2016)
#37I'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
Re: Shitlist Driven Development (2016)
#38It's better to use a Shiterator, which can yield pieces of shit on demand, lazily enumerate them just in time, and generate infinite streams of shit, instead of allocating all your shit up front, and having your shit together in one place.
That's elegant dungtional programming but it's not really relevant here as you are supposed to check if new crap matches any of the enumerated fecal matter; how would you do that against an infinite stream of diarrhea? I'd leave this to the type system if possible. And of course use a colon-delimited list for the occasion.
Re: Shitlist Driven Development (2016)
#39Earlier 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.
I still write new applications in Win32 (or x64). If you want to ensure your app works on as many environments out of the box as possible this is the way to go. In fact, you shouldn’t even depend on DLL version of C runtime as they may not exist on the environment.
Re: Shitlist Driven Development (2016)
#40It's better to use a Shiterator, which can yield pieces of shit on demand, lazily enumerate them just in time, and generate infinite streams of shit, instead of allocating all your shit up front, and having your shit together in one place.
haha so irrelevant yet funny