Love4Boobies wrote:
Far from it, you see kids picking it up with relative ease but there aren't too many quantum physicist or neuroscientist kids out there.
Yeah, and have you seen the kind of code that they write?
Love4Boobies wrote:
When you have a choice between being clever/efficient and doing it in a simple manner, the latter is almost always the correct answer.
over-optimised < efficient, efficient > bloated. In short, don't mistake efficient code for over-optimised code (at which point is because unreadable/difficult to maintain), and don't mistake bloated code for simple code. Of the two implementation examples that I gave, the first would be bloated because it's doing more work than necessary, while the second would be efficient because it's doing just the work that's required to complete the task (and it's not over-optimised).
Love4Boobies wrote:
And I wouldn't recommend non-compliance. Imagine parsing a huge code base, like Linux, with a non-compliant parser; you think you'll like the results?
I never advocated non-compliance. What I did advocate was not supporting extensions to a standard and specific variants of a particular format/protocol when they're a) seldom used b) give you an undesirable amount of work and/or make your code ridiculously complicated and c) are beyond the scope of your project. I also mentioned that my experience with official standards documents is that they give you the full details of all of these additional variations and don't tell you the 10%, 50%, 75% or whatever of the standard that you need to implement to actually write code that works in 99% of cases and 100% of all cases that you care about.
Case in point: type 2 MIDI files do exist, but almost nobody uses them so unless you're writing a specialised application for recovering data from MIDI files you probably don't need to worry about them beyond "throw an error if the user has one". (Note: I said
almost nobody - I'm not talking about parsing the entire Linux kernel codebase here, but an average-sized project picked at random from GitHub.) You don't need to implement every HTTP header and response code to write a working HTTP client that will allow you to browse the internet, but if you want to write a robust client that will work no matter what then you'll need to implement everything (and for laughs include HTCPCP in that as well).
It's about getting the balance between robustness/flexibility and complexity. And what I'm advocating is a category on the wiki for pages that say "here's how you can get xxx up and running on your OS" (e.g. "here's how you can get a working HTTP client" or "here's how you can get a working media player" or "here's how you can get a working image-loading library" or whatever else, we should probably include TCP/IP in there). I'm not saying that we should cover every detail of every protocol, but to give people the information that they need to turn their practically-useless OS into something with an interesting userspace that they can say "look, it even plays MP3 files!" instead of being restricted to "look, it can read a FAT filesystem!".
What's more, there are already OSdevers out there who have sifted through the standards documentation and figured out what's needed to make something usable, and there's no reason to not let them share it with the rest of us.