I'll have to look at OCaml and SML. I've done a lot of languages of various flavours; they're mostly languages, as far as I'm concerned - a means of expressing an algorithm.
I strongly concur with your avoiding optimisation. If it's a good algorithm, proper implementation is more important than good optimisation. If it's a bad algorithm, no amount of implementation or optimisation will improve it, so may as well start over. In any case, optimising a bad algorithm or bad implementation will only get you bad results faster. Not very productive. Keep us posted; this is a good project. Regards, Donald. ----- Original Message ----- From: "anthonix" <[email protected]> To: [email protected] Sent: Wednesday, December 16, 2009 11:14:42 PM GMT -05:00 US/Canada Eastern Subject: Re: [kicad-users] Re: topological autorouter integration with KiCAD Donald H Locker wrote: > Oooh! C! I do a bit of C. Since 1982 [shiver.] You have been writing C for longer than I have been around.. nice :) I'm not too fussed about using C. The main reason was because PCB is C. I've pondered switching to a functional language like OCaml.. Development would probably be slow initially, as I learn, but I expect dev time would soon become much faster than C. What do you guys think about a functional lang such as OCaml or SML? > What libraries does the toporouter rely on? Currently GLib and GTS. GTS will soon be removed. There is currently very little in the way of data structure optimization. I was trying to avoid premature optimization, and so almost everything uses a GLib linked list. These will later be optimized, and this could also be an opportunity to remove the GLib dep. <shameless gloating> Despite the fact that most data is in some fairly awful linked lists, it could route Harry Eaton's flare genesis board in ~2 seconds compared to freerouting.net's > 2 minutes.. the toporouter solution was also curvilinear as opposed to octilinear and used less wiring. </shameless gloating> > I know neither Specctra nor any of the export formats. So all may be beyond > me. I've only spent a couple of minutes researching specctra, so I probably know about as much as you. I'll hold off spending time on the specctra interface in the hope that someone else will :) Best Wishes, Anthony
