Clay Baenziger wrote: > Hi Dave, > Thank you for pointing out where I might still have assumptions I've > not yet recognized. My comments are in-line. > > On Thu, 14 May 2009, Dave Miner wrote: > >> Clay Baenziger wrote: >>> Hi Dave, >>> My apologies, I think I did a poor job of communicating some >>> assumptions in my e-mails. However, I think using AI will help the >>> intern team; some of the benefits I see are: >>> >>> *To interface with the AI engine an XML manifest only needs be provided. >>> XML can easily be verified and is a well defined format which can be >>> verified by the team as they develop, allowing for an easy incremental >>> development process. >>> >>> *Building a UI is one component required for a text installer. If >>> the Slim Engine is used, then a UI and an ability to interface with >>> the C >>> based Slim Install framework will be needed. This is two components and >>> thus more complexity and code the team would need to develop to >>> reach the >>> same end goal. >>> >> >> I'm not sure I buy your comparison. I look at it as: >> >> - the existing GUI interfaces to the slim engine using C, so examples >> of doing that are available > > I agree that there are examples, but I see the maintainability of C code > to be inferior to that written in Python as any new functionality will > need to be coded up from scratch and error handling in C must be done at > a far lower level than using the OO try/except methods in Python, for > example. >
I think you're ascribing a level of magic here to exception handling which I'm not sure Python qualifies for. I get it more in the Java case, because compile-time binding against declared exceptions of your consumed interfaces is checked, but it looks to me like Python's a lot less rigorous there, and hence you can write some pretty hideously broken code nonetheless. In our case, I'd say our Python looks more like masqueraded C code ;-) > Further, Python has what appears to be a mature curses library > interface[1] which should allow them to take full advantage of Python > error handling and rapid object-oriented coding practices without much > effort. > > 1: http://www.amk.ca/python/howto/curses/ > Perhaps, I think that's the team's judgment to make. >> - there is no existing code written to emit AI manifests. That'll >> have to be developed from scratch. > > Though there is no code to emit AI manifests, there are example AI > manifests which could be modified and there are XML engines in our > source base which can easily be used to output XML. > > For example, LXML[1] has an Element Tree API which is geared explicitly > to creating an XML document. (It's how the AI webserver generates > XHTML.) Further, the output for the team then can be validated against > the AI schema which is a very easy target to test against. > > 1: http://codespeak.net/lxml/api.html > >> I suspect you have an unstated assumption about how the team might >> implement a text UI which perhaps is coloring your evaluation? > > I think I mainly see the team as being well versed in C++ and Java but > not C, so feel Python to be a more natural fit for us to learn from > their OO skills and experience, rather than fitting them into a C world > and us into more C code which could be written in a higher level language. > > Admittedly I hold a strong insecurity about using C versus a more modern > language which I suspect is a strong bias away from C solutions. > Might want to work on your insecurities there, we're going to have a lot of C to deal with no matter what happens with this piece ;-) I'm puzzled that someone could be conversant in C++ and Java yet find C challenging, but that's a digression, to be sure. I have nothing against higher-level languages, and indeed advocate for them for the most part, primarily because they typically have higher programmer productivity. I'd suggested doing the GUI in pygtk originally, but once we decided to build it in the context of Dwarf and hence had to interface to the old world, that became moot. Next rewrite. I frankly don't care much which way this is decided, as I anticipate there'll be lots of subsequent work required to finish it up for release, just want to make sure that the factors I do value are considered. Dave
