Everything is a $ABSTRACTION and Microkernel Hell

[mystran]

And besides, originally we talked about OS design, and honestly - if a developer cannot work correctly unless he's got a "safe" language runtime and GC to take him by the hand, I don't want him near OS code anyway. But that's just MO.

Well, just yesterday, trying to clean up one particular misfunctioning piece of code, I was thinking something like: world would probably be so much better place, if all programming code had to be written with editors without a copy-paste function.

[Solar]

world would probably be so much better place, if all programming code had to be written with editors without a copy-paste function.

ROTFL... I know exactly how you feel.

[Candy]

Or if your product wasn't rated by the amount of LOC - which promotes that kind of programming - but by the amount of LOC versus the amount of used features realised by that code.

[Solar]

I much prefer if my work is rated by how good it works.

Counting LOC is like measuring the psi of a boxer's punch. It doesn't tell you sh*t about how good a boxer he is.

[Candy]

I much prefer if my work is rated by how good it works.

Counting LOC is like measuring the psi of a boxer's punch. It doesn't tell you sh*t about how good a boxer he is.

Amount and content of punches versus quality of knock-out and following of rules is a pretty fair indication afaik. At least, the only way to cheat it is to make short simple code that does a lot - which is what I want.

[mystran]

I'd say if you measure programming work by how long it takes until there are no more serious bugs vs the number of features, then it's highly likely that any well scoring code will also have relatively low LOC count for the number of features, as soon as there is anything non-trivial required from the code.

Besides, large LOC count isn't bad in itself. It's just that if there's duplication in the code, then if said duplication has to be changed (say, there's a bug, or requirements change or expand) then the changes have to be made in several places, and this is where the problems come.

Hence, for any non-trivial combination of features, only well written code is ever likely to reach the point of "no more serious bugs." Ofcourse the code might not starts it's life as "well written" but sooner or later it has to be refractored, if continued maintenance with finite time investment is desired.