Re: Why I never got into Lisp

Zach Beane <xach@xxxxxxxx> writes:

Chris Barts <puonegf+hfrarg@xxxxxxxxx> writes:

I bet an ultra-competent macro head could have shrunk code considerably
over the course of the whole program. But in small blocks, Lisp tends to
look flabby compared to Huffman-coded languages like Perl.

I think this has a detrimental effect in how you think about solutions
in languages like Perl. Since certain solution styles have optimized
syntax baked right into the language, going outside those styles
suddenly feels like a lot of hassle and not worth the trouble. I think
that's why a lot of solutions converge tweaking strings with regular
expressions and sticking them into hash tables.

If you can accept Lisp's notion that most constructs (including method
calls, control structures, array references, etc) look somewhat like a
function call, it doesn't feel like you're really going outside the
preferred realm of solutions by simply adding more features that look
somewhat like function calls. Code that uses a specialized forms of
table storage or arrays doesn't look unnatural simply for not being
able to take advantage of a compressed syntax using {} or [].


I think I agree....

I recently had to write some fairly simple scripts to analyse some
data files. At work, they have a very poor grasp of programming and
language issues - its one of those places where they waste far too
much time writing poorly thought out specs and demand you use their
"supported" language, which unfortunatley is Oracle's PL/SQL - yep,
thats right, we are supposed to use this for everything, even tasks
with no database requirements.

Obviously, I have ignored that requirement because its stupid and
mainly because nobody will ever see the code - its only the
output/reports they are interested in. As there has been some perl
used in the past, I figured that would be the most acceptable solution
should it become known what I was doing. I consider myself a fairly OK
perl programmer having used it on and off for about 10 years.

I wrote the script and started refining it as I got a clearer
understanding of the large data sets being processed (I had no
documentation, no real description of the data and have had to
discover it). As the script developed, I began to feel more and more
uncomfortable about it as it felt very clunky and I wasn't confident
my results were what I thought they were and the number of probable
bugs concerned me. It struck me at the time that some of my problem
was due to difficulty in mapping my conceptual ideas/solutions into
perl. I decided to try some other languages and see how this real
world task might change.

I decided to try a solution in CL. I'm not yet as confident regarding
the language as I am with Perl and spend considerably more time
searching the hyperspec for appropriate functions or refreshing my
memory regarding arguements and return values etc. Despite this, the
whole process was almost instantly more rewarding and progress was
much faster. The resulting code was also much easier to understand and
I had increased confidence that the reports were actually reporting
what I intended etc. The whole repl interaction was also much more
rewarding for this type of explorational programming.

This got me thinking about other languages. I've recently being
looking at Ruby, which I have to say seems on the surface to be the
nicest OO language I've used since smaltalk at Uni. Using it makes me
shudder when I remember the years in the wilderness programming Java.
I found the solution I developed in Ruby also mapped more readily wrt
how I thought of the problem conceptually.

In the end, I found that for this particular problem, the easiest
language to use was CL, then Ruby and finally Perl (keeping in mind
that Perl is actually the language I have the most experience with).
The CL and Perl appear to have similar execution times, but given my
inexperience with CL, I suspect the CL solution could be faster if
optimised. I found both the CL and Ruby solutions used considerably
more memory and the Ruby solution was considerably slower than the
perl one. Again, this could be due to my lack of Ruby experience as
this is my first Ruby script.

However, the most interesting observation for me was that both CL and
Ruby made the task simpler mainly because the way I was thinking about
the problem maps to those languages with a lot less effort than
with Perl.

Tim
--
tcross (at) rapttech dot com dot au
.

Relevant Pages

  • Re: Native language versions
    ... : For a general purpose programming language: Probably not. ... Even though this is not Perl, but TeX, I know ... instead of the English commands (TeX ...
    (comp.lang.perl.misc)
  • Re: Ruby vs. PHP
    ... done is checked out which versions of Perl, Python, YARV, Ruby, jRuby ... dynamic language to the seconds for the benchmark with gcc. ... YARV, Python, Perl and PHP have fairly close medians and the boxes are ...
    (comp.lang.ruby)
  • Re: For performance, write it in C - Part 2, comparing C, Ruby and Java
    ... knowing Perl is helping in my learning of Ruby. ... let's just say I think Ruby is a vast improvement on Perl. ... Frankly, I think one of the biggest reasons Java and, to a slightly ... Language" sense of entitlement -- not universally, ...
    (comp.lang.ruby)
  • Re: Implementing an English-Like Language - a Friendly Reply (Was:I just thought Id ask..)
    ... > interested in working with me on programming a programming ... > language in perl? ... all of the keywords would be english words ... If the language will be something screen reader ...
    (comp.lang.perl.misc)
  • Re: Probably an FAQ, but...
    ... You referred to 'dedicated' Ruby coders, ... Another person on this list that's been programming a "longish" ... time and is in the intersection of language lawyers (aka people who ... innovations have *led* the formal specifications, ...
    (comp.lang.ruby)