![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kriegorDisclaimer/explanation/etc: This is a code diary and most of this won't make sense; I'm largely talking to myself. If you like to watch other people flay their own brain in real time though (I sure do!) knock yourself out.
I have this rampant, rampant overdesigning problem-- but, I think, it takes a slightly different form than most overdesigning problems, at least the ones I observe-in-public. It's not that I get lost among the trees. I hate deep detail diving, actually. It's that I can see the entire shape of a problem but consistently lack the muster, rapport or simple trust to delegate anyone other than myself-- and 'myself' is consistently smaller than projected (a history of mania distorts this, it does).
As a result, most of my 'systematic' projects-- things that require an ongoing devotion of time, under the faith it will be worth it-- have hung off me like a dozen albatrosses for years, because while I can see the tradeoffs I may need to make with myself as lone actor, I'm not willing to make them as they too closely shear my preferences. TL;DR: I'm picky and uncooperative, a uniquely unhelpful pair of traits.
I'm somewhat relieved by the recent conversation to the gist of criticizing the assumption 'open source' means 'someone will be maintaining this'-- clarifying that it simply means you can read the source, for better or worse. The open vs. libre discourse has much to say on this I'm sure-- relevant cultural understandings are lost to scope and time. I have my criticisms of both-- hence, truly, seeing 'better or worse'.
(My thoughts are that the 'open source will make your code better' rhetoric focuses on first-order effects at the expense of second-order developments of culture, and the 'the ability to tweak and modify software should be a right' rhetoric focuses on second-order effects and throws out the immediate, first-order ones that get most humans' biased, emotional attention. They're both right while the trades they make are both stupid.
In other words, 'open source will make your code better' arguments are, in my eyes, logically analogous to 'we should stop thieves because they're taking someone's stuff', whereas 'open source and in turn modifiability is a cornerstone right' is logically analogous to 'we should stop thieves because it's demeaning to live in a society where you just have to sort of be okay with your stuff being stolen sometimes'. Both attitudes can quickly turn naive to who is stealing what or why. And while I am using theft as an example for a reason, the reason is not direct comparison.)
anyway
What this ever comes down to is the usual attention-dysfunction pattern: I'm much more practiced at making a new design than putting the loom time into an extant one. And I'm reluctant to engineer my time for that, as consistently 'tricking' myself into an ongoing project is an exhausting game. Additionally it doesn't help that some chunks and bits of my ego have strayed into this-- self models of 'you never finish anything', 'if anyone finds out you don't know xyz programming concept no one will take you seriously', et cetera.
I still don't know what unit tests are, for the record, and I suspect I won't unless I experience some kind of a brain injury and become amenable to working on a team, or at best working collaboratively.
There were a couple of paragraphs here, but they mostly had to do with generalizing how my own, personal experiences with self-defined programmers-above-all-else have been almost uniformly unpleasant. Problems with tech culture as they are I don't think I'm in a state of mind to comment on them.
The design for uc2e goes something like this:
- Make a compatible ('modern' is specifically not used here) port of c2e, a la openMW etc. Its features and library use should be generic enough to compile on any C-supporting platform in the forseeable future.
-- This is a bit of a challenge since a nontrivial amount of c2e's features rely on manual and platform-specific memory mapping, but I think I can manage.
I'm not the first person to try this and I won't comment on the other attempts other than to blanketly define them as unsuccessful (albeit I have gotten much utility out of scanning openc2e's code).
I had, for a time, considered trying to do this in JavaScript ('wc2e'). While-- and I can see this all too clearly, by the principle described in the first paragraph-- perfectly possible, I now drill some barriers into the ground; I lack the necessary patience with others' code for this and the sands of the underlying platform are too 'shifting' to match my level of potential output. Basically, I justify my emotional distaste for high-level, syntactically 'wiggly' languages by emphasizing the context that I simply don't have the resources to maintain or adapt a codebase to 'keep up with the times' -- and I say, in this vindication, as if the function of a computer has meaningfully changed since networking and individual PCs became norms!
It has, of course. But I omit the nuance to prevent another decade of tilting.
The 'u' is 'mu', for micro.
At any rate, the first level of subtasks looks something like: In a relatively platform-agnostic, but high-performance way, reimplement:
- platform independent i/o
- scrolling 2d graphics at arbitrary resolutions
- an entire scripting language with the necessary caching to keep things copacetic
- a 2d physics engine matching the behavior of an extant one, with no canonic source for its constants; this will probably become a task for a disassembler when the time comes
- the Creatures brain
- the Creatures genetic system
- 2d 'skeletal' graphics
- various binary parsers; fortunately, these all do have a canonic layout
From a distance, not that tall of an order. Some of these tasks are not of the same scale as the others, though. The CAOS parser essentially involves writing an entire API; almost everything in the c2e is done through CAOS, the major exceptions being the entire modest rest of this list.
And as it is I'm too insecure to admit that heap management still commands considerable respect and fear from me. Maybe that's as it should be.
Anyway, I've decided to kick off 'serious' development (remember what I said I was going to start when I moved? well, I meant it, even if it incurs months' lag) with some tools for this purpose I've meant to make for years-- specifically a PRAY decompilar for the moment as none of the extant ones satisfy me (monk's java requirement is insufferable and I can't tweak revelation to my needs nor recompile it). The code is nasty, but it's mine, and maybe the rest of this will continue to be so too.
I will mull on 'serious' for a moment. Was it 'serious' endeavors that earned me any progression in visual art? No; it was habituality; and the observation that my style has crystallized largely to improvisational, single-sitting work despite what I might be "oh so capable" of potentially does not escape me in this comparison. I've been experimenting, since I moved, with making my situation with verbal and logical projects similar.
Part of the danger with including disassembly of c2e itself as a tool is that I experience a temptation to try to copy the engine 1:1 when the original engine ... actually had some pretty glaring problems. One of the 'pros' of considering writing it in JS was being freed from this-- can't indulge if the same libraries aren't even available, much less usable or relevant to the platform. I've now eschewed that and it's back. I suppose I have to trust myself to structure it better on my own.
I have this rampant, rampant overdesigning problem-- but, I think, it takes a slightly different form than most overdesigning problems, at least the ones I observe-in-public. It's not that I get lost among the trees. I hate deep detail diving, actually. It's that I can see the entire shape of a problem but consistently lack the muster, rapport or simple trust to delegate anyone other than myself-- and 'myself' is consistently smaller than projected (a history of mania distorts this, it does).
As a result, most of my 'systematic' projects-- things that require an ongoing devotion of time, under the faith it will be worth it-- have hung off me like a dozen albatrosses for years, because while I can see the tradeoffs I may need to make with myself as lone actor, I'm not willing to make them as they too closely shear my preferences. TL;DR: I'm picky and uncooperative, a uniquely unhelpful pair of traits.
I'm somewhat relieved by the recent conversation to the gist of criticizing the assumption 'open source' means 'someone will be maintaining this'-- clarifying that it simply means you can read the source, for better or worse. The open vs. libre discourse has much to say on this I'm sure-- relevant cultural understandings are lost to scope and time. I have my criticisms of both-- hence, truly, seeing 'better or worse'.
(My thoughts are that the 'open source will make your code better' rhetoric focuses on first-order effects at the expense of second-order developments of culture, and the 'the ability to tweak and modify software should be a right' rhetoric focuses on second-order effects and throws out the immediate, first-order ones that get most humans' biased, emotional attention. They're both right while the trades they make are both stupid.
In other words, 'open source will make your code better' arguments are, in my eyes, logically analogous to 'we should stop thieves because they're taking someone's stuff', whereas 'open source and in turn modifiability is a cornerstone right' is logically analogous to 'we should stop thieves because it's demeaning to live in a society where you just have to sort of be okay with your stuff being stolen sometimes'. Both attitudes can quickly turn naive to who is stealing what or why. And while I am using theft as an example for a reason, the reason is not direct comparison.)
anyway
What this ever comes down to is the usual attention-dysfunction pattern: I'm much more practiced at making a new design than putting the loom time into an extant one. And I'm reluctant to engineer my time for that, as consistently 'tricking' myself into an ongoing project is an exhausting game. Additionally it doesn't help that some chunks and bits of my ego have strayed into this-- self models of 'you never finish anything', 'if anyone finds out you don't know xyz programming concept no one will take you seriously', et cetera.
I still don't know what unit tests are, for the record, and I suspect I won't unless I experience some kind of a brain injury and become amenable to working on a team, or at best working collaboratively.
There were a couple of paragraphs here, but they mostly had to do with generalizing how my own, personal experiences with self-defined programmers-above-all-else have been almost uniformly unpleasant. Problems with tech culture as they are I don't think I'm in a state of mind to comment on them.
The design for uc2e goes something like this:
- Make a compatible ('modern' is specifically not used here) port of c2e, a la openMW etc. Its features and library use should be generic enough to compile on any C-supporting platform in the forseeable future.
-- This is a bit of a challenge since a nontrivial amount of c2e's features rely on manual and platform-specific memory mapping, but I think I can manage.
I'm not the first person to try this and I won't comment on the other attempts other than to blanketly define them as unsuccessful (albeit I have gotten much utility out of scanning openc2e's code).
I had, for a time, considered trying to do this in JavaScript ('wc2e'). While-- and I can see this all too clearly, by the principle described in the first paragraph-- perfectly possible, I now drill some barriers into the ground; I lack the necessary patience with others' code for this and the sands of the underlying platform are too 'shifting' to match my level of potential output. Basically, I justify my emotional distaste for high-level, syntactically 'wiggly' languages by emphasizing the context that I simply don't have the resources to maintain or adapt a codebase to 'keep up with the times' -- and I say, in this vindication, as if the function of a computer has meaningfully changed since networking and individual PCs became norms!
It has, of course. But I omit the nuance to prevent another decade of tilting.
The 'u' is 'mu', for micro.
At any rate, the first level of subtasks looks something like: In a relatively platform-agnostic, but high-performance way, reimplement:
- platform independent i/o
- scrolling 2d graphics at arbitrary resolutions
- an entire scripting language with the necessary caching to keep things copacetic
- a 2d physics engine matching the behavior of an extant one, with no canonic source for its constants; this will probably become a task for a disassembler when the time comes
- the Creatures brain
- the Creatures genetic system
- 2d 'skeletal' graphics
- various binary parsers; fortunately, these all do have a canonic layout
From a distance, not that tall of an order. Some of these tasks are not of the same scale as the others, though. The CAOS parser essentially involves writing an entire API; almost everything in the c2e is done through CAOS, the major exceptions being the entire modest rest of this list.
And as it is I'm too insecure to admit that heap management still commands considerable respect and fear from me. Maybe that's as it should be.
Anyway, I've decided to kick off 'serious' development (remember what I said I was going to start when I moved? well, I meant it, even if it incurs months' lag) with some tools for this purpose I've meant to make for years-- specifically a PRAY decompilar for the moment as none of the extant ones satisfy me (monk's java requirement is insufferable and I can't tweak revelation to my needs nor recompile it). The code is nasty, but it's mine, and maybe the rest of this will continue to be so too.
I will mull on 'serious' for a moment. Was it 'serious' endeavors that earned me any progression in visual art? No; it was habituality; and the observation that my style has crystallized largely to improvisational, single-sitting work despite what I might be "oh so capable" of potentially does not escape me in this comparison. I've been experimenting, since I moved, with making my situation with verbal and logical projects similar.
Part of the danger with including disassembly of c2e itself as a tool is that I experience a temptation to try to copy the engine 1:1 when the original engine ... actually had some pretty glaring problems. One of the 'pros' of considering writing it in JS was being freed from this-- can't indulge if the same libraries aren't even available, much less usable or relevant to the platform. I've now eschewed that and it's back. I suppose I have to trust myself to structure it better on my own.
