Nothing else has value to them apart from capital and its "profitable" usage, so the fundamental reason why corporations even exist, to collectively bring about real world value takes a back seat.
792 karma · joined October 18, 2011
Nothing else has value to them apart from capital and its "profitable" usage, so the fundamental reason why corporations even exist, to collectively bring about real world value takes a back seat.
These sorts of refactorings take time, even more so if done by "committee". The good thing is that explicit interfaces have to be created thereby (hopefully) increasing adaptability and resilience over time.
Honest question, I don't really get how this would improve my work flow.
() Spec and (variably coarse) implementation plan are already grounded in code reality and are commited.
I wonder which trend will be winning though. I personally won't bet on quality.
I did subagent based removal tasks a few times. These were the ones that required the least amount of input or thinking from me, because the requirements are abundantly clear. "Remove this part of the code without breaking any other part or by porting the tests done with it onto another system."
In these situations the code acts as the bookkeeping ledger itself, and coordination complexity is almost a no-brainer.
I had the problem of crashing terminals due to OOM kills and wanted to switch to a more lightweight terminal. Also I had too many of them and couldn't find the right one any more.
I thought, why not build one yourself. The result:
https://github.com/ThePixelPilgrim/kabelsalat
It has GTK tabbed, (almost) transparently tmux-backed terminals (so quitting or crashing the app and starting it up again restores the state) in colored, named groups.
I recently added Wayland app embedding to run Chrome side by side with the terminal, local to each group, but this is still a bit shaky.
Would be nice if someone would test drive it and give me some feedback. :)
Not sure about "bugs" in that area, but there is a lot of work going on by mathematicians in formalizing and checking ever more complex proofs using proof assistants.
These systems have been tested on very complex proofs already, but well... I'm not a mathematician, just a software engineer who accepted his new role in this "new thinking order".
If I sell software to my customers that reduces their operational complexity by me investing some code, then I don't consider it a loss.
https://se-radio.net/2008/03/episode-88-the-singularity-rese...
Super interesting approach. I see this eventually be integrated into future mainstream languages, though that may take a while. I suspect that the game programming crowd will try to use it first, due to the possibility to prove certain edge cases at compile time and skip the runtime cost. But perhaps this optimization drive is no longer the case because we've got bazillions of cores nowadays. I may be too old for these predictions. Cool nonetheless.
Refactoring code to reduce the number of lines is _compression_, akin to RLE coding.
Refactoring the code to lift conceptually coherent parts is _abstraction_.
Less compression, more abstraction. Then you're fine.
edit: ah, yes also a broker controlled component manager that can start, stop, monitor services over the mentioned broker. This is the carpet that brings the room together.