Linked by Hadrien Grasland on Fri 28th Jan 2011 20:37 UTC
OSNews, Generic OSes It's recently been a year since I started working on my pet OS project, and I often end up looking backwards at what I have done, wondering what made things difficult in the beginning. One of my conclusions is that while there's a lot of documentation on OS development from a technical point of view, more should be written about the project management aspect of it. Namely, how to go from a blurry "I want to code an OS" vision to either a precise vision of what you want to achieve, or the decision to stop following this path before you hit a wall. This article series aims at putting those interested in hobby OS development on the right track, while keeping this aspect of things in mind.
Thread beginning with comment 460211
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[11]: Machine language or C
by Alfman on Sun 30th Jan 2011 09:32 UTC in reply to "RE[10]: Machine language or C"
Alfman
Member since:
2011-01-28

"The first time code is written, the primary priority of a developer should not be speed, but cleanness, maintainability, and getting it to work."

I don't disagree with the order of priorities here. But I do believe efficiency should have a larger role up front than your suggesting.

Once the whole thing works, the "cement" has already begun to dry, so to speak.

Reply Parent Score: 1

RE[12]: Machine language or C
by Neolander on Sun 30th Jan 2011 09:54 in reply to "RE[11]: Machine language or C"
Neolander Member since:
2010-03-08

The way I interpret this "early optimization is the root of all evil" quote, it reads that one should not prioritize optimization above more important concerns the first time which code is written.

If there's no compromise to make, then I agree that it's possible to optimize right from the first time, or even at the design stage.

But what I was trying to point out is that it's relatively easy to optimize well-written code, as soon as it is sufficiently flexible by design (i.e. we can optimize without breaking function calls or thing like that). So one should not worry too much about optimization too early.

Good cement dries slowly, so to speak.

Edited 2011-01-30 10:00 UTC

Reply Parent Score: 1

RE[12]: Machine language or C
by Morin on Sun 30th Jan 2011 20:58 in reply to "RE[11]: Machine language or C"
Morin Member since:
2005-12-31

I don't disagree with the order of priorities here. But I do believe efficiency should have a larger role up front than your suggesting.

Once the whole thing works, the "cement" has already begun to dry, so to speak.


You shouldn't do *anything* up-front except writing a prototype to get feedback. Then you'll see what you did wrong, including performance issues. If "drying cement" keeps you from fixing problems, your project will have much more serious issues than performance.

Reply Parent Score: 2

RE[13]: Machine language or C
by Alfman on Sun 30th Jan 2011 23:09 in reply to "RE[12]: Machine language or C"
Alfman Member since:
2011-01-28

"You shouldn't do *anything* up-front except writing a prototype to get feedback. Then you'll see what you did wrong, including performance issues."

I don't think anybody here was referring to the prototype. Never the less, if your prototype is functional enough that it can be used for performance analysis, then it seems to me that you've already put in a significant investment, no?

In any case, if you believe in building a separate prototype and using that for performance analysis, then you really ought to agree with me that planning for an efficient design up front is important since that's essentially what a prototype is. This way you can analyze what works and performs well BEFORE you get too far into development of the production code.

"If 'drying cement' keeps you from fixing problems, your project will have much more serious issues than performance."

What is that supposed to mean?


I think I've made a strong case on why planning for efficiency early on is important, sometimes more so than optimizing later on. It doesn't really matter if I'm right or not because it flies against the tide of authoritative people who say the exact opposite. In the end, no matter how much merit my argument actually holds, I know that I've lost.

Reply Parent Score: 1