On Fri, 23 May 2008 08:20:42 +0200 (CEST), Andreas Tille wrote: > On Thu, 22 May 2008, David Paleino wrote: > > >> It is not any more complex than it needs to be. > > > > Oh well, it is "complex" to me. I'm not a *real* Python coder, I can just > > put together some lines... > > Over the years I observed the problem that there are so many half done medical > projects which never reach any usable state because they are more or less one > man shows written in a programming language that this one man just knows by > chance. Cooperation does not happen because the protagonists just speak > different programming languages. So we are beaten by the fact that there are > so many shiny programming languages available that cooperation on niche > products (yes, I regard Free Medical Software as a niche product considering > the number of users we actually have) is effectively blocked. Fully ACK. > So I would not claim that Python is the best language to pick (probably there > is no such thing like the best language) for the purpose you have in mind but > there is no reason against Python at least. The big advantage that there is > a project which looks somehow promissing and which existed and evolved over > several years which is a good quality measure considering other projects that > had a much shorter live cycle. Keeping this in mind I would regard this as > a good reason to learn Python (which is not that hard) and try to adopt as > much as possible from GNUmed. I'm in fact learning Python (remember the scripts we use for our website? ;)) > > That's rather easy in a language you know (-- I don't really know Python, I > > go by trial-and-error ;) ) > > That's a start, isn't it? ;-) > > >> In fact, GNUmed is a lot less complex semantically than what it needs to > >> become - it doesn't cover any billing or prescribing so far. > > > > True, and I'd need that as well. > > If GNUmed manages to attract more developers (I hope you will not be the only > one) chances are good that billing and prescribing might be added sooner or > later and I see no reason why a project written from scratch should implement > these features faster than a project that has reached a certain state. OpenDental is not "written from scratch" ;) It has a number of users on Windows, and also works on Linux, AFAICT. > >>> Dentists need a more specific software (i.e. usually they also have a > >>> printout of teeth to click on and select treatment). > >> > >> That would be fairly easy to add. > > > > Again, for any *python coder* ;) > > I feel far more comfortable with C#, which OpenDental is written in. > > How did you gained your C# knowledge? Years of Windows programming :p > You will see that learning Python is much easier, because has a much less > overhead. You know, what I found difficult for all programming languages (be it Python, Perl, C# itself, ...) is binding with GTK. I could successfully write CLI apps, but when it comes to GTK... I lose myself there. > BTW, I would not like to persuade you to join GNUmed. I'd like to join GNUmed indeed, but I cannot assure any constant development :( > If you think that chances are good to profit from OpenDental code at large > scale this is fine as well. The only advise is to not to start just another > one-man-show project. You have to form a community around your project. Well... Medicine is a niche sector in software, and Dentistry is a niche sector in Medicine. I would be happy if that community would be of 20 people or so. > If you fail in doing so you have good chances to have spend your time in > something that will bit-rot after five or ten years (depending from your luck > or your effort you have to put into your real job where you gain some money > from). So just try to spend your time into a project that sounds promising > for the future. Well, I'd need that software for myself, at least! ;) Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Attachment:
signature.asc
Description: PGP signature