On 14/12/10 23:22, Les Mikesell wrote:
> On 12/14/2010 4:01 PM, m.roth@xxxxxxxxx wrote:
>> Les Mikesell wrote:
>>> On 12/14/2010 3:38 PM, m.roth@xxxxxxxxx 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
