Re: Learning Lisp the hard way

JavaLisper,

It sounds like you're ramping up on several things at once: a new
language, new tools, an existing code base with possibly some design
and documentation shortcomings, and maybe ramping up on the software's
problem domain. I assume your new employers felt you were capable of
learning these things given you didn't have experience with them
before. So be sure to relax and give yourself a chance. How many
semesters did it take you to learn some Java? How many years to
master it? I thought Lisp would be quick to learn but I've found it
has a number of concepts that don't already exist in Java, so it has
been more than merely learning a new syntax.

I've seen plenty of badly designed, badly commented code in Java by
the way. Developers generally write what they write, equally good or
bad, in whatever language they are using. So if the current code base
is poorly done, it tells more about the prior developers than the
language.

I started learning Lisp recently, so I won't have the insight that
more experienced people here will have, but here are a few quick tips
I can note from my own experience. Maybe you will find them useful.

First, making an IDE that is fast, stable, extensible, featureful, and
to actually finish all of the small details is a big effort. The
reason IDE's as nice as Eclipse and Netbean exist is because Sun and
IBM paid real project managers, developers and testers to make them.
So although they are available to you today for free, they are really
commercial projects given away for free. It's good to remember that
when comparing those with a community-created editor with no
commercial support. When I started learning Java there were no IDEs
- not even an emacs mode - so I had to keep my copy of Java in a
Nutshell handy.

Having said that, I haven't so far found any shortcoming in
Emacs/Slime compared to Eclipse. It gives me code completion,
hotlinking to the hyperspec, the ability to jump around in the code,
to where a function or variable is defined or the reverse, to all of
the places a function or variable is used. Many of your complaints
seem to be centered around your lack of knowledge about how to use the
tool, not the capability of the tool itself.

I've recently had to work on updating some existing C# code at work,
and having used Eclipse daily for years, it's difficult to use at
first. The IDE is equally capable, I just haven't learned to use it
yet. For me, it works best if I bootstrap my brain by learning a
little bit of the IDE, then a little bit of the language, then a
little bit of the code and problem at hand, then a little bit
more... (loop a few times).

After learning some Emacs, I've found some useful Emacs features are
missing in Eclipse. Like the ability to record keystroke macros or
the ability to paste any of the past pasteboard items.

So learn the tool better, or try a different one that suits you better
(I haven't tried the others, but other people have made some
suggestions.) Here is a link to some of the documentation about
navigating cross references, code completion and most of the other
items you mentioned.

http://common-lisp.net/project/slime/doc/html/SLIME-mode.html#SLIME-mode

About C-c C-c being interpreted in a different context. I can't see
exactly what's happening on your computer, but I experienced something
similar with one lisp implementation (clisp) but not another
(clozure). I believe that with clisp, hitting C-c C-c was compiling
the function in the current package at the REPL prompt (probably
CL-USER) instead of within the package declared at the top of the
file. I assume this is a bug, but for now, if I'm working in a
package for a while I do an (in-package :my-package) at the REPL
prompt. Alternatively, I compile the whole file with C-c C-k so that
the (in-package) definition at the top of the file is included in the
compilation.

For me, step by step debugging is useful for Java (Java is more
painful without it), but I've realized that having the REPL is far
more flexible and powerful and I can usually pinpoint problems faster
with it. It's as if in Eclipse I could hit the "run in debugger"
button and have it sit there running my entire working session, with
the ability instantiate temporary objects to test with, and inspect
any object in the running system.

The Java approach is to generate Java code from any XML definitions
your libraries require (i.e., Spring or EJB or most of the other Java
frameworks), compile your code, set a breakpoint, start your server
and connect to it, start your client, take some action on the client
that hopefully triggers the right code path on the server to cause the
break point to be hit. Once I'm at the breakpoint, I can view a few
of the variables on the stack and heap, but I can't create new objects
on the fly, inspect and run things while sitting at the break point.
I'd love it if I could start the EJB server and then do my development
in a REPL, simply recompiling objects in the live server instance as I
make changes.

Lastly, here are a few emacs addons I have personally found useful:

- tabbar (tabbed navigation for emacs)

- paredit (takes care of filling in close parens. install when you
have an hour to learn the details.)

- desktop-save-mode - remembers which files you had open between
sessions

- IDO mode

- parenface - to make parens light grey

- highlight-parentheses - makes the nested layers of parens around the
cursor different colors

- Also, be sure emacs knows how to launch your web browser, so Slime
can hotlink from your code to the lisp API docs (hyperspec). I
think this is what I needed on my system:
(setq browse-url-browser-function 'browse-url-firefox)

Take care and good luck.

Matthias
.