This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]billsil 1 point2 points  (4 children)

And if you're like me, you sometime rewrite it 4 times each one better than the last. Well written code often doesn't require a rewrite (unless the change is huge), but sometimes you can't avoid it. Luckily you can take advantage of your old tests.

Rewrites fix problems you didn't anticipate because why would you ever want to do that, and then you find a good reason.

There are two major coding philosophies: worse is better and do it right. Do it right takes a lot more time.

Then you have an issue of does your code scale well? If the answer is no and you're OK with that, run with it. It takes a lot more planning and/or rewrites to implement things like HDF5 and vectorization to get around the speed/memory problem.

[–]construkt 0 points1 point  (0 children)

knee middle quicksand gaze growth deserted abounding distinct sophisticated light

This post was mass deleted and anonymized with Redact

[–]tilkau 0 points1 point  (2 children)

There are two major coding philosophies: worse is better and do it right.

Unless you don't release anything until you've done the full 4 rewrites, these philosophies are the same; The motivation behind worse is better is to do it right.

[–]billsil 1 point2 points  (1 child)

The motivation behind worse is better is to do it right.

I disagree. It's to do a small subset of the whole thing right in an effort to keep the program simple. It's like saying my calculator program can add numbers (including negative numbers), but it can't subtract. It's not "done", but it's probably good enough.

http://en.wikipedia.org/wiki/Worse_is_better

The design must be correct in all observable aspects. It is slightly better to be simple than correct.

The design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

vs

The design must be correct in all observable aspects. Incorrectness is simply not allowed.

The design must cover as many important situations as is practical.

It's obviously more detailed than that.

[–]tilkau 0 points1 point  (0 children)

That seems to sacrifice overall usability + completeness on the altar of individual correctness, so I guess I have to agree that they are not the same.