Given that one could spend years with Lisp and never master it all,
what items and/or concepts would you say a Lisper needs to break
through to the next level? It seems it's one thing to become
comfortable with the language and be able to do in Lisp what can
already be done in some other language. At the other end of the
spectrum is the world of heavy macrology, advanced MOP, reader macros,
etc.
How would you define that middle ground, and what it takes to start
breaking through to the next level? What defines a Lisper as more
than a newbie dabbler, but far less than truly grokking the Lisp way?
And since many common software projects today are often just one-off
implementations of frequently solved problems (read: design patterns),
what problems provide the kind of challenge that requires more
advanced Lisp skills to solve? At least, to solve in a more elegant
Lisp-centric solution, that is, where those more advanced skills can
be acquired and developed?
jmckitrick wrote:
> what problems provide the kind of challenge that requires
> more advanced Lisp skills to solve? At least, to solve
> in a more elegant Lisp-centric solution, that is, where
> those more advanced skills can be acquired and developed?
I've been working on the puzzles at ITA Software:
http://www.itasoftware.com/careers/SolveThisWorkHerePuzzles.html?catid=114
You don't have to know about knowledge representation or other
areas of AI, but you need to have an excellent grasp of algorithms.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> jmckitrick wrote:
>
>> what problems provide the kind of challenge that requires
>> more advanced Lisp skills to solve? At least, to solve
>> in a more elegant Lisp-centric solution, that is, where
>> those more advanced skills can be acquired and developed?
>
>
> I've been working on the puzzles at ITA Software:
> http://www.itasoftware.com/careers/SolveThisWorkHerePuzzles.html?catid=114
>
> You don't have to know about knowledge representation or other
> areas of AI, but you need to have an excellent grasp of algorithms.
>
Not a bad idea, since those are engaging problems. That strawberry jobby
is very tempting, I'd love to burn a month on that. I just think it is
headed in the wrong direction, too small, too well-defined. The "next
level" is harnessing all that power to handle An Interesting Problem,
big and poorly defined. Bigger and poorlier as we go. This is not about
more skills and syntax and technique, it is about weilding them in
combat. Good example, actually. Book learnin only takes you so far, and
it ain't far. Get out there and rumble. I never get past chapter three
in a programming book -- once I have even the vaguest lay of the land I
have to start programming. Which suggests that The Real Problem is that
the OP does not have any code they want to write, by which I mean
application they want to create. It sounds like we have a conductor who
admires no symphonies, because no one who understands the instruments
and all the prerequisites to conducting has to ask what to do next. In
fact, could one rent orchestras by the hour, they would do so long
before they should, for in the end is that not why we are all here, to
make dumb computers do wonderful things? Have I lost everyone? I am.
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 25, 9:15 pm, Ken Tilton <···········@optonline.net> wrote:
> have to start programming. Which suggests that The Real Problem is that
> the OP does not have any code they want to write, by which I mean
> application they want to create. It sounds like we have a conductor who
> admires no symphonies, because no one who understands the instruments
> and all the prerequisites to conducting has to ask what to do next. In
Just to clarify, I *have* delivered a non-trivial CL app into a
professional production environment. It's a website and web app
that's running as we speak. It's sort of like a custom version of
surveymonkey.com that's specialized for developing personality and
corporate culture assessments. And I'm now porting parts of it into
php. Which led me to the point that nothing in this particular
problem couldn't have been solved by any other language. Thus my
question. For another current project I'm going the other direction.
It's been written and delivered in php, and I'm porting it (much more
succinctly) to sbcl and/or LispWorks. Not rocket science, but a heck
of a lot more fun in Lisp.
jmckitrick wrote:
> On Dec 25, 9:15 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>have to start programming. Which suggests that The Real Problem is that
>>the OP does not have any code they want to write, by which I mean
>>application they want to create. It sounds like we have a conductor who
>>admires no symphonies, because no one who understands the instruments
>>and all the prerequisites to conducting has to ask what to do next. In
>
>
> Just to clarify, I *have* delivered a non-trivial CL app into a
> professional production environment. It's a website and web app
> that's running as we speak. It's sort of like a custom version of
> surveymonkey.com that's specialized for developing personality and
> corporate culture assessments. And I'm now porting parts of it into
> php. Which led me to the point that nothing in this particular
> problem couldn't have been solved by any other language.
Not to quibble, but if the problem is not solved more easily with Lisp,
it /is/ trivial, or at least not what I meant by finding a suitable
symphony to perform. otoh, if you are handed twenty such trivialities
and create a tool to churn them out in minutes each -- even if the tool
generates PHP! -- then you have your symphony. And one thing we normally
see in business is folks who say KISS and just duplicate the code each
time and achieve productivity that way, changing just what needs to be
changed, which is great until word comes down to change X -- in all 42
of the damn things. In this case we have pilot error, duplicating the
Lisp 42 times when a metasolution was possible, and the pilot crawls out
of the wreckage saying "I should have used PHP".
Another problem here is the presumption that one will find one's
symphony in the workplace. It can happen, but in a body shop it will not
unless is given a free rein to find a better way. This is where that fun
hobby project one has always wanted to tackle comes into play.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 26, 10:21 am, Ken Tilton <···········@optonline.net> wrote:
> Not to quibble, but if the problem is not solved more easily with Lisp,
> it /is/ trivial, or at least not what I meant by finding a suitable
> symphony to perform. otoh, if you are handed twenty such trivialities
Not to quibble about quibbling, but there is no question the Lisp
solutions *are* more succinct, flexible, and powerful. The solutions
simply did not require language features unique to Lisp.
Sort of like how crawling from the wreckage of an F/A-18 is
subjectively better than crawling from the wreckage of a single-engine
Cessna 150. The answer to the pilot's "wow, did you *see* that?"
would probably be more exciting for the F/A-18 than the Cessna.
On Dec 26, 2:30 am, Dan Bensen <··········@cyberspace.net> wrote:
> jmckitrick wrote:
> > what problems provide the kind of challenge that requires
> > more advanced Lisp skills to solve? At least, to solve
> > in a more elegant Lisp-centric solution, that is, where
> > those more advanced skills can be acquired and developed?
>
> I've been working on the puzzles at ITA Software:http://www.itasoftware.com/careers/SolveThisWorkHerePuzzles.html?cati...
>
> You don't have to know about knowledge representation or other
> areas of AI, but you need to have an excellent grasp of algorithms.
>
> --
> Danwww.prairienet.org/~dsb/
Thanks for mentioning them, sometimes I really need some distraction.
In order to return the favour heres' some more puzzles:
http://www.streamtech.nl/site/problem+set
cheers
Slobodan
> On Dec 26, 2:30 am, Dan Bensen <··········@cyberspace.net> wrote:
>> I've been working on the puzzles at ITA Software:http://www.itasoftware.com/careers/SolveThisWorkHerePuzzles.html?cati...
Slobodan Blazeski wrote:
> In order to return the favour heres' some more puzzles:
> http://www.streamtech.nl/site/problem+set
Cool! Thanks a lot :)
jmckitrick wrote:
> At least, to solve in a more elegant
> Lisp-centric solution, that is, where those more advanced skills can
> be acquired and developed?
I think the problem isn't so much the language or the complexity of the
problems to solve but where to get programmers that can actually handle
a language like Lisp. As long as the industry prefers cheap, replacable
programmers, preferrably working in some low-wage country, there's
little hope.
On Tue, 25 Dec 2007 21:14:29 +0100, Matthias Buelow wrote:
> I think the problem isn't so much the language or the complexity of the
> problems to solve but where to get programmers that can actually handle
> a language like Lisp. As long as the industry prefers cheap, replacable
> programmers, preferrably working in some low-wage country, there's
> little hope.
That sounds just fine to Mr. Capitalist's ears. This will be true in any
industry, so long as the job is getting done.
--
Sohail Somani
http://uint32t.blogspot.com
Sohail Somani wrote:
> That sounds just fine to Mr. Capitalist's ears. This will be true in any
> industry, so long as the job is getting done.
The problem is, with this kind of attitude we get the kind of crappy
software that we see today everywhere. Which imho costs the economy as a
whole a lot more than if more sensible investment into and planning of
development resources would be made. Of course most of today's large
companies don't look any farther than the next quarterly figures and a
good long-term strategy that might however result in lower short-term
profits is shied away from (or not even recognized in the first place).
Matthias Buelow <···@incubus.de> writes:
> Sohail Somani wrote:
>
>> That sounds just fine to Mr. Capitalist's ears. This will be true in any
>> industry, so long as the job is getting done.
>
> The problem is, with this kind of attitude we get the kind of crappy
> software that we see today everywhere. Which imho costs the economy as a
> whole a lot more than if more sensible investment into and planning of
> development resources would be made. Of course most of today's large
> companies don't look any farther than the next quarterly figures and a
> good long-term strategy that might however result in lower short-term
> profits is shied away from (or not even recognized in the first place).
On the other hand, there are every days more and more millionairs, so
there could be a niche market for high quality software, like there
might be for high quality hardware. Lisp N�5, Logiciel de Luxe. ;-)
Now, what kind of program do these millionairs want?
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Now, what kind of program do these millionairs want?
Either something completely useless but shiny, or something that makes
them more money. Hmm... If programming could be elevated to a recognized
art form, we could have /patrons/...
Matthias Buelow <···@incubus.de> writes:
> Pascal J. Bourguignon wrote:
>
>> Now, what kind of program do these millionairs want?
>
> Either something completely useless but shiny,
Hey, butt out. I have the Lisp-powered-useless-but-shiny market
cornered at http://wigflip.com/ .
Zach
Zach Beane <····@xach.com> writes:
> Matthias Buelow <···@incubus.de> writes:
>
>> Pascal J. Bourguignon wrote:
>>
>>> Now, what kind of program do these millionairs want?
>>
>> Either something completely useless but shiny,
>
> Hey, butt out. I have the Lisp-powered-useless-but-shiny market
> cornered at http://wigflip.com/ .
And we're trying hard to take over the market for software helping
them make even more money. (http://www.netfonds.no/manual_pt_eng.php)
...Peder...
--
This must be Thursday. I never could get the hang of Thursdays.
On Dec 27, 10:46 am, ·····@news.klingenberg.no (Peder O. Klingenberg)
wrote:
> Zach Beane <····@xach.com> writes:
> > Matthias Buelow <····@incubus.de> writes:
>
> >> Pascal J. Bourguignon wrote:
>
> >>> Now, what kind of program do these millionairs want?
>
> >> Either something completely useless but shiny,
>
> > Hey, butt out. I have the Lisp-powered-useless-but-shiny market
> > cornered athttp://wigflip.com/.
>
> And we're trying hard to take over the market for software helping
> them make even more money. (http://www.netfonds.no/manual_pt_eng.php)
>
> ...Peder...
> --
> This must be Thursday. I never could get the hang of Thursdays.
Nice app I've use it in my presentation. If you make your site lisp
based instead of that ugly .php
please letr me know where I could buy a poster with you.
Slobodan
Slobodan Blazeski <·················@gmail.com> writes:
> Nice app I've use it in my presentation.
Thanks! (But I can't really take any credit for PrimeTrader as such,
I've never touched that code. It's just that PT is the only user
visible app we have.)
> If you make your site lisp based instead of that ugly .php please
> letr me know where I could buy a poster with you.
Yeah, well, that's not likely in the near future, sorry. The system
for managing the web pages actually predates most of the lisp
web-frameworks by quite a bit, and the pages do their job adequately,
so there's no incentive to switch from PHP. The php code is gradually
being simplified, though. Initially, quite a bit of logic was
embedded in the php. That is slowly changing to lisp based
middleware-servers. Thankfully.
We are currently betatesting a new application for mobile devices,
based on Hunchentoot. Our current offering for handhelds has the
unfortunate characteristic of not working on phones made in the last
3-4 years, despite being written in this wonderful language that
promised "write once, run anywhere". None of us really want to touch
that code either. Modern phones have quite capable web browsers, so
we take advantage of them instead of messing with Java ME. Web
browsers, of course, bring their own exciting incompatibilities, but
at least the application code will be bearable to look at.
...Peder...
--
This must be Thursday. I never could get the hang of Thursdays.
On Thu, 27 Dec 2007 10:46:40 +0100, Peder O. Klingenberg wrote:
> And we're trying hard to take over the market for software helping them
> make even more money. (http://www.netfonds.no/manual_pt_eng.php)
LispWorks?
--
Sohail Somani
http://uint32t.blogspot.com
Sohail Somani <······@taggedtype.net> writes:
> On Thu, 27 Dec 2007 10:46:40 +0100, Peder O. Klingenberg wrote:
>
>> And we're trying hard to take over the market for software helping them
>> make even more money. (http://www.netfonds.no/manual_pt_eng.php)
>
> LispWorks?
Yes.
...Peder...
--
This must be Thursday. I never could get the hang of Thursdays.
In article <··············@beto.netfonds.no>,
·····@news.klingenberg.no (Peder O. Klingenberg) wrote:
> Zach Beane <····@xach.com> writes:
>
> > Matthias Buelow <···@incubus.de> writes:
> >
> >> Pascal J. Bourguignon wrote:
> >>
> >>> Now, what kind of program do these millionairs want?
> >>
> >> Either something completely useless but shiny,
> >
> > Hey, butt out. I have the Lisp-powered-useless-but-shiny market
> > cornered at http://wigflip.com/ .
>
> And we're trying hard to take over the market for software helping
> them make even more money. (http://www.netfonds.no/manual_pt_eng.php)
>
> ...Peder...
That is impossible!
We all know that you can't develop 'applications' in Lisp
and sell them on Linux, Windows AND Mac OS X.
Your application simply can't exist. ;-)
http://www.lispworks.com/success-stories/netfonds-primetrader.html
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> writes:
> That is impossible!
>
> We all know that you can't develop 'applications' in Lisp
> and sell them on Linux, Windows AND Mac OS X.
And we do nothing to dispell that myth, as we don't actually sell
PrimeTrader. It's a free download :)
...Peder...
--
This must be Thursday. I never could get the hang of Thursdays.
In article <··············@beto.netfonds.no>,
·····@news.klingenberg.no (Peder O. Klingenberg) wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > That is impossible!
> >
> > We all know that you can't develop 'applications' in Lisp
> > and sell them on Linux, Windows AND Mac OS X.
>
> And we do nothing to dispell that myth, as we don't actually sell
> PrimeTrader. It's a free download :)
That must be an error in the Matrix. ;-)
>
> ...Peder...
--
http://lispm.dyndns.org/
On Wed, 26 Dec 2007 13:18:39 +0100, Matthias Buelow wrote:
>> That sounds just fine to Mr. Capitalist's ears. This will be true in
>> any industry, so long as the job is getting done.
>
> The problem is, with this kind of attitude we get the kind of crappy
> software that we see today everywhere. Which imho costs the economy as a
> whole a lot more than if more sensible investment into and planning of
> development resources would be made. Of course most of today's large
> companies don't look any farther than the next quarterly figures and a
> good long-term strategy that might however result in lower short-term
> profits is shied away from (or not even recognized in the first place).
Exactly. That is the attitude that needs to change for anything else to
change. There is something to be said for the status-quo: Zzzz... :-)
--
Sohail Somani
http://uint32t.blogspot.com
In article
<····································@x29g2000prg.googlegroups.com>,
jmckitrick <···········@yahoo.com> wrote:
> Given that one could spend years with Lisp and never master it all,
> what items and/or concepts would you say a Lisper needs to break
> through to the next level? It seems it's one thing to become
> comfortable with the language and be able to do in Lisp what can
> already be done in some other language. At the other end of the
> spectrum is the world of heavy macrology, advanced MOP, reader macros,
> etc.
>
> How would you define that middle ground, and what it takes to start
> breaking through to the next level? What defines a Lisper as more
> than a newbie dabbler, but far less than truly grokking the Lisp way?
You would have a decent development environment with the necessary
libraries installed. You would be able to customize it for
your purposes. The environment is no longer a baggage, but
actually supporting you for software development tasks.
You understand everything that Pitman & Norvig have written
here about Lisp style (in their tuotrial):
http://lispm.dyndns.org/documentation/norvig-lisp-style.pdf
Good understanding of Macros. "On Lisp" read once or twice.
http://www.paulgraham.com/onlisp.html
> And since many common software projects today are often just one-off
> implementations of frequently solved problems (read: design patterns),
> what problems provide the kind of challenge that requires more
> advanced Lisp skills to solve? At least, to solve in a more elegant
> Lisp-centric solution, that is, where those more advanced skills can
> be acquired and developed?
There is nothing better like hacking code. Real code.
if you don't want to program web pages ;-) here are some ideas:
* any kind of tool that integrates with McCLIM
* a 'natural language' interface to your development environment
Command: List all functions from Robert that have been changed in the
last two weeks
Command: List all classes with a slot named "TIME"
* develop a SPAM filter for Emacs or HTTP POST operations
* develop a language for controlling animated objects
See the 'Open Agent Engine' for Clozure CL :
http://homepage.mac.com/bfulgham/FileSharing2.html
* write a compiler that compiles image processing scripts
into efficient code
* extend Movitz with a better graphics driver and a simple window
system. Alternatively implement a disk driver .
http://common-lisp.net/project/movitz/
--
http://lispm.dyndns.org/
There has been a lot of excellent advice on this thread; nearly
everything I was going to recommend has already been recommended,
especially "On Lisp". One little thing I'll add:
Rainer Joswig wrote:
> There is nothing better like hacking code. Real code.
And also, reading code. Find very well-written Lisp code
(you'll have to judge that) and study it carefully.
From: Paul Tarvydas
Subject: Re: Breaking through to the next level
Date:
Message-ID: <fksn19$91c$1@aioe.org>
jmckitrick wrote:
> Given that one could spend years with Lisp and never master it all,
> what items and/or concepts would you say a Lisper needs to break
> through to the next level?
There are only about two underlying concepts in Lisp. Everything else
(incl. Common Lisp) flows from these concepts. I was utterly befuddled by
Lisp in university, until these two concepts clicked in my mind.
1) Everything is either a list or an atom.
2) Lisp provides operations on lists and operations on atoms.
You mention macros. Let's take macros as an example...
A lisp program is a list (point 1 - everything is a list or an atom, and
that includes programs).
Now, because Lisp programs are lists, Lisp's operators can operate on
programs. You can use the full power of the language to create/change Lisp
programs (aka "lists").
That's about all there is to say about macros.
You can write books about Lisp macros, but they are nothing more
than "looky-here at this amazing algorithm/pattern I've developed" in
flavour.
A convention emerged over time. When you treat a list as a program, the CAR
of the list is the function and the REST of the list are arguments to the
function. Macros allow you to change that convention by interpreting
specific units of the list in different ways (e.g. "loop").
A Lisp system is very much like an interactive compiler.
When you READ a list, the atoms are tokenized and converted into symbols
(typically stored in a hash table, which in the old days used to be an
OBLIST). This is the same as a "scanner" in compiler technology.
When you interpret the symbols within a list - e.g. the CAR is a function
and the REST of the list are arguments - you have built a "parser"
(and "semantic analysis" and "interpreter" / "coder" phases).
Lispers maintain this simple convention - the CAR is the function, the REST
is the argument list - because it is easy to parse and to interpret. And,
it fits neatly with the "everything is a list" paradigm. You don't need
YACC to parse Lisp expressions - you can build simple parsers without any
fuss if you stick with the simple convention. Lisp is like a language that
comes with LEX and YACC built into it. Lisp COULD have a more complex
syntax, but it appears that lispers don't care to bother with syntactic
sugar - they are happy to live with a simple syntax that can be simply
parsed by simple list operators.
That's all there is to Lisp. Everything else is just nuance...
pt
In article <············@aioe.org>,
Paul Tarvydas <········@visualframeworksinc.com> wrote:
> jmckitrick wrote:
>
> > Given that one could spend years with Lisp and never master it all,
> > what items and/or concepts would you say a Lisper needs to break
> > through to the next level?
>
> There are only about two underlying concepts in Lisp. Everything else
> (incl. Common Lisp) flows from these concepts. I was utterly befuddled by
> Lisp in university, until these two concepts clicked in my mind.
>
> 1) Everything is either a list or an atom.
>
> 2) Lisp provides operations on lists and operations on atoms.
There you see the differences in education.
I learned:
1) Everything is a function
2) Even data (numbers, ...) can be built out of functions
>
> You mention macros. Let's take macros as an example...
>
> A lisp program is a list (point 1 - everything is a list or an atom, and
> that includes programs).
>
> Now, because Lisp programs are lists, Lisp's operators can operate on
> programs. You can use the full power of the language to create/change Lisp
> programs (aka "lists").
>
> That's about all there is to say about macros.
>
> You can write books about Lisp macros, but they are nothing more
> than "looky-here at this amazing algorithm/pattern I've developed" in
> flavour.
>
> A convention emerged over time. When you treat a list as a program, the CAR
> of the list is the function and the REST of the list are arguments to the
> function. Macros allow you to change that convention by interpreting
> specific units of the list in different ways (e.g. "loop").
>
> A Lisp system is very much like an interactive compiler.
>
> When you READ a list, the atoms are tokenized and converted into symbols
> (typically stored in a hash table, which in the old days used to be an
> OBLIST). This is the same as a "scanner" in compiler technology.
>
> When you interpret the symbols within a list - e.g. the CAR is a function
> and the REST of the list are arguments - you have built a "parser"
> (and "semantic analysis" and "interpreter" / "coder" phases).
>
> Lispers maintain this simple convention - the CAR is the function, the REST
> is the argument list - because it is easy to parse and to interpret. And,
> it fits neatly with the "everything is a list" paradigm. You don't need
> YACC to parse Lisp expressions - you can build simple parsers without any
> fuss if you stick with the simple convention. Lisp is like a language that
> comes with LEX and YACC built into it. Lisp COULD have a more complex
> syntax, but it appears that lispers don't care to bother with syntactic
> sugar - they are happy to live with a simple syntax that can be simply
> parsed by simple list operators.
>
> That's all there is to Lisp. Everything else is just nuance...
>
> pt
--
http://lispm.dyndns.org/
From: Paul Tarvydas
Subject: Re: Breaking through to the next level
Date:
Message-ID: <fku1ct$5i9$1@aioe.org>
Rainer Joswig wrote:
> In article <············@aioe.org>,
> Paul Tarvydas <········@visualframeworksinc.com> wrote:
>
>> jmckitrick wrote:
>>
>> > Given that one could spend years with Lisp and never master it all,
>> > what items and/or concepts would you say a Lisper needs to break
>> > through to the next level?
>>
>> There are only about two underlying concepts in Lisp. Everything else
>> (incl. Common Lisp) flows from these concepts. I was utterly befuddled
>> by Lisp in university, until these two concepts clicked in my mind.
>>
>> 1) Everything is either a list or an atom.
>>
>> 2) Lisp provides operations on lists and operations on atoms.
>
> There you see the differences in education.
>
> I learned:
>
> 1) Everything is a function
>
> 2) Even data (numbers, ...) can be built out of functions
:-)
I learned LISP from Let's Talk Lisp and by porting Fritz van der Wateren's
LISP for the 6800 (DDJOCCAO, Sept. 1979) to a Z80 (it grew from 4K[sic] in
size to 5K[sic] in size).
pt
From: Joost Diepenmaat
Subject: Re: Breaking through to the next level
Date:
Message-ID: <87myrybbbl.fsf@zeekat.nl>
jmckitrick <···········@yahoo.com> writes:
> Given that one could spend years with Lisp and never master it all,
> what items and/or concepts would you say a Lisper needs to break
> through to the next level? It seems it's one thing to become
> comfortable with the language and be able to do in Lisp what can
> already be done in some other language. At the other end of the
> spectrum is the world of heavy macrology, advanced MOP, reader macros,
> etc.
>
> How would you define that middle ground, and what it takes to start
> breaking through to the next level? What defines a Lisper as more
> than a newbie dabbler, but far less than truly grokking the Lisp way?
I really don't know what level you're at, and I'm considering myself
very much a Lisp newbie, but I've just got my hands on the "Lisp in Small
Pieces" book, (I'm half-way through chapter 2) and it looks very
interesting if you're interested in the technology behind lisp.
http://pagesperso-systeme.lip6.fr/Christian.Queinnec/WWW/LiSP.html
Paul Graham's "On lisp" (there's a PDF on his site) is also definitely
interesting.
http://www.paulgraham.com/onlisp.html
As a reasonably experienced programmer in some other languages, I'd say
the best way to break through your "comfort zone" and really get
better is to try as many different programming paradigms as you can get
your hands on. If need be, try another language. That's how I ended up
trying Lisp anyway.
Joost.
From: Raymond Wiker
Subject: Re: Breaking through to the next level
Date:
Message-ID: <m2abnxi2ld.fsf@RawMBP.lan>
jmckitrick <···········@yahoo.com> writes:
> Given that one could spend years with Lisp and never master it all,
> what items and/or concepts would you say a Lisper needs to break
> through to the next level? It seems it's one thing to become
> comfortable with the language and be able to do in Lisp what can
> already be done in some other language. At the other end of the
> spectrum is the world of heavy macrology, advanced MOP, reader macros,
> etc.
>
> How would you define that middle ground, and what it takes to start
> breaking through to the next level? What defines a Lisper as more
> than a newbie dabbler, but far less than truly grokking the Lisp way?
>
> And since many common software projects today are often just one-off
> implementations of frequently solved problems (read: design patterns),
> what problems provide the kind of challenge that requires more
> advanced Lisp skills to solve? At least, to solve in a more elegant
> Lisp-centric solution, that is, where those more advanced skills can
> be acquired and developed?
I recently discovered projecteuler.net - this site has a
number of set problems, ranging from trivial to fairly difficult (at
least way over *my* head). I started doing some of these, and found
them a good way of improving my loop-fu. There are also problems that
highlight the strengths of Lisp in other ways - they won't help you
learn about those strengths, but may be a good way to improve your
skills in applying them.