On 14/12/10 23:22, Les Mikesell wrote: > On 12/14/2010 4:01 PM, m.roth at 5-cent.us wrote: >> Les Mikesell wrote: >>> On 12/14/2010 3:38 PM, m.roth at 5-cent.us wrote: >>>> >>>>> If you don't like java's verbosity, you might like groovy. You can, >>>>> for >>>> >>>> OO in general, and java in particular, IMO, is trying to enforce good >>>> coding standards by compiler... except, of course, that it doesn't work. >>>> >>>>> example, print items from a database in about 3 lines. >>>> >>>> Really? I can do that in one: >>>> sqlplus (or mysql, or whatever) >>>> select * from mytable; >>>> >>>> Or from C, using, say, Pro*C: >>>> Exec SQL >>>> select .... >>>> End-Exec >>>> >>>> mark, being difficult >>> >>> I think besides being difficult you are missing the point - you can't do >>> anything else with those values from a sql server's own monitor tool - >>> and the way you do even that will vary with the sql server flavor. With >>> groovy you can use any jdbc interface the same way and hand off the >>> values to any other java jars or code you have around - maybe use >>> jfreereport to graph them with a few more lines, etc. I suppose you >>> could do that in C if you wanted to spend the rest of your life writing >>> it. >> >> Sure I can, but then, I know a good bit of sql as a language (bleah!). Why >> "the rest of my life"? Through the nineties, a *lot* of folks wrote a >> *lot* of C with embedded SQL as it's called. > > 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() . 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/> >> 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. 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. 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. kind regards, David Sommerseth