Hi -
I've been trying to learn Lisp, since everyone who knows it or
writes about it seems to think it's the best thing since sliced bread.
And from what I have seen and done, I can tell it's a rich, expressive
language.
My problem is that I have 20+ years experience coding in other
languages (C, C++, Java, C#), so when I get about halfway into anything
of substance, I wind up saying something like "this would be so much
easier in [previously mastered language here]" and getting frustrated.
So I'm looking for problem suggestions that do *not* lend themselves
to easy solutions in languages other than Lisp.
Any ideas would be appreciated.
Thanks,
Bryan
Bryan Glennon <·············@bpgc.com> writes:
> Hi -
> I've been trying to learn Lisp, since everyone who knows it or
> writes about it seems to think it's the best thing since sliced
> bread. And from what I have seen and done, I can tell it's a rich,
> expressive language.
>
> My problem is that I have 20+ years experience coding in other
> languages (C, C++, Java, C#), so when I get about halfway into
> anything of substance, I wind up saying something like "this would
> be so much easier in [previously mastered language here]" and
> getting frustrated.
>
> So I'm looking for problem suggestions that do *not* lend themselves
> to easy solutions in languages other than Lisp.
You might want to check out my book, soon to be published by Apress,
currently avaialable on the web in draft form at:
<http://www.gigamonkeys.com/book/>
It gives, I think, several reasonable examples of non-trivial programs
in Common Lisp. Of course if you're a wizard in some other langugae
I'm sure you can think of a way to do them in that language but I
think they show Common Lisp's strengths to good advantage.
-Peter
P.S. I was a serious Java programmer for about as long as one can have
been a Java programmer before writing this book and some of the
examples are of things that I had written previously in Java. At least
in my experience the obvious Common Lisp solution was way better than
the best Java solutions I was ever able to come up with.
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Bryan Glennon wrote:
> Hi -
> I've been trying to learn Lisp, since everyone who knows it or
> writes about it seems to think it's the best thing since sliced bread.
> And from what I have seen and done, I can tell it's a rich, expressive
> language.
>
> My problem is that I have 20+ years experience coding in other
> languages (C, C++, Java, C#), so when I get about halfway into anything
> of substance, I wind up saying something like "this would be so much
> easier in [previously mastered language here]" and getting frustrated.
>
Well Lisp is about 50 years old. What do you think that means?
Why the interest in Lisp?
Wade
Bryan Glennon <·············@bpgc.com> writes:
> My problem is that I have 20+ years experience coding in other
> languages (C, C++, Java, C#), so when I get about halfway into anything
> of substance, I wind up saying something like "this would be so much
> easier in [previously mastered language here]" and getting frustrated.
I have found that's the case with every new language I have ever
learned. Just because you're finding it with Lisp doesn't mean that
Lisp won't ultimately be better for you. It's just that familiar
things are, well, more familiar.
Frankly, after 1 year of programming in Lisp, I now look at all other
languages and think, "This would be so much easier in Lisp. And what's
with the complicate syntax? Can't they just use something simple like
parenthesis?" ;-)
> So I'm looking for problem suggestions that do *not* lend themselves
> to easy solutions in languages other than Lisp.
You know what convinced me was recoding some things I had done
previously with Java in Lisp. Everybody can point you to some "toy"
applications where Lisp will simply kick-ass. But that isn't the
point. If you try Lisp versus something else on some of the other
programs you have written in the past, in application domains that you
know, I think you'll end up convincing yourself of Lisp's utility. I
did one such test myself. You can find the write-up with my results
at:
http://www.findinglisp.com/papers/case_study_java_lisp_dns.html
(Crap! As an aside, don't you hate it when you look back at something
you have written and proof-read a bunch of times and you still find
typos. I hate that. Okay, so ignore the typos.)
Note that this was done with only a couple of months of Lisp knowledge
under my belt, so you really don't have to be an expert. Pick
something meaty enough that you can make a fair comparison, but not so
large that you would have to spend weeks and weeks rewriting it in
Lisp. Then just start. Push through that phase of feeling like you're
incompetent in the new language. You will be for a while, but then
it'll start becoming easier. Then grade yourself.
---
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
Dave Roberts <···········@remove-findinglisp.com> writes:
> You know what convinced me was recoding some things I had done
> previously with Java in Lisp. Everybody can point you to some "toy"
> applications where Lisp will simply kick-ass. But that isn't the
> point. If you try Lisp versus something else on some of the other
> programs you have written in the past, in application domains that
> you know, I think you'll end up convincing yourself of Lisp's
> utility.
I strongly concur with that. A few years back I was playing around
with Lisp after having worked full time as a Java programmer for about
five years. I started reimplementing something I had written in Java
when I was first starting out in Java and that I had tried to redo in
Java a couple times since then as I became more experienced with Java.
Working in Common Lisp, even though I had to check the usage of almost
every standard function and macro in the HyperSpec, was still more fun
and more productive than doing the same thing in Java would have been.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Bryan Glennon wrote:
> I've been trying to learn Lisp, since everyone who knows it or
> writes about it seems to think it's the best thing since sliced
> bread. And from what I have seen and done, I can tell it's a rich,
> expressive language.
Welcome.
> My problem is that I have 20+ years experience coding in other
> languages (C, C++, Java, C#), so when I get about halfway into
> anything of substance, I wind up saying something like "this would be
> so much easier in [previously mastered language here]" and getting
> frustrated.
Most of the languages that you have used thus far are pretty much just
derivatives of C it would seem. Nothing wrong with that, except that's
why you probably picked them up so quickly. Lisp is very different than
what you are used to.
> So I'm looking for problem suggestions that do not lend
> themselves to easy solutions in languages other than Lisp.
Coming up with "toy" problems that are very easy in Lisp and not in
other languages is easy. All one needs to do is start using macros and
most languages fold quickly. But this would be unfair. You are so used
to the C world that you would quickly retort "but why would I want to
do that?" Much like an old BASIC programmer would ask what good
recursion is (example courtesy of PG, of course). It would be much
better for you to just give yourself a larger problem to solve and
solve it in Lisp. As you work out the details and learn more about the
language you will see the light :)
Jeff M.
--
http://www.retrobyte.org
··············@gmail.com
Bryan Glennon schrieb:
> Hi -
*******************************************************************
> I've been trying to learn Lisp, since everyone who knows it or
> writes about it seems to think it's the best thing since sliced bread.
> And from what I have seen and done, I can tell it's a rich, expressive
> language.
*******************************************************************
Listen to what a lisp newbie says after doing 20 years in other than
lisp.
> My problem is that I have 20+ years experience coding in other
> languages (C, C++, Java, C#), so when I get about halfway into anything
> of substance, I wind up saying something like "this would be so much
> easier in [previously mastered language here]" and getting frustrated.
Yes this is a problem. You may feel the prison of 20 years...
You deal with an interpreter. No compile necessary. You get the result
immediately. Best use for beginn is: play around with it, as much as you
like.
But keep in mind, as easy it looks, as stubborn it is. A single ' will
make a different world and so does a , too. Means a deep look into the
documents is always a big "aha", even after years of lisp experience.
The lispy way is one of the oldest on byte machines and corresponding is
the stuff that have been collect over the time.
> So I'm looking for problem suggestions that do *not* lend themselves
> to easy solutions in languages other than Lisp.
There are more possible ways in lisp to reach the point. So, find your
style here. I am sure, you keep smiling about "other languages"...
(ohoh, pscht :)
lin
Bryan Glennon <·············@bpgc.com> writes:
>
> Hi -
> I've been trying to learn Lisp, since everyone who knows it or
> writes about it seems to think it's the best thing since sliced bread.
> And from what I have seen and done, I can tell it's a rich, expressive
> language.
>
> My problem is that I have 20+ years experience coding in other
> languages (C, C++, Java, C#), so when I get about halfway into anything
> of substance, I wind up saying something like "this would be so much
> easier in [previously mastered language here]" and getting frustrated.
>
> So I'm looking for problem suggestions that do *not* lend themselves
> to easy solutions in languages other than Lisp.
Write a symbolic calculus program that handles differentiation and
integration.
It was the first Lisp project I did, in my CS course right after writing
a simple desktop calculator in Algol. It was much simpler to do the
symbolic math in Lisp than to do the simple arithmetic in Algol.
As an example, you would want to be able to handle things like
(differentiate '(* 2 x y) 'x) => '(* 2 y)
(differentiate '(* 2 (expt x 3)) 'x) => '(* 6 (expt x 2))
etc.
--
Thomas A. Russ, USC/Information Sciences Institute
Bryan Glennon wrote:
> My problem is that I have 20+ years experience coding in other
> languages (C, C++, Java, C#), so when I get about halfway into
> anything of substance, I wind up saying something like "this would be
> so much easier in [previously mastered language here]" and getting
> frustrated.
It is certainly a problem, and has been for me, too.
Another way of looking at Lisp versus other languages is to examine the
relative number of opportunities for making mistakes, introducing bugs,
painting yourself into a corner from which the only way out is a lengthy
and painful refactoring, etcetera.
I think human nature is responsible for people looking back at their
coding careers with rose coloured glasses; remembering the great hacks
and the amazing all-weekend coding sessions, and forgetting the bad
bugs and 48 hour debugging sessions. As well, contemplate how many times
you've spent thirty seconds decoding a complex expression which
probably would have benefited from one or two more sets of parentheses
for human readability. It all adds up.
The above have been important considerations for me. I find that Lisp
languages reduce the opportunity for certain types of error which are
very common elsewhere.
Bryan Glennon <·············@bpgc.com> writes:
> I've been trying to learn Lisp, since everyone who knows it or
[...]
> My problem is that I have 20+ years experience coding in other
> languages (C, C++, Java, C#), so when I get about halfway into anything
> of substance, I wind up saying something like "this would be so much
> easier in [previously mastered language here]" and getting frustrated.
Any examples?
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Bryan Glennon wrote:
> My problem is that I have 20+ years experience coding in
> other languages (C, C++, Java, C#), so when I get about
> halfway into anything of substance, I wind up saying
> something like "this would be so much easier in
> [previously mastered language here]" and getting
> frustrated.
>
> So I'm looking for problem suggestions that do *not*
> lend themselves to easy solutions in languages other than
> Lisp.
Symbolic algebra is the obvious one. Just a week ago I
thought "Maybe the generic functions in CLOS offer a nice
way to organise such code?" and typed in:
(defmethod deriv ((form number) var) 0)
(defmethod deriv ((form symbol) var)
(if (eql form var) 1 0))
(defmethod deriv ((form cons) var)
(deriv-func (car form) (cdr form) var))
(defmethod deriv-func ((f (eql '+)) args var)
`(+ ,@(mapcar (lambda (arg)
(deriv arg var))
args)))
(defmethod deriv-func ((f (eql '*)) args var)
`(+ ,@(maplist (lambda (tail)
`(* ,@(ldiff args tail)
,(deriv (car tail) var)
,@(cdr tail)))
args)))
(defmethod deriv-func ((f (eql 'sin)) args var)
(assert (= (length args) 1))
`(* ,(deriv (car args) var) (cos ,(car args))))
I really ought to get Paradigms of Artificial Intelligence
Programming
http://www.norvig.com/paip.html
and read chapter 15 - Symbolic Mathematics with Canonical
Form, but it is fun to play with CLOS and I after I wrote
the beginnings of a simplifier,
(defun simplify (form)
(typecase form
(atom form)
(cons (simp-func (car form)
(mapcar (function simplify)
(cdr form))))))
etc etc ...
Prompt> (deriv '(sin (* x x)) 'x)
=> (* (+ (* 1 X) (* X 1)) (COS (* X X)))
Prompt> (simplify *)
=> (* (COS (* X X)) (+ X X))
I realised that I could get DERIV to simplify as it went by
using an around method
(defmethod deriv :around ((form cons) var)
(simplify (call-next-method)))
So I can easily experiment with which simplifications to try
at various stages.
Ofcourse, one doesn't want
(+ -1 (* (+ 2 (sqrt 3))
(- 2 (sqrt 3)))) => 1.1920929e-7
so the next job might be to define some classes for
algebraic numbers, define some ADD methods,
(defmethod add ((x surd)(y surd)) ... )
and shadow
CL:+ with
(defun algebra:+ (&rest extended-numbers)
(reduce (function add) extended-numbers))
Also a read macro for typing in algebraic numbers.
Having a built-in type (complex rational) helps you get
started. Having multiple dispatch helps with defining the
add and multiply methods for the extended numbers. I'm
guessing that multiple inheritance will help with defining
the classes for the extended numbers.
Conclusion
----------
Pick symbolic algebra as a toy project to give a focus to
learning CL and there will be no haunting doubts about how
it might be easy in C, C++, Java, or C#, no matter how
skilled one was in those languages.
Alan Crowe
Common Lisp - putting the fun into function.
Bryan Glennon <·············@bpgc.com> writes:
> My problem is that I have 20+ years experience coding in other
> languages (C, C++, Java, C#), so when I get about halfway into anything
> of substance, I wind up saying something like "this would be so much
> easier in [previously mastered language here]" and getting frustrated.
Depending on how you measure time, I don't have quite 20 years in
other languages but I am in the same boat. But...
As my familiarity with Lisp grows (ANSI Common Lisp), I find that more
and more things become easier in Lisp than in other languages. Sure,
I'm taking my time gaining Lisp proficiency. I run into walls that
block my understanding for a time. But as I clear each hurdle, the
Lisp way gets easier.
So my suggestion is to just stick with it. Whatever your programming
domain, I am fairly confident that Lisp will prove more expressive
than other general purpose programming languages.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Bryan Glennon wrote:
> So I'm looking for problem suggestions that do *not* lend
> themselves to easy solutions in languages other than Lisp.
Something I would've liked hearing about before... Some will say that
Lisp represents a 100% change in thought. But I don't think that's true
in the sense they mean. Instead, Lisp is more about being a complete
tool. Pick a subject like errorhandling, numbers, iteration, OOP; and
you will see things pursued to their logical conclusions.
It's not about replacing what you know. But instead giving those
trained muscles a tool whose goal is to amplify that strength.
It wouldn't surprise me at all if those with deeper experience than me
can surpass my proficiency fairly quickly, since that experience is
amplified.
So when confronted with something like macros, it's nothing
particularly new. It's just about treating code as any other
datahandling issue. You can bring your entire knowledge to bear upon
manipulating code, just as you would bring it to bear on every other
thing you do with a machine.
MfG,
Tayssir
Thanks for all the suggestions and feedback.
Peter - Great book, sorry I can't think of a good tag line for you.
Dave - Nice case study. I would not have figured the differences would
be that great.
Now I'm diving in again - expect more requests for help :-)
Cheers,
Bryan
Check out here
http://www.dynamiclearningcenter.com/
and specifically here
http://www.dynamiclearningcenter.com/samples/ray-tracing/index.html
This is an exercise designed to teach a language in a more-usual
way than reading first principle out of a book: by hacking on and
improving a nontrivial, working program.