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.