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

Adam Tauno Williams awilliam at whitemice.org
Wed Dec 15 13:29:20 UTC 2010


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.





More information about the CentOS mailing list