Re: My Perl is starting to look like Lisp

David Steuber <david@xxxxxxxxxxxxxxxxx> writes:

> Tim X <timx@xxxxxxxxxxxxxxxxx> writes:
>
> > Lisp I would place in the 'pro' column - its very simple syntax means
> > that to a large extent, you are forced to work with the same style -
> > while you will see minor differences in style, you can easily reformat
> > the sources without running the risk of breaking things and everything
> > looks familir. In perl, its not so simple - some users exploit hidden
> > variables extensively, others prefer a mroe explicit style, some write
> > perl which looks like C and others write perl which looks like line
> > noise, some use prototypes, others don't, some use strict mode others
> > don't, some prefer 'or', 'and' and 'not' while others prefer ||, &&
> > and ! (worse yet, they have different precedence) etc.
>
> I don't quite agree with this. Certainly the complex syntax of Perl
> allows more obvious cosmetic style differences. But programming style
> goes deeper than that. The simple looking structure of Lisp belies
> the fact that there can be as many programming styles as there are
> programmers. Paul Graham writes his code one way in ACL and On Lisp.
> Peter Norvig writes code a different way in PAIP. Then you have
> Keene's examples in OOP in CL. You can freely mix programming
> methodologies in Lisp without giving it a second thought.
>
> Maybe an inexperienced Lisp programmer sees nothing but a tree of
> parenthesis. But that is not where the style resides in a Lisp
> program. Lisp really offers as much freedom of style as prose.
>

I think we are at cross purposes here. I agree you can employ many
different programming paradigms using lisp (and perl). However, due to
perl's flexibility/variety of supported syntax, it can be very
difficult to follow code you didn't write. With lisp, while you may
use various paradigms, the simple syntax makes it very quick and easy
to get the basics of what the code does. Admittedly, you may have to
go a grab Keene to read up on lisp objects, or take time to study the
macros the author has used to make his code more domain specific etc.,
but on the whole, you can pick up some lisp code and get a very good
sense for what is going on.

With Perl, I've experienced too many times a situation where it is
very difficult to even understand in high level broad terms what is
going on - in fact, Perl is the worst language for this I've come
across. You often spend so much time trying to follow exactly what is
going on at the code level, you miss the underlying algorithm. Its
very easy to make mistakes because the 'behavior' of the language can
be different depending on how it is used. For example, the difference
in precedence between || and 'or', or the subtle differences between
&subroutine($x) and subroutine($x) or even subroutine $x. You also
need a lot more experience with Perl before you get the same level of
understanding of a piece of code as you do with lisp - this is not to
say lisp doesn't have some important and sometimes difficult to fully
grasp aspects, rather that Perl has far more aspects which don't seem
to have (to me) the same level of logical connections and you often
only realise or find out about some subtle technique after it is
pointed out by someone else.

I've used a lot of perl and in fact, its what finally led me to
lisp. I've worked on a couple of fairly large perl projects which ran
over multiple years and involved many different developers. After that
experience, I'm now very reluctant to embark on a new project which is
to be based on perl and would only consider it if some very clearly
formulated rules are put into place regarding coding style. However,
even with strict procedurres, I've found perl really doesn't scale
well. As a sys admin support tool, I think its great and use it for
such purposes on almost a daily basis. For something quick and dirty
its excellent. However, for something large which will have a long
life requiring maintenance and expansion of functionality and which
will be worked on by a team of people, I wouldn't recommend perl.

Therefore, when I started considering the next project I wanted to
work on, I began to look for something else. I originally looked at
python as people had told me it was good and much better for larger
projects etc. After a fairly short evaluation, I found myself thinking
about Lisp and decided to take another look - I hadn't really ever
done any Lisp - really only just enough to get by when I was working
for a distributed AI research lab. The more I looked at it, the more I
liked it. I started doing a few small programs to solve some of those
annoying little problems we all deal with, but which seldom become
irritating enough for us to bother actually writing code to
solve. Then I read Peter's Practicle Common Lisp book, which finally
convinced me to try using Lisp for my project. So far, things are
looking good. Progress is very slow, mainly because I tend to spend
too much time reassuring myself I undestand things enough to start
designing/coding (always a problem for me with a new language) and
partially because I've got to do this in my spare time, which lately,
I don't seem to have much of. Still, the experience is the main driver
and I have to say, the shift from developing in perl, java, c and c++
to lisp is substantial and requires as much unlearning as learning,
but is the first time I've been excited about coding again in many
many years.

Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
.

Relevant Pages

  • Re: Computer Algebra Algorithms
    ... If you want to learn CAS, learn lisp because that is what the ... The parser could be written in C or any other language. ... I would consider that such a minor aspect of a programming ... generally prefer righting there numeric algorithms in Maple and MATLAB ...
    (sci.math.symbolic)
  • Why should I care about Lisp and Scheme?
    ... Foreword to the book "Essentials of Programming Languages". ... It's an imaginary conversation between a newbie and a hacker. ... Why should I care about Lisp and Scheme? ... language, the result would be a Lisp interpreter. ...
    (comp.lang.scheme)
  • Re: F#
    ... Why did they take Lisp? ... properties of the language are only a part of the picture. ... If the favored programming style of a certain language ... Knowing a success story only tells me that other people ...
    (comp.lang.functional)
  • [ANN] 2nd European Lisp & Scheme Workshop
    ... Pascal Costanza, Programming Technology Lab, Vrije Universiteit Brussel ... Lisp has a tradition of providing a fruitful basis for language design ... and suggestions for breakout groups that discuss the opportunities Lisp ...
    (comp.lang.lisp)
  • Re: Opinions on intro lisp books
    ... But Lisp is a little different, ... Some languages support one style of programming better than they ... Even if that weren't the case, I'm not sure that a language being a ... I don't believe that learning to program in CL requires more theory ...
    (comp.lang.lisp)