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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
