On 12/15/2010 7:07 AM, David Sommerseth wrote: > >> The sql side is easy enough - the point you are missing is that you have >> access to any number of jdbc connections/versions at once (say you want >> to copy among different database types) and also to anything else >> already available as a java jar or source. Writing the code to display >> a graph on most platforms is the part I thought would take you a >> substantial amount of time, where with groovy you can include swing and >> jfreereport and hand it some values. > > I planned to stay out of this discussion. But when I see claims that > jdbc connections and doing copy between/among different database types, > I must raise my voice. > > Most databases to indeed follow SQL standards. But there are several > SQL standards (SQL92, SQL98), and then you have different > interpretations of them. So a INSERT statement which works flawlessly > against a MySQL database might not work against PostgreSQL, SQLite or > Oracle - due to that the MySQL syntax might not follow a defined SQL > standard. > > Then you can have a SQL query working flawlessly against PostgreSQL, but > it uses features only available to PostgreSQL, like SEQUENCE. So > Oracle, SQLite or MySQL won't understand NEXTVAL() . I don't think I claimed that java/groovy/jdbc would make standard sql work with non-standard sql server types, but it can give you a connection to nearly every type of server with the ability to write your own queries and handle the results. Perl would have the equivalent with DBI/DBD. If you are just doing data copies/conversions, you might be able to do the whole thing with something like Pentaho's ETL tool that used to be kettle but is now PDI: http://kettle.pentaho.com/ > To reuse other libraries/modules/extensions is *almost* always a good > idea, no matter which language you use. At least if that > library/module/extension is used by many and have a good development > trend and few annoying bugs. But sometimes, such an approach makes life > much more difficult than it needs to be to solve a single task. > > F.ex ... What if I have a C program and need a /very simple/ XML output, > which is rather static. One simple solution is: > > printf("<?xml version=\"1.0\"?>\n" > "<mydata><sender>%s</sender><msg>%s</msg></mydata>\n", > sender, message); > > How many of you would use, say libxml2 to do the same job? > > xmlDoc *doc; > xmlNode *root; > > doc = xmlNewDoc((xmlChar *)"1.0"); > root = xmlNewNode(NULL, (xmlChar *)"mydata"); > xmlDocSetRootElement(doc, root); > > xmlNewTextChild(root, NULL, > (xmlChar *) "sender", (xmlChar *) sender); > xmlNewTextChild(root, NULL, > (xmlChar *) "msg", (xmlChar *) message); > xmlSaveFile("-", doc); > xmlFreeDoc(doc); > > (I avoided using scripting languages in this example on purpose, to > avoid another Python/Perl/PHP/my-favourite-language discussion) > > Both are valid solutions and produce exactly the same result. But using > the external library in this case is actually more error prone. If you > forget xmlFreeDoc(), this little application leaks memory. There are no > checks for NULL pointers, causing a segmentation fault. While the > single printf() line would just print "(null)" instead and not crash. > Sometimes the latter is preferred and acceptable, but a segfault is > almost never acceptable. > > But the printf() solution also have a few other nasty gotchas which > libxml2 will handle gracefully. Imagine if the message string contains > HTML data, or just a single ampersand. However, sometimes your program > will just dump out numbers, and then suddenly printf() is just as good > as the libxml2. > > So there are times when using external libraries/modules/extensions are > completely overkill. And there are times when doing it yourself is task > too big. Most good and skilled developers usually see where this border > line goes. The rest of the developers just hack something together and > provides something which usually works very fine and that you don't need > to read the code afterwards. I usually either start with the simplest possible way or the most complete abstraction I can find, depending on the need for performance and the time it takes to digest the API for the high level tool. There's a 50/50 chance that this first choice will be wrong, but anything in between has generally been worse. XML::Twig would probably be my perl-ish choice for anything involving xml, particularly parsing it. > Bottom line is: It doesn't matter which language you use or which > modules that language supports. What matters is: a) Is the language > suitable for the task, b) Can the developer use the language and needed > modules efficiently, c) Does the developer know how to solve the > complete task wisely ... the rest is just a matter of personal taste. Just tracking the available libraries and the bugs that are likely to affect your use of them is about a full time job though, so there probably aren't a lot of people that are equally capable of doing something quickly in more than a few languages. Consultants, of course, are always ready to say that they can as long as you are paying for the time it takes... -- Les Mikesell lesmikesell at gmail.com