Learning Lisp the hard way
JavaLisper
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.
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.
Rainer Joswig
<09bec3f9-5df0-4066...@w1g2000prk.googlegroups.com>,
JavaLisper <nol...@mt2009.com> 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.
>
> 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.
Right, but there are also features in Lisp that will
help small teams to write a bunch of libraries
that are documented and can be used to create an
application.
There was years ago a small book 'Lisp Style & Design'
which explained how to structure an application and
how to develop it. Unfortunately this book is hard
to get and very expensive.
Table of Contents here:
http://lispm.dyndns.org/news?ID=NEWS-2006-05-28-1
There is definitely some need for more tutorials
on programming in Lisp (style & design),
maintaining Lisp programs and using the IDEs
(SLIME, LispWorks, Allegro CL, ...).
> 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.
Why not use the Allegro CL IDE? Anyway you might want to
read the manual of Allegro CL (the development tool
parts) and the manual about the Allegro CL IDE.
The IDE is available for Windows and Linux.
> 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.
There are tools to browse class hierarchies and generic functions.
> 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.
There are cross reference tools.
> 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?
You can use the stack frame to find the function source.
Allegro CL records the source locations. You really
should read the chapter on the Allegro CL debugger
to see what features it offers.
> 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?
Not really.
> 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.
Learn about the IDE completion that is provided.
> 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.
For most uses, the Lisp IDE records the usage of functions
and can be queried about it.
> 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."
Lots of things are like you don't expect them. Some simply
are not available (UML diagrams for Lisp code), some
are different and some stuff is there that you might not
know about. It might help to read the documentation of
the Lisp you are using. Allegro CL has also its
own Emacs interface (ELI) and its own IDE. Plus it might
be useful to check if Franz offers training for their IDE.
Allegro CL has quite a lot development features (metering,
inspectors, debugger, cross reference, ...) that are really useful.
>
> 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.
Common Lisp is also quite good for small teams. But there is
no replacement for good software-engineering practice.
Without them, one can create a mess that is much worse
than in many other languages. A good IDE helps
(check out the Allegro CL documentation, LispWorks
is also a good alternative).
So, to sum it up, I understand your frustration:
* Lisp IDEs works different from Java IDEs
* some tools are not there
* some tools look different
* some stuff is more complicated
* lack of discipline leads to hard to maintain software
Don't forget to read the manuals.
Tim Bradshaw
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?
I removed the rest - I am sure that Lisp is hard to pick up from a
Java background. Having (somewhat, I'm not really a programmer any
more other than in the "run this script on 600 machines sense") moved
the other way, you'll be glad to know that Java is pretty painful
coming from a Lisp background as well: all that bondage and
discipline :-)
In the specific thing you ask: yes you can do all this quite easily.
However CL's condition system is somewhat different than Java's in the
sense that you could build Java's from CL's (I am fairly sure) but you
could *not* build CL's from Java's. The important thing to understand
(and it takes a while to get your head around this) is that HANDLER-
BIND deals with conditions *before the stack has unwound*. The more
conventional HANDLER-CASE macro (which is somewhat similar to Java's
try) is built from HANDLER-BIND (well, may be built from it in the
sense that you could write your own version which was). That
difference completely changes the way the condition system works, and
(once you understand it) it's also a pointer to the way Lisp differs
from languages like Java: you get these spectacularly powerful
primitives from which, with macros, you can built more syntactically-
convenient things (and of course, for CL, some of these syntactically-
convenient things are already there, though you can build more).
In terms of development environments, CL doesn't really have anything
as overwhelmingly helpful (or, perhaps, just overwhelming) as
Eclipse. When I wrote a lot of CL I used the LispWorks environment,
which I found very productive (it costs money other than for a
slightly restricted version, which I realise is now seen as
unacceptable by many: I've given up even trying to talk to those
people as I find it is almost always just more useful to kill them
straight away).
Kenneth Tilton
> 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
Pascal J. Bourguignon
> 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.
I find that learning new programming language is like learning new
human languages: to make it easy, you need to recover your baby mind.
Clear your mind, don't try to understand, plunge in it, and soon
enough your powerfull 1e14 neurons will be able to make sense of it.
In the mean time, read about Lisp and read you Lisp program,
independently of your java knowledge. (This is indeed the hard part,
you have to detach yourself from known frames, temporarily).
> 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.
And clearly, he didn't have a Java mind when writting this lisp code
(otherwise he could have written Java in Lisp and you would understand
it easily).
> [...]
> 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.
While with great efforts it would be, theorically, possible to give
the (set of) line(s) where the condition originated, in lisp it is
not very meaningful, because lisp sources are not text files, but
s-expressions that are built in various ways, and from various
origins. Of course, most of the time, these s-exps are built by the
lisp reader from text files, but a lot of them are actually built by
executing functions, either when reading the text files, or when
compiling the program. These little s-exp building functions are what
is called macros. Some macros themselves may be generated from
macros, so identifing a source text file corresponding to some CONS
cell in the source s-exp is really hard and meaningless.
If you remember that in Common Lisp, there are only 17 special
operators, and about 70 macros (the rest being normal functions), you
may realize that most of the source s-exps are not read from text
files but generated dynamically by these macros.
> 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 lisp, and unfortunately I have no choice in that matter.
Have you tried (STEP (some-function 'some-argument)) ?
Also, it may help if you compile your program having declared:
(declare (optimize (space 0) (speed 0) (safety 3) (debug 3)))
> 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?
Indeed. I agree that we lack sophisticated tools, doing global lisp
program analysis, such as infering types, shaking trees,
time-travelling debuggers (see google video "debugging in time"), etc.
We need more lisp programmers to have the resources to develop these
tools.
> 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.
You need to learn to use the REPL to good effect. It is not a command
user interface for the compiler. It is a sandbox to explore new and
old programs. With tools such as STEP, TRACE, INSPECT, etc, you can
use the REPL to learn how the program works, from inside, trying out
each functions, even internal functions, in addition to reading them.
> 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.
But exportation from a package _documents_ the visibility of a
function! You thought there was no documentation, but the source is
its own documentation. You just need to learn to read it.
> 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,
Using the right terminology might help. In lisp, errors are signaled,
not thrown.
> 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?
Not at all. You noticed yourself that HANDLER-BIND does it. To handle
the condition is to exit otherwise than by normal return. That is, you
can THROW some object (CATCH it), you can RETURN-FROM some enclosing
BLOCK, you can GO to some tag, you can SIGNAL another ERROR.
> 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."
Try:
http://www.cliki.net/Getting%20Started
http://www.cliki.net/Online%20Tutorial
http://www.cliki.net/Lisp%20books
Use groups.google.com to search this newsgroup. There are a lot of very
good articles. But you will need to use the right terminology (read the
CLHS glossary).
http://world.std.com/~pitman/Papers/Condition-Handling-2001.html
If you need to analyse that code body, remember that it's written in Lisp!
That means that you can trivially READ the source!
To deal with packages and reader macros simply, you may first load the
sources, and then:
(defparameter *some-file*
(with-open-file (src "some-file.lisp")
(loop
:for sexp = (read src nil src)
:until (eq sexp src)
:collect src)))
so now you can automatically process *some-file*, with normal lisp code.
For example, you can find all the methods calling a given function
(approximatively) with:
(defun defmethodp (form)
(and (listp form)
(eq 'defmethod (first form))))
(defun tree-find (object tree &key (test (function eql)))
(or (funcall test object tree)
(tree-find object (car tree))
(tree-find object (cdr tree))))
(let ((symbol 'some-package::some-function))
(remove-if-not (lambda (form)
(and (defmethodp form)
(tree-find symbol form)))
*source-file*))
etc.
The first consequent program I wrote in Common Lisp was such a
simplistic source analyzer for a C++ program, that would build a C++
methods call graph.
--
__Pascal Bourguignon__
Thomas A. Russ
Let's see what advice we can give.
> 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.
OK. But if this is reasonable standard lisp code, then the original
programmer should have chosen some nice, long, descriptive names for the
functions, classes and methods. Oftentimes, the names themselves are
chosen to be largely self-documenting.
On the other hand, it's possible to write bad, unmaintainable code in
any language, so your mileage may vary.
> 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.
Well, I and a lot of others would disagree. Many features of Common
Lisp are more geared toward building large systems and not necessarily
one-off programming jobs. Among these are the package system for
managing namespaces and a lot of introspection code.
> 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.
OK. But make sure you make appropriate use of Meta-. (Meta-period)
SLIME should also show you argument lists.
Finally, don't overlook some of the key features lisp has that is
missing in Java, namely the ability to type code into the REPL and
execute it interactively. Also, the TRACE macro for tracking function
calls. And the INSPECT facility for examining data structures. And
finally the natural serialization of much of the lisp data structures.
The REPL in particular allows you to experiment with some of the code to
see what it does and how it behaves. It also allows you to make
incremental changes in the code and try them out immediately, without
the need to go through the laborious build cycle of Java.
There is also a nice interactive debugger, and the ability to redefine
code while in a break loop and then continue on with the fixed code.
The inspector is also available in the debugger break loop.
> 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.
OK. There are two very important differences that you will need to get
used to. First of all, I'll deal with packages and then with the VERY
DIFFERENT object model in CLOS.
Packages in lisp manage name to symbol object mappings. That's it. They
allow you to set up namespaces that are separate, so that different
parts of a large system do not end up generating name conflicts.
Packages only manage the namespace and the name to symbol mapping.
The CLOS object model is significantly different from the Java/C++
object model. Classes encapsulate DATA only. They support multiple
inheritance nicely, and allow you to put storage (slots) into any of the
inherited classes. Unlike Java interfaces, which do not allow code or
fields.
Methods in CLOS do not belong to classes. This is important, so I'll
repeat: Methods in CLOS do not belong to classes. Methods belong to
generic functions. All of the methods that share a name are part of the
same generic function. The choice of which method to invoke when a
generic function is called is determined by dispatch on the type of all
of the required arguments. This provides you with multiple dispatch.
So, what you will typically find in a well-organized lisp source file is
a set of functions that are related to each other by what they do. The
organization of files is around FUNCTION, not class. So typically a
number of methods for the same generic function will often be in the
same place. Along with related methods and functions.
> 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.
Look at
> 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?
Exceptions will generally show you which function generated it. That
would be a particular stack frame. Some of this information is
controlled by the degree of compiler optimization that has been done.
In some cases a lot of stack frames are missing.
On the other hand, if you run interpreted code (such as what you will
get in Allegro CL by typing at the REPL), you will end up with many more
stack frames, since there is the information from the interpreter
interspersed in the call stack. This can be a blessing or a curse. You
will get more information with interpreted code, but sometimes too
much. But you can control this by compiling or not, and also by setting
additional options such as optimization and debug information levels.
> Stepwise debugging also seems to be impossible with my setup with
> allegro list, and unfortunately I have no choice in that matter.
I generally never use a stepper when debugging lisp code.
It is, however, easy to insert BREAK points in lisp. And then you can
use the debugging tools to look over the state of the computation. You
can also use the REPL to try out function calls, even in the middle of a
debugger session.
It is a different mode of operation, but you will need to learn to use
the appropriate debugging tools.
> 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?
Usually. But what is returned should be specified by the function
documentation or at the least the function's name. The type isn't
really all that useful if you don't know what it means. After all, how
helpful is it for you to see the following Java type signature:
public int f (int x, int y)
If I call it with f(2, 3) and it returns 8, is that the right answer?
> 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?
TRACE calls to the function. That will show you the call and the return
value. You should be able to determine the type from that.
> I could try
> wrapping all function bodies in (the <type> ...) but that does not
> look so slick.
DON'T DO THAT. Use a THE form is a promise to the compiler about the
types produced. It is not something that is enforced or checked by the
compiler. It is assumed that you would not lie to your compiler. If
you are concerned about this you can look at CHECK-TYPE. But I would
advise not going there initially.
If you really want to declare the types, you can do that. Look at the
FTYPE declaration. But again, I don't think that would be necessary.
> And the same applies to function parameters, if their
> type can be inferred automatically, why can't the IDE infer their
> types for me?
The type isn't inferred automatically. All values in lisp have manifest
type. That means that each value, including primitive literals carry
their type information around with them. You can introspectively figure
this out at any time. Just use TYPE-OF on the value. But generally,
you don't need this level of detailed information about everything. So
just concentrate on the parts that you need to understand.
You need to free your mind of this notion that types have to be
specified for everything. Think instead of all parameters being typed
Object, and able to handle anything.
> 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.
Huh?
This should only be the case if you modify some global state that the
compiler depends on. And that should be rare, unless you are redefining
things in the REPL.
If this is happening to you, then there is some other fundamental
misunderstanding, but there aren't enough clues to diagnose it from afar
right now.
> 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.
Well, that's because of the difference in the code organization model.
Lisp code is organized around functions, so it would perhaps be better
to learn the functions first and worry about the data types later.
Organization is around FUNCTIONs.
> 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.
Largely that is historic, and partly because the things that, for
example, the logging systems do are so simple to create in Lisp via the
macro system.
First of all, most logging can be done by simply inserting statements
that write to *trace-ouput*, which can then be rebound if you like.
> 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.
Lisp has a design philosophy of trying not to get in a programmer's
way. So visibility is signaled by package exporting. If a symbol isn't
exported, that is a warning sign that you shouldn't rely on in being
part of the interface for that chunk of code.
You have to free your thinking from being class-limited. You understand
functions as their own thing. When you know what a function does, it
really doesn't matter where it is used from. It will still always do
the same thing.
Ignore EVAL. It is hardly ever used in production code. You are making
things much harder for yourself by imagining all sorts of things that
could be going wrong. Instead, concentrate on the items that are being
actually used in the code you need to maintain.
Does it even use EVAL? How many macros are there?
> 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?
No. But it doesn't happen that often. You either handle the error or
don't bother catching it in the first place.
If you want some details on that aspect, you will need to carefully go
over HANDLER-BIND and EXCEPTION-CASE.
> 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.
It works great for large systems. That is where it really shines.
Now, in Java you have literally thousands of libraries, many of them
doing the same sorts of things. How many different logging libraries
are there? Don't you have to learn about all of them before you can do
any Java programming? I mean, what if you leave out the one library
that would really make your life simpler? Oh no, we have hit the
"paralysis of analysis", just in a different form.
So chill and approach this as an interesting exercise in expanding your
mind and set of programming tools and methods. It will help you in your
programming career, even if you never do any additional lisp work,
because it will present different ways of doing things. It is
mind-broadening, similar in some ways to learning a foreign language.
--
Thomas A. Russ, USC/Information Sciences Institute
Jon Harrop
You've basically rediscovered all of the reasons why good programmers no
longer choose to use Lisp.
JavaLisper wrote:
> 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.
Ah yes. I know this situation well. Lisp code is notoriously difficult to
maintain. Hence, companies that buy Lisp code inevitably end up rewriting
it. So rewrite your entire program in a modern language and document it.
> 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.
Lisp predates IDEs.
> 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.
Lisp predates UML.
> 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?
That is probably just lack of decent development tools. However, I am
surprised this is not better catered for because Lisp's lack of discipline
forces its programmers to live in the debugger. Consequently, I would have
expected it to be luxurious in there.
> 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?
Of course, but Lisp predates modern type theory and is completely incapable
of expressing such things in a usable way.The foundation is missing as well
as the tools.
> 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?
Learn to use the debugger and then use it to run through the program and
watch how it works. However, unless the program does something inherently
very complicated (unlikely if it can be written in Lisp) you are better off
just rewriting the entire thing from scratch starting from the
specification and forgetting the existing Lisp code.
> And the same applies to function parameters, if their
> type can be inferred automatically, why can't the IDE infer their
> types for me?
Lisp's basic design was ossified decades before decent type inference was
invented. Lisp is nowhere near capable of expressing such things.
> 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.
That's due to undisciplined programming.
> 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.
Yes, of course.
> 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.
Lisp was created a long time before such functionality was invented.
> 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.
Worse, Lisp allows any function to be replaced at run-time with anything
else, even if there are trivial type errors. Hence the unmaintainable "rats
nest" of code.
> 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?
No. Actually resumable exceptions are common 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.
Funny but wrong. All the intelligent people left the Lisp community a long
time ago.
> 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.
Yes. The value of Lisp is that you can hack together something that looks
good and sell it for a vast sum of money before the buyer realises the
hidden cost of it having been written in Lisp. There have been several high
profile occurrences of this (Lisp's "success" stories) and the codebase
gets written almost all the time.
For example, Sony made the mistake of buying Lisp code with NaughtyDog only
to have it completely rewritten:
http://bc.tech.coop/blog/060118.html
Yahoo made the mistake of buying Lisp code from Paul Graham, only to have to
rewrite it completely:
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=31402
The moral is: don't bother trying to maintain Lisp code.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Kaz Kylheku
> JavaLisper wrote:
>> 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.
>
> Ah yes. I know this situation well. Lisp code is notoriously difficult to
> maintain.
You've never given evidence that you have any experience or knowledge of Lisp.
So basically, this is just made up.
> All the intelligent people left the Lisp community a long
> time ago.
Note that one Jon Harrop is quite a fixture in the Lisp community,
so that can't be right.
Maybe this is where you find dumb people with whom you can enjoy discussing
on your own level?
Come on, just do a Lisp project; it's obviously what you want to do. :)
Dimiter "malkia" Stanev
> to have it completely rewritten:
>
> http://bc.tech.coop/blog/060118.html
Sony bought Naughty Dog, because there are some awesome programmers,
that would code in anything anyday just to get it working. Off course
their development way had to be dumbed down, so other studios can use
their technology.
And you exactly know what i mean by dumbing down!
java...@gmail.com
> i have several years of Java experience, but now my new job requires
Would Clojure be of any help to you?
Tim Bradshaw
[elided]
JavaLisper: have a search back through the recent archives of CLL to
decide whether you want to pay any attention to this person. The
answer should be pretty clear, I think.
Adde
>
> The moral is: don't bother trying to maintain Lisp code.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
Lisp is a powerful tool. It takes a lot of intelligence to use it
without hurting yourself and it takes a lot of intelligence to
interpret the results since you need to understand the underlying
reasoning. Blaming the tool for your own lack of intelligence is,
well, not very intelligent.
Now, go be a good drone and write your daily thousand lines of
"Modern" code and quit wasting our time.
Jon Harrop
> Lisp is a powerful tool. It takes a lot of intelligence to use it
> without hurting yourself and it takes a lot of intelligence to
> interpret the results since you need to understand the underlying
> reasoning. Blaming the tool for your own lack of intelligence is,
> well, not very intelligent.
Has anyone ever been "intelligent" enough to build anything significant in
Lisp without "hurting themselves"?
Regardless, that does not help someone who just inherited an unmaintainable
rats nest of code from yet another unaccomplished Lisper.
Kenneth Tilton
Careful, they may be the same person. If /Jon/ stops listening to
himself he gets garbage collected. Have you seen the mulcher?
java...@gmail.com
> On Jan 29, 3:34 am, Jon Harrop <j...@ffconsultancy.com> wrote:
Jon Harrop would like to be The Lisp Satan, too bad that he doesn't
have any Lisp experience, which would be the first requirement for
this Job...
Slobodan Blazeski
> Hi,
> i have several years of Java experience, but now my new job requires
> me to learn Lisp.
use lisp in the first place would act very dumb to hire programmer
with zilch experience in lisp to be incharge for the system written in
lisp. Than you say that you have Allegro, since it's a company that's
certainly an enterprise edition. So why would someone coming from
Eclipse would use or even less tweak with Emacs when nice Allegro IDE
is in his hands? Or since your company have money for the best tools
they could certainly spend little more for little training. Franz has
a certification program. In whole your post you didn't mentioned any
credential, like your name (are your parents calling you JavaLisper at
home ?), the company that you are working for, or what the hell your
system is suppose to do or even better who wrote such a crap? Lisp is
a small town, you can't hide and that's exactly what you're trying to
do. Why ? Because you're troll, and lispers and too nice persons to
believe you. Put down your mask to see your face nol...@2009.com
(mythrashmail account).
bobi
java...@gmail.com
> ... Java ... Lisp ...
I think you're searching for Gigamonkeys Consulting.
If that doesn't help, you could always convert the Chief Monkey back
to Java.
Happy bananas!
JavaLisper
The others here use Emacs, and I am not sure whether Allegro IDE has
actually more features, or whether the lack of the features I look for
is due to the lisp language.
> You can use the stack frame to find the function source.
> Allegro CL records the source locations.
Yes, I use that already. Still often I struggle to understand where in
a function using macros the error happened. I'd love to see the error
location in a some screen where the relevant function has been
macroexpanded deep enough to show the location of the error exactly in
expanded code.
> Learn about the IDE completion that is provided.
I already use completion, but I do not find it all that powerful.
Similar for syntax highlighting, which I would have hope to be more
semantic rather than mostly syntactical.
Like in my IDE, the following code would be all the same font:
... (setf (aref output-array (get-x cell) (get-y cell)) (get-symbol
car))
even though some of those are functions, others accessors, others
variables.
JavaLisper
> the (set of) line(s) where the condition originated, in lisp it is
> not very meaningful, because lisp sources are not text files, but
> s-expressions that are built in various ways, and from various
> origins.
As I replied to the previous poster, I'd often love to see the error
location in the expanded code, where it would make most sense.
> Have you tried (STEP (some-function 'some-argument)) ?
No, I did not know that one. It helps a bit, though like the stack
there is so much stuff going on around what I coded myself which I am
not too interested about. I'd like a STEP which only shows steps "in
my code" if that makes any sense.
> http://world.std.com/~pitman/Papers/Condition-Handling-2001.html
That one did not work for me.
> To deal with packages and reader macros simply, you may first load the
> sources, and then:
>
> (defparameter *some-file*
> (with-open-file (src "some-file.lisp")
> (loop
...
Thanks, I will try. However I would have expected such functions and
libraries to exist, and to be mature after I don't know, 50 years of
Lisp, and that they would ship with lisp.
JavaLisper
> maintain. Hence, companies that buy Lisp code inevitably end up rewriting
> it. So rewrite your entire program in a modern language and document it.
> For example, Sony made the mistake of buying Lisp code with NaughtyDog only
> to have it completely rewritten:
>
> http://bc.tech.coop/blog/060118.html
>
> Yahoo made the mistake of buying Lisp code from Paul Graham, only to have to
> rewrite it completely:
>
Though the additional rant is not too helpful, thanks for those links.
It helps me if some of the stories of the great success of LISP get
demystified a bit.
deech
-deech
Xah Lee
quick reply paragraph-by-paragraph style. But overall, i'd say 40% of
your problem is unfamiliarity of developing with dynamic languages in
larger scale software, 40% of being a lisp newbie, and 20% due to lisp
is truely old lang lacking all modern goodies.
On Jan 28, 2:20 pm, JavaLisper <nol...@mt2009.com> wrote:
> 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.
just want to mention that in this situation, it's a pain to begin
with, in any lang.
> 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.
in general, lisp in real world is not that much malleable or
extensible as lisp fanatics or books would picture it. It is
flexibility is about in the same class of nynamic langs aka scripting
langs, like perl, python, php, etc.
> 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.
Yes. Emacs is great for its power in text processing, however it
doesn't have built-in semantic based processing features like Eclipse.
There was some major effort, see:
http://jdee.sourceforge.net/
however, it has been inactive for maybe 9 years.
it is comparatively trivial to add Eclipse-like features to emacs,
because of the emacs lisp system there. Basically, you just need a
coherent design. There are relatively very few elisp coders, and given
that emacs's dev culture, it's not likely they will all work in one
design. Instead, you have 100 persons each having some lisp code that
does a bit this and that to satisfy their own need, adding them
together is incoherent, usually incompatible or inconsistent UI.
since you are on the road to emacs, you might try:
• Emacs Lisp Tutorial
http://xahlee.org/emacs/elisp.html
> 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.
UML, supposedly “Universal” modeling “lang”, is basically exclusively
used in OOP world only, in particular Java & C++. They are pretty much
useless and become and redundant for functional langs. (this can be
said for much of “Design Patterns” movement, and eXtreme Programing
(XP was red HOT in early 2000, now it seems disappeared. LOL))
In fact, my opinion of it is that it is one of the worst sneak-oil in
the computing world.
«... what society overwhelmingly asks for is snake oil. Of course, the
snake oil has the most impressive names —otherwise you would be
selling nothing— like “Structured Analysis and Design”, “Software
Engineering”, “Maturity Models”, “Management Information Systems”,
“Integrated Project Support Environments” “Object Orientation” and
“Business Process Re-engineering” (the latter three being known as
IPSE, OO and BPR, respectively).”» — Edsger W Dijkstra (1930-2002), in
EWD 1175: The strengths of the academic enterprise.
quoted from my Java tutorial:
• Java Tutorial
http://xahlee.org/java-a-day/java.html
For a essay on UML, Design Patterns, eXtreme Programing, see:
• Why Software Suck
http://xahlee.org/UnixResource_dir/writ/why_software_suck.html
> 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 haven't tried Slime. Am not a Common Lisp coder. (am Mathematica and
emacs lisp expert among others. (see my website for tutorial about 5
languages))
Try the other's advice about using the IDE of commercial lisp vendors.
> 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.
Yes, exactly. In functional programing world, you don't have
everything as one giant inflexible tree with a million branches.
Instead, you have packages/libraries, and each has functions. For a
field X, you use library X, which provide functions for X. You don't
have to get to know what is one particular library's tree. You just
use the function you want on your data. In other words, in functional
programing, you use functions on your data, as opposed to how
functions/methods are coded/organanized in particular package you are
using to see whether it is a suitable oop “object”.
> 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.
don't know if this renaming is your personal quirk or need, but in
general you don't rename existing code.
But if you need to (certainly i can imagine situations), yes, emacs
and much of dynamic lang world does not have some systematic
mechanical ways to rename. Search & replace dir-wide with eye-balling
is pretty much what you do. (partly because non-static types it's
harder)
for interactive find-replace in emacs, see:
• Interactively Find and Replace String Patterns on Multiple Files
http://xahlee.org/emacs/find_replace_inter.html
> 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.
In emacs, you can type Alt+x highlight-phrase to highlight a phrase.
There are also highlight-regexp, highlight-lines-matching-regexp.
These works on the current buffer. To highlight a phrase of all files
in a dir, you can Alt+x grep-find. (assuming you know basics of unix's
“find” syntax.)
> 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?
I HATE exceptions in Java, and in fact the whole concept of EXCEPTIONS
in programing langs, i hate the very terminology of
“EXCEPTIONS” (being inane, inaccurate, like a dishonest euphemism). My
first exposure to the concept in in Java around 1999. I suppose it was
first made popular in C++ ?
in particular, like Design Patterns, OOP, UML i hate, i think the
concept of “exceptions” is also one of the things that primarily came
out of the OOP world for OOP purposes. It is, in a sense, a complexity
introduced by OOP paradigm, not applicable or much useful outside of
OOP. See:
• What are OOP's Jargons and Complexities
http://xahlee.org/Periodic_dosage_dir/t2/oop.html
this is getting long. I'm posting this now. Second part follows
separately.
Xah
∑ http://xahlee.org/
☄
JavaLisper
wrote:
> On Jan 28, 11:20 pm, JavaLisper <nol...@mt2009.com> wrote:> Hi,
> > i have several years of Java experience, but now my new job requires
> > me to learn Lisp.
>
> I believe that your story is fabricated. Any company smart enough to
> use lisp in the first place would act very dumb to hire programmer
> with zilch experience in lisp to be incharge for the system written in
> lisp. Than you say that you have Allegro, since it's a company that's
> certainly an enterprise edition.
I see your point but I don't think your scepticism justifies your
calling
me a liar. I was hired into an academic position, not into a company,
and
I never claimed so, and a reason to hire me might have been lack of
candidates with Lisp background willing to work for little money.
Rainer Joswig
<f2553904-764c-4cb9...@y23g2000pre.googlegroups.com>,
JavaLisper <nol...@mt2009.com> wrote:
> > Why not use the Allegro CL IDE?
>
> The others here use Emacs, and I am not sure whether Allegro IDE has
> actually more features, or whether the lack of the features I look for
> is due to the lisp language.
So you did not read the manual?
>
> > You can use the stack frame to find the function source.
> > Allegro CL records the source locations.
> Yes, I use that already. Still often I struggle to understand where in
> a function using macros the error happened. I'd love to see the error
> location in a some screen where the relevant function has been
> macroexpanded deep enough to show the location of the error exactly in
> expanded code.
You can run code in interpreted
mode and see the expanded code. A good stepper for example
will step you through the code and the expansions.
For debugging it sometimes helps to run the code in the
interpreter.
>
> > Learn about the IDE completion that is provided.
>
> I already use completion, but I do not find it all that powerful.
> Similar for syntax highlighting, which I would have hope to be more
> semantic rather than mostly syntactical.
> Like in my IDE, the following code would be all the same font:
> ... (setf (aref output-array (get-x cell) (get-y cell)) (get-symbol
> car))
> even though some of those are functions, others accessors, others
> variables.
JavaLisper
> > would be like generating UML diagrams showing all classes and
> > dependencies, showing inheritence hierarchies and such.
>
> UML, supposedly “Universal” modeling “lang”, is basically exclusively
> used in OOP world only, in particular Java & C++. They are pretty much
> useless and become and redundant for functional langs.
I do not love UML particularly, what I like to do is visualize
components
graphically instead of textually. Like just scribbling some boxes and
arrows
on paper, I don't do much more in UML most of the times.
See, text is by its nature sequential, best for sequences, acceptable
for trees,
but very bad for graphs with cycles. To represent cycles in text, you
need ids
pointing to somewhere, and that means much more effort than just
looking at
an image.
Also UML like images help reduce the infromation to just the bits I
am
interested in sometimes. Like if I have 10 functions in 10 files, and
I want to know
how they call each other, I do not want to read them all, memorizing
all calls
from each to another, jumping between files.
I do not believe this is either useless or redundant for functional
programming neither.
Pascal J. Bourguignon
> Thanks, I will try. However I would have expected such functions and
> libraries to exist, and to be mature after I don't know, 50 years of
> Lisp, and that they would ship with lisp.
Unfortunately, lispers are usually paid to translate their lisp
programs into lesser programming languages, or when they are lucky, to
write automatic translators from lisp to lesser programming languages,
instead of further developing lisp tools for lisp.
--
__Pascal Bourguignon__
jos...@corporate-world.lisp.de
Mr. Harrop is a comp.lang.lisp (and beyond) spammer, who hasn't
written any
Lisp. He basically advertises for his OCAML and F# business here.
The other guy has already written a few lines of Emacs Lisp code
to customize Emacs.
Kenneth Tilton
> In article
> <f2553904-764c-4cb9...@y23g2000pre.googlegroups.com>,
> JavaLisper <nol...@mt2009.com> wrote:
>
>>> Why not use the Allegro CL IDE?
>> The others here use Emacs, and I am not sure whether Allegro IDE has
>> actually more features, or whether the lack of the features I look for
>> is due to the lisp language.
>
> So you did not read the manual?
>
>>> You can use the stack frame to find the function source.
>>> Allegro CL records the source locations.
>> Yes, I use that already. Still often I struggle to understand where in
>> a function using macros the error happened. I'd love to see the error
>> location in a some screen where the relevant function has been
>> macroexpanded deep enough to show the location of the error exactly in
>> expanded code.
>
> You can run code in interpreted
> mode and see the expanded code.
No need. AllegroCL has shown macros in the stack for a coupla years now.
I am surprised JavaLoser did not notice.... PWUAHAHAHAHHHAHAAA!!!
hth,kth
Pascal J. Bourguignon
>> > 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.
>>
>> UML, supposedly “Universal” modeling “lang”, is basically exclusively
>> used in OOP world only, in particular Java & C++. They are pretty much
>> useless and become and redundant for functional langs.
>
> I do not love UML particularly, what I like to do is visualize
> components graphically instead of textually. Like just scribbling
> some boxes and arrows on paper, I don't do much more in UML most of
> the times. See, text is by its nature sequential, best for
> sequences, acceptable for trees, but very bad for graphs with
> cycles. To represent cycles in text, you need ids pointing to
> somewhere, and that means much more effort than just looking at an
> image.
You can use cogre to make your diagrams from the lisp code.
http://cedet.sourceforge.net/cogre.shtml
Also, it's not really true that nothing is done in the domain of lisp
code visualization. Only this is not distributed as commercial products.
See for example:
http://www.iam.unibe.ch/~scg/Archive/Papers/Dozs08aLispLooksDifferent.pdf
Or if it is commercialized, it is too expensive for a casual use.
--
__Pascal Bourguignon__
Xah Lee
> 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?
lisps are dynamically typed. In general, langs like Mathematica, perl,
python, php etc don't much care about type, you just care about what
is the value. In many of these lang, types are automatically
converted. e.g.
In python, int/float are auto converted. In perl and php, string,
number (int/float) are all auto converted. In Mathematica, there's not
even “types” as int float, you just have real world types like Real
numbers, Rational Numbers, Complex numbers. So-called “algebraic
types” by so-called computer scientists.
The gist is that, in these high level langs, you don't care about the
computer-engineering by-product of “type”. You only care about value.
i don't quite understand why you needed to know the type in your task.
In some static typed functional lang, such as Ocaml, Haskell, they are
very type strict (far more so than Java), yet the lang provide type
inference (which doesn't exist in java).
The term “type inference”, or usually jargonized by functional
programing tech geeking fuckfaces as “Hindley Milner type inference”,
may seem exotic and fearsome. But it's really a trivial idea.
For example, in java, you can declare a var of String type like this:
String s1 = "someStr";
But look yonder!! the syntax for string literal: “"someStr"”, already
unambiguously indicate a string type. So, why does the lang REQUIRE
the programer to put a “String” in front of s1? Since the compiler can
trivially infer s1 is a string type.
This is a very simple, to the point, practical, illustration of the
need for type inference. Calling it “type inference” is in fact a bit
stupid. It's like calling a car “Electro/Combustion Engine System
wheeled car” or the sky as “immersive overhead wheather-appearance
sky” or calling variables in computer languages as “automatic
reference update name-template”.
In a ideal world, “type inference” doesn't need a name, and is simply
part of a well-designed language. In view of the history of progress
of languages, sometimes things out of necessary engineering issues,
has names. Similar applies to terminologies like “int, float, double,
data types, type systems, garbage collection”, and now “type
inference”. Tech geeking morons will dive into these stupidities going
nowhere.
> 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.
Not sure what you mean. What you said as is doesn't make sense. The
functional programing stupid jargon REPL stands for Read-Evaluate-
Print-Loop. “Compilation”, depending what you mean, usually does not
depend on REPL, since REPL is usually just a interactive or step-wise
programing paradigm usually for tutorial or small programs. (lisp
fanatics will disagree, but they are morons)
> 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.
static typed OOP langs like Java, out of its nature heavily relies on
templates to ease coding. So, if you are habituated with Java, you
expect tools to show you templates, hierarchy, the system, so that it
makes it more possible to BEGIN to work on it. In high-level langs or
dynamic & scripting lang or functional programing world, things are
more flexible and non-fixed and non-static, so you don't need these to
begin with, or that such a tool doesn't make sense.
As i mentioned before, you have basically many different set of
functions, each set does things in field X. What is required for you
to know is familiarity with these functions of the set you want to
use. (set here means variously as packages, libraries, modules) A
function typically has a input/output spec. Namely, what java would
call method signatures. For more detail on this issue, see:
• Interface in Java
http://xahlee.org/java-a-day/interface.html
> 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.
Standard in-line documentation format as javadoc is a good thing. Most
dynamic lang or functional lang doesn't have it, or as extensive and
elaborate as Java.
(i think the idea of in-line documentation of function originates with
lisp in the 1980s or earlier)
Elaborate in-line doc system/format is good especially for large
projects.
> 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.
Java's “visibility of methods” or its elaborate privacy/public
declaration is risen as necessary consequence of the OOP machinery.
See the section «The Rise of “Access Specifiers” (or, the Scoping
Complexity of OOP)» at:
• What are OOP's Jargons and Complexities
http://xahlee.org/Periodic_dosage_dir/t2/oop.html
in highlevel or functional lang, in a package you may have lots
functions, and some function is only aux helper functions that has
little use outside of the package. So, you also have the issue needing
to know which function are public. In general, well-written packages
hide or does not expose these aux functions to public view. These lang
however does not have a elaborate, fixed, mechanical system like Java
for declaring what function is at what “access level”. In perl,
Python, for examples, usually aux functions are simply not imported so
you don't see them.
> 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?
Large number of users is a significant advantage. Lisp was a popular
lang in the 1980s, but today it's fringe. (it is made fringier and
fringier by lisp fanatics, especially Common Lispers and Scheme
Lispers) On this issue, regarding available help, see:
• Language, Purity, Cult, and Deception
http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html
> 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.
Remember, most lisp things you read on the web is crap. The lisp books
published in 1980s or 1990s are also inane and crap for today's
computing industry landscape.
Remember, your problem is likely 40% unfamiliarity of developing with
dynamic languages, 40% of being a lisp newbie, and 20% due to lisp
obsolesce.
Thanks for reading my rant, too.
Xah
∑ http://xahlee.org/
☄
Thomas A. Russ
> ?? writes:
> > You can use the stack frame to find the function source.
> > Allegro CL records the source locations.
> Yes, I use that already. Still often I struggle to understand where in
> a function using macros the error happened. I'd love to see the error
> location in a some screen where the relevant function has been
> macroexpanded deep enough to show the location of the error exactly in
> expanded code.
Do you really run into this problem a lot?
Does the lisp code you are trying to maintain use a lot of its own
macros?
Generally, you would want to try to understand the functionality that a
macro provides and not typically worry about the expansion, unless you
suspect that the macro itself is buggy. The whole point of using macros
and functions is to provide an abstraction layer to allow you to not
have to try to keep track of every detail at the same time. So, it
would be better to not generally worry about the expansion, but instead
try to comprehend what the macro itself is trying to do.
One major application of macros is to construct a higher-level,
domain-specific language for writing code. So you should learn this
higher-level, domain-specific language. It will make your life simpler.
Finally, what about
> Similar for syntax highlighting, which I would have hope to be more
> semantic rather than mostly syntactical.
Well, there's a reason it's called SYNTAX highlighting.
> Like in my IDE, the following code would be all the same font:
> ... (setf (aref output-array (get-x cell) (get-y cell)) (get-symbol
> car))
> even though some of those are functions, others accessors, others
> variables.
First of all, accessors are just functions in Lisp, so there really
isn't any distinction. Some accessors are ordinary functions (like from
DEFSTRUCT), whereas others are generic functions (like from CLOS). And
nothing stops you from adding arbitrary other methods to a generic
function that is used as an accessor for some arguments. So there
really isn't any syntactic distinction between accessors and functions.
It depends more on the intended usage, and that can't be detected
syntactically.
And you don't really need additional highlighting to distinguish
functions and variables. Functions can be detected by the "(" character
that is right in front of them. Variables have white space in front of
them. You will need to learn to adjust to the Lisp conventions and way
of thinking.
After all, you presumably don't approach XML or XSLT expecting it to
work and look like Java, do you? Common Lisp is a different language.
You will need to adjust your cultural perceptions and not try to do Java
development with a Common Lisp system. You need to follow the Lisp Way.
Kaz Kylheku
> JavaLisper <nol...@mt2009.com> writes:
>> Similar for syntax highlighting, which I would have hope to be more
>> semantic rather than mostly syntactical.
>
> Well, there's a reason it's called SYNTAX highlighting.
Indeed. Ideas can be colorless, and even sleep furiously. But if there is a
hint of green, syntax is being assigned. :)
Rob Warnock
+---------------
| > http://world.std.com/~pitman/Papers/Condition-Handling-2001.html
|
| That one did not work for me.
You were given a bum steer; Kent Pitman's pages moved from
"world.std.com" to "nhplace.com" way back in 2003. Try this:[1]
http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html
Also be sure to check out Kent's many other interesting/useful
writings on software, largely on Lisp:
http://www.nhplace.com/kent/Papers/index.html
The following older paper might provide additional context/insight
into the above paper on conditional handling:
http://www.nhplace.com/kent/Papers/Exceptional-Situations-1990.html
And *definitely* before complaining about there being no generic
COPY or COPY-INSTANCE in Common Lisp, you need to read this: ;-} ;-}
http://www.nhplace.com/kent/PS/EQUAL.html
-Rob
[1] Which you could have also found by Googling for
"Condition-Handling-2001" and hitting the
"I'm feeling lucky" button...
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
blue indigo
>> > 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.
>>
>> UML, supposedly “Universal” modeling “lang”, is basically exclusively
>> used in OOP world only, in particular Java & C++. They are pretty much
>> useless and become and redundant for functional langs.
>
> I do not love UML particularly, what I like to do is visualize
> components
> graphically instead of textually. Like just scribbling some boxes and
> arrows
> on paper, I don't do much more in UML most of the times.
*snip*
Eh, what? This looks like it's from the middle of a thread, but there's no
attributions and I don't see any other posts in cljp from the same thread.
I don't care much for UML -- when I want to document or specify something
I write a Java interface with appropriate doc comments.
The basic type system for a project can be specified this way, and as an
extra added bonus feature the compiler can understand parts of it and
enforce parts of the specified contracts.
Assuming, of course, that you're coding the final product in Java.
--
blue indigo
UA Telecom since 1987
Arne Vajhøj
> On Thu, 29 Jan 2009 14:12:52 -0800, JavaLisper wrote:
>>>> 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.
>>> UML, supposedly “Universal” modeling “lang”, is basically exclusively
>>> used in OOP world only, in particular Java & C++. They are pretty much
>>> useless and become and redundant for functional langs.
>> I do not love UML particularly, what I like to do is visualize
>> components
>> graphically instead of textually. Like just scribbling some boxes and
>> arrows
>> on paper, I don't do much more in UML most of the times.
>
> *snip*
>
> Eh, what? This looks like it's from the middle of a thread, but there's no
> attributions and I don't see any other posts in cljp from the same thread.
Xah Lee likes to cross post to several groups with "discussion
encouraging" content.
:-)
Arne
MarkHa...@gmail.com
> You will need to learn to adjust to the Lisp conventions and way
> of thinking.
>
> After all, you presumably don't approach XML or XSLT expecting it to
> work and look like Java, do you? Common Lisp is a different language.
> You will need to adjust your cultural perceptions and not try to do Java
> development with a Common Lisp system. You need to follow the Lisp Way.
>
> --
David Van Driessen once said the same thing about learning Common Lisp
Slobodan Blazeski
We got a lot of spam nonsense like your post comming from trolls who
have nothing better to do,so I apologize IF I got the false positive.
But then why you're hiding your name?
bobi
gavino
> JavaLisper wrote:
> > Hi,
> > i have several years of Java experience, but now my new job requires
> > me to learn Lisp.
> > 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.
>
> 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.
>
> > 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.
>
> > emacs to the expectations of lame eclipse users like me. But still I
> > miss some IDE features Java IDEs offer me.
> > would be like generating UML diagrams showing all classes and
> > dependencies, showing inheritence hierarchies and such.
> > similar things, but I have not seen any function to get such a high-
> > level overview.
> > package, but in Lisp it seems functions and such are just like dropped
> > in packages, in hundreds per package.
> > 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.
> > 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.
> > 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?
> > 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?
> > yield different results, even if the sources did not change, based on
> > the state of the REPL.
> > 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.
> > 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.
> > 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.
> > 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?
>
> > 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?
gavino
> Adde wrote:
> > Lisp is a powerful tool. It takes a lot of intelligence to use it
> > without hurting yourself and it takes a lot of intelligence to
> > interpret the results since you need to understand the underlying
> > reasoning. Blaming the tool for your own lack of intelligence is,
> > well, not very intelligent.
>
> Has anyone ever been "intelligent" enough to build anything significant in
> Lisp without "hurting themselves"?
>
> Regardless, that does not help someone who just inherited an unmaintainable
> rats nest of code from yet another unaccomplished Lisper.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u
how does lisp enable things to be easy and cool over python?
gavino
> On Jan 29, 3:34 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>
>
>
> > You've basically rediscovered all of the reasons why good programmers no
> > longer choose to use Lisp.
>
> > JavaLisper wrote:
> > > 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.
>
> > maintain. Hence, companies that buy Lisp code inevitably end up rewriting
> > it. So rewrite your entire program in a modern language and document it.
>
> > > 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.
>
>
> > > 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?
>
> > surprised this is not better catered for because Lisp's lack of discipline
> > forces its programmers to live in the debugger. Consequently, I would have
> > expected it to be luxurious in there.
>
> > > 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?
>
> > of expressing such things in a usable way.The foundation is missing as well
> > as the tools.
>
> > > 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?
>
> > watch how it works. However, unless the program does something inherently
> > very complicated (unlikely if it can be written in Lisp) you are better off
> > just rewriting the entire thing from scratch starting from the
> > specification and forgetting the existing Lisp code.
>
> > > And the same applies to function parameters, if their
> > > type can be inferred automatically, why can't the IDE infer their
> > > types for me?
>
> > invented. Lisp is nowhere near capable of expressing such things.
>
> > > 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.
>
>
> > > 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.
>
> > else, even if there are trivial type errors. Hence the unmaintainable "rats
> > nest" of code.
>
> > > 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.
>
> > time ago.
>
> > > 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.
>
> > good and sell it for a vast sum of money before the buyer realises the
> > hidden cost of it having been written in Lisp. There have been several high
> > profile occurrences of this (Lisp's "success" stories) and the codebase
> > gets written almost all the time.
>
> > For example, Sony made the mistake of buying Lisp code with NaughtyDog only
> > to have it completely rewritten:
>
> >http://bc.tech.coop/blog/060118.html
>
> > Yahoo made the mistake of buying Lisp code from Paul Graham, only to have to
> > rewrite it completely:
>
> >http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPos...
>
> without hurting yourself and it takes a lot of intelligence to
> interpret the results since you need to understand the underlying
> reasoning. Blaming the tool for your own lack of intelligence is,
> well, not very intelligent.
>
> "Modern" code and quit wasting our time.
can you really do same program in 1/5 code using lisp?
jos...@corporate-world.lisp.de
\|||/
(o o)
,----ooO--(_)-------.
| Please |
| don't feed the |
| TROLLs ! |
'--------------Ooo--'
|__|__|
|| ||
ooO Ooo
Frank Buss
> so what is using lisp like?
> feel wise?
This is difficult to describe. I think it has to do with the philosophical
problem of Qualia:
http://en.wikipedia.org/wiki/Qualia
You can try to describe it with words, but it would be the same like trying
to describe how the color "red" feels, to a blind people: Unless you try
programming in Lisp yourself, you won't know how it feels, so maybe YOU
will never know it :-)
> 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?
It is not more powerful, but it is a sound mix of some interesting language
ideas, which helps to choose the one which fits a given problem. E.g. if
you want to write some functional program, like this one:
http://www.frank-buss.de/lisp/functional.html
This is easy in Lisp, because it has closures. Would be more difficult in
Forth, at least if you try it out-of-the box with ANS Forth.
But if you want to build some GUI, the object oriented concept might be
better, as shown in the SDL mapping for the lispbuilder-sdl project, e.g.
for the surface class:
http://code.google.com/p/lispbuilder/
Of course, mixing different concepts can be very powerful, too, e.g. the
with-* macros, which are used in Common Lisp and in Lispbuilder.
Of course, this flexibility has the drawback, that it is not as perfect for
a given paradigm as a language designed for it, e.g. Haskell for functional
programming or Java for simple imperative programs, which can be written
and maintained by average programmers.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
TomSW
> 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.
Are you using th Allegro IDE? It allows you to:
- inspect objects
- browse classes & class trees
- graph inheritance trees
- view the direct and indirect slots, direct an indirect methods of
an object / class
> 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.
If you did the same thing in Java, wouldn't you also end up using
search & replace?
> 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.
Emacs can highlight all the occurrences of a symbol in a buffer. There
are various ways to do it - some of my coworkers have a shortcut that
highlights the symbol at point, I tend either to start doing a search
(C-s) which highlights the next occurrences of the search term (C-w in
this situation adds the word at point to the search term), or M-x
occur
Allegro's cross-referencing functions can be very useful for certain
kinds of code analysis, for example, detecting calls to undefined
functions, functions that are no longer called, etc.
Incidentally, if you are using the Allegro IDE with Slime, you will
need to do some tweaking so that the IDE's "find definition" opens the
definition in Emacs, not in Allegro's editor (which sucks). Bill
Clementson's blog mentions one way to do this - another way is to
fwrap or advise Allegro's ide.find-definitions:show-source-code:
(in-package :ide.find-definitions)
(def-fwrapper show-source-code-slime (def)
(swank:ed-in-emacs (excl::convert-to-external-fspec
(first (raw-info def)))))
(fwrap 'show-source-code :acl-slime 'show-source-code-slime)
(funwrap 'show-source-code :acl-slime)
I'm in the opposite situation, getting used to Java after using Lisp
(and have plenty to bitch about too...)
Tom SW
Frank Buss
> If you did the same thing in Java, wouldn't you also end up using
> search & replace?
In Java you could use Eclipse, which has a lot of automatic refactoring
tools:
http://www.ibm.com/developerworks/library/os-ecref/
This is an old article, today Eclipse has more sophisticated refactoring
tools, but it is a nice article anyway.
Jon Harrop
> On 29 Jan., 22:45, JavaLisper <nol...@mt2009.com> wrote:
>> Though the additional rant is not too helpful, thanks for those links.
>> It helps me if some of the stories of the great success of LISP get
>> demystified a bit.
>
You mean I am not maintaining a widely-used or high-profile Lisp code base
but, then, neither is anyone else here (including you). In fact, none
exist.
jos...@corporate-world.lisp.de
> jos...@corporate-world.lisp.de wrote:
> > On 29 Jan., 22:45, JavaLisper <nol...@mt2009.com> wrote:
> >> Though the additional rant is not too helpful, thanks for those links.
> >> It helps me if some of the stories of the great success of LISP get
> >> demystified a bit.
>
> > Mr. Harrop ... hasn't written any Lisp.
>
> You mean I am not maintaining a widely-used or high-profile Lisp code base
> but, then, neither is anyone else here (including you). In fact, none
> exist.
No, I did't mean that. I meant what I wrote: you haven't written any
Lisp
libary, application, tool, whatever. Nothing. Nada. Nichts.
Many people in c.l.l have, including me.
Raymond Wiker
> We got a lot of spam nonsense like your post comming from trolls who
> have nothing better to do,so I apologize IF I got the false positive.
> But then why you're hiding your name?
You mean like calling yourself "fireblade" :-?
java...@gmail.com
>> Mr. Harrop ... hasn't written any Lisp.
Should we really offend the intelligence (even of fresh newbies) with
the explicit need of telling them that Jon Harrop is only doing
advertising masturbation?
OK, but then we should do it right:
Jon Harrop is doing advertising masturbation on Mondays.
Jon Harrop is doing advertising masturbation on Tuesdays.
Jon Harrop is doing advertising masturbation on Wednesdays.
Jon Harrop is doing advertising masturbation on Thursdays.
Jon Harrop is doing advertising masturbation on Fridays.
Jon Harrop is doing advertising masturbation on Saturdays.
Oh yes, and I forgot:
Jon Harrop is doing advertising masturbation even on Sundays.
JavaLisper
It's not that I need it, it is that it makes things easier.
Imagine this situation
(let ((a (foo)))
(bar a))
where bar is a generic function having several methods for different
classes of a.
Then if foo always returns instances of a certain class, it would help
me to know.
What's more, when dealing with a system somebody else wrote, I would
in the above not know what classes foo or bar deal with. Assume now
bar were a function, then just to find out what kind of values it is
intended to work on, I'd have to read
either foo or bar, and from there on recursively, until I find some
cue.
As beautiful as Lip code may be, I actually like sometimes to skip
reading functions, but lack of documentation and declaration forces me
to waste my time reading code just to find out what kind of values it
deals with.
> For example, in java, you can declare a var of String type like this:
>
> String s1 = "someStr";
>
> But look yonder!! the syntax for string literal: “"someStr"”, already
> unambiguously indicate a string type. So, why does the lang REQUIRE
> the programer to put a “String” in front of s1?
There is no need, but some reasons to still enforce this, but I guess
this has been discussed in other places plenty of times.
> In a ideal world, “type inference” doesn't need a name, and is simply
> part of a well-designed language.
What I'd like is that my IDE would tell me that in the following:
(defun foo ()
(bar))
(defun bar ()
'( a b c))
that foo always returns a list.
> > 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.
>
> Not sure what you mean. What you said as is doesn't make sense. The
> functional programing stupid jargon REPL stands for Read-Evaluate-
> Print-Loop.
What I mean is in emacs I press C-c C-C twice without changing the
open
file, the result may be different the second time, depending on the
file.
> In high-level langs or
> dynamic & scripting lang or functional programing world, things are
> more flexible and non-fixed and non-static, so you don't need these to
> begin with, or that such a tool doesn't make sense.
In Lisp, I would also enjoy if typing "(let" and some shortcut
created (let ((| )) )
And even better, if there was
(foo (a b)...)
where a and b where declared as Integer and String respectively, then
typing
(let ((a 3) (b "test"))
(foo
would automatically suggest a and b as next entries.
My Emacs IDE has completion suggestions, but that also suggest plenty
of words that exist but are not valid in the context. As an example
in:
(defun foo (a) (declare (type list a)) ...)
(let ((test1 4) (test2 '(a b d))
(foo tes|
"|" indicating the cursor, I would like the IDE to only suggest test2
not test1.
> Elaborate in-line doc system/format is good especially for large
> projects.
This kind of thinking causes people not to document small projects.
However many large projects started small. And sometimes the time when
the project grows from small to large is when the guy that created the
sources leaves for other to take over undocumented code.
Which is why I prefer the thinking that encourages documenting even
for small projects.
JavaLisper
> functions and variables. Functions can be detected by the "(" character
> that is right in front of them. Variables have white space in front of
> them.
Except of course for quoted lists (unless within a macro body) or in
(let ((let a)...
Look, nobody *needs* syntax highlighting (unless somebody invented a
prog lang with semantic colouring), but it makes reading any code in
any language easier.
Dimiter "malkia" Stanev
WARNING: Predatory Masturbating on the rise!
http://www.chaser.com.au/index.php?option=com_content&task=view&id=1483&Itemid=26
JavaLisper
> > 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.
>
> If you did the same thing in Java, wouldn't you also end up using
> search & replace?
No, not with an IDE like Eclipse. Such as in
(defun foo (foo)
(foo foo))
i could, if the Lisp IDE could do the same thing, press C-r over the
first foo, enter bar, and the code would then look like this:
(defun bar (foo)
(bar foo))
And not only in the same file, but Eclipse would ask to make the
changes to any cllaer of foo anywhere in the source tree, and even in
many kinds of configuration files.
Same works for changing
(foo (a b) (/ a b)) to (foo (b a) (/ a b)), as in also changing the
order of parameters in all calls to foo.
I think this is impossible in Lisp because of macro bodies and such,
which is a thing I don't like about Lisp. Go on, sue me.
> Allegro's cross-referencing functions can be very useful for certain
> kinds of code analysis, for example, detecting calls to undefined
> functions, functions that are no longer called, etc.
Is that the free version of Allegro IDE? Or just allegro lisp?
JavaLisper
wrote:
> We got a lot of spam nonsense like your post comming from trolls who
> have nothing better to do,
> so I apologize IF I got the false positive.
Learn to apologize proper, if you want me to accept.
> But then why you're hiding your name?
I am shy. I want to be able to whine without my boss knowing. I don't
want to tell my name to people who call other people liar prematurely.
Whatever, take your pick.
JavaLisper
> functions and variables.
And of course one does not actually need to indent code, since
counting brackets is just a matter of get used to it, dropping old
paradigms, leaving the comfort zone...
Rainer Joswig
<580ea9a9-c454-456b...@q30g2000prq.googlegroups.com>,
JavaLisper <nol...@mt2009.com> wrote:
> > i don't quite understand why you needed to know the type in your task.
>
> It's not that I need it, it is that it makes things easier.
> Imagine this situation
> (let ((a (foo)))
> (bar a))
>
> where bar is a generic function having several methods for different
> classes of a.
> Then if foo always returns instances of a certain class, it would help
> me to know.
You could interface to a type inferencer (like in SBCL). Usually
I would just type (foo) to the REPL and see what it returns.
For more complex tasks I would trace FOO or BAR.
> What's more, when dealing with a system somebody else wrote, I would
> in the above not know what classes foo or bar deal with. Assume now
> bar were a function, then just to find out what kind of values it is
> intended to work on, I'd have to read
> either foo or bar, and from there on recursively, until I find some
> cue.
You can declare it in the code. Lisp has an FTYPE
declaration. Some code uses a VALUES declaration. You
can add your own declaration types with DECLARATION.
Often it is just sufficient to use a documentation
string. One can look that up with a keystroke
in most IDEs or (documentation 'bar 'function) .
> As beautiful as Lip code may be, I actually like sometimes to skip
> reading functions, but lack of documentation and declaration forces me
> to waste my time reading code just to find out what kind of values it
> deals with.
That's why some code documents or declares it as I have mentioned
above.
Another way is to use your own defining macros that do more
and expand into the usual defining macros.
CL-HTTP example:
(define-generic put-document (url stream &optional newly-created-url-p check-versions-p)
(declare (values url status content-type-spec bytes last-modification))
(:documentation "Deposits a document read from STREAM into a pathname denoted by URL.
When CHECK-VERSIONS-P is non-null, the derived-from header is checked against the existing
resource version."))
You see that it has a values declaration. Also in some IDE it will
register this generic function and make it searchable, etc.
...
> (defun foo ()
> (bar))
>
> (defun bar ()
> '( a b c))
>
> that foo always returns a list.
It does not ALWAYS return a list. It looks like it will, but it can be changed
at runtime. Also it is 'difficult' to write a function that
will compute that for the general case
...
> In Lisp, I would also enjoy if typing "(let" and some shortcut
> created (let ((| )) )
>
> And even better, if there was
> (foo (a b)...)
See PAREDIT and REDSHANK as CL editing extensions for Emacs.
...
> This kind of thinking causes people not to document small projects.
> However many large projects started small. And sometimes the time when
> the project grows from small to large is when the guy that created the
> sources leaves for other to take over undocumented code.
> Which is why I prefer the thinking that encourages documenting even
> for small projects.
Right. Documentation is good. CL has documentation strings for that.
(defclass foo ()
((a :documentation "this fine slot has ..."))
(:documentation "this fine class has no superclass. It has one slot a and is used for ..."))
Common Lisp allows documentation strings in several places.
DOCUMENTATION can then look up the documentation. A keypress away in most IDEs.
TomSW
> As beautiful as Lip code may be, I actually like sometimes to skip
> reading functions, but lack of documentation and declaration forces me
> to waste my time reading code just to find out what kind of values it
> deals with.
Lisp isn't the only language that doesn't declare types. As for the
lack of documentation, it's hardly Lisp's fault - given your lack of
familiarity with Lisp and the code you're working with you don't have
much option but to read the code anyway, and document it as you go :)
Types do provide their own documentation, but only up to a point, and
then it's down to disciplined programmers, as it always will be. In
that respect it sounds like you were unlucky with your predecessors.
> In Lisp, I would also enjoy if typing "(let" and some shortcut
> created (let ((| )) )
>
> And even better, if there was
> (foo (a b)...)
>
> where a and b where declared as Integer and String respectively, then
> typing
> (let ((a 3) (b "test"))
> (foo
>
> would automatically suggest a and b as next entries.
- and what happens if you have more local variables, with more complex
types, and your method "foo" is specialised for more than one
combination of those types? This happens all the time in CLOS and will
mean that your type-based "helpful" completion will be wrong more
often that it's right.
Try paredit mode, it's very a very nice Emacs minor mode for editing
lispy languages. As for boilerplate code, consider avoiding it
altogether - use macros :) Also have a look at the Emacs extension
yasnippet, and the abbreviations support (eg to expand "dsb" into
"destructuring-bind", "lll" into "#'(lambda () )" etc).
Get good at using the Allegro IDE, and Emacs, they're both very
powerful. Come to terms with the fact that you're working with an
unfamiliar language and that there's going to be a learning curve. On
the other hand, don't believe anyone who tells you that the problem is
only due to your unfamiliarity with Lisp, or your lack of
intelligence, enlightenment, whatever.
Good luck, hopefully you'll end up liking Lisp.
TomSW
> (defun foo (foo)
> (foo foo))
>
> i could, if the Lisp IDE could do the same thing, press C-r over the
> first foo, enter bar, and the code would then look like this:
>
> (defun bar (foo)
> (bar foo))
>
> And not only in the same file, but Eclipse would ask to make the
> changes to any cllaer of foo anywhere in the source tree, and even in
> many kinds of configuration files.
> Same works for changing
> (foo (a b) (/ a b)) to (foo (b a) (/ a b)), as in also changing the
> order of parameters in all calls to foo.
nice.
> I think this is impossible in Lisp because of macro bodies and such,
> which is a thing I don't like about Lisp. Go on, sue me.
It's not impossible - in this situation you would be able to find the
macro callers of foo, and change the name and order of arguments
inside the macro. Then you'd have to recompile all the users of the
macro, which is annoying but I believe SLIME has a facility to make it
easier. Of course, it depends on the macro. For that matter, it's
simple to imagine a function that would defeat this kind of
refactoring:
(defun good-luck-with-that (state &rest args)
(let* ((fn-name (cookup-fn-name-from-state state))
(fn (symbol-function (intern fn-name))))
(apply fn args)))
Dynamic programming has its benefits too, though :)
> > Allegro's cross-referencing functions can be very useful for certain
> > kinds of code analysis, for example, detecting calls to undefined
> > functions, functions that are no longer called, etc.
>
> Is that the free version of Allegro IDE? Or just allegro lisp?
I don't know what you mean by "just allegro lisp" since the IDE and
the cross-reference functionality etc. come with the free version
(Allegro Express) and the full version.
I also suggest you take a step back and explore the new environment,
read the Allegro docs, get used to Emacs and SLIME, and then come back
with questions and gripes - if you want actual help, and not just some
mailing-list rough n tumble, that is.
Thomas A. Russ
Actually, this is somewhat backwards.
You don't use the parentheses for reading lisp (to a first
approximation), you use the indenting. The parentheses are there for
the compiler.
Suffice it to say that lisp users didn't find that type of additional
highlighting to be useful. Or else they would have added it. It's not
as if lisp programmers would be deterred by needing to use elisp.
So the syntax coloring tends to be what is generally considered useful
to experienced lisp programmers.
So, it isn't a real issue. And binding forms are a sufficiently
restricted set, so that it is easy to learn what they are. I mean, Java
IDEs don't highlight constructors different from methods, do they? Why
not, they're very different sorts of constructs. Same thing with lisp
values and function invocations.
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ
You are now being deliberately obstreperous.
> > And you don't really need additional highlighting to distinguish
> > functions and variables. Ž Functions can be detected by the "(" character
> > that is right in front of them. Ž Variables have white space in front of
> > them. Ž
>
> Except of course for quoted lists (unless within a macro body) or in
> (let ((let a)...
But quoted lists have this wonderful syntactic maker, namely the QUOTE.
So that is really a silly objection.
And if you can't properly parse a LET body, you should give up on Lisp
now. There aren't very many binding forms. And although one is allowed
to bind a variable called LET, if that is the sort of code you are
actually running into, then you should resign from the project now and
save yourself days of frustration.
So, how about giving some actual examples of what the problems you are
encoutering in the field are, rather than constructing hypothetical
"issues" that don't really arise in practice?
> Look, nobody *needs* syntax highlighting (unless somebody invented a
> prog lang with semantic colouring), but it makes reading any code in
> any language easier.
So does learning the language and the conventions for formatting and
reading that language.
A quick check of the Eclipse IDE for Java doesn't show any difference in
syntax coloring between variables, numeric constants, method calls or
array acceses. So obviously you don't need such cues there, right?
Maybe we need to let Kenny take over this thread. ;-p
Lew
> Good luck, hopefully you'll end up liking Lisp.
This is all horribly off topic for a Java newsgroup.
--
Lew
Thomas A. Russ
Followups and reply trimmed. Not really relevant to the java group,
unless the poster is trying to start a flame war. Which I am beginning
to suspect.
JavaLisper <nol...@mt2009.com> writes:
> > i don't quite understand why you needed to know the type in your task.
>
> It's not that I need it, it is that it makes things easier.
> Imagine this situation
> (let ((a (foo)))
> (bar a))
>
> where bar is a generic function having several methods for different
> classes of a.
> Then if foo always returns instances of a certain class, it would help
> me to know.
Well, the whole idea of organizing your methods around a generic
function is that the generic function of a given name is supposed to
only do one sort of thing.
So you should be able to tell what is going to happen (in general) to A
just by knowing that the BAR function is being called.
*** This is important, so pay attention ***
Methods belong to GENERIC FUNCTIONS. They DO NOT BELONG TO CLASSES!
This is a fundamental difference in the object models, and until you
grasp this difference, you will continue to struggle. So what you need
to find out is what the BAR function does. And it should do that to
anything that it is given.
And you have exactly the same problem in Java. The effective method
that gets called when you invoke a method in Java depends on the
specific class that the returned value has. So just because you know
the type returned by FOO, doesn't mean you know exactly which method is
being invoked because FOO can return any subclass of its return type.
*** That's the whole point of using methods. ***
> What's more, when dealing with a system somebody else wrote, I would
> in the above not know what classes foo or bar deal with. Assume now
> bar were a function, then just to find out what kind of values it is
> intended to work on, I'd have to read
> either foo or bar, and from there on recursively, until I find some
> cue.
And if you knew which class foo returned, you wouldn't have to read
anything, right? Of course not. You would still have to read things.
It is just that the programmign model is different. And you are still
fighting it rather than learning what it is.
Did I mention that methods belong to generic functions? So your
strategy for understanding the code has to be function-centric rather
than class-centric. This is a difference. You will have to adjust your
thinking to accomodate this difference. Or else you could just
reimplement the functionality of the lisp code from scratch in Java.
Perhaps that would be the easier route.
> As beautiful as Lip code may be, I actually like sometimes to skip
> reading functions, but lack of documentation and declaration forces me
> to waste my time reading code just to find out what kind of values it
> deals with.
You are focusing too much on the values it deals with and not enough on
what it DOES with them. Do you skip reading the method definitions in
Java class files because you already know what class you have?
> > For example, in java, you can declare a var of String type like this:
> >
> > String s1 = "someStr";
> >
> > But look yonder!! the syntax for string literal: “"someStr"”, already
> > unambiguously indicate a string type. So, why does the lang REQUIRE
> > the programer to put a “String” in front of s1?
>
> There is no need, but some reasons to still enforce this, but I guess
> this has been discussed in other places plenty of times.
>
> > In a ideal world, “type inference” doesn't need a name, and is simply
> > part of a well-designed language.
>
> What I'd like is that my IDE would tell me that in the following:
> (defun foo ()
> (bar))
>
> (defun bar ()
> '( a b c))
>
> that foo always returns a list.
But that isn't always possible in lisp. There is additional flexibility
that renders this somewhat difficult. Especially when you consider the
potentially dynamic behavior of lisp.
Consider instead:
(defmethod bar ()
'(a b c))
(defmethod bar :around ()
(if (today-is-tuesday-p)
"Tuesday's are special!"
(call-next-method)))
> What I mean is in emacs I press C-c C-C twice without changing the
> open
> file, the result may be different the second time, depending on the
> file.
Well, this is really bizarre.
Perhaps you could post a short example of a function that exhibits this
behavior?
> In Lisp, I would also enjoy if typing "(let" and some shortcut
> created (let ((| )) )
>
> And even better, if there was
> (foo (a b)...)
>
> where a and b where declared as Integer and String respectively, then
> typing
> (let ((a 3) (b "test"))
> (foo
>
> would automatically suggest a and b as next entries.
And what if FOO were a method that would work either way? Don't rely on
your IDE being a crutch that gets in the way of understanding what it is
that you are actually programming.
>
> My Emacs IDE has completion suggestions, but that also suggest plenty
> of words that exist but are not valid in the context. As an example
> in:
>
> (defun foo (a) (declare (type list a)) ...)
>
> (let ((test1 4) (test2 '(a b d))
> (foo tes|
>
> "|" indicating the cursor, I would like the IDE to only suggest test2
> not test1.
Why? Maybe you are in the middle of revising code and plan to next
change the signature of FOO to match your new view of how to organize
your program. Why would you want the IDE to force you to first change
FOO and then its call?
The whole point of lisp development environments is to make the
interaction more free, to allow a multi-pronged approach to
development. Coming from a more straight-jacket environment this new
found freedom may be a little frightening, but if you don't let your
fears overcome you, you will find the experience liberating.
Embrace the Lisp way!
Matthias
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
Kenneth Tilton
Didn't you learn anything in kindergarten? Just clap your hands over
your ears and go "whhooo! whoooo!". Not sure on the spelling, but that
should keep you from learning what a toad of a language you use.
hth,kenny
blue indigo
> Lew wrote:
>> TomSW wrote:
>>> Good luck, hopefully you'll end up liking Lisp.
>>
>> This is all horribly off topic for a Java newsgroup.
>
> Didn't you learn anything in kindergarten? Just clap your hands over
> your ears and go "whhooo! whoooo!". Not sure on the spelling
The spelling you're looking for is: pee ell oh en kay.
HTH, HAND.
--
blue indigo
UA Telecom since 1987
blue indigo
> blue indigo wrote:
>> Eh, what? This looks like it's from the middle of a thread, but there's no
>> attributions and I don't see any other posts in cljp from the same thread.
>
> Xah Lee likes to cross post to several groups with "discussion
> encouraging" content.
Oh, it was him that started this? I've had him plonked since oh, I don't
know, three or four years ago maybe.
It explains a great deal, though.
Asgeir
> JavaLisper ha scritto:
>> i have several years of Java experience, but now my new job requires
>> me to learn Lisp...
>
> Would Clojure be of any help to you?
>
> http://clojure.org/
>
Nobody wants to write a « Clojure considered Harmfull » ?
--
Asgeir
TomSW
>
> Nobody wants to write a « Clojure considered Harmfull » ?
Someone should. Clojure looks very interesting and useful and it would
be helpful if someone could explain in a sane way what the problem is.
Zach Beane
> Suffice it to say that lisp users didn't find that type of additional
> highlighting to be useful. Or else they would have added it. It's not
> as if lisp programmers would be deterred by needing to use elisp.
Until SLIME came along, there were many useful things that could be
added to ILISP but people just didn't do it.
Useful things don't just inevitably happen; it takes imagination and
energy and individual effort.
Zach
Jon Harrop
> On Jan 28, 11:20 pm, JavaLisper <nol...@mt2009.com> wrote:
>> Hi,
>> i have several years of Java experience, but now my new job requires
>> me to learn Lisp.
>
Do you also believe that Yahoo and Sony are secretly making extensive use of
Lisp behind closed doors?
Kaz Kylheku
> TomSW wrote:
>
>> If you did the same thing in Java, wouldn't you also end up using
>> search & replace?
>
> tools:
Refactoring is the Java term for doing work.
Pascal Costanza
LOL
Actually invented by Smalltalkers, but still makes sense... ;)
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
William James
> On 29 Gen, 13:33, Adde <a...@trialcode.com> wrote:
> > On Jan 29, 3:34 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> > [Lisp is evil]
>
> Jon Harrop would like to be The Lisp Satan, too bad that he doesn't
> have any Lisp experience, which would be the first requirement for
> this Job...
Religious fanaticism.
Slobodan Blazeski
cheers
bobi
Slobodan Blazeski
> Slobodan Blazeski wrote:
> > On Jan 28, 11:20 pm, JavaLisper <nol...@mt2009.com> wrote:
> >> Hi,
> >> i have several years of Java experience, but now my new job requires
> >> me to learn Lisp.
>
> > I believe that your story is fabricated...
>
> Do you also believe that Yahoo and Sony are secretly making extensive use of
> Lisp behind closed doors?
clear. Be careful with your multiple personalities or you might end up
insane.
Crazy frog that sounds famigliar
cheers
bobi
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy http://www.youtube.com/watch?v=be2AUvIZLtE
mark.p...@gmail.com
Dandelion (update site for adding in Eclipse's Software Updates
window: http://dandelion-ecl.sourceforge.net/update/ ), if you'd like
to work in a more familiar setting.
I'm just starting into Lisp from Java myself, so I can't speak to much
of the functionality (I'm up to arithmetic operators in my first
tutorial :-p).