see below, please. regards,
Richard Erlacher ----- Original Message ----- From: "Dave McGuire" <[EMAIL PROTECTED]> To: <sdcc-user@lists.sourceforge.net> Sent: Friday, September 05, 2008 1:17 PM Subject: Re: [Sdcc-user] documentation & open source generally > On Sep 5, 2008, at 2:37 PM, Richard Erlacher wrote: >>>> I could say that, but it wouldn't be the case. When you "poke >>>> around in the >>>> dark" all that you can report or that you can learn is what you've >>>> observed. >>>> If you know how it's SUPPOSED to behave, then you can draw some >>>> valid >>>> conclusions about the things you've observed. Do you see the >>>> distinction? >>> >>> Sure I do. However, for example, scientific discovery doesn't >>> work this way. Claiming that all learning by observation is somehow >>> invalid is bogus. >>> >> So you figure that, to a potential user, the use of this product >> should be >> "scientific discovery?" > > No, it was an example, as I clearly stated above. > >> People are supposed to know what a piece of >> software is supposed to do BEFORE they write it. > > A goal, sure. > >> One shouln't have to guess after it's published. > > We know what SDCC does. It's a C compiler. It compiles C code. > Goal achieved. Go write some code. > >> Poking around in the dark is done when you have a >> piece of undocumented software that you've "acquired" though you >> don't know >> how to use it. > > I know how to use SDCC. You would too, if you...go write some code. > >> This sort of question will arise again and again, though you >> won't notice it unless someone determined to get it "fixed" >> complains. Most potential users will simply go away. > > No, most users will file bug reports...you know, something > useful...after writing some code. > One can only file a bug report if one finds what's known to be a bug. If you don't know what the code is intended to do, you can't possibly know whether what you've observed is outside that scope. Now, as I've said before, SDCC is pretty mature, and the original authors are not readily available to declare what they originally intended. There aren't any initially documented objective spec's because the original authors wanted to have a compiler to use, and initially didn't care whether it was ever of use to anyone else. They/he wanted a tool. Only after seeing that it worked well did the author decide it might actually be worth massaging into publishable form. It's obviously been a success. That's why I'm willing to expend effort on it. I'm willing to do that despite the fact I'll probably never use it commercially, as I don't believe in using HLL's for small code. However, it does beg for a documentation cleanup/update. > >> The reason software seldom does what it is supposed to do, as >> you've said >> above, is that the spec's aren't written until after the deed is >> done. As I >> mentioned before, the reason M$ doesn't publish doc's for their >> products >> together with those products is that they're afraid someone will >> figure out >> that it doesn't do what it was intended to do. That's because of poor >> management and, of course, poor programming practice, such as >> documenting >> the work after, instead of before, it is done. > > Software development is an artistic and evolutionary process, not > a step-by-step "pull this lever, push that button" process. The > sooner you learn that, the sooner you'll be able to...write some code. > I've been writing code since the early '60's and certainly have to disagree. While generation of software is a creative process, its proper execution is subject to rigorous engineering procedures. It's not the artsy-fartsy process that many dilletante's imagine it to be. That's why, unlike U.S. software houses, the Japanese houses, for example, have, for decades, been bringing huge software efforts in ahead of schedule and under budget, while U.S. producers are typically 200-300% over both budget and schedule. > >> Now, consider this -- I have a piece of what appears to be fully >> satisfactory code -- written in ASM -- at least as far as I'm able to >> determine from simulation. I want to assemble it in the SDCC suite's >> assembler in order to generate the files that are palatable to >> SiLabs' IDE, >> so I can program their part and run their in-circuit debugger. This >> requires the availability of an OMF file, which SDCC's tools are >> said to >> produce. Where is that procedure described in the doc's? How >> would I go >> about it? Would you recommend I simply start guessing? > > Let me put it this way: If I wanted to do that today, I'd get it > done. I'm NO smarter and NO better than you, and I'd get it done. > In order to walk on water, you have to know where the rocks are. The doc tells you that. Otherwise, you just have to swim for it. That's neither sensible nor efficient. Remember, too, that my "complaint" was that the doc is insufficient, and that I'd help write/update the stuff if I could find the necessary information on which to base that. If I have to do it experimentally, the end-product will likely be invalid and unreliable. All I can do is pull together and organize what's accepted to be valid and true information. Telling me to "swim for it" isn't going to lead in that direction. > > -Dave > > -- > Dave McGuire > Port Charlotte, FL > > ------------------------------------------------------------------------- ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
