Hacker News new | comments | ask | show | jobs | submit login

The quotes in the paper are interesting: "Nobody actually creates perfect code the first time around, except me. But there’s only one of me.” Linus Torvalds, 2007

And another, which highlights why there might be many more unearthed bugs, and would probably go unnoticed. "I suspect that making the scheduler use per-CPU queues together with some inter-CPU load balancing logic is probably trivial . Patches already exist, and I don’t feel that people can screw up the few hundred lines too badly"

Looking at the bigger picture in general, this again shows that getting software right is not easy. Now and then you still hear about the bugs popping up in the code which is very core to an OS. One I can recall is a decade old TCP bug which Google fixed last year[1].

[1] http://bitsup.blogspot.sg/2015/09/thanks-google-tcp-team-for...




I don't think the paper contradicts the second quote. It just points out that things got a lot more complex since.

"this again shows that getting software right is not easy."

Not easy, yes, but in my experience getting software right isn't too difficult. What seems impossibly hard is keeping software right, maintaining correctness in the presence of new requirements, compatibility constraints and just sheer caring about different things than we used to[1]. At some point I suspect you'd get a better design by rewriting things from scratch. But the way we do development makes rewriting stressful and error-prone, leading to the repeated arguments about whether rewriting is good or bad[2]. The question isn't whether rewriting is good or bad. Software is the most malleable medium known to man, and we should do all we can to embrace that essential malleability that is its primary characteristic and boon. The question is how not to mess up rewriting, how to keep our clay from gradually getting more and more brittle under the weight of added constraints.

(I work on this problem: https://github.com/akkartik/mu/blob/7f5a95cdbe/Readme.md. It's been 31 days since I last got on my soapbox in this forum: https://news.ycombinator.com/item?id=11285529.)

[1] "The future is a disagreement with the past about what is important." http://carlos.bueno.org/2010/10/predicting-the-future.html

[2] Against rewrites: http://www.joelonsoftware.com/articles/fog0000000069.html; https://steveblank.com/2011/01/25/startup-suicide-%E2%80%93-... https://basildoncoder.com/blog/pg-wodehouse-method-of-refact.... Pro-rewrite seems the minority position: http://brettweigl.tumblr.com/post/48385335083/what-can-produ... http://building.wanelo.com/2012/09/14/the-big-switch-how-we-... http://alicebob.cryptoland.net/why-i-rewrote-quivi-from-scra... (with many apologies). And yet we've seen several major rewrites: Netscape (for all Joel Spolsky's criticism above, would Firefox had been possible without the rewrite? Echoing Jeff Bezos's dictum, open source projects can afford to be misunderstood for a long time), Python 3 [edit: no, Python 3 was not a rewrite as I was corrected below], Perl 6, Angular 2. A more balanced viewpoint: https://blog.learningbyshipping.com/2013/04/02/surviving-leg....


Python 3 does not belong on the list of rewritten projects. Python 3 was not a rewrite. It just introduced major breaking changes in the API.


It had the same external effects of a rewrite. If Python didn't have such a large userbase it could have been an extinction level event.


Ah, thanks for the correction.

But why did Python 3 take so long to release, then?


It's not that python 3 took a long time to release. It's that it consciously broke compatibilities with pyton 2, and library authors took a long time to port their library to python 3, so a lot of people writing python didn't even bother looking at it.


A 10 year transition† around that breaking change was the plan all along ever since PEP 3000 (dating, unsurprisingly, from 2006), with:

- time for things to settle and eventual mistakes to be fixed (3.0, 3.1, 3.2) while the 2.x line lives

- lockstep 2.x versions that include stdlib and language (vai __future__) feature backports from 3.x line (2.6, 2.7) to get maximum portability and minimum tech debt for new code written on 2.x line.

- finally, impetus to transition with non-backported new language and stdlib features (3.4, maybe 3.3 already)

and of course, letting time for lib authors to port their existing code.

Never has it been the plan for people to instantly port existing, non-lib code to python 3.0 (or even 3.1 or 3.2), and never has it been so that python 3.x instantly obsoletes the 2.x line, and in fact, quite the opposite.

So people that like the new-n-shiny and blindly jump onto the latest version bandwagon were definitely in for the roughest ride, and gave Python 3 the bad rep we know.

I honestly prefer the way this transition has been handled rather than the "hey everything is compatible except it's not and things are subtly breaking all around" attitude from Ruby which I have to deal with now.

† the 10 year figure was somewhere in a ML that I can't seem to get a hold on back when I was working with Python and having to plan for this transition.

[PEP 3000]: https://www.python.org/dev/peps/pep-3000/


Ah, I see, so Python 3 only took a couple of years, about the same as any minor release: https://en.wikipedia.org/wiki/History_of_Python#Version_rele...


You can see Guido’s 2006 talk about the project here for some history https://www.youtube.com/watch?v=UIDdgeISLUI


You are thinking of Perl


The best example is of SSL. Over a decade and we have not even got "correctness" part right.


Over a decade? It's over twenty years old! SSL/TLS & its XPKI are complete and utter jokes.


That shows a massive revealed preference, and says nothing about what is possible in software.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: