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.
> 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.
> 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.
-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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
