Am Sonntag, den 13.04.2008, 23:31 +0100 schrieb Alan Gauld: > "Dinesh B Vadhia" <[EMAIL PROTECTED]> wrote > > > Your last paragraph is the gist of my note ie. it's the > > documentation, documentation, documentation. > > I agree it can be very variable in quality. > One of the problems of Open Source is that there are more > people who want to write code than there are who want to > write documentation... > > > In addition to Python, we use Numpy/Scipy/webpy at > > the server - all of them Python libraries written in Python > > and/or C - and have faced no end of problems with > > these libraries. > > All non standard items, all Open Source. > > > We also use HTML/CSS/JavaScript/JQuery at the browser > > All standard items for Browser work. Tools designed for the job. > Have you tried using non standard browser code libraries > like say the various graphing libraries for JavaScript? Or > sound libraries, say? They are just as patchy in support. > > > Of course, these tools are fully documented including > > the dead tree type! > > Exactly, but they are standard tools so need to be > compared to core Python not the contributed software. > Of course you could use Java on the server and then > you could buy commercial libraries that do the same > job as Numpy etc. But you have to pay hard $$$ for > those. So you take your choice: persevere with Python > and its libraries for its rapid development and hope the > time savings outweigh the time spent working out how > the libraries work or, pay out for the commercial products > and hope the savings in quality(*) outweigh the > expenditure. And also hope that the different tools work > together because if they don't you can't go look at > the source to fix it! Its all about making choices, but > that's engineering - you choose the right trade off!
And don't forget that even with the best documented Java/C++ library you will be coding way slower. OTOH, Python has relative strong introspective powers, it's seldom that I'm incapable of figuring how to use a library from trying it out interactivly. OTOH, reading the docs and/or source code later often points out that I did things potentially not in the best or recommended way. ;) > > (*)And of course that's a gamble too because there are > many badly documented commercial libraries too! > But at least you can complain to somebody! :-/ <rantmode> Yeah, although this most often means being ignored by somebody that has some of my money/my budget/my customer's money. While it is often frustrating to have no or little response to problems with open source stuff, at least one has the option to try to fix it yourself. Admittingly that does not work for typical commercial operations aka Java sweatshops in practice, as they tend to hire not good enough developers to make that a workable proposition. I've seen contractors that did not do anything in 3 months (well, they did some simple string replaces on constants in the code) being hired as employees, probably because they were the only ones not killing the hiring talk immediatly ;) </rantmode> > > Alan G > > _______________________________________________ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
