Filesystem devs should aim to make “badly written” app code “just work” (2009)
1–10 of 117 posts
Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)
#2Told you: Perl is built by the gods.
Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)
#3Suggestion: I think the title should be:
> Linus: Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
His point seems to be more about accepting reality and allowing the practice (which in this case is theoretically "badly written" code) to "just work".
As the title stands now:
> Linus: People should aim to make "badly written" code "just work"
One might incorrectly assume Linus is suggesting that defensive programming should be practiced heavily -- but that does not appear to be what he is saying here.
Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)
#4Quite a bizarre read considering Linux's decision to e.g. overcommit memory makes 100% correctly written code break nondeterministically...
Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)
#5"Anybody who wants more complex and subtle filesystem interfaces is just
crazy. Not only will they never get used, they'll definitely not be
stable."
I think there is a more universal truism here - that "complex and subtle" are sources of pain, problems and headaches.
I want to write "cool" and "magical" code as much as the next person, but that's the stuff that I look at later WTF because I am no longer in the same state of mind. Clear, simple, straight forward, plain as day are better than anything else.
And if you do have to do something "magical" something "odd" or hard to understand for the love of god please leave notes explaining what, why and how you did what you did. And if you are replacing a "clean" and "readable" version leave it there commented out. Sure it is "in the repo" but almost no one ever looks and you are just making it harder for me to figure out the original intent of whatever was there.
Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)
#6(2009)
Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)
#7I think the message is that we should make the basic stuff "just work" before we start adding the complexity of more bells and whistles.
Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)
#8The thread title omits a crucial word: "Filesystem" (as in "filesystem people", not just "people"). The point he is making is that filesystems are supposed to be utterly reliable; applications should not have to take extreme precautions to avoid having the filesystem lose their data. And the fact that practically nobody actually takes any precautions, let alone extreme ones, is strong evidence that programmers do in fact expect filesystems to be that reliable.
Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)
#9Suggestion: I think the title should be: > Linus: Theory and practice sometimes clash. And when that happens, theory loses. Every single time. His point seems to be more about accepting reality and allowing the practice (which in this case is theoretically "badly written" code) to "just work". As the title stands now: > Linus: People should aim to make "badly written" code "just work" One might incorrectly assume Lin…
Or perhaps “Filesystems should aim…”. Which is what he actually seemed to mean.
Re: Filesystem devs should aim to make “badly written” app code “just work” (2009)
#10Is there a point though, when badly written code becomes so hard to maintain and improve, that people would just avoid doing that altogether?
The reason "badly written" works for Open Source is that if code is useful - there will be someone in the future who will refactor it. In proprietary setting that only happens when the fate of the company itself (or a large chunk of the business) is at stake. Otherwise stagnation is king.