Can anyone suggest ideas for a project involving LISP?
I have to write one for a postgrad degree.
I was thinking about doing a CLOS representation of a chess game.
...any other ideas???
"Christopher Lindop" <·····@clindop.fsbusiness.co.uk> writes:
> Can anyone suggest ideas for a project involving LISP?
> I have to write one for a postgrad degree.
> I was thinking about doing a CLOS representation of a chess game.
> ...any other ideas???
For a degree in what subject area? Unless the degree is in
theoretical computer science, you're best off to pick a project area
that will serve you well on your resume later. IMO, picking chess is
unlikely to do this unless you're looking for a job as a teacher or a
chess master.
Also, I think you should only do chess if you have thoroughly surveyed
the chess literature (which I imagine to be large at this point) and
you think you have something new to contribute, either in terms of
thought or point of view. An "I did it too" project seems a waste.
You're going to be putting a real, measurable part of your life into a
project like this. Make it count. Some colleges don't require the
"new idea" or "new perspective" standard for some degrees, but I think
it is always helpful to try to bring this thought into play when
evaluating where to spend one's life. Do something that allows you to
contribute your strengths and to make an impact where no one has.
And much though I'm happy to see someone with a strong interest in
Lisp, I'm frankly skeptical of the notion of choosing a project to
match an implementation language rather than vice versa. I think
your subject area should make sense as a project independently of
your implementation language. That is, as a general rule,
"FOO in Lisp" is an interesting topic iff "FOO" is an interesting
topic. Taking an uninteresting project and putting it in Lisp does
not usually make it interesting. There are perhaps exceptions to be
made, but this is a case you'll have to make--not something that flows
naturally. Lisp will, in the end, probably be a fine language to do your
research in and I'm not trying to talk you out of that part--I'm just not
sure it needs to be in the title. e.g., "Web Server in Lisp" is not
any more interesting than "A Web Server". By contrast, "An Artificially
Intelligent Web Server" is an interesting topic, whether in Lisp or not,
and incidentally would be easier to do in Lisp.
On Mon, 30 Apr 2001 20:32:08 GMT, Kent M Pitman <······@world.std.com> wrote:
>"Christopher Lindop" <·····@clindop.fsbusiness.co.uk> writes:
>
>> Can anyone suggest ideas for a project involving LISP?
>> I have to write one for a postgrad degree.
>> I was thinking about doing a CLOS representation of a chess game.
>> ...any other ideas???
>
>For a degree in what subject area? Unless the degree is in
>theoretical computer science, you're best off to pick a project area
>that will serve you well on your resume later.
Although I'd recommend doing a project you're interested in over one which is
aimed solely at improving your resume. You stand much more chance of
completing the project successfully in my experience.
>And much though I'm happy to see someone with a strong interest in
>Lisp, I'm frankly skeptical of the notion of choosing a project to
>match an implementation language rather than vice versa.
He may be keen to get Lisp onto his resume, an extended project strikes me as
a good way of doing this.
Mark
····@scientia.com (Mark Dalgarno) writes:
> On Mon, 30 Apr 2001 20:32:08 GMT, Kent M Pitman <······@world.std.com> wrote:
>
> >"Christopher Lindop" <·····@clindop.fsbusiness.co.uk> writes:
> >
> >> Can anyone suggest ideas for a project involving LISP?
> >> I have to write one for a postgrad degree.
> >> I was thinking about doing a CLOS representation of a chess game.
> >> ...any other ideas???
> >
> >For a degree in what subject area? Unless the degree is in
> >theoretical computer science, you're best off to pick a project area
> >that will serve you well on your resume later.
>
> Although I'd recommend doing a project you're interested in over one which is
> aimed solely at improving your resume. You stand much more chance of
> completing the project successfully in my experience.
Perhaps I should have said "both", then.
Surely there are theoretical things that need researching and we need
grad students to do that research even if it's not "essential to business".
I just don't think "chess" is, at this point and as a general proposition,
one of them. A lot of work has been done on chess and the only work that
I recommend anyone doing at this point on it should be work where they
really have a strong believe not only that "chess is fun" but also that
"they have something to contribute to chess beyond what has already been
done". At this point, merely saying "wow, chess is cool and I want to
join the ranks of the cool" is, I think, both scientific and career suicide.
Maybe that's just me--and others who do hiring for companies should chime in
here to correct me if so--but if I saw a resume from the 70's and 80's doing
chess research, I might be impressed thinking (this is a "pioneer")
but if I saw one from nowadays looking at it, I'd look at it *very*
differently and much more skeptically, asking myself "does this person know
the first thing about anything he/she will need to do 'real work'".
These are issues that I fear students are not often instructed about
at the time they make thesis choices, and I think it leads students to
make bad choices. It's one of those things I keep saying about
wisdom: Just because there is a guideline (by me or anyone) doesn't
mean you can't break the guideline. But the wisdom part comes not in
following the guideline or ignoring the guideline, but in
understanding the reason for the guideline and then making your
ultimate choice in the face of the knowledge of the personal and
professional consequences of having held to or violated a guideline.
Wise people aren't people who follow dogma from me or anyone; they are
people who either follow guidelines by those with more experience
until they reach a point of deep understanding of the reasons for
those guidelines, or who have achieved a deep understanding of the
reasons for the guidelines sufficient to understand the reasons for
them, and then make whatever choice seems appropriate to them in the
face of that deep understanding of those same reasons.
It is no small chip on my shoulder that for all MIT (where I went to
school as an undergrad) touts itself and is touted by others as a way
to prepare you for what's out there, it pretty much wholly overlooked
all manner of practical advice like the stuff I'm dispensing here when
it put me through school. It taught us tons of theory, but little
about the practical application of that theory, often claiming "we'll
pick that up on our own without prodding". But I'm not so sure that's
the best way. I'm much more impressed with some other schools
(Stanford and Northeastern strike me as examples) that don't treat
"business stuff" as of secondary importance. These things end up
mattering and can really make or break careers. Students have a right
to know how they are and will be perceived, not to just assume that
theoretical might and grades are all that will be looked at. And
often I think this is what they (especially MIT people) come out
believing.
> >And much though I'm happy to see someone with a strong interest in
> >Lisp, I'm frankly skeptical of the notion of choosing a project to
> >match an implementation language rather than vice versa.
>
> He may be keen to get Lisp onto his resume,
Easily achieved.
Languages: Lisp
Add phrases like "well-versed in" or "strong background in" or "many
years of experience in" as appropriate. Requires no project. Job
interviewers will probe the details as needed. But it doesn't need to
be in the title of any paper you've written or project youv'e done to
make it true and useful on the resume.
And resumes are not required to show the actual topic of a project area
or report. You can certainly write ``A report entitled "..."''' but you
can just as easily write ``A report about ...'' without mentioning the
title, and you can make such a custom resume for anyone who wants to see
a Lisp bias. But wiring Lisp into the title has consequences beyond
resume writing--it means anyone who requests the actual title sees this
bias wired in, and it further means that the literature community and
conference committees to which you submit your work will see this bias
(and either appreciate it or not). Every time anyone invents a language
or implementation, we see slews of papers that we saw the previous year as
"blah blah" being recast as "blah blah in FooLog". That doesn't mean this
is 100% a bad idea, but what I'm trying to do is to alert a newbie in the
community to the fact that this is not perceived universally as a mitzvah
(as a "good thing"--hope I spelled it right). Some people instantly recognize
the pattern "x in FooLog" as "I'm having trouble coming up with something
novel so I'm rehashing something that's not in a new coat" and I think
it's worth knowing before you start that this can easily impede your
project's success.
There is always a chance for any worthwhile paper that it will succeed
in spite of itself, but I think that piece of information is virtually
useless to the aspiring paper writer because it is "not constructive"
(by which I do not mean "is not worded in a friendly way", as many
people mean by "constructive", bur rather by which I mean "is not
worded in such a way as to allow the hearer to make an immediate,
material improvement"). Lots of people think saying "Yes, that can work."
is constructive because it sounds friendly, but I claim that it really
offers nothing. Telling the person a pitfall to avoid or an issue to be
sure they've checked off their checklist seems more constructive to me,
and this is what I have tried to do here.
> an extended project strikes me as a good way of doing this.
An extended project is a fine way of acquiring Lisp skills.
My points were two:
- the worth of the project is not enhancd by putting "in Lisp" at the
end of the title. the title had better still sound worthwhile without
those two words there.
- it's better to choose a topic first and then see if Lisp will suit it.
HOPEFULLY (for us in the Lisp community), Lisp is a general purpose
language and will suit the need anyway. But given that "in Lisp" is not
the valuable part, I think the right thing is to find the project you
really want to do and THEN to choose a language. If it turns out, in
the end, that Lisp can't handle the project, I'd be very interested
to hear about why... But if Lisp can (as some of us think) handle just
about any project anyway, how does it help to "look for a project you
can do in Lisp" given that (applying the first of my two points), this
is the same as "look for a project you can do" (removing the "in Lisp")?
Kent M Pitman <······@world.std.com> writes:
> Maybe that's just me--and others who do hiring for companies should chime in
> here to correct me if so--but if I saw a resume from the 70's and 80's doing
> chess research, I might be impressed thinking (this is a "pioneer")
> but if I saw one from nowadays looking at it, I'd look at it *very*
> differently and much more skeptically, asking myself "does this person know
> the first thing about anything he/she will need to do 'real work'".
I think that's right. It would have to be `some unusual & interesting
approach to playing chess'. And actually, even there I'd worry
because you need to assume that whoever is looking at the CV knows
that this is interesting, rather than just knowing that chess is
sort-of a solved problem.
Actually, I guess, something like `a program that plays go reasonably
well' would probably be much more interesting (but a much harder
problem unless things have changed).
If I was hiring people I'd also be much more interested in knowing
that they could write competent & maintainable code than that they
could solve some academic problem. I've looked at too much academic
lisp code...
>
> It is no small chip on my shoulder that for all MIT (where I went to
> school as an undergrad) touts itself and is touted by others as a way
> to prepare you for what's out there, it pretty much wholly overlooked
> all manner of practical advice like the stuff I'm dispensing here when
> it put me through school. It taught us tons of theory, but little
> about the practical application of that theory, often claiming "we'll
> pick that up on our own without prodding". But I'm not so sure that's
> the best way. I'm much more impressed with some other schools
> (Stanford and Northeastern strike me as examples) that don't treat
> "business stuff" as of secondary importance. These things end up
> mattering and can really make or break careers. Students have a right
> to know how they are and will be perceived, not to just assume that
> theoretical might and grades are all that will be looked at. And
> often I think this is what they (especially MIT people) come out
> believing.
>
I'd *really* like to see people be given some kind of clue about basic
economics. Almost everyone I deal with has no idea *at all* what
costs money and how much it costs. I recently had a bunch of
discussions where it became apparent that people (and not stupid
people) had no idea at all how much it would cost to reimplement some
system, because they were either assuming time was free, or
underestimating the cost by a factor of 3 or so. I wonder if anyone
teaches this in CS-type degrees.
--tim
>>>>> "CL" == Christopher Lindop <·····@clindop.fsbusiness.co.uk> writes:
CL> Can anyone suggest ideas for a project involving LISP? I have
CL> to write one for a postgrad degree. I was thinking about
CL> doing a CLOS representation of a chess game. ...any other
CL> ideas???
You're getting a postgrad degree, and doing a programming project, and
you're asking for ideas of what to do?
Anyways, what about incorporating a Lisp system into the Flux OSKit
project, and making a nice bootable Lisp OS?
http://www.cs.utah.edu/flux/oskit/
There's any number of suitable GPL'd or public domain Lisps that would
fit in well.
~ESP
--
Evan Prodromou
····@prodromou.san-francisco.ca.us
In article <··············@priss.bad-people-of-the-future.san-francisco.ca.us>
, Evan Prodromou wrote:
> ...
>Anyways, what about incorporating a Lisp system into the Flux OSKit
>project, and making a nice bootable Lisp OS?
>
> http://www.cs.utah.edu/flux/oskit/
>
>There's any number of suitable GPL'd or public domain Lisps that would
>fit in well.
i think it has been done already with DrScheme or mzscheme
--
hs
----------------------------------------------------------------
"The cheapest pride is national pride. I demonstrates the lack of
characteristics and achievements you can be proud of. The worst loser
can have national pride" - Schopenhauer
Hartmann Schaffer <··@paradise.nirvananet> wrote:
+---------------
| Evan Prodromou wrote:
| >Anyways, what about incorporating a Lisp system into the Flux OSKit
| >project, and making a nice bootable Lisp OS?
| > http://www.cs.utah.edu/flux/oskit/
|
| i think it has been done already with DrScheme or mzscheme
+---------------
MzScheme. See <URL:http://www.cs.rice.edu/CS/PLT/packages/mzscheme/index.html>
MzScheme is available in kernel form for x86 machines, which
allows MzScheme to boot without the aid of a separate operating
system. The MzScheme kernel is based on the OSKit[*].
[*] Is a link to the same OSKit link as Evan gave.
But since this *is* comp.lang.lisp and not comp.lang.scheme, the
question is still interesting: What about some flavor of Common Lisp
(perhaps CLISP, for simplicity) directly on top of the Flux OSKit?
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
"Christopher Lindop" <·····@clindop.fsbusiness.co.uk> writes:
> Can anyone suggest ideas for a project involving LISP?
> I have to write one for a postgrad degree.
A bit late but:
Review the Meta-Object Protocol. Find its strengths and weaknesses.
Suggest improvements. Discuss pros and cons of these changes.
Implement at least one improvement in some CL system.
Stig Hemmer,
Jack of a Few Trades.