On Jan 18, 2009, at 1:53 PM, Dick Hollenbeck wrote:
It is especially curious why thisshould exist at all when as of two weeks ago there was an SVF conversiontool in this project.It .... does not require a separate step to use.You are correct if it works as advertised.(If it does not work, then someone will have to maintain/fix it, and that is when my concerns would come into play.)Now if I may change the subject a little, back to the language issue:I was also under the impression that C was being used in this project because the project wanted to minimize runtime footprint, and that duplication of features was not desirable because of runtime footprint costs. Now because this is a duplication of an existing feature, one could now assume that runtime footprint is no longer a high priority for this project. (I am not saying that runtime footprint should be a priority.)
I don't believe that was the case at all. Many of the developers on this project are more comfortable with C and the original program was written in C. Rather than spend months rewriting it in a new language for dubious reward, we can add to and maintain the existing code base.
There are _some_ users that incorporate OpenOCD as part of an embedded system (see ZY1000) and have limited system resources. Keeping the overall footprint down is a good things for them, but certainly _not_ the main driving force. They are welcome to simply remove any functionality they do not wish to have. Also, the duplication provided here is extremely small. The entire SVF support is under 3000 lines (I don't have the exact number handy) and should compile down to under 1K of code and data.
I would completely support a patch that provided SVF support by having an in-program converter to XSVF. The python-based converter serves a purpose, but it is not a complete answer.
With that assumption in mind, I again feel it bolsters my belief that C is NOT the correct language for any part of this project except for the cable drivers, and even they could be done in C++. I am fluent in C, C++, Java and Python and have seen wide variation in maintainability and ease of adding new features that want to jiggle the status quo of thought on this issue a little here.
You are entitled to your belief, but unless the majority of the developers agree that the project should be rewritten in another language, it will _not_ happen. I have 10+ years of experience in 23 programming languages. The design of the program is much more vital to ease of maintainability and extension than the language. I've seen examples of both good and poor design in all of those languages (C, C+ +, Java, and Python included).
A man holding a shovel once told a bull dozer salesman to go away, he could move dirt without the bull dozer.
And he might be right to do so if the job was a thousand miles from a gas station that has diesel.
Dick
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
