It's harder to subtract code than to add it
-
I'm simplifying my graphics library. I'm moving the responsibility for async operations, and other driver related nonsense outside the library. There are a number of reasons for it, KISS being the overarching philosophy. Previously I had tightly coupled drivers for this library for a bunch of display devices and platforms under Arduino but it's sort of out of scope of just graphics operations themselves. Now I have a draw on demand library that builds on my graphics library, draws as needed, and renders bitmaps to send to the display. There's very little need for a tightly coupled driver interface anymore. That means my capabilities queryable parameters get reduced significantly, no more read, async, or suspend. It's not necessary. But man, removing those breaks everything. I have endless template specializations for the various capabilities, like drawing synchronously vs asynchronously, or drawing on devices where readback isn't available (nixing things like alpha-blending and anti-aliasing). I don't need those anymore, but we're talking hundreds and hundreds of compile errors. Taking a break in the middle of it is difficult because getting back into it is tough. Adding features is easy by comparison.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'm simplifying my graphics library. I'm moving the responsibility for async operations, and other driver related nonsense outside the library. There are a number of reasons for it, KISS being the overarching philosophy. Previously I had tightly coupled drivers for this library for a bunch of display devices and platforms under Arduino but it's sort of out of scope of just graphics operations themselves. Now I have a draw on demand library that builds on my graphics library, draws as needed, and renders bitmaps to send to the display. There's very little need for a tightly coupled driver interface anymore. That means my capabilities queryable parameters get reduced significantly, no more read, async, or suspend. It's not necessary. But man, removing those breaks everything. I have endless template specializations for the various capabilities, like drawing synchronously vs asynchronously, or drawing on devices where readback isn't available (nixing things like alpha-blending and anti-aliasing). I don't need those anymore, but we're talking hundreds and hundreds of compile errors. Taking a break in the middle of it is difficult because getting back into it is tough. Adding features is easy by comparison.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Ctrl z Ctrl z Ctrl z ...
-
I'm simplifying my graphics library. I'm moving the responsibility for async operations, and other driver related nonsense outside the library. There are a number of reasons for it, KISS being the overarching philosophy. Previously I had tightly coupled drivers for this library for a bunch of display devices and platforms under Arduino but it's sort of out of scope of just graphics operations themselves. Now I have a draw on demand library that builds on my graphics library, draws as needed, and renders bitmaps to send to the display. There's very little need for a tightly coupled driver interface anymore. That means my capabilities queryable parameters get reduced significantly, no more read, async, or suspend. It's not necessary. But man, removing those breaks everything. I have endless template specializations for the various capabilities, like drawing synchronously vs asynchronously, or drawing on devices where readback isn't available (nixing things like alpha-blending and anti-aliasing). I don't need those anymore, but we're talking hundreds and hundreds of compile errors. Taking a break in the middle of it is difficult because getting back into it is tough. Adding features is easy by comparison.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'm simplifying my graphics library. I'm moving the responsibility for async operations, and other driver related nonsense outside the library. There are a number of reasons for it, KISS being the overarching philosophy. Previously I had tightly coupled drivers for this library for a bunch of display devices and platforms under Arduino but it's sort of out of scope of just graphics operations themselves. Now I have a draw on demand library that builds on my graphics library, draws as needed, and renders bitmaps to send to the display. There's very little need for a tightly coupled driver interface anymore. That means my capabilities queryable parameters get reduced significantly, no more read, async, or suspend. It's not necessary. But man, removing those breaks everything. I have endless template specializations for the various capabilities, like drawing synchronously vs asynchronously, or drawing on devices where readback isn't available (nixing things like alpha-blending and anti-aliasing). I don't need those anymore, but we're talking hundreds and hundreds of compile errors. Taking a break in the middle of it is difficult because getting back into it is tough. Adding features is easy by comparison.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Absolutely. That's one of the reasons why code usually become more complicated over time.
-
Absolutely. That's one of the reasons why code usually become more complicated over time.
I'd say new capabilities is why a system gets larger and more complicated over time. Without refactoring, new capabilities become harder to add to the original architecture. But inside almost every system is a smaller system, struggling to get out. So if customers stopped their feature requests, refactoring could slowly shrink the code base, eventually reducing it to zero. :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I'd say new capabilities is why a system gets larger and more complicated over time. Without refactoring, new capabilities become harder to add to the original architecture. But inside almost every system is a smaller system, struggling to get out. So if customers stopped their feature requests, refactoring could slowly shrink the code base, eventually reducing it to zero. :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.If customers stop their feature requests, which would come first, refactoring shrinking the code base to zero, or the need for developers reduced to zero? :omg:
There are no solutions, only trade-offs.
- Thomas SowellA day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes) -
I'm simplifying my graphics library. I'm moving the responsibility for async operations, and other driver related nonsense outside the library. There are a number of reasons for it, KISS being the overarching philosophy. Previously I had tightly coupled drivers for this library for a bunch of display devices and platforms under Arduino but it's sort of out of scope of just graphics operations themselves. Now I have a draw on demand library that builds on my graphics library, draws as needed, and renders bitmaps to send to the display. There's very little need for a tightly coupled driver interface anymore. That means my capabilities queryable parameters get reduced significantly, no more read, async, or suspend. It's not necessary. But man, removing those breaks everything. I have endless template specializations for the various capabilities, like drawing synchronously vs asynchronously, or drawing on devices where readback isn't available (nixing things like alpha-blending and anti-aliasing). I don't need those anymore, but we're talking hundreds and hundreds of compile errors. Taking a break in the middle of it is difficult because getting back into it is tough. Adding features is easy by comparison.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I forget who wrote this, but "I'm writing you a long letter because I don't have time to write a short one."
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I forget who wrote this, but "I'm writing you a long letter because I don't have time to write a short one."
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Blaise Pascal I believe
-
I forget who wrote this, but "I'm writing you a long letter because I don't have time to write a short one."
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
I have a book, a collection called "Great Short Stories of the English Speaking World" (or something like that) whose foreword explains that writing a great short story is far harder than writing a great novel. Perhaps the principle is more widely applicable than I thought!
