Home > Archive > Lisp > December 2007 > Breaking through to the next level
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Breaking through to the next level
|
|
| jmckitrick 2007-12-25, 7:13 pm |
| 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?
| |
| Matthias Buelow 2007-12-25, 7:13 pm |
| 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.
| |
| Rainer Joswig 2007-12-25, 7:13 pm |
| In article
<f2a47b92-a328-42eb-859c-eb99479926aa@x29g2000prg.googlegroups.com>,
jmckitrick <j_mckitrick@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/documentati...-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 w s
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/
| |
| Joost Diepenmaat 2007-12-25, 7:13 pm |
| jmckitrick <j_mckitrick@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/C...c/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.
| |
| Dan Bensen 2007-12-25, 10:13 pm |
| 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/....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/
| |
| Ken Tilton 2007-12-25, 10:13 pm |
|
Dan Bensen wrote:
> jmckitrick wrote:
>
>
>
> I've been working on the puzzles at ITA Software:
> http://www.itasoftware.com/careers/....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
| |
| Sohail Somani 2007-12-25, 10:13 pm |
| 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
| |
| Paul Tarvydas 2007-12-26, 4:26 am |
| 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
| |
| Rainer Joswig 2007-12-26, 4:26 am |
| In article <fksn19$91c$1@aioe.org>,
Paul Tarvydas <tarvydas@visualframeworksinc.com> wrote:
> jmckitrick wrote:
>
>
> 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/
| |
| Matthias Buelow 2007-12-26, 8:09 am |
| 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).
| |
| jmckitrick 2007-12-26, 7:11 pm |
| On Dec 25, 9:15=A0pm, Ken Tilton <kennytil...@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.
| |
| Pascal J. Bourguignon 2007-12-26, 7:11 pm |
| Matthias Buelow <mkb@incubus.de> writes:
> Sohail Somani wrote:
>
>
> 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__
| |
| Daniel Weinreb 2007-12-26, 7:11 pm |
| 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.
| |
| Ken Tilton 2007-12-26, 7:11 pm |
|
jmckitrick wrote:
> On Dec 25, 9:15 pm, Ken Tilton <kennytil...@optonline.net> wrote:
>
>
>
> 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
| |
| Paul Tarvydas 2007-12-26, 7:11 pm |
| Rainer Joswig wrote:
> In article <fksn19$91c$1@aioe.org>,
> Paul Tarvydas <tarvydas@visualframeworksinc.com> wrote:
>
>
> 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
| |
| Matthias Buelow 2007-12-26, 7:11 pm |
| 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/...
| |
| Zach Beane 2007-12-26, 7:11 pm |
| Matthias Buelow <mkb@incubus.de> writes:
> Pascal J. Bourguignon wrote:
>
>
> Either something completely useless but shiny,
Hey, butt out. I have the Lisp-powered-useless-but-shiny market
cornered at http://wigflip.com/ .
Zach
| |
| jmckitrick 2007-12-26, 7:11 pm |
| On Dec 26, 10:21=A0am, Ken Tilton <kennytil...@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.
| |
| Raymond Wiker 2007-12-26, 7:11 pm |
| jmckitrick <j_mckitrick@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.
| |
| Peder O. Klingenberg 2007-12-27, 4:26 am |
| Zach Beane <xach@xach.com> writes:
> Matthias Buelow <mkb@incubus.de> writes:
>
>
> 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.
| |
| Sohail Somani 2007-12-27, 4:26 am |
| On Wed, 26 Dec 2007 13:18:39 +0100, Matthias Buelow wrote:
>
> 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
| |
|
|
|
|
| Peder O. Klingenberg 2007-12-27, 8:09 am |
| Sohail Somani <sohail@taggedtype.net> writes:
> On Thu, 27 Dec 2007 10:46:40 +0100, Peder O. Klingenberg wrote:
>
>
> LispWorks?
Yes.
....Peder...
--
This must be Thursday. I never could get the hang of Thursdays.
| |
| Peder O. Klingenberg 2007-12-27, 8:09 am |
| Rainer Joswig <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.
| |
| Rainer Joswig 2007-12-27, 8:09 am |
| In article <ksejd8xw71.fsf@beto.netfonds.no>,
peder@news.klingenberg.no (Peder O. Klingenberg) wrote:
> Rainer Joswig <joswig@lisp.de> writes:
>
>
> 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/
| |
| Slobodan Blazeski 2007-12-27, 8:09 am |
| On Dec 26, 2:30 am, Dan Bensen <randomg...@cyberspace.net> wrote:
> jmckitrick wrote:
>
> I've been working on the puzzles at ITA Software:http://www.itasoftware.com/careers/...es.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
| |
| Slobodan Blazeski 2007-12-27, 8:09 am |
| On Dec 27, 10:46 am, pe...@news.klingenberg.no (Peder O. Klingenberg)
wrote:
> Zach Beane <x...@xach.com> writes:
>
>
>
>
>
> 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
| |
| Peder O. Klingenberg 2007-12-27, 8:09 am |
| Slobodan Blazeski <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.
| |
| Dan Bensen 2007-12-27, 10:11 pm |
| > On Dec 26, 2:30 am, Dan Bensen <randomg...@cyberspace.net> wrote:
Slobodan Blazeski wrote:[color=darkred]
> In order to return the favour heres' some more puzzles:
> http://www.streamtech.nl/site/problem+set
Cool! Thanks a lot :)
|
|
|
|
|