Re: Learning Lisp the hard way

On Jan 28, 3:36 pm, Kenneth Tilton <kentil...@xxxxxxxxx> wrote:
JavaLisper wrote:
Hi,
i have several years of Java experience, but now my new job requires
me to learn Lisp.
I find it terribly frustrating at times, and need to rant to just let
some steam off. But maybe other have some helpful tips for me to get
into it easier.
Note I do not want to advocate Java over lisp, it's just the only
other language I know well enough to compare. So no need to get all
defensive and point out how much better I will still be off when I
prefer Lisp over Java, this is not a Lisp vs. Java post, I do not love
Java nor do I care how much you hate it.

Actually, you better get used to it because this is your only
consolation (the fact that you are lucky enough to be paid to use Lisp
because it is so much more powerful (read "fun") than Java) because
everything you whine about below is pretty accurate. Unless you can use
Windows to program AllegroCL (or also some *nixes, I forget which, where
they have ported their IDE) because they do have a nice IDE closer to
(but still far from) what you are used to in Java.

But mostly you are right, you are doomed, Lisp development is not like
Java development so you learn new tricks, such as using the MOP to
explore OO models with custom scripts instead of an Object Browser tool.

kt



My situation is that I need to extend an existing system of lisp
sources written by somebody else who is not around anymore, and who
did not exactly intent his code to be extended, in terms of how he
documented it.

I imagine from the Graham articles I read that Lisp is really more for
the kind of jobs that one does for oneself, green-field development. I
already understand that Lisp gives freedom of how to express things
that is incredible compared to Java, and also plenty of ways to "hack"
as Paul Graham puts it.
Now unfortunately these do not seem as a great advantage to me having
to understand and extend a system written by somebody else.

What I use is emacs with slime and allergro lisp. I already tweaked
emacs to the expectations of lame eclipse users like me. But still I
miss some IDE features Java IDEs offer me.
Some things I do in Java to get an overview of a system new to me
would be like generating UML diagrams showing all classes and
dependencies, showing inheritence hierarchies and such.
Slime CLOS Object inspection seems to generally be able to do roughly
similar things, but I have not seen any function to get such a high-
level overview.
I am used to methods being neatly organized in classes, and classes in
package, but in Lisp it seems functions and such are just like dropped
in packages, in hundreds per package.
What I'd do next in Java with an existing system is rename classes and
methods if they seem badly named to me. But it seems in Lisp this
works only by search and replace, which is hardly what I could do over
hundreds of files.
What I also miss is a function like "mark occurences", such that when
the cursor is over a variable or function, all places in the code
where it is used are highlighted, making it easier to track where
which data goes.
Next on my list of disappointments is exception handling. I am used
for an exception to have mostly meaningful messages and above all show
me exactly which line of the code caused the exception. Currently all
I get is the function in which it happened, even worse if it happened
within a macro, i do not even get that. And the Stack looks
superflous, like (/ 1 0) gave me 20 stack frames, where I'd expect 2
at most in Java. These 20 cannot all be relevant to (/ 1 0), can
they?
Stepwise debugging also seems to be impossible with my setup with
allegro list, and unfortunately I have no choice in that matter.
Next on my list is declarations, I am used for methods in java to
declare both the type returned as well as all checked exceptions. Now
I see this is not convenient if you want to stay flexible about
returning different types, but really most of the times I expect
functions in lisp systems return just one time, don't they?
Now to find out that type, it seems I have to go recursively through
all branches of a function expanding all macros hoping I will not miss
anything. Can't there be anything helping me there? I could try
wrapping all function bodies in (the <type> ...) but that does not
look so slick. And the same applies to function parameters, if their
type can be inferred automatically, why can't the IDE infer their
types for me?
Another thing that annoys me greatly is that compiling in Emacs can
yield different results, even if the sources did not change, based on
the state of the REPL.
When I look through the existing code, I find plenty of things pretty
dirty, at first sight, making it hard for me to extend the code unless
I am sure I understood it all perfectly.
I of course greatly miss the power of Java code completion, which
comes with the restrictions of the Java OO system. It makes it so easy
to most classes you see for the first time, because the IDE would
suggest all methods of instances, while in lisp I have to first learn
all defined functions until I will have a chance to pick the one I
wanted.
I also seem to read very little about standards about documenting,
unit-testing, logging. Like in the java world, there is javadoc,
JUnit, Log4J, and one can be confident most open source projects will
use those to a reasonable extend. Of course the system i have to deal
with does not have any such standards, and it seems to me that such
standards are not of great concern to lispers. I found things like
Stefil, cldoc, log5, as alternatives, but they do not seem like
standards.
What would help me greatly in java to get the idea of the code is the
visibility of methods. If a method is private to a class, I know I
must be able to understand its usage just in this class, and changes
that I could make could only change things in this class. For
functions in lisp it seems there is no telling where they might be
used, especially since they could be used from within macros or
(eval ...) expressions, even for functions not exported from the
package, as lisp does not enforce visibility rules.
What I also like about Java is how many web resources there are for
java, plenty of tutorials, but mainly also plenty of problems people
ran into like me, and how they solved them. Today I googled for
"rethrowing errors", you know, as in handling exceptions of some type,
but not all of those. I found no usable result. The basic solution
would be (error the-error) as I know by know, but even that seemed
unpractical, as this does no more provide the stack of the original
error. (handler-bind) seems to rethrow the original error with the
original stack, but then it seems unable to prevent it from being
rethrown. Now the whole point here is that google found no result,
cltl2 was no big help, and this is just one of plenty of problems I
expect to encounter in the future. Is rethrowing errors something
exotic in lisp?

Now some of this is mere rant, but if you had similar experiences and
found ways to reduce the frustratin, please share.
And yeah, I read the joke about it being a good things Lisp being a
bitch to some at first so that those give up and less bad lisp code
gets written. haha, very funny. But don't give me "You'll get used to
that."

I think I can imagine already why Lisp is a great choice for any one-
man project, but it seems that it totally sucks for reverse
engineering systems, because it allows so bloody much.



so what is using lisp like?
feel wise?
apparently forth has low level words you can build into
anything.......and lisp allows you to construct procedures.....so how
is lisp nicer than subroutines or procedures.....tcl proc lets one
make procedures.....how is lisp more powerful?
.

Relevant Pages

  • Re: Learning Lisp the hard way
    ... Note I do not want to advocate Java over lisp, ... Unless you can use Windows to program AllegroCL (or also some *nixes, I forget which, where they have ported their IDE) because they do have a nice IDE closer to what you are used to in Java. ... Next on my list of disappointments is exception handling. ...
    (comp.lang.lisp)
  • Learning Lisp the hard way
    ... Note I do not want to advocate Java over lisp, ... Next on my list of disappointments is exception handling. ... When I look through the existing code, I find plenty of things pretty ...
    (comp.lang.lisp)
  • Re: Learning Lisp the hard way
    ... Note I do not want to advocate Java over lisp, ... Next on my list of disappointments is exception handling. ... When I look through the existing code, I find plenty of things pretty ...
    (comp.lang.lisp)
  • Re: Learning Lisp the hard way
    ... Note I do not want to advocate Java over lisp, ... Why not use the Allegro CL IDE? ...
    (comp.lang.lisp)
  • Re: Is anything easier to do in java than in lisp?
    ... And any experienced lisp ... in java generally you hardly ever use ... static String showInputDialog(Component parentComponent, ... which was about generic sequences (lists ...
    (comp.lang.java)