[CentOS] OT: programming language for morons (newbie friendly language in Open Source world)

Wed Dec 15 19:40:24 UTC 2010
Les Mikesell <lesmikesell at gmail.com>

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 at gmail.com