4 ms·

Make code obvious such that someone else tackling the same problem could write the same obvious structure and solution. Writing the naive code first, then optim

by loopz 5y ago

Make code obvious such that someone else tackling the same problem could write the same obvious structure and solution. Writing the naive code first, then optimizing, makes it more obvious how to accomplish this, including non-obvious comments and references. So make code obvious first to reduce WTF's later.

AstralStorm 5y ago
This never works. You cannot iteratively progress from a wrong algorithm to a good one in general. You can maybe optimize things by cutting off problem space, but that does not actually work in many problems. For example, quicksort and radix sort have nothing in common besides ordering things. Likewise treating a tree like a general graph won't get you to a B-tree. Trying to simulate behavior of an array with a single linked list requires an expensive and smart memory allocator. Etc. It gets even more complex if we're talking real-time software, especially multithreaded. Single thread solution does not appear even remotely similar to a performant, concurrent, ordering tolerant code.
- loopz 5y ago
  It is as you say problem dependent. In a high level language, you could start off with a generic std lib sort. Or you could start off with the intended sort algo and improve on it. The point is to make it more or less straight-forward and readable first. Then you find optimizations, inlining, etc., keeping intentions in comments and the like. For multithreaded there are design and tactics that can be documented separately, as comments would probably be too spread out anyways to be too useful. This is hard when working iteratively, as you have to work out a working solution before you know it. The problem is after tough work to end up with something working, but unreadable and less maintainable. The ideal would be to have the time to rewrite and retest, and not etch that magic brilliant code in stone. Ie. the linux kernel is a good example of code being iteratively refactored and rewritten many times. Though as you say, it'd require quite some time diving deep into such code anyway. Doing what works well should make it accessible to more than one dev. So the point is just so that others can access and modify the code a bit easier, even for tough sections. This goes very much against the grain, because of exhaustion and not wanting to take on further risks and rework.
deleted 5y ago
[deleted]

by loopz 5y ago

AstralStorm 5y ago

This never works. You cannot iteratively progress from a wrong algorithm to a good one in general. You can maybe optimize things by cutting off problem space, but that does not actually work in many problems. For example, quicksort and radix sort have nothing in common besides ordering things. Likewise treating a tree like a general graph won't get you to a B-tree. Trying to simulate behavior of an array with a single linked list requires an expensive and smart memory allocator. Etc. It gets even more complex if we're talking real-time software, especially multithreaded. Single thread solution does not appear even remotely similar to a performant, concurrent, ordering tolerant code.

loopz 5y ago
It is as you say problem dependent. In a high level language, you could start off with a generic std lib sort. Or you could start off with the intended sort algo and improve on it. The point is to make it more or less straight-forward and readable first. Then you find optimizations, inlining, etc., keeping intentions in comments and the like. For multithreaded there are design and tactics that can be documented separately, as comments would probably be too spread out anyways to be too useful. This is hard when working iteratively, as you have to work out a working solution before you know it. The problem is after tough work to end up with something working, but unreadable and less maintainable. The ideal would be to have the time to rewrite and retest, and not etch that magic brilliant code in stone. Ie. the linux kernel is a good example of code being iteratively refactored and rewritten many times. Though as you say, it'd require quite some time diving deep into such code anyway. Doing what works well should make it accessible to more than one dev. So the point is just so that others can access and modify the code a bit easier, even for tough sections. This goes very much against the grain, because of exhaustion and not wanting to take on further risks and rework.

deleted 5y ago

[deleted]