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.
Bryan Glennon <bryan-No-S...@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:
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.
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?
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 :)
Bryan Glennon <bryan-No-S...@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:
(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.
> 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 :)
Bryan Glennon <bryan-No-S...@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
Dave Roberts <dave-rem...@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.
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:
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 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.
> 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 <bryan-No-S...@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.
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.
