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...