On Wed, 2010-12-15 at 14:07 +0100, 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() .
+1
And the list can go on and on and on and on ... As long as the database API don't "stupidify" the API so remove the need of writing SQL statements yourself, you need to really do a lot of careful research and testing among all database types you want to support - and only use features which works identical for all types. Or else you need to add a wrapper layer adopting queries depending on the backend database. SQLalchemy [1] does such "stupidifying" work. But it makes a lot of simple SQL commands more complicated if you know SQL very well. Hence my term "stupidifying". But it's probably the safest path. However, I don't know if SQLalchemy or similar modules are available to other languages than Python. [1] http://www.sqlalchemy.org/
+1 SQLalchemy is a *very* nice package. Any modern application *not* using an ORM should, IMNSHO, have a very good justification for not doing so [and that reason is usually bogus]. ORMs provide more than just database abstraction but session management, result-set caching, and protection from issues such as SQL injection.
There are ORMs for just about every language/platform: Hibernate (Java), NHibernate (.NET), LINQ (.NET), RDO (PHP), Rose (Perl).... Quality varies but just about anything is superior to embedding literal SQL into an application.
But I think the real point of this thread is that perl isn't bad, bad programmers (sorry, "developers") will write bad code in any language.
That may be someone's point. Mine is that a lot of good code has already been written and is easily available. Use it instead of writing your own bad code. And this is especially true for perl and java with a little bit of overlap in the places you might use them. Groovy sort of increases that overlap.
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.
+1. I'd almost always advocate solution#2. "Simple" routines rarely stay that way and XML is literred with gotchas [escaped characters, encoding, namespaces] that I have seen detonate two many times. libxml2 will, potentially, raise errors, and more descriptive errors, earlier in the process of doing something stupid.
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.
The old saying about stability and quality: getting to 90% is easy, that last 10% is really hard.