Saturday, October 29, 2005
CL-DUIM Progress
According to the library.dylan file in the 'core' directory, the following packages need to be defined (forming, I assume, the core of the DUIM functionality):
duim-utilities
duim-geometry
duim-DCs
duim-sheets
duim-graphics
duim-extended-geometry
duim-layouts
duim-gadgets
duim-frames
duim-recording
I've now transliterated all these bar one (duim-recording) into Lisp - of a form. I need to revisit what I've done and standardise on some of the approaches I've taken (for example, should the built in Lisp list and array types be used, or should new Dylan-like objects be built?) because currently some things are rather haphazard (another example - I started converting Dylan's abstract classes into Lisp standard classes (using defclass) and later decided to provide a 'define-abstract-class' macro) so half the code is one way and the other half the other way.
The notable thing missing currently is any back-end code; once what I have has been kicked into shape a little more I'm going to crack on and get something working with Cocoa (hopefully). Then I need to go back and add in the other things I'm missing; recording, presentations, graph, menu and table formatting, support for images, and the 'panes' support (the latter possibly needing to be expedited, I'm not sure yet).
I also need to revisit my automated tests which are already suffering some bit-rot.
Still a long way to go, I'm going to be busy!
My current plan of work consists of:
1) Tidy what's already converted
2) Convert vanilla-backend, and write a concrete (Cocoa) back end
3) Convert the 'extras'
4) Automated tests
5) Port DEUCE to CL (on top of DUIM, obviously)
6) Document, document, document (probably need to write some kind of document authoring tool, or just use something already available. It would be nice to be able to integrate the documentation into some kind of DUIM-based workspace though)
duim-utilities
duim-geometry
duim-DCs
duim-sheets
duim-graphics
duim-extended-geometry
duim-layouts
duim-gadgets
duim-frames
duim-recording
I've now transliterated all these bar one (duim-recording) into Lisp - of a form. I need to revisit what I've done and standardise on some of the approaches I've taken (for example, should the built in Lisp list and array types be used, or should new Dylan-like
The notable thing missing currently is any back-end code; once what I have has been kicked into shape a little more I'm going to crack on and get something working with Cocoa (hopefully). Then I need to go back and add in the other things I'm missing; recording, presentations, graph, menu and table formatting, support for images, and the 'panes' support (the latter possibly needing to be expedited, I'm not sure yet).
I also need to revisit my automated tests which are already suffering some bit-rot.
Still a long way to go, I'm going to be busy!
My current plan of work consists of:
1) Tidy what's already converted
2) Convert vanilla-backend, and write a concrete (Cocoa) back end
3) Convert the 'extras'
4) Automated tests
5) Port DEUCE to CL (on top of DUIM, obviously)
6) Document, document, document (probably need to write some kind of document authoring tool, or just use something already available. It would be nice to be able to integrate the documentation into some kind of DUIM-based workspace though)
Sunday, October 23, 2005
SAD
I've just finished the structured analysis and design course my employer sent me on. It was based on UML 2.0 of course and actually wasn't too bad. The instructor (John Conolly) seemed to actually be competent, which was a nice surprise.
My only worry is that this kind of activity won't actually resolve any of the issues we tend to have to deal with when developing software in the commercial world, namely that 'the business' never knows what it actually wants (and even more rarely what it needs) and the developers are never given enough time to write even half-decent code (in our case in Java). Whilst structured analysis / design should help I just can't see us getting the time to do the job properly unfortunately.
UML doesn't look like it will fit in too well with Lisp, but I was expecting that. I suspect with a few tweaks (support for multimethods being the most obvious) UML could be used to represent a Lisp system. Unfortunately dabbling in structured design will pretty much destroy one of the biggest strengths of Lisp; namely the dynamic nature of development and the ability to change running code on the fly.
I think it shouldn't be too hard to dump the structure of a Lisp program into UML though (well - once the limitations of UML wrt Lisp are addressed) so in terms of 'model driven architecture' Lisp and UML should be a pretty good match.
The 3-week course has halted the work I was doing porting DUIM into Lisp. I'll get back to that over the next couple of days. Most of the Dylan code has been converted now, but I need to finish off the macros (Dylan's macro syntax feels very kludgy compared to Lisp's) but that shouldn't take too long. There are a few compatability methods I want to revisit and I'm going to wrap Lisp sequences to make them look more like their Dylan counterparts.
I've also got quite a big job to do documenting the thing (Fundev's documentation is good but I want more detail; think CLIM 2 spec rather than DUIM API reference) and writing some automated tests.
My only worry is that this kind of activity won't actually resolve any of the issues we tend to have to deal with when developing software in the commercial world, namely that 'the business' never knows what it actually wants (and even more rarely what it needs) and the developers are never given enough time to write even half-decent code (in our case in Java). Whilst structured analysis / design should help I just can't see us getting the time to do the job properly unfortunately.
UML doesn't look like it will fit in too well with Lisp, but I was expecting that. I suspect with a few tweaks (support for multimethods being the most obvious) UML could be used to represent a Lisp system. Unfortunately dabbling in structured design will pretty much destroy one of the biggest strengths of Lisp; namely the dynamic nature of development and the ability to change running code on the fly.
I think it shouldn't be too hard to dump the structure of a Lisp program into UML though (well - once the limitations of UML wrt Lisp are addressed) so in terms of 'model driven architecture' Lisp and UML should be a pretty good match.
The 3-week course has halted the work I was doing porting DUIM into Lisp. I'll get back to that over the next couple of days. Most of the Dylan code has been converted now, but I need to finish off the macros (Dylan's macro syntax feels very kludgy compared to Lisp's) but that shouldn't take too long. There are a few compatability methods I want to revisit and I'm going to wrap Lisp sequences to make them look more like their Dylan counterparts.
I've also got quite a big job to do documenting the thing (Fundev's documentation is good but I want more detail; think CLIM 2 spec rather than DUIM API reference) and writing some automated tests.
