Hacker News Reader

Comment by BadassFractal | Hacker News Reader

The saying is that total rewrites are always a bad idea. It'll be interesting to see if this one would be an exception to the rule.

View on HN

That saying is wrong. Total rewrites for the wrong reasons are a bad idea. Total rewrites for the right reasons and with _a right team_ can be great (i.e. better abstractions, better understood domain requirements which can lead to a more simple, better codebase, enable features that were not feasible before, and so on). Succintly: If the theory of the existing system is still understood well enough and the team understands the domain requirements and has experience of implementing similar systems then a rewrite can be a great idea (ref Naur: 'Programming as theory building' on what the theory of the system means as a concept and what are it's implications). For specific businesses, total rewrites can be startup-level risky and should be done due to specific domain requirements. I think this is usually what is meant by the 'bad idea' meme. Joel Spolsky wrote of this at some point and gave example of Netscape's rewrite attempt. His advice of "don't do it" was highly context dependent, though.

When we discuss of creating a new industry standard API, we are not discussing of a single rewrite. There are a few typical patterns how these are done: 'fostering' an existing tech stack under a public institution or developing the API publicly.The public API development usually consists of two parts - agreeing on the theory of the API and implementing one or more reference implementations of the said API at the same time by member institutions.

I'm not sure how to gauge the risk of this public API development. There are costs for member organisations but usually they are insignificant when compared to the size of an institution. There is usually no established product whose feature development and support stagnates because of this but rather the development is done to facilitate potential future products and features. Of course, the API adoption can fail (ref. for example OpenVG) but that fait can befall any new development for any number of reasons.

Very informative, thanks for sharing that.

The way I've heard it is: "Total rewrites are always a bad idea. Sometimes they are necessary."

For an API with 20 years of cruft? Rewriting is the only option.

Unfortunately, it also means GL has 20 yearly of usage history and large numbers of app that using it.

Rewriting those will be much more harder. A lof of them probably not open source.

Why would you want to rewrite them? The old OpenGL will just stagnate, I imagine, not go away.

They'll continue working without a hitch. Various versions of OpenGL can live with each other.

The article gives the age as only argument for why it carries all that cruft, but it can never be the only factor. If it were, the 23 year old Linux kernel project would be rotten by now, especially with the 31 year old GNU toolkit.

Sure I understand that there might be some stuff that should be deprecated (much like with HTML elements, the old stuff can be supported while newer projects use newer and better stuff), but rewriting from the ground up also means that you have to re-educate every developer out there. They might as well go and release for Windows instead since they probably have some experience with DirectX too.

Rewriting something that many people use is a bad idea, especially when there are well-funded competitors trying to get developers onto their own platforms.

Yeah, but Linux is not afraid of removing cruft. Computers (and the x86-i386 arch) changed very little over the past 20 years, even with the 64-bit stuff

Graphical cards evolved much more in the last 15 years.

The first Direct3D versions were also bad, but they evolved and removed cruft and broke backwards compatibility.

Well, as the recent article about modernizing less showed, such old projects frequently do show their age.

I don't do 3D programming but have benefited as a happy Steam customer from the great games on Linux now. Having said that, it's generally a bad idea to re-write software with such a massive customer base on the basis of age. The term cruft doesn't qualify this notion. Refine, update sure but re-writing seems like a major overreaction.

This is a new API, not a new codebase. New APIs happen all the time.

Well OpenGL exists in the first place as cleaned up version of IrisGL (it originally was going to be IrisGL 5)

It's not a rule though. Total rewrites are often not a good idea, but sometimes they are.

Reply on news.ycombinator.com