On Sep 25, 2010, at 11:08 AM, Tim Edwards wrote: > The bottom line? To make it more popular, widen the audience. It seems > to me that a very good way to widen the audience is to have another, > modernized version of the tool, with broader access to platforms such > as the Mac, or Windows, the iPad, or whatever. The source code is just > an implementation. It's the underlying concept that counts. Personally, > I'm pleased that somebody likes the underlying concept enough to take > the trouble to port it to a different graphics package, to clean up the > code; to actually care about it.
:) Nice to hear. Alas, those are merely the results of my original drive. And my original drive is to use xcircuit is a tool to design computation pipelines and state machines. But I'm too lazy of a fellow to make myself deal with the original-style C code more than once. Ergo the only solution is to port, otherwise I'll have to deal with the original design plenty of times. Everything else: availability on multiple platforms, more features, whatnot is merely a side effect. And I also want to have a decent substitute for baseline EDA packages out there (PCB123 and Eagle, at least). I want, for example, Xcircuit to be a more modern front-end to ltspice's spice library; I don't particularly like the feel of the original UI. But that's a side goal merely because it'll be reasonably easy. > Software evolves. Software that is too constrained to a specific set > of dependencies tends to die out. I started writing XCircuit in the > summer of 1993, as I started my Ph.D. work at Johns Hopkins. That makes > it 17 years old. That's very old, by software standards. The switch to > Tcl/Tk and away from Xt was an attempt to keep it from folding into the > obscurity of graphics packages that were increasingly outdated. Anyway, > I have spent 17 years of my life on this thing, and it's reached the > point where it does, more or less, everything that I need it to for my > own work. I've scratched my itch, as it were. The more it stays my > program, in my style of coding, the more vulnerable it is in the long > run. I'll admit, I'm a pretty curmudgeonly programmer. I'm of the > generation that learned to program on the Apple II and thinks that C > is just a bit too far removed from assembly code for my liking. I also > have the equally curmudgeonly attitude that anybody who hasn't read > Donald Knuth from cover to cover and taken it to be the word of god > isn't qualified to program, which makes me very hesitant to write > software that is dependent on other packages, because, heaven forbid, > they may have written an inefficient algorithm. Yeah, I think I need > to let go a bit. I do understand the bit about efficient algorithms. I'm doing day-to-day coding for Z8 Encore! and ZNEO platforms, and those are not stellar performers yet I use both to do quite a bit of DSP-style number crunching. While I can't claim having read all of TAOCP, I do know about it, have it on my bookshelf, and one volume is usually "on loan" in the bathroom, so it gets a regular reading ;) The nice thing about a framework is that if there are inefficiencies, you fix them once and a lot of software benefits. It's my hope that the end product of my work will be digestible enough for Tim to be able to contribute. At least I'm here to explain myself, even if the need for it usually would imply that I have to fix my code to be clearer. Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
