RANT: Throwing around code does not REALLY help users.
- NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California
Re: RANT: Throwing around code does not REALLY help users.
There's also a difference between using a graphics library without dissecting it when writing a game, and using a graphics library without dissecting it when writing a graphics library. The latter is much more like osdev when you copy paste driver code.
- gravaera
- Member
- Posts: 737
- Joined: Tue Jun 02, 2009 4:35 pm
- Location: Supporting the cause: Use \tabs to indent code. NOT \x20 spaces.
Re: RANT: Throwing around code does not REALLY help users.
Go and use google, and find the specification. this site (http://www.mcamafia.de/mcapage0/mcamafia.htm) has on it, somewhere, I cannot recall where, a FULL list of ALL of the original IBM PC specifications, including a full, official BIOS interrupt list, information on the standard behaviour of the FDD controller, and everything.bewing wrote:I'm going to partially disagree with quok. There are circumstances, and then there are other curcumstances.
For example: I am currently working on floppy controller code, and it is very confusing, because the old wiki article was a stub, none of the emulators match any real hardware that I can access, the datasheet contradicts itself in many places, and leaves out several vital pieces of info.
Honestly, I'd LOVE for someone to throw me some code for floppy controllers at this point, that works on all real hardware.
I can learn from code just fine.
I can try each little subsection that is different from what I'm doing now, and see what they did that makes it work.
That is EXTREMELY useful information.
But for newbies, you are right, quok.
It takes a hell of a lot of experience to be able to take apart a piece of working code, to see WHY it works. Really, just as much experience as it takes to read through somebody else's code, to tell them why theirs DOESN'T work.
So you have to target your audience. If it is a newbie posting, tell them in words how to do it, or pseudocode. If you are talking to an advanced OSdever -- feel free to post code, I'd say.
How did I find it and you didn't? It's a literal gold mine. It even has full documentation on the original VGA and XGA registers, and whatnot. I remember feeling elated when I found it some months back.
What justification is there for me and my hard work, at finding rare, precious documentation, and reading through it, and someone else now expecting me to water down everything to try to 'help' them? I think it would be best if they used google'd and found the information on their own. Improves their search skills, and gets them the best source for know-how: the original documentation.
EDIT: And note: this is one reason why when people are told to google, and they come and say "I checked google and didn't find anything" it really doesn't make sense.
--Do better
gravaera
Last edited by gravaera on Mon Dec 07, 2009 4:51 pm, edited 1 time in total.
17:56 < sortie> Paging is called paging because you need to draw it on pages in your notebook to succeed at it.
Re: RANT: Throwing around code does not REALLY help users.
Absolutely true, and that's why I said I agree with the general sentiment. However, it seemed everyone here agreed with not using someone else's code at all.Solar wrote:There's a difference between a function library, complete with test cases, documentation, a CHANGES.txt and an URL being given where to retrieve future maintenance releases, and an undocumented piece of code tossed at someone.
JAL
Re: RANT: Throwing around code does not REALLY help users.
Again, when you take tested/trusted code, I see no reason for disection. If I were to port SDL to my OS, I defintely would not disect the code. Nor would I when porting GCC, or glibc, or whatnot.NickJohnson wrote:There's also a difference between using a graphics library without dissecting it when writing a game, and using a graphics library without dissecting it when writing a graphics library. The latter is much more like osdev when you copy paste driver code.
JAL
-
- Member
- Posts: 25
- Joined: Fri Dec 04, 2009 10:08 am
Re: RANT: Throwing around code does not REALLY help users.
If anyone ever answers one of my questions with code could you please comment it well enough that someone could decipher it (hey at least most of the code here isn't in perl...). Not pointing fingers (I wouldn't know who to point at) but I've been there before and un-commented code (C less so than Assembly) is nearly impossible to read. As a side note even though I'm a noob and probably ill-prepared for my upcoming venture I highly doubt I'd use someones code if they posted it even if I could understand it completely (kinda defeats the whole purpose to me).
Re: RANT: Throwing around code does not REALLY help users.
It depends. When it is written well enough, and not too long, and you have some additional documentation, then uncommented code would suffice.monkeykoder wrote:I've been there before and un-commented code (C less so than Assembly) is nearly impossible to read.
Well, recognizing you are ill-prepared will probably help you along a lot better than all the noobs that say things like "I know a bit of C and I want to make an OS with networking and a webbrowser". As for reusing code: sometimes it may help you along, especially it is code in an area you don't want to focus on (yet). If it is well-tested, use it. Not every aspect of OS making may be to you liking.As a side note even though I'm a noob and probably ill-prepared for my upcoming venture I highly doubt I'd use someones code if they posted it even if I could understand it completely (kinda defeats the whole purpose to me).
JAL
Re: RANT: Throwing around code does not REALLY help users.
That's all fine and quite in line with what NickJohnson said. He made the distinction between e.g. porting SDL / GCC / glibc, and e.g. using someone else's task scheduler.jal wrote:Again, when you take tested/trusted code, I see no reason for disection. If I were to port SDL to my OS, I defintely would not disect the code. Nor would I when porting GCC, or glibc, or whatnot.NickJohnson wrote:There's also a difference between using a graphics library without dissecting it when writing a game, and using a graphics library without dissecting it when writing a graphics library. The latter is much more like osdev when you copy paste driver code.
Every good solution is obvious once you've found it.
-
- Member
- Posts: 25
- Joined: Fri Dec 04, 2009 10:08 am
Re: RANT: Throwing around code does not REALLY help users.
I just hope that someday I am prepared for the task at hand trying will at least tell me how much I don't know.jal wrote:It depends. When it is written well enough, and not too long, and you have some additional documentation, then uncommented code would suffice.monkeykoder wrote:I've been there before and un-commented code (C less so than Assembly) is nearly impossible to read.
Well, recognizing you are ill-prepared will probably help you along a lot better than all the noobs that say things like "I know a bit of C and I want to make an OS with networking and a webbrowser". As for reusing code: sometimes it may help you along, especially it is code in an area you don't want to focus on (yet). If it is well-tested, use it. Not every aspect of OS making may be to you liking.As a side note even though I'm a noob and probably ill-prepared for my upcoming venture I highly doubt I'd use someones code if they posted it even if I could understand it completely (kinda defeats the whole purpose to me).
JAL
This thread reminds me of being in an analysis class there were two types of people in that class math geeks and people that wanted to teach high school math. The people that wanted to be teachers would spend hours memorizing proofs so they could spill them out on the test. The math geeks would spend hours pouring over the book and talking about why the proofs worked. I'd say both groups had people on both sides of the pass/fail line but the math geeks knew what they had done and the others didn't. Each person gets to choose what group they're in let each choose (I will say the pass rate was higher among the math geeks...).