Reply to thread

Message: [QUOTE="Tim X, post: 4872047"] I thought that was part of his point. i.e. the differences are largely just differences of syntactic sugar and that criticising one for being 'horrible' when you don't understand its type of refined sugar while ignoring aspects of the sugar you are familiar with that could be just as easily abused or confusing to the uninitiated was illlogical and meaningless. Flamewar? I thought it was a reasonably thought out and argued response. Unlike RG's original comments on perl, the gist I got from the post was in fact anti-flamewar i.e. that the differences were really about differences in familiarity and that claiming one is better than the other is pretty pointless. If anything, it was the more rational and balanced assessment compared to RG's original comment. For the record, I find a lot about perl I don't like, especially with respect to its syntax and somewhat inconsistent behavior in certain areas. I much prefer CLs simpler and far more consistent approach. I disagree with Perl's philosophy of allowing everyone to do it 'their way' and anyone who has worked with perl on either a project with many develoers or maintaining code written by many different authors will know what I'm getting at. However, I've also frequently come across problems that are much easier to solve with perl than they are with CL. In fact, I ran into one just recently. I had to do some work with a system that makes extensive use of Oracle and Oracle stored procedures. I wanted to use CL for the task. However, after many many hours of searching and trying out various CL interfaces to Oracle, I had to give up because I could not find one single CL to Oracle library that would allow you to work with stored procedures and ref cursors. Plenty, like clsql and Clisps Oracle DB extension would allow you to do basic SQL queries, but none would allow you to call a stored procedure and have access to all Oracle parameter type (IN, OUT and IN OUT) or ref cursors (at least I couldn't work it out from the docs or source code or experimentation). After many many days of installing various libs, which in itself was often painful, going through lots of docs, many of which were outdated, incomplete or poorly written and even having compiled clisp extensions etc, I had to give up. I turned to perl. In less than half a day, I had things working via Perl's DBI interface using the DBD::Oracle driver. Installation was rediculously simple - essentially starting the perl CPAN shell and asking it to install DBI and DBD::Oracle and it came with extensive and well written comprehensive documentation. In half a day I had all the tools working ans was able to concentrate on the problem I wanted to work on rather than tyring to just get an environment that would let me even start. I'd prefer to be working with CL, but taht wasn't possible. Arguements regarding which language is better or more powerful at a theoretical level become pointless if you cannot use it to solve a real world problem. This type of issue gets raised in this group frequently and the general response is to attack the poster and become extremely defensive, making all sorts of wild claims about CLs power and the ease at which you can implement a library etc. However, the reality is that for many problems, CL is not a good choice because it lacks the user base of other languages such as perl and therefore lacks the extensive repository of working useful libs that give the productive edge you need to survive in the commercial world. If, on the other hand, I want to experiment with some ideas or write some software for pleasure or do something where I have the luxury of time etc, I will likely use CL because it is one of the languages I really enjoy programming in and which frustrates me less. It is frequently the language I'll turn to if I want to try out something unusual or a bit left of field where I don't want the preconceptions of Larry, Gido or Matz getting in my way. However, if I want to get paid for solving a problem and want to get a reasonable hourly rate, I'm afraid CL will seldom be my first choice because I cannot rely on basic library functionality being available and I don't ahve time to write everyhting from scratch. We probably need tobe a little less sensitive regarding criticisms of CL. Sometimes, they are valid and we should listen and learn. Tim P.S. If anyone knows of a CL library that will allow me to interact with an Oracle database AND allow me to call stored procedures, passing data in both directions and access ref cursors, *PLEASE* let me know - I would still prefer to use CL for these jobs over perl. [/QUOTE]

Verification