Øyvind Harboe wrote: > I insist on a good regression testing story before I'd get behind > changing language across the board. Dumping a buggy implementation > on the community and let it sort it out is not the way I want to go.
Like with the libusb code. I'm surprised that you think that this is what I advocate. Seriously. > I think realistically it would be possible to add Lua as an option, > but leave the Jim Tcl in. This makes no sense at all to me. There's just one set of cfg files. Duplicating them means twice the maintainenance burden. Weird. If there will be change it should be like ripping off a band aid; quick pain and then get on with it. > I don't believe that there is much, if any, programming at all that > 95% of use cases involves and therefore there would not be much > advantage to a better language(I'm not saying Lua is). It's not about use, it's about development. "I don't know Tcl" comes up again and again. Me, I *did* know Tcl rather well, but haven't used it for more than 15 years and I am utterly disinterested in starting to use it again. Not so with Lua. Which translates to more hours contributed. (Not just by me, I expect.) > One advantage of Tcl is that in the *simplest* cases the proc > invocations looks just like commands. I find that good and bad. I do believe this is actually the case also for Lua, but even if not I don't think it's bad that it is immediately obvious that something is using a specific language. //Peter ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
